I'm not sure it's relevant in this case, as unless I'm misreading the article you have linked to, it seems to be suggesting a solution for the duplicate SusClientIDs issue which is (as I suggested above) supposed to be fixed automatically by WSUS SP3 (which I'm running).

Backup and recover physical and cloud-based servers and workstations, as well as endpoint devices that belong to remote users. Avoid downtime and data loss quickly and easily for Windows-based physical or public cloud-based workloads!

Fair enough, I'll give it a go on my WSUS test group tomorrow and see if it clears up the problem. If that works and the duplicate SusClientID issue then I've another thousand or so PCs that probably have the same problem unfortunately!

Unfortunately I can't run psexec on remote PCs at the moment. It looks like the AV might not be happy with psexec/psexesvc using remote pipes.

What I have done however is log onto a selection of PCs and check the SusClientId registry key on each. I don't see any replication in that key, even in machines with sequential numbers from the same image batch. At a guess, I'd say that the fix that Microsoft implimented in the v7.4 build of WUAgent must do regenerate the SuSClientId at first run.

We have added an automatic feature to the Windows Update Agent that is installed on WSUS client computers. This feature can help address this duplicate-SusClientID issue. The feature provides a solution that is added to the client-side Windows Update Agent starting with version 7.0.6000.374. (This version is the client version that was included with WSUS 3.0.)

This solution uses a hardware validation routine to determine whether the current client hardware has changed since the SUSClientID value was created. (This hardware includes network adapters and hard disks.)

The hardware validation routine is stored as a binary large object in the Susclientidvalidation registry key at the same location as the Susclientid registry value. If the hardware validation routine indicates that all the hardware has changed, a new SusClientID value is generated by the client.

Note The hardware validation routine requires that the client connect to a server that is running Windows Software Update Services 3.0 or a later version of WSUS and not to a server that is running Windows Software Update Services 2.0.

Run the command wuauclt /resetauthorization /detectnow on all your clients

So the situation seems to be as I suggested in my opening question, that WSUS 3 deals with the problem of duplicate SusClientID's. As we have quite a lot of clients, can you suggest what resetting the authorisation should achieve in the context of the problem?

I should have said to just find a way to run the script on all your clients to ensure the SUSId's get changed.

Put in a startup script until all your clients are in your console. Like I said there is no harm if it runs more than once.

Your issue is kind of a catch22, if your image was imaged after it connected to WSUS and.....

"This solution uses a hardware validation routine to determine whether the current client hardware has changed since the SUSClientID value was created. (This hardware includes network adapters and hard disks.) "

If your clients are all identical hardware/network adapters this would explain the need to reset the SUSclientID.

This is why it is recommended to sysprep. Again, just run the script and be done with it and I would ensure that your image doesnt have those registry keys before it is deployed.

I think the point that the MS article is trying to make is that it would check the hardware serial/MAC address etc, rather than the hardware model number. If you take out a network card and replace it with an identical network card the system should recognise that it is a different item of hardware because it has a different hardware ID. Regenerating the client ID on a change of hardware type (ie. replacing an Intel card with a freecom card) wouldn't make sense really.

I have checked machines that have been reimaged using the same image created with sysprep and they do have different SusclientID's.

Well, to address your initial problem..the only way for your clients to be appearing and disappearing is because of a duplicate sid at one point or another. Once all your client machines go thru their hardware validation routine or you run the script it should be remediated.

Sorry if I come across as a bit of an 'awkward customer' as it were. It's just that if I'm going to deploy a script to as many PCs as I'm going to have to, I want to be entirely sure of what the problem is before I do it :-) I'll let you know how I get on.

by Batuhan Cetin
In this article I will be guiding through the process of removing a failed DC metadata from Active Directory (hereafter, AD) using the ntdsutil tool in a Windows Server 2003 environment.
These steps are not necessary in a Win…

I've always wanted to allow a user to have a printer no matter where they login. The steps below will show you how to achieve just that.
In this Article I'll show how to deploy printers automatically with group policy and then using security fil…

In this video we outline the Physical Segments view of NetCrunch network monitor. By following this brief how-to video, you will be able to learn how NetCrunch visualizes your network, how granular is the information collected, as well as where to f…