WSUS clients fail with WARNING: Exceeded max server round trips: 0x80244010

J C Hornbeck/Joe Tindale touched on this topic on a Microsoft blog post here.

In that post he touches on what's actually happening:

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.

I've bolded the more important information.  This is hardcoded and cannot be reconfigured.  This, to me, is a bit ridiculous that it can't be reconfigured.  

I have a WSUS client where we 'reset' the Windows Update client.  After resetting the client we were getting an error "WARNING: Exceeded max server round trips: 0x80244010".  We would try multiple times but this error wouldn't go away and prevented us from running Windows Update on this system.  So I started to investigate.  The first thing I did was finish reading that blog entry.  Hornbeck continues:

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.

Again, I have bolded and underlined the important parts.  

I started my investigation by trying to replicate the problem.  I started up Windows Update and 'checked for updates'.

Ok, no problem.  So I checked again.

Well, Hornbeck/Tindale did say it may take a couple passes.  Let's try again.

I'm getting worried now...  Let's try a fourth time.

Hmmm...   At this point I wanted to better understand what Windows Update was doing.  I originally installed Wireshark to trace the conversation but it was difficult and time consuming to try and count the traffic back and forth to the WSUS server.  So I reverted my system and installed Fiddler2 on it.

From the video you can actually see the traffic from the WSUS server.  The request for the 'Updates' starts at item 3 and completes at 203.  Exactly 200 round trips.

Since my previous Windows Update attempts at the WSUS server failed after a few tries I thought I would trace the traffic with Fiddler for the multiple attempts.  My logic was I wanted to know if the traffic was 'looping'; repeating itself and getting to the limit preventing updates.  Or, would each send/receive be unique and thus, simply, more is needed?

The first bit of the first run.  If the second run as identical or near identical traffic 'packet sizes' I would be concerned it's looping...

I reset Fiddler and started the second run.  Completely different!

When I started the second run I was happy to see it was a completely different result.  I cleared Fiddler for a 3rd time ran the 'Check for Updates' until it timed out again, and cleared Fiddler again.  I then thought to just let Fiddler capture everything.  There really is no need to clear it each time.  I monitored the Fiddler output looking for loops or patterns.  The update check timed out a forth time (as before).  There was no looping I could see.

Finally, on the fifth run:

Updates!  We have updates!

In the end, when the Microsoft blog post was written (2008) there probably was only enough updates that two or three passes would go through all of them.  As time as gone on and more and more updates have been deployed to systems this hardcoded maximum is doing a huge disservice.  Our Windows 2008R2 SP1 systems require FIVE passes of clicking/waiting/clicking/waiting/etc.

A natural solution to this is to expose the "max server round trips" variable and allow it to be programmed by the organization according to their needs.  The present state of this issue is unnecessarily confusing and arbitrarily limited.