Showing results for 
Show  only  | Search instead for 
Did you mean: 

ePO 4.0 to 4.5 - Migration

Currently we have 4 datacenters and 2 epo consoles. 1 console for the datacenters in the US and 1 for the datacenters over seas. They are both epo 4.0. We want to upgrade to epo 4.5 and consolodate to one epo console. Here is the plan, can you guys weigh in on if this sounds feasible?

1) create a new epo 4.5 on new hardware

2) create new sql database on SQL server

3) place the new 4.5 epo server at one datacenter and have 3 distributed repositories, one at each of the other datacenters.

4) send new agents to all the managed endpoints so they report back to the new epo server

I guess that is the long and short of the design. I do have some questions though, assuming this design is sound:

1) Is there any other way to do a rogue agent detection other than have a rogue agent detection on each subnet? We have MANY subnets...

2) Do the distributed repositories send out agents to the managed endpoints or just DAT updates?

Do you see any issues with this plan?

Message was edited by: mbergin on 12/9/09 1:19:49 PM CST
7 Replies
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 8

Re: ePO 4.0 to 4.5 - Migration

The plan as you have outlined it looks fine (I'm sure you have all the missing details such as getting the correct policy sets in your new EPO server worked out).

The initial agent push cannot be done from a distributed repository; however, you can use Agent Handlers (AH) in EPO 4.5 to do this. An agent handler in a nutshell is the Apache and Eventparser service for EPO with no tomcat service (so it does not have a console). It functions like a distributed repository but it is also capable of handling agent-to-server communication. In EPO 4.5 when you push an agent you can specify which agent handler will do the push. If you decide to go with agent handlers I strongly recommend use use MA 4.5. MA 4.0 does not know to check for additional handlers so if it fails to connect to the first handler it tries it does not know (unlike MA 4.5) to check for another handler thus requiring a re-push of the agent to restore agent-to-server communication.

If you do not wish to cover all subnets then an alternate method is to install an RSD sensor on all DHCP servers and set the sensor policy to monitor DHCP requests. This has the downside of not detecting machines with a static IP (because they never make DHCP requests) but you do not have to install a sensor on all subnets.

Re: ePO 4.0 to 4.5 - Migration

Thank you so much for the information!

Would you suggest that I make the DR's at the other DataCenters AH's as well, at least for the agent push? Is there any difference between an AH and a DR, other than being able to push software?

I read about the Rogue system detection and it seems to be needed on all subnets. We don't really need that, all the servers we create have ePO agent installed via the image and they all join a domain. Various domains, but at least a domain.



McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 8

Re: ePO 4.0 to 4.5 - Migration

The differences between an AH and a DR are significant. To be clear you can deploy software from a DR via a deployment task but you cannot push an agent from a DR that must be done from an AH (the ePO server itself has an AH installed). The primary difference between the two is that in addition to functioning as a DR an AH ALSO handles agent-to-server communication.

As the installation/maintenance/configuration of an AH is a bit more involved than a DR I would recommend keeping the number of AHs on your network to a minimum.


Re: ePO 4.0 to 4.5 - Migration

Hi Jeremy,

I'm planning to do more or less the same migration (epo 4.0 to 4.5). But before doing that I'd like to ask what is best practices actually to it?

according to my plan, the scenarios are:

1. build new server with win 2008 R2

2. install epo 4.5, create new SQL DB, and move all policies and tasks to that server.

(is there any way to export policies from old server and import them into new one?)

3. create new Framepkg.exe and replace the old one (Framepkg.exe is being deployed via GPO) to let client be pointed to the new server.

4. move site by site clients into new epo server.


1. Disconnect current DB.

2. create new server with the same IP address and hostname (which is difficult, because at the moment epo 4.0 server is virtual, and I'm planning to move it to physical. but virtual and physical environment has different vlan's)

3. install epo 4.0 on new server, connect old DB to it.

4. upgrade epo 4.0 with epo 4.5

Your help in this issue is very appreciated!

thanks in advance,


McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 6 of 8

Re: ePO 4.0 to 4.5 - Migration

If you wish to retain all of your current policies/settings/system tree structure/etc rather than starting from scratch then I would recommend migrating ePO 4.0 to a new server then upgrading to ePO 4.5. Instructions on migrating ePO 4.0 can be found in KB51438:

To answer your question yes you can import/export policies (the option is in the policy catalogue); however, this will only import he policies to the new server it will not keep the same assigments so you would then have to go and re-assign all of the policies.


Re: ePO 4.0 to 4.5 - Migration


I have a question about migrating ePO 4.5 server to new hardware with new IP and new name. I tried it as McAfee described in KB66616 (install new ePO server on new hardware, with the same patches as on the old hardware) and KB66620, but still fails on two last points 😕 At first I cant get RunDllGenCerts working (but have done everything as is written in KB). OR at the second, when the RunDllGenCerts works (1 from 10 attempts, some miracle or what), I got many faults on the logon screen to ePO console than and, of course, can not log in.

What am I doing wrong?

Thank you for help.

McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 8 of 8

Re: ePO 4.0 to 4.5 - Migration

Its hard to say for sure without knowing the exact error messages but I think I have an idea of what is going on.

If you look closely at the RunDllGenCertscommand it is essentially making a console connection to ePO (which is why you have to provide it your ePO console logon). If you cannot logon to the ePO console this command won't run successfully. Now the other problem you mentioned (unable to logon to the ePO console) explains why you cannot get the RunDllGenCerts command to complete.

For the logon issue I can only guess without seeing the orion log but most likely you did not retain the same installation path when you moved ePO. For example if you migrate from a 32-bit to a 64-bit OS the install path will be different (on the 64-bit OS ePO will install in the "Program Files (x86)" directory as opposed to just "Program Files"). Or possibly you are trying to install EPO on a different drive like the "D:" drive because you are running out of space on the "C:" drive.

If the install patch changes at all then you will need to manually edit the .xml files in the following directory so they have the correct absolute path: <ePO install directory>\Server\Conf\Catalina\localhost

If that is not helping then restart your ePO services and post a copy of your orion.log taken immediately after the services restart so we can take a look. The orion.log is located here: <ePO install directory>\Server\logs\

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community