One update should do it. Machines that were off at the time would pick up the change on next connection.
Master sitelist has a version number, if this is later than the one on the client then the client requests the later copy.
The reason the KB workround says to make a trivial change to repo or AH assignments in the ePO console is really to trigger a greater version number in the master sitelist so the clients all get a refresh on the next connection.
Please note though, you don't actually lose the AH data, you lose the AH priority so most often attempts connection to the first in the sitelist then in listed order regardless of the actually expected priority.
All AH are still listed, but you may endup connecting to the wrong one until the sitelist priority values are re-established by the sitelist refresh.
But what happens when client machines, in a DMZ, are normally behind a firewall and are assigned to a specific agent handler, try to talk to a different one, and fail?
Does the "defective" agent try one handler and then another, or just the first one and then stop?
Can this bug lead to orphaned agents, if they can't talk to a specific handler?
It'll walk down the list of enabled sites until it either connects or reaches the end of the list.
If it can't reach any of them, then yes such a machine would lose contact with ePO.
This is why it's good practice to try and provide some alternative routes where possible rather than rely on just the one connection as a single point of failure.
We've decided to sit out this revision of the agent and wait for patch 2.
It's only on 50 boxes out of 10,000 anyway
Is it possible to issue a roll-back of the agent so it goes back to 220.127.116.1122?
Can we install an older version of the agent on top of a new one?