WSUS + Ghosted Machines. I OFFICIALLY GIVEUP!!!

Hi again all,

Sometime ago i started a thread on here about ghosted machines not registering on our WSUS server. I think i have now officially exhausted every last possible thought and idea and still no matter what i have tried nothing will get ghosted machines to appear in WSUS.

I'll explain what i have tried one last time in the hope someone out there may have a solution;

I have built a few XP images using Norton Ghost. When i put the image onto a machine it does not appear in the WSUS server, i have attempted to fix this by trying the following;

Whilst joint to the domain ran the following script;

@echo off
Echo Save the batch file "AU_Clean_SID.cmd". This batch file will do the following:
Echo 1. Stop the wuauserv service
Echo 2. Delete the AccountDomainSid registry key (if it exists)
Echo 3. Delete the PingID registry key (if it exists)
Echo 4. Delete the SusClientId registry key (if it exists)
Echo 5. Restart the wuauserv service
Echo 6. Resets the Authorization Cookie
Pause
@echo on
net stop wuauserv
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
net start wuauserv
wuauclt /resetauthorization /detectnow
Pause

NO LUCK

Disjoined the computer from the domain and ran the script. NO LUCK

Disjoined from the domian ran NEW SID followed by script. NO LUCK
Joint to the domain ran NEW SID followed by script. NO LUCK

Ran Sysprep V2.0. NO LUCK
Ran Sysprep v2.0 followed by script. NO LUCK

Ran ghostwalker and script. NO LUCK

Built a new XP machine from scratch using the CD and watched it appear immediately into the WSUS console, just to confirm what i already knew that the problem ONLY has to do with ghosted machines.

I dont know what else to try. WSUS works and works great for the computers that are in there, but these damn ghosted machines with there identical wsus identifiers has driven me to the point of insanity. Im almost at the point of recalling every machine one by one and rebuilding them from CD!

Sorry about the rant but any help would be greatly greatly appreciated.

Im actually quite amazed a utility has not been released for this yet.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

jibbajabba

I run in all sorts of problem when a machine was joined to the domain BEFORE the SID was changed ....

blargoe

Do you still know what the name of the original machine, prior to it being imaged? Do a registry search for that name and see if there's anything lingering. I don't recall having this problem with WSUS, but one of our engineers traced a problem with some other software down to sysprep not pulling out the original computer name from one of the subkeys way down in hklm\system\CCS\Services

The machines in question actually GET updates, it's just that they don't appear in the console?

bwcarty

When I find that WSUS is completely sporked from duplicate machines, I just delete all the machines from the WSUS client and set up this computer startup script. You'll just need to configure the shared folder path on line 3.

' Folder that the script needs create/write access to, one file for  
' each SusClientId will be created.  
sFolderPath = "\\server\share"  
  
' Path and name of file where the script will log the name  
' of the computers where the SusClientId is deleted by the script.  
' This script is for administrator information only, it's content is  
' not used by the script in any way.  
' Using _ as first character in the name will cause it to be  
' listed first in Explorer  
  
sLogFilePath = sFolderPath & "\_ClientIdResetLog.txt"  
Const OpenAsASCII      =  0  
Const OverwriteIfExist = -1  
Const ForAppending = 8  
Set oShell = CreateObject("WScript.Shell")  
Set oFSO = CreateObject("Scripting.FileSystemObject")  
Set oWshNetwork = CreateObject("WScript.Network")  
sRegKey = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate"  
  
' Suppress error in case values does not exist  
  
On Error Resume Next  
  
' Check for registry marker  
  
sIDChecked = oShell.RegRead(sRegKey & "\ClientIdChecked")  
Err.Clear  
  
' To be sure the script is run only once, test on marker  
  
If sIDChecked <> "yes" Then  
SusClientId = ""   ' init value  
sSusClientId = oShell.RegRead(sRegKey & "\SusClientId")  
If sSusClientId <> "" And oFSO.FolderExists(sFolderPath) Then  
sFilePath = sFolderPath & "\" & sSusClientId & ".txt"  
If oFSO.FileExists(sFilePath) Then  
  
' Another computer is using the same SusClientId, we need to  
' clear out the registry values.  
' delete values  
  
oShell.RegDelete sRegKey & "\AccountDomainSid"  
oShell.RegDelete sRegKey & "\PingID"  
oShell.RegDelete sRegKey & "\SusClientId"  
  
' Stop and start the Automatic updates service  
  
oShell.Run "%SystemRoot%\system32\net.exe stop wuauserv", 0, True  
oShell.Run "%SystemRoot%\system32\net.exe start wuauserv", 0, True  
  
' Run wuauclt.exe with resetauthorization  
  
sCmd = "%SystemRoot%\system32\wuauclt.exe /resetauthorization /detectnow"  
  
oShell.Run sCmd, 0, True  
  
' Create entry in log file.  
' If script is not able to open the file for write access, it  
' will give up after 5 seconds (10 loops)  
  
bUpdLogFinished = False  
iLoops = 0  
On Error Resume Next  
Do  
Err.Clear  
  
' Open for appending  
  
Set fLogFile = oFSO.OpenTextFile(sLogFilePath, ForAppending, True)  
If Err.Number <> 0 Then  

' Was not able to open the log file for writing  
' Waiting 1/2 a second before trying again  

WScript.Sleep 500  
  
Else  
  
fLogFile.WriteLine Now & ", " & oWshNetwork.ComputerName  
  
fLogFile.Close  
  
bUpdLogFinished = True  
  
End If  
  
iLoops = iLoops + 1  
  
Loop Until bUpdLogFinished Or iLoops > 10  
  
Else  
  
' No other computer have reported this SusClientId, we need  
' to create a text file in the common folder using the SusClientId  
' as file name. Putting the computer name inside the file.  
  
Set f = oFSO.CreateTextFile(sFilePath, OverwriteIfExist, OpenAsASCII)  
f.WriteLine oWshNetwork.ComputerName  
f.Close  
End If  
End If  
On Error Resume Next  
  
' Create registry marker  
  
oShell.RegWrite sRegKey & "\ClientIdChecked", "yes"  
End If

Claymoore

How are the computers being assigned to WSUS? Are you using Group Policy, and are the settings correct?

Remember, Group Policy settings aren't written to the normal keys in the registry, but to the separate Policy Key. WSUS settings are in the following key and subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

I have always created my reference machines outside of my domain, so i have no experience with sysprepping and imaging a machine after it has had WSUS group policy settings applied to it. Are the PCs getting unique SusClientId values after they are sysprepped/rejoined to the domain?

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate

albanga

Thanks for all the feedback guys

Blargoe - Unfortunately i dont know the name of the original machine (wish i did). There is actually a number of different images out there (we buy refurbished machines and cannot get the same models all the time). The machines are not recieving any updates. They are part of the domain so the group policy is set for them to download the updates from the wsus server which just isn't happening. I could maybe live with them not appearing but still getting updates but unfortunately not the case.

Bwcarty - Script looks really in depth, could you tell me a little more about it? Are you saying i should delete every computer in thew WSUS console then set this script as a log-on script for all machines and what will happen? Does this work for you in the situation of ghosted machines? What would happen if i ran it on a single machine that is having the issue wihtout having to delete all the mahcines in the console. Sorry im not the best at understanding scripts.

Claymoore - Yes we are doing it via group policy and the settings are correct as it works beautifully on all other machines that are not ghosted. I will follow up on the registry keys that i have been deleting though, maybe if what you are saying is correct then by deleting the policy registry settings it may make a difference.

Unfortunately claymoore the problem lies with all the machines that are already out there which already have the problem, so i need to fix them first, once i have figured out how to do that then i'll fix the issue with the ghost images.

Thanks for the suggestions. Very very very much appreciated. Hopefully we can get through this

bwcarty

Basically, the script examines the SusClientId value of the machine and looks in the shared folder you specify on line 3 for a file name that matches that value. If the file exists, that means another system is already using that SusClientId, so the script stops/starts Automatic Updates, deletes the appropriate WSUS registry values, and issues the wuauclt /resetauthotization /detectnow command to force AU to check in with WSUS and get a new SusClientId.

After the script verifies that it has a unique SusClientId, it creates a file with the SusClientId value in the shared folder and then adds a registry value to the local machine that flags it as having been checked.

If you have two systems that you know have duplicate SusClientId's, you can run the script on those just to test it out and see if things show up correctly in WSUS afterwards.

Claymoore

You could also try the Client Diagnostic Tool from the Microsoft Windows Server Update Services Tools and Utilities website.

albanga

Hi again all,

Well after tireless attempts and every suggestion failing for me, i had all but given up my hope of ever getting ghosted machines into the WSUS console. In one last ditch effort i grabbed our companies developer and explained everything to him and left him to it, well 25 minutes later i now have a working script

What he did, was something no one had ever mentioned to me before and i had posted on thei before to about a 15 post thread of suggestions. In the end the working script is as follows, i hope this helps someone in the future so they dont go through the pain i went through.

@echo off
net stop wuauserv
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /f
ren c:\windows\SoftwareDistribution SoftwareDistribution.old
wuauclt /resetauthorization /detectnow /runhandlercomserver

All the script is doing is stoppping the windows update service. Then deleting the entire windows update registry, it then renames a folder in Windows that WSUS writes information to. Then it redetects. When doing that is rewrites a new windoes update folder with all the keys and makes a new folder.

PROBLEM SOLVED!!!

Thank You to everyone for there help and suggestions during this troubling time

blargoe

So basically, rename/delete enough stuff to fool automatic updates into thinking it had never been set up before. That works.

sprkymrk

Interesting. And I've never seen the "/runhandlercomserver" switch before.

Mmartin_47

We used Ghost at my IT certification school. Not sure on this one but as I recall, we had the same issue getting WSUS to work with images. Not sure if it was for WSUS though or for installing Exchange.

albanga

sprkymrk wrote:

Interesting. And I've never seen the "/runhandlercomserver" switch before.

Yeah either had i, i thought thw whole wuauclt only had two switches which were /reauthorization and /detectnow. It does turn out though there are a few more. I will have a chat to our developer to see what it actually does. I think he found information about it on a forum.

I added the lines to our script on Friday evening so hopefully when everyone boots up this morning, all computers will be part of the wsus console.

Chrisg_on_technet

We have had an issue where a number of PC's were joined to the domain but only the first PC appeared on WSUS. The registry fix solves it but it hadn't always been happening so I had a think about it... We recently started using WSUS and on our older images it is fine. The key seems to be how we updated the PC prior to creating an image from it. Historically, we have used AU direct to MS no problem - more recently we have used WSUS so that we get only the updates released to our machines. It seems obvious now that using WSUS to update a PC before image creation will write all the unique stuff talked about in this post to the registry of the original which is then copied to all PC's cloned. I am testing this theory at the moment by using AU to update a new build to get an image from but limit manually what is applied - a bit tedious...

Hope this is useful...

Blessings

Chris

snadam

albanga wrote: »

Built a new XP machine from scratch using the CD and watched it appear immediately into the WSUS console, just to confirm what i already knew that the problem ONLY has to do with ghosted machines.

Take that XP machine that you know works with WSUS, run sysprep and image the machine. Push it down on another PC, and join it to the domain, and retry the WSUS process again. The key phrase is that you know it works with WSUS. It could just be a bad image and instead of slamming your head against the wall, try a clean slate and see if that works.

Take the PC OFF the domain before running sysprep (or just dont join it to the domain at all), THEN sysprep and run ghost. General rule of thumb is joining the domain is the LAST step in the imaging process (e.g, bring up the machine, check drivers, functionality, blah blah blah, THEN manually join the domain afterwards). At least thats how Ive done it and I have had little to no issues.

if im repeating myself or covering steps you already took, then my bad.
good luck!