none
Replica server "needed" updates different from Primary WSUS server RRS feed

  • Question

  • I've noticed that during testing, our replica WSUS 3.0 SP2 server reports a different number of updates that are "needed" from the primary server, for a test client which is running Windows XP Pro SP3. The XP test computer is manually assigned to a group on the replica computer, which has been replicated to the primary. On the primary server WSUS console I have assigned the test group, which the test computer is a member of, a number of updates totalling 20. However on the replica server a status report of the test computer shows that 28 updates are needed, with several of these not having been approved.

    There is no client-side tagetting enabled. All settings are applied via GPO. All WSUS servers are v3.0 SP2. There is/has been only one test client so-far. Only possible reason I can think of is that I have changed the test computers group membership twice - but on the replica server on each occassion. Any help gratefully received. Thank you.

    Friday, July 23, 2010 9:32 AM

Answers

  • It's necessary to consider a number of factors here:

    • The WUAgent reports status on updates regardless of whether those updates are approved or not.
    • Update status from the replica is rolled up during server synchronization. The upstream server is current as of that last synchronization/reporting rollup.
    • Update status on the replica is based on the last detection event performed by the client. The relationship between the frequency of server synchronization and client detection can cause such anomalies, as well as the specific time(s) at which those events occurs.

    Ergo it's not at all unusual that the replica server might show 28 updates needed, but the upstream server only shows 20. If the test client first detected those updates as needed subsequent to the most recent synchronization, then those detection events have not yet been reported to the upstream server. Take a look at the Arrival Date for those 8 updates -- if it's less than 24 hours ago, this is the reason.

    Bottom line: It's really not practical to make these kind of comparisons -- they almost never will match.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, July 23, 2010 8:37 PM
    Moderator

All replies

  • It's necessary to consider a number of factors here:

    • The WUAgent reports status on updates regardless of whether those updates are approved or not.
    • Update status from the replica is rolled up during server synchronization. The upstream server is current as of that last synchronization/reporting rollup.
    • Update status on the replica is based on the last detection event performed by the client. The relationship between the frequency of server synchronization and client detection can cause such anomalies, as well as the specific time(s) at which those events occurs.

    Ergo it's not at all unusual that the replica server might show 28 updates needed, but the upstream server only shows 20. If the test client first detected those updates as needed subsequent to the most recent synchronization, then those detection events have not yet been reported to the upstream server. Take a look at the Arrival Date for those 8 updates -- if it's less than 24 hours ago, this is the reason.

    Bottom line: It's really not practical to make these kind of comparisons -- they almost never will match.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, July 23, 2010 8:37 PM
    Moderator
  • Lawrence,

    Thank you for your very thorough answer and apologies for the delayed response - I have been away.

    Yes, I think I've now got the picture for this scenario and how updates are handled and display through the replica before being rolled up.

    Thanks again.

    Tuesday, August 17, 2010 9:31 AM
  • I have had the same problem and I do not feel this is at all normal. I have seen this happen when you decline an update then run the server cleanup wizard before it has had a chnace to replicate the declined update to the replica server. So make sure you give all the replicas time to update all the declined update before running the Server Cleanup Wizard on the primary WSUS.

    Now how I have have fixed this in the past is chnage the rolls of the primary and replica servers. Run the WSUS configuration wizard on both WSUS's and make the replica the primary and the primary the replica. Let it run like this for a day so that you are certain both servers are now showing all the correct number of updates. If you have more than one replica server this may take several days to change them each to the primary and wait for replication.

    Once every WSUS is showing the same number of updates then if you wish to change the primary back to the original you can. You should now be ok.

    This has worked for me in the past. Like I said at the begining now make sure not to run the WSUS Cleanup Wizard till all the replica servers are synchronized to the primary or this could happen again.

    Wednesday, December 28, 2011 4:35 PM
  • I have seen this happen when you decline an update then run the server cleanup wizard before it has had a chnace to replicate the declined update to the replica server.
    The Server Cleanup Wizard will have no impact on the replication of a DECLINE operation to replica servers because the Server Cleanup Wizard does nothing to an already declined update -- except delete the installation file associated with that update if the updates was previously approved. If the update was previously approved, then presumably the files are already on the replica server, so there's nothing to replicate except the change of status -- which will replicate regardless of the use of the Server Cleanup Wizard on the upstream server. Running the Server Cleanup on the replica servers after the synchronization will remove the file from the replica server.
    Now how I have have fixed this in the past is chnage the rolls of the primary and replica servers. Run the WSUS configuration wizard on both WSUS's and make the replica the primary and the primary the replica.
    This is totally unnecessary, and definitely NOT recommended. Doing this significantly risks causing permanent de-synchronization between your actual replica server and your actual upstream server. The correct way to manage this scenario is to properly coordinate the execution of the Server Cleanup Wizard on the replica servers with the upstreams server and the synchronization events.
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    Wednesday, December 28, 2011 5:18 PM
    Moderator