Did you get a resolution to this issue?
I have the same issue, have you figured out a fix?
I would suggest filing a SR with VMware and providing SRM and vCenter support bundles.
As a tip - what format do you use when logging in using your AD account - user@domain or domain\user? Have you tried logging into vSphere Web Client using both formats? Sometimes there are issues normalizing the account format across authentication systems.
1 person found this helpful
This is a bit strange but it started working after I logged onto both Vcenter web clients at same time.
You saved me Daniel! I had the same problem and your solution fixed it for me. Thank you!
Does the pairing work if you are logged into web client as the SSO user or any user from the SSO domain?
If yes, you need to change the Identity Source from IWA to AD as LDAP due to the fact there is some socket timeout with IWA as identity source.
Not an issue from SRM, It's something from the identity source.
Go into Navigation | Site recovery | Site and take either your Protected or Recovery site view and check which side of the SRM is NOT connected
Then on the NON connected site, relaunch the VMware vCenter Site recovery Manager Server service
I have SRM 6.1.2
As this happened only once in 1,5 years and we had an intersite network issue I'm not going to dig any deeper right now.
Thanks ! you solve my problem too.
After restart services SRM server on Services Win Svr and refresh on SRM Website, this site is automatically Connected on both Sites !!
I got the same error too and wasn't able to run any recovery plans or recovery plan tests as all the options at the recovery site were greyed out.
I also saw the same error message about the login creds being invalid at the recovery site.
What we did was login to each site individually and saw no errors in that process. Following that I logged out of the VC session and logged back in and then the message was no longer seen. It seems like some creds are cached which could be causing the issue. No services on the SRM servers were restarted no any changes made to the Identity sources in the two sites.
Does anyone know what might be the root cause of this issue?