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

Hello,

I am in a configuration where, from the Wsus server point of view, all
clients have :
- The same computer name
- The same IP (Wsus behind ISA)
- The same hardware configuration

All my clients have be reseted, so their SusClientID are all
different, so they can be uniquely identified by the server.
But all these computers overrides each other in the Wsus Console (so
there is only one computer shown). I notice that each time there is a
cookie refresh on a client, it overrides an other client in the
database (the ComputerID becomes the one of the new client). There is
only one computer in the Wsus database, and it's ComputerID is always
changing, as clients are synchronizing ...

I also notice that if I add a hardware or software distinction to my
clients (changing the Computer Name ...), it works, and a new computer
entry is created.

So ? Why Microsoft use a unique SusClientID to identify the clients,
but do not use it when it shoud (when client config. is the
same ...) !

Do anybody got a trick, tip, of patch to avoid this anoying bug ...

Thanks for your help,

Guillaume.

In WSUS 2 the GUID was the main ID for the client. This resulted in multiple
entries for a PC every time the SUSID changed (which it does do from time to
time e.g. leaving the domain and re-joining). This was considered an undesirable
feature and the behavior was changed in WSUS 3 to prevent the duplicate entries.
It is not a "bug"

Just curious, how do you tell one PC from another?

I'm somewhat confused too. (pardon me, only dropped in to ask a question but
got interested)

TTBOMK WSUS, behind ISA or not, will be supplied the actual computer name of
the PC. You cannot have same named computers on an ethernet segment (and
work effectively) so these same named computers would each need to be on
their own ethernet segment. A case where this is possible may be many
standalone PC's at remote sites all called 'PC' (or pc.workgroup) but
pc.domain.lan being repeated over various sites is an invalid config and the
DC would be going nuts with errors.

I _know_ that in the case of WSUS behind ISA several PC's coming through ISA
to WSUS report their own IP. Not sure about the reverse scenario though,
several PC's behind ISA logging into WSUS on the external side.

makes me think that the PC's may have been installed from image. Standard
confusion concerning improperly imaged (as pertains to WSUS) PCs. I know the
solution is somewhere but don't have a link handy.
wuauclt /resetauthorisation /detectnow? (sorry, I don't have much to do with
'build from image')

Let my reply to your diffrents questions :-)

My clients computers have been installed from image and have all the
same harware platform (bios version ...).
I have deleted the client WSUS Guid from the registry before making
the image, so the clients will have to generate a new ID (automaticaly
done by the WU client) after the first boot. No need to have a
wuauclt /resetauthorisation, as the cookie refresh is done
automaticaly when a new ID is generated.

Clients are in a workgroup scenario (and Wsus is not installed on a
domain integrated server), with no needs for inter-clients
communications, so they all have the same Netbios name and I got no
problems with that (I know it is not in the best practicies, but it
works in my scenario).

The WSUS server is in a DMZ with ISA Server acting as a frontend
reverse proxy. I can configure the WSUS publication rule so that the
request will appear as comming from the client (on WSUS), so the
client IP will be shown in the WSUS console ... But some of my clients
are firewalled behind a NAT router, so from the WSUS server, they will
all have the same IP (the external NAT router IP).

I dont't want to clearly identify the clients from the WSUS console, I
juste want to have a global overview of the update status of all my
clients. And if, one day, I want to identify a specific client, I can
go to the WSUS database, and get the unique SusID of the client.

So ...
I think that the WSUS server considers, as there is no hardware/IP/
CptName change, that a SusID change is only an update for the
computer entry having this configuration, and not a new computer entry
to create ... That's why I got only on computer entry, with rotating
SusID.
In my opinion, there is no solution to this problem ... I just hope
that microsoft will add an option in the next release to make computer
distinction based only on SUSID and not on harware or IP ...
Today, I have found a way to bypass this problem, by generating a
random computer name during the image copy on the client. But random
does not mean unique ...

I'm sorry, but IMHO you have dug your own hole and pulled the dirt in on
top. I'm not surprised it ain't workin', I'm surprised it is as well as it
is.

If it helps at all, WSUS uses the full computer name (including the domain
suffix) if the computer knows what it is.

Do the computers not have DNS entries either?

PS : The computers on which I cannot change the name use a DNS
server ... Maybe setting a new alias or a reverse dns entry could
help ...

Yes, is seems that the client DNS Name and the SusID are the only
thing the Wsus server use to distinguish clients ...
For my laptops images, i foud a way to bypass the computer name
problem by generating a random computer name after image deployement.

But, I got a problem with some clients where I cannot change the DNS
name because it runs name dependant services on...
So is there somewhere on the registry on the clients a way to set the
computer name send to the wsus server (without changing the real
computer name)?
I sometimes see in the WindowsUpdate.log file the entry "DNS NAME
= ..." ... Is there a way to set this name, instead of letting WU
client finding it ?

[inds]

Download Full WSUS 3.0 Configuration step by step

http://forums.techarena.in/attachmen...achmentid=7987

Okay.. now I really DO believe this is SPAM/Phishing.

This is the second post in a week, different subjects (but the same email),
with the same exact link.

If a third one appears in this format, without any useful information in the
body, I will report all three of them as SPAM and have them removed.

[techguru1]

I have a similar yet different scenario:

I have a large number of computers that all have the same NetBIOS name, FQDN and (in many cases) the exact same configuration. The only difference without exception is each machine's IP Address. To clarify, the computers are in various locations and do not exist on the same network. The infrastructure is working properly and need not be of concern to those who wish to provide insight to the issue I am having.

As many other posters have indicated, WSUS 3.0 is replacing the computer in the WSUS Console ... based (as it appears) solely on their NetBIOS name. Of course, I realize that WSUS first establishes a secure relationship with each computer; evidence is in the registry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Win dowsUpdate\ in the values "SusClientId" and "SusClientIdValidation" ... the former being created by manually executing "WUAUCLT.EXE /resetauthorization /detectnow" and the latter once the WSUS server accepts the request and adds the computer to the console.

What I am assuming is that the aforementioned generated unique identifier must be getting assigned in duplicate ... not at all considering that each requesting computer has a unique IP address, as mentioned in my opening paragraph.

In summary, is there a way - at each client of WSUS - to specify a value thereby making the computer "unique" to WSUS ... taking into consideration my infrastructure as stated above?

Agreed; I already knew that the "SusClientId" and "SusClientIdValidation" values were unique. In fact, I renamed the values on one WinXP computer and subsequently deleted that computer from the WSUS Console. Then, after executing "WUAUCLT.EXE /resetauthorization /detectnow" and/or "NET STOP WUAUSERV & NET START WUAUSERV", new and unique values were regenerated for on the WinXP WSUS client machine.

I understand why Microsoft made this change on WSUS 3.0, in contrast to 2.0 where duplicates were being created in the WSUS Console after (for example) disjoining and rejoining the domain. However, they should still provide backward compatibility for infrastructure scenarios like mine where computers are deployed to various locations and managed by me; in regard to which Microsoft Updates are installed and when. In my scenario, it's paramount that the FQDN of each and every machine be identical.

I am considering BMC's Configuration Management (Formerly Marimba) tool at http://apps.bmc.com/products/products_services_detail/0,,0_0_0_1301,00.html[/url]. However, this issue may likely persist, regardless of which patch deployment tool is employed.

I will continue to research this. However, given the unique infrastructure, it's likely I will be forced to update all previously-deployed machines to have a unique FQDN.

Actually the FQDN. This won't help in your situation, of course. If you can't
avoid having duplicate FQDNs, your only recourse (so far as I know) is to run
multiple WSUS servers.

No, the machines will still have different identifiers. The WSUS server simply
deletes the "old" record when a duplicate FQDN appears. In normal
circumstances, this prevents duplicate records appearing for the same computer
following a reinstall or if the SusClientId changes for any reason.

There's a recipe for disaster!

Using WSUS in the above described scenario is actually outside the scope of
the EULA.

Well, that's not true. Each computer establishes an *ANONYMOUS* connection
with the WSUS Server!

These values are not evidence of any secured connection -- it's just a
auto-generated GUID that provides the WSUS database with a unique identifier
for each client.

If it is getting duplicated -- that would be happening as a result of a
master image, which contains a SusClientID registry value, being cloned.

Well, as you pretty much alluded to above:

1. Delete the SusClientID and SusClientIDValidation values.
2. Run 'wuauclt /resetauthorization /detectnow' at a command prompt.

As noted in my previous reply... "infrastructure scenarios" like the one you
describe are not even licensed uses of a single WSUS Server, much less a
supported scenario!

You need to install an independent WSUS Server in each of your clients'
locations.

Yes.. you can pretty much count on the presence of duplicate names and
domains to be an issue in any network or systems management tool.

Yes.. you will.

And, even if you're not "forced"... you *should*. It's the right thing to
do.

[techguru1]

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.

This does work, so long as the two machines know what their fully qualified DNS
name is. You can check whether a computer knows it's DNS name under System
Properties, Computer Name, Full computer name.