Failures in Solution User Certificate Parity Checks Inconsistent results for the VC Machine ID Check
search cancel

Failures in Solution User Certificate Parity Checks Inconsistent results for the VC Machine ID Check

book

Article ID: 438044

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

In a VMware vCenter Server 8.0.3 environment configured with Enhanced Linked Mode (ELM) or Standalone, the vCenter Diagnostic Tool (VDT) may report failures during health checks. Specifically, the VC Machine ID Check flags as failing or inconsistent. While the environment may appear functionally stable, VDT identifies that the MachineGuid registered in the directory services does not match the expected identifiers for the vCenter nodes.

This issue typically manifests in the VDT output with:

  • Failures in Solution User Cert Parity Checks

  • Inconsistent results for the VC Machine ID Check

 

 Solution User Cert Parity Checks
            [FAIL]    Solution User Cert Parity Checks
                        Traceback (most recent call last):
                       
                          File "/vdt-2.x/vcenter/vc_scripts/vc_soluser_checks.py", line 123, in get_users
                            raise NoSolutionUsersFound(f"No solution users found matching machine ID: {machine_id}")
                        Solution User Cert Parity Checks.NoSolutionUsersFound: No solution users found matching machine ID: ########################

 

Machine ID doesn't match vpxd.cfg
                          Current MID: ####################################
                          Correct MID: ####################################
                 

Environment

 

  • Product: VMware vCenter Server Appliance (VCSA)

  • Version: 8.0.3

 

Cause

The root cause is an incorrect or mismatched MachineGuid value within the vmdir (VMware Directory Service) configuration. This mismatch prevents VDT from verifying the identity parity across the environment.

Resolution

To remediate the MachineID inconsistency, you must manually update the registry value on each impacted vCenter Server.

  1. Create a Backup: Take a cold snapshot of all vCenter Server Appliances in the SSO domain to ensure a valid roll-back point. If in ELM all vCenters should be powered off for the snapshot.                                                                                     

  2. Access the Shell: Connect via SSH to the VCSA as root.

  3. Update MachineGuid: Execute the following command to set the correct MachineGuid (replace <machine-id> with the correct ID provided by your analysis or engineering):

    /opt/likewise/bin/lwregshell set_value '[HKEY_THIS_MACHINE\Services\vmdir]' "MachineGuid" <machine-id>
  4. Restart Services: Restart all vCenter services to apply the change:
    service-control --stop --all
    service-control --start --all
  5. Verify: Rerun the VDT tool to confirm the VC Machine ID Check now reports a healthy status.
  6. Repeat the steps above on the next vCenter if it’s in ELM mode.

NOTE: If vCenter High Availability (VCHA) is enabled, snapshot operations on the vCenter Server Appliance are not supported and may result in failover or data inconsistency. Disable or remove VCHA before proceeding. See  VCHA FAQ

 

Additional Information

Subscribe to this knowledge article to get updates on this issue.