|
Beginner’s Admin FAQ for Windows Software Update Services 2.0 Some information gleaned from the Microsoft.public.windows.server.update_services newsgroup, www.WSUS.info, and the WSUS mailing list hosted by www.patchmanagement.org Assembled by Rob Dunn Email:(uphold twothousand1(#) at hotmail dot com) 01/23/07
This list is by no means complete, but I was hoping to put together some handy information into a one-stop-doc. Hopefully it will benefit someone – Rob
Other information contributed from:
WSUS MVPS: Torgeir Bakken, Mohammed Athif Khaleel, and Lawrence Garvin
WSUS community: Paul Narula, Mike Davies, and Adrian Marsh.
I’m going to credit the people here rather than for each item they contributed, so as to clear up as much clutter as possible. |
This document assumes that you’ve already downloaded and installed the current release of WSUS and that it is functioning without error. Also, while there are some 3.0 tidbits here and there, most of the document is geared for WSUS 2.0.
Before beginning, please review the Microsoft FAQ: http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx
Table of Contents
Q: Where can I get the GPO template wuau.adm for Automatic Updates?
How to configure automatic updates by using Group Policy or registry settings:
Further information from Microsoft on how to configure Automatic Updates via GPO:
Specify intranet Microsoft update service location
Reschedule Automatic Updates Scheduled installations
No auto-restart for scheduled Automatic Updates installations
Automatic Updates detection frequency
Allow Automatic Updates immediate installation
Delay Restart for scheduled installations
Re-prompt for restart with scheduled installations
Allow non-administrators to receive update notifications
Do not display ‘Install Updates and Shut Down’ option in Shut Down Windows dialog box
Do not adjust default option to ‘Install Updates and Shut Down’ in Shut Down Windows dialog box
Enable recommended updates via Automatic Updates (WSUS 3.0)
Allow signed content from intranet Microsoft update service location (WSUS 3.0)
Q: What registry entries are changed when these policy settings are applied?
Q: Where are the non-GPO Automatic Updates registry keys stored?
Other Windows Update related policy settings.
Remove access to use all Windows Update features
Selfupdate and WSUSAdmin folders on WSUS IIS Server
Q: What address should I point my clients to in my GPO for Windows Updates?
Q: What is the Selfupdate tree for?
Q: Is it necessary to edit the registry on the clients? When is it necessary?
Applying a GPO in a Windows NT domain environment:
Manually configuring AU Client for WSUS in a workgroup environment:
Q: How do you push out updates to clients?
Q: Why do my computers keep rebooting even though I specified to not reboot them?
Q: Can I deploy Service Packs?
Q: How can I force my computer to download updates and install?
Q: How can I tell if my computer has a pending reboot?
Q: How do I tell a computer to detect needed updates or check in with the server?
Q: I’ve applied my GPO, but no clients are showing up in the WSUS console. What’s going on?
Not enough time has passed for the clients to check in automatically
Potential duplicate clients using the same WSUS SID
Invalid GPO settings or GPO not being applied correctly to the clients
Q: How do I control the bandwidth used by Windows Updates (BITS)
Q: Where can I find tools to report information from my WSUS database?
Q: Where can I locate diagnostic tools to troubleshoot my client and/or server configuration?
Q: Where can I download the WSUS API Samples?
Central reporting for multiple WSUS servers
Q: How can I extract updates directly from the WSUS database?
Q: Where can I find information on the WSUS (server component) API?
Q: Where can I find information on the WUA (Windows Update Agent) API?
Q: Where can I find Microsoft documentation for WSUS 2.0?
Q: My WSUS content directory is full! How can I clean up unneeded files?
Q: How do I configure the WSUS console for read-only access for reporting purposes? (WSUS 2.0)
It should either be located in your %windir%\inf folder (if you’ve updated to XP SP2 or have Windows Server 2003).
Note that the policy "Allow non-administrators to receive update notifications" is missing from the wuau.adm file that comes with WinXP SP2.
To see that policy, use the wuau.adm file that the WSUS installation places in the folder %windir%\inf\ on the WSUS server.
So, to enable this template and see all available AU settings in your AD, you will need to make sure that your DC has this copy of the template (should be 42Kb in size).
Also note that the new settings that are part of the template which comes with WSUS 3.0 will have no affect on Automatic Update 2.0 and below clients.
http://support.microsoft.com/Default.aspx?kbid=328010
Configure Automatic Updates by Using Group Policy: http://technet2.microsoft.com/WindowsServer/en/Library/51c8a814-6665-4d50-a0d8-2ae27e69ca7c1033.mspx -
Managing the WSUS Automatic Updates Client Download, Install, and Reboot Behavior with Group Policy: http://www.microsoft.com/technet/community/columns/sectip/st0506.mspx
See the above link ‘Managing the WSUS Automatic Updates Client Download, Install, and Reboot Behavior with Group Policy’ for some other examples of GPO setting configuration.
|
Specifies whether this computer will receive security updates and other important downloads through the Windows automatic updating service.
This setting lets you specify if automatic updates are enabled on this computer. If the service is enabled, you must select one of the four options in the Group Policy Setting:
2 = Notify before downloading any updates and notify again before installing them.
When Windows finds updates that apply to this computer, an icon appears in the status area with a message that updates are ready to be downloaded. Clicking the icon or message provides the option to select the specific updates to download. Windows then downloads the selected updates in the background. When the download is complete, the icon appears in the status area again, with notification that the updates are ready to be installed. Clicking the icon or message provides the option to select which updates to install.
3 = (Default setting) Download the updates automatically and notify when they are ready to be installed
Windows finds updates that apply to your computer and downloads these updates in the background (the user is not notified or interrupted during this process). When the download is complete, the icon appears in the status area, with notification that the updates are ready to be installed. Clicking the icon or message provides the option to select which updates to install.
4 = Automatically download updates and install them on the schedule specified below
Specify the schedule using the options in the Group Policy Setting. If no schedule is specified, the default schedule for all installations will be everyday at 3:00 AM. If any of the updates require a restart to complete the installation, Windows will restart the computer automatically. (If a user is logged on to the computer when Windows is ready to restart, the user will be notified and given the option to delay the restart.)
5 = Allow local administrators to select the configuration mode that Automatic Updates should notify and install updates
With this option, the local administrators will be allowed to use the Automatic Updates control panel to select a configuration option of their choice. For example they can choose their own scheduled installation time. Local administrators will not be allowed to disable Automatic Updates' configuration.
To use this setting, click Enabled, and then select one of the options (2, 3, 4 or 5). If you select 4, you can set a recurring schedule (if no schedule is specified, all installations will occur everyday at 3:00 AM).
If the status is set to Enabled, Windows recognizes when this computer is online and uses its Internet connection to search the Windows Update Web site for updates that apply to this computer.
If the status is set to Disabled, any updates that are available on the Windows Update Web site must be downloaded and installed manually by going to http://windowsupdate.microsoft.com.
If the status is set to Not Configured, use of Automatic Updates is not specified at the Group Policy level. However, an administrator can still configure Automatic Updates through Control Panel.
Supported on: Windows Server 2003, XP SP1, 2000 SP3
|
Rob’s notes:
I’ve found that most people have servers set for either option 2 or 3, to prevent accidental reboots (if they are not logged into).
If you have other administrators that maintain their servers, you may want to choose option 5 to allow them to configure the AU settings.
Client workstations probably should be configured for option 4 to automatically install. Computers will reboot if no one is logged into them. Of course, this depends on your environment and how you’ve defined your update policies.
Rob’s notes:
Currently (as of 8/25/05), the ‘Set the intranet statistics server’ has no affect (for future releases).
Rob’s notes:
Using client-side targeting is the way to go, especially for medium to larger organizations. This way, you can organize your clients in WSUS according to your AD layout. If you move a computer into a different OU, the settings will change accordingly (if you have the GPO set up to be different for different OU’s, that is!).
I recommend creating the target groups first in the WSUS administration console before enabling and configuring this setting. If you do not do this, your computers will appear in the ‘unassigned computers’ group. If you create your groups after you’ve configured the GPO, the computers should relocate into the appropriate target groups in WSUS after they’ve performed a GPO machine policy refresh.
Another thing to note is that if someone configures their computer to receive updates from the server, but perhaps the computer is not part of your OU structure where you’ve applied a GPO, it will appear in the ‘unassigned computers’ group in WSUS.
If you don’t use client-side targeting, you will have to manually create your groups in WSUS and manually move the clients to the appropriate groups.
I recommend creating at least a few groups to accommodate testing of new updates:
1. Servers/Workstations - Integrity Testing
2. Workstations – Test
3. Workstations – Production
4. Servers – Test
5. Servers – Production
Integrity testing is a term given to the process to determine if a patch will crash a computer and uninstall properly. This is not to determine if other applications are affected by the update.
We have new updates automatically deploying to our Integrity Testing group which contains ONLY computers and servers that have been set up with the idea that if the system crashes, the server or workstation affected does not impact the workday or business production.
Testing means that there is a procedure in place to test application functionality on the computers/servers where the updates have been deployed. Normally, this group is a set of computers that have copies of production applications installed on them to verify that the update did not “break” the app. The testing procedures can become quite tedious and thorough, but depend on your update procedures.
We have a group of 10 willing users that are “IT friendly” which test our updates after the initial testing is complete. They report back to us any instability and our Support Desk is aware who is in the group and when new updates will be deployed to them.
We have a few servers on different OS’ that are set up in a virtual environment with various roles (printing, DHCP, domain controller, applications, etc.).
Production is the final deployment group that will receive the updates after all testing has been completed in the prior two groups.
You should have a complete patch management process in place with instructions on what to do when there are enterprise or system problems.
Rob’s notes:
If you have your WU Agent set to refresh and detect in the morning, it might be useful to have this set for a short time period after a person may log into the PC – so they aren’t working on something important if the PC needs to be rebooted.
Rob’s notes:
This setting is important so that you don’t surprise people with a reboot during their workday!
Most network admins will configure this option to ‘Enabled’ so that it reminds the user to restart.
Note that this GPO has no affect if you set a deadline to an approved update that is installed on a computer (Deadlines force the computer to restart).
Rob’s notes:
If you have a test lab/target group set up, you might consider reducing this down to a more frequent interval (we use 1 hour, since all of our test computers are local) for only that target group. Note that you can force the client to do this by running ‘wuauclt.exe /detectnow’.
Rob’s notes:
I haven’t seen any negative effect (yet) of this setting being enabled. It is nice to have updates install and then have the client report back before a reboot is performed stating that the computer is completely up to date.
Some admins don’t like to install any updates without restarting, so your mileage may vary.
Rob’s notes:
This is the amount of time after an update is installed that the user will be prompted with a ‘Restart Now’ dialog. We have ours set for 10 minutes, but it doesn’t really matter, since the updates install in the background anyway (unless they are really nosey and know exactly when they are being updated!).
As far as I know, there is no way to remove this notification altogether using the GPO template or Windows Update Agent settings.
If you don’t configure the next policy setting ‘Re-prompt for restart with scheduled installations’, the user will be prompted EVERY 10 minutes (default value) after they click ‘Restart later’ at the initial restart option dialog. Most people find this extremely annoying.
Rob’s notes:
This option is very useful for those who do not want to be bothered every 10 minutes (the default) after they click ‘Restart later’ with the restart option dialog.
We have our setting configured as 240 minutes (as our installs are at 12:00), so it reminds the users to restart close to the end of the workday.
|
Specifies whether, when logged on, non-administrative users will receive update notifications based on the configuration settings for Automatic Updates. If Automatic Updates is configured, by policy or locally, to notify the user either before downloading or only before installation, these notifications will be offered to any non-administrator who logs onto the computer.
If the status is set to Enabled, Automatic Updates will include non-administrators when determining which logged-on user should receive notification.
If the status is set to Disabled or Not Configured, Automatic Updates will notify only logged-on administrators.
Note: If the "Configure Automatic Updates" policy is disabled, this policy has no effect.
Supported on: Windows Server 2003, XP SP1, 2000 SP3
|
Rob’s notes:
When enabled, this will allow non-admins to:
Keep this in mind when applying updates to Terminal/Citrix Servers.
We have our setting disabled for all workstations, as we don’t want non-admins controlling reboots of any updated computers.
Rob’s notes:
This gives the user of applying any updates while they are shutting down their PC. What might not be so nice is if the update is fairly large, and the user is in a hurry to get going.
See the next policy setting on how to configure it to be the default option for their shutdown screen.
Note that if you have scheduled your updates to install automatically (option 4 under ‘Configure Automatic Updates’), then this is a great additional setting to configure. Again, if the updates have downloaded but not yet installed on the system, this option will remind the user to do so prior to shutting down. If they do not install the updates, they will get the option during their startup process the next time they boot up (called ‘Install at startup’ – there is no policy to control this particular option).
|
This policy setting allows you to manage whether the 'Install Updates and Shut Down' option is allowed to be the default choice in the Shut Down Windows dialog.
If you enable this policy setting, the user's last shut down choice (Hibernate, Restart, etc.) is the default option in the Shut Down Windows dialog box, regardless of whether the 'Install Updates and Shut Down' option is available in the 'What do you want the computer to do?' list.
If you disable or do not configure this policy setting, the 'Install Updates and Shut Down' option will be the default option in the Shut Down Windows dialog box if updates are available for installation at the time the user selects the Shut Down option in the Start menu.
Note that this policy setting has no impact if the Computer Configuration\Administrative Templates\Windows Components\Windows Update\Do not display 'Install Updates and Shut Down' option in Shut Down Windows dialog box policy setting is enabled.
Supported on: At least Microsoft Windows XP with SP2 Shut Down option in the Start menu. |
Rob’s notes:
See my note above regarding the usefulness of this setting if you have updates automatically installing.
This is nice to set the default option to install the updates for the users so they are again reminded visually to update their system.
|
Specifies whether Automatic Updates will deliver both important as well as recommended updates from the Windows Update update service.
When this policy is enabled, Automatic Updates will install recommended updates as well as important updates from Windows Update update service.
When disabled or not configured Automatic Updates will continue to deliver important updates if it is already configured to do so. |
Rob’s notes:
No notes yet 01/23/07
|
Specifies whether the Windows Update will use the Windows Power Management features to automatically wake up the system from hibernation, if there are updates scheduled for installation.
Windows Update will only automatically wake up the system if Windows Update is configured to install updates automatically. If the system is in hibernation when the scheduled install time occurs and there are updates to be applied, then Windows Update will use the Windows Power management features to automatically wake the system up to install the updates.
Windows update will also wake the system up and install an update if an install deadline occurs.
The system will not wake unless there are updates to be installed. If the system is on battery power, when Windows Update wakes it up, it will not install updates and the system will automatically return to hibernation in 2 minutes. |
Rob’s notes:
No notes yet 01/23/07
|
Specifies whether Automatic Updates should accept updates signed by entities other than Microsoft when the update is from an intranet Microsoft update services location.
If set to Enabled, Automatic Updates will accept updates received through an intranet Microsoft update services location if they are signed by a certificate found in the "Trusted Publishers" certificate store of the local machine.
If set to Disabled, updates from an intranet Microsoft update services location must be signed by Microsoft.
Updates from a service other than an intranet Microsoft update service must always be signed by Microsoft regardless of whether this policy is Enabled or Disabled. |
Rob’s notes:
No notes yet 01/23/07
These settings manipulate the following key: HKLM\Software\Polices\Windows\WindowsUpdate
You can find these settings in the following key: HKLM\ SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
Note that a GPO will supersede these localized settings.
|
This setting allows you to remove access to Windows Update.
If you enable this setting, all Windows Update features are removed. This includes blocking access to the Windows Update Web site at http://windowsupdate.microsoft.com, from the Windows Update hyperlink on the Start menu, and also on the Tools menu in Internet Explorer. Windows automatic updating is also disabled; you will neither be notified about nor will you receive critical updates from Windows Update. This setting also prevents Device Manager from automatically installing driver updates from the Windows Update Web site.
Supported on: At least Microsoft Windows XP Professional or Windows Server 2003 family (although this works on 2000 as well – Rob) Shut Down option in the Start menu. |
Rob’s notes:
Found under ‘User Configuration’> ‘Administrative Templates’ > ‘Windows Update’
This will block all access to the Windows Update site so the only location you can pull updates from is your WSUS server.
How this relates to WSUS:
This option will cause the option ‘restart later’ to be grayed out even if the user is a local administrator on the PC. The only way to eliminate this message is either to click ‘restart now’, or to stop the ‘Automatic Updates’ service. It is an effective way to remove the ability to defer restarts to all of your users, including administrators!
You may end up annoying a LOT of people with this setting, so be careful!
NOTE: This is a user-based policy.
Point your clients to http://server/
- that should be adequate – unless during setup you've specified an alternate
port (like 8530), in which case it would be: http://server:8530/. In 99% of cases, you'd only specify http://server/.
The /wsusadmin directory is where you as
administrator go to do administrator-like things with WSUS - i.e.
approve/un-approve updates for detect or install.
The /selfupdate tree is for use only by the WU agent
on the client computers. This is what keeps your clients up to date
with the latest WU agent. If this isn't working, you may have troubles with new
clients reporting in.
Information on SelfUpdate and troubleshooting:
Only if there isn't a way to centrally manage your clients via GPO's. So, if
you don't have access to create a central policy for your client computers,
editing the registry might be the answer for you.
You’d want to use registry edits in NT4 or workgroup environments. Also, a member of http://www.WSUS.info (thank you!) site provided this information:
You don't have to use regedit (either manually or via script). You can use the wuau.adm template provided for use with GPO, in NT4 System Policy Editor, SO LONG AS you resave the template in non-unicode format.
Information about saving the wuau.adm template in non-unicode format is here: http://support.microsoft.com/default.aspx?scid=kb;en-us;325909
Try to use the latest version of System Policy Editor, under XP-SP2.
All the settings are the same as for the AD GPO, and are well documented in the Microsoft whitepapers, especially "Deploying Microsoft WSUS" by Tim Elhajj and Sean Bentley.
Edit the Default Computer object, after testing the settings with specific named Computer objects in your Domain. As with all NT4 Domain System Policy, you must save the resulting file as NTConfig.pol in the netlogon share of your domain controllers (typically the PDC has the master copy), and ensure that this file is replicated to all other BDCs in the Domain.
Reboot the client to pick up the setting changes. If you have access to regedit, you can check the appropriate keys to ensure the change has taken place.
WSUS detection, client update, and any approved installs should now happen according to your specified schedule.
WSUS: Script to Manually Configure Automatic Update Client for WSUS in a workgroup environment: http://support.microsoft.com/kb/555454
Updates don't actually get pushed, per se - you select what updates you want to install to your clients (or to find out whether or not they are needed – i.e. ‘detect now’).
The clients report to the server and figure out what updates it needs, and the server stores the needed/not needed info in the database.
Then, at the pre-determined time (defined in your GPO's/registry edits) it will cause one of the following things to happen to the client computer:
Check for updates and report the needed or not needed status to the server, and notify the user that there are new updates available for download...
Check for updates, report, and download the updates and alert the user they are ready to install
Check for updates, report, download, and install the updates
Most commonly, this is because a deadline has passed for a particular update. Even if you’ve specified that updates should only download and not install automatically, the deadline will force the client to install the update as soon as it checks to detect new update status from the WSUS server.
Many people think that if they apply a deadline to an update, this means that the update will apply on that day. This is not true – without using deadlines, the time that the update will install is contingent upon the time that you’ve specified in the GPO setting ‘Configure Automatic Updates.’ So, if you’ve specified the updates to install at 12:00 via this policy setting, that’s when the computer will try to install the updates.
Also, make sure you have not enabled and applied the policy setting ‘Remove all access to Windows Update’ to your domain. This policy setting will gray out the ‘Restart later’ option when updates have applied and require a reboot.
Yes, for example, WSUS is able to provide SP4 to Win2k SP3 computers.
Service Pack 4 for Windows 2000 is categorized under "Service Packs" at the WSUS server. Verify that you have selected the category "Service Packs" under update classification.
In the WSUS admin console:
Click Options --> Synchronization Options --> Press the "Change..." button under "Update classifications". Select “Service Packs" and “Update Rollups” if not already selected. Click ‘OK’ to return to the main console window.
If it was not selected, save the settings and perform a new synchronization by clicking on ‘Synchronize now’ in the tasks pane.
Afterwards, to locate SP4 for Win2k, you can create a custom view on the ‘Updates’ screen that includes ‘Service Packs’. You can use the following search text in your filter criteria:
Service Pack 4
Try the force download and installation of approved updates from WSUS server and email results script here:
http://www.vbshf.com/vbshf/forum/forums/thread-view.asp?tid=199&start=1
You can run the following VBScript to get this information. Copy the lines of code into a text file and name it with a .vbs extension:
Set objSysInfo = CreateObject("Microsoft.Update.SystemInfo")
Wscript.Echo "OEM hardware support link: " _
& objSysInfo.OEMHardwareSupportLink
Wscript.Echo "Reboot required: " & objSysInfo.RebootRequired
From the client computer, run the command ‘wuauclt.exe /detectnow’. This will tell the client to check in for newly approved updates.
You can force a remote Windows Update Agent detection cycle by running the following VBScript (copy lines of code into a text file and name it with a .vbs extension).
sComputer = inputbox("Enter a computer name to run WUA detectnow","Invoke detectnow")
If sComputer = "" then
wscript.echo "No computer name given. Defaulting to local computer."
End If
on error goto 0
Set autoUpdateClient = CreateObject("Microsoft.Update.AutoUpdate",sComputer)
autoUpdateClient.detectnow()
wscript.echo "All done. Check the windowsupdate.log file for WUA results."
There are number of reasons for this (and not all of them are listed here). Please read through these carefully!
Make sure that you’ve allowed enough time for the clients to check into the WSUS server. I’ve seen clients check in as quickly as 10 minutes after running ‘wuauclt.exe /detectnow’, but sometimes it can be as much as a few days, depending on other factors:
· Frequency of the GPO’s being applied to the computer (wuau.adm is a machine policy template), or if the GPO is applied at all
· The time that you specified in your GPO for client check-ins under the GPO setting: ‘Automatic Updates Check-in Frequency’.
· Frequency of computer restarts (and resultant GPO refreshes)
· Frequency of computer connection to the AD (or whatever method you are using to propagate the WSUS client settings)
To force the computer to refresh the machine policy (note that this does not force a WU Agent refresh), do the following:
Windows 2000: secedit /refreshpolicy machine_policy /enforce
Windows XP/2k3: gpupdate /force
Verify that you are not using cloned images without some sort of SID generation tool (Microsoft Sysprep or Norton’s GhostWalk, for example). You may need to resolve this issue by deleting the registry keys that contain the WSUS SID information:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\AccountDomainSid
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\PingID
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\SusClientId
Stop and restart the ‘Automatic Updates’ service in the service management console.
Execute ‘wuauclt /resetauthorization /detectnow’ from the command-prompt.
You can run this in a batch script to automate the process. Copy the lines of code into a text file and name it with a .bat extension:
@echo off
Echo Save the batch file "AU_Clean_SID.cmd". This batch file will do the following:
Echo 1. Stops the wuauserv service
Echo 2. Deletes the AccountDomainSid registry key (if it exists)
Echo 3. Deletes the PingID registry key (if it exists)
Echo 4. Deletes the SusClientId registry key (if it exists)
Echo 5. Restarts the wuauserv service
Echo 6. Resets the Authorization Cookie
Echo 6. More information on http://msmvps.com/Athif
Pause
@echo on
net stop wuauserv
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
net start wuauserv
wuauclt /resetauthorization /detectnow
Pause
This is probably the #1 reason why clients are not showing up in the WSUS administration console. Check and recheck your settings and make sure that you are applying your GPO properly!
Remember that the WSUS GPO is a computer-based GPO. If you’ve applied it to an OU where only user objects are stored, you will not see any computers appear in the WSUS console.
Information on Windows 2003 Group Policies:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/featured/gp/default.mspx
Check to verify that you are receiving the WSUS policy on the client computer:
|
Windows 2000: |
GPResult.exe (http://download.microsoft.com/download/win2000platform/gpresult/1.0/NT5/EN-US/gpresult.exe) |
|
Windows XP/2K3: |
Resultant Set of Policies (RsoP) MMC snap-in or GPResult (built-in) |
WSUS and the Microsoft Updates service utilizes BITS (Background Intelligent Transfer Service), which can be throttled back to reduce bandwidth consumption. This makes a single WSUS even more robust, by effectively increasing the variety of LAN/WAN scenarios to which it can service.
Information on using a GPO to manage BITS:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bits/bits/group_policies.asp
Try starting out by configuring it to 10kbps during the day and 50kbps after-hours.
From this link:
http://www.microsoft.com/windowsserversystem/updateservices/downloads/default.mspx
You can find client and server diagnostic tools, the WSUS server software itself, RC Upgrade cleanup tool, and WSUS API samples.
The WSUS samples includes the following tools (as of 8/25/2005):
(http://download.microsoft.com/download/7/4/5/7458e392-11de-4543-936c-b5248e344487/readme.htm)
|
Sample Name |
Description |
|
ApprovedUpdatesToXML |
Creates an XML file with a list of approved updates and details of their approval including the groups that the update is approved for, and the approval action. |
|
UpdateStatusToXML |
Creates an XML file with a list of approved updates and their installed status on client computers. Each update section contains an overall summary for all computers, a summary per target group and the status of the update on each computer within each target group. |
|
ComputerStatusToXML |
Creates an XML file with a list computers on the Update Services server, and the status of updates approved for each computer. |
|
UpdateStatusToCSV |
Creates a simple CSV file with a list of approved updates and a summary of the status of the updates on each computer |
|
UpdatesToXML |
Creates an XML file with a list of updates and interesting information about each update, including ID, title, description, KB articles etc. |
|
Update Services Notifications |
A Windows Service that periodically sends email notifications to selected users about synchronized updates, and an update status summary. To install the service, run the setup and then run the Update Services Notifications shortcut from the start menu to configure the service. |
|
ADImporter |
This tool allows you to pre-populate target groups with computers from Active Directory. The sample application connects to the default Active Directory domain controller, and lists the OUs and computers in the domain. It also lists the computer groups available on the Update Services server. Using this sample, you can select computers from Active directory and "register" the selected computers with Update Services. Note that each computer registered must be configured to talk to the Update Services server independently of using this tool |
|
CleanStaleComputers |
This sample application removes computers from the Update
Services server that have not contacted the server in a specified number of
days. |
|
ComplianceReport |
Creates an HTML report that lists computers that do not have all the approved updates installed |
|
ComputersNeedingReboot |
Creates an HTML report that lists computers that have installed updates, but still require a reboot to be fully patched |
|
ApproveNeededUpdates (undocumented) |
This tool lists all needed updates for clients (reporting to the WSUS server from where the tool is executed from) which have been set to an approval of ‘detect only’. You are given a choice of approving all updates to ‘install’ status. This will result in all previous approval settings for the affected updates to be removed. |
|
ListApprovedUpdates (undocumented) |
Creates a text report that lists all approved updates since the specified date (accessible via a drop-down calendar object). Along with the update title, the release date of the update, the applicable Operating Systems, and the date when the updates were approved are also listed. |
|
wsusmigrate
|
The WSUS Migration Tools can assist in migrating settings from one WSUS server to another. The tools can backup and restore the following settings: Configuration – export and import all WSUS options. Computers – this refers to the machines that exist in the
database of the server that you are backing up.
|
WSUS Reporting Rollup Sample Tool
This tool uses the WSUS application programming interface (API) to demonstrate centralized monitoring and reporting for WSUS. It creates a single report of update and computer status from the WSUS servers into your WSUS environment. The sample package also contains sample source files to customize or extend the tool functionality of the tool to meet specific needs. The WSUS Reporting Rollup Sample Tool and files are provided AS IS. No product support is availabe for this tool or sample files. For more information read the readme file.
Also located at: http://www.microsoft.com/windowsserversystem/updateservices/downloads/default.mspx
You can use the WSUS Extract HTA tool developed by Rob Dunn here: http://www.wsus.info/forums/index.php?showtopic=6685
Alternatively, you can use this batch script found here: http://msmvps.com/blogs/athif/archive/2006/05/09/94107.aspx
A MSDN portal has been set up here that goes into full detail of the information regarding developer resources for the WSUS development resources.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wus/wus/portal.asp
Also review the API samples listed above under ‘Tools and related resources’.
A MSDN portal has been set up here that goes into full detail of the information regarding developer resources for the WSUS development resources.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wua_sdk/wua/portal_client.asp
You can find it here:
http://www.microsoft.com/windowsserversystem/updateservices/downloads/WSUS.mspx
But for brevity’s sake, the main links are here:
The server diagnostic tool (also called the “WSUS debug tool”) is available from here: http://www.microsoft.com/windowsserversystem/updateservices/downloads/default.mspx
This tool helps administrators gather Update Services Server debug logs and configuration information for further troubleshooting. The tool has the below command line parameters (from the readme): OutputCab: optional parameter to create a cab of the tool output in the specified file. Tool: mandatory parameter specifying the tool to run. this parameter has the below options· ResetAnchors: Force a full sync in the next subscription run.
· PurgeUnneededFiles: Delete all files not needed on the WSUS server.
· SetForegroundDownload: Enable foreground content download in WSUS server. This can be used for proxies that don't support range requests.
· ResetForegroundDownload: Reset foreground content download in WSUS server.
· GetBitsStatus: Get the status of BITS jobs. This tool requires BitsAdmin.exe to be in PATH.
· GetConfiguration: Get the WSUS server configuration Information.
· GetLogs: Get the WSUS Server Installation/Debug Logs.
Examples · Gather Server Logs: WsusDebugTool.exe /Tool:GetLogs /OutputCab:c:\ServerLogs.cab
· Get help on a tool: WsusDebugTool.exe /Tool:GetConfiguration /?
· Purge unneeded content: WsusDebugTool.exe /Tool:PurgeUnnneededFiles
See this question about why you may have so much data in your content directory (Re: SUS only took up xGb amount of space…why does my WSUS content directory have 18Gb of data in it?). You may be downloading updates that you will never need to deploy.
Use the server diagnostic tool that you downloaded in the previous step(!) and run it with the following command-line switch:
Wsusdebugtool /Tool:PurgeUnneededFiles
NOTE IF YOU ARE USING REPLICA SERVER GROUPS: Be ESPECIALLY careful about the process you engage when purging content in replica server groups. It's critical that the downstream server has fully synchronized and downloaded all content from the master server -and- that the master server is not permitted to synchronize with microsoft.com during the period of time you intend to purge content stores.The content stores in a replica server group need to be purged at the same time on all replica servers, or else you will encounter issues with your content folder not being correct on your replica servers [sic]. Specifically - if the master server syncs with microsoft, gets an update 'expired', but the downstream replica servers have not downloaded the content for that (now) expired update, the replica servers will crap out trying to download content that is now expired. A similar problem happens if you purge the content from the master server before the replica server(s) have finished downloading the content. When attempting to download content, the replicas will throw '404' exceptions trying to get non-existent content.I would suggest this procedure (after thinking about this issue for several weeks): 1. Set the master server to manual synchronization.
2. Synchronize the master server with microsoft.com.
3. When the master server has finished synchronizing, run 'removeunneededrevisions' (if desired), and then mark updates to be purged as "Declined".
4. At each replica server, set the replica server to manual synchronization, then synchronize with the master server.
5. When the replica server has finished synchronizing (which will include the updates now marked as "Declined"), as well as synchronizing for revisions to be removed, and have downloaded any needed content, then run the PurgeUnneededFiles on the replica server. (You cannot run 'removeunneededrevisions' on the replica servers, as the metadata on a replica server cannot be "managed".)
6. After all replica servers have been synchronized, fully downloaded, and purged, then you can run PurgeUnneededFiles on the master server.
7. Reset the master server to automatic synchronization. (You might also want to run a manual synchronization if you missed a scheduled synchronization during this purge process.)
8. Reset the replica servers to automatic synchronization.
I believe this procedure will avoid any risks that would otherwise be encountered when purging content from a replica server group. -Lawrence Garvin WSUS MVP
This is not Microsoft recommended, but it can be done.
This will result in the following:
You can set up a ‘read-only’ group so that certain members of management, etc. can view the reports and have no permission to edit any settings. This is accomplished by creating a couple copies of the main aspx files and adding some permissions to the subfolders of the WSUS administration site.
NOTE: Step 11 involves editing a file that will reduce functionality slightly by removing the ability to edit an update approval settings via the WSUS reporting mechanism. This can still be accomplished through the main update window via the WSUS console.
· Help.aspx
· utcxpost.aspx
· Details.aspx
i. Details.aspx
Rename the copies to:
.\administration\RO-default.aspx:
Change any reference to banner.aspx to say RO-banner.aspx (should only be one)
.\administration\RO-banner.aspx:
Add the following lines right before </html> toward the end of the file.
<script language="VBSCRIPT">
TabManage.style.display = "none"
TabComputers.style.display = "none"
TabUpdates.style.display = "none"
</script>
Warning: This next file change will disable the ability to approve/decline updates from the reporting mechanism (even if you are an administrator). You can still perform approval actions against the updates if you go through the Updates interface as Administrator.
.\administration\reporting\currentstatus\approvalsummary\detaulsdialog.aspx
Add ‘//’ to line 39, so it looks like this (this remarks out the function to create the approval links in the details window for the update if it is clicked on):
//TCDeploymentTableClick(null, null, TCLastSelectedRow);
Have one of your new WSUS read-only users browse to http://server/wsusadmin/ro-default.asp. The ‘WSUS read-only’ group should be able to view the welcome screen, reports and computers icon. They should not have the ability to change or decline any approvals.
There isn’t a current interface for WSUS (you have to develop your tools in .NET for WSUS), but there is for the Windows Update Agent.
Here are two good resources from Microsoft:
http://www.microsoft.com/technet/scriptcenter/scripts/sus/client/default.mspx
http://www.microsoft.com/technet/community/columns/scripts/sg0705.mspx#EMAA
A number of factors can determine exactly how much data your WSUS content folder is holding.
So, while SUS didn't store as much content, WSUS has a bit more flexibility in what it is archiving – verify your configuration by checking the WSUS Administration options under ‘Synchronize’. Make sure you are only downloading the updates for the languages and OS types that you support.
Here is a list of Automatic Update related error codes that you can peruse that may give you an indication of what’s going on (it’s a big file, so be patient while it loads):
http://www.vbshf.com/vbshf/wsus/sus_error_code.htm
http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx - Microsoft WSUS
http://www.wsuswiki.com/WSUSFAQ - WSUS Wiki
http://www.microsoft.com/wsus - WSUS download and technical documentation
http://www.microsoft.com/windowsserversystem/updateservices/evaluation/revguide.mspx - Windows Update Services Reviewer’s Guide
http://www.wsus.info/ - WSUS information/forums/articles/tool recommendations
http://www.wsuswiki.com/ - WSUS WIKI information
http://msmvps.com/Athif/ - Mohammed Athif Khaleel’s WSUS blog (WSUS MVP)