I've called in to McAfee support who pointed out that EPO 5.1 is not supported on 32bit OSes like Server 2003R2. So I will need to "migrate" to Server 2012R2 before going to EPO 5.1
They also told me the IMPORTANT: note in KB71078 about not migrating clients to a new EPO server does not apply in this case because I am not really migrating the EPO client to a new EPO server. The New EPO server will be using the same database as the old EPO server. That warning in the KB71078 applies to moving the client from one EPO server to another EPO server. I am very concerned about that advice though since the KB article is pretty clear about it not working.
Does anyone here have advice on whether it is trouble or not to move EPO to new hardware and OS if the Database is not changing?
Has anyone ever hired Professional Services to do this work? What has been your experience there?
Moving ePO to new hardware is fairly painless and I have done this dozens of times. KB66616 is the backup and recovery KB for ePO. The same process is used to recover an ePO server as moving it to new hardware.
KB710789 and KB83186 refer to migrating to an ePO server with a new database. Following the guidance in KB66616 and moving the database to new hardware is supported.
If you are running on a x86 OS, you will need to stay on ePO 4.6 until after migrating to the x64 OS. However, Server 2012R2 is not supported with ePO 4.6 so you will need to go to Server 2008R2 x64.
There is a few things you will want to think about before taking action.
1. The IP of ePO should remain the same to allow clients to connect to ePO. There is ways around this but the easiest path is just to reuse the IP and use a DNS redirect for the old hostname.
2. It may be a good time to move the database to a production SQL server.
3. Create / review your ePO SQL database backup schedule.
Thanks for the tips.
Right now I have the EPO Server 4.6.6 application with SQL 2005 (Enterprise) running together on a Windows 2003 x86 Server.
My goal is to move that setup to two separate servers, splitting the EPO server application and the SQL database. I will keep EPO on the same version until the move is complere. I intend to upgrade SQL to at least SQL 2008R2 - and potentially SQL 2012 (underlying OS at 2008R2 is fine)
My first step, I think is to backup the database and restore it to separate new hardware. So I will have Current EPO Server App still running on the 2003 server, but then pointing it to the "new" SQL server which is the same (backed up and restored) database.
Then I will plan to move the EPO installation from the old server to the second new server running Server 2008R2.
The only "gotcha" I see is this line in the in KB66616 - "If you are going from 32-bit to 64-bit OS, or installing ePO to a different path, you must follow KB71078 instead"
Is that not true for me? I am migrating from 32bit to 64bit.
Also KB71078 says I can't do it if I have Drive Encryption, which I do have. Does this warning not apply to me since I am using the same Database and have ther ability to backup and restore the EPO files?
"IMPORTANT: Migrating of the ePO server is not supported if the ePO server also manages Drive Encryption/Endpoint Encryption for PC systems due to current DE/EEPC and ePO limitations." THAT note points to KB83186 which says it is only relevant if I am moving clients from one EPO server to another (which I don;t think I am technically doing since I have the same database)
Anyway, that is all very very confusing - I hope it's not just me who is confused by these three nested KB articles.
Starting with KB66616 -> which points to KB71078 due to 32bit -> 64bit transition, which has a RED BOLD warning about not doing it if you have Disk Encryption, but the article it refers to says they mean if you are moving clients from one EPO server to another, which I think I am not doing if it is a backup/recovery - Right? Either I am too dumb to grok it or the KB articles are contradictory and poorly written (probably a bit of both!)
I really do feel like I need to follow KB71078 because that is the one that talks about repointing the configration from "Program Files" to "Program Files (x86)" which I will need to do, right?
The one bullet point in KB83186 that concerns me the most is this..
- The Drive Encryption Product policy cannot be transferred from one ePO server to another because the policy contains the ePO Public Key for that specific ePO Server. Transferring the policy will result in the computer and Recovery Key being encrypted with the wrong key, removing the ability to perform a client side recovery.
I wish there were a statement on KB83186 and KB71078 that says none of this matters if you are going to migrate the DB too. It seems like these warnings only apply if you don;t intend to backup and restore the existing EPO server version and files. Like if you wanted to start fresh, but that is not what it says in the KB. It says that if I want to move from 32bit OS to 64Bit OS I have to use KB71078 and that KB says that it cannot be used when you manage Disk Encryption. I am starting to feel like maybe I should hire McAfee professional services and pay someone else take the responsibility. Losing the decryption keys for DE and also loosing the user self recovery data would be very very bad. It sopunds like that is what happens if you want to do a hardware refresh with EPO. And I have to be reading that incorrectly. How could you possibly expect to not be able to refresh EPO hardware?
This year, we had to upgrade our ePO server, since it was running on Server 2003. What we did instead, we stood up a new Server 2008 R2 server, with the latest version of McAfee ePO Server (5.1), and then we used the "transfer systems" functionality of ePO to start transferring machines from the old ePO server to the new one. Regarding the encrypted laptops (EEPC 6.2 and later), they will transfer, but the user assignments do not transfer. So, on the new server, we ended up turning on the "Add Local Domain Users" policy so that once the laptop was registered with the new ePO server, it automatically added the currently logged in user to the list of encryption users for that particular machine.
Details regarding transferring systems is available here: McAfee KnowledgeBase - How to transfer/move computers from one ePO server to another
We kept both servers up for a couple months during the transition period.
Also, if you come across a machine later that has not been transferred to the new server, you can just install the new McAfee Agent on that machine, and that will get it talking to the new ePO server.
You will need to follow KB71078. Migrating from x86 to x64 requires editing the Catalina XML files as the physical extensions are in a different directory path. This is also required if you change the install directory from C: to D: as these files point to the location of the extension.
I will be revisiting this KB in the coming weeks to provide a definitive definition of what "migrate those machines to a different ePO server" means.
KB83186 and KB71078 only apply if you do not intend on using the same database as no policies or client configurations are stored on the ePO Application server. I put the statement in KB83186 regarding transferring the policy to ensure that if one was to migrate to a new ePO database the policy will not be exported and imported like a VSE, HIPS, ect. policy can be.
The ePO Public key in the policy is used to encrypt the machine and recovery keys and is unique to the ePO server database and cannot be imported to a different ePO database. So exporting the policy from one ePO server to another would result in the client machines uploading keys encrypted using the wrong key. If using the same database, this is not an issue. All of the bullet points below "Issues after migrating" are there to warn of the potential impacts that can occur when transferring systems to a ePO different database and are real world scenarios. Again, none of these are applicable if using the same database.
The method that you are planning on using is a great method. Moving the database first and then moving the application server second is preferable as it increases the probability that a smooth transition will occur by splitting the time required and will simplify any troubleshooting in the event an issue arises.