Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've done some digging on the site and around, and I haven't seen anything that quite addresses my problem.

I have recently deployed a WSUS 3.0 SP2 hierarchy to a new data center and a pair of remote sites. Approximately half of the machines (almost entirely Win7) in one of the sites are reporting into WSUS but are showing no update status. That is the unique machine name is there, but no additional details.

Impacted machines have this error in their WindowsUpdate log:

WARNING: WU client failed Searching for update with error 0x8024400d

My research has lead me to belief the issue is related to duplicated Computer SIDS in one of the locations. It appears that a machine that was cloned was not properly sysprep'd prior to being imaged. I now have about thirty machines reporting the same SID (as determined by psGetSID).

In addition to rebuilding the clone image, I now have to resolve this issue on the thirty client machines. I am afraid they may have to be rebuilt.

  1. I am aware that MS strongly states that sysprep is to be run on non-deployed machines. Can I run sysprep on an already deployed machine, and what are the ramifications?
  2. Is there another solution the resolves this issue short of a complete rebuild?
share|improve this question
You can reset SusClientID without using sysprep as described in KB903262. However, the error does not seem to point to the duplicate ID issue (duplicate IDs usually result in computers not appearing in the list on the server, but still getting updates). Instead, it looks like these computers have problems when accessing the WSUS server; this may be caused by wrong proxy settings, or misbehaving antivirus software. – Sergey Vlasov May 14 '12 at 18:58
up vote 1 down vote accepted

There is no need to re-sysprep these machines. The WSUS support team blog has an article about this with a fairly short batch file that should solve your problem.

Hope this helps,

(Signature for disclosure purposes) David Windows Outreach Team - IT Pro

share|improve this answer
I had two problems, that combined to cause a real mess. There was another device on the network that was periodically coming online on the same IP address. Changing the base IP resolved the HTTP issues. I further tested the batch file linked in the above post on a impacted machine and it updated status to the WUS server. I blew away the existing database, started over, pushed the script out via GPO and am waiting for machines to finish reporting in. So far 75% have done so. Thank you for your assistance. – David Broaddus May 16 '12 at 14:01
Fantastic. Glad to have helped. – WinOutreach4 May 22 '12 at 19:36

You can't run Sysprep (or any SID-changing utility) on a domain-joined machine, but you should be able to remove it from the domain, run Sysprep on it and then join it back.

share|improve this answer
A while ago, I ran newSID (which no longer exists, sadly) on an XP machine joined to a domain. I tested it for a while, and everything ran fine. Anecdote =/= data, and it makes the system technically unsupported, and XP is not Win7 - but it can be done. – NathanG May 14 '12 at 19:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.