none
WSUS Reporting

    Question

  • Dear All,

    We got almost 4300 workstations in our environment but the workstation reporting in the console is 3600 in which we found its a problem with SUSCLIENTID and we fix it via SCCM & Group policy. But still the numbers are not increasing above 3600. Does that mean it is because of reporting cycle?

    Can anyone explain me why it is not showing all the workstation?


    Regards, Pratap

    Sunday, March 04, 2012 6:17 AM

Answers

  • Hi,

    Walk through this guide resolving the duplicate SUSClientID issue: http://blogs.technet.com/b/sus/archive/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-don-t-all-my-clients-show-up-in-the-wsus-console.aspx

    If it fails again,pls post your windowsupdate.log from your problematic client here.

    Best regards,

    Clarence


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.



    Monday, March 05, 2012 2:26 AM
  • We created a batch file using below script to refresh SUSCLIENTID which has fixed some client issue.

    This script is dysfunctional, which probably explains why it only worked on 80% of your systems.

    REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /va /f

    Overkill in deleting the entire registry KEY, when deleting only two VALUES would have been sufficient (see KB903262), but this part is more or less functional.

    WUAUCLT /ResetAuthorization /DETECTNOW

    And the use of this command at this point is correct, which would have initiated a new detection event, expired the targeting cookie, and allowed the Windows Update Agent to generate a new (unique) SusClientID.

    WUAUCLT /DETECTNOW

    This command is totally useless. It will be ignored by the WUAgent because it is already busy executing the previous invocation of WUAUCLT.

    PING 1.1.1.1 -n 1 -w 60000 >NUL
    WUAUCLT /REPORTNOW

    These two commands are highly unlikely to provide any useful results at all. The PING command is a creative way to insert a 60 second delay into the script, however, 60 seconds is not likely long enough to complete the original call to WUAUCLT, ergo, the odds that the /REPORTNOW command actually executed are very slim.

    Net stop wuauserv

    And unless that 60 second delay was long enough, and the /REPORTNOW command executed (which may account for the 80% of systems that did successfully update their SusClientID)... you then destroyed all of that work by yanking the service out from under the agent, effectively aborting any work still in progress -- and that could easily account for the 700 systems still broken.

    The actual fact is that only THREE commands are necessary to script the resetting of a SusClientID:

    REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate /f /v SusClientID
    REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate /f /v SusClientIDValidation
    WUAUCLT /ResetAuthorization /Detectnow


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, March 08, 2012 2:26 AM

All replies

  • Hi,

    Walk through this guide resolving the duplicate SUSClientID issue: http://blogs.technet.com/b/sus/archive/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-don-t-all-my-clients-show-up-in-the-wsus-console.aspx

    If it fails again,pls post your windowsupdate.log from your problematic client here.

    Best regards,

    Clarence


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.



    Monday, March 05, 2012 2:26 AM
  • We got almost 4300 workstations in our environment but the workstation reporting in the console is 3600 in which we found its a problem with SUSCLIENTID and we fix it via SCCM & Group policy. But still the numbers are not increasing above 3600. Does that mean it is because of reporting cycle?

    Can anyone explain me why it is not showing all the workstation?

    Appears to be some confusion here.... at least confusion on my part. :-)

    By default, Configuration Manager clients will not report to the WSUS (SUP) server in a Configuration Manager environment.

    So before you can take any of the advice about this issue, and before anybody can provide you a valid response, first we need to better understand exactly what your environment is, and why you're concerned about clients reporting to the WSUS server. Is the WSUS server configured as a Software Update Point (SUP) in your Configuration Manager environment?

    Also, worthy of note.. neither Configuration Manager, nor Group Policy, are capable of repairing a duplicate SusClientID issue, so I'm quite curious what is meant by "...and we fix it via SCCM & Group policy."

    In a Configuration Manager environment with a Software Update Point (SUP), the SusClientID is not used, and thus is irrelevant.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Monday, March 05, 2012 9:47 PM
  • lawrence,

    we are using Windows software update service 3 version and not SCCM(SUP). We created package to fix the duplication of SUSCLIENTID and we deployed it thru SCCM server.

    When we take WSUS report it is showing only for 3600 instead of 4300 machine. so for reporting purpose i need to find why all 4300 systems are not  showing in the report. Hope u got it now.


    Regards, Pratap

    Tuesday, March 06, 2012 7:03 AM
  • We created package to fix the duplication of SUSCLIENTID and we deployed it thru SCCM server.

    I should like to hear much more detail on exactly what you did to fix this problem using a ConfigMgr package -- and HOW you deployed it via ConfigMgr if ConfigMgr is not configured to do Software Updates! (Seems to me to be a major non-sequiter in that scenario.)

    When we take WSUS report it is showing only for 3600 instead of 4300 machine. so for reporting purpose i need to find why all 4300 systems are not showing in the report.

    Well, my guess would be that your ConfigMgr 'fix' didn't work -- at least not on the 700 systems that are missing -- and that's an exceptional amount of assumption going on in the face of zero evidence indicating the actual nature of the problem. Perhaps, maybe, it's simply a case of those 700 systems are not properly configured to begin with?

    If it is a duplicate SusClientID issue, might I also suggest using the procedures as documented in KB903262 -- which do not require a ConfigMgr "package", but can be implemented with a simple startup script.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin


    Wednesday, March 07, 2012 1:54 AM
  • Lawrence,

    I should like to hear much more detail on exactly what you did to fix this problem using a ConfigMgr package -- and HOW you deployed it via ConfigMgr if ConfigMgr is not configured to do Software Updates! (Seems to me to be a major non-sequiter in that scenario.)

    A: We created a batch file using below script to refresh SUSCLIENTID which has fixed some client issue.

    REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /va /f

    WUAUCLT /ResetAuthorization /DETECTNOW
    WUAUCLT /DETECTNOW
    PING 1.1.1.1 -n 1 -w 60000 >NUL
    WUAUCLT /REPORTNOW

    Net stop wuauserv
    PING 1.1.1.1 -n 1 -w 6000 >NUL
    Net start wuauserv

    Well, my guess would be that your ConfigMgr 'fix' didn't work -- at least not on the 700 systems that are missing -- and that's an exceptional amount of assumption going on in the face of zero evidence indicating the actual nature of the problem. Perhaps, maybe, it's simply a case of those 700 systems are not properly configured to begin with?

    If it is a duplicate SusClientID issue, might I also suggest using the procedures as documented in KB903262 -- which do not require a ConfigMgr "package", but can be implemented with a simple startup script.


    A - Correct the above package didnt work on 700 system so i used GP to update the same. I can see some numbers increasing but up to the level expected


    Regards, Pratap

    Wednesday, March 07, 2012 4:07 PM
  • We created a batch file using below script to refresh SUSCLIENTID which has fixed some client issue.

    This script is dysfunctional, which probably explains why it only worked on 80% of your systems.

    REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /va /f

    Overkill in deleting the entire registry KEY, when deleting only two VALUES would have been sufficient (see KB903262), but this part is more or less functional.

    WUAUCLT /ResetAuthorization /DETECTNOW

    And the use of this command at this point is correct, which would have initiated a new detection event, expired the targeting cookie, and allowed the Windows Update Agent to generate a new (unique) SusClientID.

    WUAUCLT /DETECTNOW

    This command is totally useless. It will be ignored by the WUAgent because it is already busy executing the previous invocation of WUAUCLT.

    PING 1.1.1.1 -n 1 -w 60000 >NUL
    WUAUCLT /REPORTNOW

    These two commands are highly unlikely to provide any useful results at all. The PING command is a creative way to insert a 60 second delay into the script, however, 60 seconds is not likely long enough to complete the original call to WUAUCLT, ergo, the odds that the /REPORTNOW command actually executed are very slim.

    Net stop wuauserv

    And unless that 60 second delay was long enough, and the /REPORTNOW command executed (which may account for the 80% of systems that did successfully update their SusClientID)... you then destroyed all of that work by yanking the service out from under the agent, effectively aborting any work still in progress -- and that could easily account for the 700 systems still broken.

    The actual fact is that only THREE commands are necessary to script the resetting of a SusClientID:

    REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate /f /v SusClientID
    REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate /f /v SusClientIDValidation
    WUAUCLT /ResetAuthorization /Detectnow


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, March 08, 2012 2:26 AM