-=-=-=-=-=-=-
- In the group policy object (GPO) that you created for WSUS, go to Computer Configuration/Administrative Templates/Windows Components/Windows Update and make sure you have enabled the option "Enable client-side targeting". Then create a "Target Group Name" for that WSUS server:
- In the WSUS 2.0 console, under Options / Computers, change to the other option: "Use Group Policy or registry settings on computers" to specify how to assign computers to groups. In WSUS 3.0, go to Options in the left pane, then Computers, and select "Use Group Policy or registry settings on computers":
Now it will pick up all domain computers that receive your WSUS GPO...and have the most updated version of Windows Update client installed. So if you find that there are still some workstations out there that aren't getting picked up by WSUS, and you know that they're getting the GPO, then you need to update Windows Update client (wuauclt.exe) on each of them.
The simplest way to do this is:
- Log into that machine as an admin, right click on My Computer and select Properties.
- Click on the Automatic Updates tab, then click on the text towards the bottom of the window that says Windows Update Web site. (On a Vista workstation, click Windows Update in the bottom left of the window, then click on the text that says Get updates for more products.)
- The Windows Update website pops up. The first thing it does is check to see if you have the most current version of Windows Update client installed on your PC. Allow it to run this check and accept all recommendations for updates. If it asks you if it can install something, click Install or Install Now. You may need to allow it to run an ActiveX control first.
- When you see "Welcome to Windows Update", you know that you now have the latest version of Windows Update client installed. (On Vista workstations, you will see "Microsoft Update was successfully installed.")
- The website may suggest that you upgrade Windows Update to Microsoft Update. You can do this too, as it provides the ability to update other Microsoft software such as Office, but it is an optional step in this process.
Hopefully, after all this, your WSUS server will finally see all of your workstations.
But if not, you've got one last shot. Go to the workstation that your WSUS server can't see and do the following:
- Open up a DOS window and at the prompt, type in: wuauclt.exe /detectnow This forces the WSUS server to detect this workstation right away.
- Or if that doesn't work, try wuauclt.exe /resetauthorization /detectnow According to Microsoft, this "expires" the local cookie that it gets from WSUS and then phones home.
-=-=-=-=-=-=-
Speaking of wuauclt.exe, there are apparently a number of undocumented switches that you can use with wuauclt.exe at the command line. If this interests you, you can read more about them here.
-=-=-=-=-=-=-
Finally, a word of advice about how to deal with WSUS to update your servers. Many SysAds are afraid to use WSUS on their servers because it has been known to automatically reboot servers once approved patches are applied. There are plenty of horror stories like this on the web; certainly, you don't want your production servers rebooting in the middle of a business day or during a backup, and obviously you don't want servers rebooting without prior scheduling and notice to your users.
The problem is that even with the "No auto-restart" toggle enabled in the WSUS GPO, servers can still automatically reboot under certain circumstances. This toggle will only prevent auto-restart if a user is logged in. If no user is logged in (typical for servers), then it will still auto-restart.
This is how you can use WSUS to update your servers without fear of auto-restarts:
- Make a completely separate WSUS GPO for your servers. (I actually have set up separate WSUS GPOs for "Test Servers" as well, so that Server 2003 patches can be tested on non-essential servers before patching them to production servers.)
- Start by configuring this "Servers" WSUS GPO exactly the same as your "Workstations" GPO.
- Then, under "Configure Automatic Updates", use Automatic Updating level 3 ("Auto download and notify for install") rather than 4 ("Auto download and schedule the install").
- Ensure "Target group name for this computer" is set to a distinct name, such as "Servers".
- Then ensure "Allow Automatic Updates immediate installation" is set to Disabled.
- Now set "Reschedule Automatic Updates scheduled installations" to Disabled.
- Finally, ensure "No auto-restart for scheduled Automatic Updates installations" is set to Enabled...just to be safe, even though we know it's only going to work half the time!
Apply this server-specific WSUS GPO to the OU where your servers are located. You will being to see servers appear in their own group in WSUS. (The group will be named whatever name you specified in step 4 above.) Once they are in that group, you can begin to see what updates are already installed and what updates need to be installed on each server.
When you decide to install a particular patch/update, you can simply approve it for your Servers group. WSUS will automatically upload the patch(es) to each server, but it will not install them. You will need to log in to each server and manually install the patches. That may seem like extra work, but it ensures that you control when the server reboots following applied updates.
Even though you have to manually do the actual install, WSUS is still helpful in this scenario for two reasons:
- It still automates the downloading of update files to each server from microsoft.com or WSUS -- this is still a huge time savings!
- WSUS gives you clear, comprehensive, up-to-the-minute data on what updates are installed on each server and what updates each server needs
We have operated in this framework in our organization for the past 6 months and have found it to be very successful.
1 comment:
Awesome post. THanks very helpful.
Post a Comment