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.