WilliamLam.com

Automating Active Directory Identity Source & Default Domain in vSphere Web Client

by // 4 Comments

Over the holiday break I learned about two awesome tidbits from my buddies Blair Fritz and Frank Buechsel who both work over in our GSS Organization. The first tidbit came from Blair who recently shared a newly published VMware KB 2063424 that provides both a Windows and Linux script to automate the setup of your Active Directory as an Identity Source within vSphere SSO. The reason this is so cool is that you no longer have to perform this additional manual step using the vSphere Web Client just to be able to start using your Active Directory as a source for authorization within your vSphere environment. In my opinion, this step should just happen automatically if your vCenter Server (applies to both VC for Windows and VCSA) is already joined to an Active Directory Domain.

UPDATE (01/15/19) - For vSphere 6.5 and 6.7, please refer to VMware KB 67304 for the updated package required to automate this configuration

active-directory-identity-source-and-default-domain-in-vsphere-web-client-0
Looking at the contents of the script, I have extracted the main parts of the script to create a quick snippet that can easily be integrated into my existing VCSA 5.5 Configuration script if you are interested in automating this particular configuration.

AD_DOMAIN=primp-industries.com
EXPORTED_SSO_PROPERTIES=/usr/lib/vmware-upgrade/sso/exported_sso.properties

if [ -e ${EXPORTED_SSO_PROPERTIES} ] ;then
	rm -f  ${EXPORTED_SSO_PROPERTIES}
fi

cat > ${EXPORTED_SSO_PROPERTIES} << __SSO_EXPORT_CONF__
ExternalIdentitySource.${AD_DOMAIN}.name=${AD_DOMAIN}
ExternalIdentitySource.${AD_DOMAIN}.type=0
ExternalIdentitySourcesDomainNames=${AD_DOMAIN}
__SSO_EXPORT_CONF__

/usr/lib/vmware-upgrade/sso/sso_import.sh > /dev/null 2>&1
rm -rf ${EXPORTED_SSO_PROPERTIES}

The next tidbit that I learned the same day came from Frank. It was in regards to configuring the default Identity Source for vSphere SSO which includes localos, vsphere.local and if you have Active Directory configure, your AD Domain is an option as seen in the screenshot below. For a fresh installation, the "localos" Domain is always the default and I was interested in configuring my AD Domain as the default. It turns out this is also possible to automate and more details can be found in this handy VMware KB 2070433.

active-directory-identity-source-and-default-domain-in-vsphere-web-client-1
Similar to the other KB, I have created a quick snippet which can be integrated into my existing VCSA 5.5 Configuration script if you are also interested in automating this configuration.

AD_DOMAIN=primp-industries.com
SSO_ADMINISTRATOR_PASSWORD=vmware
SSO_LDIF_CONF=/tmp/defaultdomain.ldif
                
cat > ${SSO_LDIF_CONF} << __DEFAULT_SSO_DOMAIN__
dn: cn=vsphere.local,cn=Tenants,cn=IdentityManager,cn=Services,dc=vsphere,dc=local
changetype: modify
replace: vmwSTSDefaultIdentityProvider
vmwSTSDefaultIdentityProvider: ${AD_DOMAIN}
__DEFAULT_SSO_DOMAIN__

ldapmodify -f ${SSO_LDIF_CONF} -h localhost -p 11711 -D "cn=Administrator,cn=Users,dc=vsphere,dc=local" -w ${SSO_ADMINISTRATOR_PASSWORD}

I was quite happy to learn about these two tips as these are literally the two last configurations that I have not been able to automate since the vSphere SSO Admins APIs are currently private. I will be updating my VCSA Configuration Script in the next few days to include these additional configurations and will publish an updated script once it is complete. A big thanks goes to both Blair and Frank for sharing this awesome information!

Want to issue a VAAI UNMAP operation using the vSphere Web Client?

by // 3 Comments

Recently, I have seen several requests from both customers and partners wanting to be able to run the VAAI UNMAP operation from within the vSphere Web Client. For those of you not familiar with the VAAI UNMAP operation, I recommend you check out this blog post by my colleague Cormac Hogan. Today, the only way to issue the UNMAP operation is by using ESXCLI either remotely or in the ESXi Shell. There is currently not a vSphere API for this operation and therefore it would be difficult to build a native vSphere Web Client Plugin to provide this functionality.

Having said that, one way to provide this capability is through the use of a vCenter Orchestrator (vCO) Workflow which can remotely execute an ESXCLI command whether that is going through ESXCLI using a Linux jump box or through PowerCLI using a Windows jump box. Starting with vSphere 5.5, you can now extend the vSphere Web Client and attach a vCO Workflow to a vSphere Object and be able to execute the workflow right from the vSphere Web Client. This is great if you are already using vCO, but for those that are not, it can be somewhat complex to setup along with a steep learning curve depending on your experience.

Today, there was an exciting announcement from my Automation buddy, Alan Renouf for a new VMware Fling called PowerActions for the vSphere Web Client. This new Fling allows you to easily extend the vSphere Web Client in the following ways:

  • Access a PowerCLI console directly in the vSphere Web Client
  • Ability to run a context aware PowerCLI script directly from the vSphere Web Client

The prerequisite for setting up PowerActions is no different than vCO calling a PowerCLI script, you just need a Windows "jump-box" that has PowerCLI installed along with PowerActions. The added benefit, is that you do need to setup another piece of infrastructure like vCO if you are not already using it. This made setting up PowerActions extremely easy to setup and even I was able get it up and running in under 5minutes (minus a quick RTFM moment :)).

Given the number of inquiries regarding VAAI UNMAP operation via the vSphere Web Client, I thought that would be a great use case for my first PowerActions script! Below are the instructions on creating the VAAI UNMAP script for PowerActions:

Step 1 - Click on the PowerCLI Scripts option on the left hand side of the Object Navigator and then click on the "New Script" Icon. Select Datastore as the context aware object for the script.

unmap-command-in-vsphere-web-client-0
Step 2 - Provide a name and description for the script. Also make sure to select "Action".

unmap-command-in-vsphere-web-client-1
Step 3 - Copy and paste the following script from https://github.com/lamw/vghetto-scripts/blob/master/powershell/unmap-poweraction.ps1 inside the script window and then save the script. What the script does is takes the Datastore object and retrieves a list of ESXi hosts that has access to the Datastore and then randomly selects one of the host. This is required because ESXCLI operations on a per host level and we use that information to pass into Get-EsxCli cmdlet to issue the VAAI UNMAP operation.

Step 4 - To test the script, you just need to right click on a VMFS Datastore and click on PowerCLI->Execute a Script

unmap-command-in-vsphere-web-client-2
Note: Please be aware of the impact when running a UNMAP operation, you may want to run this on a non-production datastore for testing purposes or during off hours when your workload may not be as busy.

Step 5 - Select the VAAI UNMAP script you just created and once selected and you will be prompted to specify the number of VMFS blocks to unmap per iteration which is exactly the same input when manually ESXCLI.

Screen Shot 2014-09-17 at 10.30.09 PM
At this point, if everything was successful the VAAI UNMAP operation should begin and you can tail /var/log/hostd.log to see the UNAMP operation. Once completed, you should see the prompt return true.

As you can see, it was extremely easy to create my own PowerAction script that expose new functionality and making it available within the vSphere Web Client. I think this is going to be a pretty popular Fling and remember if this is something you would like to see officially in the product, be sure to leave a comment on the PowerAction for vSphere Web Client Fling page, product managers are listening! The only feedback I have is that I would love to see this get extended beyond just PowerCLI and into a generic script extension framework, just imagine the possibilities!

Edit Virtual Hardware 10 VMs using vSphere 5.5 Update 2 C# Client

by // 13 Comments

vSphere 5.5 Update 2 has just released and among the various bug fixes, one that stands out the most to me and I am sure everyone will be quite happy about (including myself) is the ability to now edit a Virtual Hardware 10 Virtual Machine using the legacy vSphere C# Client. Previously, if you tried to edit a Virtual Machine running the latest Virtual Hardware (version 10), you would get a warning message prompting you to use the vSphere Web Client and the operation would be blocked.

edit-vh10-vsphere-c#-client-0
The feedback has been loud and clear from customers/partners and I am glad to see that VMware has re-instated this functionality in the latest vSphere 5.5 Update 2 C# Client. You will still be prompted with a dialog noting that only Virtual Hardware Version 8 features will be editable using the vSphere C# Client and that all newer Virtual Hardware features, you should still leverage the vSphere Web Client and/or vSphere API. This will at least allow you to edit basic functionality of a VM when vCenter Server is unavailable or if you are not running vCenter Server but wish to use the new Virtual Hardware version.

Here is the direct download link for the vSphere 5.5 Update 2 C# Client: http://vsphereclient.vmware.com/vsphereclient/1/9/9/3/0/7/2/VMware-viclient-all-5.5.0-1993072.exe

edit-vh10-vsphere-c#-client-1
Note: You do not need to install vSphere 5.5 Update 2 to be able to use this new functionality, you just need to upgrade your vSphere C# Client to the vSphere 5.5 Update 2 release and you will be able to connect to previous versions of vSphere 5.5 (vCenter Server & ESXi).