I generated a problem for my self today, that at first was not very obvious and a bit strange in behavior. I thought I would write this out in a blog article if others making the same mistake!
I was using a third-party imaging tool – Microsoft Deployment Toolkit (MDT) to deploy the guest operating system on a blueprint requested from vRealize Automation. I followed this article from VMware that explained how to configure vRealize Automation to provision VMs using MDT. As the article stated I also ran into problems with externalWFstubs.machineprovisioned timeout errors, so I had to adjust the default values for this specific external call.
As I don’t need to write out the change I made, I quote it here:
Last but not least, there’s a good chance that applying an image will exceed the 30-minute default timeout for external automation in the Machine Provisioned Lifecycle State. In my (very slow) lab, the MDT imaging process took about 45 minutes, end-to-end. To be safe, I increased this timeout to 60 minutes. To do so, edit the ExternalWFStubs.xml file located on your IaaS server, here:
C:\Program Files (x86)\VMware\vCAC\Server\ExternalWorkflows\xmldb. There are multiple sections. Find the WFStubMachineProvisioned section, and increase its timeout. PLEASE resist the temptation to enter 00:60:00. I didn’t, and now I have a little more grey hair to show for it! Any value greater than 59 will confound vRA and cause Requests to fail with errors like “Request failed: dev-0067 not found, and possibly deleted before provisioning finished.” Instead, be sure to enter one hour as 01:00:00 (90 minutes would be 01:30:00, etc.).
But before I changed this file, I created a backup of the file, in the same directory.
So I went back to test the change to see if it fixed the issue, and as the deployment using MDT took a while, I also worked simultaneously on another vRO workflows for the Building Machine state. I found that all of a sudden all workflows executed from vRealize Automation was started twice after each other.
After various testing and searching through log files, I made a google search and was lucky to find this community post, with a hint to look at the xml files that I changed. I had created a backup of this file and this had the extension of .xml and this post indicated that vRA loads all XML files in this directory and thereby also running vRO workflows twice (or one time per loaded XML file). After removing the backup XML file from the directory and restart the IAAS service, it all went back to normal. Thanks to a community user called “djerfe” that directed me this in this direction.