RESOLUTION
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:
2002/05/02 17:38:42 22:38:42 Success IUENGINE Querying Software Update Catalog from http://servername/auotupdate/getmanifest.asp
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:
326693
How to Force Automatic Updates 2.2 to Perform a Detection Cycle
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:
- Click Start, click Run, type gpedit.msc, and then click OK.
- Under Computer Configuration, click Administrative Templates.
- On the Action menu, click Add/Remove Templates.
- Click Add.
- Click the Wuau.adm file in the %SystemRoot%\Inf folder, and then click Open.
- Verify that the Wuau.adm file is listed in the Add/Remove Templates dialog box, and then click Close.
- In Group Policy Editor, expand Computer Configuration, Administrative Templates, Windows Components, and then Windows Update.
- Configure the two policy settings as appropriate, and then
quit Group Policy Editor.
- 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:
321709 HOW TO: Use the Group Policy Results Tool in Windows 2000
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:
259398 SceCli Event ID 1001 and UserEnv Event ID 1000 When Dfs Client Is Disabled
For Microsoft Windows XP-based clients:
314494 Group Policies Are Not Applied The Way You Expect; "Event ID 1058" and "Event ID 1030" Errors in the Application Log