Back on the old "GetPackageInfo.aspx: Server is busy. Package request is backing off"
I am on a remote with a customer on Package Server synchronisation issues.
We have blocked http traffic at the IIS level to only allow requests from one of the 3 unconstrained Package Servers. We are currently updating the package (downloading) at a rate of 2 packages per minutes.
This may look like a good number if the packages were downloading something, but no. We are only downloading the package.xml from the server (served by GetPackageInfo.aspx) and then the snapshot.xml (from the url/unc path provided in the package.xml).
So why is it downloading at such a slow rate? First of all because we reduced the Retry Delay and MaxRetry Delay  to the lowest possible values: 1 and 1 (each one minutes). So the AeXNetComms dll doesn't block outgoing requests for up to an hour as per default (in effect this change is benefiting the download rate a lot).
Still, with these aggressive settings in place the PS Agent spends between 50~75% of its time doing nothing... logging the infamous server busy messages.
Right now we have had a run of 3~4 minutes with 5~10 packages updating. Let's see if anything comes up. Note that we have Wireshark running and capturing http traffic at the PS level. We can see that when the Altiris Agent logs Server busy errors no outbound http requests are made, so the AeXNetComms is implementing the 2x1 minute retry period at a global level.
The error's back. IIS error log files doesn't show anything. Argh. Still looking...
Planning a robocopy job to replicate the other uPS and let the cPS catch up before tomorrow. So much work for only a couple of files to synchronise.
A word on the IIS error seen in httperr files: Connection_Dropped seem to indicate an with network connection whilst the request is being processed. In short Http.sys receives the request and passes it to the designated w3wp process. The process picks the request from the queue and starts processing it, however the connection is reset before the http response is crafted and sent back to the requestor .
More on this tomorrow hopefully with some good news.