One of the things that is not obvious about SRM is what type of permissions is required for account used to run SRM.Most of the documentation notes that you need Administrator in vCenter for SRM for at least pairing, but there is a lot of focus on roles and not the service account.
1)Account entered during SRM install: This account needs administrator rights on the corresponding vCenter in order to register with vCenter and for normal operations.
2)SRM windows services account (if configured)
This account is used if you want to run commands on the SRM server during a recovery and you require specific rights granted by AD. This may include updating DNS entries or running scripts against other servers. To change SRM to run as as service account, go to services, right click on the SRM service and change the account from “Local” to the service account of your chooseing, Restart SRM. This account does not necessarily need to be a member of the local Administrators group, but I preferred to have it there. For my case, it’s redundant since I have the service account as a member of an administrator ad group.
There is a nice blog post about using scheduled tasks to run SRM commands under a service account context. I haven’t tried it out yet so I’m not sure if you can pass SRM variables to the script or if it has to be a static
3)Account used to Pair Sites in SRM
One of the first configuration items is to pair the SRM servers together. This account seems to only be needed just for the pairing and doesn’t seem to be stored in the database (from what I saw at least) for future use. This account needs administrator rights on vcenter. Validate that the account shows up in the permissions tab in SRM (see image)
4)Account used to login to vCenter/SRM
SRM provided new permissions to assign to existing roles and sample roles for common tasks. That being said, use the account that you normally login to vcenter with.
5)Account used to login to SRM a Alternate Site
When you open up SRM you will be asked for credentials to the alternate site. Use the credentials that are assigned SRM privileged in the alternate vcenter. Often (within the same company) this will be the same account you logon to the first vcenter with. I’m hoping they let you SSO with the first credentials, providing the same account gets old.
OK, now that permissions are out of the way, here is the issue that I ran into.
I was able to pair the two sites together with my regular account from site a but not from site b. with the service account I could not pair either way.
The errors were similar to this KB
My account was a vcenter admin and I added SRM as a vcenter admin so I was confused. I also tried adding the a service account as a local administrator on the vcenter and the SRM server with no luck.
The early warning “canary” was actually an issue where my paired vsphere replication appliances were not being shown as paired in srm from site a but looked good from site b. support happened to saw that a site was not fully connected so I re-connected from site a to site b using my account. That fixed everything but I had decided that the service account should be used for that )which is where I found the errors)
Support was unable to determine the issue at the time at the time, but I spent a few hours googling after the family was asleep and I ran into this Kb.
It appears that SRM stores the administrators that have SRM access into the database. For some reason, this database was not in sync with what was on vCenter. Also on the Permissions tab in SRM, it did not show individual entries, it stated that permissions were inherited from vCenter and were not individually listed (at least from what I recall). Following the KB, I cleared the entires in the two tables on both SRM DBs and restarted services.
Now everything works as expected.
Pingback: Force Test of SRM Recovery Plan | Virtual Chris