Log in with the credentials of the "administrator@vsphere.local" account of the SSO domain you have joined.
In other words, the account "administrator@vsphere.local", whose password had been defined when configuring the VCSA server on site 1 (Brussels).
Once connected to this 2nd VMware vCenter Server (VCSA), you will see that you have access to:
Note: if the remote VCSA server does not appear in your case, connect to the web client of your other VCSA server.
Indeed, this may happen temporarily at first since the DNS zones of your DNS servers are not instantly replicated.
You will see at the end of this tutorial how to fix it quickly.
Create the data center(s) and folders you want for your site 2 (Paris), then add your VMware ESXi host where you want.
In the "Add Host" window that appears, provide the host name (domain name) or IP address of the VMware ESXi host on site 2 that you want to add to your VCSA server inventory.
Provide the credentials of an account with the required permissions on this VMware ESXi host.
For example: the "root" account of this VMware ESXi host.
Ignore the security alert that appears by clicking "Yes" if it is due to the use of a self-signed SSL certificate (which is the case by default).
A summary of the host to add is displayed.
Click Next.
Assign the correct license (if you have one) or leave the trial license selected by default if you are in a test environment (for example).
Lockdown mode allows you to restrict direct access to the VMware ESXi host, as well as its DCUI (Direct Console User Interface) console so that it can only be managed through your VMware vCenter Server .
Leave the option "Disabled" (default) to not restrict access to your VMware ESXi host and click Next.
Select the datacenter or folder (if applicable) where you want to add the virtual machines that are currently present on your VMware ESXi host.
A summary about adding your VMware ESXi host appears.
Click Finish.
Your VMware ESXi host has been added to your VMware vCenter Server (VCSA) inventory.
Note: at the bottom of the page, you will see the "Add standalone host" task appear.
You will also have access to the virtual machines present on the added host.
As you can see, from the VMware vCenter Server (VCSA) of our site 2 (Paris), we can easily access the information and settings of our VMware vCenter Server (VCSA) of our site 1 (Brussels).
We can also access the different data centers, folders, hosts, virtual machines, ... that are there.
Thus, we can for example display the information of a VMware ESXi host of our site 1 (Brussels) from the VMware vCenter Server (VCSA) of our site 2 (Paris) without any problem (as you can see in the bar address of the web browser used).
We can also display the information of a virtual machine of site 1 (Brussels) from the VMware vSphere Client of the VCSA server of site 2 (Paris) transparently.
Of course, we can also access our local vCenter Server (VCSA), as well as its resources: data centers, hosts, virtual machines, ...
Previously, we used the "VMware vSphere Client" web client from our "paris-vcsa" server.
In our case, our 2 VCSA servers (brux-vcsa and paris-vcsa) appeared in this web client.
On the other hand, using the web client "VMware vSphere Client" of our server "brux-vcsa", we could not access our remote VCSA server (paris-vcsa).
Indeed, as you can see in the image below, our server "paris-vcsa.informatiweb.lan" does not appear.
However, it should have appeared there given that our 2 VMware vCenter Server (VCSA) servers are linked together and that they appear in the web client of our remote VCSA server (paris-vcsa).
In reality, the problem is not with VMware vCenter Server (VCSA), but with your local DNS server, whose DNS zones are not up to date.
Source: One vCenter Server instance not available in Linked Mode (2004720).
Indeed, when you create DNS records on your local DNS server (the one present on the same physical site as the one where you deployed your VCSA server), these are not automatically replicated to the other DNS servers present on the other physics.
Note that this issue only occurs when you have multiple internal DNS servers for the same domain. Which is supposed to be the case in any multi-site Active Directory infrastructure if you followed the best practices for it.
As you can see, in our case, on our main DNS server (BRUX-DC1) at site 1 (Brussels), the only existing DNS record for VCSA servers is: brux-vcsa.
On our secondary DNS server (BRUX-DC2), the problem is the same.
On the other hand, in our case, on the main DNS server (PARIS-DC1) of site 2 (Paris), the 2 DNS records for the VCSA servers exist: brux-vcsa and paris-vcsa.
This explains why the web client of our VCSA server on site 2 (Paris) can access our 2 VCSA servers (brux-vcsa and paris-vcsa).
But, it does not work correctly from the VCSA server of site 1 (Brussels).
To solve the problem, simply wait or force the replication of data from your Active Directory infrastructure via the console: Active Directory Sites and Services.
To do this, in this console, select the server whose DNS zone is not up to date (in our case: BRUX-DC1), then deploy this node and select the "NTDS Settings" node which appears on the left.
Then, in the right part, you will see a list of objects of type "Connection" which indicates with which domain controllers the data of your Active Directory infrastructure is replicated for it.
In our case, we right click "Replicate Now" on the object which concerns the server "PARIS-DC1" (whose DNS zone is up to date as you can see in the previous image).
A message will tell you that Active Directory Domain Services will attempt to replicate data from the desired Active Directory domain controller.
Click OK.
Plain Text
One or more of these Active Directory connections are between domain controllers in diferent sites. Active Directory will attempt to replicate across these connections. For more information about how to verfiy replication, see Help and Support.
Warning : data replication is not instantaneous. Wait a minute, then check if the DNS zone has been updated on the desired DNS server (in our case: BRUX-DC1).
To see the background data replication status, go to the server that was not up to date (in our case: BRUX-DC1) and type the command:
Batch
repadmin /showrepl
As you can see, the Active Directory domain services have in particular replicated the data of the Active Directory partitions "DomainDnsZones" and "ForestDnsZones" which contain the DNS zones integrated into the Active Directory.
This is the case for the DNS zone of the domain created when promoting your servers to domain controllers.
Plain Text
DC=DomainDnsZones,DC=informatiweb,DC=lan Paris\PARIS-DC1 via RPC ... Last attempt @ 2022-02-12 21:25:09 was successful. ... DC=ForestDnsZones,DC=informatiweb,DC=lan Paris\PARIS-DC1 via RPC ... Last attempt @ 2022-02-12 21:25:09 was successful. ...
A minute later, check the DNS zone of the desired server and you will see that it has been updated.
Now, the records of our 2 VCSA servers (brux-vcsa and paris-vcsa) are also available on our DNS server "BRUX-DC1".
Disconnect from the previously problematic VCSA server web client and log in again as: administrator@vsphere.local.
If the DNS records are available on your local DNS server (site 1 in this case), your 2 VCSA servers will appear.
And as expected, you will be able to manage everything remotely via this web client.
VMware 5/19/2023
VMware 11/23/2022
VMware 4/19/2024
VMware 7/3/2024
Pinned content
Contact
® InformatiWeb-Pro.net - InformatiWeb.net 2008-2022 - © Lionel Eppe - All rights reserved.
Total or partial reproduction of this site is prohibited and constitutes an infringement punishable by articles L.335-2 and following of the intellectual property Code.
No comment