vCenter Server – Page 13

What's New in vSphere 6.0 Update 1 for VCSA?

09.01.2015 by William Lam // 31 Comments

One of the announcements at VMworld this week is the upcoming release of vSphere 6.0 Update 1 (GA sometime in Q3 2015) and in addition to bug fixes there are also several new enhancements that have been added. Here are some of the new capabilities specifically for the vCenter Server Appliance (VCSA).

New Deployment Targets - The VCSA now supports both vCenter Server (brownfield) as well as ESXi (greenfield) as a deployment targets.When using either the Guided UI or Scripted UI, you can now deploy to an existing vCenter Server which might serve as a management cluster for example. Previously, ESXi was the only supported deployment target.
Convert Embedded VCSA to External PSC - An Embedded VCSA deployment can now be re-configured or re-pointed to an External PSC using the new "reconfigure" and "repoint" option found in the /bin/cmsso-util utility. This allows customers to quickly get started using the simple Embedded VCSA deployment and as they get more comfortable and want to scale out to an External PSC for features like Enhanced Linked Mode, you can easily do so.

Two of the most frequently asked questions that I have seen from customers since the release of the VCSA 6.0 is where did the VMware Appliance Management Interface (VAMI) and URL-based patching go? These were definitely two missed features that did not make it into VCSA 6.0 release and today I am pleased to announce that they have returned with some nice enhancements!

VAMI UI - The VAMI UI can be accessed in the familiar 5480 port by visiting the following URL of the VCSA: https://[VCSA]:5480 and requires a local OS account to login like the root user account. The VAMI itself has been completely re-written both on the backend as well as the frontend which is now an HTML5 interface. All VAMI functionality can be accessed both from the UI as well as using the appliancesh command-line interface.

URL-based patching - URL-based patching is also included in the new VAMI UI interface. By default it is configured to point back to VMware's online repository but you can also configure it to use an ISO or a custom repository as previous versions supported. All patching capabilities are also available using the appliancesh command-line interface.

PSC UI - In addition to new VAMI UI, there also now a new Platform Services Controller (PSC) UI which is also written in HTML5. The new UI is located at the following URL: https://[VCSA]/psc and requires an SSO Administrator account to login. This new UI actually uses the same backend as the PSC configurations found within the vSphere Web Client. The idea behind this UI is to provide customers with a way to configure SSO and other related configurations within the PSC for either a greenfield setup or when the vSphere Web Client is unavailable. This can come in handy for troubleshooting purposes. Lastly, with the new PSC UI, you will now be able to replace certificates from a UI standpoint where as previously this was only available in the CLI.

Build-2-Build upgrade support - In prior releases, both a "Major" and "U" (Update) release of the VCSA meant that you had to deploy the new VCSA to perform a migration based upgrade. In vSphere 6.0 Update 1, "U" releases (U1, U2, etc) can now be accomplished by an in-place upgrade or sometimes refer to as a build-2-build. There will be a VCSA 6.0 Update 1 ISO which can be mounted within your existing VCSA 6.0 appliance to perform the upgrade as seen in the screenshot below.

appliancesh automation - The appliancesh interface in the VCSA 6.0 was primarily targeted for interactive usage and did not support any type of Automation. The feedback from customers was to provide a way to be able to call into the various appliancesh commands and in VCSA 6.0 Update 1, you can now execute a series of appliancesh commands within a file and re-directing that into an SSH session. VMware is also looking into providing a proper API for the appliancesh commands, if you have any feedback on this please leave a comment or reach out to Alan Renouf, who is the PM.

Below is the contents of the vcsa-commands.txt file which contains the following appliancesh commands to configure and enable NTP for the VCSA:

ntp.test --servers 0.pool.ntp.org,1.pool.ntp.org
ntp.server.add --server 0.pool.ntp.org,1.pool.ntp.org
timesync.set --mode NTP
ntp.get

Lastly, though this is not specific to the VCSA, I thought it was also worth mentioning that you can now access ALL capabilities of vSphere Update Manager (VUM) within the vSphere Web Client. VUM will still require a separate Windows system, but will fully inter-operate with both the Windows VC as well as the VCSA and you no longer need to rely on the vSphere C# Client to perform remediation or base-line creation and assignments.

As you can see, there are a ton of enhancements in the latest vSphere 6.0 Update 1 release and if you have not taken vSphere 6.0 for a spin yet, I definitely recommend starting with this release.

Quick Tip - Determining the vCenter Server OS platform (Windows or VCSA) using vSphere API

06.25.2015 by William Lam // Leave a Comment

The vSphere API is an extensively rich interface for being able to extract all sorts of useful information about your vSphere infrastructure. One useful trick that may come in handy for those requiring to perform operations directly against the vCenter Server guestOS itself is to figure out whether you are connecting to a Windows vCenter Server or the vCenter Server Appliance (VCSA)? Lets say you wish to automate the deployment of the recently released VSAN 6.0 Health Check Plugin and the process to install the plugin will differ between Windows vCenter Server and the VCSA, so it would be ideal if you can easily distinguish between the two

A simplistic solution would be to quickly test for something that would exist in either Windows or Linux, but what if you wanted to perform these operations using the vSphere API and the Guest Operations API to execute the commands within the guests? Well, luckily the vSphere API actually provides this information when connecting to a vCenter Server API endpoint and you can tell if you are connecting to a Windows vCenter Server or the VCSA.

To determine the guestOS type for the vCenter Server you are connecting to, there is a property called osType which you can query when you first connect. Below is a quick PowerCLI snippet for accessing this property, you can also use a variety of other vSphere SDKs to extract this property.

$server = Connect-VIServer -Server reflex.primp-industries.com

$server.ExtensionData.Content.About

Disconnect-VIServer -Server $server -Confirm:$false

The osType property for the VCSA is linux-x64

The osType property for vCenter Server for Windows is win32-x64

vCenter Server 6.0 Tidbits Part 10: Automating SSO Admin configurations

06.03.2015 by William Lam // 4 Comments

A common request that I have heard from customers is to have the ability to automate vCenter Single Sign-On configurations from a programmatic standpoint. Unfortunately, this is currently not possible today as a public API does not exist for SSO. Having spent some time exploring the underlying vmdir database which is just an LDAP-based system (here & here) and learning about a way to update a particular key per KB2070433 within the vmdir database which I have shown here and I have found here, I wanted to see if it was possible to query for these specific SSO Admin configurations and also be able to update these properties.

Disclaimer: Please take extreme caution when connecting to the vmdird database. You should take extreme care in making changes while in the database else you can negatively impact your environment.

There are three main sections to the SSO Admin configurations that can be seen from the vSphere Web Client:

Password Policies
Lockout Policy
Token Policy

For each section, I have provided the specific ldapsearch query (please refer to this article as per-requisite) which can either be run directly on the VCSA if you are using that or a system that includes the ldapsearch command. You will need to replace the text highlighted in blue with your own environment details.

Password Policies & Lockout Policy

To view the following set of configurations, here is the ldapsearch query to use:

/opt/likewise/bin/ldapsearch -h 192.168.1.70 -w 'VMware1!' -x -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -b "cn=password and lockout policy,dc=vghetto,dc=local"

Here is a screenshot of the Password Policies as seen in the vSphere Web Client and their corresponding LDAP property names:

UI Setting	LDAP Attribute Name
Maximum lifetime	vmwPasswordLifetimeDays
Restrict reuse	vmwPasswordProhibitedPreviousCount
Maximum lenght	vmwPasswordMaxLength
At least special character	vmwPasswordMinSpecialCharCount
At least alphabetic character	vmwPasswordMinAlphabeticCount
At least uppercase character	vmwPasswordMinUpperCaseCount
At least lowercase character	vmwPasswordMinLowerCaseCount
At least numeric character	vmwPasswordMinNumericCount
Identical adjacent Characters	vmwPasswordMaxIdenticalAdjacentChars

Here is a screenshot of the Lock Policy as seen in the vSphere Web Client and their corresponding LDAP property names:

UI Setting	LDAP Attribute Name
Maximum number of failed login attempts	vmwPasswordChangeMaxFailedAttempts
Time interval between failures	vmwPasswordChangeFailedAttemptIntervalSec
Unlock time	vmwPasswordChangeAutoUnlockIntervalSec

Token Policy

To view the following configuration, here is the ldapsearch query to use:

/opt/likewise/bin/ldapsearch -h 192.168.1.70 -w 'VMware1!' -x -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -b "cn=Tenants,cn=IdentityManager,cn=Services,dc=vghetto,dc=local" -s sub "objectclass=vmwSTSTenant"

Here is a screenshot of the Token Policy as seen in the vSphere Web Client and their corresponding LDAP property names:

Token Policy

UI Setting	LDAP Attribute Name
Clock tolerance	vmwSTSClockTolerance
Maximum token renewal count	vmwSTSRenewCount
Maximum token delegation count	vmwSTSDelegationCount
Maximum bearer token lifetime	vmwSTSMaxBearerTokenLifetime
Maximum holder-of-key token lifetime	vmwSTSMaxHolderOfKeyTokenLifetime

Now that we know how to query for a particular SSO Configuration, here is how you can modify one of these properties. In the example below, we will be changing the life time of a password which dictates the frequency in which you need to change an SSO user's password. Using the "Password Policies" table above, we can see the that property name is called vmwPasswordLifetimeDays

To modify an LDAP entry, we will need to first create a file that contains the change, in the example here we are going to name it change.ldif and it should contain the following where the "replace" keyword shows which property is getting modified and the next line after shows the value that it will be changed to.

dn: cn=password and lockout policy,dc=vghetto,dc=local
changetype: modify
replace: vmwPasswordLifetimeDays
vmwPasswordLifetimeDays: 30

To apply the change, we will now run the following ldapmodify command and specifying our change.ldif configuration file:

/opt/likewise/bin/ldapmodify -f change.ldif -h 192.168.1.70 -D "cn=Administrator,cn=Users,dc=vghetto,dc=local" -w 'VMware1!'

If the change was successful, you can confirm by either querying the property again using the ldapquery command or just refreshing the SSO Configurations using the vSphere Web Client.