Accepted Solutions
The sdconf.rec tells the agent who the primary is, and who the replicas are if you did an automatic rebalance before generating it. It also tells the agent how long to wait for a response from the AM server, and how many times to retry before giving up and trying another replica. 5 retries is a holdover from a long time ago, when there might have been an unreliable network (think X.25), so you wanted a lot of retransmissions to make sure your authentication request packet got through. But for a long time, networks have been pretty reliable, there for if an AM server did not respond after 3 requests (initial and 2 retries or attempts), it very likely will not reply after 6 attempts (initial and 5 retries).
So 5 retries is most often a waste of time if it comes into play.
Changing Retry attempts begs the question: should you change the re-transmission timeout or Maximum time between each retry (assuming no response)? Short answer, usually not, only exception might be a single increase to 6 seconds in a very busy agent - very busy being 10s of thousands of users on that agent in a short amount of time.
If you make this timeout too short, less than 5 seconds, you do not give the AM servers enough time to respond, so your agent sends a second or subsequent authentication request while the 1st response is in transit. This results in a re-use failed authentication, because the same token-code is used for two authentications.
I have seen one occasion or situation where increasing this timeout to 6 seconds actually helped to solve a problem. Customer was up north, where there is a lot of snow during the winter, and during snowstorms up to 17,000 employees were told to work from home and use a VPN connection to work. When all of these users started working during the morning of the snowstorm, the AM server logs showed 100s to 1000s of authentication failures due to re-use. The AM servers were so inundated with the authentication requests that during peak usage it was taking the AM server about 5.1 seconds to respond to an authentication request. This occurred between 7:30-9:30am, there were no problems after 9:30am. We increased the max timeout to 6 seconds, generated and downloaded a new sdconf.rec, placed the file on the VPN server and no more problem.
