Best practices for joining vCenter Servers in Linked Mode (2005481)

Purpose

This article provides best practices when working with vCenter Server Linked Mode, as well as steps to troubleshoot vCenter Server Linked Mode issues.

Resolution

Best practices

 

When working with vCenter Server Linked Mode issue, follow these best practices:

• If the vCenter Server is joined to a domain, ensure that it can communicate with the Domain Controller. If Domain Controller communication problems exist, remove and add the vCenter Server to the Windows domain.
  
• Ensure that all vCenter Server system times are synchronized with a time difference of no greater than 5 minutes.
  
• Ensure that all vCenter Server are the same version and build. For more information, see Cannot access instances of vCenter Server in Linked Mode configuration after upgrading to vCenter Server 4.1 (1026346).
  
• Ensure that the VirtualCenter Server Service uses an account with rights to logon as a service/batch job.
  
• The vCenter Server Linked Mode Configuration tool must be run by a domain user that is also a local administrator on both machines where vCenter Server is installed.
  
• Different Windows domains for vCenter Servers are permitted only if there is a two-way trust between the two domains. Ensure this is true from both Windows domains.
  
• If User Account Control (UAC) is enabled, be sure to use Run as administrator when starting the vCenter Server Linked Mode Configuration tool.
  
• Ensure that the vCenter Server Windows machine name matches the Domain/DNS name.
  
  Note: Instancename, VimWebServicesUrl, and VimApiUrl keys must match. For more information, see ESX and vCenter Server Installation Guide.
  
• Ensure that the Windows firewall service is running but the firewall is turned off.

Verifying the initial replication

The Jointool/vCenter Server installer does a large set of checks to validate initial replication between instances. Issues with joining two instances are usually due to errors in initial replication. However, after a successful join (especially with more than two total instances in the vCenter Server linked mode group), some instances may not see all instances in the group.

 

To see if ADAM replication is the issue, perform these steps on all concerned vCenter Server machines:

1. Click Start > Administrative Tools > ADSI Edit.
2. Right-click ADSI Edit in the left pane and click Connect to.
3. Under Connection Point in the Distinguished Name box, enter dc=virtualcenter,dc=vmware,dc=int. 
4. Under Computer in the domain or server box, enter localhost:389, then click OK. This opens up a new connection to our application partition in ADAM.
5. Expand Default naming context and drill down clicking the OU=Instances container on the left pane. You see entries (GUIDs) under OU=Instances for the vCenter Servers in your setup.
   
   This list should be identical on every replica (and the primary). It does guarantee that replication will continue to succeed,  but it does indicate that initial replication during installation was successful.

Verifying the Health service status

To verify the Health service status for the LDAP Replication Monitor, install the service-monitoring vSphere Client plugin as part of all vCenter Server installs:

1. In vSphere Client, click Home.
2. Click vCenter Server Service Status in the Administration section.
   
   Note: If you do not see vCenter Service Status, you have to enable the plugin by clicking Plug-ins > Manage plug-ins.

Troubleshooting replication issues

To troubleshoot replication issues:

1. Click Start > Administrative Tools > Event Viewer.
   • Review the  Event Viewer Log entries for related ADAM instance (VMwareVCMSDS or something similar) events. Record any warning or error messages you find.
   • Example warning messages involving replication are often explicit. For example:
     
     8453 Replication access was denied.1772 The list of RPC servers available for the binding of auto handles has been exhausted.
     Note: This error is often a symptom of firewalls blocking ports (RPC mapper runs on port 135, and needs ports > 1024 to be open on the machine).
     
2. Run Knowledge Consistency Check (KCC) from the command line to confirm replication is the problem. Run KCC on the replica machine:
   
   
   • C:\Windows\ADAM\repadmin.exe /kcc localhost:389 (to confirm local consistency)
   • C:\Windows\ADAM\repadmin.exe /kcc remoteVCFQDNremotePort (to confirm remote primary consistency)
     
     If either of these return an error, inform VMware if you open a Support Request.
     
3. Forcing replication can help diagnose issues. To force replication between ADAM instances:
   
   C:\WINDOWS\ADAM>repadmin /replicate remote-vc:remote-vc-adam-port local-vc-fqdn:local-adam-port dc=virtualcenter,dc=vmware,dc=int
   
   This is an example of successful replication:
   
   C:\WINDOWS\ADAM>repadmin /replicate vm08.PDPVC.com:389 vm04.PDPVC.com:389 dc=virtualcenter,dc=vmware,dc=int Positive response:
   Sync from vm04.PDPVC.com:389 to vm08.PDPVC.com:389 completed successfully.
   
   This is an example of failed replication:
   DsBindWithCred to vm04.pdpvc.com failed with status 1753 (0x6d9):There are no more endpoints available from the endpoint mapper 
   
4. To verify inbound and outbound replication from one machine, run the command:
   
   repadmin /syncall localhost:vc-ldap-port 
   
5. Run directory service tests with dcdiag. This runs a comprehensive list of tests to help diagnose what may have failed with the replication (such as name resolution and or referrals):
   
   (c:\windows\adam or c:\windows\system32) dc diag /s:localhost:vc-ldap-port

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2005481