Best practice for software deployment/updating?

[Tobias.vonLienen]

Are there any best practice tips on how to best deploy and update software on about 750 devices? We want to automate it as best as we can (using smart groups).

 

One problem that we face is, if we're using smart groups for specific applications and then associate a new revision to that group, it gets automatically deployed to all devices at once. Is there any way to do this for only a few devices a time? 

 

Are there any best practice tips in general? We're open for any new ideas.

[Sean]

Revisions should do this for you.

When a Fileset association exists with a device, through Revisions, there is a 'default' revision, plus other revisions (the default is also available as another revision).  You may either associate 'default' or one of the other revisions to devices.

If you have 'default' as an association with all devices, when you create a new revision, do not yet alter the default.  You may then associate the new revision with a subset of devices for testing.  Once happy with this group of devices, you can then alter the 'default' to be this new revision.  At this point, all devices with default as the revision will update to this newer version, now set as the default.

For example:

This is from the option when creating an association.  Two revisions, yet 3 options:

• version 15.53.6.0
• version 15.40.8.0
• default

Default happens to be 15.40.8.0 at the moment, but that could be changed.  Default still associated, but the revision associated as default becomes altered.

 

[Tobias.vonLienen]

Revisions are great and we want to use them but in this instance I'm searching for something more specific. Let me try to explain our onboarding process as best as I can:

 

We use MDT for initial OS and driver installation. (We don't use FileWave IVS, nor do we plan to) Right after that, we install the FileWave Client onto the new device. The client gets added to the model and we clone it to a group, let's call that "onboarding" where all the standard software filesets are associated. Now even after all these filesets have been installed, the client stays in this "Onboarding" group. This helps because then we can see which filesets have been installed on said client at any time. 

 

If a software needs an update and we associate a new revision to that same "onboarding" group, any new device that gets added to the group will receive the newest version (revision). The problem here is, that since we don't remove the clients that have already been onboarded from that group, all the previous clients will also immediately receive the new revision.

Similar problem if you want to update certain applications using smart groups that filter for if the application is installed. It would immediately install it on all the devices in that smart group. 

Is there a way to roll out these associations/revisions gradually to the same group, so that not all devices within that group try to update immediately?

 

Hope this isn't too confusing..

[Sean]

Adding a new revisions should have zero impact on all devices, until one of two things occur.

• You change the association of which revision within that Fileset
• You have default set as the associated revision and you alter the default to define a different revision

The act of adding a new revision itself shouldn't alter anything on any devices, otherwise.

As noted before, you can set any one single revision within that Fileset to one or more devices, be that a subset of the Onboarding group or not.

With revisions, the association is usually constant and would normally be the case of changing which revision is active on any given device within that Fileset.

Clearly, if there is one single association to a group and you alter which association that is or change the revision that is set within that association, then this will impact all of the devices in that group.  

Typical workflow would be:

• Set default to standard set of devices
• On new revision, create the new revision, associate this revision alone to a set of test devices
• Once test has been confirmed, alter the default to be this new revision
• Repeat for each new version

Your test devices prove everything is okay and then you allow all devices to update to this new version.

However, in your instance, it sounds like you wish to try and stagger the update for some reason and also that you don't want to update devices that already have a revision set, but new devices should receive the new revision.

The idea of not wanting to update current devices, but wanting new devices to instal the latest version is somewhat unusual and a little awkward to handle in some respect.

If your idea is purely to reduce all devices updating at the same time, you could look at a Policy Blocker script.  This suspends management until an exit code of 0 is produced.  They run every 5 minutes.  You could make it, so that the device reports a non-zero exit value for some times of the day and not others.  You could alter this policy for differing blocks of devices, meaning they would only honour a change in Model Number based upon those timings.  This has the obvious drawback that would need to also be allowed for.  What if the device was never on at that time block?

I used to do something similar to this for the old method of Apple software updates, to prevent one bad update from killing loads of machines or lots of machines attempting reboots at the same time, whilst randomising which devices were updated, to prevent taking out an entire department in one go.  Albeit entirely scripted and not involving blocker scripts, but same principle.  If the device name ended with a number from 0-2, update on Monday.  If it ended 3-5, update on Tuesday and if it ended 6-9 update on Wednesday.

Alternatively, consider making sub groups of the main group and associate to these sub-groups instead of all devices.  This way you can change the association for some devices at a time, by associating to the sub groups and not the group as a whole.

When creating the association, don't set the association to the 'default' revision, but instead set it to the desired version for each sub group, effectively never using the 'default' revision.

Continuing the idea of just trying to stagger updates, there are potentially other ways to achieve this.  If it can just be random you could base Smart Groups on random aspects of devices and associate to each of these sub groups, only changing the revision desired as and when.  For example, last character of the serial number, some aspect of the client name, quantity of ram, etc.  This does though require alteration of multiple associations of the same Fileset to be amended as and when.

I guess the real question is what is the problem for your setup?

• What is the issue with all devices receiving an updated version.  Why wouldn't you want this to occur
• Is this issue around bandwidth, user interruption in some way or other
• What is the issue with devices that already have a version installed being upgraded to the new version.  Is there a reason you don't want all devices aligned with single versions of Filesets

Requirement Scripts are also a consideration, but you need to be careful with these.

When a requirement fails, it retries every 2 minutes.  You could do some like, if it is a Monday and device name ends with X, then exit 0.  If it is a Tuesday and device name ends with Y, then exit 0. In all other cases exit non-zero.

Devices that end with a X will only continue the activation process if it is Monday.  Devices whose name ends with Y will only continue the activation process if it is a Tuesday.  Once activated, requirement script will cease running every 2 minutes.  (There are other exit codes to mess with this timing).

There are consequences though.  Again, the idea of capturing devices that were off on the day they should have ran.  Additionally, avoiding a DDOS on the server.  These scripts run every 2 minutes on failure, pulling, running and then reporting back to the server on every fail.  If you have lots of these for lots of Filesets, you could get to the point of overwhelming the server.

Based upon your description, it sounds like you need to consider sub groups with differing associations, which do not use the 'default' revision, but perhaps the real questions above may highlight something else or a differing approach.