In that post he touches on what's actually happening:
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:
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.
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.