As usual, please bear with me with my essay below.
Due to change control requirements, we are going to have a new ePO server running at the same time as an old ePO server, with a
migration that may take some time. Due to the new server having different keys due to new server name, the remote sites are going
to have 2 repositories, 1 for the endpoints managed by the old ePO server, and 1 for the endpoints managed by the new ePO server.
At some point in time, due to low available bandwidth* to remote sites, we would want to decomission the old repository on some
sites, however the ePO server will still be active. On occasion we see an endpoint that requires a full DAT zip update (I know
there are workarounds that should ensure that this is never the case such as fallback sites etc, but hosts can actually be off for a
large amount of time in this environment) - we dont want these hosts to download this DAT zip from the ePO server, but again, due to
low bandwidth constraints, we dont want two lots of repository pushes per site, and eventually want to decomission the old
repository on some sites while leaving the old ePO server active.
Now... the main question is that when a host is powered on, what order are actions carried out by the agent? May seem like a wierd
question, but does it download any new policies from the ePO server before carrying out client tasks? The DAT download task is
configured to run every hour, and run after 5 minutes if missed. The agent policy currently has the ePO server enabled as a backup
repository if the local repository is unavailable, and obviously we cant change the policy on a host that is off. I have a feeling
that an update task may start to run before a new policy is received to advise the host that has been off for a while not to use the
ePO server as a backup repository. I would look at filtering on the network, but if the ePO repository is used, the same port is used to
download the updates as is used to call back (agent to server communication port) - so essentially this cant be done.
I have tried to keep this as concise as possible and may be missing something obvious, but any input on this would be greatly appreciated!
*Due to the low bandwidth available, we need to be in control of file transfer times. Sometimes on remote sites, a laptop or
workstation can pop up that has not been used for over a month and hence it requires the full DAT zip. As we are not in control of
the time that the laptop/workstation can suddenly become alive, we dont want a full DAT zip transfer from the ePO server suddenly
happening during busy network times, so repositories are preferred.