EDIT 07-26-2017: PowerCLI 6.5.1 seems to fix this issue with connecting but you still may have issues finding some cmdlets, I don’t have the latest SRM so I can’t test the API.
I have been getting back into SRM scripting, this time with SRM 6.1. In a previous post, I discussed some strategies around how to size a SSO domain. In my case, I opted to have my protected and recovery sites in the same SSO domain. This actually simplified management of the domain with the web client since I did not have to login to each site individually (SSO handles distributing my credentials). There are some other issues around clutter when you have multiple SRM instances in the same SSO domain, but that’ s not the issue that I want to discuss.
In PowerCLI, there is a cmdlet called “connect-srmserver” that you use after you have done connect-viserver. Then you provide the cmdlet the username and password for the local and remote sites, at that point it will query the vCenter you connected to (as your local site) for the local SRM server. The cmdlet will then query the SRM server for the local and remote solution user (this is a SSO solution with format SRM-<uuid> or SRM-remote-<uuid>). The cmdlet will get the the respective PSCs for each site and then acquire a SAML token using the credentials provided. The SAML token will then be delegated to that solution user. This is an intricate authentication scheme which hard to debug (as I found out).
As you can see in the screenshot below, using connect-srmserver with the -user -password and -remoteuser -remotepassword flags results in an error
Looking at the logs on the remote PSC server, you see the authentication succeed and then the “Unknown@vsphere.local”. This “Unknown” account is a problem.
If you only authenticate to the local SRM server (only user -user and -password), the cmdlet succeeds but this prevents you from using some features of the APIs.
I started to look for the “Unknown” user by looking at the SSO solution user that is being used with SRM. As seen below, this can be obtained through getsolutionuserinfo() and getpairedsitesolutionuserinfo(). The paired site solution user shows up as Unknown
I also found the table in SQL that contained the paired site info and saw “Unknown” as well
I also cross-checked with all of my other SRM instances that are in shared site and saw the same thing. I logged into the VMware HOL and launched a SRM lab. The SRM lab used two different SSO domains and in that case the local user was SRM-<uuid> and the remote user was SRM-remote-<uuid>. What’s interesting in the shared-sso model is that vSphere client doesn’t have an issue, so either they put in the right logic in vSphere client to use the local SRM user twice, or they do sometime totally different. With the cmdlet and APIs, they don’t have that logic or they forgot to update the database.
What I ended up doing was to go to the SQL table (as seen above pds_solutionuser) and manually edit the User field and put the same local solution user name as the remote one.
I re-ran the connect-srmserver cmdlet and I connected fine
I also verified that the loginsites method (using the API) functioned as well.