I performed a Bigfix Server Migration last night, and it failed. A migration is basically a new install, but you copy key directories from the old server, and point to the old database during the install. I use a remote DB, and the Bigfix version being installed is 9.5.13.
I was worried during the install that things were not going correctly when I was prompted to change the SA password during the install. Then at the end, the following error appeared.
Database Error
The database appears to be in an inconsistent state. Please contact your support representative.
Database Error: [Microsoft][SQL Server Native Client 11.0][SQL Server]Cannot alter the login 'sa', because it does not exist or you do not have permission. (37000:15,151)
Is this error because of inadequate DB permissions?
I am using a service account to perform the install. The account has DBO permissions. I know the instructions say use ‘sa’ equivalent permissions. What exactly does that mean? It would be nice to have pictures in the instructions. Does it mean that the role has to be sysadmin, as well as, DBO?
After working with support, it was determined that the problem was that the databases did not have sysadmin privilege. It would be nice to have a better error message, and a recoverable install. I rolled back the migration because I didn’t know the state of the DBs.
Now I know to look for the sysadmin role on each DB. The DBAs seem to want to keep removing it. Then they think they always know better. I will check before every install or upgrade.
When you get that SA dialog, I’ve found that you can ‘X’ out of it to finish the install. The key next step is to open the Administration tool post-upgrade. When you do, it will automatically check the database schema version. Likely it is downlevel. It will automatically bring it up to the proper schema for the version you installed. (Be sure to be logged on with an account that has DBO privileges when you run the Admin tool.)
I’ve encountered that problem several times with various version upgrades with remote database over the years. The process I described has worked fine for us on those occasions. I have that documented internally for our junior admins.