WSUS 3.0 SP1 BUG - Computers with same configuration are overridden !

I am facing a bug while updating my system. I have a number of common systems on the network. Each of the client system on the network has a different SusClientID. Which is used by server to identify the clients. Now this system simply override each other in WSUS so that there is only a single pc is seen in console. But due to some issue everytime after a cookie refresh on the client system it overrides the other one. I had checked, there is only single computer in the database but the ComputerID keeps on changing when the client syncs. Now if any news changes are done like adding a hardware or software or by modifying the system name, it looks to be working. I am confused with the SusClientID. Why it is used here. If all client config is common then this must not be used. Hope you people will understand what I am trying to do here.

GUID is the main ID of a client system on your network. So when everytime the SUSID is modified there are multiple entries created. This might be some kind of additional feature of WSUS which is used to avoid duplication. I do not think it is a issue or a bug.

I am also a bit confused. I was reading for this kind of issue on WSUS and landed here. There is a question that I want to ask too. To some extent it is not fare to have a common computer name on the entire network. Common names can cause a tons of errors in DC which is not notified instantly unless you see in logs. I had seen a number of bugs on WSUS behind ISA where ample of systems are working on their own IP. If a system is restored through image on common hardware then there are chances of duplicate client name and IP on the network.

That is common with me. All of my client on the network are installed from a image restore disc. So ample of them are having common configuration. I had modified the registry and removed WSUS Guid. And then I had created the image disc of system. So after restore a new ID should be generated on its own when then system boots up. For cookie refresh run wuauclt /resetauthorisation. Buy this the client will take the new ID. Now in a common workgroup things works a bit differently. There WSUS is not installed on the server. There are very less issue seen here as all of them communicate through netbois name.

What I think that settings that you are talking about is a buggy. You had messed everything and still it is working that is your luck. Does the system are also having dns entries there. What I think is the client DNS and SusID are the only two things that are used by WSUS server to differentiate among the client systems.

It is much better if you rework on the WSUS configuration from scratch. That is the only way to get your settings back proper. The below link will provide you a bit of detailed information on the same.

Step-by-Step Guide to Getting Started with Microsoft Windows Server Update Services 3.0

I have to add a bit more here on my issues. I am explaining the same in bit detail and hope that it will guide others also. My office has quiet high amount of workstations. They might be over 100. Each of them are having a common Netbios name. Along with they all are working on a common configuration and FQDN. But all of them are have different IP address. Every thing goes well where there is no issue. Now WSUS replaes each of the system in console through the NetBios. It looks it work by creating a secure communication with a system, verifying its registry value and then performing other acctions. By running WUAUCLT.EXE /resetauthorization /detectnow WSUS server accepts the system request and then add the computer automatically in the console. So in this way it looks a unique id is generated. In registry two things SusClientId and SusClientIdValidation are unique. WSUS 3.0 looks for reliable in dealing with duplicates.

What I know that FQDN is of no use here. It cannot help you much here. Also there is no chances of having a common FQDN. Client system uses a different identifiers to communicate with the server. WSUS server removes the old record when there are duplicate FQDN.

In my ways this is getting complicated. I had used WSUS based on the above suggestions. Every client connections with a system with anonymous connection. The value mentioned does not reflect a secure connectivity. Ample of them are auto-generated guid. If this is common then the SusClientID will also give duplicate result. If you can see those duplicates then remove the duplicate value of SusClientID and SusClientIDValidation. Run wuauclt /resetauthorization /detectnow.

What I know that you will have to configure a independent WSUS server on each of your clients location. That will quiet remove the issue of common names and domains.

It's a major undertaking to have all of the existing / previously deployed systems undergo a NetBIOS name change. I am trying to keep that as the last resort. I can't get into details but it's a requirement that all of the deployed servers have the SAME NetBIOS / FQDN.

Perhaps I misused the word "secure". I was merely trying to say that the process created a relationship between the WSUS client & server which, once finalized, was bound in regard to the relationship between "SusClientId" and "SusClientIdValidation".

I believe the WSUS client is first assigned a unique "SusClientId" ... then passes that to the WSUS server ... and, once accepted, the server generates a unique "SusClientIdValidation" value ... and passes that back to the client ... as visible in the client's registry as mentioned previously.

I was hoping that there was some other registry value that I could assign at each WSUS Client, to make the client appear unique to the WSUS Server, without interfering with the FQDN.

In following the steps in Microsoft KB article 903262, I removed these two registry settings. Subsequently, I successfully regenerated them using NET STOP/START of WUAUSERV service followed by WUAUCLT /resetauthorization /detectnow:

- SusClientId
- SusClientIDValidation

http://support.microsoft.com/kb/903262

My question is this: While a new and unique SusClientId was generated each time on the WSUS Client, the SusClientIDValidation value was exactly the same. Is WSUS Server caching information about a machine thereby allowing it to resupply the same SusClientIDValidation each time? If so, and more importantly to me, what criteria is WSUS Server using to recognize a machine that previously connected?

The reason I ask is this: As an experiment, I renamed the domain of the WSUS Server as well as the domain of a WSUS Client to match. Despite doing so, when the client checked in, it updated the previous entry for that very client in the WSUS console ... instead of creating a new entry.

Continuing with the experiment, I re-imaged the WSUS Client ... and, this time, only changed the Host name. I performed the aforementioned steps to introduce the client to WSUS. This worked ~ a new entry appeared in the WSUS Console for this "new" host.

I believe that this proves WSUS 3.0 considers only the Hostname in identifying a unique client system. In my prior post, only changing the domain name did not achieve these results.

In summary, WSUS 3.0 obviously requires that Hosts not share the same name, despite / regardless of existing in unique domains.

For example:
MYSERVER-A.thisdomain.local
MYSERVER-A.thatdomain.local
...will not work using WSUS 3.

Whereas:
MYSERVER-A.thisdomain.local
MYSERVER-B.thisdomain.local
... will work.

And:
MYSERVER-A.thisdomain.local
MYSERVER-B.thatdomain.local
... will work as well.

Is this a known "feature" (bug)?

Since I have (and can only have) one domain for the entire deployed solution, it appears that I will be forced to rename all of my hosts to be unique.

Just want to confirm that does it works for two system which has a qualified dns name. The same can be found under System Properties.

Hi Harry,

Thanks for the reply. I had previously checked that setting; it was not an issue.

I assure you; I tested numerous scenarios and strongly believe that WSUS 3.0 is looking only at hostname.

Thanks!

Hi,

There seems to be a way to spoof WSUS to accept computers with the same name. This isn't the most prettiest solution, but is working although :-)

REMARK: This only works when you have got different MAC addresses because the "SusClientIdValidation" regkey is generated using the MAC address.

It takes some small amount of time to manual editting the database:

1) Register the first computer to WSUS
2) Start Microsoft SQL Management Studio, and open the WSUS database (SUSDB)
3) Browse to SUSDB -> Tables -> dbo.tbComputerTarget, right-click on it and choose "Open Table"
4) In the column "FullDomainName", locate the computer, and change the hostname by clicking on it and modifying the name. Save and close the table
5) Open WSUS -> All computers and click on "Refresh"
6) Repeat the steps 1 to 5 for the other computers one by one.

Ok, please ignore the solution above.

When the computers are reporting again, the databse value is overwritten, which results in loosing computers within WSUS.

I struck a similar issue at my last job. We used ghost to image machines.

It turned out that the last version of wsus (not current, no idea if current has same settings) was detecting the pc's sid

We ended up running newsid across all our desktops and then they started behaving in wsus

Natalie