The hairline shows how long I've been in IT
Patch Management is only partly a technical activity. Good communications are at least as important, if not even more so. No matter how well you designed your deployment plan to support the needs of your business, you need to communicate effectively with the right people each month to be successful. The general principle is to avoid surprises. If everyone knows what’s going on that concerns them, the whole process proceeds smoothly. What things should you communicate, and who do you tell? The answer always depends on details of how your company is organized, how it operates, and how you deploy the updates. Here are some examples to consider:
Anticipated Patching
What: On Thursday before Patch Tuesday, Microsoft announces the updates they expect to release the following week. Keep in mind that the actual release may contain more or fewer updates and could also include re-released updates. When: Shortly after the pre-announcement is available. Why: This announcement doesn’t contain a lot of detail, but it’s enough to have some idea how great the impact may be. Who to tell: Share a summary of this announcement with everyone involved in Change Management, so they can begin thinking of possible impact on other planned activities.
What: On Thursday before Patch Tuesday, Microsoft announces the updates they expect to release the following week. Keep in mind that the actual release may contain more or fewer updates and could also include re-released updates. When: Shortly after the pre-announcement is available. Why: This announcement doesn’t contain a lot of detail, but it’s enough to have some idea how great the impact may be.
Who to tell: Share a summary of this announcement with everyone involved in Change Management, so they can begin thinking of possible impact on other planned activities.
Patch Release Details
What: Summary of details of each update, including the affected operating systems or products, how the vulnerabilities could be exploited (i.e., through email, web sites, network connection or physical logon), if the update requires a reboot, and if it can be uninstalled. When: On Patch Tuesday afternoon or first thing the following morning. Why: This helps people understand what applications might be affected and the impact of the deployment. Who to tell: Everyone involved in Change Management or testing of server applications.
What: Summary of details of each update, including the affected operating systems or products, how the vulnerabilities could be exploited (i.e., through email, web sites, network connection or physical logon), if the update requires a reboot, and if it can be uninstalled.
When: On Patch Tuesday afternoon or first thing the following morning.
Why: This helps people understand what applications might be affected and the impact of the deployment.
Who to tell: Everyone involved in Change Management or testing of server applications.
Deployment Schedule and User Impact
What: The planned schedule for deploying updates to pilot testers, other special groups, and the general population, including the deadlines for each group that is allowed to postpone or schedule updates. Explain the normal activities required and any unusual activities or appearance. Include a link to a comprehensive explanation of the patching process for users. When: The afternoon after Patch Tuesday, or as soon as the schedule and activities are known. This should be after initial testing is completed. Why: If users know what to expect to see and what to do, you’ll have fewer calls to the Help Desk and fewer problems. This also serves to explain the patching process to new employees. This also helps many people schedule changes or other activities to avoid conflict with the updates. Who to tell: All employees that will see update activities. You may want separate communications to pilot testers and other users that have different schedules or activities than the majority of users. That allows simplifying the message to all employees and reduces confusion.
What: The planned schedule for deploying updates to pilot testers, other special groups, and the general population, including the deadlines for each group that is allowed to postpone or schedule updates. Explain the normal activities required and any unusual activities or appearance. Include a link to a comprehensive explanation of the patching process for users.
When: The afternoon after Patch Tuesday, or as soon as the schedule and activities are known. This should be after initial testing is completed.
Why: If users know what to expect to see and what to do, you’ll have fewer calls to the Help Desk and fewer problems. This also serves to explain the patching process to new employees. This also helps many people schedule changes or other activities to avoid conflict with the updates.
Who to tell: All employees that will see update activities. You may want separate communications to pilot testers and other users that have different schedules or activities than the majority of users. That allows simplifying the message to all employees and reduces confusion.
Special Deployment Announcements
What: These are announcements to pilot testers, users responsible for exception machines that get non-standard deployment options, and anyone else who sees deployment schedules or options that are different from the majority of users. When: On the day updates are deployed to each group, or very shortly before. Why: These announcements serve as a reminder of the update schedule for their particular machines, a reminder of which machines are affected, and a reminder of the testing and feedback that is expected of them. This is intended the improve the quality of pilot testing and feedback, and reduce problems resulting from updating exception machines. Who to tell: All users who will receive deployments on a different schedule than the majority of users or who have different options for postponing or processing updates.
What: These are announcements to pilot testers, users responsible for exception machines that get non-standard deployment options, and anyone else who sees deployment schedules or options that are different from the majority of users.
When: On the day updates are deployed to each group, or very shortly before.
Why: These announcements serve as a reminder of the update schedule for their particular machines, a reminder of which machines are affected, and a reminder of the testing and feedback that is expected of them. This is intended the improve the quality of pilot testing and feedback, and reduce problems resulting from updating exception machines.
Who to tell: All users who will receive deployments on a different schedule than the majority of users or who have different options for postponing or processing updates.
Deployment Issues
What: You will occasionally find issues with certain updates that change the deployment plans. These might include problems that prevent proper patching or conflicts with important business applications. The information you supply includes the affected update, the issue preventing normal deployment, the affected machines, the revised deployment plan, and the plan for resolving the issue. When: As soon as the issues are found and the revised plan is decided. Why: The affected people need to know if an update will be deployed separately, later, or if the entire deployment is being delayed, or if an application is affected by an update. Who to tell: In each case, the Information Security and appropriate IT management must be informed. Other people may need to know if they have to take different actions because of these changes. Any more general announcements must be written and timed to minimize confusion that can result.
What: You will occasionally find issues with certain updates that change the deployment plans. These might include problems that prevent proper patching or conflicts with important business applications. The information you supply includes the affected update, the issue preventing normal deployment, the affected machines, the revised deployment plan, and the plan for resolving the issue.
When: As soon as the issues are found and the revised plan is decided.
Why: The affected people need to know if an update will be deployed separately, later, or if the entire deployment is being delayed, or if an application is affected by an update.
Who to tell: In each case, the Information Security and appropriate IT management must be informed. Other people may need to know if they have to take different actions because of these changes. Any more general announcements must be written and timed to minimize confusion that can result.
Patching Progress Reports
What: Management reports of the progress applying updates and explanation of any differences from normal. When: The management receiving these reports will specify the desired frequency. In larger organizations there may be separate detail reporting to lower levels of management and summary reporting to senior management, with different frequencies. Typically there are a small number of regular reports at key dates, plus exception reports if required. Why: IT and Security management will generally want progress reports for any important projects. Security patching, even though it occurs every month, qualifies in most companies. In addition, if problems arise in any portion of the deployment it’s vital to inform the proper people as soon as possible. For example, an update to a particular product may frequently fail for some reason that didn’t turn up in initial testing. This would require developing a plan for rerunning that update, which may entail unplanned user disruption.
What: Management reports of the progress applying updates and explanation of any differences from normal.
When: The management receiving these reports will specify the desired frequency. In larger organizations there may be separate detail reporting to lower levels of management and summary reporting to senior management, with different frequencies. Typically there are a small number of regular reports at key dates, plus exception reports if required.
Why: IT and Security management will generally want progress reports for any important projects. Security patching, even though it occurs every month, qualifies in most companies. In addition, if problems arise in any portion of the deployment it’s vital to inform the proper people as soon as possible. For example, an update to a particular product may frequently fail for some reason that didn’t turn up in initial testing. This would require developing a plan for rerunning that update, which may entail unplanned user disruption.
Who to tell: This normally includes the two levels of management above the person managing the deployments plus the Information Security manager. In some organizations, management of server support, desktop support, division CIOs, and others may want to be included in such reporting.
You have to tailor this to your organization, of course. The key is to remember that patching affects every computer, every user, in the company. If the users and managers understand what will happen and when, everything is likely to go much smoother.