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.

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