Software Update Management: Managing SUM objects
Following on from my post on the new objects in Software Update Management I thought I'd jot something down around how to manage the two main objects: Deployment Packages and Deployments.
This is all subject to change as it's still a new feature. No doubt best practices will change but at least this is a starting point and I'll come back to it in the future to keep it up to date.
Deployment Packages
Clients can install targeted updates from any deployment package available. This gives you a lot of flexibility in this feature.
At its simplest, you could just create a single package that contains all updates that you want to install and distribute this to all of your distribution points. If you have lots of storage on your DPs then this is an easy option that removes a lot of admin effort. However, you may be wasting a lot of storage and network usage when doing this. Some ways you may want to cut this down are:
- Create language specific packages and distribute this to the applicable regions.
- If you know a certain site only manages servers then create a package specifically for server updates, similarly if the site only manages PCs.
- If you know that a certain application is only used in a certain region then create a package containing updates for that application and only distribute to the applicable region's DPs
With any of the above you do need to consider roaming clients. For example, if a computer from one language region roams to another site and you still want it to receive updates when roaming you'll need to accept that these will come across the WAN from the assigned site DPs rather than locally.
So all this probably leads most people to think "I'll just stick everything in one package, that's much easier". A few words of warning:
- That package is going to get very large after time. If that package somehow becomes corrupted on one of your DPs and you need to refresh it then that is a lot of data to have to send to the DP again.
- At some point you will want to reclaim some storage and clear out a lot of updates that are no longer required. If you only have one large package then this will be a cumbersome task.
For the above reasons I would avoid a single large package and instead go with something like a yearly package. Another option is to go with platform based packages, that way when you no longer have any Windows XP clients (you're all upgrading to Vista right?) you can get rid of the Windows XP package and get some of your storage back.
Deployments
My initial instinct for this was to try and do things in the same way as most of us used to with SMS 2003 i.e. one large "sustainer" package and then a monthly smaller package (if anyone hasn't already heard of this approach with SMS 2003 then let me know and I'll post something, but most are probably familiar with it).
You would therefore have two deployment objects:
- A "sustainer deployment": Contains all updates other than those released on the most recent month. Deadline is set to some time in the past so that any out of date clients install these updates as soon as possible to ensure that all computers meet a certain baseline.
- A "monthly deployment": Contains updates released in the most recent month. Deadline is set according to the highest priority update within the deployment. This ensures that users have a certain period of time each month to install updates before the deadline is reached. If an update deemed critical is included in the deployment then the deadline will be shorter than if all updates are a low priority.
This would mean that each month (when new updates are released) you move the updates in the current "monthly" to the "sustainer" and add the new updates to the "monthly", and update the deadline on the "monthly" accordingly.
However, whilst this represents an easy way to do things, there are some drawbacks. The main one is that information on the updates included in a given deployment is stored in a single policy per deployment. After time the "sustainer" could have hundreds of updates in and this policy could grow to several MBs. Each time you move updates into the sustainer the policy gets updated and clients need to download it again. This is rather wasteful and depending on your network and design could have some nasty network impact. It also gets cumbersome for the client to process such a large policy.
Therefore, with this in mind I believe a better approach is to create a new deployment each month. That keeps the policy small and means that once a client has downloaded the policy for that month, it never needs to again. It also makes it easier to clear things out at a later date if you no longer need deployment objects that are years old.
Of course, you may also need to create other deployments for specific purposes or exceptions but if I try and list what all of those might be I'll be here all day. You'll figure these out as you start thinking about how you're going to use the feature.
Final Thought
I haven't gone into them here, but remember, Update Lists are your friend(s). Take a look at the online guidance: http://technet.microsoft.com/en-us/library/bb693591.aspx.