I was looking through the 4.5 installation guide's instructions for upgrading from 3.6.1 (page 18) but didn't see any reference to a cfgnaims.exe file. Could you give me a summary of what this file does?
In ePO 3.6.1, this file is where you set where is your database server and which account you will want that ePO use when accessing the database.
In ePO 4.0 or 4.5 this file doesn't exist. The same configuration is done by accessing https://YourEPOServer:8443/core/config
Hope this helps.
Thanks again, Bruno.
It has been many years since I last setup an ePO server and just couldn't recall what that file was for. I appreciate the explanation.
I finally got time with our DBA to attempt to migrate the database from 2000 to 2008. After he copied it and restored it to the new 2008 server, I ran the cfgnaims.exe file and pointed it to the new 2008 server. Since the new database server has a different password, I made sure I reflected this change in the Account Details for both the Administrator and Reviewer accounts (we use SQL Authentication for these accounts).
I closed out my 3.6.1 windows and logged back into the app and all looked well. I wasn't yet convinced that I was really pointing to the new database, so I rebooted our ePO server. After rebooting, I am unable to log into ePO. I get the generic message that gives you some things to check such as being sure it is turned on and that you used the right p/w. If I then use cfgnaims.exe to point back to the old database, everything works fine again. If I use cfgnaims.exe to point to the new server, then everything still APPEARS to be working until I reboot the epo server which results in my being unable to log in again.
Our DBA and I found KB58843 in which we found reference to changing the server name in the registry. This did not have any effect either. I'm not too surprised since there is also an entry in the registry for the p/w. But since this entry is encrypted, I don't see how we would be able to change it.
So, any ideas or suggestions?
ePO 3.6.1 does not support SQL 2008 so an upgrade will not work that way.
To Upgrade directly from ePO 3.6.1 to ePO 4.5 the only option is to use a full SQL 2005 server.
Another way would be this one:
- Update ePO 3.6.1 to ePO 4.0
- move DB to SQL 2008
- Update to ePO 4.5
- Update database with ePO 3.6.1 to SQL 2005
- Update to ePO 4.5
- Update DB from sql 2005 to 2008
Thanks for the reply, Tom. I was afraid that it was going to be a two-update process. But, I've got another idea to suggest. Since my current 3.6.1 ePO server is virtualized, I'm thinking of building a brand new 4.5 virtualized ePO server, copying the existing SQL 2000 database to the new 2008 SQL server, then shutting down the old 3.6.1 ePO server and pointing the new 4.5 ePO server to the updated database. I'm guessing that I'll have to be sure that after shutting the old 3.6.1 ePO server off I'll have to rename the new 4.5 ePO server with the same name as the old 3.6.1 ePO server. I'll also give it the old 3.6.1 ePO server's IP address.
How does this process sound? Am I forgetting anything?
This is not possible as you must upgrade an ePO 3.6.1 with its database.
In this process the database is changed so a restore of an ePO 3.6.1 to any other version of epo is not possible.
This does also apply to different patch versions.
So you must upgrade the ePO 3.6.1 to ePO 4.5 before moving the database to a new server (and even this is complicated if you want to change the servername because epo 4.x uses certificates) ...
copying the existing SQL 2000 database to the new 2008 SQL server, then shutting down the old 3.6.1 ePO server and pointing the new 4.5 ePO server to the updated database.
You can't just copy the DB from one version to the other- you have to perform an upgrade of ePO on the DB so that the tables etc can all be upgraded.
When i upgrdaed from 3.6.1 to 4.5, I just created a new VM with ePO 4.5, imported my policies and redeployed the agent for the new server. All my clients installed the new agent (version upgrade) and appeared in the new console.
May be easier in the long run. You have to determine what is best and easiest for your environment.
We will be facing a similar issue to you soon. Our ePO 4.0 server will soon be upgraded to either ePO 4.5 or the just released 4.6. Luckily for us that we are going to migrating it to a VM in the next few months. That will make it easier to recovery from upgrade failures due to snapshots. Our ePO 4.0 is using MSDE.
We plan on doing the following steps:
1. Install SQL Express 2005.
2. Migrate the MSDE backup to SQL Express 2005.
3. Detach and unistall MSDE.
4. Wait a few week to makes sure that there are no issues with EPO 4.0 & SQL Express 2005 database.
5. Upgrade to either EPO 4.5 or 4.6.