I have tried to keep this as high level as possible, so please bear with me! I have reviewed some posts in the community forums and also looked through some KB articles, and will shortly be in a position to test the upgrade process, however I have found nothing that seems to completely match my requirements.
We are currently running an ePO4.0p7 server on Windows2k3 with a local SQL 2005 Workgroup database. We are planning to upgrade to a new ePO server with a new server name and IP, and also looking to upgrade VSE (8.5 to latest) and HIPS (7.0 to latest). The new server will be running Windows 2k8 R2 and SQL Server 2008 R2.
The simplest technical upgrade path I can see would be to essentially start from scratch, and treat the new ePO server as a complete fresh install. The (very) high level plan for this would be:
- install new ePO server
- install old and new extensions and packages for VSE and HIPS (to later migrate policies)
- export current VSE and HIPS policies from old ePO server and import to new server
- migrate older policies to newer policies (epomigrationtool for VSE, and server task for HIPS)
- install old extension and package for mcafee agent on new ePO server
- export current agent policies from old ePO server and import to new server
- update agent extension on new ePO server and check in newest agent package
- push out agent from new ePO server and then deploy updated VSE and HIPS software
The above ignores the actual policy assignments to the system tree for now, which I imagine is going to be the part of this that requires the most work, as there is a lot of broken inheritance.
The harder technical plan would be to install the current version of ePO and SQL Server on the new windows server, and then run with a backup and restore. The problem here would be with the required change in name of the server - if we restore the database to a server with a different name, there will likely be problems with certificates, and the agents will still need to be repushed. However it would make the job of working through the policy assignments that little easier. After this restoration we could then follow through the normal upgrade path for ePO and endpoint software. So, high level plan again:
- install new ePO server (existing ePO 4.0 and SQL Server 2005 version running on new server)
- backup old ePO server and restore to new server (KB51438). Restore includes all existing old endpoint software
Note that the new ePO server install of 4.0 would need to be installed directly on to Win2k8 (and not win2k3 followed by an OS upgrade) due to internal standard OS image requirements.
1) this is where I get confused. For ePO4.5/4.6, a backup/restore that involves a server name change leads to KB66616, that then
leads to KB66620. However, KB51438 doesnt mention any other KB in the case of a server rename - does this imply that the above two
steps will essentially work as is (if the agents are repushed)?
2) I can imagine an added complication comes as per KB71078, as we will be also moving from a 32-bit to 64-bit system, however that article applies to 4.5 and 4.6 - will it work for 4.0?
3) Are there any other major concerns with the two above options that people can think of?
Any further info or clarification required, please let me know.
Currently trying to follow through https://community.mcafee.com/thread/44787 - the KB mentioned in there appears to point to a cluster migration article, but from the sound of the post, it looks to have worked.
As I was planning on migrating the ePO4.0p7 server to a new server before the upgrade (so the original DB can be kept and upgraded
by the ePO upgrade process), I was following through KB51438 (which does imply that if the IP and hostname are changing, the only
caveat is that agents need to be repushed...). I run into the following error on trying to restore the database:
Strangely enough, my search came across https://community.mcafee.com/thread/34184, which I didnt pick up in my original searches,
and this included a comment from Joe:
"However, if they are intending to move ePO to a new server with a different name, then this will cause a problem."
I can confirm that the SQL server is running on the same server as the ePO server. After a further search on the error I came across:
The article seems to imply that this can be fixed quite easily, but I believe that the example used is actually a backup of the same
database using a different backup name... However further links, such as the below seem to all point to the same fix (and the first
one confirms the option to be selected when using Management Studio)
So... as I have snapshots in my VM environment, I gave that a bash, and the restore completed successfully... and then... Unable to
log in to the console (and many many extenstion initialisation errors)! Checked out KB60112, KB51670, KB60112. Didnt check out
KB53607 as this is a *small* test DB. Didnt check out KB53461 as there is over 8G of drive space left.
I can confirm that ePO and SQL Server are the exact same versions and were installed to the same directories as the original ePO
Coming back to Joes comment above, is what I am trying to do actually possible, and if so, what mix of articles should I be looking
at to get this done. Note that I have the constraint of the original server remaining untouched. I also have a limited amount of
time for this, and would appreciate thoughts/recommendations of moving forward with the possibly administratively burdensome task of
simply building a new ePO4.6.2 server and rolling out from scratch (obviously the policies etc can be exported and imported, but the
assignments may take a while longer!)
Still looking into further...
A test from https://localhost:8443/core/config resulted in:
test failed: cannot open database "epo4_EPO2" requested by the login. The login failed.
When testing with invalid credentials, it advised that authentication had failed, so this looks to be a DB access issue.
DB properties (general) showed EPO2\Administrator as owner, maybe because it was this user who restored the DB?
Starting again, tried to restore using eposqladmin DB user, but this user didnt have rights to the backup file, so:
1) restored when logged in as Windows Admin (Windows admin took over the DB)
2) ran " SELECT DB_NAME() AS DataBaseName " in Management Studio to ensure that active DB was ePO DB
3) ran " EXEC sp_changedbowner 'eposqladmin' "
4) confirmed owner had changed by looking at db properties
And can confirm that this has appeared to work. I have an operational ePO server with a new name and IP using the previous database. Policies are there, policy assignments are there. Still a number of tests to do, but looking good...
I will mark this answer as helpful so anybody in the same situation can check it out and maybe contribute with experiences. I am gathering that I dont get any points from marking this as helpful myself 🙂