The same happened to me, please somebody help us...
Has anyone found a solution to this as I have the same error
FYI these type issues occur for one a of few reasons...
1. You Renamed the ePO Server.
2. The install truly never created the Apache SSL certs on install, (due to problems with the RSA SDK).
3. You are running another application that is using CRYPTOCME2.DLL and CRYPTOCME2.SIG. (Do a search for these files, they should only exist in the epo servers install path).
4. You restored another ePO Servers Database to the Current ePO Server you are working with, OR you pointed your current ePO server to another existing ePO Servers Database.
The important thing to know, is that the Certs are unique to each server, and that they are stored in the Database. Also that the ePO Server is really an Agent Handler, so if these values don't match then your server will never, Process ASCI's from client machine, Perform Push Agent Installs, Perform Wakeup Calls to agent machines, or Be able to perform the Ping function (via the epo console) to existing managed machines.
If you can tell me what scenario you are dealing with I can tell you who to fix the problem.
Senario is this - we had a Windows 2003 Std server within a domain, fresh install, Windows 2003 R2 with SP2, .NET 2.0 install with MSXML 6.0 I completed a sucessful install on this server but it died about two days later. I then wiped the machine, re-installed the OS as above but ePolicy Orchestrator never sucessfully installs. NOTE: this new server has same IP address and name, and has the same PUBLIC IP address, always install fails at the point of generating the SSL certs and so apache does not start as the SSL.crt it is expecting are not in the SSL folder within apache. Spoken to support but they seem stumped
Any help greatefully recieved
Do a search for the CRYPTOCME2.DLL and CRYPTOCME2.SIG on that machine. If they exist anywhere besides the epo install dir (and possibly the Mcafee Agent Directory), then another vendor has loaded the RSA crypto files as well. Certain Versions of Dameware and EMC Powerpath use a different version of these DLLs and have been know to break our agent and ePO server install.
One thing to try is putting our version of the CRYPTOCME2.DLL and CRYPTOCME2.SIG into the Windows\System32 folder. Reason being is that the Path statement of your machine will load our version first if you place our version of the RSA libraries in the SYSTEM32 folder. (NOTE: this could break the other vendor). Thus the install should complete as it can now create our SSL certs using the version of RSA we require.
The reason we don't do this by default is we attempt to be friendly to other vendors by placing our files, in our McAfee folders only. Some other vendors will add them selves to the path statement or place there versions in the WINNT\SYSTEM32, instead of calling it from there install paths. Thus causing issues for any other App that may need to use a different version of the RSA SDK modules.
If this work around still fails, you will need to run the Setup with a Special switch for support...
Note: this command is case sensitive and will put your passwords in plain text in the install logs. So be sure to change them ahead of time to something your not concerned with sharing to us. Or just change your passwords when your done testing/troubleshooting. Personally, I do both as changing your passwords on a regular basis is just a good security practice.