As I work closely with VMware Support, it’s clear that issues and confusion around vSphere 6.x certificates are still very much a pain-point for customers.
I’ve spoken a bit about this topic in the past (but have been meaning to get back to it). You can see my previous posts below: (Note: even though they say 6.0 they are applicable for 6.5 too)
What I want to achieve by this post is to hopefully dispel some of the confusion. First, repeat the title of this post to yourself – “Just because you can, doesn’t mean you should.”
Just because you can replace any and all certificates in a vSphere environment, doesn’t mean necessarily should.
The only question you need to be able to answer is – “What problem am I trying to solve?”
Long story short, for the majority of use cases, replacing the Machine SSL certificate on each vCenter / PSC should be sufficient. Keep reading for more information.
Continue reading “vSphere 6.x Certificates – Just because you can, doesn’t mean you should.”
In vSphere 6.x all services and components have Service Registration details recorded in the VMware Directory Service of the Platform Services Controller.
Each Service Registration can contain one or more Endpoint entries.
Each Endpoint may contain an SSL Trust value.
The SSL Trust value must always match the current Machine SSL certificate of the PSC or VC or Embedded node it refers to.
If you use the Certificate-Manager from 6.0 U1b or later – the tool will take care of updating these entries. If you replace the Machine SSL manually or have used the tool before 6.0 U1b then you may encounter this issue.
Continue reading “vSphere 6.x SSL Trust Anchors”
If a migration fails or you wish to roll back a successful migration then the basic steps are as follows:
1 Shutdown the Appliance 6.0 that has resulted from the migration
2 Power on the original source Windows 5.5 machine
3. The Windows machine will have lost it’s trust with the Active Directory Domain so you may need to log into the Windows machine as a local Administrator and re-join the Active Directory Domain and reboot the Windows machine.
Note: This is because the resulting vCenter Server Appliance 6.0 will have overwritten the Windows vCenter computer account on the AD.
Important: If you have other solutions that have been upgrade for compatibility with vSphere 6.0 these may cease to work after the rollback and would need to be rolled back themselves. This includes ESXi 6.0 as this is not manageable from a vCenter Server 5.5. Also be careful that you do not have Virtual Machines running Hardware Version 11 as these VMs cannot run on ESXi 5.5 or older.
I’ll go into a little more detail on different typologies as the larger and more distributed the environment the more caution and planning is needed
Continue reading “Handling vCenter Server Migration failure scenarios”
At long last the much anticipated vCenter Server Windows to Appliance Migration utility has arrived.
Dubbed vCenter Server Appliance 6.0 U2m (no prize for guessing what the M stands for)
This first release allows you to migrate a Windows based vCenter Server 5.5 environment to a vCenter Server Appliance 6.0 U2 environment.
Important: You cannot perform a horizontal migration. i.e. You cannot migrate a Windows vCenter Server 6.0 to a vCenter Server 6.0 Appliance. It must be a migrate and upgrade.
Also you cannot change topology during a migration. i.e. A vCenter Server 5.5 with Embedded SSO will result in a vCenter Server 6.0 with Embedded PSC
Continue reading “vCenter Server 5.5 Windows to Appliance 6.0 Migration”
In this post I’ll explain how to deploy and configure an F5 Load Balancer for use with PSC 6.0 High Availability using a script to configure the F5. I got tired of manually configuring F5 Load Balancers for testing and lab building so I scripted the configuration and am sharing it here.
Disclaimer: The configuration of a 3rd Party Load Balancer is not supported by VMware. The 3rd party vendor should be engaged for support. The script in this post is not supported by VMware. Use at your own risk.
I used F5 BIG-IP v12 but have also tested on v11. Other versions may or may not work.
Continue reading “Automatically Configuring an F5 BIG-IP Load Balancer for PSC 6.0 HA”
In this series I’m going to outline, step by step, how to replace your vSphere 6.0 certificates using VMCA as a Subordinate CA and also exclusively using your own CA and not leveraging VMCA.
Replacing your vSphere 6.0 Certificates using VMCA as a Subordinate CA
NEW: Replacing your vSphere 6.0 Certificates using your own CA (no VMCA)
Replacing your vSphere 6.0 Certificates using a Hybrid model (Coming Soon)
I’m not a fan of using a custom SSO Domain name. There’s little to no reason for changing from “vsphere.local”. The ability to customise the SSO Domain name was introduced in vSphere 6.0.
Unless you have an iron-clad reason to change it, don’t.
Continue reading “Caution: Custom “vsphere.local” domains”
One increasingly common question VMware Support receives from customers is around the topic of going from vCenter Server 5.5 with an embedded SSO to vCenter Server 6.0 with an external PSC.
Continue reading “Migrating from Embedded SSO to External PSC”
In vSphere 6.0 you have Solution Users that internal vCenter/PSC services use to interact. These Solution Users use certificates to log into services and components instead of maintaining passwords.
You have the option to replace these certificates with your own certificates or use VMCA issued certificates.
To solve a separate problem, the ability to control the Certificate Subject information in the Solution Users was added in an update to the vSphere Certificate-Manager with 6.0 U1b that allows the user to specify the Subject information for each Solution User.
Update: vSphere 6.0 U3 has made improvements to the Certificate-Manager to prevent you from getting into this issue. You will be only asked to complete one cfg file and the tool will automatically make a value unique using the Solution User ID.
Continue reading “Caution: Solution User Certificates in vSphere 6.0”
Configuring PSC HA to utilise SSL Pass-through basically means we don’t have any SSL Certificate on the Load Balancer VIP. To achieve this all PSC’s in the PSC HA Cluster are required to present the same certificate.
It also means that if you suspect your load balancer may be the cause of an issue, you can make vCenter bypass the load balancer directly to a PSC by creating a hosts file entry on the vCenter which maps the IP of a PSC to the Load Balanced FQDN.
Continue reading “Configuring PSC 6.0 High Availability with SSL Pass-through”