This is another story fresh from the field- luckily one with a happy ending.
I was engaged on a fairly quick project to migrate the internal VMware and Horizon View databases from a default SQL Express instance to a new SQL server that the client built and configured. This is something that I’ve done many times in the past, and has routinely gone to plan.
It’s important to remember that every every environment is unique. This particular environment required an additional hour of time to get View Composer back up and churning out ReFit operations! As in most things, but particularly advanced IT work…. Prior results don’t guarantee a repeatable checklist!
The process we took for the database migration was as follows:
- Create a backup file on SQL Express.
- Back up the View Composer database in SQL Express.
- Rename the backup file and transfer to network storage/C$ drive of the new SQL server.
- Create a shell database in SQL on the destination machine.
- Restore the Composer backup OVER the new SQL database.
- Create a new SQL account and make it owner of Composer database.
- Repoint the Composer DSN on the machine running View Composer using SQL account credentials.
Seems pretty simple, and has worked many times in the past. This time as I said, things didn’t go to plan.
After the migration, going into Services and trying to restart the View Composer service gave an error. In the logs for Composer, I saw that it was trying to connect with the old DSN name and blank credentials.
I checked the DSN, and retested the connection – Correct credentials, and the test was successful as expected. Where is Composer getting this info?
Turns out, I needed to change another thing in this environment.
I needed to follow this KB to edit the SVIWebConfig, substituting sane values for our environment:
After performing the above, Composer started and all was well with the world.
Then I had to migrate the vCenter databases and ran into another weird DSN problem… which will be the subject of another Blog post!