Automatic Updates 2.2 Client Does Not Detect Approved Updates from Software Update Services

Although new updates have been approved on a server that is running Software Update Services, the Automatic Updates version 2.2 client may not detect those updates.

There are several possible causes for this issue. These causes can range from the client being unable to resolve the name of the server that is running Software Update Services to the client not receiving the policy settings.

To resolve this issue, use any of the following methods.

Method 1

To determine if the client is performing detection against the server that is running Software Update Services, view the %SystemRoot%\Windows Update.log file. Look for an entry that is similar to the following:This entry shows the Automatic Updates client checking the approved updates catalog on the server that is running Software Update Services. Make sure that the detection occurred after the new updates were approved. If the detection occurred before the updates were approved, you can force the Automatic Updates client to perform detection again by following the steps that are described in Microsoft Knowledge Base Article 326693. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

Method 2

View the Windows Update.log file to look for error codes. When an error occurs, it is typically logged in hexadecimal format. If the hexadecimal error code begins with the "0x8019" prefix, you can convert the last three digits of the error code to decimal to obtain the HTTP status code that was returned to the client during the detection cycle.

For example, you can convert hexadecimal error code 0x80190194 to HTTP status code 404 ("File Not Found") by converting the last three digits of the error code (in this example, 194), to decimal to obtain HTTP status code 404.

Error code 0x80072EE7 is another common error code that is logged in the Windows Update.log file. This error code indicates a name resolution problem; the client cannot locate the Software Update Services server. In this situation, you can work around the error by using either the IP address or the full DNS name of your Software Update Services server when you configure your policy settings

Method 3

If the client was configured by manually editing the registry, use the Gpedit.msc file to configure the client. This makes sure that the registry entries are created in the correct location in the registry, and have the correct value types and values. To configure the client by using the Gpedit.msc file:

1. Click Start, click Run, type gpedit.msc, and then click OK.
2. Under Computer Configuration, click Administrative Templates.
3. On the Action menu, click Add/Remove Templates.
4. Click Add.
5. Click the Wuau.adm file in the %SystemRoot%\Inf folder, and then click Open.
6. Verify that the Wuau.adm file is listed in the Add/Remove Templates dialog box, and then click Close.
7. In Group Policy Editor, expand Computer Configuration, Administrative Templates, Windows Components, and then Windows Update.
8. Configure the two policy settings as appropriate, and then quit Group Policy Editor.
9. Restart the client computer.

Method 4

If the client was configured by using the Gpedit.msc file but still does not perform a detection cycle against the server that is running Software Update Services, use the Gpresult.exe tool from the Microsoft Windows 2000 Resource Kit to determine if the client computer is receiving the policy settings. For additional information about how to use the Gpresult.exe tool, click the article number below to view the article in the Microsoft Knowledge Base: If the policy is not being received by the client computer, use the information in the following Microsoft Knowledge Base articles to troubleshoot Group Policy.

For Microsoft Windows 2000-based clients: For Microsoft Windows XP-based clients:

The Automatic Updates 2.2 client performs a detection cycle one time every 17 to 22 hours.