Update management is a task IT professionals approach with the same enthusiasm they usually reserve for a visit to the dentist. Ensuring that computers are up-to-date is tedious, and at the back of every IT professional's mind is the fear that lurking somewhere deep within a newly released patch is code that will cause more problems than it solves. You need to balance thoroughly testing updates before deploying them with the knowledge that code that targets the vulnerabilities these updates address usually appears on the Internet within a week of the update's release. Spend too long pontificating on the adverse impact of applying an update and you'll become vulnerable to the exploits the update protects you against.
In this article, you'll learn about several patch-management–related problems and the steps you can take to mitigate them. The particular annoyances this article covers are as follows:
- Determining which updates have already been deployed
- Preventing update traffic from saturating WAN links
- Preventing update installation from interrupting end users' computer use
- esting updates before deployment
This article focuses primarily on problems related to managing updates for Microsoft OSs and applications. Managing updates for third-party products without using a tool such as Microsoft System Center Configuration Manager (SCCM) 2007 poses even more challenges.
Determine Which Updates Have Been Deployed
As more computers in organizations become mobile, administrators have more difficulty determining whether a particular update has been deployed on every computer or just on some of them. Back when I worked in first-level support, it was easy to keep track of which updates had been installed because we had to install them manually and would cross computers off a central list as each computer was done. When updates deploy automatically over the network, it's more difficult to track whether updates have deployed successfully, unless you use solutions such as SCCM 2007.
Most organizations use Windows Server Update Services (WSUS) to manage the deployment of OS updates, as well as updates for Microsoft applications. When a configured computer contacts the WSUS server to obtain and download updates, the WSUS server records which updates computers have obtained. Computers can contact the WSUS server according to a schedule or the connection can be initiated manually. The drawback to WSUS is that although it records which updates computers have obtained, it doesn't actually check the client to see if any updates are missing, and it can be hazy on whether the update that was obtained has actually installed correctly.
WSUS knows only about updates it has provided; it has no way to know if an update has been installed in another way. For example, what if a laptop user spends a few weeks away from the office and uses Windows Update through the Internet, rather than WSUS, to keep her computer up-to-date? WSUS doesn't know about these updates because it's aware only of updates it distributes, not updates obtained from other locations. WSUS also knows only about computers that have reported to it. It's possible for WSUS to be completely unaware of computers on your network because, for some reason, those computers have never been able to successfully contact the WSUS server.
There are two free solutions to help with the problem of knowing which updates are installed, so you don't have to manually check each computer to see whether a specific update is installed and you don't have to deploy a solution such as SCCM 2007 that can be a drain on your IT department budget. The first free tool you can use to check computers for missing updates is the Microsoft Baseline Security Analyzer (MBSA), which you can download from Microsoft's website. The latest version, MBSA 2.1.1, supports scanning Windows 7 and Windows Server 2008 R2 computers. You can use MBSA to check for all missing updates from a list published by Microsoft or against the list of updates that you’ve approved on a WSUS server. It would be nice if the MBSA tool's functionality were included with WSUS so that update deployment and checking could occur from a single console, but Microsoft currently has no plans to combine these two products.
Instead of the MBSA tool, you can use Get-Hotfix, a new cmdlet included with Windows PowerShell 2.0. Get-Hotfix lets administrators query computers locally or remotely to determine which hotfixes are installed. Using PowerShell scripting, you can query a list of computers to determine whether an update or a specific list of updates is missing. For example, the following script scans all computers listed in the file computers.txt and adds the names of computers missing the hotfix indicated by the identifier KB974332 to a text file named Missing-KB974332.txt:
get-content computers.txt | foreach
{ if (!(get-hotfix -id KB974332
-computername $_ -ea 0))
{ add-content $_
-path Missing-KB974332.txt }}]
Although the code appears on multiple lines here, you would enter it all on one line. The bit of code -ea 0 sets the error action to silent, preventing the command from producing error text during execution.
Prevent Update Traffic from Saturating WAN Links
Organizations deploy solutions such as WSUS not only to centralize the deployment of updates but also to minimize the amount of update traffic downloaded from the Internet. Rather than 1,000 computers downloading a 100MB update, one WSUS server can download the update and then distribute it to all computers on the network. This process works fine until you take into account branch offices and saturated WAN links. Just as you generally don't want to have all your computers downloading the same large update from the Internet, you don't want to have 100 computers at a branch office all downloading the same update from the head office WSUS server across a low-bandwidth WAN link.
You can configure WSUS so that it hosts only the update approval list and not the update files, forcing WSUS clients to download update files from the Internet, but this means that all WSUS clients, not just those in branch offices, source their update files from Microsoft's update servers. In many organizations, the solution to this problem has been to configure separate WSUS servers at each branch office location, with branch office clients obtaining updates from their local WSUS server. However, adding WSUS servers adds to administrative overhead. It's possible to configure WSUS servers in an upstream/downstream relationship so that updates approved on one server are automatically approved on another, but every server you add to your infrastructure will increase costs in some way.
The solution for branch office computers is to leverage a new technology called BranchCache in conjunction with Windows' existing Background Intelligent Transfer Service (BITS) peer caching functionality. BranchCache is a new feature for computers running Windows Server 2008 R2 and Windows 7 (Enterprise or Ultimate editions). BranchCache lets clients at branch offices share content automatically with each other when they obtain that content from an appropriately configured remote server. BITS peer caching is an existing Windows networking technology that can work in concert with BranchCache to make update transfer across the network more efficient.
You configure BITS and BranchCache through Group Policy. BITS and BranchCache policies are found in the Computer Configuration\Administrative Templates\Network node of a Group Policy Object. You can leverage BranchCache with WSUS only if the WSUS role is installed on a computer running Windows Server 2008 R2 and the client computers are running Windows 7 Enterprise or Ultimate edition.
The advantage of using BranchCache and BITS with WSUS is that organizations can use a single WSUS server to deploy updates to head office and branch office networks without saturating branch office WAN links with update traffic. Updates are retrieved across the link by one branch office client, then shared with the other clients at that location. This has the advantage of a local branch office WSUS server without the additional administrative overhead. You can find out more about BranchCache in the Microsoft article "Server Configuration."