"Duplicates Found" failure in VDT report for vCenter Server

Products

• VMware vCenter Server

Issue/Introduction

• After running VDT script on a vCenter Server, one of "Duplicates Found" failure error might be presented.

[FAIL]    VCENTER-FQDN (VC Server or CGW)

                    [FAIL]    Duplicates Found (activedirectory / cs.registry)
                                Ignore if this is the PSC HA VIP.  Otherwise, you must unregister the extra endpoints.

Or

[FAIL]    VCENTER-FQDN (VC Server or CGW)

                    [FAIL]    Duplicates Found

You must unregister the extra endpoints. Please run lsdoctor.py -r option 3 on this node for each service type listed

Duplicates by Node ID:

'Node ID: ########-06bb-####-a185-########ea0a' :

'Service type: activedirectory' :
- 'Service ID: ########-3292-####-ae2a-########57b8'
- 'Service ID: ########-fa6c-####-a576-########bcc8'
'Service type: cs.registry' :
- 'Service ID: ########-4dc8-####-9d09-########1fd4'
- 'Service ID: ########-f258-####-94df-########9586'

• In the example above, 2 services are detected to be duplicated: activedirectory / cs.registry.  It is possible to see other service type as well.

Environment

vCenter Server 7.x

vCenter Server 8.x

vCenter 9.0

Cause

• During a vCenter upgrade (notably to versions 7.x or 8.x), the process may register new endpoints without successfully removing the previous ones. This often triggers a "VMware vAPI Endpoint Service Health Alarm" or causes vCenter patching to fail with errors like "Invalid Type, Expected String, Instead got None Type.
• If an external Platform Services Controller (PSC) or a vCenter node in Enhanced Linked Mode (ELM) is removed without being properly decommissioned, its service registrations remain in the shared Lookup Service database.
• Using the cmsso-util domain-repoint command can sometimes result in duplicate cs.registry endpoints, especially if the workflow uses contains logic rather than an exact match when searching for existing service IDs.
• Service and certificate records are tightly coupled with the vCenter Machine ID. If there is a mismatch during a recovery or migration, it can lead to duplicate or stale registrations.
• Issues with host re-registration or synchronization between vCenter and solutions like vSphere Replication or Site Recovery Manager can create duplicate entries in the database.

Resolution

Duplicate service registrations must be removed using the lsdoctor tool, Download the lsdoctor tool from KB article using the 'lsdoctor' Tool.

1. Preparation:
   1. Ensure a valid file-level backup or offline snapshot exists for the vCenter Server.
   2. In an SSO domain with multiple nodes, shut down all vCenter servers/ Platform services controller (PSCs) simultaneously before taking snapshots. 
2. Remediation Steps:
   1. Run the tool with the reconstruction flag: python lsdoctor.py -r
   2. Select Option 3 from the menu to unregister extra endpoints.
   3. Repeat for each service type listed in the VDT failure report.
   4. Once the script completes restart all the vCenter services: service-control --stop --all && service-control --start --all
   5. Re-register any external solutions that were previously pointed to this node (SRM, vSphere Replication, NSX-V, etc.)

 Note: Service registration may fail, resulting in the vCenter Server UI becoming inaccessible. In such cases, it will be necessary to replace all services with newly registered services by selecting Option 2 after running the lsdoctor tool using the following command: python lsdoctor.py -r

Additional Information

Limitations

Currently, the Lookup Service Doctor tool supports vCenter 6.5 and above (both Windows and VCSA). When new builds of vCenter Servers are released, the lsdoctor tool must be updated asynchronously. This means that the lsdoctor tool support for the latest version of vCenter Server may be updated sometime after a new build is released.

For more information, see Using the 'lsdoctor' Tool.