WilliamLam.com

VCSA (vCenter Server Appliance) Resources

by // 2 Comments

Here is a consolidated page on all the articles I have written about the VCSA (vCenter Server Appliance). Hopefully this will be useful when looking for anything related to VCSA.

VCSA 5.5

VCSA 5.1

VCSA 5.0

Additional Tips/Tricks

How to Add/Remove vCenter SSO Identity Sources Using the Command-Line for Windows vCenter Server & VCSA

by // 16 Comments

The new vCenter SSO (Single Sign-On) in vSphere 5.1 can support multiple Identity Sources (Active Directory, OpenLDAP and Local OS) and these configurations can all be managed by using the vSphere Web Client. Here are some additional documentation as well as a video on how to managing Identity Sources using the vSphere Web Client.


However, if you wish to manage the Identity Sources through the command-line for automated deployments, you probably do not want to use the GUI. Luckily, there is a vCenter SSO CLI that you can use on both a Windows deployment as well as on the VCSA (vCenter Server Appliance).

In the examples below, I will show you how to add an Active Directory Identity Source to both a Windows deployment as well as a VCSA deployment using the command-line.

Adding Active Directory Identity Source to Windows vCenter SSO Server

Before getting started, you will need to know the vCenter SSO Administrator password. This is the password that you had configure during the installation of vCenter SSO for the admin@System-Domain account.

Step 1: Change into the C:\Program Files\VMware\Infrastructure\SSOServer\utils directory and you will be using the rsautil command-line tool. To get a list of help options for managing Identity Sources, run the following command:

rsautil manage-identity-sources

Step 2:  Run the following command (substitute the values for your own enviornment) :

rsautil manage-identity-sources -a create -u admin -p !VMware123! -r ldap://fullerene.primp-industries.com --ldap-port 3268 -d primp-industries.com -l PRIMP-IND --principal-base-dn DC=primp-industries,DC=com --group-base-dn DC=primp-industries,DC=com -f "" -L *protected email*

Note: When you login into the vSphere Web Client, the username for the vCenter SSO account is "admin@system-domain" but for the CLI, it is just "admin". If you do not have a failover LDAP Server, specify "" for -f flag.

Here is a screenshot of adding the Active Directory Identity Source:

Step 3: You can also confirm the configurations by performing the "list" operation by running the following command:

rsautil manage-identity-sources -a list -u admin -p !VMware123!

Adding Active Directory Identity Source to VCSA

For the VCSA, there are few additional steps as the vCenter SSO Administrator account "admin" does not contain a default password as noted in this article. You can either follow the instructions in that article to set a password for the "admin" user and then jump to Step 3 OR you can perform all required steps using the command-line.

Step 1: We first need to set the vCenter SSO Master Password as it is required to change the "admin" user account. Since the vCenter SSO Master Password is auto-generated during installation, we will recover the account which will then allow us to set a password of our own choosing. Run the following two commands and in the second command, you will specify the vCenter SSO Master Password of your choice.

source /etc/vmware-sso/keys/recovery.cfg
/usr/lib/vmware-sso/utils/ssowrench manage-secrets -a change -u "$SSO_RECOVERY_USERNAME" -p "$SSO_RECOVERY_PASSWORD" -N vmware123

Note: Do not forget the vCenter SSO Master Password that you have selected, as there is no way to recover the account after this.

Step 2: Now that we have the vCenter SSO Master Password, we can now set a password for the "admin" user. Run the following command and specify the Master Password (-m flag) as well as a new password (-p flag) for the admin (-u flag) user.

/usr/lib/vmware-sso/utils/ssowrench reset-admin-password -u admin -p '!VMware123!' -m vmware123

Step 3: Once we have a password set for the "admin" user, we will be using the same vCenter SSO CLI utility as we did in the Windows vCenter Server deployment but in the VCSA it is called ssowrench and it is located under /usr/lib/vmware-sso/utils

Run the following command which accepts the same set of options as the Windows version (substitute the values for your own enviornment).

/usr/lib/vmware-sso/utils/ssowrench manage-identity-sources -a create -u admin -p '!VMware123!' -r "ldap://fullerene.primp-industries.com" --ldap-port 3268 -d primp-industries.com -l PRIMP-IND --principal-base-dn "DC=primp-industries,DC=com" --group-base-dn "DC=primp-industries,DC=com" -f "" -L *protected email*

Here is a screenshot of adding the Active Directory Identity Source:

Step 4: To view all Identity Sources, you can run the following command (as seen in the screenshot above):

/usr/lib/vmware-sso/utils/ssowrench manage-identity-sources -a list -u admin -p '!VMware123!'

Note: If you do not wish to specify any of the credentials on the command-line, the utility in both Windows and VCSA will automatically prompt for input.

Changing GuestOS Type Using a Custom vCO Workflow in the vSphere Web Client

by // 6 Comments

Something you might not have noticed, is the fact that you can not change or modify the guestOS type after a virtual machine has been created in the new vSphere Web Client, this option is just grayed out.

Though this is a change in behavior compared to the old vSphere C# Client, I actually took this as an opportunity to try out one of the most interesting and unrealized feature in the vSphere 5.1 release. This feature being a tighter integration between vCenter Server and vCenter Orchestrator. This means that you can now take any of your existing vCO workflows or create new workflows and make them directly available to any of the vSphere objects within the new vSphere Web Client as a custom action. 

Note: A feature request/bug has already been filed with VMware to have the ability to change the Guest OS and Guest OS Version for a virtual machine after creation in the vSphere Web Client.

Here is an example of a custom workflow that I created called Change Guest OS Type and as you can see that it only shows up under the context of a virtual machine object in the vSphere Web Client. 

From my perspective, the use cases are endless as you can create ANY custom workflow to perform any action or series of operations that can span across VMware products as well as 3rd party systems and directly present them to your end users in the new vSphere Web Client. Not only that, users can specify which workflows they see by default on a given vSphere object and this can differ from user to user based on their daily set of tasks.

So going back to our scenario, here is a way to change the Guest OS and Guest OS Version using a custom vCO workflow.

Step 1 - Download Change Guest OS Type vCO workflow to local desktop.

Step 2 - Open up the vCO Workflow Client, you can do this by pointing your browser to your vCO Server and click on "Start Orchestrator Client" link.

Step 3 - Import the Change Guest OS Type vCO workflow from your desktop to your vCO Server

Step 4 - Next, we need to go to the vSphere Web Client to make this vCO workflow available on a particular vSphere object, in our case it is a virtual machine. On the home page of the vSphere Web Client, click on "vCenter Orchestrator" icon in the center pane or select it from the navigation pane on the left. Once you are in the vCenter Orchestrator configuration page, select the "Manage" tab and click on the "plus" icon.

In this view, you can specify which default vCO workflows are made available across the various vSphere objects. These can be modified or removed based on the frequency of workflow usage.

Step 5 - Locate the Change Guest OS Type vCO workflow on the left hand side and then click on the Add button. Finally, select type to be virtual machine as this workflow is only applicable to a VM and OK to save the settings.

If we take a look at the vCenter Orchstrator configuration page, we will see our new workflow is now listed as one of the defaults for a virtual machine object. You can edit and modify any of these based on the workflows you wish to see by default. I highly recommend you add workflows that you use frequently so you do not have to search through the entire list each time.

Finally, it is time to test drive our new workflow! Locate a virtual machine and right click on the object, in a second you should see a sub-menu for All vCenter Orchestrator Actions and then select our vCO workflow Change Guest OS Type which will start off a very familiar wizard.

The first screen is the object selected, which in our case is our virtual machine. You can of course change this, but we will leave it as it's context was automatically picked up.

The next screen is to select the Guest OS Family (Windows, Linux & Other) that you wish to modify your virtual machine to.

The last part is just to select the Guest OS Version which is provided as a list of the guest OSes based on your previous selection.

To apply the Guest OS change, just click finish and watch the vCO workflow execute.

Though the functionality of changing the Guest OS is not available in the new vSphere Web Client, you can still provide the same functionality to your end users through a custom vCO workflow which are now tightly integrated into the vSphere Web Client. Hopefully this sparks some ideas on other vCO workflows you can create or expose through the vSphere Web Client in your own environment. I know I have a few in mind 🙂

A big thanks goes out to Christophe Decanini for helping me with a few questions while creating this workflow.