Steve Pruitt at myITforum.com

Have you ever designed a patching process, only to find that users and managers complained after you implemented it, and no one supported you? Good planning and communications with the right people help assure that you develop a good plan, that the plan is approved by everyone concerned, and minimize problems and complaints during the deployments.

Before designing a patch deployment methodology you must understand your tools and objectives:

• Understand the options available to manage the deployment. These are different for WSUS, SMS 2003, ConfigMgr (also known as SCCM 2007) and other software. If you use SMS, you can combine the patch deployment options with other SMS capabilities such as running only if no user is logged on, wrapping the deployment execution in a script that adds options, etc.
   
• Get your management’s guidance and expectations. What are your trade-offs between security and disruption? What standards are expected for completing the patching? The best security means completing the patching quickly, but that also requires the greatest disruption. Avoiding disruption extends the time needed to complete securing the network. This should be one of your first questions to your management. The preferred guideline is in the form of “Use the least disruption that allows completing patching to 99% within ___days” or something similar.
   
• Understand the business needs of your environment. That means talking with key business unit and IT management.

Your plan has to include a few key parts that you can develop through communications:

• What are the restrictions on rebooting computers in various groups? Some can be scheduled, some require control by the computer users or other responsible people.
• Most companies have some groups that can be rebooted any night without problems, others that can never be rebooted during the night, and others that need to control the timing. For example, if you have a 24-hour call center, you can't do anything that will reboot all of those representatives at the same time. It needs to be spread out and controlled. Operations consoles can't be rebooted during their working hours, which are often the middle of the night. There are usually some IT managers, such as Desktop Support or Call Center, who can identify various such groups and the managers there to talk with.
   
• Will reboots occur immediately after the updates are applied or some time later? Will they be automatic or manual? If manual, how will you manage and enforce the requirement?
   
• How much time do various group need to schedule reboots? For example, Insurance company actuaries often run calculations that require several days to complete. Do you have any similar functions?
   
• How will you handle computers, such as laptops, that are offline during the normal patching period? Will they be patched immediately after they reconnect, or will users be allowed a period to complete this?
   
• How will pilot testers be selected, and replaced as required? Who will test for a department if a pilot tester is on vacation?
   
• How will you identify the computers that fall into different groups, and how will you maintain the accuracy of those lists? That includes groups that are treated differently for deployment schedules or options and pilot testers. Maintaining the accuracy of these lists is vital - errors in these lists will cause the biggest problems and complaints most of the time. If possible, find a way to identify critical groups of computers automatically by subnet or some other common characteristics that SMS can use in collection queries.
   
• Who do you need to communicate with on a regular basis? How will those lists be maintained? These may include users that will get different deployment handling than most users, pilot testers, managers of key departments, etc.

Find out which departments are particularly critical to the business, and talk to them to find out if they have any special needs. Find out which departments are known to complain to IT senior management, and include them in your planning from the beginning. You need to come up with a patch management system that will meet the needs of all of these groups. Talk to each group and find out their requirements. Explain the importance of protecting their computers with the minimum of disruption.

Once you develop a plan that you think will meet their needs, you have to convince a number of groups of people that your plan is sound. That means selling it, and also listening closely to all complaints or objections. In most cases you should be able to explain how the issues are handled in the plan. Sometimes you'll need to think about the issues the raise and revise the plan accordingly.

• The first group is your management. You can't go any further until your boss and perhaps one level higher have agreed to support your plan.
   
• The second group is the corporate security manager or team. If they believe you have a good plan that adequately protects the company, they can help convince other people.
   
• The third group is all of the other managers you talked with while developing your plan. Show them how your design reflects their needs, and explain their responsibilities to assure that their computers are protected with the minimum of disruption.

Finally, if you are changing what the users will see or what they must do, you have to explain this to all of them. Use all of the communications opportunities your company offers, including newsletters, regular meetings with all managers or all employees, etc. Follow this up with an email to all employees that has a brief explanation and a link to a more complete presentation for those that are interested. Ask your corporate communications staff to help prepare and send this out.

If you follow this communications process, you should have the understanding and support of the IT and business unit management that are most affected by your patching strategy. This will go a long way towards minimizing problems as you implement the plan.