Verified Answers

If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it! Learn more

  • State Not Answered
  • Replies replies
    4
  • Subscribers subscribers
    41
  • Views views
    352
  • Users 0 members are here
  • Locked Locked
Related
Options
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

MigrationDeletedUser
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
  • 0
    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/

  • 0 in reply to MigrationDeletedUser
    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.
  • 0 in reply to MigrationDeletedUser
    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
  • 0   in reply to bkelsen
    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

Reply
  • 0   in reply to bkelsen
    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

Children
No Data

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.