This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What triggers ZENworks to replicate Content Bundles

The general question I'm trying to get answered is what triggers ZCM replicate a bundles content, is it the action of uploading content or incrementing the bundle? It's obvious that when you create a new bundle or select a new server to replicate that content to, it will be replicated during the next content replication schedule. But what if you already have a bundle (with content like Install File or Install Directory) and you modify the the content (i.e. you add an extra file(s) or directory(s) to the action). Do you need to increment the version of the bundle to trigger the replication or does the action of uploading the content trigger the replication to all other servers that the bundle is currently set to "include" in replication?
Parents
  • dlagiglia,

    It appears that in the past few days you have not received a response to your
    posting. That concerns us, and has triggered this automated reply.

    Has your problem been resolved? If not, you might try one of the following options:

    - Visit http://support.novell.com and search the knowledgebase and/or check all
    the other self support options and support programs available.
    - You could also try posting your message again. Make sure it is posted in the
    correct newsgroup. (http://forums.novell.com)

    Be sure to read the forum FAQ about what to expect in the way of responses:
    http://forums.novell.com/faq.php

    If this is a reply to a duplicate posting, please ignore and accept our apologies
    and rest assured we will issue a stern reprimand to our posting bot.

    Good luck!

    Your Novell Product Support Forums Team
    http://support.novell.com/forums/

  • Content replication (along with a LOT of other tasks) is dealt with by the Zen Loader Service on your Primary Content Servers. The service looks at a table in the backend database to get it's work queue (zQueue table I beleive). It then works through the queue. This is why it can take a while to replicate.

    I cannot say for sure but I'm 95% sure it will replicate content on upload. Although it will not deploy to clients that have already installed the bundle until you have incremented the version.

    If you are looking for 100% certainty you can monitor the zQueue table in your database to see when the changes are added to the queue.
  • We had an issue where we disabled af few actions in a larger bundle consisting in many install bundle actions in the Install Action set.
    We have 3 primary servers and the result was that in ZCC the bundle showed up with disabled actions on each of the ZCM servers, but the change did not replicate to them untill we did a version "bump". (this was evident on the clients getting the bundle)
    My take on this is that intra Server Replication follows the Server/Client rule where the client does not update/change anything in a bundle unless we have a version "bump".
    From a server 2 server replication perspective this is a bug, as the meta-data change of disabling / enabling actions may be disirable to get implemented to any NEW workstations/users using ANY primary server (thus needing the replication to kick in), but where we DO NOT wish to affect the existing install base for any given bundle.

    Should this be a SR or a RFC ?

    KR/Bjørn
Reply
  • We had an issue where we disabled af few actions in a larger bundle consisting in many install bundle actions in the Install Action set.
    We have 3 primary servers and the result was that in ZCC the bundle showed up with disabled actions on each of the ZCM servers, but the change did not replicate to them untill we did a version "bump". (this was evident on the clients getting the bundle)
    My take on this is that intra Server Replication follows the Server/Client rule where the client does not update/change anything in a bundle unless we have a version "bump".
    From a server 2 server replication perspective this is a bug, as the meta-data change of disabling / enabling actions may be disirable to get implemented to any NEW workstations/users using ANY primary server (thus needing the replication to kick in), but where we DO NOT wish to affect the existing install base for any given bundle.

    Should this be a SR or a RFC ?

    KR/Bjørn
Children
  • This is likely an RFE that is already handled with ZCM 11 Sandboxing.

    On 12/16/2010 5:06 AM, bkelsen wrote:
    >
    > We had an issue where we disabled af few actions in a larger bundle
    > consisting in many install bundle actions in the Install Action set.
    > We have 3 primary servers and the result was that in ZCC the bundle
    > showed up with disabled actions on each of the ZCM servers, but the
    > change did not replicate to them untill we did a version "bump". (this
    > was evident on the clients getting the bundle)
    > My take on this is that intra Server Replication follows the
    > Server/Client rule where the client does not update/change anything in a
    > bundle unless we have a version "bump".
    > From a server 2 server replication perspective this is a bug, as the
    > meta-data change of disabling / enabling actions may be disirable to get
    > implemented to any NEW workstations/users using ANY primary server (thus
    > needing the replication to kick in), but where we DO NOT wish to affect
    > the existing install base for any given bundle.
    >
    > Should this be a SR or a RFC ?
    >
    > KR/Bjørn
    >
    >



    --
    Craig Wilson - MCNE, MCSE, CCNA
    Novell Knowledge Partner

    Novell does not officially monitor these forums.

    Suggestions/Opinions/Statements made by me are solely my own.
    These thoughts may not be shared by either Novell or any rational human.

    --

    Be sure to "Like" My (and a few others) Cool Solutions below! 

    https://community.microfocus.com/members/craigdwilson/bookmarks