Strange Clients Not Reporting To Console problem (Duplicate Hardware & Software Config)

Since I reinstalled WSUS this year, only about half of our site computers
are contacting the WSUS server.

I have a particular group of three computers, "office1", "office2" and
"office3". They are identical hardware and were all imaged with the same
Sysprepped image at the beginning of this year. They are all in the same
computer OU in Active Directory and therefore receive the same GPO which
places them into a group called "Office".

In the group of computers called "office" is a fourth computer that we'll
call "dm" which is different hardware and different Windows, software etc.

The situation is that only one of the three computers called "Office" 1, 2
or 3 can be reported in the console at any one time. The one which is shown
in the console is whichever one last reported its status. I have seen all
three at different times, but only one of them at a time.

The computer "dm" in the same group always appears.

Now, this is not the only instance of this that I have. I have a group of 30
computers in a suite that have identical hardware and software. They were
all loaded from the same sysprepped image a year ago.
But only one of those 30 computers ever shows up in the WSUS Console. They
are in a different computer group from the "office" group mentioned above. I
haven't got enough data for this group of 30 yet but I suspect it is the
same scenario, whichever computer last reported its status to WSUS is the
one that is reported in the console, and only that computer.

In both groups, all the computers are running Windows XP, in some cases it
is SP3. Some are probably still running SP2.

The situation seems to be repeated in some of the other groups but it is not
totally consistent.

There is no other indication, as far as I am aware, that there was a problem
with the sysprepping or any other process of setting these computers up. How
would you check the computer SID to see if there is anything untoward like a
duplication?

There is nothing in the logs of any of these machines that indicates any
problem. They all show they are contacting the Updates Server and getting
update information, they are all uploading updates back to the server.
ClientDiag works fine on every one without errors.

--

"NZSchoolTech" <> wrote in message
news:...
> Since I reinstalled WSUS this year, only about half of our site computers
> are contacting the WSUS server.
>
> I have a particular group of three computers, "office1", "office2" and
> "office3". They are identical hardware and were all imaged with the same
> Sysprepped image at the beginning of this year.

There's the first "most likely cause".

> The situation is that only one of the three computers called "Office" 1, 2
> or 3 can be reported in the console at any one time.

Bingo. Classic symptom. Duplicate SusClientID values caused by improper
cloning from an improperly prepared master image.

> Now, this is not the only instance of this that I have.

No.. I tend to doubt it.

> There is no other indication, as far as I am aware, that there was a
> problem with the sysprepping or any other process of setting these
> computers up.

But, in fact, there is a *critical* problem with the sysprepping!

> How would you check the computer SID to see if there is anything untoward
> like a duplication?

Read the sysprep documentation. Use the -reseal flag. -- for future efforts.
Actually, you'll want to rebuild your master image, so as to remove the
defective SusClientID from the image.

For these efforts, you need only delete the registry value 'SusClientID' in
the key
HKLM\Software\Microsoft\Windows\CurrentVersion\Win dowsUpdate
and reboot for every machine cloned from your defective master image.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

This is the script I run to sysprep the machines on XP
sysprep -mini -reboot -reseal -quiet

Furthermore, all of those computers worked fine on our previous WSUS 2.0
installation on a Windows Server 2003 R2 server.
The reporting problems have only been occurring since we set up a new
Windows Server 2008 x64 server and installed a new installation of WSUS 3.0
on it, with no migration of data from the old one.

Perhaps you'd like to think about what other possibilities would apply. What
is this SUSClientID? Is it something new in WSUS that Sysprep doesn't know
about and therefore gets cloned, well cloning PCs is so commonplace that
Microsoft should have their head around what is needed by now.

Thanks.

--


"Lawrence Garvin [MVP]" <> wrote in message
news:...
> "NZSchoolTech" <> wrote in message
> news:...
>> Since I reinstalled WSUS this year, only about half of our site computers
>> are contacting the WSUS server.
>>
>> I have a particular group of three computers, "office1", "office2" and
>> "office3". They are identical hardware and were all imaged with the same
>> Sysprepped image at the beginning of this year.
>
> There's the first "most likely cause".
>
>> The situation is that only one of the three computers called "Office" 1,
>> 2 or 3 can be reported in the console at any one time.
>
> Bingo. Classic symptom. Duplicate SusClientID values caused by improper
> cloning from an improperly prepared master image.
>
>> Now, this is not the only instance of this that I have.
>
> No.. I tend to doubt it.
>
>> There is no other indication, as far as I am aware, that there was a
>> problem with the sysprepping or any other process of setting these
>> computers up.
>
> But, in fact, there is a *critical* problem with the sysprepping!
>
>> How would you check the computer SID to see if there is anything untoward
>> like a duplication?
>
> Read the sysprep documentation. Use the -reseal flag. -- for future
> efforts. Actually, you'll want to rebuild your master image, so as to
> remove the defective SusClientID from the image.
>
> For these efforts, you need only delete the registry value 'SusClientID'
> in the key
> HKLM\Software\Microsoft\Windows\CurrentVersion\Win dowsUpdate
> and reboot for every machine cloned from your defective master image.
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

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

A Windows 2000-based, Windows Server 2003-based, or Windows XP-based
computer that was set up by using a Windows 2000, Windows 2003, or Windows
XP image does not appear in the WSUS console

"When you use Sysprep or another unique SID-generating technology to create
the images, the SusClientId registry value is not cleared if it was
populated within the image before the image is deployed."

--


"Lawrence Garvin [MVP]" <> wrote in message
news:...
> "NZSchoolTech" <> wrote in message
> news:...
>> Since I reinstalled WSUS this year, only about half of our site computers
>> are contacting the WSUS server.
>>
>> I have a particular group of three computers, "office1", "office2" and
>> "office3". They are identical hardware and were all imaged with the same
>> Sysprepped image at the beginning of this year.
>
> There's the first "most likely cause".
>
>> The situation is that only one of the three computers called "Office" 1,
>> 2 or 3 can be reported in the console at any one time.
>
> Bingo. Classic symptom. Duplicate SusClientID values caused by improper
> cloning from an improperly prepared master image.
>
>> Now, this is not the only instance of this that I have.
>
> No.. I tend to doubt it.
>
>> There is no other indication, as far as I am aware, that there was a
>> problem with the sysprepping or any other process of setting these
>> computers up.
>
> But, in fact, there is a *critical* problem with the sysprepping!
>
>> How would you check the computer SID to see if there is anything untoward
>> like a duplication?
>
> Read the sysprep documentation. Use the -reseal flag. -- for future
> efforts. Actually, you'll want to rebuild your master image, so as to
> remove the defective SusClientID from the image.
>
> For these efforts, you need only delete the registry value 'SusClientID'
> in the key
> HKLM\Software\Microsoft\Windows\CurrentVersion\Win dowsUpdate
> and reboot for every machine cloned from your defective master image.
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"NZSchoolTech" <> wrote in message
news:%...
> This is the script I run to sysprep the machines on XP
> sysprep -mini -reboot -reseal -quiet

Then they shouldn't have any duplicate SusClientIDs, and either you're
getting dupes from somewhere else, or this is not (despite the classic
symptoms) a dupe SusClientID scenario.

> Perhaps you'd like to think about what other possibilities would apply.

No, actually I'd like to inspect some real data;
there really aren't any other known possibilities.
See below for what we actually need.


> What is this SUSClientID?

The SusClientID is the GUID that WSUS stores to uniquely identify each
machine in the environment. It's captured in the WSUS database and in the
registry of each client machine.


> Is it something new in WSUS that Sysprep doesn't know about and therefore
> gets cloned, well cloning PCs is so commonplace that Microsoft should have
> their head around what is needed by now.

No, actually the SusClientID was more of an issue in WSUS 2 than WSUS 3;
it's been mitigated somewhat by some enhancements in WSUS 3, but
unfortunately not completely eliminated as a problem area.

It gets cloned when the -reseal parameter is not used, thus causing the
original SIDs of the master machine to not be properly deleted. The cloned
images then all contain the same SusClientID as the master machine.


We need to review a detection event on each of the three machines. Please
perform the following procedure, and then post the resulting log entries in
three separate messages in this thread.

1. Reboot the client.
2. After startup run the command 'wuauclt /resetauthorization /detectnow'
3. Wait 30 minutes.
4. Post the log entries starting with the time of the reboot from Step #1.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

"NZSchoolTech" <> wrote in message
news:...
> http://support.microsoft.com/kb/903262
>
> A Windows 2000-based, Windows Server 2003-based, or Windows XP-based
> computer that was set up by using a Windows 2000, Windows 2003, or Windows
> XP image does not appear in the WSUS console
>
> "When you use Sysprep or another unique SID-generating technology to
> create the images, the SusClientId registry value is not cleared if it was
> populated within the image before the image is deployed."

Yep.. that's the basic "classic" duplicate SusClientID issue.

But if you used -reseal on sysprep, then this cannot be the issue you're
experiencing.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Lawrence Garvin [MVP] wrote:

>> http://support.microsoft.com/kb/903262
>>
>> A Windows 2000-based, Windows Server 2003-based, or Windows XP-based
>> computer that was set up by using a Windows 2000, Windows 2003, or
>> Windows XP image does not appear in the WSUS console
>>
>> "When you use Sysprep or another unique SID-generating technology to
>> create the images, the SusClientId registry value is not cleared if it
>> was populated within the image before the image is deployed."
>
> Yep.. that's the basic "classic" duplicate SusClientID issue.
>
> But if you used -reseal on sysprep, then this cannot be the issue you're
> experiencing.

I'm not sure about this; we've had a lot of reports of this same thing
happening. Perhaps the WUA is regenerating the SusClientID after the sysprep
operation but before the machine is shut down for cloning?

Harry.

It is the issue, using -reseal, because that article admits as much.

I use the script shown to run sysprep every time because it means I don't
have to remember which switches to use, and it includes the -reseal option.

--


"Lawrence Garvin [MVP]" <> wrote in message
news:...
> "NZSchoolTech" <> wrote in message
> news:...
>> http://support.microsoft.com/kb/903262
>>
>> A Windows 2000-based, Windows Server 2003-based, or Windows XP-based
>> computer that was set up by using a Windows 2000, Windows 2003, or
>> Windows XP image does not appear in the WSUS console
>>
>> "When you use Sysprep or another unique SID-generating technology to
>> create the images, the SusClientId registry value is not cleared if it
>> was populated within the image before the image is deployed."
>
> Yep.. that's the basic "classic" duplicate SusClientID issue.
>
> But if you used -reseal on sysprep, then this cannot be the issue you're
> experiencing.
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

The article seems to suggest that Sysprep is not resetting that value if it
already exists.

That to me is as good as saying that Sysprep doesn't know about this new key
that WSUS uses, because that key didn't exist when Sysprep was last reissued
for XP. The version of Sysprep I am using appears to be dated October 2006.

It's a given we have installed updates on the machines before they are
cloned, because there are usually a lot to install and we want to save time
and work on the duplicates. So the key gets populated before the cloning,
and Sysprep doesn't remove it, -reseal or not.

This key is only of significance to WSUS 3 by the look of it. WSUS 2 doesn't
use it.

The article says there is some way of the key automatically being reset if
the machine has a different hardware configuration from the original. That
won't do much when we have computers with identical hardware configuration.

I followed the instructions in the article to delete the keys and reset
authorization and it now is working great on a small group of machines. So
now I have to work out how to automate it for a pushed update in Group
Policy to lots of machines.

--


"Harry Johnston [MVP]" <> wrote in message
news:...
> Lawrence Garvin [MVP] wrote:
>
>>> http://support.microsoft.com/kb/903262
>>>
>>> A Windows 2000-based, Windows Server 2003-based, or Windows XP-based
>>> computer that was set up by using a Windows 2000, Windows 2003, or
>>> Windows XP image does not appear in the WSUS console
>>>
>>> "When you use Sysprep or another unique SID-generating technology to
>>> create the images, the SusClientId registry value is not cleared if it
>>> was populated within the image before the image is deployed."
>>
>> Yep.. that's the basic "classic" duplicate SusClientID issue.
>>
>> But if you used -reseal on sysprep, then this cannot be the issue you're
>> experiencing.
>
> I'm not sure about this; we've had a lot of reports of this same thing
> happening. Perhaps the WUA is regenerating the SusClientID after the
> sysprep operation but before the machine is shut down for cloning?
>
> Harry.

"Harry Johnston [MVP]" <> wrote in message
news:...

>> But if you used -reseal on sysprep, then this cannot be the issue you're
>> experiencing.
>
> I'm not sure about this; we've had a lot of reports of this same thing
> happening. Perhaps the WUA is regenerating the SusClientID after the
> sysprep operation but before the machine is shut down for cloning?

You know... it *is* possible that -reseal is no longer a valid solution to
this issue.

I'm thinking back to WSUS v2 days... when there was also a registry value
for AccountDomainSID, which the WUA v5 client used to match against the
actual machine domain SID to determine if the SusClientID needed to be
refreshed.

WUA v7 no longer uses the AccountDomainSID value. Sysprep, while it does
clear the *machine* SIDs.. knows nothing about *application* values, such as
SusClientID -- ergo, SusClientID, which would have been reset under WUA v5
as a result of sysprep stripping the machine SID, will not be reset under
WUA v7, because there's nothing available to trigger the re-creation of the
SusClientID.

That leaves the *only* viable solution to manually remove the SusClientID
from the master image registry before running sysprep.

This also may explain the continued proliferation of duplicate SusClientID
values, even though the changes in WSUS v3 were supposed to reduce, if not
eliminate, them. We traded one problem for another, I'm afraid.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin