WSUS clients fail with WARNING: SyncServerUpdatesInternal failed: 0x80244010
Here’s an issue we have been seeing lately that I wanted to let you know about. If you've just rolled out some new clients and are seeing these errors then this should explain why.
========
Issue: Newly built clients may fail to sync with the WSUS server with the following error:
2008-09-11 15:08:57:651 4908 738 PT WARNING: Exceeded max server round trips: 0x80244010
2008-09-11 15:08:57:651 4908 738 PT WARNING: Sync of Updates: 0x80244010
2008-09-11 15:08:57:651 4908 738 PT WARNING: SyncServerUpdatesInternal failed: 0x80244010
2008-09-11 15:08:57:651 4908 738 Agent * WARNING: Failed to synchronize, error = 0x80244010
2008-09-11 15:08:57:701 4908 738 Agent * WARNING: Exit code = 0x80244010
2008-09-11 15:08:57:701 4908 738 Agent *********
2008-09-11 15:08:57:701 4908 738 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2008-09-11 15:08:57:701 4908 738 Agent *************
Cause: 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. A “trip” to the server consist of the client going to the server and saying give me all updates within a certain scope. The server will give the client a certain number of updates within this trip based on the size of the update metadata. The server can send 200k worth of update metadata in a single trip so it’s possible that 10 small updates will fit in that single trip. Other larger updates may require a single trip for each update if they exceed the 200k limit. Due to the way Office updates are published you are more likely to see this error if you’re syncing Office updates since their metadata is typically larger in size.
The client takes these new updates as they trickle down and inserts them into a small database to cache them for future use. So during the first client synchronization with WSUS the client may get 75% of the available updates, put them into the database, and then fail at some point due to the number of max trips being exceeded. The good news is the second synchronization cycle will not need to start from the beginning since the client has already cached 75% of the updates into its database. The second cycle will pick up where it left off and most likely finish getting all the updates from the server. There have been a few rare cases where a third scan cycle is needed but more often than not two is sufficient.
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.
https://technet.microsoft.com/en-us/library/cc708521.aspx
To use group policy:
Automatic Update detection frequency
This policy specifies the number of hours that Windows will wait before checking for available updates. The exact wait time is determined by using the number of hours specified minus a random value between 0 and 20 percent of that number. For example, if this policy is used to specify a 20-hour detection frequency, then all computers to which this policy is applied will check for updates anywhere between 16 and 20 hours.
If the status is set to Enabled, Automatic Updates will check for available updates at the specified interval.
If the status is set to Disabled or Not Configured, Automatic Updates will check for available updates at the default interval of 22 hours.
To set Automatic Update detection frequency
1. In the Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
2. In the details pane, click Automatic Update detection frequency, click Enabled, and type the number of hours for the detection interval.
3. Click OK.
=======================
Or to use the registry:
If you are using ConfigMgr 2007 and using WSUS as a Software Update Point your workaround may be a little trickier. For normal Software Updates synchronization again the first sync will fail but the second/third scheduled sync would succeed. If using Operating System Deployment you will want to configure the Install Software Updates task to continue on errors so that other actions within the task sequence can continue despite the initial sync failure. Go to the Install Software Updates task, select the Options tab and choose “Continue on error". Next, you should add another Install Software Updates task right after the initial one if you want the OS patched. You can choose to configure this task to “Continue on error” as well and add a third Install Software Updates task but this may not be needed.
As for a long term fix. We are currently looking at all the available options and hope to have a more permanent fix somewhere down the road. I will try and post more information back to this blog when that information becomes available.
Joe Tindale | Senior Support Escalation Engineer
Comments
- Anonymous
January 01, 2003
The saga continues, still no solution. Is Microsoft ignoring this??? - Anonymous
January 01, 2003
WSUS 3.0 e 3.0 SP1: Mancata sincronizzazione dei client - Anonymous
January 01, 2003
We have the same problems on our corporate WSUS, each client need 3 times !Is there a way to increase the size of each trips as a workaroung ? - Anonymous
January 01, 2003
It's 9 months later now. Is there a solution for this problem which is more stable than the solution on this page. I'm looking for a Microsoft supported solution. Or should I say a Microsoft fix... :) - Anonymous
September 13, 2010
Any news about a fix or a solution ??? 2010 now.... :) - Anonymous
March 23, 2012
Really you want them to fix something.. Its 2012 and its still broke. The word workaround was invented by an IT guy for sure.... - Anonymous
February 01, 2013
Well... shouldn't this have been fixed by now. Just change the maximum number of trips to 3000 because this issue is really, really annoying. The manager who sat down and thought "Yeah, this is a good idea" was obviously the wrong man for the job.Come on Microsoft, this bug... and it is a bug no matter if intentional or not... should have been fixed years ago. - Anonymous
April 02, 2014
Any Update? its 2014 - Anonymous
February 19, 2016
Its 2016 and this is still causing issues with WSUS/SCCM...any fix? - Anonymous
February 23, 2016
It's 2016, and I'm still encountering this issue on our Windows 10 rollout. - Anonymous
February 26, 2016
Any update? its 2016 - Anonymous
March 08, 2016
Yes, it is now 2016 and still wondering whether or not this issue has been corrected? I continue to encounter this issue and as with some of the other posts it's very annoying having to click on search for updates several times. For me it's more than 3 times about 5 to 8 times until they finally are starting to download. What is the issue? How can this be remedied?- Anonymous
March 08, 2016
I'm also wondering when this will actually be fixed. Imagine all the wasted time cumulatively across the world... - Anonymous
March 10, 2016
I get the same issue, normally fixes itself after 5-6 times of checking.Really annoying Microsoft haven't managed to put a fix in for this yet! - Anonymous
March 10, 2016
I'm also getting this issue ... It's terrible! MDT Deployments fail constantly forcing a manual run of Windows updates
- Anonymous
- Anonymous
March 16, 2016
2016-3-16 Thanks for the info! I just kept trying it and after 4 or 5 tries and a few hours of scanning, it now says that the machine has 65 important updates. So, with Windows 7, this still isn't fixed and considering how people have reported Windows 8 and even 10 having the problem, I'll classify this is a "never-fix" for the Windows operating system. - Anonymous
March 28, 2016
This is annoying. Happening to all new clients added to my network nowadays. - Anonymous
March 30, 2016
Indeed! This is a annoying bug, please fix! - Anonymous
April 01, 2016
The comment has been removed - Anonymous
May 17, 2016
just encountered this issue earlier. reboot / restart, login local/domain didn't help.ran wuauclt, no help.I tried this suggestion from http://microsoft.public.gr.windows.servers.narkive.com/f0QsFzxT/solving-error-0x80244010-to-anyone-who-is-interestedopened CMD as admin then runregsvr32 wuapi.dllregsvr32 wuaueng.dllregsvr32 wuaueng1.dllregsvr32 wucltui.dllregsvr32 wups.dllregsvr32 wuweb.dllregsvr32 jscript.dllregsvr32 winhttp.dllran windows update, then voila. updating now.Client : Windows 2008 R2 EnterpriseWSUS : Windows 2008 R2 STD - Anonymous
May 17, 2016
Still experiencing this problem. Takes about 6-7 passes of manually running Windows update before the updates start to download. Kind of frustrating when you've got a large volume of desktops to build. - Anonymous
May 18, 2016
Недавно стал сталкиваться с данной проблемой все чаще и чаще. Поиски решения привели сюда. Я в шоке, что с 2008 года по 2016 год проблема не устранена. Это как понимать ? Что за бред. - Anonymous
June 06, 2016
07 June, 2016.more than 50 windows 7 PCs got this error. And not report to wsus ... - Anonymous
June 09, 2016
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. See here if you need to know how (not written by me, I take no credit):http://www.tecknowledgebase.com/43/how-to-identify-and-decline-superseded-updates-in-wsus/Windows updates now run like a dream.- Anonymous
July 08, 2016
Declining superseded updates was the solution.Windows updates now run like a dream. - Anonymous
July 11, 2016
Thanks Mr Flibbles. Been struggling with this for a very long time before seeing your post. This solved all our headaches immediately! - Anonymous
August 23, 2016
Many Thanks for your solutionWindows updates now run like a dream. - Anonymous
September 07, 2016
Declining superseded worked great for me - thank you so much for the info. I just changed out about 25 computers that had most of the patches already installed but kept failing the check for updates. Very happy I ran across your post - Anonymous
October 06, 2016
This worked fantastic, thank you so much - Anonymous
October 11, 2016
Jusr remeber to start at the upstream Server first , if you have replicated Server , this could cause some snyc issues
- Anonymous
- Anonymous
August 11, 2016
THANK YOU!This did the trick! http://www.tecknowledgebase.com/43/how-to-identify-and-decline-superseded-updates-in-wsus/I searched 2 days for this problem. This solved my issue!- Anonymous
August 29, 2016
Oh yeah, cleaning out WSUS did the trick!
- Anonymous
- Anonymous
August 30, 2016
Hi! Running wuauclt.exe /resetauthorization /detectnow fixed the problem for me. - Anonymous
October 06, 2016
This worked for me==================================================================net stop wuauservREG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /fREG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /fREG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /fnet start wuauservwuauclt /resetauthorization /detectnow================================================================== - Anonymous
December 16, 2016
Fixed in KB3102810? - Anonymous
January 13, 2017
The comment has been removed