Exporting and Restoring vCenter 8.x Permissions Before Breaking Enhanced Linked Mode

Cosmin Trif — Tue, 30 Jun 2026 15:45:00 +0000

Breaking Enhanced Linked Mode is one of those changes where the technical command is not the hardest part. The hard part is making sure administrators, service accounts, and external products can still log in and do their jobs after the vCenters no longer share the same SSO domain.

In this post I will walk through a repeatable way to export and restore vCenter 8.x RBAC data before splitting Enhanced Linked Mode. The focus is on three permission layers:

Custom roles
Explicit object or inventory permissions
Global permissions

The short version is this: object permissions usually survive the split because they live in the vCenter database, but global permissions and SSO-domain objects need special handling. If you depend on global permissions, do not start the split until you have exported them and have a plan to recreate or import them afterward.

What Changes When You Split ELM

Enhanced Linked Mode lets multiple vCenter Server instances share one vCenter Single Sign-On domain. When you break that relationship, the vCenters stop sharing the same SSO namespace.

That matters because not all permissions are stored the same way.

Item	What to expect
Custom roles	Export and re-import them so role names and privilege sets are consistent.
Object permissions	Usually remain on the vCenter inventory objects, but the principals must still resolve after the split.
Global permissions	Must be exported and recreated/imported after the split.
Local SSO users/groups	Must be recreated if they are still needed.
AD/LDAP identity sources	Must be recreated or verified on the standalone vCenter.
Solution users/plugins	Usually need product-specific re-registration or repair.

If the environment is managed by VMware Cloud Foundation / SDDC Manager, stop and validate supportability first. Cross-domain repointing is not something I would treat as a casual vCenter-only operation in a VCF managed environment.

Download the Helper Scripts

I use three helper scripts for this workflow:

Script	Purpose
Export-VCenterRbac.ps1	Exports custom roles and explicit object permissions from a vCenter.
Convert-AuthzDoctorPermissions.ps1	Converts `authz-doctor` output into a clean CSV for global permissions.
Import-VCenterRbac.ps1	Imports roles, optional global permissions, and object permissions after the split.

The scripts assume PowerShell 7+ and PowerCLI:

Install-Module VMware.PowerCLI -Scope CurrentUser
Set-PowerCLIConfiguration -InvalidCertificateAction Warn -Confirm:$false

Run the import with -WhatIf first. This is especially important when restoring global permissions.

Before You Export Anything

Do the boring checks first. This is where most bad outcomes are avoided.

Confirm which vCenters are staying linked and which vCenters are being split.
Confirm you have working SSO administrator access.
Confirm you have root access to each VCSA so you can run authz-doctor.
Take a file-based backup of each vCenter.
Take powered-off snapshots of all ELM nodes at the same point in time if that is your rollback method.
If vCenter HA is enabled, remove it before the split.
Identify any local SSO users/groups that need to exist after the split.
Identify all AD/LDAP identity sources that need to be recreated.
Identify solution accounts for NSX, SRM, Aria, backup products, monitoring tools, and plugins.

I also like to create at least one explicit vCenter-root permission for a known AD admin group on each vCenter before the change. Do not rely only on global permissions for your break-glass path.

Step 1: Export Roles and Object Permissions

Create one export folder per vCenter. Do not mix them. The object paths and managed object references are specific to the vCenter they came from.

cd C:\temp\vcenter-elm-rbac

.\Export-VCenterRbac.ps1 `
 -Server vcsa01.example.com `
 -OutDir .\exports\vcsa01

.\Export-VCenterRbac.ps1 `
 -Server vcsa02.example.com `
 -OutDir .\exports\vcsa02

.\Export-VCenterRbac.ps1 `
 -Server vcsa03.example.com `
 -OutDir .\exports\vcsa03

Each export folder should contain:

manifest.json
roles.json
object-permissions.json
object-permissions.csv
global-permissions.template.csv

roles.json is used for import. object-permissions.json is also used for import. The CSV is there so you can review the permissions quickly in Excel or another editor.

Open manifest.json and make sure the count looks reasonable:

Get-Content .\exports\vcsa01\manifest.json | ConvertFrom-Json

Step 2: Export Global Permissions with authz-doctor

Global permissions are the part I care about most in an ELM split. They are easy to forget because they live under Administration > Access Control > Global Permissions, not on the normal inventory tree.

On each vCenter appliance, SSH in as root and run:

/usr/lib/vmware-vpx/scripts/authz-doctor/authz-doctor.py permission_check > /tmp/authz-doctor-permissions.txt

Copy the file back to the matching export folder:

scp root@vcsa01.example.com:/tmp/authz-doctor-permissions.txt ./exports/vcsa01/

The permission rows in that file are pipe-delimited and look like this:

Principal | IsGroup | RoleId | RoleName | Propagate | Entity
VSPHERE.LOCAL\vpxd-extension-xxxx | False | -1 | Admin | True | Global
DOMAIN\vSphere-Admins | True | -1 | Admin | True | Global

The converter detects these rows by their column layout, so it does not matter whether your vCenter build prints a leading | on each row.

Then convert the global permission rows into CSV:

.\Convert-AuthzDoctorPermissions.ps1 `
 -InputFile .\exports\vcsa01\authz-doctor-permissions.txt `
 -OutputFile .\exports\vcsa01\global-permissions.csv `
 -GlobalOnly

Repeat this for each vCenter.

The resulting file should have this shape:

Principal,IsGroup,RoleId,RoleName,Propagate,Entity
"DOMAIN\vSphere-Admins","True","-1","Admin","True","Global"

Step 3: Review Principals Before the Split

Do not blindly import the CSV later. Review it first.

Pay special attention to:

administrator@vsphere.local or users from the old SSO domain
Local SSO groups that will not exist after the split
Solution users such as vpxd-*, vsphere-ui-*, NSX, SRM, backup, or monitoring accounts
AD groups whose domain name or identity source alias may change
Custom roles that exist on one vCenter but not another

If you are moving from a shared SSO domain to standalone SSO domains, a principal name that made sense before the split may not resolve afterward. The permission entry can exist, but it is useless if the identity source cannot resolve the user or group.

Step 4: Add Temporary Object-Level Admin Access

Before breaking ELM, add a direct permission at the root of each vCenter inventory for the admin group you will use after the split.

In the vSphere Client:

Select the vCenter object at the top of the inventory.
Go to Permissions.
Add your AD admin group.
Assign the appropriate role, usually Administrator for the migration window.
Enable propagation.

This gives you a local object permission that is independent of Global Permissions. It is your practical safety net.

Step 5: Break Enhanced Linked Mode

Follow the supported vCenter 8.x ELM split procedure for your environment. At a high level, the flow is:

Shut down the vCenter being split from the SSO domain.
From one of the remaining linked vCenters, unregister the powered-off node.
Power on the vCenter being split.
Repoint it to a standalone SSO domain.
Validate that the vCenter no longer shows the other linked vCenters.

The key point for this post is timing: do not import permissions until the standalone vCenter has its identity source and SSO domain in the final state.

Step 6: Recreate Identity Sources and Local SSO Objects

After the vCenter is standalone, log in with the new SSO administrator and recreate or verify:

AD/LDAP identity sources
Local SSO users
Local SSO groups
Any SSO group nesting used by the exported permissions
Certificates or trust needed for LDAPS

Before importing permissions, test that the principal resolves. For example, search for the AD group in the vSphere Client permission picker. If the picker cannot resolve it, the import will not give you meaningful access.

Step 7: Dry-Run the Import

Start with a dry run:

.\Import-VCenterRbac.ps1 `
 -Server vcsa01.example.com `
 -InDir .\exports\vcsa01 `
 -GlobalPermissionsCsv .\exports\vcsa01\global-permissions.csv `
 -UsePrivateMobForGlobalPermissions `
 -WhatIf

The import order is:

Create or update custom roles.
Import global permissions if a CSV is provided.
Import object permissions.

The global permission import uses the vCenter MOB endpoint for AuthorizationService.AddGlobalAccessControlList. That is why the switch is intentionally named -UsePrivateMobForGlobalPermissions. I want it to be obvious that this is different from the normal object permission path through AuthorizationManager.

If you only want to restore roles and global permissions first, skip object permissions:

.\Import-VCenterRbac.ps1 `
 -Server vcsa01.example.com `
 -InDir .\exports\vcsa01 `
 -GlobalPermissionsCsv .\exports\vcsa01\global-permissions.csv `
 -UsePrivateMobForGlobalPermissions `
 -SkipObjectPermissions `
 -WhatIf

Step 8: Run the Import

Once the dry run looks right, run it without -WhatIf:

.\Import-VCenterRbac.ps1 `
 -Server vcsa01.example.com `
 -InDir .\exports\vcsa01 `
 -GlobalPermissionsCsv .\exports\vcsa01\global-permissions.csv `
 -UsePrivateMobForGlobalPermissions

If you changed principal names during the split, edit global-permissions.csv before running the import. For example, change:

OLDSSO\vSphere Admins

to:

CORP\vSphere Admins

or whatever the correct identity source now exposes.

Step 9: Verify Access

Do not stop after the script completes. Verify the permission model from both the API side and the user side.

Run authz-doctor again:

/usr/lib/vmware-vpx/scripts/authz-doctor/authz-doctor.py permission_check > /tmp/authz-doctor-permissions-after.txt

Check Global Permissions in the vSphere Client:

Administration > Access Control > Global Permissions

Then test real logins:

Log out of the SSO administrator account.
Log in as a user from the restored AD admin group.
Confirm you can see the expected inventory.
Confirm you can perform a low-risk administrative action.
Test at least one non-admin role if you have delegated access.

For object permissions, you can also re-export and compare the count:

.\Export-VCenterRbac.ps1 `
 -Server vcsa01.example.com `
 -OutDir .\exports\vcsa01-after

Compare-Object `
 (Import-Csv .\exports\vcsa01\object-permissions.csv) `
 (Import-Csv .\exports\vcsa01-after\object-permissions.csv) `
 -Property Principal,RoleName,Propagate,EntityPath

Some differences are expected if you intentionally changed principals or cleaned up stale entries. Unexpected missing admin groups are not expected.

Common Gotchas

The import cannot fix an identity source that does not exist. Recreate AD/LDAP first.

Custom role IDs can change. The import script matches role names first because role IDs are not always stable across systems.

Object permissions can point to objects that no longer exist. The script tries the original managed object reference first and then the inventory path. If neither resolves, review the CSV and decide whether the permission is still needed.

Solution users are not normal human permissions. If NSX, SRM, Aria, a backup product, or a monitoring tool owns a registration, use that product’s supported reconnect or repair procedure instead of blindly restoring stale solution-user permissions.

Global permissions are broad. Review them carefully before bringing them back into a standalone vCenter.

References

The goal is not just to preserve a list of permissions. The goal is to preserve access that still resolves, still matches the right role, and still works after each vCenter stands on its own.

PowerCLI on Cosmin.us