I was recently asked by a client to assist with migrating their current VMware Site Recovery Manager 5.1.1.7655 from one database server to another. As I’ve done this in the past a few times, I figure it wouldn’t take me much time but to my surprise it too much longer than I thought so I figure this warranted a blog post in case I run into this again.
I began by backing up the production SRM database to a BAK file, recreated the SQL Authentication account on the new SQL server, then restored the SRM database. As I wasn’t the consultant who deployed this instance of SRM, I noticed that the database’s schema and owner was set to dbo and not the service account. What the person who deployed SRM had done was simply make the service account an sysadmin on the database server which I figure I’d take the opportunity to correct so I used an old blog post I wrote for SRM 4:
Recovering / reinstalling SRM (Site Recovery Manager) 4.1.1 after suffering a host failure
https://blog.terenceluk.com/2011/10/recovering-reinstalling-srm-site.html
… to configure the schema and service account as per the following VMware KB:
Connecting to VMware vCenter Site Recovery Manager fails with the error: Unable to start Site Recovery Manager Service (1027973)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027973
The database schema has three requirements:
- It must be owned by the SRM database user (the database user name you supply when configuring the SRM database connection).
- It must be the default schema for the SRM database user.
- The database schema name must be the same as the database user name.
Then reconfigured the ODBC connector to point to the new SQL server but quickly noticed that when I try to start the VMware vCenter Site Recovery Manager Service service, I receive the following error:
Windows could not start the VMware vCenter Site Recovery Manager Server service on Local Computer
Error 1067: The process terminated unexpectedly.
Unfortunately, the event logs doesn’t provide much more information than an Event ID: 7034 error with the message:
The VMware vCenter Site Recovery Manager Server service terminated unexpectedly. It has done this 4 times(s).
What was strange was that if I made the service account a sysadmin, the service would start:
After combing through setting after setting between the two SQL servers and not finding any differences other than having configured the service account the correct way, I noticed that when I browse the restored database properties on the new server, navigate to the Files page, the Owner field was blank:
Attempting to assign the service account would fail because it indicates that account already has the mapping. So I went ahead and removed the database mapping from the service account’s properties then went back into the database’s properties to assign the owner as the service account and this time it worked. Reviewing the User Mapping tab now shows the following:
It’s a big strange that the screenshot above lists the user and default schema as dbo while the Owner for the database properties is listed as the service account:
… but the service now starts:
I explained the situation to the client and proposed that it is possible to try and reconfigure the mappings back to what we expect it to be and try a SRM reinstall mimicking a server loss issue but the client was ok with the current configuration for now.
Hope this helps anyone who may come across such a situation and unable to actually perform a reinstall of SRM.
