none
WSUS Clients fail with 0x80244010 in a silent installation

    Question

  • Hi

    This problem is becoming more and more of a headache.

    We run a silent OS deployment tool that has a post install script to install and configure the system to point to our WSUS Server. The network is active but the system does not have Internet access, so it polls for the WSUS server for High classification patches.

    Now upon each system install I'm getting WSUS client error 0x80244010. Google then points to this blog post:

    http://blogs.technet.com/b/sus/archive/2008/09/18/wsus-clients-fail-with-warning-syncserverupdatesinternal-failed-0x80244010.aspx

    Quote "So what does this mean to you?  If using WSUS only, not much.  First of all this will only occur on new clients that have not synced with WSUS or clients which have had the datastore removed (%windir%\softwaredistribution).  Second, the clients will only fail during the first scan but succeed on the second (or sometimes third).  The detection frequency can be configured by group policy or a registry setting and by default will occur every 22 hours."

    This is all well and good but when the error occurs it requires you to press OK to carry on running the WSUS install. Our silent deployments run on a timeout model and obviously, unless the installs are watched, we are constantly getting installs timing out.

    "the clients will only fail during the first scan but succeed on the second (or sometimes third)." Surely this can't be the fix for the problem? I'd have to run the same process two or three times just to get the system the latest patch levels?

    "The error, 0x80244010, means WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS and happens when a client has exceeded the number of trips allowed to a WSUS server.  We have defined the maximum number of trips as 200 within code and it cannot reconfigured." - Is there no way to increase the maximum number of trips?

    Thanks.

    Regards


    Friday, July 15, 2011 11:17 AM

Answers

  • don't you feel it's at all strange that every other OS is fine but 2008 x64?

    Well, first, this is an invalid statement. I have seen this issue occur on ALL operating systems! as far back as Windows XP system that did not have the current service pack applied -- all the way back to XP SP1 systems needing XP SP2.

    The error occurs when the client makes more than 200 round trips to the server trying to download all approved patches?

    Second, it's not an error! It is a by design behavioral limitation programmed into the Windows Update Agent in order to constrain the amount of network connectivity used in a single detection event.

    Third, approvals have absolutely nothing to do with the process. The WUAgent caches all APPLICABLE updates -- including those that are Not Approved.

    Fourth, the issue is not constrained to just operating system updates -- it also would include Office updates, Definition Updates (for Windows Defender, installed by default), and any other updates applicable to installed components or applications on those machines.

    Fifth, even if the machine is baselined at Service Pack 2, until you DECLINE the pre-SP2 updates (which you cannot do until you update your images being used to install these systems), all of those pre-SP2 updates are also being cached in the WUAgent datastore, and are part of the update collection impacted by this round-trip limitation.


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, July 28, 2011 3:58 PM
    Moderator

All replies

  • "The error, 0x80244010, means WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS and happens when a client has exceeded the number of trips allowed to a WSUS server.  We have defined the maximum number of trips as 200 within code and it cannot reconfigured." - Is there no way to increase the maximum number of trips?

    There is no way to increase the value; nor is there actually any real reason to do so. As the article states, this is an initialization problem, not an operational one.

    What the article doesn't say is the actual root cause of this problem -- which is almost always TOO MANY updates defined as scannable on the WSUS server.

    Identify all SUPERSEDED updates on your WSUS Server and DECLINE them, thus reducing the number of updates that the WUAgent has to cache locally before it can perform the scan. By reducing the number of updates that must be scanned and evaluated, it is possible to get the entire collection within the "200 round trips" limitation.

    Bottom line what's happening here is that the WUAgent needs to cache the update definitions in the local datastore. On a new machine the datastore is void of any cached entries. There is a limit on how much data (i.e. how many round trips of data collection) that the WUAgent can perform during a detection interval. It's designed as a bandwidth and network throttling tool, and for sustained operations it's more than generous in its setting.

    For the initial scan, though, it can be problematic -- particularly if, for example, an XP SP3 machine is scanning all several hundred XP updates released since RTM -- and this is typically where this issue manifests. It may also appear on Windows Server 2003 systems for the same reason. Generally for Vista and later systems, there are not enough updates in the catalog to manifest this problem (yet) -- but you should also perform the same maintenance for those operating systems. If you have Vista (SP2) systems, then decline the pre-SP2 updates. Also, do so for Windows Server 2008 SP2 x86 systems. Once you've fully deployed SP1 to Windows 7 and Windows Server 2008 R2, you'll also want to decline the pre-SP1 updates for those two platforms.

     


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, July 15, 2011 4:52 PM
    Moderator
  • We are currently running WSUS 3.0 SP1, could this be happening due to not being on the latest SP2?

    Well, not being on the latest rev of WSUS definitely introduces a performance disadvantage, but this 200-round-trips limitation has not been changed. As noted in the article, this only occurs on initial detection of the client.

    With regard to your 2008 x64 systems, are they baselined at Service Pack 2? Have you declined all pre-SP2 updates? A WSUS server I just installed for testing two days ago shows over 750 updates just for the OS, add another collection for IE and other products. Also, if Definition Updates are applicable to this system, you may have a large collection there -- not unlikely that a Win2008 x64 system scanning the entire catalog could find upwards of 1000+ updates to be evaluated. (Obviously I have underestimated the number of updates now available to Vista and later systems.)

    With regard to the Server Cleanup Wizard, since the only thing it "removes" are expired updates, old revisions, and file content for declined updates, none of those 300+ updates were likely even affecting this round-trip issue. This is not something you can fix with the SCW. You will have to manually engage with the updates list, identify updates that are not decline that do not need to be detectable, and decline them. Specifically you should focus on superseded updates that report as 100% Installed/NotApplicable; but you should also include updates that pre-date the service pack levels that are deployed in your base installation images.


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, July 20, 2011 3:37 PM
    Moderator
  • Thanks again Lawrence, Is there a way to pre all SP2 updates without manually engaging with the list of updates?

    Go to the All Updates view, filter on Status=Installed/NotApplicable and Approval=Any Except Declined

    Enable and sort by the Supersedence flag.

    Select the superseded updates and Decline.


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, July 21, 2011 2:41 PM
    Moderator
  • When I do this, there are no updates at 100% all are 99%? Is it still safe to decline?

    NO!

    If ALL updates are reported as 99% Installed/NotApplicable, then you need to find the MISSING system(s) that are being reported as not updated. Most likely they are dead systems. Search All Computers and sort by Last Reported Date to find the oldest LRD. Verify those systems still exist; if not, delete them from the console so that their Not Updated status does not skew the percentages of those updates.

     

     


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, July 21, 2011 3:58 PM
    Moderator
  • I'm slightly concerned now as doing this search shows a system that last reported 21/07/2011(Today) has only 99% installed of Installed/Not Applicable? Shouldn''t this be showing 100%?

     

    I know it's not the oldest LRD but shouldnt all these be showing 100% if the patches that are approved have been installed?

     

    Regards


    • Edited by Timjon Wednesday, July 27, 2011 7:26 PM
    Thursday, July 21, 2011 4:18 PM
  • I'm slightly concerned now as doing this search shows a system that last reported 21/07/2011(Today) has only 99% installed of Installed/Not Applicable? Shouldn''t this be showing 100%?

    What this information identifies is that you have a NotInstalled/NotApproved update. That may, or may not, be a desirable objective. You need to determine whether the "missing update" needs to be installed, or not. For example, if the update that is NotInstalled/NotApproved is the .NET Framework v4.0, that might be a desirable state.

    Also, you need to be careful about the meaning of Installed/NotApplicable when looking at updates vs when looking at computers. Earlier you reported that ALL UPDATES were reporting as 99% Installed/NotApplicable -- that is not a desirable state. That most likely indicates COMPUTERS registered with the WSUS server that are not detecting/reporting, and should be removed. Keeping in mind our original objective -- identify updates that are superseded and 100% Installed/NotApplicable so they can be declined, thus reducing the number of updates that need to be scanned by a new client.

    An isolated update that is 99% Installed/NotApplicable indicates that the newest update in a collection is likely not approved or not yet installed, and the superseded update is still being reported as NotInstalled. A few updates that are 99% Installed/NotApplicable is actually an expected condition right after a synchronization on Patch Tuesday (the newest updates are not yet approved or installed). If ALL updates have 99% Installed/NotApplicable, that suggests one or more computer systems that are not providing installed state data to the WSUS server.

    But COMPUTERS reporting with 99% Installed/NotApplicable updates may well be a normal and expected condition, because rarely will you approve and install all available updates to a system. Furthermore, and perhaps more to the point of your question -- that number is not based on just your approved updates, but it's based on ALL updates available on the WSUS server and applicable to that system.  I've discussed this several times over the years -- but consider that a Server, more particularly, even, a Domain Controller, should never have certain updates installed to it -- Silverlight, to name one, currently the .NET 4.0 to name another. The important thing, when a computer is 99% Installed/NotApplicable, is to *know* why that value is not 100%. Sometimes, the better way to approach this is to not  use the percentage values, but to enable the COUNT columns. Identify the count of updates NotInstalled/NotApproved on a particular computer and confirm that the updates that represent that count do not include updates that should be approved and installed.


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Friday, July 22, 2011 2:47 PM
    Moderator
  • Is there any other ideas what could be causing this?

    Well, we know exactly what is causing the behavior.

    The point is that this is a natural artifact of an initial detection by a client, and the steps you have implemented to reduce the number of available update is the best you can do. Beyond that, if there are too many updates, there are too many updates.

    Then again . . . you could try patching your master image before sealing it... this would give you a ready-made-cache on your cloned machines *and* reduce the actual number of updates that need to be installed after OS deployment. Be sure to delete the SusClientID on your master image machine after patching but before sealing.

    btw.. you never answered one of my earlier (and critical) questions . . . is your Master Image baselined with Win2008 Service Pack 2 already installed?


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, July 26, 2011 12:15 AM
    Moderator
  • The master image is baselined at SP1, so I could streamline SP2 and see if that helps.

    We run an environment that some times requires systems to be and specific SP levels and not necessarily the latest.

     


    • Edited by Timjon Wednesday, July 27, 2011 7:26 PM
    Tuesday, July 26, 2011 8:03 AM
  • The master image is baselined at SP1, so I could streamline SP2 and see if that helps.
    Absolutely! For Windows Server 2008, SP1==RTM, which means your systems are scanning almost three years of updates. That's the root cause of hitting the 200-round-trip limitation doing the initial scan!
    We run an environment that some times requires systems to be and specific SP levels and not necessarily the latest.

    Given that support for any machines NOT running Service Pack 2 ended two weeks ago, and there will be no more patches available for Windows Server 2008 RTM (SP1) systems, I'd suggest you might want to find a solution forthwith for whatever situation is precluding the use of Service Pack 2.

    BTW... you should have mentioned this earlier when I advised you to DECLINE all pre-SP2 updates that were 100% Installed/NotApplicable. If you're still deploying RTM systems, then you CANNOT decline those pre-SP2 updates because you still NEED them. Thus you are stuck with this problem until you do eliminate your RTM (SP1) image baseline.

    And, generally speaking, the mentality that "some systems need to be at earlier service pack levels" is now Old School. For several years now Microsoft has enforced the expiration of downlevel service packs. In April, 2009, new Windows Server 2003 updates were only installable on (Win2003) Service Pack 2 systems; in July, 2010, new Windows XP updates were only installable on (WinXP) Service Pack 3; as of two weeks ago, new Windows Server 2008 (and Vista) updates will only be installable on (Win2008/Vista) Service Pack 2 systems.


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Tuesday, July 26, 2011 12:23 PM
    Moderator
  • Deployed the system with a baseline of SP2 and the same thing still happens! Error 0x80244010
    .

    I have no idea what to try now to fix the problem.

    I think you may not be grasping this fundamental point -- you may not be able to fix it. It's not "broken"! It is a "by design" behavior of the WUAgent, and it's not an issue for 99% of implementations.

    It is an issue for you because you're trying to script and force this sequence of events, rather than just letting the WUAgent do its job on its own -- or properly implementing Deadlines and a special Target Group -- which is how most environments deal with patching new machines up-to-date.


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Wednesday, July 27, 2011 6:32 PM
    Moderator
  • Ok, let me be more specific.

    I am grasping exactly what you are saying and I understand that our environment is slightly different from the "norm" but don't you feel it's at all strange that every other OS is fine but 2008 x64? Surely a similar amount patches were released for x32?

    Even though the our scenario is different, surely the mechanics are the same. The error occurs when the client makes more than 200 round trips to the server trying to download all approved patches? The number of patches between x32/x64 may differ slightly but not the extent where it would exceed that limit? Especially if they are baselined at SP2.

     

    Regards


    Wednesday, July 27, 2011 7:10 PM
  • don't you feel it's at all strange that every other OS is fine but 2008 x64?

    Well, first, this is an invalid statement. I have seen this issue occur on ALL operating systems! as far back as Windows XP system that did not have the current service pack applied -- all the way back to XP SP1 systems needing XP SP2.

    The error occurs when the client makes more than 200 round trips to the server trying to download all approved patches?

    Second, it's not an error! It is a by design behavioral limitation programmed into the Windows Update Agent in order to constrain the amount of network connectivity used in a single detection event.

    Third, approvals have absolutely nothing to do with the process. The WUAgent caches all APPLICABLE updates -- including those that are Not Approved.

    Fourth, the issue is not constrained to just operating system updates -- it also would include Office updates, Definition Updates (for Windows Defender, installed by default), and any other updates applicable to installed components or applications on those machines.

    Fifth, even if the machine is baselined at Service Pack 2, until you DECLINE the pre-SP2 updates (which you cannot do until you update your images being used to install these systems), all of those pre-SP2 updates are also being cached in the WUAgent datastore, and are part of the update collection impacted by this round-trip limitation.


    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
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, July 28, 2011 3:58 PM
    Moderator
  • Seems your response is a bit defensive and still you give no definitive answer.  Give people a simple manual form answer is all that is needed.  Take the offending device off the domain, log into the device at the device level w/o domain. Hit the internet with Wifi, change the settings back to the Win10 default and let it download the updates from MS. Apply the updates reboot, again, out of the domain, check for futher updates until you get a response that the device is up to date.  Then put the device back in the domain, reset the updates, have a nice day.  May be simple but worked like a charm.


    • Edited by vtice-merit Thursday, August 04, 2016 2:15 PM
    Thursday, August 04, 2016 2:08 PM
  • We were finally able to resolve our issue by going through WSUS and declining all the superseded updates.

    Running the server clean-up tool does not automatically decline a superseded update if that update was already approved. Therefore you need to go through from time to time and manually decline them. Luckily, there is a relatively painless way to identify superseded updates and decline the. 

    For complete answer please Refer to https://blogs.technet.microsoft.com/sus/2008/09/18/wsus-clients-fail-with-warning-syncserverupdatesinternal-failed-0x80244010/

    Monday, December 19, 2016 7:35 AM