We are upgrading from ePO 4.6.8 to ePO 5.3.1. I built a new server with a different host name and IP Address. Both servers are in the same domain. I would like to migrate the managed systems (@2000 systems) from the 4.6.8 to the 5.3.1. I would like to just migrate the systems to the new server and start fresh with the policies, so I'm not concerned with moving anything but the managed systems to the new ePO server.
I have read that possibly the best/easiest approach is to add the new 5.3.1 ePO as a Registered Server on the 4.6.8 and then use the 'Transfer system' method. I have tried that but for whatever reason I cannot make a database connection to the 5.3.2 ePO. I'm positive I have the correct information entered and credentials. It may be a network issue but would like to know what logs on the 4.6.8 I could look at to verify.
As a temporary test, can I install the 5.0.2 McAfee Agent from the new server on a managed system over the 4.8 Agent and expect the system to start communicating with the new 5.3.1 ePO? I did try that and it appeared that the server xml file had the correct 5.3.1 ePO information but the sitelist.xml file still maintained the previous 4.6.8 ePO information.
I looking for any support in migrating these systems from one ePO to a newer ePO with a different host name and IP.
Thanks in advance for any support.
If you're not concerned about moving policies over, I'd have thought the easiest way would be to push the client installation from new server and let it overwrite the existing, so the agent then knows it's being managed by a new server. When you right-click the agent (shield icon) in the systray and go to "about", does it have the old server name or the new one? Also, try issuing an Agent Wake-Up from the ePO console, and see if that updates your sitelist.xml.
I deployed the new agent to the managed server and actually watched the McAfee\Agent directory structure on the target server build out. That was a good sign. However, the sitelist.xml file was not updated but the server file was updated. The 'About' status from the shield icon does have the new server listed. Subsequently, since the sitelist.xml file was not updated, it is not communicating with the new server. I tried to initiate a wake up from the new ePO server and it just times out.
I accessed the 4.6.8 ePO that was managing this server and it too cannot initiate a wake (as expected). The end result after the new agent was deployed is that this server seems to be in limbo and not managed. The question is how do I get the sitelist.xml file updated from here?
Hmm, I would have expected the sitelist to update. Can you open the agent status monitor and do a "Collect and Send Props" and "Check New Policies"? If these fail, there should be some sort of indication as to why, which might help figure out why it's not working.
Alternatively, I presume this procedure is what you used for attempting the transfer?
One gotcha on that I found when transferring the database to a new server was that the SQL team moved the TCP port SQL was listening on from default on the new one; that gave me lots of problems. And when you're entering the credentials right, you've copy/pasted those credentials into a SQL Server Management Studio connection or PowerShell Invoke-SqlCmd to make sure you can connect using those credentials?
Well, after further poking around, I found that the OS Host Firewall was still enabled for Guest/Public on the new ePO server. This was the root cause of the older ePO server not being able to make a database connection from the 'Registered Servers' configuration AND also the reason the new Agent Deployment was not able to communicate back to the new ePO. DARN Firewall!!!! These two things were successfully tested once the Firewall setting was disabled on the new ePO.
Thanks for your support. And yes, I really believe the preferred method is the KB you sited above and now that I made that database connection I can go that route.