Troubleshooting client self-update issues

Troubleshooting client self-update issues

If the client self-update does not work automatically, use the following suggestions to troubleshoot the problem.

How to differentiate between the SUS client and WSUS client

Use the Automatic Updates user interface (UI) to differentiate between the SUS and WSUS clients. The following illustrations show the user interface of the SUS and WSUS clients.


Verify that the client software in your organization can self-update

Some computers might already have the WSUS client installed. Other computers might have a version of Automatic Updates that is incapable of performing self-update. For more information see Deploying Microsoft Windows Server Update Services. If the clients in your organization are capable of and require self-update, but are still not self-updating, see the next section.

Verify that the SUS clients are pointed to the WSUS server

If you have the WSUS client installed but the client computer is pointed to a SUS server, Automatic Updates falls into legacy mode and the client computer uses the SUS client user interface. In this case you need to redirect the computer away from the SUS server to get the WSUS client to function. When you point Automatic Updates away from the SUS server, it automatically comes out of legacy mode and the new client user interface appears.

If your client computers are pointed to the WSUS server and you do not see the WSUS client user interface shown above, see the next section.

Check for the selfupdate tree on the WSUS server

WSUS uses IIS to automatically update most client computers to the WSUS-compatible Automatic Updates. To accomplish this, WSUS Setup creates a virtual directory named Selfupdate, under the Web site running on port 80 of the computer where you install WSUS. This virtual directory, called the self-update tree, holds the latest WSUS client. For this reason, you must have a Web site running on port 80, even if you put the WSUS Web site on a custom port. The Web site on port 80 does not have to be dedicated to WSUS. In fact, WSUS only uses the site on port 80 to host the self-update tree.

To ensure that the self-update tree is working properly

  1. Confirm that there is a Web site set up on port 80 of the WSUS server.
  2. cscript WSUSInstallationDrive:\program files\microsoft windows server update services\setup\InstallSelfupdateOnPort80.vbs

  3. If you have WSUS client self-update running on port 80 of the WSUS server, see the next section.

Check IIS logs on the WSUS Server

Check the IIS logs on the WSUS server. IIS logs are typically located in %windir%\system32\LogFiles\W3SVC1 for the default Web site. If you copied the Wutrack.bin file to the \InetPub\wwwroot folder on the WSUS server when you set up client self-update, you can open the IIS logs and search for Wutrack.bin to attempt to locate error messages about why self-update is failing. Typical errors might be 404 (file not found) 401/403 (authentication/access), and 500 (Internal server error). Use IIS Help to troubleshoot any problems found in the IIS logs.

If you have installed Windows® SharePoint® Services on the default Web site in IIS, configure it to not interfere with Self-update

If you install Microsoft Windows Sharepoint Services on the same server that is running WSUS, you might get the following issues:

If client computers are not running the WSUS-compatible version of Automatic Updates, they will not be able to receive updates through WSUS.

To resolve this issue

  1. Grant Anonymous access (Anonymous Auth) to the Default Web site, ClientWebService and Selfupdate v-roots in IIS.
    1. Open the Windows Sharepoint Services Central Administration Site (click Start, point to Administrative Tools, and then click Sharepoint Central Administration).
    2. Click Virtual Server Configuration, and then click Configure Virtual Server Settings.
    3. Click Default Web Site.
    4. Click Virtual Server Management, and then click Define managed paths.
    5. In the Add a new pathbox, set the type to excluded path. Under Path, type the following:
      "/iuident.cab"
      "/wutrack.bin"
      "/clientwebservice"
      "/Selfupdate"

Check network connectivity on the WSUS client computer

Check network connectivity on the WSUS client computer. Use Internet Explorer to determine if self-update files on the WSUS server are accessible to the client computer. If you perform the following procedure and are prompted to download or open the files, you have verified network connectivity. It is not necessary to save or open the files. You cannot self-update Automatic Updates this way. If you do not have access to these files, troubleshoot network connectivity between the WSUS client computer and the WSUS server.

To check network connectivity on the WSUS client computer

  1. Click Start, and then click Run.
  2. In the Open box, type iexplore and then press ENTER
  3. http://WSUSServerName/iuident.cab

    where WSUS server name is the name of your WSUS server. Ensure that you are prompted to download or open Iuident.cab. This verifies network connectivity from the WSUS client and the availability of the Iuident.cab file on the WSUS server.

  4. http://WSUSServerName/selfupdate/AU/x86/osvariable/languagevariable/wuaucomp.cab

    where WSUSServerName is the name of your WSUS server and where osvariable is a variable indicating the operating system of the client computer. The possible variables for osvariableare NetServer, W2K or XP, and where languagevariable is a variable indicating the language of the operating system of the client computer. The possible variables for oslanguage are based on the standard 2- to 4-letter language abbreviations. For example, here is a URL for a client computer running an English version of Windows XP:

    http://WSUSServerName/selfupdate/AU/x86/XP/EN/wuaucomp.cab

  5. Ensure that you are prompted to download or save Wuaucomp.cab. This verifies network connectivity from the WSUS client and the availability of the Iuident.cab file on the WSUS server. If you are prompted to save or download both of these files, see the next section.

Check logs on the SUS client computer

Check the %windir%\windows update.log on the client computer to see if there has been any activity or any attempts to contact the server. Check the %systemdrive%\program files\windowsupdate\v4\urllog.dat file on the client computer for cached server pingbacks if the client computer has not been able to communicate with the server.

These files are hidden by default. Use the following procedure to display hidden files and folders in Windows Server 2003.

To display hidden files and folders on Windows Server 2003

  1. In Control Panel, open Folder Options.
  2. On the View tab, under Hidden files and folders, click Show hidden files and folders.
  3. If you can find no problem with the logs on the WSUS client, see the next section.

Manipulate registry settings on the SUS client computer

If all else has failed, you can attempt to manually manipulate registry settings to get the client computer to self-update to the WSUS client.

To manually manipulate registry settings on the SUS client computer

  1. Click Start, and then click Run.
  2. In the Open box, type regedit and then click OK.
  3. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\

    If the WindowsUpdate key does not exist, do the following:

  4. On the menu, click Edit, point to New, and then click Key.
  5. Type WindowsUpdate as the name for the new key.
  6. If the WUServer setting does not exist, do the following:

    On the menu, click Edit, point to New, and then click String Value.

  7. Type WUServer as the setting name.
  8. If the WUStatusServer setting does not exist, do the following:

    On the menu, click Edit, point to New, and then click String Value.

  9. Type WUStatusServer as the setting name.
  10. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

    If the AU key does not exist, do the following:

    On the menu, click Edit, point to New, and then click Key.

  11. Type AU as the name for the new key.
  12. If the UseWUServer setting does not exist, do the following:

    On the menu, click Edit, point to New, and then click DWORD Value.

  13. Type UseWUServer for the setting name.
  14. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update

  15. Click Start, click Control Panel, and then double-click Automatic Updates.

  16. In the Automatic Updates dialog box, specify download and installation options, and then click OK. Make sure that Turn off Automatic Updates is not selected.
  17. Ensure that the AUState setting has a value of 2 (0x2). If it does not, modify it by double-clicking and changing the value.
  18. If the LastWaitTimeout setting exists, delete it.
  19. If the DetectionStartTime setting exists, delete it.
  20. net stop wuauserv

  21. net start wuauserv

  22. Wait approximately 6 to 10 minutes for the self-update to occur.

To force the SUS client computer to check with the WSUS server

  1. DetectionStartTime (REG_SZ) YYYY.MM.DD HH.MM.SS. The DetectionStartTime value is written in local time, but the detection actually occurs 5 minutes after the time noted.

    LastWaitTimeout (REG_SZ) YYYY.MM.DD HH.MM.SS. The LastWaitTimeout value is written in GMT or Universal Time, and represents the actual time that detection occurs.

    Although these values refer to the time that detection is going to start, the first phase of detection is the process of checking whether a self-update is necessary. Therefore, these values actually refer to when self-update from the SUS client to the WSUS client should occur.

  2. If the client software has not self-updated after ten minutes, refresh the \Auto Update registry key. If the LastWaitTimeout value has changed and is now 24 hours later than its previous value, that indicates that Automatic Updates was not able to contact the server URL that you specified in the WUServer value.

Comments

Popular posts from this blog

Exchange Server Error -1018: How Microsoft IT Recovers Damaged Exchange Databases

Server and Domain Isolation Using IPsec and Group Policy

[Solved] The Group Policy client-side extension Internet Explorer Zonemapping failed to execute