I've had exaclty the same problem in my test lab with one difference, I cannot login to the ePO 4.5 server anymore, the login screen shows numerous messages below the login box indicating that the EPO application cannot connect tothe SQL DB.
I'm not using the full blown SQL but the one that comes with the ePO 4.5.
You should try to log onto https://your_epo_Server:8443/core/config and have a look at this page to see if everything is OK. Then you just need to write again the password for ypur DB user, test connection and save. Have also a look to your e epo services and see if they are running
Are you using an SQL user within your ePO or is it a domain user?
You can try to launch C:\VSE880LML\ePOPolicyMigration.exe > log.txt and then have a look at the log to see if you can see anything else
The database account is a local SQL account on the SQL server. Since I don't provide the account to the tool, it seems to be able to grab the username from an ePO .INI file. Obviously, I'm passing the password using the password switch
I did pipe the information out to a log.txt and copied it in the orginal post.
Using SQL authentication: username:\!sqladmin_01
OpenDatabase error: 80040E4D ?
That seems to be a generic login failed message based on a google search. But the account and password work fine when tested in ePO. I can also directly connect to SQL with the account using the same password.
Is SQL on a different sever to ePO?
I've managed to get further with this issue with similar message on screen, and the account used by my epo to connect to SQL was a local account and it turned out the account was locked out in SQL.
This did not resolve the issue completely, somehow the port number used by ePO was different so I changed it back to the default 1443 and this works.
Now to go and try the migration again!
I had the same issue as stated before and I've resolved this now.
The issue was with the account used by the ePO to connect to the SQL server. This account was a local account setup in SQL and I found that the account was locked out in SQL. Unlocked the account and this resolved the issue.
A good test is to load up the epo core/config page test yuor account. There may also be an issue with the port number used to connect to SQL, for this you will need to do more checking on the port number used by SQL (SQL Server Configuration Manager TCP/IP settings).
BUMP this for any more ideas or thoughts, as I run into the same issue.
ashman - Where did you go to "unlock" the account on the SQL server?
Got this to work after realizing that the AD account that I was using on the ePO server didn't have access to the SQL Database. Even though the SQL account was correct, I had to use an AD account that had access to the SQL Database.
I hope this can help someone else down the road.
Message was edited by: sparkdragon on 2/17/12 2:36:45 PM CST
After re-reading my above post, I wanted to clarify for future readers.
I was getting the error that the OP mentioned when I was logged into the server that hosts our ePO with an AD account that had insufficient rights to the SQL database. It didn't seam to matter that I had provided a proper SQL account and password. Once We logged back into the ePO server with and AD account that had access to the SQL database, we were successful in running the epopolicymigration.exe tool.
That was long winded, but I hope this is more clear.