Re: Some clients not appearing in WSUS console but receiving updates
DaveMills
>I am using WSUS 3.1 and I have noticed some of my clients are not showing in
>the wsus admin console but they do receive updates. How can I fix this?
>
>Thanks.
Are they cloned images. Do the ones listed keep changing. Are the target group
names correctly set.
--
Dave Mills
There are 10 type of people, those that understand binary and those that don't.
Dave
change because there are over 1500 machines so its hard to keep track.
Here is the windowsupdate log from one machine which seems to be getting
updates OK but not listed in wsus console
Misc =========== Logging initialized (build: 7.1.6001.65, tz: +1030)
===========
Misc = Process: C:\WINNT\system32\wuauclt.exe
AUClnt Launched Client UI process
Misc =========== Logging initialized (build: 7.1.6001.65, tz: +1030)
===========
Misc = Process: C:\WINNT\system32\wuauclt.exe
Misc = Module: C:\WINNT\system32\wucltui.dll
CltUI FATAL: Failed to get notification handle, hr=80070057
AU Triggering AU detection through DetectNow API
AU Triggering Online detection (non-interactive)
AU #############
AU ## START ## AU: Search for updates
AU #########
AU <<## SUBMITTED ## AU: Search for updates [CallId =
{85141A54-62CB-4B7D-8AA9-2E27FC822C00}]
Agent *************
Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
Agent *********
Agent * Online = Yes; Ignore download priority = No
Agent * Criteria = "IsHidden=0 and IsInstalled=0 and
DeploymentAction='Installation' and IsAssigned=1 or IsHidden=0 and
IsPresent=1 and DeploymentAction='Uninstallation' and IsAssigned=1 or
IsHidden=0 and IsInstalled=1 and DeploymentAction='Installation' and
IsAssigned=1 and RebootRequired=1 or IsHidden=0 and IsInstalled=0 and
DeploymentAction='Uninstallation' and IsAssigned=1 and RebootRequired=1"
Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
Misc Validating signature for
C:\WINNT\SoftwareDistribution\SelfUpdate\Default\wuident.cab:
Misc Microsoft signed: Yes
Misc Validating signature for
C:\WINNT\SoftwareDistribution\SelfUpdate\Default\wuident.cab:
Misc Microsoft signed: Yes
Misc Validating signature for
C:\WINNT\SoftwareDistribution\SelfUpdate\Default\wsus3setup.cab:
Misc Microsoft signed: Yes
Setup *********** Setup: Checking whether self-update is required
***********
Setup * Inf file:
C:\WINNT\SoftwareDistribution\SelfUpdate\Default\wsus3setup.inf
Setup Update NOT required for C:\WINNT\system32\cdm.dll: target version =
7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuapi.dll: target version =
7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuapi.dll.mui: target
version = 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuauclt.exe: target version
= 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuaucpl.cpl: target version
= 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuaucpl.cpl.mui: target
version = 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuaueng.dll: target version
= 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuaueng.dll.mui: target
version = 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wucltui.dll: target version
= 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wucltui.dll.mui: target
version = 7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wups.dll: target version =
7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wups2.dll: target version =
7.1.6001.65, required version = 7.1.6001.65
Setup Update NOT required for C:\WINNT\system32\wuweb.dll: target version =
7.1.6001.65, required version = 7.1.6001.65
Setup * IsUpdateRequired = No
PT +++++++++++ PT: Synchronizing server updates +++++++++++
PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://server:8530/ClientWebService/client.asmx
PT WARNING: Cached cookie has expired or new PID is available
PT Initializing simple targeting cookie, clientId =
013a4a84-24fb-439c-a3e7-a73767618bdd, target group = , DNS name =
computername.domain
PT Server URL = http://server:8530/SimpleAuthWebService/SimpleAuth.asmx
PT +++++++++++ PT: Synchronizing extended update info +++++++++++
PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://server:8530/ClientWebService/client.asmx
Agent * Found 0 updates and 38 categories in search; evaluated appl. rules
of 511 out of 686 deployed entities
Agent *********
Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
Agent *************
AU >>## RESUMED ## AU: Search for updates [CallId =
{85141A54-62CB-4B7D-8AA9-2E27FC822C00}]
AU # 0 updates detected
AU #########
AU ## END ## AU: Search for updates [CallId =
{85141A54-62CB-4B7D-8AA9-2E27FC822C00}]
AU #############
AU AU setting next detection timeout to 2008-03-14 09:09:20
AU Setting AU scheduled install time to 2008-03-14 03:30:00
Report REPORT EVENT: {48A607ED-D16A-4947-AD8A-BCFE54174DEB} 2008-03-14
12:54:03:040+1030 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software
Synchronization Windows Update Client successfully detected 0 updates.
Report REPORT EVENT: {243EF3E7-D6C6-4103-A102-6C72AB6EE8EB} 2008-03-14
12:54:03:040+1030 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.
Misc =========== Logging initialized (build: 7.1.6001.65, tz: +1030)
===========
Misc = Process: C:\WINNT\system32\wuauclt.exe
AUClnt Launched Client UI process
Misc =========== Logging initialized (build: 7.1.6001.65, tz: +1030)
===========
Misc = Process: C:\WINNT\system32\wuauclt.exe
Misc = Module: C:\WINNT\system32\wucltui.dll
CltUI FATAL: Failed to get notification handle, hr=80070057
Report Uploading 2 events using cached cookie, reporting URL =
http://server:8530/ReportingWebService/ReportingWebService.asmx
Report Reporter successfully uploaded 2 events.
AU Forced install timer expired for scheduled install
AU UpdateDownloadProperties: 0 download(s) are still in progress.
AU Setting AU scheduled install time to 2008-03-15 03:30:00
![Winfried Sonntag [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXdEqZtpkXz0AFa1lLZBTRauO9fuu7812JL6tBjN90kK4_WHg=s40-c)
Winfried Sonntag [MVP]
> I am using WSUS 3.1 and I have noticed some of my clients are not showing in
> the wsus admin console but they do receive updates. How can I fix this?
Use this Script: http://msmvps.com/blogs/athif/pages/66376.aspx
Winfried
--
http://www.microsoft.com/germany/windowsserver2003/technologien/updateservices/default.mspx
http://www.wsuswiki.com/Home
DaveMills
>They are not cloned images (uses sysprep). Hard to say if the listed ones
>change because there are over 1500 machines so its hard to keep track.
I do not understand why you are using sysprep if you are not cloning images.
However when I had this (which was due to cloning without using sysprep) I used
the script written by Torgier which you can find here
http://www.archivum.info/microsoft.public.softwareupdatesvcs/2005-07/msg00423.html
I still run it as a startup script just in case. It is more manageable for 1500
clients as it only "fixes" the duplicates if they are duplicates.
Lawrence Garvin [MVP]
news:hj6nt31s0al3rg56o...@4ax.com...
>>They are not cloned images (uses sysprep). Hard to say if the listed ones
>>change because there are over 1500 machines so its hard to keep track.
> I do not understand why you are using sysprep if you are not cloning
> images.
More significantly, the fact that sysprep was used, significantly increases
the likelihood that it's a 'cloning' issue, since (as has been my
observation), the majority of people using sysprep are not using it
correctly -- which directly contributes to the cloning problem.
> However when I had this (which was due to cloning without using sysprep) I
> used
> the script written by Torgier which you can find here
> http://www.archivum.info/microsoft.public.softwareupdatesvcs/2005-07/msg00423.html
> I still run it as a startup script just in case. It is more manageable for
> 1500
> clients as it only "fixes" the duplicates if they are duplicates.
Running it as a startup script is, no doubt, also contributing to your
problems in a WSUS 3.0 environment (wasn't much good as a startup script in
WSUS 2.0 either). It should be run as a ONE-TIME-ONLY script -- and even
then, only when determined that running the script is the /correct/ fix for
that specific problem.
>>PT Initializing simple targeting cookie, clientId =
>>013a4a84-24fb-439c-a3e7-a73767618bdd, target group = , DNS name =
>>computername.domain
Fundamental/Basic problem --- the computer doesn't know what target group it
belongs to.
>>Agent * Found 0 updates and 38 categories in search; evaluated appl.
>>rules
>>of 511 out of 686 deployed entities
Thus found "0 updates and 38 categories", which accurately represents what's
viewable to a computer that thinks its in the "Unassigned Computers" group.
--
Lawrence Garvin, M.S., MCBMSP, MCTS(x4), MCP
Senior Data Architect, APQC, Houston, Texas
Microsoft MVP - Software Distribution (2005-2008)
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/profile/Lawrence.Garvin
DaveMills
<ons...@postalias.news> wrote:
>"DaveMills" <Dave...@newsgroup.nospam> wrote in message
>news:hj6nt31s0al3rg56o...@4ax.com...
>
>>>They are not cloned images (uses sysprep). Hard to say if the listed ones
>>>change because there are over 1500 machines so its hard to keep track.
>
>> I do not understand why you are using sysprep if you are not cloning
>> images.
>
>More significantly, the fact that sysprep was used, significantly increases
>the likelihood that it's a 'cloning' issue, since (as has been my
>observation), the majority of people using sysprep are not using it
>correctly -- which directly contributes to the cloning problem.
>
>
>> However when I had this (which was due to cloning without using sysprep) I
>> used
>> the script written by Torgier which you can find here
>> http://www.archivum.info/microsoft.public.softwareupdatesvcs/2005-07/msg00423.html
>> I still run it as a startup script just in case. It is more manageable for
>> 1500
>> clients as it only "fixes" the duplicates if they are duplicates.
>
>Running it as a startup script is, no doubt, also contributing to your
>problems in a WSUS 3.0 environment (wasn't much good as a startup script in
>WSUS 2.0 either). It should be run as a ONE-TIME-ONLY script -- and even
>then, only when determined that running the script is the /correct/ fix for
>that specific problem.
Are you thinking of the right script? This one runs once only. I don't have
problem in WSUS 3
>
>>>PT Initializing simple targeting cookie, clientId =
>>>013a4a84-24fb-439c-a3e7-a73767618bdd, target group = , DNS name =
>>>computername.domain
>
>Fundamental/Basic problem --- the computer doesn't know what target group it
>belongs to.
>
>>>Agent * Found 0 updates and 38 categories in search; evaluated appl.
>>>rules
>>>of 511 out of 686 deployed entities
>
>Thus found "0 updates and 38 categories", which accurately represents what's
>viewable to a computer that thinks its in the "Unassigned Computers" group.
--
Lawrence Garvin [MVP]
>>> However when I had this (which was due to cloning without using sysprep)
>>> I
>>> used
>>> the script written by Torgier which you can find here
>>> http://www.archivum.info/microsoft.public.softwareupdatesvcs/2005-07/msg00423.html
>>Running it as a startup script is, no doubt, also contributing to your
>>problems in a WSUS 3.0 environment (wasn't much good as a startup script
>>in
>>WSUS 2.0 either). It should be run as a ONE-TIME-ONLY script -- and even
>>then, only when determined that running the script is the /correct/ fix
>>for
>>that specific problem.
> Are you thinking of the right script? This one runs once only. I don't
> have
> problem in WSUS 3
I wasn't aware (or perhaps had forgotten, given that the thread date of the
link is Jul 2005!)... that this particular script actually maintained a flag
value.
I would hardly characterize this script as running "once-only". What it does
is =check= the SusClientID once only to see if it exists as a duplicate
somewhere else on the network. The script still runs every time the system
logs onto the network to do a local registry check -- which is pointless
once the problem has been resolved.
Of course, the presence of the flag value is no guarantee that the
SusClientId hasn't been RE-duplicated elsewhere after the script runs. :-(
Given that the problem is caused exclusively by human error, once the
duplicate clients are remediated, and appropriate steps are taken to ensure
the human error is not repeated, the script should be removed from the
network.
My issue was with this statement,
>>> I still run it as a startup script just in case. It is more manageable
>>> for
>>> 1500
>>> clients as it only "fixes" the duplicates if they are duplicates.
as it doesn't continue checking for duplicates -- it fixes a duplicate
one-time-only -- and that's how the script should be used. If it's thought
that a client has a newly duplicated ID, then the ~\ClientIDChecked registry
value needs to be manually deleted, so that the script can re-check against
the list of known IDs on the network share. Of course if that file hasn't
been updated in several months because everything's been happily noting the
presence of ~\ClientIDChecked -- which does not mean that the SusClientID
has, or has not, been changed on the client system since originally
remediated.
Furthermore, the original functionality of the WUA v5.8 client was actually
based on the value of the ~\AccountDomainSID registry key. If =that= value
was changed (which was a cached value), then the WUA triggered a
reinitialization of the SusClientID. That functionality no longer exists
(the AccountDomainSID registry key isn't even maintained by the WUA v7
client), and deleting the SusClientID on a current client does nothing that
I can see.
I just simulated the script by deleting the SusClientID registry value
and running 'wuauclt /detectnow'. The detection ran, logged the =same=
(deleted!) SusClientID in the WindowsUpdate.log, completed the detection
event, and did not rebuild the SusClientID value in the registry.