vCenter 6.7 Cross SSO Domain Repointing

By | April 17, 2018

It’s back, finally! A new feature with vCenter 6.7 is the ability to repoint a vCenter Server to another Platform Services Controller node, that resides in an entirely different vSphere SSO domain. This functionality is huge for domain consolidation, and also domain splitting (which admittedly is a less required use case from what I’ve seen, but something that still can be a useful use case).

Edit: As per a comment from Rupak, I believe this feature is only available on the vCenter Server Appliance and is not available for the Windows deployment of vCenter 6.7. With that said, hopefully if you are running vCenter 6.7 you are now running the appliance, as you have likely had several chances to migrate to the VCSA either using the migration tool, or manually (albeit with plenty of scripts to assist with the move of config and workloads).

I say new, but really I should say returned, as this functionality was available to vSphere administrators in vSphere 5.5, and has been a pain point of versions 6.0 and 6.5 of the product as it constrained the ability to consolidate or split without building new vCenter Servers, based on business requirements or consolidation of IT resources within an organisation.

After a cross-domain repoint, services such as tagging and licensing are migrated to the new Platform Services Controller.

In the post below, I’m going to take you through the process of doing a Cross SSO Domain Repoint of vCenter Server 6.7.


I’m going to use a straight forward example here, where we have two fictional companies; Company A and Company B. Yeah, original aye! We have two SSO domains (companya.local and companyb.local), and each SSO domain has one PSC node and one vCenter Server.

Company A has acquired Company B, and the IT team has decided to consolidate the deployment, and wish to repoint Company B’s vCenter Server (companyb-vc01) to their own SSO domain (companya.local) and PSC node (companya-psc01).

Here’s a basic diagram of the environment prior to any changes:

And he’s the desired end state we are trying to achieve. I’ve still put Company B’s PSC node in the diagram, as this would still exist after the repoint and would need to be decommissioned manually to complete the process, if that’s the desired outcome:


  • Cross domain repointing is only supported with Platform Services Controller 6.7 and vCenter Server 6.7
  • Each vCenter Server and vCenter Server node must be in a healthy state
  • To ensure no loss of data, take a snapshot and/or backup each node before proceeding with repointing the vCenter Server or Platform Services Controller
  • If vCenter High Availability is in use, this should be disabled prior to the repointing, and can be re-enabled after a successful repoint
  • The repointing supports external deployment models only. You can repoint an embedded vCenter Server to a PSC in another SSO domain, but you first need to externalise the embedded deployment

Pre-check and Conflicts

So by now you might be thinking about conflicts. What if there are objects in the destination environment that are the same as the source environment? Thankfully VMware have thought about this and they provide the option to run a pre-check for conflicts.

The pre-check mode fetches the tagging (tags and categories) and authorisation (roles and privileges) data from the Platform Services Controller. Conflicts can be checked for tagging and authorisation data. The Pre-check does not migrate any data, but checks the conflicts and writes them to a JSON file.

The JSON file can then be reviewed to see if there are any conflicts and if so, an administrator can provide detailed input on how to handle various conflicts.

I’m planning to do another post on this section, or edit this section of this post with more information on how to handle the conflicts, but in summary there are 3 actions you can pick for the conflicts. The examples below are specifically for roles, but these actions are valid for all conflict types:

COPY. A copy of the conflicting role is created in the target Platform Services Controller, with –copy appended to the role name. The new role is created with a new role ID with the same set of privilege IDs. The new role ID is updated in the VPX_ACCESS table. The new role ID is applicable for both role name conflict and role ID conflict.

MERGE. The MERGE option is resolved in the following sequence:

  1. If the source Platform Services Controller has a role with the same name and privilege list as a role in the target Platform Services Controller, but the role IDs are different, the role ID from the target Platform Services Controller is used and updated in the VPX_ACCESS table.
  2. If the source Platform Services Controller has a role with the same name as a role in the target Platform Services Controller, but with a different privilege list, then the privilege lists for both roles are merged

SKIP. Do nothing. The specific role is skipped.


To perform the repoint, we can use the cmsso-util command with the domain-repoint option. The mandatory arguments are listed below:

Mode can be pre-check or execute.


This is the SSO administrator user name for the source Platform Services Controller. Do not append the @domain, just state the username.


The FQDN of the Platform Services Controller to repoint the vCenter Server to.


This is the SSO administrator user name for the destination Platform Services Controller. Do not append the @domain, just state the username.


SSO domain name of the destination Platform Services Controller.


The FQDN of the vCenter Server pointing to a destination Platform Services Controller. The vCenter Server is used to check for component data conflicts in the pre-check mode. If not provided, conflict checks are skipped and the default resolution (COPY) is applied for any conflicts found during the import process. This argument is optional only if the destination domain does not have a vCenter Server. If a vCenter Server exists in the destination domain, this argument is mandatory.

So, coming back to our example, I’m going to log in to the vCenter Server and run the following command:

We get prompted for the source and target PSC administrator passwords, and then get the following warning and information screen. Please take a few minutes to actually read the warning, it’s important.

There’s also a prompt asking if the settings are correct and do we want to continue:


After proceeding with the repoint, the tool will go through various steps to export and import the data / services in to the target SSO domain and repoint the vCenter Server. We’re given a breakdown of each stage with a status of Done or Failed (I believe). In the lab on a brand new deployment, the repoint took around 15 minutes. Obviously YMMV and this is might be longer in a production environment with actual data within the environment.


Things are looking good and the repoint was successful. If I go ahead and log in to the vSphere Client on either Companya-vc01 or companyb-vc01, I can see that these two vCenter Servers are now in Enhanced Linked Mode with each other, and when looking at the Deployment > System Configuration section of the Web Client, we can see there are now 3 nodes in the topology – 2 vCenter Servers and one Platform Services Controller as per the diagram further up in the blog post.


Companyb-psc01 still exists, but with nothing else in that SSO domain we can go ahead and safely decommission and delete the virtual appliance.


So there you have it. The process for cross domain repointing in 6.7 is quite straight forward and in my (rather basic) testing, has worked well. I’m keen to look at some more complex scenarious with various conflicts in the lab, and I’ll be sure to report back any findings.

What do you think of this new functionality? Will you be using it in vSphere 6.7?


21 thoughts on “vCenter 6.7 Cross SSO Domain Repointing

  1. Pingback: Релиз VMware vSphere 6.7 |

  2. Robert

    Doesn’t work for me, I get a certificate error:-

    Failed to validate sso credential. Error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:719)

    And of course there’s nothing I can find anywhere that references this problem. SSO domain and SITE are identical on a freshly built PSC, the current Windows vCenter server is 6.7 as is the PSC, no errors, everything is stable, and it still fails. Are there some other prerequisites needed to get this to work?

    1. Matt Post author

      Hi Robert,

      I’m not aware of any other prerequisites, but with that said every environment is different and different steps may need to be performed in each environment to ensure it is in a good state to allow a cross SSO domain repoint.

      Can you please clarify your set up for me? For example, what are the SSO domains, sites, PSC / vCenter node deployments.

      If this is a production environment I’d suggest logging it with VMware Global Support Services to troubleshoot.

      Cheers, Matt.

      1. Matt Post author

        Yes, I believe that’s correct and I forgot to call this out within the post, I don’t think I was aware of it when writing this post actually and I overlooked the mention of a Windows vCenter in the original comment. I’ll amend shortly, but hopefully by 6.7 everyone is now running the vCenter Server Appliance.

        1. Robert J Birkett

          I don’t intend to run the appliance, the original 6.0 appliance was and always has been a pain to maintain under Linux, and if you don’t manage the disk space, the defaults just lock it up eventually. It shouldn’t matter if you run the VCenter under Windows 2016 or run the appliance. If the Windows platform doesn’t work then why do they even bother supporting it, just tell everyone it is no longer supported and that you MUST use the appliance instead. I’ve already built out the system, and I’m not about to replace it. Maybe they should fix this before they finish the HTML5 feature support for VCenter so we can get rid of Flash. More half finished products from VMware…..


          1. Matt Post author


            Everyone has different experiences, but I would say the appliance model has been much easier to maintain than vCenter Server on Windows. I agree with the disk space issue (mostly the logging disk mount), but this is just a “day 2” operations task of managing any machine in an environment. Left to it’s own devices, I’m sure a Windows server will run out of free disk space as well over time.

            The Windows vCenter Server is deprecated, 6.7 will be the last major release that supports running vCenter Server on a Windows Server, see the following blog post for more information. I’d suggest planning the migration off a Windows based vCenter Server.

            And as noted in the following blog post, as of 6.7 Update 1 the vSphere client (HTML5) will have full functionality –

            Cheers, Matt.

  3. eva wesolowska

    Doesn’t work for me as well ….

    Just want to check possibility , I’ve tried to repoint VCSA 6.7 with external PSC 6.7 to another PSC 6.7 but it failed :
    Starting License pre-check … Done
    Starting Authz Data export … Failed
    Conflict data, if any, can be found under /storage/domain-data/Conflict*.json
    Pre-checks failed.

    Thats my LAB , I’m trying to replay steps for possible upgrade path in prod .
    SO in lab I have to VCSA 6.7 with External PSC 6.7 , both vCenters have different Site Name and SSO Domain .
    Both vCenters where upgraded from WinSrv 2012 6.0 to VCSA 6.7 .

    Just wander are there any specific logs I could view why is it failing ?
    I logged SR with VMware as well to confirm if above is supported as well ???


  4. VSSadmin


    I used your guide to do the re-point with 6.7U1 (VCSA – with 2 different SSO Domains) to point to an embedded PSC which is supported with U1.

    Worked really good – nice guide!!!

  5. Tomasz


    I have exactly the same issue – any luck with this in your case ?

  6. David

    I am trying to follow this along with that vmware also posted and the commands seem good however mine will not get past:
    Starting Authz Data export … Failed

    I have checked for conflicts under /storage/domain-data/Conflict*.json and there are no fies at all in here there is actually no domain-data folder at all. I am running all VCSA 6.7U1 with external PSC.

    Once quick question both domains are called vsphere.local would this pose an issue or the names themselves have to be different? Any help here would be much appreciated .


    1. Matt Post author

      Hi David,

      Both domains having the same name won’t be a problem. I’m a bit under the pump at the moment but I will try to identify which log might have more information as to why your export is failing and come back to you. I’d also suggest posting your question on the vCenter VMTN forums as well as no doubt you will have someone there respond sooner than I that knows which log to take a look at.

      Have you tried running cmsso-util with the –debug option?

      Cheers, Matt.

      1. Dave

        Hey Matt,

        Thanks for getting back to me. I have not tried the debug option but might give that a try. I also put in a support ticket with VMware directly to see if they can come with something. In the meantime I will give what you suggested a try.

        Thank you much.

        1. Matt Post author

          Thanks David. Please post back with what you find either via GSS or the debug option!

          Cheers, Matt.

  7. Jarrod

    If we have an embedded PSC version of 6.5VCSA and upgraded it to 6.7 VCSA will this still work? I hope so we just upgraded to 6.7 and i want to now linked mode without redeploying all 100 + VCs in my environment:)

    1. Matt Post author

      Hey Jarrod,

      6.7U1 should give you the flexibility to do whatever you need to do with externalising / embedding / repointing.

      While it can be done, it probably depends on how many embedded / external deployments you currently have and how many repoints need to be done to consolidate to your desired end goal. I’m assuming you don’t want to attempt to put 100+ VCs into a single SSO domain.

      A prerequisite to do a cross-domain repoint is to externalise the PSC first. Depending on your scenario this could add a lot of time and resource overhead as you’d then want to embed the deployment again after a repoint anyway.

      Cheers, Matt.

  8. Tireak C Tulloch

    I wonder if this is a viable solution where the current vsphere.local domain may have some corruption or data inconsistencies between PSC’s that would take too much of any effort to clean up. It would look a viable solution for that situation by building a new vsphere.local domain and repointing the VCSA’s to it.

  9. Adek Kalos

    The issue with the “Starting Authz Data export … Failed” message is related to Spring version referenced in the /usr/lib/repoint/
    In version vSphere 6.7 U2 it should be 4.3.20 but the script calls 4.3.9

    Here is the oneliner to inject correct entries:
    sed -i ‘s/4.3.9/4.3.20/g’ /usr/lib/repoint/

    As always create copy of the original file before making any changes

  10. forbsy

    Thanks. 6.7U1 repoint does some different tasks like uninstalling the source PSC. Worked well. I now have 3 VCSAs in Enhanced Link mode.

  11. Matt

    No dice for me on VCSA 6.7 U3c, unfortunately.

    The syntax of ‘cmsso-util domain-repoint’ appears to have changed:

    # cmsso-util domain-repoint –mode pre-check –src-emb-admin administrator –src-psc-admin administrator –dest-psc-fqdn [blah] –dest-psc-admin administrator –dest-domain-name [blah] –dest-vc-fqdn [blah]
    usage: cmsso-util [-h] {unregister,reconfigure,repoint,domain-repoint} …
    cmsso-util: error: unrecognized arguments: –src-psc-admin administrator –dest-psc-fqdn [blah] –dest-psc-admin administrator –dest-vc-fqdn [blah]

    So I tried this but it also failed:

    # cmsso-util domain-repoint –mode pre-check –src-emb-admin administrator –replication-partner-fqdn [blah] –replication-partner-admin administrator –dest-domain-name [blah]
    Replication partner must beembedded vCenter Server node.
    Failed to determine deployment type for the Node : [blah]. Please verify.

    I’m wondering if that’s because the destination node is VCSA 6.5. Maybe both have to be 6.7 for it to work?

    1. Matt Post author

      Hey Matt.

      Sorry for the delay in getting to this comment. I’d strongly suggest that both vCenter servers be the same build before attempting a repoint. And it is a feature of 6.7 so it definitely won’t work with 6.5. I’ll aim to check out any changes in the command syntax over the weekend and update the post accordingly.

      Cheers, Matt.


Leave a Reply

Your email address will not be published. Required fields are marked *