Tag Archives: vSphere 7.0

vSphere 7.0 Certificate Management

vCenter 7.0 brings many new features, one of which is a much smoother certificate management experience. There are now 4 main ‘modes’ for certificate management.

These are; Fully Managed Mode, Hybrid Mode, Subordinate CA Mode and finally Full Custom Mode. There is a great article here from Bob Plankers explaining the difference between each.

As mentioned in Bob’s blog, Hybrid Mode is the recommend option, and I will show you that process here in this blog.

Firstly, in your vSphere Client, browse to Administration > Certificates. Then click Actions and select ‘Generate Certificate Signing Request (CSR)’.

Complete the required fields with your information, making sure you have at least added the common name as a Subject Alternative Name to avoid issues with modern browsers. Click Next.

Finally, copy or download your CSR to generate the certificate on the CA of your choosing. Click Finish when ready.

Generate CSR 
1 Enter Info 
2 Generate CSR 
Generate CSR 
Copy or download the CSR below and provide it to your Certificate Authority 
to be signed. 

Once you have your certificate, return to Administration > Certificates and this time select ‘Import and Replace Certificate’.

You then need to select the second option. This may seem slightly deceiving but it effectively is the option you need when you have generated the CSR from vCenter like this.

Now browse and select both your freshly produced certificate, and the root certificate or certificate chain if you have issuing CA’s.

Replace Certificate 
1 Choose appropriate option 
2 Replace with signed certificate 
Replace with external CA certificate 
vCenter server services will be automatically restarted after successful replacement Of the machine SSL certificate. 
Machine SSL Certificate 
Chain of trusted root certificates 
Version: 3 (Ox2) 

Hit replace, then wait for the Web Client to restart with the new certificate.

Now one final step is needed to complete Hybrid Mode. You need to download the VMCA Root certificate from https://<vCenterFQDN by clicking the ‘Download trusted root CA certificates’ option and distributing it to your vSphere admins.

Once distributed and installed on your vSphere admins client devices, they should not get certificate errors when either browsing to vCenter or the hosts it manages.

You could however, get this error due to the default certificate having a 5 year validity period and not being within the new ‘standard’ of 398 days.


If you receive this, you will want to adjust the vpxd.certmgmt.certs.daysValid value in the vCenter Advanced Settings. It defaults to 1825, making it 365 (one year) will stop this.

You can then renew the certificate on each host by clicking ‘Renew’ in the Configure > Certificates menu –

Before (5 years) –

After (1 Year)-

If you want to do this renewal via PowerCLI (because…well why wouldn’t you!?) there is a nice function here by Ankush Sethi which does a great job.

Thanks for reading.

Deploying and Connecting A Key Management Server to vCenter

Is it secure?  

This has to be one of the first things you consider with any technology solution or decision today.  So when I was lucky enough to receive a NFR license from HyTrust for their KeyControl Key Management System I was excited to get this into my lab so I can make use of VMware’s vSAN and VM Encryption.

In this post I will be going through the process of deploying a HyTrust Key Control appliance and creating a trust with vCenter.  It was surprisingly straight forward and I was up and running in no time at all!

Firstly, deploy the OVA to an ESXi Host or Cluster that isn’t going to be managed by the Key Control appliance.  You don’t want your encryption keys in the same place as the objects you are encrypting!  

Follow the OVF deployment wizard, providing the details as prompted, and once the appliance is online, complete the final configuration steps to finish the installation.

You will then be met with this screen – 

System setup has completed successful ly . 
System Conf iguration Sunmry : 
Hostnam: smt-lab-kms-al 
Phnagemnt IP Address: 1B . Zag . 15 . 15 
From your browser, please go to https ://IB .ZBB . 15 . 15

Now, browse to the web GUI and log in using the default credentials.  You will then be prompted to set your own, followed by SMTP and online monitoring configuration options.

Once this is done and you are logged in there are a few KMIP settings you need to adjust in order for it to be ready to connect to vCenter as a Key Provider – 


Protocol = Version 1.1

Actions • 
Host Name: 
Client Certificates 
Version 1.1 
O Infinite 
Connections Will use TLS 1.2 if set to Enabled 
Certificate Type: 
Log Level: 
Restnct TLS] 
Custom nex value

Below is a link to a HyTrust document with the details for vSphere 6.5.  I used this for deployment in my vSphere 7 environment. You can find it here.

You will also want to apply a license file.  This is done via; ‘Settings > License’, by way of uploading the license file you have been issued.

This completes a basic configuration that is now ready to connect to vCenter.  If you are deploying outside of a lab environment, you are going to want to review your installation appropriately for the environment it is intended for.

So over to the Web Client.  Select the vCenter Server object, select ‘Configure > Security > Key Providers’ and hit ‘Add Standard Key Provider’.

Summary Monitor 
Con figure 
Key Providers 
Message of the Day 
Advanced Settings 
Authentication Proxy 
vCenter HA 
Trust Authority 
Ke Providers 
Alarm Definitions 
Scheduled Tasks 
Storage Providers 
Internet Connectivity 
Hosts & Clusters 
V Ms 
Linked vCenter Server Systems 

You will then want to give it a name, followed by the requested information.  Once done, click ‘Add Key Provider’

Add Standard Key Provider 
HyTrust Key Control 
Proxy configuration (optional) 
Password protection (optional) 

You will receive the following prompt to confirm you want to from the Key Provider you have entered. Click ‘Trust’

This will have now created a Key Provider, but will show that it is not connected and has a certificate issue.  So next we need to set up the trust.

This can be done by clicking ‘Establish Trust’ and selecting ‘Make KMS trust vCenter’

Key Providers 
Key Provider 
HyTrust Key Control (default) 
Provider By Trust Key Control - 
KMS trust vCenter 
Make KMS trust vCenter 
Upload Signed CSR Certificate 
vcenter Trust KMS 
Make vCenter Trust KMS 
Upload KMS Certificate 
Connection Status 
1 KMS not connected 
Key Management Servers 
1 certificate issue(s) 
vCenter Certificate 
Connection Status 
Client trusts server 
KMS Certificate 
@ Valid until: Dec 31, 2049 

In my lab, I have gone with the option of creating a CSR and having the KMS issue a certificate – 

Make KMS trust 
1 Choose a method 
2 Estaalish Trust 
Choose a method 
Choose a method to make the KMS trust the vCenter based on the KMS vendor's 
requirements Once the trust is established, all replicas in the same KMS cluster will 
also trust the vCenter_ 
C) vCenter Root CA Certificate 
Download the vCenter root certificate and upload it to the KMS. All certificates 
signed by this root certificate will be trusted by the KMS 
C) vCenter Certificate 
Download the vCenter certificate and upload it to the KMS. 
C) KMS certificate and private key 
Upload the KMS certificate and private key to vCenter 
New Certificate Signing Request (CSR) 
Submit the vCenter-generated CSR to the KMS then upload the new KMS- 
signed certificate to vCenter. 
Make KMS trust 
1 Choose a method 
2 submit CSR to KMS 
Submit CSR to KMS 
Copy or download the CSR below, make it available to KMS, and have the KMS 
sign the certificate. 
@ The trust won't be established after you finish this wizard. Go to the 
KMS to upload the CSR, have the KMS sign the certificate, and upload 
it to the vCenter to establish the trust. 

Download the CSR using the option available.  This will be in the .pem format which is exactly what you need.

Now over to the HyTrust appliance, load the CSR we downloaded into the wizard, as well as a name, and hit create.  This is via the KMIP menu and selecting ‘Actions’ followed by ‘Create New Client Certificate’.

Actions • 
Valid From 
Client Certificates 
Create a New Client Certificate 
Load File 
Certificate Name 
Expires In (day 
Certificate Name 
Certficate Name 
Certificate Expiration 
Certificate Signing Request (CSR) 
CSR needs to be in beseö4 encoded PKCS#IO 
Certificate Password 
Certificate Password 
Confirm Password 
Confirm Password 

Once this is done, select the certificate and click ‘Actions’ and select the ‘Download Certificate’ option.  This again will come in the requested .pem format.

Client Certificates 
Create Certificate 
Delete Certificate 
Delete All Certificates 
Download Certificate

Back to vCenter, we now need to upload the certificate using the ‘Establish Trust’ option and selecting ‘Upload Signed CSR Certificate’.

Provider By Trust Key Control - 
KMS trust vCenter 
Make KMS trust vCenter 
Upload Signed CSR Certificate 
vcenter Trust KMS 
Make vCenter Trust KMS 
Upload KMS Certificate 
Key Management Servers 
Connection Status 
Client trusts server 
vCenter Certificate 
KMS Certificate 
@ Valid until: Dec 31, 2049

Once uploaded, you will see that the connection is now showing as connected and has a valid certificate.

Key Providers 
Key Provider 
HyTrust Key Control (default) 
Provider By Trust Key Control - 
Connection Status 
@ Connected 
@ Valid 
Key Management Servers 
Connection Status 
@ Connected 
vCenter Certificate 
@ Valid until: Aug 9, 
KMS Certificate 
@ Valid until: Dec 31, 2049

This is now setup and ready to begin looking at VM and vSAN Encryption.  Check out the next post which will go into both these options in more detail.

Thanks for reading.

Creating Virtual Distributed Port Groups Using PowerCLI

I recently needed to create a new Distributed Port Group and set a specific load balancing policy on an existing Distributed Switch. Nothing to exciting, but a task many have to complete. As this is a common repeatable task, i put together this short .ps1 to allow a repeatable way of completing this.

You can find the file here on GitHub

Just populate the Variables section with required information like so…

Save the file, then run the the .ps1 file from PowerShell prompt. (Ensure you have the PowerCLI Module installed; see my previous post)

Note you must add .\ to the beginning of the file name if you are executing the file from the directory you’re already in

Enter credentials with sufficient privilege in vCenter.

You will then see an output similar to this:

If you now take a look in the Web Client you will see the freshly created Distributed Port Group.

Creating just a single portgroup could potentially be quicker in the Web Client. What isn’t quicker, is multiple.

If you have a requirement to create multiple Distributed Port Groups on a vDS, you can use this script to do so in one go.

Just populate the Variables section with required information like above, then run the the .ps1 file from a PowerShell prompt. (Ensure you have the PowerCLI Module installed; see this post.

This uses and Array Table to build your source data, in this example, the PortGroup Name and VLAN ID for each. You can add further rows (more Port Groups) to the array by repeating the line in the red box, or add additional attributes by repeating the text from the green box on each line.

There are many ways you could modify this script to change the source of data, including ‘Get-Content’ from a .txt file for instance.

You can get the script here.

This is just one way to create Port Groups using PowerCLI, have a play around and make it work for you!

Thanks for reading.

vCenter Tag Administration Permissions

The use of VMware tags recently became a requirement for some of my colleagues in an environment that was inherited.  They were faced with being unable to create Tags & Tag Categories or Assign and Delete them, despite ‘having admin rights’.

Upon investigation it became apparent that while the admins had been granted the Administrators Role at the vCenter Object Level, they had had not been granted sufficient rights at the Global Permissions Level, or any rights for that matter.

The following graphic shows the vSphere Inventory hierarchy.

Link to VMware’s article – Here

As you can see from the graphic, assigning privileges at the Global Level is required to manage Tags and additionally, Content Libraries.

You can see below a vSphere Admin, who has the Administrator Role assigned at the vCenter Level, is not able to select the New, Edit, Delete or Add Permission options for Tags or Tag Categories.

In this scenario there were two different permission requirements, one for a vSphere Admin team, the other for a Storage team both of which could be addressed by two existing roles; Administrators and Tagging Admin.  You could of course create a custom role should you have a requirement to do so. Here are the privileges assigned to the tagging admin role for reference.

The vSphere Admin Team required the Administrator Role at the Global Level (root object) so they could manage Content Libraries and Tags, while the Storage Team required the ability to Create and Assign Tags only.

You can assign permissions to a user or a group from multiple Identity Sources, in this scenario, an Active Directory source.  You will need to do this from an account that already has the Administrator Role at the Global Level.  By default, the administrator@vsphere.local account has this privilege. (replace the domain as needed if you have used a different SSO domain name)

From the Menu, select ‘Administration’ and select the ‘Global Permissions’ option in on the left-hand side.

From here, select the Add Permission icon.

You can now select the domain of the user or group you wish to add from the drop-down list and begin to type the name of that user or group.  It will begin to narrow your selection as you type. 

Select the user.

Now select the appropriate role and select the ‘Propagate to child object’ option.

If you have multiple users, groups or roles you need to assign, repeat the process.

You will now see both permissions in the Global Permissions menu.  If logged in, you will need to log out and back in for this to take effect. Both scenarios are shown.

If you now return to the Tags & Custom Attributes menu, logged in as a user from either of these groups, you will see that the New, Edit, Delete or Add Permission options for Tags or Tag Categories are now available.

Note: Providing a user or group privileges at the Global Permissions Level and selecting, ‘Propagate to child objects’ will give that user or group the privilege’s on the child objects such as vCenter, Cluster, VM and Datastore. 

This can be useful if you have multiple vCenters in Enhanced Linked Mode (ELM) as you only need to apply it once.

vCenter –

Host –

Datastore –

Further information can be found in the following VMware article which explains how you can grant permissions on a Tag object, rather than at the Global or vCenter Levels to give you further granualar control.


Inheriting any environment can be difficult and full of unknowns, hopefully this could help you if you are experiencing a similar issue!

Thanks for reading!

vSphere 7 / VCF4.0 HOLs now available

Want to get hands on with vSphere 7 and VMware Cloud Foundation 4.0 (VCF4) but don’t have a either access to it or a HomeLab to install it?

VMware have announced the availability of both HOLs! Check out the link below to find out more and the links to these labs.


These are a great way to gain experience with VMware products. Check it out!

Deploying Custom Virtual Standard Switches for Management

I have been rebuilding my lab hosts a lot lately! Once because I fiddled too much with my vSAN cluster and killed it… Another more interesting occasion being the release of VCF 4.0 on VMUG and beginning the deployment of this!

I prefer to use Standard vSwitches for my management network in my labs and needed a quick and easy way to get the hosts back online with minimal effort. One thing I don’t like is seeing vSwitch0… I prefer seeing useful and descriptive naming, like I’m sure many others do!

Below are a few lines of PowerCLI to quickly and easily create a new vSwitch using a spare VMNIC (you should be using more than one physical NIC for resiliency), then migrate the Management VM Kernel adapter and original VMNIC over to it, followed by a clean up of vSwitch0.

<#ESX Host to target#> $ESXHost = "ESX102.lab.local"
<#Name of the Management Switch#> $ManagementSwitchName = "vSS_Management"
<#vmnic to be used for Management Switch#> $ManagementSwitchNIC = "vmnic1"
<#MTU size for Management Switch#> $ManagementSwitchMTU = "1500"
<#Name of the Portgroup for the VMKernel Adapter#> $ManagementVMKPortGroupName = "vSS_VMK_Management"
<#Name of the PortGroup for VM's#> $ManagementPGSwitchName = "vSS_PG_Management"
<#Management VMKernal Nic to be migrated#>$vNic = "vmk0"
<#Management VMKernel assosiated pNic#>$PhysiscalNic = "vmnic0"
<#Old vSwitch#> $OldvSwitch = "vSwitch0"
#New Standard Management Switch
$NewSwitch1 = New-VirtualSwitch -VMHost $ESXHost -Name $ManagementSwitchName -Nic $ManagementSwitchNIC -mtu $ManagementSwitchMTU
$NewSwitch1 | New-VirtualPortGroup -Name $ManagementVMKPortGroupName -VLanId 0
$NewSwitch1 | New-VirtualPortGroup -Name $ManagementPGSwitchName

Once the new vSwitch is in place, the next block of code migrates the Management VM Kernel adapter and the VMNIC over to it.

#Migrate Mangement VMKernel Adapter
$mgmt_vmk = Get-VMHostNetworkAdapter -VMHost $ESXhost -Name $vNic
$pnic = Get-VMHostNetworkAdapter -VMHost $esxhost -Name $PhysiscalNic
Add-VirtualSwitchPhysicalNetworkAdapter -VirtualSwitch $NewSwitch1 -VMHostPhysicalNic $pnic -VMHostVirtualNic $mgmt_vmk -VirtualNicPortgroup $ManagementVMKPortGroupName -Confirm:$false

Now the clean up block. This removes the now redundant vSwitch0.

#Remove Original vSwitch0
Remove-VirtualSwitch -VirtualSwitch (Get-VirtualSwitch -VMHost $ESXHost  | Where-Object {$_.Name -eq $OldvSwitch}) -Confirm:$false

Note: If you have more than two VMNIC’s associated with the vSwitch, you will need to adjust this to include them.

Thanks for reading.

Downgrading VM Hardware Version

Having to downgrade a VM’s hardware version or compatibility level is something that comes up now and again.  There are many reasons you may need to do this; being it moving a VM to an environment with an older version of vSphere, or having issues following a planned upgrade that you now no longer have a snapshot for.

There are 3 VMware supported ways to downgrade which you can find in this VMware KB – https://kb.vmware.com/s/article/1028019

Let’s take a look at the options.

Revert to a previous snapshot.

Now this is only of use if you took a snapshot in the first place… If this is a planned upgrade, I would hope one was taken! However, you could have performed the upgrade and removed the snapshot before discovering the defect which is leading you to return to a lower hardware version.

If you do have an appropriate snapshot, reverting to it is a viable option.  You can achieve this by the usual means.  Right click the VM, hover over the Snapshot option and either select revert to snapshot, or manage snapshots if you have more than one or aren’t sure.

VMware vCenter Converter.

Another option is the VMware vCenter Converter.  This is a free tool available from VMware that can perform a number of conversion tasks.  One of these is the ability to copy the original VM to ‘another’ but allowing changes to the VM ‘hardware’ such as the hardware version, disk sizes, disk provisioning (Thick or Thin), CPU and memory changes and much more. (more info here —-). You also get the option to power off the original and power on the new as it completes.  This method reduces downtime but can be heavy going with high IO machines , in fact I wouldn’t do it with high IO machines.

Once your conversion is complete, you can then delete original. This is a great option with a simple to follow wizard, however it can take a fair amount of time to complete depending on the size of the VM.

Original VM, Hardware Version 14.

During the conversion you will need to have either renamed the original VM inventory name, or use a temporary name during the conversion, which, you can return to the original name once you delete the original.

You have the option to select any hardware version

Now power off, rename back to the original name and perform a storage vMotion to rename the files on the datastore.

Detaching and Re-Attaching the disks.

This is my personal preferred method! If I only need to modify the VM hardware version, this is my go to.  This involves creating a new VM with no hard disks and then attaching the disks from the original VM. This approach is particularly useful when your VM has large disks.  Lets go through the process.

Create a New Virtual Machine giving it a temporary name, the required hardware version, and  matching CPU, memory, SCSI controllers and network adapters.  One additional setting you will need to take care with is that you match the Firmware option.  Don’t worry about adding any hard disks. NB: If you have any dependencies for the original MAC addresses, if you take this route, you will need to note them and manually assign them to the new adapaters.

Now, ensure you have a backup, as you should do before any work, and take a snapshot the original VM to give you a fast rollback should you need it (quiesce the memory if you so wish). Power off the VM and rename it, <name>_old for instance.

Edit the VM settings and note the location of the disk(s).

Detach the hard disk(s), ensuring NOT to tick the option to delete from datastore (that will ruin your day…) 

Now edit the new VM settings and attach an existing disk

Browse to the disk(s) location and attach the disks starting with the OS disk first.

Power on and you have now downgraded the hardware version. If you are using static IP addresses, be prepeared to reassign these.

So we now have a bit of cleaning up to do… The inventory name is incorrect and the disks aren’t stored with the VM.  

You now need to power the VM off, rename it to the original name and perform a storage vMotion to rename and move all the VM files and disks into a single folder on the datastore.

When conducting any change, always ensure you have a backup and a valid rollback should something not go as planned!

Thanks for reading.

Installing PowerCLI using Install-Module

I was asked recently ‘Do we have PowerCLI downloaded?’.  Yes, we may, but it could be anywhere and it is likely an outdated version.

There is no need to download the installer! You can install PowerCLI using the Install-Module cmdlet in Windows PowerShell. (Providing you have an internet connection!) Below we will look at the steps required to install the latest version of PowerCLI on your system.

From an elevated PowerShell prompt run the following –

Install-Module VMware.PowerCLI.

If you don’t already have it installed, you will be prompted to install the NuGet Provider. Type ‘y’ and enter to continue.

You will get a further prompt to confirm you are happy to install a module from the ‘PSGallery’. Again, ‘y’ and enter to continue.

The PowerCLI Module will then begin to install. It will cycle through installing multiple dependent packages which will take a few minutes. Sit back and wait…

Once returned to the prompt, you can confirm the installation by running –

Get-Module VMware.PowerCLI -List Available | FL

You have now installed PowerCLI version You will likely end up installing a later version.

Last step, load the module for use

Import-Module VMware.PowerCLI

You’re ready to go! But…

Not every system you need to use this module on will have internet access. In this, case the ‘Save-Module’ cmdlet is your friend.

Save-Module -Name VMware.PowerCLI -Path <Path to directory>

The module will then proceed to be downloaded into the directory you have specified and will look like this –

On your target server, you will need to confirm your module paths. You can do this by using the following command. You may have more than one path.


Now copy the directory that contains the module you have saved, to a module path on the target server. Likely ‘C:\Programfiles\WindowsPowerShell\Modules’ on a Windows System.

Now the Module is on your system, all that’s left is to import the module as above –

Import-Module VMware.PowerCLI

Thanks for reading! Hope this has been of use and catch you in the next post.