Addressing errors when using vRA 7.4 Guest Agent

Having upgraded my vRA instance in my HomeLab to 7.4 not long after it GA'd, I recently decided to create some nice, new templates as well. You know, latest patches, hardware, basic config etc.

I won't bore you with exactly how I installed Windows, patched it or configured it. The relevant part of the process to this article was the installation of the vRA Guest Agent and subsequent testing of it.

I already had my vRA blueprint configured; just a simple Windows Server 2012 R2 template that has the vRealize LogInsight agent installed and configured on it automatically as part of the provision process:

Installing the vRA Guest Agent

This is a documented process to install the software agent on a Virtual Machine that is then subsequently turned in to a template. For vRA 7.4, the documentation can be found on VMware's site:

Install the Guest Agent on a Windows Reference Machine

Prepare a Windows Reference Machine to Support Software

This worked without issue. I shutdown the machine, turned it in to a template and update my blueprint.

Testing the new template

This is where I ran in to an issue. The request resulted in a Virtual Machine being created from the template and powered on. However, when the Guest Agent ran it threw an error and failed the request.

In case you can't read it, is says:

The following component requests failed: w2012r2. Request failed: Machine w12-0004: InstallSoftware : "Error writing properties to C:\opt\vmware-appdirector\agent\appd.properties_6/-01-_1653_49.62".

That's a funny looking filename! Completely invalid in fact.

Why it happens

The short version, it's a bug. There is a workaround.

The vRA Guest Agent receives a number of properties from vRA when it runs and it stores those in a file called “appd.properties”. What seems to be different in vRA 7.4 however is that the file is initially created with a different name and then renamed to its correct name. The initial name includes a date-time stamp that evaluates differently depending on the locale that the template is setup with. Mine use the UK locale. I subsequently learned that other European locales are similarly affected, but in different ways.

Luckily, this functionality is controlled completely by a Windows batch script that you can change.

The workaround

The first step is to convert the template back in to a VM and power it on. Once booted and login completed, the folder where the Guest Agent file we need is located at C:\opt\vmware-appdirector\agent-bootstrap:

And the file that we need is “vcac-appd-gc.bat”. Looking at it, you can see the line where the problem occurs at the end of this code snippet:

REM Constants
set APPD_PROPERTIES=appd.properties
set APPD_AGENT_DIRECTORY=C:\opt\vmware-appdirector\agent
set APPD_AGENT_LOGS_DIRECTORY=%APPD_AGENT_DIRECTORY%\logs
set APPD_PROPERTIES_FILE=%APPD_AGENT_DIRECTORY%\%APPD_PROPERTIES%
set CUSTOM_PROPERTIES_FILE=%APPD_AGENT_DIRECTORY%\custom.properties
set VCAC_APPDCUSTOM_LOG=%APPD_AGENT_LOGS_DIRECTORY%\vcac-appd-gc.log
set APPD_AGENT_RAN_FLAG=%APPD_AGENT_DIRECTORY%\agent_ran
set APPD_AGENT_FAILED_FLAG=%APPD_AGENT_DIRECTORY%\bootstrap_failed
set SLEEP_INTERVAL=30
set APPD_PROPERTIES_INPUT=%APPD_AGENT_DIRECTORY%\appd.properties_%date:~4,2%-%date:~7,2%-%date:~10,4%_%time:~0,2%%time:~3,2%_%time:~6,5%

The date and time added to the end of the “appd.properties” file produces a filename that's illegal when using Windows in the UK locale:

After some experimentation…

…I came up with something that worked:

Replacing the final line of the code snippet above with the three lines below, I converted my VM back in to a template and tested again.

set TIMESTAMP=%date:/=-%_%time::=-%
set TIMESTAMP=%TIMESTAMP: =%
set APPD_PROPERTIES_INPUT=%APPD_AGENT_DIRECTORY%\appd.properties_%TIMESTAMP%

It worked!

Almost…

A colleague of mine from Spain who was experiencing the same issue tried my workaround and reported that it didn't work for him as the resultant filename contained a comma. After a bit of experimentation by yet another colleague, a globally acceptable (and simpler) workaround was devised. Ignore the three lines above and simply change the value for APPD_PROPERTIES_INPUT as below:

set APPD_PROPERTIES_INPUT=%APPD_AGENT_DIRECTORY%\appd.properties_%RANDOM%

Problem solved. It's been logged as a bug and will be looked at. For now, just use the workaround above.