I`m trying to migrate my ePO 4.6.6 to 5.0.0 using the upgradecompatibility tool to create the Migrate.zip file, but it's freezing with status "Compressing: 0%" in source server, and it doesn't go on. Cheking deeper, I've also realized which ePO services stop working after upgradecompatibility tool execution, is it normal?
Someone could help me with issue?
OS version and system type please?
will you upgrade on same machine or different one?
The OS is Windows Server 2008 R2 64bit, and I'll upgrade in a different server and sql database.
I have the same problem.
My EPO 4.6.6 server is a Windows Server 2003 32 bit. The Microsoft SQL DB is on another server, a Win 2008 R2.
I'm trying to use UpgradeCompatibility.exe, but it stops working with message "Compressing 0%".
I tried to restart, to update Windows, add disk space, but nothing helps. Also tried a username with same password on both server (EPO and SQL), but it fails too.
Maybe someone out there already faced and resolved this problem.
Did you guys figure this out yet? I am having the same problem.
I think this tool hangs when it tries to establish connection with SQL DB.Either any firewall blocking issue or tool was not designed if SQL is on another machine.I think some McAfee tool designer must have to explain it?
After a lot of work and efforts, I managed to install ePo 5.
I just installed ePo 4.6.6 on a 64-bit server folowing this article:
After that, I tried to upgrade to ePo 5, but it didn't work. After a week of yelling at McAfee, On the 1st or 2nd of May, (not the 29th of April like written), this technical article appears:
I followed it and have been able to upgrade to ePo5.
I suppose that if you have a look at this id="orion.server.https" in the server.xml file, you will not find it. Try to add it and launch again the upgradecompatibilitytool.
If it doesn't work, I can only suggest to move ePo 4.6.6 to the 64 bit system following the first article and then upgrade to ePo 5 directly on the new server.
Hope you'll have luck.
We had the same issue and logged a case with McAfee. Worked with a nice Tier 2 engineer who found out the issue was the missing line in the server.xml like you mentioned. Adding the line id="orion.server.https" before creating the migrate.zip worked on my test 4.6.6 ePO server. Will consider migrating the production server about a month after the first patch comes out for ePO 5.0. It is my policy to always wait for the first patch as I don't want to be an early adopter and can't risk McAfee issues in our environment.
They did say that they will add a check for the line in the next patch.
Or there should be one more like this?
Infact I am having this issue while updating from 4.6.1 to 4.6p6?
on 5/22/13 12:41:44 PM CDT
Thanks for the reply. I tried what was in 78121. The server.xml file was missing the attribute but adding it made no difference. I called McAfee and they told me that they are aware of the problem and that it is not going to work. They told me to follow 71078. What a pain. For me the source and target are named differently.
Why not pull the product if they know it is not working? Would have saved me some time with this. Watching the thread for awhile just in case someone comes up with a solution. Fingers crossed.