I’m always trying to automate as many processes at work. Earlier this year we started working on trying to automate as much of Infrastructure deployment as possible. Turning manual processes which require a lot of documentation into code that can be stored in source control. This is commonly known as Infrastructure as Code.

One idea I had a few months back was to try and automate the deployment of VMware Appliances with configuration injected. Last weekend I had some time to work on a script that can deploy OVF’s to VMware vCenter and VMware ESXi directly.

The script is written in Microsoft PowerShell and requires version 3+ of PowerShell along with VMware vSphere PowerCli. Configuration values that the script uses are held in a JSON data file.  This allows one copy of the script to be stored and a number of JSON configuration files used against it.  All this could be stored in a source control system like GIT.

Another requirement is VMware OVF Tool. This is used to deploy the appliance to the vCenter or ESXi host and inject the configuration properties.  OVF Tool can’t currently deploy appliances to directly ESXi with customised properties. Version 4 of the tool will have the added the parameter: –X:injectOvfEnv to do this but this has at this point not yet been released.

Thanks must go to William Lam who recently wrote an article and put together some scripts that can inject properties into a OVF once OVF tool has deployed it to a ESXi host. I have used this example to inject the properties until version 4 of OVF tool has been released.

I have added the script along with sample configuration files to GitHub. I have made the script flexible so you should be able to use it to deploy other VMware Appliances that require configuration properties for deployment.

Eamples:

How to execute the script from PowerShell:

.\Deploy_VMware_Appliance.ps1 -configpath "D:\configuration\vco_5_5_config_host.json"

Here is an example of the configuration file to deploy the VMware vCenter appliance directly to a ESXi host.  Note you shouldn’t change the property: vm.vmname.

{
    "config": {
        "deployType": "host",
        "deployConfig": {
            "host": "192.168.10.51",
            "host_username": "root",
            "host_password": "password",
            "vmName": "vcsa",
            "datastore": "DS1",
            "diskMode": "thin",
            "network": "VM Network",
            "powerOn": true,
            "ovfpath": "D:\\Mware-vCenter-Server-Appliance-5.5.0.5100-1312297_OVF10.ova"
        },
        "properties":
            {
            "vami.DNS.VMware_vCenter_Server_Appliance":"192.168.10.55",
            "vami.gateway.VMware_vCenter_Server_Appliance":"192.168.10.1",
            "vami.hostname":"vcsa.domain.local",
            "vami.ip0.VMware_vCenter_Server_Appliance":"192.168.10.56",
            "vami.netmask0.VMware_vCenter_Server_Appliance":"255.255.255.0",
            "vm.vmname":"VMware_vCenter_Server_Appliance"
            }
    }
}

More details and examples are available in the GitHub Repository.

You can view and download the project from GitHub

Today I’ve been working on a VMware vCenter Orchestrator workflow to add custom fields on a Virtual Machine. To do this you need to check if the custom field has been created on vCenter using the method addCustomFieldDef on the VcCustomFieldsManager object.


var customFieldsManager = VirtualMachine.sdkConnection.customFieldsManager;

customFieldsManager.addCustomFieldDef("fieldName", "VirtualMachine", null, null);

This will produce an error if the field is already added on the vCenter server so you need to carry out a check.

var customFieldsManager = VirtualMachine.sdkConnection.customFieldsManager;

for each( var field in customFieldsManager.field )
 {
 if( field.name == name )
 {
  // handle match
 }
 }

I found that the attribute field was undefined. After some checking of my code I was sure this was a bug. With a quick Google I found this post on the VMware Community https://communities.vmware.com/thread/477831. It would appear that there is a bug in vCenter Orchestrator 5.5 Inventory Service where it returns incorrect information.  The fix for this is to disable the Inventory Service by adding the following line to the file vmo.properties and then restarting vCO.

com.vmware.o11n.vim.useInventoryService=false

You will find this file in the following locations depending on how you have deployed vCO.

Installation Location
Installed Orchestrator with the vCenter Server installer install_directory\VMware\Infrastructure\Orchestrator\app-server\conf
Standalone version of Orchestrator install_directory\VMware\Orchestrator\app-server\conf
Virtual appliance version of Orchestrator /etc/vco/app-server/

This does appear to be a common issue being reported not just on the customFieldsManager.fields attribute from the Inventory Service. Here is a post where someone has reported the issue when looking up a VlanID on a vSwitch PortGroup.  I noticed a comment on this post saying that the vCO Inventory Service is going to be deprecated in a future release.

I think the inventory service will be deprecated in the future releases (if not already).

This week I have been doing some work with the VMware vSphere 5.5 vCenter Server Appliance (5.5.0.5100 Build 1312297). During this testing I ran into problems setting up AD Authentication with a Windows 2012 domain within vCSA.  The message displayed was Error: Enabling Active Directory failed.

Enabling Active Directory failed

I carried out the normal checks:

  • Checked that  a FQDN(Fully Qualified Domain Name) for my vCSA hostname was being used.  E.g. VCSA.labdomain.local
  • Checked that the domain was entered as a FQDN. E.g. labdomain.local
  • Checked that DNS has a forward and reverse look up record for the vCSA.
  • Pinged the AD server from the console of the vCSA to check DNS.
2013-09-25 12:37:28 20053: ERROR: Enabling active directory failed: Joining to AD Domain:   vCSA.labdomain.local
With Computer DNS Name: VCSA.labdomain.local

Error: Lsass Error [code 0x0000000b]

The OU format is invalid.
2013-09-25 12:37:29 20053: VC_CFG_RESULT=302

To find out what situations caused this error I tired different AD configurations with vCSA. For this first installation the Domain and Forest functional level was Windows Server 2012.

Domain functional level

Server Domain Functional Level Forest function Level vCSA
Windows Server 2012 Windows Sever 2012 Windows Sever 2012 5.5 Doesn’t Work
Windows 2008 Windows 2008 Window 2008 5.5 Works
Windows Server 2012 Windows Sever 2012 Windows Sever 2012 5.1 Works
Windows Server 2012 Window 2008 Window 2008 5.5 Works

It would appear with the rewrite of SSO there are issues with Windows 2012 AD domains.

Update: 4th October 2013

VMware have now looked at the issue and reviewed the log bundle from the vCenter. It’s now being passed to the VMware core engineers as there is no known workaround. I will update this article when I have any more information or a workaround.

For now I would recommend not using a Windows Server 2012 domain and forest. You can use a Windows 2008 domain and forest on a Windows Server 2012.

Update

This issue is fixed in VMware vCenter Server 5.5.0a.  This has been tested with Windows Server 2012 with a Windows Server 2012 Domain and Forest function level and now functions correctly.

Hi, I'm David

I’m a Technologist specialising in Virtualisation, Automation and Cloud technologies and based in the UK.  I have been working in IT since 1998. I look after an engineering team building products for a global cloud services, disaster recovery, managed IT services and hosting company with more than 10,000 customers worldwide. I’m a VMware VCP-DCV and predominantly work with VMware, Microsoft, HP, IBM and Cisco technologies.