Multiple Bundles Deploying

Hi,

We're experiencing a very strange issue in 1 of our classrooms that we're not seeing anywhere else. Normally, when deploying bundles, they come down one at a time in an orderly fashion.. In this lab, they seem to come down all at once, conflicting with each other and causing all manner of chaos.

This lab happens to run Macs and uses Windows / Zen via Boot Camp; I can't see how this difference would have an effect so I'm wondering if anyone else has seen this issue before? All the other labs are various flavours of hardware running Windows 7.

Any thoughts?

Neil.

Tags:

Parents
  • There's really only one way to control bundle order in ZCM 10/11.

    Unfortunately it can have some unwanted side-effects.

    Basically you will make a bundle that launches other bundles. Then they'll run in the order listed.

    The possible unwanted side-effect is that the "parent bundle" associations (relationships) get passed along to the child bundles.

    So unless you always want to deploy all your bundles to all your users and devices at the same time, you have to choose between having bundles run at the same time (and thus you get errors/conflicts) or deploying ALL the bundles to ALL your users/devices at once (which can also cause problems if something goes wrong).
  • Thanks for the info but I think you may have missed the point..

    In every other area (all PC based Windows 7 - probably about 800 machines in total) plus various satellite areas, the bundles run asynchronously, nice and ordered,without any intervention from me; all I've done is related them to a particular account or device group and then Zen runs through them.

    In 1 area (Mac based with Windows 7 running from Boot Camp) the bundles, for whatever reason, are coming down synchronously, so conflicting with each other as they compete for Windows Installer time. I was just curious to know if anyone had experienced this before? Just thought it was a bit coincidental that the area this happened on happened to be a Mac based build.
  • No, they work the same in that regard.

    In ZDM, I could get the same results.

    Both rela

    On 8/1/2012 9:23 AM, Niels Poulsen wrote:
    > craig wilson wrote:
    >
    >> Which is why you could have a master bundle even with 25 bundles with
    >> an order set and end up having all 25 run at once
    >>
    >> or
    >>
    >> you could have no ordering, but still have the 25 wait on each other.
    >>
    >> All depending n how you configure the bundle.
    >>
    >>
    >>
    >> On 7/31/2012 10:39 AM, Shaun Pond wrote:
    >>> Craig,
    >>>
    >>> well duh :)
    >>>

    >
    > But did this not happend by default in ZDM?
    >



    --
    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.
  • craig_wilson;2210386 wrote:
    No, they work the same in that regard.

    In ZDM, I could get the same results.

    Both rela

    On 8/1/2012 9:23 AM, Niels Poulsen wrote:
    > craig wilson wrote:
    >
    >> Which is why you could have a master bundle even with 25 bundles with
    >> an order set and end up having all 25 run at once
    >>
    >> or
    >>
    >> you could have no ordering, but still have the 25 wait on each other.
    >>
    >> All depending n how you configure the bundle.
    >>
    >>
    >>
    >> On 7/31/2012 10:39 AM, Shaun Pond wrote:
    >>> Craig,
    >>>
    >>> well duh :)
    >>>

    >
    > But did this not happend by default in ZDM?
    >



    --
    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.


    Yes and no

    In ZFD if you did not:
    check the box "wait on force run"
    and left the apps as the default "force run" order of 0
    AND checked the associations as "force run"

    Then they would all basically "run at the same time".

    IF, however, you checked the box "wait on force run" and STILL left them at "force run order of 0", and had them associated as "force run", then they would run one at a time, based upon the alphabetical name of the app.

    Novell changed/added that same functionality in 11.2.1 with those new options.

    You could, alternatively, accomplish the same thing (even in 11.2.1) by creating a "master" bundle with launch actions of like:
    zac bln "bundle name"
    and have those wait until the action is complete.

    Pros and cons to each, to be honest. The Master bundle is nice because you have a visual order of your bundles via the Install Actions (vs. the new feature, where you have to manually maintain some sort of spreadsheet about what the order was that you gave the bundle). But, that's at the expense of a rather busy/cumbersome set of install actions every time you want to do something (not to mention re-ordering anything in there).

    All the above assumes of course, that you have ALL your bundles (that are "force runs") in either a master bundle or you've set them up accordingly with the new feature set.

    Forget to do that in EITHER case, and you'll have more than one bundle running at the same time (which, depending on what you are doing may or may not cause problems).
  • Hi Shaun,

    I worked and still work with bundle groups in order to have the bundles installed in the right order and one after the other. This worked very well with version 10 and earlier versions of 11. Now with version 11.2.1 the bundles do not respect any installation order nor do they wait for any previous bundle to complete.

    I have opened an SR because I guess that this change of behavior is not normal

    --

    Calimero
  • Calimero,

    no it's not normal, if you are taking advantage of the new feature...

    --

    Shaun Pond


  • Shaun,

    The point is that I haven't made any change except upgrading the servers and test the new agent on a fresh install respectively on a re-imaged pc. And what was working before is not working any more or at least it is not working as it worked before. So right now I am not using the new feature.:)

    --

    Calimero
  • Calimero,

    bundle groups never controlled installation order - it's the whole
    reason that the new feature was added. You've been lucky up to now...

    --

    Shaun Pond


  • Shaun,

    Ok then I must have been very lucky! I did my whole deployment like this and it worked ! I guess I used un undocumented hidden feature. :) But at least I am not the only one. I was discussing the issue with my contact at Novell Luxembourg and he told me that he was also using the bundle groups in the same way as I did. That's why he told me to keep him informed about it. I will change my configuration and use the new feature then. I have an SR opened on this should I tell them to close it?

    Thanks

    --

    Calimero
  • Calimero,

    you could wait until they come back and confirm what I said :) TID
    7006162 was created back in 2010 for this, I'm going to update it with
    a reference to the new bundle ordering feature...

    --

    Shaun Pond


  • Calimero;2212424 wrote:
    Shaun,

    Ok then I must have been very lucky! I did my whole deployment like this and it worked ! I guess I used un undocumented hidden feature. :) But at least I am not the only one. I was discussing the issue with my contact at Novell Luxembourg and he told me that he was also using the bundle groups in the same way as I did. That's why he told me to keep him informed about it. I will change my configuration and use the new feature then. I have an SR opened on this should I tell them to close it?

    Thanks

    --

    Calimero


    I wonder if the tech is confusing Bundle Grouping with Bundle Dependencies

    Bundle Dependencies COULD (in certain cases) do what you described.

    The downside is that you could only make assignments to the one/single/parent bundle. Which only worked if ALL your users/devices need that bundle, and every single bundle below it.

    For customers like myself, not all our bundles are assigned to everyone. But we still needed the ability to control the ORDER in which they were deployed.

    Prior to 11.2.1, Craig had come up with a pretty nifty neat method to do this, which we used for a bit, but now that we have 11.2.1 we can have our cake and eat it too (mmm, cake)
  • Hi,

    I have no dependencies on these bundles. All our bundles are assigned to devices and I have grouped the default bundles in a bundle group which is assigned to all our workstations. I have done my initial deployment of 1100 workstations and on every workstation the bundles installed in the order they were listed in the bundle group. This was made with version 10.3.x of the Agent. After that all new workstation, in the mean time with Agent 11.1, had the same behavior when deployed. With Agent 11.2.1 it doesn't work anymore. And I was not the only one who was successfully deploying bundles like this. And honestly when I started my deployment I was happy to have something that worked like I wanted it to do and I did not care to check if this was supposed to work like this or was documented to do so.
Reply
  • Hi,

    I have no dependencies on these bundles. All our bundles are assigned to devices and I have grouped the default bundles in a bundle group which is assigned to all our workstations. I have done my initial deployment of 1100 workstations and on every workstation the bundles installed in the order they were listed in the bundle group. This was made with version 10.3.x of the Agent. After that all new workstation, in the mean time with Agent 11.1, had the same behavior when deployed. With Agent 11.2.1 it doesn't work anymore. And I was not the only one who was successfully deploying bundles like this. And honestly when I started my deployment I was happy to have something that worked like I wanted it to do and I did not care to check if this was supposed to work like this or was documented to do so.
Children
No Data