WSUS practically stands alone as the premier update-management solution, but you can make it work even better.
Windows Server Update Services (WSUS) is truly of one of Microsoft’s noteworthy accomplishments. Many of us remember its ancestor, Software Update Services (SUS). Back then, software updates arrived with little warning and unpredictable schedules. There were dozens of patch-management solutions on the market, each advertising a unique way to bring order to the onslaught of critical updates.
Then came WSUS, and with it the crop of patch-management solutions seemed to dry up. Standing nearly alone, WSUS reigns supreme as the Microsoft patch-management solution for the masses. Why? Because it works.
Many datacenters use a WSUS server for managing their Windows updates. Even more use the WSUS client—the Windows Update Agent—for installing each update’s executable code. Nevertheless, many still struggle to deploy updates in a timely fashion. Getting to 100 percent compliance overnight is a lofty goal, even if we don’t always make it.
Many Jack-of-all-trades IT professionals don’t recognize that some of the best ways to implement WSUS aren’t the most obvious. Some aren’t even well-publicized. Let me share a few of the more-successful tricks that will help you smooth out your update process.
Getting to 100 percent update compliance requires two basic steps: First, you have to install the update; second, you have to reboot the computer. You must accomplish both steps for the computer to be considered compliant. WSUS falls short in how it handles the reboot step.
Most of you don’t want to bother users with a post-update reboot. Kicking off a reboot during the workday irritates users and can cause lost work. That’s why there’s always the option to let users postpone the reboot. Postponing a reboot gives a user time to finish what they’re doing and shut the computer down gracefully. However, postponing the reboot can delay achieving 100 percent compliance.
Another option is to attach a deadline to each approved update. That establishes a date and time when the installation and reboot must be complete. You’ll absolutely force computers to restart after the deadline passes. The problem here is with computers that were powered down or off the network during the deadline period. Those computers will get patched and subsequently rebooted after they’re powered back on or when they reconnect to the network. That’s not a good solution.
A better way to control reboots is to remove them from WSUS altogether. Build a script that reboots every computer all at once. Schedule that script to run after users leave for the day. You can update systems whenever you want, knowing your external reboot script will finish the process.
For example, identify a window of time when you’ll restart every desktop on the network—let’s say Wednesday and Saturday mornings between 2:00 a.m. and 4:00 a.m. Socialize this “reboot window” to users, so they know to save their work. Then, build yourself a little script that reboots every desktop all at once. You can download a sample one from concentratedtech.com/download. Use Task Scheduler to run that script every week during your reboot windows.
A few Group Policy settings can help with this situation: Enable the policy setting “No auto-restart with logged on users for scheduled automatic updates installations.” This will prevent an update installation from restarting the computer.
In the policy setting “Configure Automatic Updates,” set the value to 4 and make sure the installation time occurs before your reboot window. Enabling the policy “Allow Automatic Updates Immediate Installation” also helps, as it immediately installs updates that don’t require a reboot. Last, if you want to lock these settings down even for administrators, you can enable the User Configuration policy “Remove access to use all Windows Update features.”
Reconfiguring WSUS in this way separates the reboot step from the install step and gives you much better control over reaching 100 percent compliance overnight.
IT guys constantly ask me, “Is there a way to use WSUS to patch a computer immediately?” They’re tired of waiting for WSUS time-based updates. They want immediate control over when computers get patched, especially with servers.
There is a way, although it’s not exposed within the WSUS GUI. WSUS also has scripting exposure through an API. Using that API and your favorite scripting language, you can instruct any client’s Windows Update Agent to gather and install approved updates from the WSUS server. The agent will even reboot the computer immediately if updates require a reboot for installation.
The hard part is in constructing a script that’ll accomplish the task. You’ll find two scripts at concentratedtech.com/download. The first executes on the computer needing updates. It will download approved updates, install them and reboot the computer if necessary. The second uses the nifty Microsoft tool PSExec to remotely launch the first script on multiple computers across your network.
These two scripts come in handy for patching servers. You can tell your servers to patch and reboot themselves immediately, without having to wait around for the WSUS clock-on-the-wall timer to begin.
Right where the other WSUS Group Policy settings are stored, you’ll find one named Enabling Windows Update Power Management. This will automatically wake up the system to install scheduled updates.
Many of us configure our computers to move to lower-power states when they’re not in use, such as turning off the screen or even sleeping the computer. The trouble is that a sleeping computer won’t be awake for installing updates in the middle of the night.
Enabling this setting instructs Windows Update to automatically wake sleeping computers when it’s time to update. Once complete, the computers will return to a sleep mode after two minutes.
Employees who rarely connect to the Internal LAN are another challenge. These laptops are company property, but management options are limited because they’re rarely on the network. To ensure these computers get patched, many users are forced to the Microsoft public update Web site. There, they’ll get every patch Microsoft deems appropriate.
As you can imagine, there are multiple issues with this approach. Most of us want to determine which patches are installed. We want to test and approve patches so we can weed out those we know cause problems. We also need reports on patching success, to prevent an unpatched computer from infecting our network.
One way to accomplish this (and achieve 100 percent compliance overnight) is with an Internet-facing WSUS server. This type of server can address your patch-management needs for users who are rarely in the office. Internet-facing WSUS servers typically don’t contain actual update data. Instead, they point clients to Windows Update for the update content.
This lets you control which patches you deploy while offloading the patch distribution responsibility to Microsoft servers. These servers also tend to be hardened against inappropriate users through the use of SSL certificates and a separate database server.
Achieving 100 percent compliance overnight requires quickly patching clients. It also requires quickly distributing updates throughout the WSUS hierarchy. Unfortunately, that speedy distribution of update metadata and content isn’t always possible if you’ve chained multiple WSUS servers together. The frequency of Automatic Updates detection and some latent branch office network connections are the issues here.
If you’re using Windows Server 2008 R2, you can replace your chained WSUS servers with BranchCache, a content-acceleration solution that caches documents for users in remote offices. You can also use BranchCache to accelerate update deployment.
Install BranchCache on your WSUS server. Then use Group Policy to turn it on for Windows 7 clients in your remote offices. Finally, point those remote office clients to the main office WSUS server for their updates.
Using BranchCache Distributed Cache Mode, Windows 7 computers at the remote site will share WSUS content once it’s downloaded. This speeds update distribution without saturating your network connection.
The actual caching in BranchCache is completely transparent to the client. This means acceleration will work once enabled for all content downloaded from a BranchCache-enabled server. As a result, you can get rid of your remote-site WSUS servers, and remove a step in update distribution.
This last tip might feel like cheating, but it’s an important step in getting to 100 percent compliance. Eliminating expired computers from the WSUS database removes them from your compliance counters. If a computer no longer exists, it will never report compliance and you’ll never see 100 percent.
WSUS includes a Cleanup Wizard, which you should use on a regular basis. It will remove computers no longer contacting the server, as well as eliminate unnecessary updates.
I’ve been sharing these suggestions to clients for years. All of them report significant improvements in their time to full compliance. You can get there, too. If you can’t, let me know. Share your problems at concentratedtech.com/WSUSGuarantee.
Are you a Jack-Of-All-Trades (JOAT) Windows administrator? Are you responsible for networks, servers, printers, and everything in-between? If so, you’ve surely developed some useful tips and tricks for keeping those servers running. Interested in sharing? TechNet Magazine’s Geek-of-all-Trades columnist Greg Shields is looking for a few good tips for an upcoming column, and he’s seeking your help.
Got a smart tip for managing your Windows servers? Figured out a nifty tactic for keeping desktops running? Care to share a secret trick for managing your IT environment? Greg’s “Top 20 IT Tips” will appear in an upcoming TechNet Magazine issue. There, he’ll be recognizing the top 20 smartest IT JOATs in the industry alongside their game-changing tip or trick. Submit yours today! Get your name in print, extol your virtues, and remind everyone why you’re the ones that get the real work done. Send your tips to email@example.com. Every submitted tip will get a response.