Client sometime show at console screen and sometime not

hi

I'm running WSUS3 SP2, I have the issue where my client PC winXP SP3
sometime showing at the console and sometime not

I had put in the login script %systemroot%\system32\wuauclt.exe
/resetauthorization /detectnow

but still doesn't work

Any idea will be appreaciate

Thanks

"gbkhor" <> wrote in message
news:%...
> hi
>
> I'm running WSUS3 SP2, I have the issue where my client PC winXP SP3
> sometime showing at the console and sometime not
>
> I had put in the login script %systemroot%\system32\wuauclt.exe
> /resetauthorization /detectnow

This is not an appropriate command for a login script, and it won't address
your symptoms anyway.

How many clients are in your environment.
Is this the only machienthat "sometimes shows ... and sometimes not"?
Machines are not removed from the console, except by manual removal;
however, machines, which are identified in the WSUS database by a GUID
(SusClientID), can have their machine names changed.

If you have other machines that are exhibiting this same behavior, then the
most likely cause is that you have cloned them, and they have duplicate
SusClientIDs.

See KB903262 http://support.microsoft.com/default.aspx/kb/903262




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

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Hi Lawrence

I tested one machine with this command "%systemroot%\system32\wuauclt.exe
/resetauthorization /detectnow" immediately is show at console, but when I
logoff from that machine, it unlisted at console screen again.

Basically i have one primary and several downstream machine at different
location and I have about in total 1000 PC

I only seeing 4 to 5 hundered PC at primary console the rest not displayed
or not found at console

Yes, we use ghost to image the machine, but i had given an instruction to
run sysprep after it, but I can't guarantee my people follow that. Is there
a simple way to verify it?

Example, i had identify four machine not showing at console, I had use
psgetsid.exe on those machine not show at console, the result is their SID
are unique.

Will it be ok, if i put method 1 at login script at ALL the PC (i.e.
including those show at console), as it will be nightmare to cross check
which PC listed and which Pc not listed at console

Thanks

"Lawrence Garvin [MVP]" <> wrote in message
news:7A8BDF29-E994-4D27-988E-...
> "gbkhor" <> wrote in message
> news:%...
>> hi
>>
>> I'm running WSUS3 SP2, I have the issue where my client PC winXP SP3
>> sometime showing at the console and sometime not
>>
>> I had put in the login script %systemroot%\system32\wuauclt.exe
>> /resetauthorization /detectnow
>
> This is not an appropriate command for a login script, and it won't
> address your symptoms anyway.
>
> How many clients are in your environment.
> Is this the only machienthat "sometimes shows ... and sometimes not"?
> Machines are not removed from the console, except by manual removal;
> however, machines, which are identified in the WSUS database by a GUID
> (SusClientID), can have their machine names changed.
>
> If you have other machines that are exhibiting this same behavior, then
> the most likely cause is that you have cloned them, and they have
> duplicate SusClientIDs.
>
> See KB903262 http://support.microsoft.com/default.aspx/kb/903262
>
>
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"gbkhor" <> wrote in message
news:uWiq%...
> Hi Lawrence
>
> I tested one machine with this command "%systemroot%\system32\wuauclt.exe
> /resetauthorization /detectnow" immediately is show at console, but when I
> logoff from that machine, it unlisted at console screen again.

It's not your logoff that's causing that; the logoff is merely a
coincidental occurrence.

It is another PC with the same SusClientID causing this. It's a well known
and well-discussed scenario (at least once a week) and is caused by the
improper creation of master images and the cloning thereof.

The remediation steps are documented in KB903262
http://support.microsoft.com/default.aspx/kb/903262

> Yes, we use ghost to image the machine, but i had given an instruction to
> run sysprep after it, but I can't guarantee my people follow that. Is
> there a simple way to verify it?

sysprep is no longer sufficient to repair this issue; currently the only
viable methodology is to physically remove the SusClientID and
SusClientValidationID registry values from the master image prior to sealing
it.

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

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Hi Lawrence

Thanks, I will pick Method 1 from
http://support.microsoft.com/default.aspx/kb/903262

Will it be ok, if i put method 1 at login script at ALL the PC (i.e.
including those show at console), as it will be nightmare to cross check
which PC listed and which Pc not listed at console

Thanks again

"Lawrence Garvin [MVP]" <> wrote in message
news:429B1DDC-9544-4A07-8924-...
> "gbkhor" <> wrote in message
> news:uWiq%...
>> Hi Lawrence
>>
>> I tested one machine with this command "%systemroot%\system32\wuauclt.exe
>> /resetauthorization /detectnow" immediately is show at console, but when
>> I logoff from that machine, it unlisted at console screen again.
>
> It's not your logoff that's causing that; the logoff is merely a
> coincidental occurrence.
>
> It is another PC with the same SusClientID causing this. It's a well known
> and well-discussed scenario (at least once a week) and is caused by the
> improper creation of master images and the cloning thereof.
>
> The remediation steps are documented in KB903262
> http://support.microsoft.com/default.aspx/kb/903262
>
>> Yes, we use ghost to image the machine, but i had given an instruction to
>> run sysprep after it, but I can't guarantee my people follow that. Is
>> there a simple way to verify it?
>
> sysprep is no longer sufficient to repair this issue; currently the only
> viable methodology is to physically remove the SusClientID and
> SusClientValidationID registry values from the master image prior to
> sealing it.
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

"gbkhor" <> wrote in message
news:%...
> Hi Lawrence
>
> Thanks, I will pick Method 1 from
> http://support.microsoft.com/default.aspx/kb/903262
>
> Will it be ok, if i put method 1 at login script at ALL the PC (i.e.
> including those show at console), as it will be nightmare to cross check
> which PC listed and which Pc not listed at console

Method 1 is not suitable for execution as a LOGIN script, as the commands
provided should be run one-time only. If you wrap the script around logic
that includes creating a temp flag value in the registry key, and only
execute the script if that flag value is missing -- such that the script
then is only executed once for each machine -- then that should address your
issue.

Running the script against a machine which does not have a duplicate
SusClientID will cause no harm.


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

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Hi Lawrence

Thanks for the great advice, will use the temp flag at login script

"Lawrence Garvin [MVP]" <> wrote in message
news:78027F55-2735-451E-BE91-...
> "gbkhor" <> wrote in message
> news:%...
>> Hi Lawrence
>>
>> Thanks, I will pick Method 1 from
>> http://support.microsoft.com/default.aspx/kb/903262
>>
>> Will it be ok, if i put method 1 at login script at ALL the PC (i.e.
>> including those show at console), as it will be nightmare to cross check
>> which PC listed and which Pc not listed at console
>
> Method 1 is not suitable for execution as a LOGIN script, as the commands
> provided should be run one-time only. If you wrap the script around logic
> that includes creating a temp flag value in the registry key, and only
> execute the script if that flag value is missing -- such that the script
> then is only executed once for each machine -- then that should address
> your issue.
>
> Running the script against a machine which does not have a duplicate
> SusClientID will cause no harm.
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> My Blog: http://onsitechsolutions.spaces.live.com
> Microsoft WSUS Website: http://www.microsoft.com/wsus
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>

See Torgeir's script at

http://msmvps.com/blogs/athif/archiv.../04/65174.aspx

I use this a lot because some of my staff keep screwing up the image creation by
letting WSUS run and forgetting to remove the SUSClientID.

It really is a pity SYSPREP does not do this.


On Fri, 2 Oct 2009 21:46:35 +0800, "gbkhor" <> wrote:

>Hi Lawrence
>
>Thanks, I will pick Method 1 from
>http://support.microsoft.com/default.aspx/kb/903262
>
>Will it be ok, if i put method 1 at login script at ALL the PC (i.e.
>including those show at console), as it will be nightmare to cross check
>which PC listed and which Pc not listed at console
>
>Thanks again
>
>"Lawrence Garvin [MVP]" <> wrote in message
>news:429B1DDC-9544-4A07-8924-...
>> "gbkhor" <> wrote in message
>> news:uWiq%...
>>> Hi Lawrence
>>>
>>> I tested one machine with this command "%systemroot%\system32\wuauclt.exe
>>> /resetauthorization /detectnow" immediately is show at console, but when
>>> I logoff from that machine, it unlisted at console screen again.
>>
>> It's not your logoff that's causing that; the logoff is merely a
>> coincidental occurrence.
>>
>> It is another PC with the same SusClientID causing this. It's a well known
>> and well-discussed scenario (at least once a week) and is caused by the
>> improper creation of master images and the cloning thereof.
>>
>> The remediation steps are documented in KB903262
>> http://support.microsoft.com/default.aspx/kb/903262
>>
>>> Yes, we use ghost to image the machine, but i had given an instruction to
>>> run sysprep after it, but I can't guarantee my people follow that. Is
>>> there a simple way to verify it?
>>
>> sysprep is no longer sufficient to repair this issue; currently the only
>> viable methodology is to physically remove the SusClientID and
>> SusClientValidationID registry values from the master image prior to
>> sealing it.
>>
>> --
>> Lawrence Garvin, M.S., MCITP:EA, MCDBA
>> Principal/CTO, Onsite Technology Solutions, Houston, Texas
>> Microsoft MVP - Software Distribution (2005-2009)
>>
>> My Blog: http://onsitechsolutions.spaces.live.com
>> Microsoft WSUS Website: http://www.microsoft.com/wsus
>> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>>
>
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

"Dave Mills" <> wrote in message
news:...
> See Torgeir's script at
>
> http://msmvps.com/blogs/athif/archiv.../04/65174.aspx
>
> I use this a lot because some of my staff keep screwing up the image
> creation by
> letting WSUS run and forgetting to remove the SUSClientID.
>
> It really is a pity SYSPREP does not do this.

Actually, the fault is not SYSPREP's, but rather modifications made in the
v7 WUAgent that causes this.

In the v5 WUAgent, a value called AccountDomainSID was maintained in the
WUAgent key, which was compared against the machine SID. If the values did
not match, the WUAgent generated a new SusClientID. This is why sysprep did
work with WSUS v2/WUA v5 systems.

With the v7 WUAgent, thinking they'd "fixed" the duplicate SusClientID
problem by going to a machine-name-based scenario (which still really isn't,
because the SusClientID is still the unique key in the database), they
eliminated the AccountDomainSID from the registry, and thus eliminated the
only means possible to force the generation of a new SusClientID via
sysprep.

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

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

On Sat, 3 Oct 2009 07:56:06 -0500, "Lawrence Garvin [MVP]"
<> wrote:

>"Dave Mills" <> wrote in message
>news:.. .
>> See Torgeir's script at
>>
>> http://msmvps.com/blogs/athif/archiv.../04/65174.aspx
>>
>> I use this a lot because some of my staff keep screwing up the image
>> creation by
>> letting WSUS run and forgetting to remove the SUSClientID.
>>
>> It really is a pity SYSPREP does not do this.
>
>Actually, the fault is not SYSPREP's, but rather modifications made in the
>v7 WUAgent that causes this.
I did not say it was SYSPREPs fault but SYSPREP could be modified to delete the
WSUS keys.
>
>In the v5 WUAgent, a value called AccountDomainSID was maintained in the
>WUAgent key, which was compared against the machine SID. If the values did
>not match, the WUAgent generated a new SusClientID. This is why sysprep did
>work with WSUS v2/WUA v5 systems.
>
>With the v7 WUAgent, thinking they'd "fixed" the duplicate SusClientID
>problem by going to a machine-name-based scenario (which still really isn't,
>because the SusClientID is still the unique key in the database), they
>eliminated the AccountDomainSID from the registry, and thus eliminated the
>only means possible to force the generation of a new SusClientID via
>sysprep.

Actually IIRC it was a fix for the duplicate "computer name" with different
SUSClientIDs that this fixed. When a computer got a new SUSClientID it was
listed twice and the old one needed to be manually deleted. As a fix this has
worked.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.