We all know that Windows updates are important for security and functionality of our Windows PCs and we all want to keep our systems updated. But at the same time, people on volume limited internet plans also blame these windows updates running in background for escalated data usages, specially if we are running many systems and want to keep all of them updated. Sometimes we think that why are we downloading the same updates for each of the PC separately? Or feel that its really hard to keep track of what’s got updated and what’s not? Windows Server Update Services (WSUS) is one of the best solution for your all such worries.
If you are running a setup of at least 50 PCs then you sure must be knowing about WSUS already and if you not or thought that its too hard to implement then its about time to take note of it. What’s next in my post is nothing special that most of smart admins might not been knowing about, but I thought to make a step by step guide over WSUS from the resources already available over internet.
Offline updates solution: Autopatcher:
When you talk about updating few PCs just built up and installed, then the best tool that strikes me is Autopatcher. This tool downloads all the patches as per your selection and stores in a folder, which will contain an executable to update any PC (XP, 2000, 2003, Vista, Windows 7) offline. Not only that before updating it also detects that what already had been updated and more of it, the tool downloads updates in incremental ways, so that every time the folder will keep on growing to catch up the new updates.
Give it a try, its a must tool for sysadmins for updating newly installed PC in most efficient and quickest way. But note that its not a Microsoft Product, though I could guarantee myself from my experience that its perfectly sane.
Why WSUS, when you have Autopatcher?
Autopatcher could be called as entry level solution and sure a great thing about preparing PCs without networks, but the problem is, its still manual work. I mean you might have flexibility to download the updates once and keep it on some Network share location, but still you need to install patches manually over PCs and manual works to keep track of what’s updated and what’s not.
WSUS is an amazing Microsoft tool to end all such worries and that’s totally free of cost, just you need a Windows 2003 Server license, that’s it. It’s a service you run inside your organization on one or more servers which you configure to serve software updates to one or more AU clients. You can configure a WSUS server to download updates either from Microsoft or from another WSUS server within your organization.
Once you approve an update for installation, WSUS downloads it from configured upstream partner, and can then issue these updates to clients that request it. You can approve any update for some, all, or none of your computers. Once an update is approved, the targeted WSUS clients download the update using the Windows AU client. WSUS also provides reports on which clients have, and have not, had which updates.
You administer WSUS from
Start –>All Programs –> Administrative Tools –> Microsoft Windows Server Update Services.
WSUS not only keep all Windows clients across the organization updated without providing internet on all of them, but also reduces the Internet Bandwidth requirements as the updates get downloaded once only, not separately for all the windows clients.
System Requirements:
Followings are the set of requirements for installing a WSUS server:
Server Hardware Requirements
WSUS requires a single server for basic operation, although you can scale your WSUS implementation to larger numbers of servers if you wish. For a basic implementation of up to 500 users, hardware requirements, per Microsoft, are:
1. 1GHz CPU
2. 1GB RAM
You also need a network card, and around free disk space (described below)
Server Software Requirements
You need the following software components:
1. A supported Windows Server operating system – Windows Server 2003 is the preferred OS, but Windows 2000 is also supported. WSUS is supported on all editions of Windows Server 2003, but there are some restrictions of you use the Web Edition (See [WUS Restritions With2k3 Web].
2. IIS – WUS is operated via IIS, so your WUS Server needs to have IIS loaded. You need at least IIS 5.0.
3. .NET Framework 1.1 SP1 – get this 7.982MB download from the Microsoft download site. The .NET Framework 1.1 SP1 is delivered as a hot fix installation file (see KB article KB867460 for details). This expands to 55.6 MB (58,335,654 bytes) on disk prior to installation. The installation of this hot fix alsos stop IIS, and requires a reboot.
4. Background Intelligent Transfer Service 2.0 (BITS 2.0 English.zip) – this is a new version of BITS, at present only available to beta testers, or those on the OEP. This is a 1.34MB download.
5. WSUS Setup (WSUSSetup.exe) – Like BITS V2, this is available only to beta testers or members of the OEP at present. This is download is over 100mb.
6. SQL Database server. For Windows Server 2003 MSDE is installed during setup. For Windows 2000 it is not and MSDE or SQL server must be installed prior WUS setup.
Client Software Requirements
There are no special requirements for WUS Clients. Supported clients include Windows 2000, Windows XP and Windows 2003 Server (including the R2 server).
Server Disk Space Requirements
WUS Server disk space requirements fall into three categories: the WUS service, WUS updates and the WUS data base.
Microsoft recommends that you must have at least 6GB free disk space to store WUS content. At present, typical usage is around 1-2GB/language, although this does depend on what updates you specify and is likely to grow over time. Typical storage with multiple Operating systems can be as large as 60 or 70Gb.
The WSUS service installs (by default) into C:\Program Files\Update Services\. This folder takes up 365MB (371MB on disk) after the initial installation.
The WSUS Database is managed by MDSE, and is installed by default into C:\WSUS\MSSQL$WSUS. This folder takes up 216 MB after the initial install, synchronize and with only 2 clients. The size of the DB grows as you add more computers, and as you manage more updates.
Checklist before WSUS Installation:
The following is a simple checklist of possible issues.
1. Do you have Minimum Free Disk Space? See the WSUS Deployment Guide for more information on free disk space requirements.
2. Is the Installation drive & system partition formatted with NTFS? WSUS requires both the WSUS Database and the WSUS content to be loaded onto NTFS volumes.
3. Do you have IIS installed? IIS is required to setup, configure and manage (and use) WSUS.
4. Do you have Microsoft Internet Explorer 6.0 Service Pack 1 installed? This is required on your WSUS server.
5. Do you have Microsoft .NET Framework 1.1 Service Pack 1 installed? This is required, and WSUS server checks for it’s presence. NB: Installing the SP requires a reboot.
6. Do you have BITS 2.0 installed? This is required.
7. Do you have Database – SQL Server 2000/WMSDE/MSDE installed? A database is required, but WSUS will install WMSDE if no database service is found on the WSUS server.
Installing WSUS with in-built Local Database (SQL/MSDE):
Installing WUS with local database is pretty straight forward where, you have 2 Scenarios as given below:
· Installing WSUS on Default Website, with port 80.
· Installing WSUS on Custom Website, with port 8530.
Installing WSUS on Default Website, with port 80: This is the simplest installation with clicking over the WSUS Installation exe and following the instruction provided by the wizard.
Installing WSUS on Custom Website, with port 8530: Installing WSUS on custom Port 8530 is little different from the normal setup. You have to manually configure the client self update feature.
But, this kind of setup has many advantages including
· You can shut down port 80 to avoid malicious programs that target port 80.
· If you already have a website on port 80 like the Antivirus Applications, this kind of setup will help the functioning of both the sites independently.
Things to consider if you plan to install on custom port
· In this case, you have to manually set up up the selfupdate virtual directory on port 80 to enable client self update.
· You can use %\program\Update Services\Setup\InstallSelfupdateOnPort80.vbs script in order to allow those clients to self-update.
· To access the WSUS admin page, you have to include the custom port with the website like http://wsusserver:8350
· This port in not configurable during WSUSsetup, but can be changed later using IISADMIN.
Installation Overview:
As discussed earlier, WSUS Server holds the WSUS Software setup with IIS installed. Installation is very simple shown in these Steps:
Install WSUS on Server
· You need to setup WUSSETUP.exe
· Follow the wizard to specify content Folder & Administration Site.
· Take a note of Content folder which is needed while setting up the back End Server.
Initial WSUS Configuration
To setup, configure and manage your WUS server, you need to gain access to the WSUS Admin site on your WSUS Server:
From here you should do the following:
1. SET Server Options
This includes:
· Schedule – when to synchronize this WSUS Server
· Products and Classifications – define which patched to download. In particular, which products to download patches for (e.g. Windows 2000, Windows XP Pro, etc) and what type of updates to download (this includes security updates, driver updates, DDKs, tools, guidance, Feature Packs etc).
· Proxy Server Settings – you can specify a specific proxy server to use for updates,along with credentials if needed.
· Update Source – where this WSUS server should get it’s updates: from Microsoft, or an upstream WSUS server
· Languages – allows you to get language specific patches. NB: By Default, WSUS RC is set to download ALL languages. This is potentially harmful to your disk subsystem.
After you complete the configuration, ensure you save your options.
2. Perform Initial Synchronization
By default, WSUS is set to be synchronized manually. Once you configure your WSUS server, you should perform an initial synchronization. Depending on how many products, classifications and languages you have selected, and the speed of your internet connection, this could take a considerable amount of time.
WSUS Deployment:
There are a number of options available for deployment of WSUS like Group Policy based, Replica and Offline updates.
The following is the option that we use across our organization:
Group Policy based deployment
The following are a basic example setting that needs to apply over workstations for WSUS deployment:
The fact to notice is that this policy needs to be applied over the OU of workstations not the OU of Users and so the settings are under computer settings not the user settings
Offline Updates:
If your environment demands a network segment be disconnected from the Internet, or disconnected from the rest of your network altogether, don’t think you need to resort to the “sneaker net” method of patch distribution. Simply build a stand-alone WSUS server and import updates from removable media such as tape or DVD-ROM.
The process of exporting the updates from an Internet-connected server, and then importing them into your disconnected one is well documented in the WSUS Deployment Guide. However, here are the steps at a high level to give you an idea of the process.
1. Build your stand-alone WSUS server and configure its language and express installation options to match that of the Internet-connected WSUS server that will provide updates.
2. Copy the update content directory from the Internet-connected WSUS server to removable media. Remember that this content directory may be quite large (multi-gigabytes) so you may need to resort to tape, dual-layer DVD, or external USB hard drive.
3. Export and copy the update metadata from the Internet-connected WUS server’s database to removable media.
4. Copy the update content from removable media onto the disconnected WSUS server.
5. Import the update metadata from removable media into the disconnected WUS server’s database.
Again, please refer to the documentation for full export/import procedures, including command-line tool options and correct file system paths to back up.
Replica Mode:
Another option for advanced deployments is replica mode. Much like WSUS server chains, replica servers inherit settings and updates from their upstream master server. However, unlike server chains, replica servers are designed for environments where a central administrator controls computer groups and update approval for the entire enterprise.
The only information that isn’t synchronized between the master server and its replica servers is the content of the computer groups themselves. For instance, an administrator might create four computer groups on the master server named Branch A through Branch D. While all replica servers will receive these group names, they will not contain any members. The idea behind this design is that the WSUS administrator will create enough computer groups to cover the entire enterprise. Then, a WSUS replica server at a branch office will add the local PCs and servers to a group (say, Branch B) and the centrally approved patches for that group will be installed. It sounds complicated, but it really isn’t once you get wrap your brain around it. For more detailed information on replicas, refer to the WSUS Deployment Guide.
General Approaches to Patching with WSUS
There are a couple of approaches you can take to using WSUS:
1. Detect and deploy required patches This is a simple approach to using WSUS. The idea is you approve all patches for detection, then approve for installation any updates shown as being needed.
2. Investigate and authorize each patch individually In this approach, you examine, and hopefully test, each update for suitability in your organization as part of an overall change management process. Once you are satisfied the update is appropriate, you approve it for installation for the appropriate target groups. This patch management strategy is more time consuming, but should provide greater stability. This approach is probably more appropriate for larger organizations, or where you have a diverse network and multiple target groups.
Maintenance:
Disk Space concerns
As mentioned in requirements section, WSUS requires huge disk space for storing patches, which could be overgrown anytime, if you do not choose the products to be updated wisely.
Better to choose only those updates that are required and skip other ones even if recommended. Like if your scenario doesn’t has Windows 7 PCs, then no need of downloading updates related to that, same with 64 bit OS’s, Itanium processor based updated and device drivers.
Once the disk space is full, it stops getting more updates, but it keeps on updating workstations with existing updates, but one has to clear up the space. That’s why its recommended “Not to keep the updates storage in OS drive (c:) otherwise, it may critical for the server.”
Cleanup activities
There is already a wizard in WSUS console for cleanup, which takes care of the following:
- Unused updates and update revisions
- Computers not contacting the server
- Unneeded update files
- Expired updates
- Superseded updates
There are also ways for claiming disk space by removing some updates manually (wizard or console doesn’t remove updates from disk), but most of those procedures are messy and prone to error as of now. So, its recommended to use the wizard only and be wise while selecting the updates as once marked, the update will sure get downloaded, no matter you marked it as denied later.
WSUS Reports
For accessing reporting feature of WSUS, you are required to install report viewer from Microsoft
After the same WSUS console provides excellent options of generating reports with graphs, lists and tables in CSV, XLS or even PDF formats.
Although reporting tool of WSUS already provides plenty of options, but we are yet to find some option that could report in the way that when the update got released and when got downloaded.
Currently, we are going with manual ways by importing lists of all updates and finding the dates from the Microsoft Updates Download site itself. A tedious job for the first time, but later on you have to use excel tips like vlookup etc for avoiding the work for already reported updates and updating only those few updates that might be downloaded after the last report you prepared.
Note: As per Microsoft schedule, monthly updates arrive on second Tuesday of the month, though many updates arrive at the other days as well depending on severity.
WSUS deployment Troubleshooting
This is a topic of continuous learning with the issues and resolutions. Sharing here a few of known issues with WSUS Client configuration:
WSUS uses client-server architecture. The WSUS client, which runs on client computer, wakes up on a regular basis and queries a WSUS server to find applicable updates. The WSUS client is also designed to update itself, via what is known as self-update. The idea is that the client will look for, and download, both the OS and application updates, but also updates to the client itself. The latest version of the AU client is required for client computers to interact fully with the WSUS server.
In most cases this mechanism works ok, and clients get updated as needed and are able to check in with the WSUS server. But on some systems, client computers either do not properly check in with the WSUS server or do not self update. These problems are both fairly rare and easy to overcome.
There are a set of client configuration checks you can make on client computers that are not connecting to WSUS properly, and a set of know issues.
Client Configuration checks
1. The first thing to check is whether the client computer is using the latest Automatic Update client version.
The current version of the Windows Update Agent (the WSUS client component in AU) is determined by the version of the WUAUENG.DLL, located in %systemroot% \system32 folder. If the version of WUAUENG.DLL is 5.4.3790.1000 or greater, the WSUS client (or WUA) is installed. A version less than 5.4.3790.1000 indicates that SUS or earlier AU version 1.0 is installed.
If you have an earlier version of the AU client, it must be updated in order to work with WSUS. Computers running Windows XP with Service Pack 2 (SP2) already have the WSUS client installed.
The AU client, when contacting the WSUS server, will automatically update itself to the latest WSUS version if the self-update files are properly setup on the server. When connected to Windows Update or Microsoft Update, the AU client will also be able to self-update if it is not running the latest version. In addition, the AU client can also be updated by using a signed stand-alone, installation package that is available from Microsoft.
2. If you want AU clients to update from a WSUS server in your environment, be sure you have set anonymous access permissions on the virtual Self Update directory and that it is on a Web server running on port 80. WSUS uses IIS to automatically update client computers to the WSUS-compatible Automatic Updates software version. To do this, WSUS Setup creates a virtual directory named Self Update, under the Web site running on port 80 of the computer where you installed WSUS. This virtual directory, called the “self-update tree”, contains the WSUS-compatible Automatic Updates software. Earlier Automatic Updates client versions can only update if they find the self-update tree on a Web server running on port 80. The access permissions on this virtual directory must be set to allow anonymous access. This Automatic Updates version check is done every time the client checks-in with the server to detect new approved updates.
3. Be aware of GP replication time which may cause delay in your clients’ self-update process the first time a WSUS server and client are mapped. If clients have been mapped to WSUS servers using GP in an Active Directory environment, the timing of AU client check in with the WSUS server can be impacted by AD GP refresh timing (generally about every 90 to 120 minutes depending on environment). Clients mapped to servers in a non-Active Directory environment can be forced to check in and update right away by running wuauclt/detectnow from the command prompt.
4. Another variable that will impact client check-in behavior is the Automatic Updates detection frequency setting. By default, this value is set to the maximum of every 22 hours. This means that every 22 hours, minus a random offset, AU polls or checks in with the WSUS server for approved updates. Every time the client checks in, it also verifies it has the latest version of the client and if not, it self-updates from the server. This setting can be modified via policy or by directly editing the local policy or registry on the client. The minimum frequency is one hour. If clients have been mapped to a WSUS server via local policy or direct registry editing, without detection forced by running wuauclt/detectnow, it could be up to 22 hours until that client will self-update and appear in the WSUS Admin Console.
5. Imaged clients with a duplicate client ID will only appear once in the WSUS Admin Console. Each AU client must have a unique id which is created for each individual install. When imaging systems it is recommended always to use SysPrep. The WSUS admin console will only display one client for each unique ID. If you have multiple clients created from one image which are sharing the same ID, only one will appear in the WSUS admin console. All clients will check in and download updates, but only one will appear and display status in the WSUS admin console. In cases where clients are not checking in, and they were created from images without running SysPrep, the following steps will reset the existing duplicative client IDs.
a. Run regedit and go to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
b. Delete the PingID, SUSClientID and the AccountDomainSID values
c. Stop and start the Wuauserv Service
d. From the command prompt run: wuauclt /resetauthorization /detectnow
or-
From the command line, once you are sure the AU client is properly configured and not disabled, you could run a batch file (which might look something like this sample) and get the same results:
rem Fixes problem with client machines not showing up on the server due to imaging method
reg delete
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v
AccountDomainSid /f
reg delete
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v
PingID /f
reg delete
KLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v
SusClientId /f
cls
@echo Triggering detection after resetting WSUS client identitynet stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow
Additionally the following VBScript can be deployed via group policy to perform the above function automatically at logon. The script creates a registry key that will allow the script to check if it has been run on that client before. If it has it ends without performing any further changes.
Dim objShell, strKeyPath, strValueName,strComputer
set objShell = wscript.createObject("wscript.shell")
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"
strValueName = "SUSClientIdReset"
objRegistry.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, dwValue
IF (dwValue = "1") THEN
‘do nothing
ELSE
‘Fixes problem with client machines not showing up on the server due to imaging method
objRegistry.DeleteValue HKEY_LOCAL_MACHINE,strKeyPath,"SusClientId"
objRegistry.DeleteValue HKEY_LOCAL_MACHINE,strKeyPath,"SusClientIdValidation"
Set colServiceList = objWMIService.ExecQuery ("Select * from Win32_Service where Name = ‘wuauserv’")
For Each objService in colServiceList
If objService.State = "Running" Then
objService.StopService()
Wscript.Sleep 10000
objService.StartService()
End If
Next
objShell.Run("wuauclt /resetauthorization /detectnow ")
Wscript.Sleep 10000
objShell.Run("wuauclt /r /reportnow")
‘Set reg value for SUSClientIdReset for checking against later.
dwValue = "1"
objRegistry.SetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, dwValue
End If
Just save the above scipt as a *.vbs.
Though the above troubleshooting steps might be required in rare cases and if group policy updates are happening in proper manner then that solves the issue.
So, that’s all about starting up and working with WSUS, a must have tool to work with, for any IT Administrator or Sys Admin guy. Hoping to see some new faces on this side of table.
Nitish Kumar's Blog 