System Center Configuration Manager 2007 : Patch Management - Creating and Managing Deployments (part 1) - A Recommended Approach

2. A Few Best Practices

Best practices are always tricky business—what works for one organization is not necessarily the best fit for another organization. Nevertheless, it is always good to have a starting point, a set of guidelines or recommendations from those that have been through the trenches and survived. Actually, you can learn from those who didn’t survive; things like “Don’t step there” or “Don’t drink the water.”

• Manual intervention— Unlike the standalone version of WSUS, some manual intervention is required on an on-going basis to deploy updates with ConfigMgr. You must identify and download updates every time you want to deploy them. There is no way to automate this. Some may feel that this is a knock against the ConfigMgr Software Updates function, but this manual intervention is relatively minor and ensures that no updates are distributed in an organization without explicit, hands-on configuration.

• Update packages— Clients will pull applicable updates from any available package. Because of this, there is no specific need to separate updates into multiple packages. The only real limitation is a recommended technical limit of 500 updates per package. Some separation of updates is therefore logical, and the general guideline is to create a single update package for every calendar year of updates. Separating updates by operating system will produce duplication because some patches do cross operating system boundaries or are not operating system specific.

• Update lists— Update lists are the perfect way to track what updates were actually deployed in a given update deployment cycle. Because Microsoft sticks to its monthly update release rather vigorously, it makes sense to create a new list every month to contain the newly released updates. In addition, update lists only contain references to updates, so creating multiple update lists based on operating systems or some other criteria does not create any duplication.

• Deployments— After the deadline for a deployment passes, the need to have a separate deployment for the updates referenced in that deployment goes away. Therefore, on a regular cycle, something like every 3, 6, or 12 months, it makes sense to collapse the updates referenced in individual deployments with past deadlines into larger deployments. This simplifies deployment management and minimizes the number of individual deployments listed in the console.

• Initial setup— When you are first setting up Software Updates, it makes sense to create one large list for all updates before a given date. You can then create a deployment for this list to ensure that any new systems introduced into the environment and any existing ones are fully patched with all updates issued before you started using Software Updates. You can store updates for this list in one large package as long as it does not break the 500-update barrier.

• Naming conventions— Unlike the rest of the nodes in ConfigMgr, subfolders cannot be created under Update Lists, Deployment Management, and Deployment Packages. For this reason, you should establish and stick to a strong naming convention for these object types. This naming convention should clearly describe the criteria used to choose the updates contained in the given object, and ensure that objects are sorted chronologically. Table 1 contains a sample naming convention for each of these types of objects.

  Table 1. Example Software Update Object Names

  Object Type	Sample Names
  Update List	Windows XP Updates - Pre 2008 Windows Vista Updates - Pre 2008 Windows XP Updates - 12/08 Windows XP Updates - 01/09 Windows Vista Updates - 01/09
  Deployment	Windows XP Updates - 2008 Windows Vista Updates - 2008 Windows XP Updates - 01/09 Windows Vista Updates - 01/09
  Deployment Package	All Updates - 2009 All Updates - Pre 2009

  
  

3. Maintenance Windows

Deployments are somewhat limited in that they do not define an exact time that updates should or must be installed; they merely define a time when updates become mandatory. This limitation could easily cause disruption to your users and your servers if updates install at various times after the deadline.

Maintenance windows are the perfect solution to this dilemma. In general, maintenance windows prevent the ConfigMgr client from undertaking any action that could disrupt the end user on a system. This includes preventing Software Updates deployments, Software Distribution advertisements, and restarts initiated by ConfigMgr for software updates.

Because they are set on a per-collection basis, you can create maintenance windows for specific recurring and nonrecurring start and stop times. You edit these schedules by right-clicking any collection and choosing Modify Collection Settings. This displays the Collection Settings dialog box, where the first tab, Maintenance Windows, manipulates these windows. The interface for creating maintenance window schedules, displayed in Figure 2, is quite flexible and allows you to specify settings such as every third Tuesday of the month.

Scheduling with Maintenance Windows

If the collection where the deployment is effective has a maintenance window, the agent schedules installation for the start of the next occurrence of that maintenance window. The agent also calculates how much time it will take to install all the identified updates, ensuring the updates will not break the maintenance window. Additionally, 15 minutes are also added to this calculated window of time to account for a system restart. If installing the updates will exceed the window, the agent chooses a subset of the updates. If no applicable maintenance window exists, the agent immediately starts installing all updates.

After a deployment completes on a managed system, an additional compliance scan occurs to ensure successful installation of all updates. ConfigMgr forwards the results for this scan to the management point using state messages. This process is significantly expedited compared to the ITMU process and ensures the compliance data in the ConfigMgr database is always current.

Using Multiple Maintenance Windows

Maintenance windows affect software updates; they prevent updates in a mandatory deployment from installing on a system outside configured maintenance window times. This causes any mandatory deployment past its deadline to wait until the next configured maintenance window before installing its updates.

You can create multiple maintenance windows on a single collection. Any system belonging to multiple collections is also subject to the maintenance windows of those collections, because multiple maintenance windows on a single system do not cancel each other.

Maximum Runtimes

Another check performed by the Client agent is the maximum runtime for each applicable update in a deployment. If the sum of these maximum runtimes is greater than the maintenance window allows for, the Client agent will not install all applicable updates. The updates will be culled based on their maximum runtime, ensuring they complete before the window ends. To view or edit the maximum runtime for any update, find the update (in the update repository, an update list, a deployment, or even a deployment package), right-click it, and choose Properties. This opens a Properties dialog box for the update with a Maximum Run Time tab, shown in Figure 3; the value listed is editable. You can also multiselect updates to change their maximum runtimes in the same way. By default, all updates have a maximum runtime of 20 minutes.

Note that clients begin downloading updates as soon as deployments are available to them. This prevents the time required by clients to actually download updates from affecting the time available in the maintenance window.

Bypassing Maintenance Windows

Configure specific deployments to ignore configured maintenance windows by selecting the Ignore maintenance windows and install immediately at deadline check box on the Schedule tab of a deployment. Use this option very carefully if you have gone through the trouble of defining and setting up maintenance windows, because it will disrupt your carefully planned update scheduling. However, in the case of zero-day updates, the disruption may be necessary.