look inside DB Properties in "Program Files (x86)\McAfee\ePolicy Orchestrator\Server\conf\orion\db.properties for db.param.ssl=xxxx we don't use SSL and our is set to "off"
also make sure the tools.jar is present.. another thing I can suggest do new setup and transfer assets between 2 epo servers.. I had to do that after wasting week with support and no resolution.... see me other thread for the link to mcafee KB on how to transfer assets between epo servers.
Thanks for the reply.
re: dp.properties, unfortunately mine also says db.param.ssl=off in that particular file. But when the upgrade is running, the ultimate error is that it can't connect to SQL using SSL, which we don't want it to do and haven't asked it to.
re: tools.jar, there is no path to it - ie. C:\PROGRA~2\McAfee\EPOLIC~1\lib\ doesn't exist (the \lib folder doesn't exist) so not sure if this is a remnant from a previous version and an ignorable error.
I saw your post earlier about migrating to a new server, and it is something I have done myself at least once over the years of working with ePO. I am keen to avoid doing it if possible as our agents are distributed and many don't connect for weeks on end, so I would need to run both versions side by side to ensure the agents receive the move server command. I would prefer to get this in-place upgrade completed successfully and keep the migration option as a backup plan.
I've opened a case with support so if I survive that without throwing myself off the top of our building I will report back....
Any other thoughts or advice please!!!
During my testing I had turned off SSL in ePO and was able to go through an upgrade for testing. I had done another step too though in that I had gone to my MS-SQL server and disabled SSL there too. If you have it enabled there the installer might be detecting it and trying to shift your installation to SSL. So you can try disabling it on the MS-SQL server and restarting the services if it is enabled.
Also why don't you want to use SSL between the systems? There's a lot of organizational sensitive data being stored and shifted back and forth between the two systems, it's definitely better to have it encrypted.
Thanks brentil. How exactly did you disable SSL on the MSSQL server?
I'm very happy to use SSL between ePO and SQL, but as the MSSQL server hosts other databases too, to implement that would mean dealing with the bureaucrats and other application owners - and I think i'd rather spend an eternity on the phone to McAfee's Indian call centre than deal with the bureaucrats.... although it is a close call!
It's not an all or nothing when it comes to SSL, you can enable it on MS-SQL but not force it so that then you can talk in via SSL or not use SSL at the same time.
Check status of SSL in MS-SQL;
If there is an SSL certificate listed but your ePO still can't talk to it correctly as you're finding then the issue could be if the SSL certificate is self-signed or Domain signed and your ePO doesn't have the Root/CA cert in its store. You'll have to then update ePO to include a Root/CA for it to authenticate against.
So in SSCM I have no certificate listed, and none in the drop down box available to choose. After investigation, the reason is that the certificate(s) on the SQL server from our internal CA don't have the AT_KEYEXCHANGE keyspec set. Which is fine, and if I do choose to go down the SQL SSL route I will issue some new certs that meet the requirements, and enjoy some encrypted SQL transport fun!
But right now - my SQL server does not do SSL, it has no certs that even meet the requirements for SQL SSL, current ePO does not use SSL (obviously), I don't want new ePO to use SSL, so why is it trying to use SSL and not falling back to non-SSL?
That is the question anyway. I have a support case open now, will report back with an update when there is one.
Thanks all for input so far.
Well, according to the support:
You may ignore the RSA compatibility check failure when running the ePO Pre-Install Auditor tool. the upgrade will be successful without SSL connection to SQL server.
which doesn't make sense, because I DO use SSL connection.
Anyway, I was about to start the upgrade (with tons of backups, clones and snapshots), but got stuck with some not supported extensions (such as MOVE AV 3.6.x and etc).
So while rooting around in my Grant area I noticed there was a newer version of the PIA tool. PIA 126.96.36.1990 which was released April 26th compared to PIA 188.8.131.520 which is what was released when ePO 5.9 was released. When I run it now I no longer get the error related to SQL Server system RSA compatibility. As several of us had stated before this was just an issue in the PIA tool and not the ePO 5.9 installer so it looks like they resolved it there too.