virtuallyGhetto

vcenter server appliance

How to deploy the vCenter Server Appliance (VCSA) with a custom MAC Address?

by Leave a Comment

I recently had a question that came in from our field where a customer needed to deploy the vCenter Server Appliance (VCSA) with a specific MAC Address which was a requirement to ensure property connectivity within their network. This type of network requirement is not really new or unique, it is a common practice used to ensure only valid VMs with a static DHCP reservation can actually connect to a specific network but it certainly was the first time I had heard of this request for the VCSA.

With the default VCSA installer workflow, there is currently not a way to modify the network MAC Address which is automatically generated after the deployment of the OVA. Having said that, I have spent quite a bit of time exploring the various non-standard methods of deploying the VCSA in the past (see here, here and here) and with that information, you definitely can affect the MAC Address while still maintaining a valid VCSA deployment. With a bit of trial/error, there are two options depending if you are deploying the VCSA directly to an ESXi host (for initial setup) or to an existing vCenter Server. To demonstrate how this works, I have created a basic shell script called VCSAStaticMACAddress.sh which you can easily adapt to for a Windows-based environment.

The trick is that when you deploy to a vCenter Server endpoint, the required OVF properties are persisted which would allow you to only deploy the VCSA but not actually power it on and there you can easily augment a number of settings including the MAC Address. In the case of deploying directly to an ESXi host, OVF properties are not persisted and hence a challenge if you wish to make changes prior to powering on the VM. In earlier versions, it was possible to set these OVF properties by way of using the extraConfig property of the VM but it looks like this trick no longer works and requires a slight variation of the workflow which is described in the instructions below.

[Read more...] about How to deploy the vCenter Server Appliance (VCSA) with a custom MAC Address?

How to exclude VCSA UI/CLI Installer from MacOS Catalina Security Gatekeeper?

by 1 Comment

A couple of weeks ago I had upgraded my personal home computer to the latest MacOS Catalina (10.15) and one of the first issues I ran into was being able to access my vCenter Server. It turned out this was due to changes to MacOS security (which is a good thing) but certainly caught me and others off guard. In fact, I spent quite some time searching online and eventually found this workaround here.

After sharing this tidbit online (which several others also ran into) I came to learn that both Duncan Epping blogged about this issue back in Nov 2019 here and Christian Mohn blogged about this in Dec 2019 here. Sadly I did not come across either of their blogs using "NET::ERR_CERT_REVOKED macos catalina" in Google. I had assumed this was a Chrome issue and simply landed on the first few links and looking back, I now see Duncan's blog was #6 in the search results (doh!)

Today, I ran into another issue when attempting to use the VCSA CLI Installer, the following error was thrown:

“vcsa-deploy.bin” cannot be opened because the developer cannot be verified


This is again due to a security change in MacOS Catalina which now prevents terminal-based applications which are not notarized from running. For a single application/binary, you can go into System Preferences->Security & Privacy and allow anyway. For more complex applications like the VCSA CLI Installer which has a number of libraries and scripts, this will take awhile and end up frustrating end users. The updated security enhancement is actually a good thing and I did not want to disable the Gatekeeper service but I was interested in disabling it for the VCSA CLI Installer. While searching online, I came across this Hashicorp Terraform thread where folks were having the exact same issue and I found out there was a way to disable the MacOS Security Gatekeeper for a specific application.

To do so, we just need to recursively remove the metadata attribute "com.apple.quarantine" for the extracted VCSA ISO by running the following command:

sudo xattr -r -d com.apple.quarantine VMware-VCSA-all-6.7.0-Update-15132721

After the quarantine attribute has been removed, you can now run the VCSA CLI Installer (including UI Installer) without being prompted with an error. Hopefully VMware will consider notarizing future releases of the VCSA Installer and I will be sharing this feedback internally if it has not already.

Using PowerCLI to automate the retrieval of VCSA Password Policies

by Leave a Comment

I hope that every vSphere administrator or operator by now is familiar with the extremely powerful vSphere Guest Operations API functionality (details here and here), which can easily be consumed using PowerCLI's Invoke-VMScript cmdlet. If not, highly recommend you check out the links referenced. I know the GuestOps API is certainly my top favorite with sending VM keystrokes capability a very close second!

Not only does the GuestOps API unlock functionality that simply may not be possible (e.g. there's no API or automation interface) but it also enables automation within a VM without requiring any type of remote management services enabled (e.g. SSH or WinRM) or even networking to the VM for that matter!

The reason I am bringing all this up is that although there is not an API for managing and retrieving vCenter Single Sign-On (SSO) configurations which includes password policies, there is a way in which customers can still automate and retrieve this and other information by leveraging the GuestOps API. In fact, back in 2015 I demonstrated on how you can retrieve VCSA SSO password policy and configurations and we can simply apply the GuestOps API to help us automate this task. In addition, most customers do not enable SSH by default and we can still apply the GuestOps API technique and perform automation tasks to VSCSA without requiring SSH as described in this blog post back in 2016.

[Read more...] about Using PowerCLI to automate the retrieval of VCSA Password Policies

Is a DNS server still required when using a Static IP for VCSA?

by 5 Comments

When deploying a vCenter Server Appliance (VCSA), customers have two options for setting up a static network address: using either a hostname (Fully Qualified Domain Name) or just a static IP Address (e.g. no DNS). In the first option when using an FQDN, it should be no surprise that you need to also specify a valid DNS Server which the VCSA UI/CLI Installer will automatically validate both the forward and reverse address. This is the most common deployment model for customers in both production as well as for development environments such as a vSphere home lab.

In the second scenario, where a static IP Address is used, a DNS server is not required because we are NOT using an FQDN for the hostname but rather an IP Address. Having said that, if you have ever used the VCSA UI or CLI, you will find that the DNS Server entry is actually a required field and you can not proceed without providing an address.

VCSA UI Installer:

VCSA CLI Installer:

As mentioned earlier, we know that it should not be required but currently the VCSA Installer is a bit overly cautious in its pre-checks and does require a value today. This is something that has already been shared internally and the team will be relaxing this requirement in the future.

With that said, this leads us back to the original question posed in the blog title, do we need a valid DNS server when using a static IP for the VCSA?

[Read more...] about Is a DNS server still required when using a Static IP for VCSA?

Enabling shell access for Active Directory users via SSH to vCenter Server Appliance (VCSA)

by 4 Comments

I had a question the other day on whether it was possible to enable shell access for Active Directory users when logging into the vCenter Server Appliance (VCSA) via SSH? The answer is yes and though this is documented here, it is not very clear whether this is only applicable to SSO-based users only. In any case, the process to enable this is pretty straight forward and simply requires two steps which I have outlined below.

Step 0 - Ensure that your VCSA and/or PSC is joined to Active Directory before proceeding to the next step. If not, take a look at the documentation here for more details.

Step 1 - Login to vSphere Web Client and under Administration->System Configuration->Nodes->Manage->Settings->Access, go ahead and enable boh SSH and bash shell options. The first setting turns on SSH to the VCSA and the second setting allows users (local, SSO and AD) to access the shell on the VCSA.


Step 2 - In the vSphere Web Client and under Administration->Single Sign-On->Users and Groups->Groups, select the SystemConfiguration.BaseShellAdministrators group and add either an AD User and/or Group that you wish to allow to access the shell.


Once you have completed the steps above, you can now SSH to your VCSA/PSC using the AD user (UPN format) that you had authorized earlier. In the example below, I am logging into one of my VCSA using user *protected email* and as you can see, I am placed into the appliance shell by default.


At this point I can access all the appliancesh commands just like I normally would if I had logged as a root or *protected email*.

If we wish to change to bash shell, we simply just type "shell" which will enable shell access, assuming you had performed Step 2.


One thing that I noticed is that the default home directory for the AD user is /var/lib/nobody and apparently that does not exists by default, so users end up in / directory by default after enabling shell access. I am not sure if this is also related, but the username shows up as nobody as you can see from the prompt. This is something I will share with Engineering to see if we can improve upon as I am sure most of you would rather see the user that is actually logged in.

The good news from an auditing and logging standpoint is that for operations that are logged, it does properly show the username even though the prompt is showing up as nobody.

[Read more...] about Enabling shell access for Active Directory users via SSH to vCenter Server Appliance (VCSA)

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

by 10 Comments

I can still remember when I was a VI Admin and how annoying it was to try to correlate the build numbers for my ESX(i) hosts and vCenter Servers that I have deployed with the versions listed on VMware's website. This especially gets challenging when there are multiple patch releases (a, b, c or 01, 02, 03) in between major releases (5.5, 6.0, 6.0u1, 6.0u2, 6.5, etc.). Historically, most customers including myself would retrieve the respective build numbers and then manually comparing them to either the release notes and/or download website which was very tedious.

Although VMware has exposed the version number within our vSphere products since day 1 which can also be retrieved programmatically using the vSphere API (here), it unfortunately does not provide more details than simply the major/minor version (e.g. 5,5, 6.0, 6.5, etc) of the software. Recently, VMware had released a series of VMware KBs which provides a mapping between the build numbers for vCenter Server, ESXi and vSAN to their respective versions which can be found in the links below:

These are definitely a great set of resources that I know many customers including myself have been using since its release. Having said that, the process today is still pretty manual since you need to manually retrieve the build numbers for either a VC, ESXi or vSAN Host (can be automated using vSphere APIs) and then comparing that to the KBs to get the correct versions. How cool would it be if you could *easily* just point to YOUR environment and retrieve the version information for either a vCenter Server (Windows or VCSA), ESXi host(s) or vSAN host(s) without needing to manually perform this lookup each time? Well, I have just done that! I have taken all three KBs and converted that information into a simple PowerCLI script called VCESXivSANBuildVersion.ps1 leveraging our vSphere API and it provides three functions:

  • Get-VCVersion - Retrieves the vCenter Server version given a VC connection
  • Get-ESXiVersion - Retrieves the ESXi version for all hosts given a vSphere Cluster
  • Get-VSANVersion - Retrieves the vSAN version for all hosts given a vSAN Cluster

Here is an example output using the first two functions:


For the vCenter Server version output, you will notice that I am also including the OS platform of your vCenter Server, so you can distinguish between a Windows vCenter Server and a vCenter Server Appliance (VCSA) which can be useful to see if you have been #migrate2vcsa ;). For the ESXi version output, you will notice the "OriginalInstallDate" value, this is actually new API property that was introduced in vSphere 6.5 and it provides you with the original installation date of your ESXi host (more details can be found here) which is pretty neat.

Here is an example output using last function:


If you wanted to take this a step further, you could even take this output and dynamically update the vSphere UI using either Custom Attributes or vSphere Tags so you know what version the software is at any given moment. Its easy enough to set this up as a scheduled task that could run periodically so you always have the latest information provided in the vSphere UIs.

Although this is a significant improvement over the existing manual methods, I think most of you will agree that it would be ideal if this information was natively available within the product which means BOTH UI and APIs. I think we all appreciate versioning of software is not always easy and it can change from release to release for a variety of reasons, most of which may not be technical. If the vSphere platform could dynamically pull this information in either real time and/or through an offline mechanism and provide this association by default, it would greatly improve the experience when needing to troubleshoot or perform maintenance of the vSphere platform. If this is something you would like to see, please leave a comment below providing your feedback. I know I have already pinged our PMs about this and I am sure they would love to hear form you as well!

Additional Information:

Note1: Update levels can be found using the vSphere API, take a look at this article here for more details.

Note2: As of ESXi 6.5 Update 1, the Update levels are also included by default in the Embedded Host Client as shown in the screenshot below:

Note3: As of vSAN 6.2, the vSAN Management API already includes vSAN version information that can be queried. Take a look at this script here which exercises this new API. For example above, I decided to not use this new API since customers may be running older releases of vSAN which is not covered by the vSAN Mgmt API.

Note4: VMware has also published simliar build to version mapping for other VMware products which can find the complete list here.