More

WSUS 3.0 – Client machines replace previous clients in WSUS

By Antti Hurme 13/08/2013 3 Comments 2 Min Read

In a virtual environment (VMware, Citrix, Hyper-V ….) it’s easy to clone VM’s back and forth, and sometimes it has some unexpected results which aren’t noticed right away. One of these issues that I noticed was with WSUS and VM’s (clients) replaced each other as soon as they talked with the WSUS server. The client machine name, ip and applied updates changed according to the client in question, but the old one was nowhere to be found.

A Microsoft Knowledge Base article (link below) described this issue for pre-Windows Server 2008 / 2008 R2 / 2012 servers, but this does apply to them as well. In example when you clone a VM and remove it from the domain and re-join it, it will generate a new SID for the OS but not the Windows Update ID. In this case, the client OS will work just fine and you won’t notice this if you use an external (the normal) windows update method. If you use a internal WSUS server, then this becomes a problem :)

To solve this issue, you need to do some editing in Regedit to generate a new ID for Windows Update. This method does not require a reboot and you can verify that the client has registered properly with the WSUS server right after restarting the Windows Update service. I would recommend taking a snapshot of the VM or backing up your registry before continuing, even though I haven’t had any problems with this method.

  1. Stop the Windows Update/Automatic Updates service in elevated command prompt (net stop wuauserv)
  2. Open regedit and locate the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
  3. Delete the following entries (all might not apply)
    • PingID
    • AccountDomainSid
    • SusClientId
    • SusClientIDValidation
  4. Close regedit
  5. Start the Windows Update/Automatic Updates service in elevated command prompt (net start wuauserv)
  6. Run the following command to register the client with the wsus server again ” wuauclt.exe /resetauthorization /detectnow

Once these steps have been completed on a client machine, you can verify that the client has registered properly in the WSUS server. It might take some time for the client to show up, in my experience up to 60 seconds. It might take a while longer, though shouldn’t be that long.

Source: Microsoft KB article 903262

 

Written By

Who am I? | Linkedin

View All Articles
v
G
3 Comments
  1. Al says:

    Excellent solution; thank you.

  2. Michael Smith says:

    Thats brilliant , i wrote a script in a batch file that automates this process for please see below

    @ECHO OFF
    :choice
    set /P c=Are you sure wish to continue with WSUS fix? (Y/N)
    if /I “%c%” EQU “Y” goto :continue
    if /I “%c%” EQU “N” goto :exit
    goto :choice

    :continue
    echo “We are proceeding to resolve WSUS Update ID”

    pause

    net stop wuauserv

    REG DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /V PingID

    REG DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /V AccountDomainSid

    REG DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /V SusClientId

    REG DELETE HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /V SusClientIDValidation

    net start wuauserv

    wuauclt.exe /resetauthorization /detectnow

    exit

    :exit
    echo “You selected NO, exiting …”
    pause
    exit

  3. linhao says:

    thank you so much with useful information

Leave a Reply to Michael Smith Cancel reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

This site uses Akismet to reduce spam. Learn how your comment data is processed.