|
Small offices are caught between the proverbial rock and a hard place when it comes to provisioning a reliable patching system for their internal computers. First, server software is expensive and, second, small offices have small budgets. Patching systems in such an environment often means running from workstation to workstation, displacing co-workers from those systems while the administrator updates the system. What if there were an easier, more affordable way? There is and we’ll show it to you.
In mid-2005, Microsoft released WSUS (Windows Software Update Services) to help centralize patch management in organizations of all sizes. It offers the capability to chain WSUS servers together in such a way that you can test a small group of workstations for a patch QA cycle. You may also organize computers in groups and approve patches to one group as well as decline the patch for other groups. WSUS can also deploy service packs for nearly every Microsoft Product.
While WSUS is free, there is the expense of the server hardware and the required licenses. You should be able to do everything you need for centrally managing patches in your office for between $1200 and $2000 dollars. Sorry, WSUS does actually require that it be installed on a server version of Windows (2000 or higher).
To get started, grab the documentation and WSUS download from http://www.microsoft.com/wsus. Be sure to read the documentation and keep a copy on hand for working with WSUS and diagnosing any unexpected results. Also be sure to download a copy of ClientDiag.exe while you’re there. We’ll be using it later to confirm that the settings have taken properly on the client systems. The last file to download or make sure is available is BITS2.0-KB842773-x86-enu.exe. This is the updated, WSUS compatible Background Intelligent Transfer Service, version 2.0. WSUS requires this version at least to be available.
During setup, accept the WSUS defaults and use the packaged SQL server option. You shouldn’t have a need for a full copy of SQL Server since you are in a small office with a limited number of computers to manage.
Once WSUS is installed, verify the installation is working by using a web browser from a workstation to connect to the server. The default URL is http://<your-server-name-or-ip-address>/wsusadmin. When you connect, you should see this screen by default:
Set the synchronization options and create any computer groups you need as described in the WSUS documentation. Make sure to carefully select the products for which you want patches in the synchronization options since Microsoft Office is amongst the patch targets WSUS supports. This is important because WSUS cannot get past the silly need of Office apps to have the original Office Setup files at hand when the patches are applied.
To this point, everything we’ve done has been described in countless web pages about deploying WSUS and getting your Friday nights back to yourself. However, all those web sites and documents describe how to use Group Policy Objects (GPO) to get your Active Directory clients managed in WSUS. We’re going to do it a little differently. WSUS and patching are, by themselves, inadequate reasons for building, maintaining and paying for an Active Directory implementation.
GPO’s are not rocket science. They are essentially registry files that are replicated to each Domain Controller in an Active Directory. When a user logs on to the domain, the GPO’s are applied to the client workstation by modifying the workstation registry (provided the policy applies to that user or workstation). This is great stuff because it means an administrator may publish a series of registry settings once and have them applied universally throughout the domain. Great time saver! Of course, it’s also a great way to replicate a huge mistake throughout an organization, too. There’s a flip side to everything, isn’t there?
Since a GPO is just a collection of registry values, we ought to be able to construct a reliable registry import file and call it from a batch file to get the client computers configured.
In the documentation you downloaded, a series of registry key values are described and you should use them as your guide. For my purposes, I wanted to make each computer a member of the MouseTraxHome group, have them check in at 5 AM for patches, apply them and reboot if required. Here’s how the reg file looks:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate]
"WUServer"="http://dl380"
"WUStatusServer"="http://dl380"
"TargetGroup"="MouseTraxHome"
"TargetGroupEnabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate\AU]
"AUOptions"=dword:00000004
"AutoInstallMinorUpdates"=dword:00000001
"DetectionFrequency"=dword:00000002
"DetectionFrequencyEnabled"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000000
"NoAutoUpdate"=dword:00000000
"RebootRelaunchTimeout"=dword:0000003c
"RebootRelaunchTimeoutEnabled"=dword:00000001
"RebootWarningTimeout"=dword:00000005
"RebootWarningTimeoutEnabled"=dword:00000001
"RescheduleWaitTime"=dword:00000001
"ReschedulWaitTimeEnabled"=dword:00000001
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000005
"UseWUServer"=dword:00000001
You would be well advised, too, if you add another Registry entry to the file: HKLM\\software\\policies\\microsoft\\windows\\windowsupdate""ElevateNonAdmins"=dword:00000000
This entry ensures that the Automatic Updates control panel settings will be restricted from modification and that your hosts will only look at the WSUS server when Automatic Updates run.
If you’re satisfied with the values in the above text for your purposes, you may simply copy and paste to Notepad and save the file. However, be sure to replace the WUServer, WUStatusServer and TargetGroup values with ones which are appropriate to your installation. Save the file to disk as wsus.reg.
Next, we need a simple way to import the registry settings to the local workstation, stop and restart the Windows Update service, get the client to contact the server immediately (this won’t trigger a patch download but it will cause the Automatic Updates client to be updated and should result in an upgrade of the Backgound Intelligent Transfer Service to begin). We’ll also want to run the ClientDiag tool to make sure our settings are working properly.
Here’s what the batch file should look like:
regedit -s wsus.reg
net stop "automatic updates"
BITS2.0-KB842773-x86-enu.exe
net start "automatic updates"
wuauclt /resetauthorization /detectnow
clientdiag
This batch file assumes that BITS2.0-KB842773-x86-enu.exe, wsus.reg and clientdiag.exe are available in the same directory with the batch file.
Oh!! And did I mention Automatic Updates and the Background Intelligent Transfer Service? Yes, that’s right, they need to be running. Start ignoring the paranoid guy who told you to turn these off because they cause problems/report all kinds of bad things to Microsoft/take over a system, etc. None of those assertions is true in the least…but that doesn’t seem to keep bad advice from making the rounds. So turn those services on and live a little.
Now you’re ready to test a workstation setup. Place the batch file, the reg file, clientdiag.exe and the BITS update file on a CD or share the server directory containing those files. When you get to the target workstation either, Make sure to set Automatic Updates to automatically download and install updates (this setting is not documented in the WSUS documentation and the WSUS settings will fail if you don’t do this first).
Pick whatever time you want for the settings. The key is to get the system configured for automatically downloading and installing patches.
Next, run the batch file from the CD or from the share point.
Here’s what the results ought to look like in the CMD console:
regedit -s wsusdl380.reg
net stop "automatic updates"
The Automatic Updates service is stopping.
The Automatic Updates service was stopped successfully.
BITS2.0-KB842773-x86-enu.exe
net start "automatic updates"
The Automatic Updates service is starting.
The Automatic Updates service was started successfully.
wuauclt /resetauthorization /detectnow
clientdiag
WSUS Client Diagnostics Tool Checking Machine State
Checking for admin rights to run tool . . . . . . . . . PASS
Automatic Updates Service is running. . . . . . . . . . PASS
Background Intelligent Transfer Service is running. . . PASS
Wuaueng.dll version 5.8.0.2469. . . . . . . . . . . . . PASS
This version is WSUS 2.0 Checking AU Settings
AU Option is 4: Scheduled Install . . . . . . . . . . . PASS
Option is from Policy settings Checking Proxy Configuration
Checking for winhttp local machine Proxy settings . . . PASS
Winhttp local machine access type
<Direct Connection>
Winhttp local machine Proxy. . . . . . . . . . NONE
Winhttp local machine ProxyBypass. . . . . . . NONE
Checking User IE Proxy settings . . . . . . . . . . . . PASS
User IE Proxy. . . . . . . . . . . . . . . . . NONE
User IE ProxyByPass. . . . . . . . . . . . . . NONE
User IE AutoConfig URL Proxy . . . . . . . . . NONE
User IE AutoDetect
AutoDetect not in use Checking Connection to WSUS/SUS Server
WUServer = http://dl380
WUStatusServer = http://dl380
UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
Connection to server. . . . . . . . . . . . . . . . . . PASS
SelfUpdate folder is present. . . . . . . . . . . . . . PASS
Press Enter to Complete
So far, so good!
Now, wait an hour or so to give the client time to download the new Automatic Updates client from the WSUS server and then, using a web browser, go to the WSUS Administrator’s web page on the WSUS server. Once there, click the Computers graphic in the upper right of the page.
You should see the newly configured client computer in WSUS with data similar to the following:
Notice that in the details, the client has requested the group “MouseTraxHome”. Click “Move the selected computer” from the left side of the page and select the group you want to move the client to.
Click OK.
This is all good news!! This means the client computers are successfully communicating with the WSUS server and will be ready to take whatever patches you marked as “Install” for that computer group!
Over the next day or two, monitor the activity of WSUS through the Administrator’s web page. This page can tell you whether new patches are available, if client’s had problems applying a patch.
In the test case I’ve used for this article, the client is a couple months behind on it’s patches (kinda frightenting when you think about it):
Tomorrow, though, this system should be up to date and the reports will show no computers needing updates.
At this point, the installation and configuration are complete! You now have a monthly task to do in one place in your small office to make sure patches are available for your clients and monitor the condition of those client systems. You may even take a workstation or two and set them in their own patch group for testing the patches before approving their installation to the remaining workstations in the office. And you got all this automated patch management without spending next year’s raise while simultaneously improving the reliability and security of your small office!
|
