Home
.. About WSUS Wiki

WSUS
.. WSUS FAQ
.. WSUS on SBS
.. WSUS Troubleshooting
.. WSUS News Groups
.. Known WSUS Issues
.. WSUS Links
.. WSUS Wish List

WSUS Documents
.. WSUS Deployment Guide
.. WSUS Installation Guide
.. WSUS Release Notes
.. WSUS Best Practice

SUS
.. SUS FAQ
.. What Is SUS
.. SUS Troubleshooting
.. SUS Links
.. SUS Known Issues
.. SUS FAQ
.. What Is SUS
.. SUS Troubleshooting
.. SUS Links
.. SUS Known Issues

Issue 1: Installing IIS Lockdown

If you run WUS B2 on a Windows 2000 server, you should install the latest versions of the IIS Lockdown tool (download from the  IIS Lockdown Tool page on Microsoft TechNet) and the URL Scanner from the Microsoft Download Site. Install these tools and keep your IIS servers secure. The IIS Lockdown Wizard works by turning off vulnerable features of IIS, thereby reducing the security risk exposure. The URL Scanner stops potentially dangerous URLs to be dropped, thus protecting your IIS server.

Note: WUS B2 setup does not install these features. You have to install them manually. You do not need to install IIS Lockdown on computers running Windows Server 2003, because the functionality is built in.

If you already have a Web site on the computer where you are installing WUS, and you attempt to create a new Web site using WUS setup, IIS stops one of the Web sites without prompting you. The Web site that IIS stops varies depending upon what operating system you are using. On Windows 2003, the WUS created Web site runs and IIS stops the Default Web site. On Windows 2000 just the opposite happens; IIS stops the WUS created Web site and the Default Web site continues to run.

To use WUS on a computer that already has a Web site, consider running the WUS Web site on a port other than port 80. You can find instructions for how to set this up in the Deploying Windows Update Services.

Issue 3: Changing WUS configuration directly in the database is not supported

WUS stores its configuration data in a database (either MSDE or SQL Server). However, changing or altering in any way the configuration data by accessing the database directly is not supported. Administrators should not attempt to modify WUS configuration in this way. The supported way to change your WUS configuration is by using WUS administration site or by calling WUS APIs.

Issue 4: Active scripting must be enabled in order to access the WUS administration site

Internet Explorer on the administrator's workstation needs to be configured to allow active scripting before it can be used to access the WUS administration site.

Issue 5: Client interaction between Windows Update web site and WUS beta

There is known condition where using both the Windows Update website and Automatic Updates pointed to a Windows Update Services beta server will lead to an error. The following steps illustrate this known problem:

1. Redirect Automatic Updates to a Windows Update Services beta server.

2. Configure Automatic Updates to notify before download.

3. Automatic Updates will automatically scan for updates offered by your Windows Update Services beta server.

4. Wait for Automatic Updates to notify you about updates which are ready to download

5. Scan for updates on the Windows Update website

6. Attempt to install the same update which was offered to Automatic Updates by your Windows Update Services beta server.

The download from the Windows Update website will fail if Automatic Updates has already synchronized information about the same update being offered from the website. If the update was already downloaded by Automatic Updates, then this will not occur. If Automatic Updates is getting updates from the Windows Update website and not from a Windows Update Services beta server, then this error will not occur.

Setup will restart IIS without notification. This could affect existing Web sites within your organization.

Issue 7: WUS is not supported on a Terminal Services server

For the Beta release, it is recommended that you do not install WUS on a server running Terminal Services.

Issue 8: Changing the WUS or SMS MPs virtual directory access to require authentication from the default anonymous access setting can effect SMS clients download capability in a mixed SMS/WUS environment

By default the content v-directory for WUS is set with anonymous access. If you change this to require authentication, then clients will get authentication errors and be denied access to download updates. This is a known issue where winhttp.dll will use the wrong authentication context when implicit authentication is required, so the authentication challenge will fail. To resolve this issue ensure the WUS server and SMS MPS are set up with anonymous access to IIS virtual directories.

Issue 9: IWAM account use for a Windows 2000 Domain Controller (DC)

If you are running WUS from a Windows 2000 Domain Controller (DC) with SP4 then you need to ensure that the IWAM_<Machine name> account is added to the Domain Administrators account. The IWAM account contains the ASPNET account used to launch the WUS service.

To work around the problem, manually assign Impersonate a client after authentication to the IWAM account. To do so, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Domain Controller Security Policy.

2. Click Security Settings.

3. Click Local Policies, and then click User Rights Assignment.

4. In the right pane, double-click Impersonate a client after authentication.

5. In the Security Policy Setting window, click Define these policy settings.

6. Click Add, and then click Browse.

7. In the Select Users or Groups window, select the IWAM account name,

8. Click Add, and then click OK.

9. Click OK, and then click OK again.

To enforce an update of computer policy, do the following

1. Type the following at the command prompt: secedit /refreshpolicy machine_policy /enforce .

2. Then at the command prompt, type iisreset.

See the following KB article for further information: http://support.microsoft.com/default.aspx?scid=kb;EN-US;824308

Issue 10: Prevent WUS to be installed under STS web site ("company web") in SBS 2003

SBS 2003 Installation comes with the Internet Web Site(Default Web Site) and Intranet Web Site (Company web). This intranet web site is an STS web site. This web site has special security settings which requires special STS privileges to access the VROOTs underneath it. When WUS is installed as one of the vroots, administration is not possible under these tight security settings.

Issue 11: Installing WUS on a Small Business Server - Integration Issues

SBS 2000

· Users can choose to install ISA proxy 2000 or not. The default is to install ISA proxy.

· Users can choose to install SQL server or not. The default is not to install SQL.

· If your server is SBS 2000, the following has to be done prior to Installing WUS

1. If you wish to use SQL, Install MDAC 2.6 SP2. Go to Data Access Downloads on the MSDN Web site to download MDAC.

2. Grant IWAM account client impersonation rights

SBS 2003 standard

· Users can install ISA proxy 2000 or 2003. The default is to install ISA proxy.

· If SBS server uses ISA proxy to access Internet, proxy settings - proxy name and port must be entered in the Settings UI.

· If ISA is using Windows Auth, proxy credentials SHOULD be entered in the form "DOMAIN\user" (The user belonging to "Internet Users" group).

SBS 2003 Enterprise

· Users can install ISA proxy 2000 or 2003. The default is to install ISA proxy.

· If SBS server uses ISA proxy to access Internet, proxy settings - proxy name and port must be entered in the Settings UI.

· If ISA is using Windows Auth, proxy credentials SHOULD be entered in the form "DOMAIN\user" (The user belonging to "Internet Users" group).

There are 3 different Websites on each SBS server:

· Default web site--WUS can only be installed in this site.

· CompanyWebsite--this is where share point is installed. WUS cannot be installed in this site.

· Sharepoint administration site--WUS cannot be installed in this site.

Client Concerns

· If the clients are part of the Workgroup, the client might fail to download the binary file. This is caused by the client not being able to resolve the WUS server. This can be rectified by doing one of the following:

· Add appropriate DNS Domain suffix of the WUS Server to the DNS search List. This can be achieved by:

1. Open DHCP Server Settings.

2. Locate "015 DHCP DNS Domain Name" - add the appropriate Domain suffix of the WUS Server.

3. Release and renew the IP address on the client.

· Use an SQL Script that would trigger a sproc to write the correct FQDN value.

· On SBS 2000, if IIS lockdown has been run with the SBS template, the WUS server is prevented from serving binaries with .exe extension down to the client. To resolve this issue, the administrator should remove the .exe entry from the urlscan.ini file and then rerun the IISLockdown tool.

Note: SBS Admins usually expose services like OWA, OMA to internet (vroots of which are installed under the Default web site). If the Default web site is granted access to the Internet, WUS vroots may also get exposed.

Working Scenarios:

SBS 2000 (RED)

· Configuration: SBS 2000 SP4 + SQL SP3

· Configured Settings: ISA 2000 Proxy Server using Windows Auth

Working Scenario:

1. If your server is SBS 2000, the following has to be done prior to Installing WUS

· If you wish to use SQL, Install MDAC 2.6 SP2. Go to Data Access Downloads on the MSDN Web site to download MDAC.

· Grant IWAM account client impersonation rights.

2. Install WUS on the Default Web Site - can use either SQL or MSDE.

3. Configure proxy settings. If ISA is using Windows Auth, proxy credentials SHOULD be entered in the form "DOMAIN\user" (The user belonging to "Internet Users" group).

4. Create subscription, synchronize, approve and configure clients to get updates from the server.

SBS 2003 (Standard Edition)

· Configuration: SBS 2003 (Std Edition) [Standard Edition does not bundle SQL or ISA proxy].

· Configured Settings: Firewall Settings using RRAS

<="" body="">

Working Scenario:

1. Install WUS on default web site (port 80) - can opt to use either WMSDE or SQL.

2. If proxy is not used, proxy settings in the UI need not be configured.

3. If proxy is used (admin bought and installed ISA proxy), configure settings. If ISA is using Windows Auth, proxy credentials SHOULD be entered in the form "DOMAIN\user" (The user belonging to "Internet Users" group).

4. Sync, Approve Updates and configure clients to get updates from the server.

SBS 2003 (Premium Edition)
· Configuration: SBS 2003 (Premium Edition) [includes SQL and ISA proxy]
· Configured Settings: ISA 2000 Proxy Server using Windows Auth

Working Scenario:
1. Install WUS on default web site (port 80) - can opt to use either WMSDE or SQL.
2. If proxy is not used, proxy settings in the UI need not be configured.
3. If proxy is used (admin bought and installed ISA proxy), configure settings. If ISA is using Windows Auth, proxy credentials SHOULD be entered in the form "DOMAIN\user" (The user belonging to "Internet Users" group).
4. Sync, Approve Updates and configure clients to get updates from the server.

Issue 12: WUS cannot use the same instance of WMSDE which is used by Small Business Server (SBS) for SharePoint .

When installing WUS on a SBS server which also has SharePoint, WUS cannot use the dedicated instance of WMSDE or MSDE created by SharePoint on SBS. You must create a new WMSDE, or MSDE instance to be used by WUS server.

Issue 13: When installing WUS on SBS2003, the default website WUS vroots access settings must be modified to enable WUS clients to self update from the server.

The WUS Server installs 2 vroots – SelfUpdate and ClientWebService and some files under the home directory of the default web site (on port 80). This is to enable V4 and V5 clients to selfupdate through the default web site. By default, On SBS2003 and SBS2000, the default web site is configured to deny access to any IP or localhost other than those of the server.
This means the SelfUpdate and ClientWebService vroots are denied access and the clients will not selfupdate. To grant access to the clients to selfupdate, complete the following steps on the default web site’s SelfUpdate and ClientwebService Vroots.
· Click the vroot ->Properies->Directory Security->IP address and domain name restrictions ->Edit
· Check “Granted Access” and click Add
· Select “Group of Computers” and add the IP address subnet mask (This would allow all your clients within this IP range or subnet mask update from the server).

Issue 14: WUS cannot install on Windows 2003 server if the command “aspnet_regiis.exe -I” is run following the installation of ASP.NET through Add or Remove Programs in Control Panel.

WUS cannot install on Windows 2003 server if the command “aspnet_regiis.exe -I” is run following the installation of ASP.NET through Add or Remove Programs-Windows Components-Application Server-Subcomponents- ASP.NET (in Control Panel). This issue will only occur if the indicated command is run following the installation of the ASP.NET subcomponent.
To work around this issue, in the IIS Manager disable then re-enable the ASP.NET web service extension, and proceed with installation.
Issue 15: When moving a computer from one target group into another, it may take up to one hour for the computer to appear in the new target group as viewed from the Administrative console.
When a computer is assigned to a target group for the first time data on the computer is modified with the target group information. That data is refreshed periodically or hourly. When moving a computer to a new target group from another, it may take up to one hour before that information is refreshed on the client and displayed as changed in the WUS administrative console.