To my knowledge, this process will require a great deal of reconfiguration. In our testing, we have found that the vast majority of Event Broker Subscription(EBS) topics do NOT apply to XaaS blueprints. Since the Azure deploy is an XaaS blueprint, it does not partake in the machine provisioning or machine lifecycle topics. In order to perform any EBS action, we have had to add the Azure XaaS into a Composite Blueprint. By doing this, we can use very basic event topics such as "Blueprint component requested" or "Blueprint component completed". These topics do not pass a great deal of information to the vRO workflow and do NOT include any machine data.
This forced us to dig deeper into the vRO workflows that perform the deployment of Azure machines. In doing so, we found several other "gotchas." First, the "Generate Azure Machine Name" workflow is unreliably apply names. It pulls basic information from the Machine Naming Prefix that you may have assigned to the business group. However, it does NOT increment the prefix! This means that if the prefix is being used for other non-Azure deployments, such as on-prem, you may end up with duplicate names among your deployments. In reviewing the workflow in depth, I found that it merely pulls the prefix as an initial reference and then loops through name conflicts in Azure only. It will not create a duplicate machine name in Azure, but does not care about other locations.
This brought us to the last headache in this process. In order to change any of this, you must duplicate the workflows and make your modifications. This may be acceptable if you only need to modify the allocation destroy or deallocation workflows within your XaaS blueprint. However, if you need to modify the create workflow, you must create a brand new XaaS blueprint pointing to your duplicated Create Azure Virtual Machine workflow that includes any modifications you deem appropriate. This isn't overly difficult, but it is time consuming considering the sheer number of inputs that are required by this workflow and the additional customization that it appears VMware has done in building this default Azure XaaS blueprint.
The lack of XaaS EBS interaction has forced us to include some of our post-deploy, pre-release to customer processes into the "Create Azure Virtual Machine" workflow. I sincerely hope that VMware has a plan moving forward to either move Azure deployments into a Native support similar to AWS OR to incorporate the EBS into XaaS deployments. Until then, those of us that choose to implement Azure will continue to struggle within the unfortunate limitations of vRA.
