WilliamLam.com

Completely automating vCenter Server Appliance (VCSA) 5.5 Configurations

by // 8 Comments

As promised, here is a new script called configureVCSA55.sh that I have put together after learning about a couple new VCSA automation tips here and here. This script will fully automate the configuration of a vCenter Server Appliance (VCSA) 5.5 and once the script has completed, you will have a fully functional vCenter Server Appliance. There are several variables at the top of the script that you will want to edit prior to running the script.

Here is a summary of the high level operations the script is performing and not all operations will be performed, it will depend on the variables that you have configured.

  • Accept EULA
  • vSphere Inventory Size Configuration
  • Active Directory Configuration (optional)
  • DNS Search Domain Configuration
  • NTP Configuration
  • vCenter Server Database Configuration
  • vSphere SSO Configuration
  • vSphere SSO Identity Source Configuration for Active Directory (optional)
  • Active Directory default Identity Source Configuration (optional)
  • VMware Telemtry Configuration (optional)

To run the script, you can either SCP the script to a newly deployed VCSA and run it locally in the shell or remotely via SSH using the following command:

ssh root@[VC-IP] < configureVCSA55.sh

completely-automate-configuration-vcsa55.0
I almost never go through a manual configuration of the VCSA anymore (since 5.0) as it just takes way too long! Hopefully you will find this script handy when needing to quickly test something or automating the deployment of a few dozen VCSA which I know of a few customers that are doing on a regular basis 🙂

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!

Standalone VMRC (VM Remote Console) re-introduced in vSphere 5.5 Update 2b

by // 53 Comments

The VMRC (VM Remote Console) has gone through several transitions from initially being available as a standalone Windows application to an integrated browser based plugin with the release of the vSphere Web Client. In the latest vSphere 5.5 Update 2b release, a new standalone VMRC has been re-introduced to provide an alternative way to launch a VM console. The reason for this is due to the deprecated and eventual removal of NPAPI (Netscape Plugin Application Programming Interface) based plugin support from all modern web browsers which the current VMRC implementation leverages. Here is a quick excerpt from the vSphere 5.5 Update 2b release notes:

Inability to open virtual machine console using Google Chrome browser when NPAPI support is deprecated
When the NPAPI support in Google Chrome is deprecated, the virtual machine console provided in the vSphere Client Integration Plugin might no longer function when the Chrome browser is updated. As a result, you might be unable to open the virtual machine console using the Google Chrome browser and you might not be able to connect to devices.

UPDATE (10/21/14) - Looks like the standalone VMRC has just been made available and you can now download it by either following the link in the vSphere Web Client if you are on vSphere 5.5 Update 2b OR simply by going to http://www.vmware.com/go/download-vmrc

UPDATE (10/12/14) - It looks like the standalone VMRC is currently not available for download just yet. You can continue using the existing methods to connect to your VM Console, the new Standalone VMRC is NOT required but the links have been put in place to proactively get ready for NPAPI deprecation (more details below). You can subscribe to VMware KB 2091284 which will be updated when the download is available.

UPDATE (05/31/15) - If you are connecting directly to an ESXi host you can either use the vSphere API to query for the VM MoRef ID or you can easily pull it by running the following command directly in the ESXi Shell:

vim-cmd vmsvc/getallvms

The deprecation of NPAPI support is nothing new and has actually been communicated by all major web browsers for quite some time now. To ensure that VMware customers are not affected when this change goes into effect, a new standalone VMRC is being introduced to preempt the upcoming change and provides a new way of  launching a VM console using the vSphere Web Client as seen in the screenshot below.

vmrc
To be able to open a VM Console using the new standalone VMRC, you will of course need to have it installed first. You can find the link to the download on VMware.com but there is also a direct link provided on the VM Summary page in the vSphere Web Client. In addition to the new standalone VMRC, you will still be able to use the existing method as well as the HTML5 based VM console. The HTML5 console continues to work if you do not have CIP (Client Integration Package) installed on your Windows system or if you are running on a Mac OS X system. I am sure many of you are probably asking when will there be Mac OS X version of VMRC? I know I definitely am 🙂 The good news is that this is being worked on and hopefully we will see a Mac OS X version in the very near future.

Furthermore, the new standalone VMRC also includes some nice enhancements that I know some of you have been asking for, especially those that have used the previous standalone VMRC application. The new VMRC can now be directly launched using the following two URI methods:

vmrc://[USERNAME]@[VC]/?moid=[VM-MOREF-ID]
vmrc://clone:[VC-TICKET]@[VC]/?moid=[VM-MOREF-ID]

Here is a screenshot of the standalone VMRC application:

vmrc-0
The first method accepts basic authentication using username/password, the vCenter Server address and the VM MoRef Id. Here is an example of what that would look like:

C:\Program Files (x86)\VMware\VMware Remote Console\vmrc.exe vmrc://*protected email*/?moid=vm-37

The second method accepts a vCenter Server session ticket which you can generate by using vSphere API acquireCloneTicket() method. A quick way to test this example is by using the vSphere MOB and making a call to acquireCloneTicket using the following URL https://[VCENTER-SERVER]/mob/?moid=SessionManager&method=acquireCloneTicket and then specifying the ticket as seen in the example below.

C:\Program Files (x86)\VMware\VMware Remote Console\vmrc.exe vmrc://clone:*protected email*/?moid=vm-37

With the new URI handler, you can automatically associate it with the standalone VMRC application which means you can type this into a browser or into a Windows explorer and it will automatically launch VMRC. The other nice thing about the new standalone VMRC is if you would like to reduce the complexity of getting a regular use connected to their desktop, you can easily use the standalone VMRC and dynamically generating a link for your end users to access their VMs without ever exposing them to the underlying vSphere infrastructure. I suspect there will be some really interesting use cases for the new standalone VMRC and the VMRC team will continue to iterate to make it better based on customer feedback.