We have an existing 5.1.3 ePO mgmt server and a new ePO 5.3.3.
We are looking to migrate servers from old to new.
This is working for agents that communicate with the old mgmt server.
However we have 8 agent handler servers and hundreds of agents that only communicate with their respective handlers.
Is there a proven solution to migrate agent handlers and agents to the new server? I'm hoping to avoid orpaning hundreds of servers.
Will those systems be able to access the new epo server? When transferring systems, they will talk to that epo server first, then get its sitelist for any agent handlers on that server. If you point the agent handlers to the new server, then the systems that were talking to them will not get the transfer info, so you can't migrate your handlers until your systems are migrated. Are your agent handlers vm's or physical servers? If VM's, it might be best to set up new ones on the new epo server, then decomission the old ones once systems are migrated.
As a precaution, I would highly suggest exporting your system tree on the old server before transferring systems, as there are bound to be some that drop off and don't talk to the new server. You can then use that list to identify missing systems that would need the new agent deployed to them.
we have a couple of hundred servers that do not talk to the new ePO server, they only communicate through the handler(s).
I guess new agent handlers are an option but that does mean provisioning 8 new servers (even though, yes, they are VM's).
I guess it is not possible to have two instances of the agent handler running on the same Windows server?
no, that is not possible to have 2 instances running on the same server. If you can migrate some of the servers, you might want to consider that. However, the systems will have to be able to check into epo at least once to get an updated sitelist. Your only other option is to set up your agent handlers on the new epo server so they are in the sitelist, then set up your agent handler assignment rules, then deploy an agent from the new epo server.
You can also use EEDK to wrap the new server agent and check it into the old epo server and deploy it that way also. I wouldn't do that until you have all your handlers installed on the new server so there is a site the systems can reach.
Yes, I think there is going to involve a lot of agent re-installation.
Also it going to need to be done quickly to avoid orphaned agents.
Which is a pity as I was hoping for controlled, phased migration.
That is where eedk would come in handy to deploy the new agent to clients while they are still talking to the old server.