WSUS - Ghosted machines not registering? Stupid SIDS!!

albanga

Hi All,

Well as you can see from my topic i seem to be having troubles with ghosted computers not registering to our wsus server.

Just for a little background i set up wsus a year or so back for our company but my maintaining of the service has been quite second rate. Because we run terminal sevices we just apply updates to the 4 servers and we are right. However all "dumb terminals" are xp or 2000 clients and auto login into the domain so i would still like for these to recieve updates. This really hit home for us when we needed a daylight savings patch rolled out to all 250 computers in the company. As terminal services pulls the time from the local machine (region) we neeed this fixed as it would then effect all outlook calendars.

So me trying to impress said to the itc manager ill roll it out via wsus. So i downloaded tha patch and set it to roll out and thats when i realised every computer i had ghosted had an identical SID and was not recognised. Whoops! Manually installing the patch on 250 systems locally and remotely was not very much fun!

So thats where i come to you all. Now i know a lot of you are going to say why dont you just use sysprep, and yes i do agree but being a small company we have our reasons . So lets lust move on from there shall we.

After a search on the internet i found a few sources saying you can generate a new SID by making some registry changes. Just so everyone knows there was a script for this which was as follows;

@echo off
Echo Save the batch file "AU_Clean_SID.cmd". This batch file will do the following:
Echo 1. Stops the wuauserv service
Echo 2. Deletes the AccountDomainSid registry key (if it exists)
Echo 3. Deletes the PingID registry key (if it exists)
Echo 4. Deletes the SusClientId registry key (if it exists)
Echo 5. Restarts the wuauserv service
Echo 6. Resets the Authorization Cookie
Echo 7. More information on http://msmvps.com/Athif
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

So what i did was put this into a script - the pauses. And set it as the login script for the dumb terminals auto logging into the domian (we use a single account for this purpose). I let it run for a few days, as i didnt care if it deleted sids of computers already in there, i would just delete the double up in the wsus.

So here is the catch before i started the script there were 128 computers in wsus. A few days later i checked back and saw 220!! This looked promising, but then going through the list i noticed that yep they wre all just double ups. Not a single new computer had regsietred to the wsus server.

So i now find myself out of ideas and asking you all if anyone out there can give me any help into getting the remaining 120 computers that have been ghosted onto the wsus server. I am completely out of ideas????? Everywhere i looked say the script works but i can definitely tell you that if it does then it doesnt for me

Please any ideas??????

Ahriakin

http://technet.microsoft.com/en-us/sysinternals/bb897418.aspx

NewSID, much easier

sprkymrk

Try adding this line in between the referenced place of your batch file:

net start wuauserv
gpupdate /force
wuauclt /resetauthorization /detectnow

Assuming you use Group Policy to point to your WSUS server.

sprkymrk

Ahriakin wrote:

http://technet.microsoft.com/en-us/sysinternals/bb897418.aspx

NewSID, much easier

Ahriakin - NewSID does not change the unique WSUS SID, which is completely different from the computer SID. It will work for new machines to make sure they all have different SIDs (including WSUS SIDs which are generated based on the computer SID), but once you have a problem, NewSID will only change the computer SID and not the WSUS SID after the fact. Same with sysprep, thus the reason for the batch file.

albanga

Hi sprkymrk,

I tried running the batch with your line on an individual workstation but it still has not appeared in the wsus computers list.

Im still going to try running it with a login script and hopefully when i come into work in the morning it will be like santa has come and left me a new bike under the tree

I have a feeling santa is going to think i have been naughty though. Will let you know my success tomorrow.

Thanks

alharland

Run NewSID AND your batch file on each machine. Thats what I do and it works a treat.

sprkymrk

albanga, how are you pointing the computers to your WSUS server? Are you using a GPO or just manually entering the information in the registry of the computers when you clone them? If the latter, then doing a gpupdate as I suggested won't help. You could try removing one from the domain to a workgroup, then back to the domain, then run the batch file. It takes 2 reboots but I almost guarentee it will solve your issue.

Unfortunatley there may not be an easy fix, unless as alharland suggested running both NewSID and the batch file, works. Running NewSID requires admin rights too though, so not sure if it will work in your logon script. As a matter of fact, you may need admin rights to modify the registry with the batch file... Something to consider if your generic user logon is not an admin account.

Good luck!

blargoe

If you look at the file C:\Windows\WindowsUpdate.log on the client you will get all the debugging log information for the Automatic Updates client. It will tell you EXACTLY what the client is doing when you restart it and it attempts to contact the server.

Are the clients getting updates from the server at all, or is it ONLY a problem with the clients not appearing in the WSUS console?

sthomas

alharland wrote:

Run NewSID AND your batch file on each machine. Thats what I do and it works a treat.

I agree with this...I would run NewSID on the machines that you ghosted with the same SID as soon as possible. And I assume they are part of a Domain so rejoin the computes to the domain as well. I could not see how WSUS would work on a bunch of machines with the same SID. It just seems weird (wrong) to me to have a bunch of computers with the same SID.

datchcha

Doesn't Sysprep fix this issue with the SID?

snadam

datchcha wrote:

Doesn't Sysprep fix this issue with the SID?

nope, SID and WSUS SID are different

sprkymrk wrote:

Ahriakin - NewSID does not change the unique WSUS SID, which is completely different from the computer SID. It will work for new machines to make sure they all have different SIDs (including WSUS SIDs which are generated based on the computer SID), but once you have a problem, NewSID will only change the computer SID and not the WSUS SID after the fact. Same with sysprep, thus the reason for the batch file.

blargoe

I've wondered about why Microsoft wouldn't update to remove the WU sid also.

snadam

blargoe wrote:

I've wondered about why Microsoft wouldn't update to remove the WU sid also.

you mean a new version of sysprep? Yea, I dont know why either.

sprkymrk

snadam wrote:

blargoe wrote:

I've wondered about why Microsoft wouldn't update to remove the WU sid also.

you mean a new version of sysprep? Yea, I dont know why either.

I know why, but I'm not telling. :P

albanga

Wow quite a response! I will try to answer everyones questions.

Just so you know sprkymrk we are using GPO for wsus so was hoping your updated batch file would work. Unfortunately not.

What i did find out though is the batch seems to work for Windows 2000 machines? Every machine which had doubled up in the wsus console was a windows 2000 machine, however only a selected few xp machines doubled up and i have a feeling these ones were maybe not part of our ghost cycle? So it would appear that script is only working for win2000??? Seem odd? I am pretty confident that every windows 2000 computer we still have on the network is in the wsus console.

To make it a little clearer the user auto logging into the domain is named nn.desktop This user has admin privileges to each local machine so they are free to run any program they wish along with editing the registry, so that is not the problem.

Blargoe the clients that are appearing in the list are getting there updates beautifully and all controlled via GPO. The problem is the clients not appearing in the wsus console.

sthomas to answer your question yes it is wrong to have the computers with the same sid, it was an oversight on my behalf and should have been looked into earlier, as a result instead of having 5 computers with identical sids, i know have about 150.

So i am going to now run NewSID and my batch file, if no success then i will disjoin from the domain run them again and then see. IF not then...well lets cross that bridge when we get to it shall we

Thanks everyone for your input, much appreciated.

sprkymrk

Thanks for the update, it's always good when an OP responds to those trying to help. I've double checked the reg files in your batch file and it's the same ones we use for XP machines.

Have you checked the registry settings on your XP boxes to make sure they are getting the WSUS server information from your GPO? Check this key to see if your WSUS server name is there:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://servername"
"WUStatusServer"="http://servername"

Also make sure there are no typos. Before we used a GPO, we used to enter it manually before ghosting, and a tech got the forward slashes mixed up with the backslashes. He had entered:

http:\\servername

Obviously, that didn't work well.

Good luck!

albanga

Hi All,

Sorry for the lateness in getting back got sidetracked with a few other things. So here is the current update......still no luck

Im going to run through everything i have tried and please let me know if you think i have missed anything, ive been trying so many variables i think my mind is mashed. Anyways;

Whilst joint to the domain ran NewSid and wsus.bat which did not work.
Disjoined from the domain and run wsus.bat, did not work
Still disjoined ran NewSID and wsus.bat, did not work.

Checked
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://servername"
"WUStatusServer"="http://servername"

Everything is pointing correctly so it knows where the WSUS server is.

Something else no one mentioned but i thought was worth a try was ghostwalker. Pretty much just a dos version of NewSid it would appear. Still no luck.

I also looked at the C:\Windows\WindowsUpdate.log but there was a lot of text on there and i could not make it out.

So as it stands ive tried pretty much every single thing and still having no luck. Thank you so much for everyones help it has really been appreciated. I know we are coming to the end but does anyone else have any other ideas? Something drastic i could try. It feels like its getting to the point where i'll have to take ghosting out of our cycle which is not ideal in the slightest

Thanks again for everyones help, and if u need me ill be reading useless articale about how to try and fix this.

undomiel

You can try posting your WindowsUpdate.log and seeing if we can decipher it. Also have you tried the wsus diagnostics? Here's the link for the server diagnostics http://download.microsoft.com/download/7/7/4/7745a34e-f563-443b-b4f8-3a289e995255/WSUS%20Server%20Debug%20Tool.EXE which you probably don't need and the link for the client diagnostics http://download.microsoft.com/download/9/7/6/976d1084-d2fd-45a1-8c27-a467c768d8ef/WSUS%20Client%20Diagnostic%20Tool.EXE which you will definitely need. See what that reports.

albanga

Hi again all,

Sorry for my patchy responses. I have uploaded the windows update log to our website if anyone can decipher it. You can get the file at;

http://www3.dfp.biz/files/WindowsUpdate.zip

If anyone understands or can find the problem please let me know.

Thanks again everyone for all your help. Very very much appreciated

blargoe

A couple more things that I didn't mention before that occured to me when troubleshooting WSUS:

1. If Windows Installer 3.1 v2 is not installed, install it. It's supposed to automatically get pushed out with WSUS, but I've seen it not get pushed out properly.

2. Sometimes, WinHTTP proxy settings get mucked up with certain software installations (I've seen Project Server mess it up for example). You can use the WSUS Client Diagnostic ClientDiag.exe tool to check this (see undomiel's link above). If this is the problem, run proxycfg -u to reset these settings, and restart automatic updates.

3. Delete the contents of the C:\Windows\SoftwareDistribution\Download folder and restart automatic updates.

4. Does Microsoft Update work? Often, if WSUS is broken, so is Microsoft Update; and you can get more information possibly to help you debug the problem.

5. Take that WindowsUpdate.log file and get the hex codes for the error messages (the 0x800......) numbers and let google suggest an answer.

blargoe

I just opened your log file, saw your client was version 5.4.xxxxxx. What version of WSUS are you running? I'm on 3.0 and the client version for that is 7.0 I think.