vsphere6 | Electric Monk

Tag Archive for vsphere6

Rolling back and recovering from failed vSphere 6 and external multisite PSC upgrades

June 9, 2017 Multisite No comments

Recovering from failed vSphere 6 and external multisite PSC upgrades

So what happens if you have the following situation within a failed vSphere upgrade with a multi-site system?

The Scenario

The requirement was to upgrade 3 vCenters from 5.1U3 to 6.0U2. The vCenter servers previously had embedded SSO but have been repointed to the external 6.0 U2 PSCs. Note, we had an intermediary stage of repointing to 5.5U3 external SSOs first before we could upgrade the PSCs to 6.0U2. So once the PSCs are in a multisite 6.0U2 configuration, the upgrade of the vCenters can start and this is where we need to take care as the systems are interlinked at this point.

So we now have

3 x vSphere 6.0U2 PSCs set up in a multisite configuration
3 x 5.1 U3 vCenters pointing to a vSphere 6.0U2 PSC
3 x SQL 2008 R2 Databases running the vCenter Databases and the Update Manager Databases. Not seen in the example above

Why did it fail initially?

Never assume anything. We had already upgraded 2 environments without any issue so we overlooked checking the SQL environments which were meant to be a replica but clearly weren’t!

DB password had special characters in the password.
Needed to give db owner rights on the vCenter DB and the MSDB database prior to upgrading
The ODBC Connection was not the right version. We needed SQL Native Client 10 or 11.
Additional Database Permissions for VMware (Can be seen in the vSphere 6.0 Documentation Center
SQL Server 2008 R2 needed Service Pack 2 installing. (No problem with this)
An informational messages regarding the vCenter FQDN
An informational message about the ALL_SERVICES accounts. (New in vSphere. Depends if you want to use Local System for all your vCenter Services or use the multiple vSphere accounts for individual services

So how do you recover from one failed vCenter Upgrade in this scenario?

We do need to take into account at what step has it failed and check the logs to verify this. Can it be an issue that can be worked though and fixed forward or do you need to rollback and depending on how far the installer has got before failing, it might open variations in the options for a rollback. For example, if it fails to authenticate to the database, then it is unlikely it would have made any DB changes. The installer logs will give us this information.

You can retrieve the installation log files manually for examination.

Procedure

Navigate to the installation log file locations.

■	%PROGRAMDATA%\VMware\vCenterServer\logs directory, usually C:\ProgramData\VMware\vCenterServer\logs
■	%TEMP% directory, usually C:\Users\ username\AppData\Local\Temp

The files in the %TEMP% directory include vminst.log, pkgmgr.log, pkgmgr-comp-msi.log, and vim-vcs-msi.log.

Open the installation log files in a text editor for examination.

Steps

Make sure you have been through all the pre-requisites prior to starting the upgrade and test in a lab as well. Give yourself the best start at not failing.
Snapshot the whole environment (All VCs, All DBs and all All PSCs) Make sure the environment is quiesced or if you want a more consistent image vs crash consistent, shutdown the whole environment and snapshot it cold

If the upgrade of any VC 5.x to 6.0 fails in this environment, you must roll back ALL PSC. The reason is that the solution user format differs between 5.x and 6.x. During the upgrade of the VC, the VC 5.x solution users will be removed from the PSC and replaced with 6.x solution users early in the VC 6.x upgrade (during vmafd firstboot I believe). If you have a failure and only roll back the VC then you have a VC with 5.x solution users talking to a PSC that no longer is aware of those users. You must roll back ALL PSCs in the SSO Domain as they replicate.

If you encounter an unrecoverable upgrade installer error then in the event of rolling back to snapshots, the order will be all PSCs, the vCenter DB and vCenter Server
In the event the rollback above fails, all servers should be rolled back again with the order of power on being all PSCs, all vCenter DBs and all vCenter servers

Questions we have been asked

During an upgrade, could we stop/break the multisite replication agreements between PSCs to avoid any replication of issues in the event of an upgrade problem on one vCenter?

There’s no issue with breaking replication agreements generally but it not something that should be done for an upgrade. The vdcrepadmin command line tool does allows the breaking and creating of agreements and it actually protects the customer by not allowing them to delete the only agreement available. This prevents a customer from inadvertently creating an isolated PSC. What you would do is go through and create the new agreements and once they are in place just delete the extra ones. There is nothing special about the replication agreements that are created during PSC deployment. They are the same as ones created with vdcrepadmin.

PSC 6 Replication for multi-site setups

May 12, 2017 PSC Replication No comments

PSC 6 Replication

VMware Validated Designs

First of all I’d like to talk about VMware Validated Designs before going on to talk about how these can be incorporated into replicated PSC designs.

VMware Validated Designs deliver holistic data center-level designs that span compute, storage, networking and management, defining the gold standard for how to deploy and configure the complete VMware SDDC stack in a wide range of use cases. VMware Validated Designs include detailed guidance that combine with best practices on how to operate a VMware SDDC optimally. The benefits are

Accelerate time to market
Increase efficiency
De risk deployments and operations
Drive agility
Repeatable proven solutions

When looking to implement any software from the SDDC suite, we are now referring to the VMware Validated Designs for a repeatable proven solution. Of course there may always be modifications required to fit customers environments but the idea going forwards is to maintain the same standards of installation and configuration

Platform Services Controller Topology Decision Tree

Adam Eckerle from VMware has very kindly designed a poster containing a decision tree for anyone thinking of deploying PSCs and guides you through a set of decisions before deployment

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

PSC and Replication Points

All PSC replication is bi-directional but ring topology setups have to be manually created
Ring topology is now the recommended method, not mesh as it was previously
By default each PSC is replicating with only a single other PSC (the one you select when installing the additional secondary or tertiary PSC)
Site names do not have anything to do with replication today they are a logical construct for load balancers and future usage
Changes are not unique to a site but to a domain assuming they are part of the vsphere.local domain
vCenter only points to one PSC at a time or a load balanced address
PSC’s have to be part of the same domain together to use enhanced linked mode

Why Ring Topologies and not Mesh Topologies?

Ring Topologies allow for easier scaling out
They are easier to set up and maintain. There’s no issue with breaking and recreating replication agreements. vdcrepadmin does this and it actually protects the customer by not allowing them to delete the only agreement available. This prevents a customer from inadvertently creating an isolated PSC. What you would do is go through and create the new agreements and once they are in place just delete the extra ones. There is nothing special about the replication agreements that are created during PSC deployment. They are the same as ones created with vdcrepadmin
The failure of any one component in a ring does not cause replication partitions
Minimal links can be created for maximum redundancy which is increased when load balancers are used.

2 Site VVD Design

In the diagram below, you can see within each region/site, the VMware Validated Design instantiates two Platform Services Controllers and two vCenter Server systems in the appliance form factor. This includes one PSC and one vCenter for the management pod and one PSC and one vCenter for the shared edge and compute pod. The design also joins the Platform Services Controller instance to its respective Platform Services Controller instance.

3 Site VVD Design

When we start getting into a 3 site multisite design, we can then see how keeping it simple makes life a great deal easier. Below is a series of diagrams which show how this can be set up with a recommended ring topology.

This particular example uses 3 sites with 2 PSCs in each. There is no load balancer.

Steps

When initially installing the external PSCs, PSCA will be the first standalone PSC. PSCB will be installed next and partnered with PSCA. PSCC is then installed and partnered with PSCB. This is 2 way automatic replication in an inline configuration

If we wanted to make it a ring topology with just these 3 servers we could do the following and create a replication agreement between PSCA and PSCC

Now we add the second PSCs into each site and we get the following scenario. 2 way automatic links are created between the first and second PSC in each site (A and D) (B and E) and (C and F)

Now we see we have kind of lost our inline topology and how do we create a ring now? We want an inline topology of D > A > B > E > C > F
We actually need to create a new agreement between PSCE and PSCC followed by breaking the link between PSCB and PSCC. Remember the system will not let us break a replication agreement which would leave a PSC isolated so we need to create a link first

We will now get the following inline configuration

Next we want to create our ring topology. A replication agreement is created between PSCD and PSCF to create the ring

vSphere HTML 5 Web Client Fling

November 10, 2016 HTML5 Web Client No comments

vSphere HTML 5 Web Client

The vSphere HTML5 Web Client is here! It is written using HTML5 and Javascript

The following features are available at the moment

VM Power Operations (common cases)
VM Edit Settings (simple CPU, Memory, Disk changes)
VM Console
VM and Host Summary pages
VM Migration (only to a Host)
Clone to Template/VM
Create VM on a Host (limited)
Additional monitoring views (Performance charts, Tasks, Events)
Global Views (Recent tasks, Alarms–view only)

This Fling has been designed to work with your existing vSphere 6.0 environments. The new client is deployed as a new VM from the downloadable OVA. Currently the installation instructions are command line-based, but VMware are working on a GUI installation and plan to release it as an update to this Fling once it is ready.

Download and Information

https://labs.vmware.com/flings/vsphere-html5-web-client

System requirements

2 vCPU, 4 GB RAM, 14 GB
An existing VC6.0 installation (VCSA or Windows). The H5 client appliance will need 4 GB RAM, 2 vCPUs and the hard disk will grow up to 14 GB
Recommended browsers: Chrome, Firefox, IE11. Others may work, with some functional or layout issues.
Windows vCenter: Was tested with a vCenter on Windows Server 2012 R2, but should work with other versions as well.

Instructions

Note: I have a Windows 2012 R2 server running vCenter Server 6 and a Windows 2012 R2 server running an external PSC version 6. There are different instructions for running different vCenter/PSC setups.

First of all download the H5 Client Deployment Instructions and Helpful Hints.

Download the OVA and server-configure.bat

In vCenter, go to File > Deploy OVF Template

Check OVF Template details

Accept the License Agreement
Put in a name and Location

Choose a host and cluster

Select the Resource Pool if any

Choose your storage

Check Disk Format

Check VM Networking and choose a Port Group

Choose IP Address allocation

Put in an IP address

Click Finish

I then had to create an IP Pool in vCenter
Click on the Datacenter object > IP Pools

Click on the tabs and fill in the relevant information. In my case I needed to add some DNS and Association information to associate this resource pool with my networks and in particular the network my HTML 5 client is going to be on

Power on the VM
If you click on the console, you should see the below screen

SSH or WINScp as root into the H5 client appliance VM (Note: Username is root and password is demova)
Create the following folders

Copy the provided ‘server-configure.bat’ to any directory on the vCenter and PSC for Windows. (This file is one of the Fling downloads on the top left) NOTE: If you have installed vCenter into any folder other than default (%PROGRAMFILES%), the script may not find the appropriate files. You will need to edit the file and replace the two references to %PROGRAMFILES% with the appropriate path so that the “KEYTOOL” and “VECS_CLI” paths line up. These two variables are at the top of the file.
You may also need to change this at the end of the file to the correct path (this is for the ds.properties file): SET CLIENT_DIR=%PROGRAMDATA%\VMware\vCenterServer\cfg\vsphere-client
My PSC was all installed on the C Drive but I had my vCenter installed on the D Drive so I had to change the file below which is highlighted in yellow to my correct path

Run the server-configure.bat on your PSC server as Administrator
The store.jks and webclient.properties file will be created
Ignore the Creating ds.properties error message

Copy the files store.jks and webclient.properties which are generated to the below locations
/etc/vmware/vsphere-client/store.jks
/etc/vmware/vsphere-client/vsphere-client/webclient.properties
In the Windows VC machine, open an Administrator Command Prompt and run the ‘server-configure.bat’ script. The following files will get generated:

Copy the ds.properties file to H5 client virtual appliance at the following location
/etc/vmware/vsphere-client/config/ds.properties
Log into the H5 appliance and run this command to start the server:
/etc/init.d/vsphere-client start

It should come up and say started in xxx seconds

Once the installation steps above are completed, point your browser to this URL, and log in with your normal vCenter credentials:
https://H5_Appliance_Address:9443/ui

Upgrading vSphere 5.1 with embedded SSO to vSphere 6 with external multi-site Platform Services Controllers

August 19, 2016 Multisite 2 comments

vSphere 6 Platform Services Controller Multimode setup

So this is a job I had to do recently which involves quite a few stages but on the whole works very nicely. So I decided to replicate it in my lab using the below 4 servers to show how we can upgrade and migrate from an embedded situation to an external PSC situation. This initial setup has 2 x 5.1 separate vCenter Servers with embedded SSO which will end up being 2 separate 6.0.2 vCenter servers pointing to their own Window 2012 PSCs which will be in Multisite mode.

1 x Windows 2012 server with vCenter 5.1 with embedded SSO
1 x Windows 2012 server with vCenter 5.1 with embedded SSO
1 x Windows 2012 PSC 5.5 U3(New build) (Note we cannot build a v6 PSC at this point due to staged upgrade considerations) (This will be setup as the first PSC)
1 x Windows 2012 PSC 5.5 U3 (New build) (Note we cannot build a v6 PSC at this point due to staged upgrade considerations) (This will be set up as the 2nd PSC in a multi-site configuration.

PSC Information

The Platform Services Controller is available on both the Windows vCenter Server ISO or within the vCenter Server Appliance (VCSA) ISO. We will be using the Windows vCenter Server ISO.

Components that are installed with PSC 6.0 include:

VMware Appliance Management Service (only in Appliance-based PSC)
VMware License Service
VMware Component Manager
VMware Identity Management Service
VMware HTTP Reverse Proxy
VMware Service Control Agent
VMware Security Token Service
VMware Common Logging Service
VMware Syslog Health Service
VMware Authentication Framework
VMware Certificate Service
VMware Directory Service

PSC 6.0 is supported with:

VMware vCenter Server
VMware vCenter Inventory Services
VMware vSphere Web Client
VMware Log Browser
VMware NSX for vSphere
VMware Site Recovery Manager
VMware vCloud Air
VMware vCloud Director
VMware vRealize Automation Center
VMware vRealize Orchestrator
VMware vSphere Data Protection
VMware vShield Manager

What does Multi-site PSCs give us?

Customers are able to seamlessly move the vCenter Servers between PSCs when necessary
This topology allows for Enhanced Linked Mode (ELM) which is facilitated by the PSC. Starting with vSphere 6.0, the implementation of Linked Mode has changed. You no longer need to join vCenter Server instances to Linked Mode groups. You can access the replication functionality provided by Linked Mode in vSphere 6 by registering multiple vCenter Server instances to the same Platform Services Controller or joining Platform Services Controller instances in the same vCenter Single Sign-On domain
Enhanced Linked Mode provides for a single point of management for all vCenter Servers in the same vSphere domain
In vSphere 6 the Windows-based and Virtual Appliance-based vCenter Servers have the same operational maximums and can belong to the same linked mode configuration
The configuration replicates all license, global permissions, tags and roles across all sites
While it is possible to deploy PSCs over a WAN, the replication between PSCs is very latency sensitive. It is recommended that the latency between PSCs, as with any replicating directory service, to be as low as possible. Additionally, now that Enhanced Linked Mode (ELM) and all features that utilize ELM are facilitated via the PSC, for the best user experience within a vSphere environment, low latency is highly recommended
Regarding an environment in which multiple PSCs are in the same vSphere Domain and Enhanced Link Mode is being used, if a PSC in which a vCenter Server is connected to fails, access to this vCenter Server through a different vCenter Server’s vSphere Web Client is not possible. This is due to a user’s SAML token from the vSphere Web Client being unable to be passed to the failed PSC, thus to vCenter Server. Unless the PSC is brought back online or vCenter Server is repointed to a different PSC in the same domain, users cannot access it.

Considerations

It is not supported to re-register vCenter Server 5.1 to a PSC 6.0. you need to repoint vCenter 5.1 to a 5.5U3 SSO server first
You cannot re-register vCenter Server 6.0 to a PSC 6.0 that does not reside in the existing SSO Domain.
You cannot install SSO 5.5 and join a PSC 6.0 (and vice versa)

High Level Overview

Install new Windows Server 2012 R2 SSO 5.5 Server – version 5.5 U3 in the vSphere domain vSphere.local and site configuration Default-First-Site or whatever you want to call your first site for example
Install new Windows Server 2012 R2 SSO 5.5 Server – version 5.5 U3 in the same vSphere domain vSphere.local and multisite configuration Default-Second-Site or whatever you want to call your first site for example
Register/Repoint the first 5.1 embedded SSO vCenter to external 5.5 U3 SSO/PSC
Register/Repoint the second 5.1 embedded SSO vCenter to external 5.5 U3 SSO/PSC
Uninstall 5.1 Single Sign-On from the two 5.1 vCenters. It is important to do this as the underlying SSO schema changed significantly between major versions
Upgrade first external SSO 5.5 to PSC 6.0 U2
Upgrade second external SSO 5.5 to PSC 6.0 U2
Upgrade vCenters to 6.0.2
Upgrade Update Manager and vSphere Client
Check Multisite is working using vcdrepadmin tool in command prompt
Upgrade hosts and VMs

Step 1 and 2 Install 5.5 Single Sign On only on both servers in multisite mode

Attach the vSphere 5.5 U3 ISO to the first Windows Server 2012 R2 server
Select Single Sign-On and click Install

Click Next

Accept the License Agreement
Check the below screens details

Choose Standalone vCenter Single Sign-On server as this is the first SSO server before we attach the second in multisite mode

Leave the Site name as Default-First-Site or you can change it to what you want

HTTPS port is 7444

Check the Directory you are installing in to

Check all the final details

Attach the vSphere 5.5 U3 ISO to the second Windows Server 2012 R2 server

Click Next

Check the details

For this second 5.5 PSC, choose Multisite

Put in the Single Sign-On information putting in the partner host name as the first PSC server we set up

Check the certificate and click Next

Put in a name for the second site (Note the first PSC was Default-First-Site and this second one I have named Default-Second-Site)

HTTPS port is 7444

Check the Directory you are installing in to

Check the Final Details and click Install

Step 3 and 4 Repointing and reregistering VMware vCenter 5.1 to the new 5.5 SSO/PSC

After certain changes to your VMware vSphere deployment topography, you might need to re-point or re-register vCenter Server components with the vCenter Inventory Service or vCenter Single Sign-On and the vCenter Lookup Service to ensure that the components can continue to communicate.

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

On the first vCenter, open a command prompt and change directory to C:\Program Files\VMware\Infrastructure\Inventory Service\scripts
Run the is-change-sso.bat command to update the stored configuration information of the Inventory Service. Point to the https address of the new 5.5 SSO server
is-change-sso.bat https://techlabsso002.techlab.local:7444/lookupservice/sdk “administrator@vSphere.local” “SSO_password”

Type net stop vimqueryservice
Type net start vimqueryservice
Next Register vCenter Server with a different Single Sign-On instance

During installation or upgrade, vCenter Server is registered with the Lookup Service for a vCenter Single Sign-On instance. You can change this registration to the Lookup Service for a different Single Sign-On instance. You might register vCenter Server to a different vCenter Single Sign-On instance if the original Single Sign-On instance fails, or if you add a new Single Sign-On node and want to associate vCenter Server with the new node.

Note: When you register vCenter Server to a new Single Sign-On instance, you lose these permissions:

All permissions created for users from the Single Sign-On system identity source
All permissions granted to users from identity sources that are not present in the new Single Sign-On instance
All permissions granted to local operating system users

To register vCenter Server to a different vCenter Single Sign-On instance:

Open a command prompt and change directory to C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ssoregtool
Note: If you have installed vCenter Server in a location other than the default C:\Program Files\ folder, adjust the path
Unzip the sso_svccfg.zip file. Best practice is to unzip these files into a new folder and change directory to the new folder before executing the next step. Unzip to a folder called sso_svccfg
Run the below command
repoint.cmd configure-vc –lookup-server https://techlabsso002.techlab.local:7444/lookupservice/sdk –user “administrator@vSphere.local” –password “SSO_password@” –openssl-path “C:\Program Files\VMware\Infrastructure\Inventory Service\bin/”

Restart the VMware VirtualCenter Server and the VMware VirtualCenter Management Webservices services
Next Ignore the next step in the article which says to re-register vCenter with the Inventory Service unless any of the conditions are relevant
Next Register the vSphere Web Client with a different Single Sign-On instance
Open a command prompt and change directory to c:\Program Files\VMware\Infrastructure\vSphereWebClient\Scripts
Run the following command
client-repoint.bat https://techlabsso002.techlab.local:7444/lookupservice/sdk “administrator@vSphere.local” “SSO_password”

Now interestingly at this point my vSphere Web Client re-registration failed so i had a look at this KB – https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2060637 and it said my SSO password is supported with an exclamation mark. However I had to log into the web client on techlabsso002 and change the password and remove the exclamation mark in order for the registration to work!

If you have issues, it will look like this

Next you need to follow exactly the same re-registration steps for the other 5.1 vCenter server and 5.5 SSO server

Step 5 – Uninstall 5.1 Single Sign-On from the two 5.1 vCenters (Important!)

Go to Control Panel and Uninstall

Step 6 and 7 – Upgrade both 5.5 SSO servers to PSC 6 servers

Attach the vCenter 6 iso to the first PSC server and select vCenter Server for Windows and Install

Click Next

Accept the License Agreement
Put in the Single Sign-On password in and you will see it going through pre-upgrade checks

Check Ports (Important for multi-site communication) (There will be further information at the end of this post about ports required

Check Destination Directories

Choose whether to join the Customer Improvement Program

Check the final details and tick I verify that I have backed up this Single Sign-On machine
You can see that this SSO server has a replication partner of the other SSO server techlabsso003 which is in the multi-site setup
Click Upgrade

You can check a couple of links such as https://techlabsso002.techlab.local/websso

Check the below link is working also –https://techlabsso002.techlab.local/psc

Next follow the exact same steps to upgrade the second SSO server to a PSC v6 server
You will see on the final screen in the details that this is the second site (Default-Second-Site)

Step 8 – Upgrade both vCenter 5.1 U3 servers to vCenter v6.0 U2

Note: vCenter needs at least 2 vCPUs and 8GB RAM

Note: There is sometimes and error which comes up which says

The user group “NT SERVICE\ALL SERVICES” does not have the “Log on as a service” user right. This precludes the ability to use the virtual accounts feature in Windows permit greater security through increased idolation of services. We recommend that you add this group back to the list of services that have this right. If this right is not added then any installed services that would normally use a virtual account will instead use “Local Service” account

Please see the below KB for further information

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

If this right is not added then any installed services that would normally use a virtual account will instead use the “Local Service” account.

Attach the vSphere 6 ISO and select vCenter Server for Windows and click Install

Accept the License Agreement
Put in the vCenter Server credentials

It will run the pre-upgrade scripts
Put in the Single Sign-On password

Accept the certificate

Check Ports

Select Destination Directories

Check the details on the Ready to Upgrade Page

Note: When I then kicked off the installer in a client site, they had the Task Scheduler Service turned off on the vCenter server which resulted in this error message during the installation.

An error occurred while invoking external command : ‘Command: schtasks /create /ru SYSTEM /rl highest /f /sc minute /mo 5 /tn “VMwareIIAD” /tr “C:\Program Files\VMware\vCenter Server\python\python.exe\” \”C:\Program Files\VMware\vCenter Server\python-modules\iiad\iiad.py\””

Stderr: ERROR: The network address is invalid

Error occurred while creating scheduled task for IIAD

If this happens, you must makse sure the Task Scheduler is started in the services on the vCenter server

Monitoring the Installation logs

Installation Logs

· C:\ProgramData\VMware\vCenterServer\logs

· %TEMP% directory, usually C:\Users\username\AppData\Local\Temp

Step 9 – upgrade the vSphere Client

Step 10 -Upgrade Update Manager

Step 11 – Determining multi-site replication agreements and status with the Platform Services Controller using vdcrepadmin

Useful VMware KB Link here

Use these parameters using the vdcrepadmin CLI:

showservers – Displays all of the PSCs in a vSphere domain.
showpartners – Displays the current partnerships from a single PSC within a vSphere domain.
showpartnerstatus – Displays the current replication status of a PSC and any of the replication partners of the PSC.
createagreement and removeagreement – Allows for creation and removal of additional replication agreements between PSCs within a vSphere domain.

Steps for vdcrepadmin showservers

This steps below provide information on using the vdcrepadmin command-line interface (CLI) for reviewing the existing vSphere domain, Platform Services Controllers (PSC) that make up your vSphere domain as well as checking the replication agreements configured and replication status within your environment. Although the utility can be used for other operations, at this time, only what is documented must be executed by technical support staff and customers.

Log into the PSC and open a Command Prompt as Administrator
Navigate to cd c:\Program Files\VMware\vCenter Server\vmdird
Type the below command to show all the PSC Controllers in the vSphere domain

vdcrepadmin -f showservers -h PSC_FQDN -u administrator -w Administrator_Password where administrator is the PSC administrator@vsphere.local user account

Example

vdcrepadmin -f showservers -h techlabsso002.techlab.local -u administrator -w Password123!

Screen Shot 2016-08-17 at 21.35.11

You should now see the below showing you your 2 PSCs. In my case techlabsso002 and techlabsso003

Steps for vdcrepadmin showpartners

Next type the following command to show the psc partners

vdcrepadmin -f showpartners -h psc1.vmware.local -u administrator -w VMw@re123

Example

vdcrepadmin -f showpartners -h techlabpsc002.techlab.local -u administrator -w Password123!

You could run this showpartners command against all PSCs to map out the topology of the current vSphere domain by re-running this command against each of the PSCs in order to determine all of the partnerships.
You can see that some environments will be installed in an in-line fashion, with each PSC installed against the previous PSC, rather than a hub-and-spoke fashion where all of the PSCs would terminate to a central PSC

Interesting Info as per above screenprint courtesy of VMware engineer Sung Ruo.

As you can see above the replication agreement is listed as LDAPS. Any automatic agreement such as when we join PSC servers together is created as LDAPS as per this 5.5 to 6.0U2 upgrade however if we create any manual replication agreements, these will be created as LDAP going forwards.

In 5.5. the only secure LDAP communication between SSO/PSC nodes are via LDAPS. Thus in automatic replication agreements establishment, LDAPS is used.

In 6.0 and after, we introduced LDAP SASL/SRP binding which go through port 389. LDAP SASL/SRP (or KRB) is the simple and safe to manage between LDAP nodes. This binding mechanism is preferable to LDAPS as the SSL port is difficult to manage/deploy correctly as it depends on PKI. Also, LDAP layer sites below certificate. You need an ID before you can get a cert

Regardless, in 6.0 and after, the server will try SASL/SRP first and fall back to LDAPS if necessary regardless of LDAP/LDAPS in the labeledURI in the replication agreement definition. You also cannot force the replication agreements to use LDAPS in 6.0 and after.

Steps for vdcrepadmin showpartnerstatus

Next type the following command to show the partner replication status.
This CLI is limited to execution only against the local PSC. Using the command to query the replication status from one PSC to a different PSC is not yet supported.

vdcrepadmin -f showpartnerstatus -h localhost -u administrator -w Administrator_password

Example

vdcrepadmin -f showpartnerstatus -h techlabpsc002.techlab.local -u administrator -w Password123!

If you have problems with replication failing, review the /var/log/vmware/vmdird/vmdird-syslog.log or C:\ProgramData\VMware\vCenterServer\logs\vmdird\vmdird-syslog.log file for details. This provides all information related to replication status and the objects that are replicated

What do you see with multisite?

When multisite is installed, you can then log in to each vCenter and see all other vCenters which are set up and control them

Steps for vdcrepadmin createagreement – Example only with 4 PSCs as I only have 2 PSCs

Note: This cannot be used to create replication agreements between disparate (separate) vSphere domains
Map out the topology of the current vSphere domain by re-running the showpartners command against each of the PSCs in order to determine all of the partnerships

For example you have 4 PSCs

psc1
psc2
psc3
psc4

You can use the showservers parameter to get a list of all of the PSCs in the domain.

Navigate to C:\Program Files\VMware\vCenter Server\vmdird and run the below commands

vdcrepadmin -f showpartners -h psc1.vmware.local -u administrator -w VMw@re123
ldap://psc2. vmware.local

vdcrepadmin -f showpartners -h psc2.vmware.local -u administrator -w VMw@re123
ldap://psc1. vmware.local
ldaps://psc3. vmware.local

vdcrepadmin -f showpartners -h psc3.vmware.local -u administrator -w VMw@re123
ldap://psc4. vmware.local
ldaps://psc2. vmware.local

vdcrepadmin -f showpartners -h psc4.vmware.local -u administrator -w VMw@re123
ldap://psc3. vmware.local

With the topology defined, we can now generate new replication agreements. Using the PSCs 1-4 in this section as a model, we need to generate additional replication agreements between:
PSC1.* and PSC3.*
PSC1.* and PSC4.*
PSC2.* and PSC4.*
Use the following command to create a new replication agreement between PSCs to generate a mesh topology:

vdcrepadmin -f createagreement -2 -h Source_PSC_FQDN -H New_PSC_FQDN_to_Replicate -u administrator -w Administrator_Password

For example:

vdcrepadmin -f createagreement -2 -h psc1.vmware.local -H psc3.vmware.local -u Administrator -w VMw@re123

vdcrepadmin -f createagreement -2 -h psc1.vmware.local -H psc4.vmware.local -u Administrator -w VMw@re123

vdcrepadmin -f createagreement -2 -h psc2.vmware.local -H psc4.vmware.local -u Administrator -w VMw@re123

Repeat this operation for additional PSCs until you have created an entire mesh topology.
After completion, repeat Step 5 to confirm that you have generated a mesh topology.
Note: Due to replication time, it may take a few seconds to minutes for a complete mesh topology to be configured.

Steps for vdcrepadmin removeagreement – Example only with 4 PSCs as I only have 2 PSCs

Map out the topology of the current vSphere domain by re-running the showpartners command against each of the PSCs in order to determine all of the partnerships

For example you have 4 PSCs

psc1
psc2
psc3
psc4

You can use the showservers parameter to get a list of all of the PSCs in the domain.

vdcrepadmin -f showpartners -h psc1.vmware.local -u administrator -w VMw@re123
ldap://psc2. vmware.local
ldap://psc3. vmware.local
ldap://psc4. vmware.local

vdcrepadmin -f showpartners -h psc2.vmware.local -u administrator -w VMw@re123
ldap://psc1. vmware.local
ldap://psc3. vmware.local
ldap://psc4. vmware.local

ldap://psc4. vmware.local

vdcrepadmin -f showpartners -h psc3.vmware.local -u administrator -w VMw@re123
ldap://psc4. vmware.local
ldap://psc2. vmware.local
ldap://psc1. vmware.local

vdcrepadmin -f showpartners -h psc4.vmware.local -u administrator -w VMw@re123
ldap://psc3. vmware.local
ldap://psc1. vmware.local
ldap://psc2. vmware.local

Use the following command to remove a replication agreement

vdcrepadmin -f removeagreement -2 -h Source_PSC_FQDN -H PSC_FQDN_to_Remove_from_Replication -u administrator -w Administrator_Password

For example:

vdcrepadmin -f removeagreement -2 -h psc1.vmware.local -H psc3.vmware.local -u administrator -w Administrator_Password

Monitoring the PSC Replication Logs

C:\ProgramData\VMware\vCenter Server\Logs\sso\vmware-sts-idmd.log

This is a good log to use as a “one-stop-shop” for SSO authentication issues. Authentication requests/failures as well as problems with an identity source will post here.

C:\ProgramData\VMware\vCenter Server\Logs\vmafdd\vdcpromo.log

Contains installation errors during configuration of vmdir. Especially useful for errors when adding another PSC to the same SSO domain.

C:\ProgramData\VMware\vCenter Server\Logs\vmafdd\vmafdd.log

C:\ProgramData\VMware\vCenter Server\Logs\vmdird\vmdird-syslog.log

Has information concerning the SSO LDAP instance named vmdir. Problems with ldap operations and replication within SSO can be found here.

C:\ProgramData\VMware\vCenter Server\Logs\vmdird\vdcrepadmin.log

C:\ProgramData\VMware\vCenter Server\Logs\vmdird\vmafdvmdirclient.log

C:\Program Data\VMware\CIS\logs\vmdird\vmdir.log

vCenter and PSC Ports

Ports can also be seen here in the vSphere Documentation Center

The table below shows all the ports which vCenter uses but multisite communication only needs a subset of these ports

What ports need to be open between sites for PSC Multisite Mode?

Some situations exist where communication within the same SSO domain can be blocked by external firewalls. The ports which should be open are

PSC to PSC should be 389, 636, 2012, 2014, 2020 and 7444 (Plus 11711 and 11712 if using 5.5)

VC to VC should be 443

PSC to VC should be 443, 389, 636, 11711,11712 and 2012 (11711 and 11712 legacy)

vCenter to vCenter

techlabvcs004 vCenter to techlabvcs005 vCenter – 443

techlabvcs005 vCenter to techlabvcs004 vCenter – 443

PSC to PSC

techlabsso002 PSC to techlabsso003 PSC – 389, 636, 11711, 11712, and 2012 (11711 and 11712 legacy)

techlabsso003 PSC to techlabsso002 PSC – 389, 636, 11711, 11712, and 2012 (11711 and 11712 legacy)

vCenter to PSC

techlabvcs004 vCenter to techlabsso002 PSC – 443, 389, 636, 2012, 2014, 2020, and 7444 (plus 11711 and 11712 if using 5.5)

techlabvcs004 vCenter to techlabsso003 PSC – 443, 389, 636, 2012, 2014, 2020, and 7444 (plus 11711 and 11712 if using 5.5)

techlabvcs005 vCenter to techlabsso002 PSC – 443, 389, 636, 2012, 2014, 2020, and 7444 (plus 11711 and 11712 if using 5.5)

techlabvcs005 vCenter to techlabsso003 PSC – 443, 389, 636, 2012, 2014, 2020, and 7444 (plus 11711 and 11712 if using 5.5)

Checking what sites and domains the PSCs are running on

You can use the following commands from the PSC to discover the SSO topology

SSO Site

VCSA: /usr/lib/vmware-vmafd/bin/vmafd-cli get-site-name –-server-name localhost
Windows: C:\Program Files\VMware\vCenter Server\vmafdd\vmafd-cli get-site-name –-server-name localhost

SSO Domain

VCSA: /usr/lib/vmware-vmafd/bin/vmafd-cli get-domain-name –-server-name localhost
Windows: C:\Program Files\VMware\vCenter Server\vmafdd\vmafd-cli get-domain-name –-server-name localhost

How can I see what PSC I am connected to?

Under the vCenter Server’s Advanced Setting, there is a property called “config.vpxd.sso.admin.uri” which specifies the PSC it is currently linked to

Home > vCenter Inventory Lists > Your vCenter Server > Manage > Advanced Settings > Look for “config.vpxd.sso.admin.uri”

The second option is to use the vmafd-cli utility which is available on the vCenter Server itself. You will need to run the following command depending on your vCenter Server platform (VCSA or Windows)

/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location –server-name localhost
C:\Program Files\VMware\vCenter Server\vmafdd\vmafd-cli get-ls-location –server-name localhost

SQL Database Password issues during the upgrade

Interestingly we had an error at one site due to special characters

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

Installing vCenter Single Sign-On 5.5 fails if the password for administrator@vsphere.local contains certain special characters

https://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2060746

vSphere 6 Platform Services Controller HA Setups – Enhanced Linked Mode

July 6, 2016 Enhanced Linked Mode, Platform Services Controller No comments

vSphere 6 Platform Services Controller HA Setups – Enhanced Linked Mode

To install vCenter Server with 2 or more external Platform Services Controllers, first install a Platform Services Controller for Windows followed by a second Platform Services Controller joined to the same domain The Platform Services Controller contains the common services, such as vCenter Single Sign-On and the License service, which can be shared across several vCenter Server instances.

You can install many Platform Services Controllers and join them to the same vCenter Single Sign-On domain. Concurrent installations of Platform Services Controllers are not supported. You must install the Platform Services Controllers in a sequence.

1. Enhanced Linked Mode

When you select to join an existing vCenter Single Sign-On domain, you enable the Enhanced Linked Mode feature. Your Platform Services Controller will replicate infrastructure data with the joined vCenter Single Sign-On server.

Note: You can use the appliance or a Windows Server. In the steps below, I have 2 Windows servers I am using as an example

Steps to enable Enhanced Linked Mode on 2 Platform Service Controllers

Install Windows 2012 on a new server
Attach the vCenter 6 ISO to the server
In the software directory, double click the autorun installer

Accept the License Agreement
Choose External Deployment > Platform Services Controller

Put in a FQDN System Network Name for the Platform Services Controller

Ignore the warning below but do make sure you have added a DNS entry for the PSC into your DNS server and that it is joined to the domain

As this is the first PSC, you will need to select Create a new vCenter Single Sign-On domain.
Enter an SSO password

Check the ports which need to be available

Select the destination directory

Choose whether to join the VMware Customer experience program

Double check the details you have entered

Once installed you should see the below screen

Now we need to move on to the second PSC and install this in Enhanced Linked Mode

Install Windows 2012 on a new server
Attach the vCenter 6 ISO to the server
In the software directory, double click the autorun installer

Accept the License Agreement
Choose External Deployment > Platform Services Controller

Put in a name for your second PSC Controller

Ignore the warning below but do make sure you have added a DNS entry for the PSC into your DNS server and that it is joined to the domain

Screen Shot 2016-07-06 at 10.48.47

As this is the second PSC, you will need to Join an existing vCenter Single Sign-On domain and put in the FQDN of the first PSC created earlier
Enter the Single Sign-On password

Accept the certificate

Select to join an existing site which in this case is the Default-First-Site

Check the Ports screen

Choose the Destination Directory

Select whether to join the Customer Experience Program

Check the final details

Finish.
The 2 PSCs are now set up in Enhanced Linked Mode

Determining replication agreements and status with the Platform Services Controller using vdcrepadmin

Useful VMware KB Link here

Use these parameters using the vdcrepadmin CLI:

showservers – Displays all of the PSCs in a vSphere domain.
showpartners – Displays the current partnerships from a single PSC within a vSphere domain.
showpartnerstatus – Displays the current replication status of a PSC and any of the replication partners of the PSC.
createagreement and removeagreement – Allows for creation and removal of additional replication agreements between PSCs within a vSphere domain.

Steps for vdcrepadmin showservers

Open a Command Prompt as Administrator
Navigate to cd c:\Program Files\VMware\vCenter Server\vmdird
Type the below command to show all the PSC Controllers in the vSphere domain

vdcrepadmin -f showservers -h PSC_FQDN -u administrator -w Administrator_Password

Example

vdcrepadmin -f showservers -h techlabpsc002.techlab.local -u administrator -w Password123!

You should now see the below showing you your 2 PSCs

Steps for vdcrepadmin showpartners

Next type the following command to show the psc partners

vdcrepadmin -f showpartners -h psc1.vmware.local -u administrator -w VMw@re123

Example

vdcrepadmin -f showpartners -h techlabpsc002.techlab.local -u administrator -w Password123!

You could run this showpartners command against all PSCs to map out the topology of the current vSphere domain by re-running this command against each of the PSCs in order to determine all of the partnerships.
You can see that some environments will be installed in an in-line fashion, with each PSC installed against the previous PSC, rather than a hub-and-spoke fashion where all of the PSCs would terminate to a central PSC

Steps for vdcrepadmin showpartnerstatus

Next type the following command to show the partner replication status.
This CLI is limited to execution only against the local PSC. Using the command to query the replication status from one PSC to a different PSC is not yet supported.

vdcrepadmin -f showpartnerstatus -h localhost -u administrator -w Administrator_password

Example

vdcrepadmin -f showpartnerstatus -h techlabpsc002.techlab.local -u administrator -w Password123!

If you have problems with replication failing, review the /var/log/vmware/vmdird/vmdird-syslog.log or %VMWARE_LOG_DIR%\vmdird\vmdird-syslog.log file for details. This provides all information related to replication status and the objects that are replicated

Steps for vdcrepadmin createagreement – Example only with 4 PSCs as I only have 2 PSCs

Note: This cannot be used to create replication agreements between disparate (separate) vSphere domains
Map out the topology of the current vSphere domain by re-running the showpartners command against each of the PSCs in order to determine all of the partnerships

For example you have 4 PSCs

psc1
psc2
psc3
psc4

You can use the showservers parameter to get a list of all of the PSCs in the domain.

vdcrepadmin -f showpartners -h psc1.vmware.local -u administrator -w VMw@re123
ldap://psc2. vmware.local

With the topology defined, we can now generate new replication agreements. Using the PSCs 1-4 in this section as a model, we need to generate additional replication agreements between:
PSC1.* and PSC3.*
PSC1.* and PSC4.*
PSC2.* and PSC4.*
Use the following command to create a new replication agreement between PSCs to generate a mesh topology:

vdcrepadmin -f createagreement -2 -h Source_PSC_FQDN -H New_PSC_FQDN_to_Replicate -u administrator -w Administrator_Password

For example:

vdcrepadmin -f createagreement -2 -h psc1.vmware.local -H psc3.vmware.local -u Administrator -w VMw@re123

vdcrepadmin -f createagreement -2 -h psc1.vmware.local -H psc4.vmware.local -u Administrator -w VMw@re123

vdcrepadmin -f createagreement -2 -h psc2.vmware.local -H psc4.vmware.local -u Administrator -w VMw@re123

Repeat this operation for additional PSCs until you have created an entire mesh topology.
After completion, repeat Step 5 to confirm that you have generated a mesh topology.
Note: Due to replication time, it may take a few seconds to minutes for a complete mesh topology to be configured.

Steps for vdcrepadmin removeagreement – Example only with 4 PSCs as I only have 2 PSCs

Map out the topology of the current vSphere domain by re-running the showpartners command against each of the PSCs in order to determine all of the partnerships

For example you have 4 PSCs

psc1
psc2
psc3
psc4

You can use the showservers parameter to get a list of all of the PSCs in the domain.

vdcrepadmin -f showpartners -h psc1.vmware.local -u administrator -w VMw@re123
ldap://psc2. vmware.local
ldap://psc3. vmware.local
ldap://psc4. vmware.local

vdcrepadmin -f showpartners -h psc2.vmware.local -u administrator -w VMw@re123
ldap://psc1. vmware.local
ldap://psc3. vmware.local
ldap://psc4. vmware.local

ldap://psc4. vmware.local

vdcrepadmin -f showpartners -h psc3.vmware.local -u administrator -w VMw@re123
ldap://psc4. vmware.local
ldap://psc2. vmware.local
ldap://psc1. vmware.local

vdcrepadmin -f showpartners -h psc4.vmware.local -u administrator -w VMw@re123
ldap://psc3. vmware.local
ldap://psc1. vmware.local
ldap://psc2. vmware.local

Use the following command to remove a replication agreement

vdcrepadmin -f removeagreement -2 -h Source_PSC_FQDN -h PSC_FQDN_to_Remove_from_Replication -u administrator -w Administrator_Password

For example:

vdcrepadmin -f removeagreement -2 -h psc1.vmware.local -h psc3.vmware.local -u administrator -w Administrator_Password

vSphere 6 Platform Services Controller

February 7, 2016 vSphere 6 No comments

What is the Platform Services Controller?

Starting with vSphere 6.0, all prerequisite services for running vCenter Server and the vCenter Server components are bundled in the VMware Platform Services Controller. You can deploy vCenter Server with an embedded or external Platform Services Controller, but you must always install or deploy the

Platform Services Controller before installing or deploying vCenter Server

Installation Scenarios (Embedded or External)

When you install vCenter Server with an embedded Platform Services Controller, or deploy the vCenter Server Appliance with an embedded Platform Services Controller, vCenter Server, the vCenter Server components, and the services included in the Platform Services Controller are deployed on the same system.
When you install vCenter Server with an external Platform Services Controller, or deploy the vCenter Server Appliance with an external Platform Services Controller, vCenter Server and the vCenter Server components are deployed on one system, and the services included in the Platform Services Controller are deployed on another system.

Components included in the vCenter Server and vCenter Server Appliance installations

The VMware Platform Services Controller group of infrastructure services contains:

vCenter Single Sign-On
License service
Lookup Service
VMware Certificate Authority.

The vCenter Server group of services contains:

vCenter Server
vSphere Web Client
Inventory Service
vSphere Auto Deploy
vSphere ESXi Dump Collector
VMware vSphere Syslog Collector on Windows
VMware Sphere Syslog Service for the vCenter Server Appliance

Scenario 1: vCenter with an embedded PSC

Advantages of vCenter with an embedded PSC

The connection between vCenter Server and the Platform Services Controller is not over the network and vCenter Server is not prone to outages because of connectivity and name resolution issues between vCenter Server and the Platform Services Controller.
You will need fewer Windows licenses.
You will have to manage fewer virtual machines or physical servers.
You do not need a load balancer to distribute the load across Platform Services Controller.

Disadvantages of vCenter with an embedded PSC

There is a Platform Services Controller for each product which might be more than required. This consumes more resources.
The model is suitable for small-scale environments

Scenario 2: vCenter Server with an External Platform Services Controller

vCenter Server and the Platform Services Controller are deployed on separate virtual machine or physical server. The Platform Services Controller can be shared across several vCenter Server instances. You can install a Platform Services Controller and then install several vCenter Server instances and register them with the Platform Services Controller. You can then install another Platform Services Controller, configure it to replicate data with the first Platform Services Controller, and then install vCenter Server instances and register them with the second Platform Services Controller.

Advantages of vCenter Server with an External Platform Services Controller

Less resources consumed by the combined services in the Platform Services Controllers enables a reduced footprint and reduced maintenance
Your environment can consist of more vCenter Server instances

Disadvantages of vCenter Server with an External Platform Services Controller

The connection between vCenter Server and Platform Services Controller is over the network and is prone to connectivity and name resolution issues.
If you install vCenter Server on Windows virtual machines or physical servers, you need more Microsoft Windows licenses.
You must manage more virtual machines or physical servers

Scenario 3: Mixed Operating Systems

A vCenter Server instance installed on Windows can be registered with either a Platform Services Controller installed on Windows or a Platform Services Controller appliance.

Example of a Mixed Operating Systems Environment with an External Platform Services Controller on Windows

Example of a Mixed Operating Systems Environment with an External Platform Services Controller Appliance

Both vCenter Server and the vCenter Server Appliance can be registered with the same Platform Services Controller within a domain
Having many Platform Services Controllers that replicate their infrastructure data, allows you to ensure high availability of your system.
If an external Platform Services Controller with which your vCenter Server instance or vCenter Server Appliance was initially registered, stops responding, you can repoint your vCenter Server or vCenter Server Appliance to another external Platform Services Controller in the domain

Enhanced Linked Mode Overview (http://kb.vmware.com/kb/210854)

Enhanced Linked Mode connects multiple vCenter Server systems together by using one or more Platform Services Controllers.
Enhanced Linked Mode lets you view and search across all linked vCenter Server systems and replicate roles, permissions, licenses, policies, and tags.
When you install vCenter Server or deploy the vCenter Server Appliance with an external Platform Services Controller, you must first install the Platform Services Controller.
With Enhanced Linked Mode, you can connect not only vCenter Server systems running on Windows but also many vCenter Server Appliances. You can also have an environment where multiple vCenter Server systems and vCenter Server Appliances are linked together.

During installation of the Platform Services Controller, you can select whether to create a new vCenter Single Sign-On domain or join an existing domain. You can select to join an existing vCenter Single Sign-On domain if you have already installed or deployed a Platform Services Controller, and have created a vCenter Single Sign-On domain. When you join an existing vCenter Single Sign-On domain, the data between the existing Platform Services Controller and the new Platform Services Controller is replicated, and the infrastructure data is replicated between the two Platform Services Controllers

If you install vCenter Server with an external Platform Services Controller, you first must deploy the Platform Services Controller on one virtual machines or physical server and then deploy vCenter Server on another virtual machines or physical server. While installing vCenter Server, you must select the external Platform Services Controller. Make sure that the Platform Services Controller you select is an external standalone Platform Services Controller. Selecting an existing Platform Services Controller that is a part of an embedded installation is not supported and cannot be reconfigured after the deployment.

Repoint the Connections Between vCenter Server and Platform Services Controller

Joining external Platform Services Controller instances in the same vCenter Single Sign-On domain, ensures high availability of your system.

If your environment contains external Platform Services Controller instances within a site that replicate the infrastructure data within a single domain, you can redirect the vCenter Server instances to another Platform Services Controller. If an external Platform Services Controller stops responding, you can repoint the vCenter Server instances to another Platform Services Controller within the same domain.

If you want to distribute the load of an external Platform Services Controller, you can repoint some of the vCenter Server instances to other Platform Services Controller instances in the same domain.
You can repoint the connections between a vCenter Server instance and the external Platform Services Controller instances in different vCenter Single Sign-On sites if the Platform Services Controller instances replicate the infrastructure data within a single domain. A site in the VMware Directory Service is a logical container in which you can group Platform Services Controller instances within a domain. You can name the sites in an intuitive way for easier implementation. Currently, the use of sites is for configuring Platform Services Controller High Availability groups behind a load balancer. vCenter Single Sign-On sites can be, for example, external Platform Services Controller instances that are deployed in multiple physical locations.

For more information, see the VMware knowledge base article at
http://kb.vmware.com/kb/2131191

Prerequisites

Verify that the external Platform Services Controller instances are within a single site and replicate the infrastructure data within a single domain.

Procedure

Log in to the vCenter Server instance.
For vCenter Server Appliance, log in to the vCenter Server Appliance shell as root
For a vCenter Server instance installed on Windows, log in as an administrator to the virtual machine or physical server that you installed vCenter Server on.
Run the cmsso-util script.
cmsso-util repoint –repoint-psc psc_fqdn_or_static_ip [–dc-port port_number]
where the square brackets [ ] enclose the command options.
Here, psc_fqdn_or_static_ip is the system name used to identify the Platform Services Controller. This system name must be an FQDN or a static IP address.
Use the –dc-port port_number option if the Platform Services Controller runs on a custom HTTPS port. The default value of the HTTPS port is 443.
Log in to the vCenter Server instance by using the vSphere Web Client to verify that the vCenter Serveris running and can be managed.

The vCenter Server instance is registered with the new Platform Services Controller

Tag Archive for vsphere6

Rolling back and recovering from failed vSphere 6 and external multisite PSC upgrades

PSC 6 Replication for multi-site setups

vSphere HTML 5 Web Client Fling

Upgrading vSphere 5.1 with embedded SSO to vSphere 6 with external multi-site Platform Services Controllers

vSphere 6 Platform Services Controller HA Setups – Enhanced Linked Mode

vSphere 6 Platform Services Controller

Electric Monk

Don't think about what can happen in a month. Don't think what can happen in a year. Just focus on the 24 hours in front of you and do what you can to get closer to where you want to be :-)

Search

Calendar

Social Media and RSS

vExpert

Recent Posts

Archives

Categories

Fatcow Webhosting

Tag Archive for vsphere6

Rolling back and recovering from failed vSphere 6 and external multisite PSC upgrades

PSC 6 Replication for multi-site setups

vSphere HTML 5 Web Client Fling

Upgrading vSphere 5.1 with embedded SSO to vSphere 6 with external multi-site Platform Services Controllers

vSphere 6 Platform Services Controller HA Setups – Enhanced Linked Mode

vSphere 6 Platform Services Controller

Electric Monk

Don't think about what can happen in a month. Don't think what can happen in a year. Just focus on the 24 hours in front of you and do what you can to get closer to where you want to be :-)

Search

Calendar

Social Media and RSS

vExpert

Recent Posts

Archives

Categories

Tags

Fatcow Webhosting