locked
This computer has not reported status in "x" number of days RRS feed

  • Question

  • We run WSUS Server on a w2k12r2 and have clients configured through GPO accordingly. Most of the clients (all win10, different builds), do properly get their updates. In total we have about less then 100 clients. Some of them are listed in WSUS console with "This computer (Server) has not reported status in "x" number of days". Despite this fact they still get updates (not all of them, but lets focus first on these who get their updates without any issue). So my question is, how can a PC not report his status but in the same time it's getting updates from the very same WSUS?
    Any idea? I have double-checked if GPO is assigned ok, it is HKCU.... is correct and also Get-WindowsUpdateLog shows that this PC gets his updates from the WSUS in charge.
    I have googeld a lot and also have tried several fixes, for some machines it helps, for some not. Like I have had a few 1607 builds which had an issue with WSUS, I have applied that patch, if only this was the issue, it was fixed afterwards. But right now it is my own machine, which is a Creators Update (1703) with all patches applied, and it claims that it has not reported status for 326 days.
    To me this whole WSUS thing seems to be a bit of a thing where one can be lucky or not, whether it works good, somehow, or not at all.

    ANy idea how I can particularly check for this status reporting thing? And again, WSUS itself should not be wrong configured, since 85 % of the clients work well. It also is not a matter fo firewall etc, at least not that I wold be aware of.

    kind regards,
    Dieter Tontsch
    mobileX AG
    Monday, June 26, 2017 1:57 PM

Answers

  • My script will most likely fix your problem. My script does way more than what you showed.

    Also, Anne's comment about "Generally, if the clients not report for 326 days, they will be removed when run Server Cleanup Wizard" - This is true on the COMMUNICATION side, but not the reporting side. I'm guessing your computer is communicating with WSUS, just not reporting back.

    Anyways, without further adieu:

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need.

    http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

    What it does:

    1. Remove all Drivers from the WSUS Database.
    2. Shrink your WSUSContent folder's size by declining superseded updates.
    3. Remove declined updates from the WSUS Database.
    4. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    5. Compress Update Revisions.
    6. Remove Obsolete Updates.
    7. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    8. Application Pool Memory Configuration to display the current private memory limit and easily increase it by any configurable amount.
    9. Run the Recommended SQL database Maintenance script on the actual SQL database.
    10. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment, simply run:

    .\Clean-WSUS.ps1 -FirstRun

    and then

    .\Clean-WSUS.ps1 -InstallTask

    If you wish to view or increase the Application Pool Memory Configuration, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.


    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Thursday, June 29, 2017 2:47 AM

All replies

  • Hi Dieter Tontsch,

    Please do the following things and check the result after then:

    1. On the WSUS server, please run Server Cleanup Wizard. Generally, if the clients not report for 326 days, they will be removed when run Server Cleanup Wizard, but don't worry, if the GPO settings are correct and clients AU agent works well, they will show up again in the WSUS server;

    2. On the WSUS server, reindex WSUS database:

    On WSUS 2012 R2, we may use the following method to reindex WSUS database:

    1).Download and install the following tools:

    Microsoft Command Line Utilities 11 for SQL Server:

    https://www.microsoft.com/en-us/download/details.aspx?id=36433

    ODBC driver 11 for SQL:

    https://www.microsoft.com/en-us/download/details.aspx?id=36434

    2). In CMD, direct to SQLCMD.exe path using command:

    cd C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn

    3). Cope the script and store it locally:

    https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61#content

    3. On the clients, please reset windows update components:

    https://support.microsoft.com/en-us/kb/971058

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, June 27, 2017 2:12 AM
  • Hi, well I already do a regular cleanup with this script:

    CMD:

    @echo off 
    set WSUSPATH=C:\WSUSScripts\WSUS-CleanUp
    set WSUS-SERVER=server.domain.intra
    set PORT-NUMBER=8530
    set DATABASECONNECT=np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
    REM set DATABASECONNECT=np:\\.\pipe\MICROSOFT##WID\tsql\query 
    set SQLCMD="%ProgramFiles%\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe"
    
    set LOG=%WSUSPATH%\WSUS-CleanUp.log 
    set CLEANUPSCRIPT=%WSUSPATH%\WSUS-Cleanup.ps1 
    set SQLSCRIPT=%WSUSPATH%\WsusDBMaintenance.sql
    
    echo Start Database Cleanup: %DATE% at %TIME% >> "%LOG%"
    echo ============================================================= >> "%LOG%" 
    echo. >> "%LOG%" 
    echo Cleanup Report for [%WSUS-SERVER%] (Port: %PORT-NUMBER%) >> "%LOG%" 
    echo ------------------------------------------------------------- >> "%LOG%" 
    "%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe" "%CLEANUPSCRIPT%" %WSUS-SERVER% %PORT-NUMBER% >> "%LOG%"
    echo ------------------------------------------------------------- >> "%LOG%" 
    echo End Cleanup: %DATE% at %TIME% >> "%LOG%"
    echo. >> "%LOG%" 
    echo SQL Server Maintenance (Connect %DATABASECONNECT%) >> "%LOG%" 
    echo ------------------------------------------------------------- >> "%LOG%" 
    %SQLCMD% -I -S %DATABASECONNECT% -i %SQLSCRIPT% >> "%LOG%" 
    %SQLCMD% -I -S %DATABASECONNECT% -dSUSDB -Q "DBCC SHRINKDATABASE(N'SUSDB' )" >> "%LOG%" 
    %SQLCMD% -I -S %DATABASECONNECT% -dSUSDB -Q "DBCC SHRINKFILE (N'SUSDB' , 0, TRUNCATEONLY)" >> "%LOG%" 
    %SQLCMD% -I -S %DATABASECONNECT% -dSUSDB -Q "DBCC SHRINKFILE (N'SUSDB_log' , 0, TRUNCATEONLY)" >> "%LOG%" 
    echo ------------------------------------------------------------- >> "%LOG%" 
    echo End of Database-Cleanup: %DATE% at %TIME% >> "%LOG%"
    echo ============================================================= >> "%LOG%" 
    echo. >> "%LOG%" 

    WSUS-Cleanup.ps1:

    # WSUS Connection Parameters: 
    [String]$updateServer = $args[0] 
    [Boolean]$useSecureConnection = $False 
    [Int32]$portNumber = $args[1]   
    
    # Cleanup Parameters: 
    # Decline updates that have not been approved for 30 days or more, 
    # are not currently needed by any clients, and are superseded by an aproved update. 
    
    [Boolean]$supersededUpdates = $True 
    # Decline updates that aren't approved and have been expired my Microsoft. 
    [Boolean]$expiredUpdates = $True 
    # Delete updates that are expired and have not been approved for 30 days or more. 
    [Boolean]$obsoleteUpdates = $True 
    # Delete older update revisions that have not been approved for 30 days or more. 
    [Boolean]$compressUpdates = $True 
    # Delete computers that have not contacted the server in 30 days or more. 
    [Boolean]$obsoleteComputers = $True 
    # Delete update files that aren't needed by updates or downstream servers. 
    [Boolean]$unneededContentFiles = $True   
    
    #EndRegion VARIABLES  
    
    #Region SCRIPT   
    
    # Load .NET assembly 
    [void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")   
    
    # Connect to WSUS Server 
    $Wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($updateServer,$useSecureConnection,$portNumber)  
    
    # Perform Cleanup 
    $CleanupManager = $Wsus.GetCleanupManager() 
    $CleanupScope = New-Object Microsoft.UpdateServices.Administration.CleanupScope($supersededUpdates,$expiredUpdates,$obsoleteUpdates,$compressUpdates,$obsoleteComputers,$unneededContentFiles) 
    $CleanupManager.PerformCleanup($CleanupScope)
       
    #EndRegion SCRIPT

    WsusDBMaintenance.sql:

    /******************************************************************************
    This sample T-SQL script performs basic maintenance tasks on SUSDB
    1. Identifies indexes that are fragmented and defragments them. For certain
       tables, a fill-factor is set in order to improve insert performance.
       Based on MSDN sample at http://msdn2.microsoft.com/en-us/library/ms188917.aspx
       and tailored for SUSDB requirements
    2. Updates potentially out-of-date table statistics.
    ******************************************************************************/
    
    USE SUSDB;
    GO
    SET NOCOUNT ON;
    
    -- Rebuild or reorganize indexes based on their fragmentation levels
    DECLARE @work_to_do TABLE (
        objectid int
        , indexid int
        , pagedensity float
        , fragmentation float
        , numrows int
    )
    
    DECLARE @objectid int;
    DECLARE @indexid int;
    DECLARE @schemaname nvarchar(130); 
    DECLARE @objectname nvarchar(130); 
    DECLARE @indexname nvarchar(130); 
    DECLARE @numrows int
    DECLARE @density float;
    DECLARE @fragmentation float;
    DECLARE @command nvarchar(4000); 
    DECLARE @fillfactorset bit
    DECLARE @numpages int
    
    -- Select indexes that need to be defragmented based on the following
    -- * Page density is low
    -- * External fragmentation is high in relation to index size
    PRINT 'Estimating fragmentation: Begin. ' + convert(nvarchar, getdate(), 121) 
    INSERT @work_to_do
    SELECT
        f.object_id
        , index_id
        , avg_page_space_used_in_percent
        , avg_fragmentation_in_percent
        , record_count
    FROM 
        sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'SAMPLED') AS f
    WHERE
        (f.avg_page_space_used_in_percent < 85.0 and f.avg_page_space_used_in_percent/100.0 * page_count < page_count - 1)
        or (f.page_count > 50 and f.avg_fragmentation_in_percent > 15.0)
        or (f.page_count > 10 and f.avg_fragmentation_in_percent > 80.0)
    
    PRINT 'Number of indexes to rebuild: ' + cast(@@ROWCOUNT as nvarchar(20))
    
    PRINT 'Estimating fragmentation: End. ' + convert(nvarchar, getdate(), 121)
    
    SELECT @numpages = sum(ps.used_page_count)
    FROM
        @work_to_do AS fi
        INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id
        INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id
    
    -- Declare the cursor for the list of indexes to be processed.
    DECLARE curIndexes CURSOR FOR SELECT * FROM @work_to_do
    
    -- Open the cursor.
    OPEN curIndexes
    
    -- Loop through the indexes
    WHILE (1=1)
    BEGIN
        FETCH NEXT FROM curIndexes
        INTO @objectid, @indexid, @density, @fragmentation, @numrows;
        IF @@FETCH_STATUS < 0 BREAK;
    
        SELECT 
            @objectname = QUOTENAME(o.name)
            , @schemaname = QUOTENAME(s.name)
        FROM 
            sys.objects AS o
            INNER JOIN sys.schemas as s ON s.schema_id = o.schema_id
        WHERE 
            o.object_id = @objectid;
    
        SELECT 
            @indexname = QUOTENAME(name)
            , @fillfactorset = CASE fill_factor WHEN 0 THEN 0 ELSE 1 END
        FROM 
            sys.indexes
        WHERE
            object_id = @objectid AND index_id = @indexid;
    
        IF ((@density BETWEEN 75.0 AND 85.0) AND @fillfactorset = 1) OR (@fragmentation < 30.0)
            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';
        ELSE IF @numrows >= 5000 AND @fillfactorset = 0
            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD WITH (FILLFACTOR = 90)';
        ELSE
            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD';
        PRINT convert(nvarchar, getdate(), 121) + N' Executing: ' + @command;
        EXEC (@command);
        PRINT convert(nvarchar, getdate(), 121) + N' Done.';
    END
    
    -- Close and deallocate the cursor.
    CLOSE curIndexes;
    DEALLOCATE curIndexes;
    
    
    IF EXISTS (SELECT * FROM @work_to_do)
    BEGIN
        PRINT 'Estimated number of pages in fragmented indexes: ' + cast(@numpages as nvarchar(20))
        SELECT @numpages = @numpages - sum(ps.used_page_count)
        FROM
            @work_to_do AS fi
            INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id
            INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id
    
        PRINT 'Estimated number of pages freed: ' + cast(@numpages as nvarchar(20))
    END
    GO
    
    
    --Update all statistics
    PRINT 'Updating all statistics.' + convert(nvarchar, getdate(), 121) 
    EXEC sp_updatestats
    PRINT 'Done updating statistics.' + convert(nvarchar, getdate(), 121) 
    GO
    
    --Delete sync history
    PRINT 'Delete sync history.' + convert(nvarchar, getdate(), 121)
    DELETE FROM tbEventInstance WHERE EventNamespaceID = '2' AND EVENTID IN ('381', '382', '384', '386', '387', '389')
    GO

    and get the following output in the log:

    Start Database Cleanup: 27.06.2017 at  9:08:10,96  
    =============================================================  
      
    Cleanup Report for [server.domain.com] (Port: 8530)  
    -------------------------------------------------------------  
    
    SupersededUpdatesDeclined : 2
    ExpiredUpdatesDeclined    : 0
    ObsoleteUpdatesDeleted    : 60
    UpdatesCompressed         : 251
    ObsoleteComputersDeleted  : 0
    DiskSpaceFreed            : 339779144
    
    -------------------------------------------------------------  
    End Cleanup: 27.06.2017 at  9:11:27,98  
      
    SQL Server Maintenance (Connect np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query)  
    -------------------------------------------------------------  
    -------------------------------------------------------------  
    End of Database-Cleanup: 27.06.2017 at  9:11:28,19 
    =============================================================

    As you can see it cleans up lots of superseeded updates and so on and so forth. But it does not delete computers which have not reported since 30 or more days. My script should delete computers which have not CONTACTED the server since 30 or more days, but this is not the case. They are contacting the server, just they do not report, or at least WSUS claims that.

    I have run the cleanup wizard manually and got 0 for each, also for computers which have not contacted the server. Of course, because what cleanup wizard does I do each week via script.

    If I manually delete such a computer in charge, it will be re-added, but usually it remains in status "not yet reported" then.

    kind regards,

    Dieter Tontsch

    mobileX AG


    Tuesday, June 27, 2017 7:39 AM
  • Hi Dieter Tontsch,

    Please try resetting windows update components on the clients, check if after that clients will report to the WSUS server:

    https://support.microsoft.com/en-us/kb/971058

    Best Regards,

    Anne


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, June 28, 2017 7:47 AM
  • My script will most likely fix your problem. My script does way more than what you showed.

    Also, Anne's comment about "Generally, if the clients not report for 326 days, they will be removed when run Server Cleanup Wizard" - This is true on the COMMUNICATION side, but not the reporting side. I'm guessing your computer is communicating with WSUS, just not reporting back.

    Anyways, without further adieu:

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need.

    http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

    What it does:

    1. Remove all Drivers from the WSUS Database.
    2. Shrink your WSUSContent folder's size by declining superseded updates.
    3. Remove declined updates from the WSUS Database.
    4. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    5. Compress Update Revisions.
    6. Remove Obsolete Updates.
    7. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    8. Application Pool Memory Configuration to display the current private memory limit and easily increase it by any configurable amount.
    9. Run the Recommended SQL database Maintenance script on the actual SQL database.
    10. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment, simply run:

    .\Clean-WSUS.ps1 -FirstRun

    and then

    .\Clean-WSUS.ps1 -InstallTask

    If you wish to view or increase the Application Pool Memory Configuration, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.


    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Thursday, June 29, 2017 2:47 AM
  • Hi Adam,

    thanks for that. I have configured and installed your script, this really seems to be the high-end script when it comes to WSUS cleanup and maintenance. At least with your script, despite the fact that I already used some cleanup scripts all the time, it additionally declined  more then 5000 superseded updates and freed about 360 GB of 530 GB from downloads. 

    I will continue using this one, good job. But it still does not resolve my issue with clients not having reported since x days. In the meantime I found that I achieved best results when removing clients in charge from WSUS and let them re-register again. Some did report afterwards, but some still do not report, and now they have not reported yet ever :-)

    Any idea what I can do in order to make them reliably  work again? And you are right, there is a communication between WSUS and client, because otherwise the client wont register again after deletion. But the y do not report or WSUS does not understand what they report.

    i tried several solutions, stopping services, deleting SoftwareDistribution, using a PowerShell Script which also claims to fix this isssue, and much more. For some clients this works, for some not. Anyway, it is quite inconvenient going to each and every client, trying lots of things, not knowing whether they solve things or not. latency of WSUS is high anyway, sometimes after hours you finally see a progress in terms of status change...

    However, thanks a lot for your script, I hope it does not delete too much.

    kind regards,

    Dieter Tontsch

    mobileX AG

    Thursday, June 29, 2017 5:41 PM
  • 1607 RTM has a known issue that it will lose communication with any WSUS server. The fix for this is to install a CU past September as it was fixed in the September CU. Unfortunately, if the system is already 1607 RTM, you have no choice but to use a 3rd party tool like PDQ Deploy or install the CU Manually on the machine.

    It's best to install the latest CU, but you can install any one past September and then WSUS will be able to communicate again with the machine.

    Since you just ran my script, leave it for a couple of days and see if the other OS's report in.

    Try also from a client that does not report in - delete from WSUS and then run on the computer:

    net stop bits
    net stop wuauserv
    reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
    reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
    reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
    reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f
    rd /s /q "%WinDir%\SoftwareDistribution"
    net start bits
    net start wuauserv
    wuauclt /resetauthorization /detectnow


    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Thursday, June 29, 2017 6:02 PM
  • Hi,
    I am aware of the 1607 issue with WSUS, and I have applied that CU several times in order to make it work. But these computers in charge are all 1511 version. And as I said, some of them, by the simply fact that I have removed them from WSUS inventory and the re-registered, after a while they started to report. So, not modifying anything on client-side. But as you suggested, I will wait for a few days, and I will try the solution you provided in your last post.
    Thanks
    Friday, June 30, 2017 6:11 AM
  • Adams script, eventually in conjunction with removing and auto-registering of clients again seem to solve the issues. Eventually on some clients these things need to be done additionally:

    net stop bits net stop wuauserv reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f rd /s /q "%WinDir%\SoftwareDistribution" net start bits net start wuauserv wuauclt /resetauthorization /detectnow

    But afterwards almost any client is fine again.

    Thanks Adam

    Dieter

    Monday, July 3, 2017 12:40 PM
  • Adams script, eventually in conjunction with removing and auto-registering of clients again seem to solve the issues. Eventually on some clients these things need to be done additionally:

    net stop bits net stop wuauserv reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientIDValidation /f rd /s /q "%WinDir%\SoftwareDistribution" net start bits net start wuauserv wuauclt /resetauthorization /detectnow

    But afterwards almost any client is fine again.

    Thanks Adam

    Dieter

    You're welcome :)

    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Monday, July 3, 2017 1:39 PM