Using Active Directory Policies with custom hostnames in vRealize Automation - Part 2

In Part 1 I described how to configure the prerequisite AD endpoint and AD policy in vRA. In this one I describe how a custom hostname workflow can be combined with the use of Active Directory policies and the associated caveats.

Requirements:

First step is to create a workflow which generates a custom hostname. I am not going in detail on the hostname creation itself as the associated logic is company specific. Instead I will focus on the key points needed for this workflow.

• Add a input workflow parameter named payload.
• Add the necessary logic to generate unique custom hostnames
• The last workflow’s scriptable task needs to update the vCAC Entity to the new hostname.
  • Input Parameters:
    • payload
    • hostname
  • Example code:

 1var machine = payload.get("machine");
 2var vmId = machine.get("id");
 3var vcacHost = Server.findAllForType("vCAC:VCACHost")[0];
 4
 5// Get the vCAC VM Entity properties
 6var vmEntityProperties = vmEntity.getProperties();
 7
 8// Update the VirtualMachineName property with the custom hostname
 9vmEntityProperties.remove('VirtualMachineName');
10vmEntityProperties.put('VirtualMachineName', hostname);
11
12//Update the Entity object to save the changes
13var hostId = vmEntity.hostId;
14var modelName = vmEntity.modelName;
15var entitySetName = vmEntity.entitySetName;
16var entityIdString = vmEntity.keyString;
17var actionResult = System.getModule("com.vmware.library.vcac").updateVCACEntity(hostId,modelName,entitySetName,entityIdString,vmEntityProperties,null,null);

Event subscription:

Next step is to create and event subscription which launches the workflow execution. The Active Directory policy feature will create the VMs computer account at the start of the buildingmachine state. This means that the event subscription needs to be create for the VMPSMasterWorkflow32.requested POST phase. The computer account would be created with the auto generated hostname in case the VMPSMasterWorkflow32.buildingmachine PRE phase would be used.

Sending payload to vRO

In order for vRO to be able to customize the vRA request we need to send the vRA request information to vRO. This is achieved by adding a custom property to the blueprint. In this specific case the payload needs to be send to vRO for the requested state. Therefore we need to add the Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.Requested with a value of * in the blueprint properties.

Whenever working with EBS subscriptions it is best to create a property group containing the Extensibility.Lifecycle.Properties.VMPSMasterWorkflow32.< StateName > custom properties for all the states on which vRO workflows need to be executed. Then you simple need to add the custom property group to your blueprints instead.

Error handling

The downside of using the VMPSMasterWorkflow32.requested POST phase is that it does not handle failed workflows. Consequently the VM will be deployed with the by vRA auto generated hostname. We can solve this in 2 ways:

1. Create a error handling workflow which checks the hostname has been successfully updated in the vRA request. It should fail if the hostname does not match the hostname naming convention. This workflow requires an event subscription at the VMPSMasterWorkflow32.buildingmachine PRE phase.
2. Instead of creating a custom error handling workflow we can use the builtin custom workflow functionality to customize the error handling of the VMPSMasterWorkflow32.requested POST phase. This can be achieved by adding the Extensibility.Lifecycle.Error.Event.VMPSMasterWorkflow32.requested with value Disposing custom property to each blueprint containing VMs. Whenever the custom hostname workflow fails vRA will start the Disposing process, fail the VM deployment and no VM will be deployed.

AD policy related workflows

In case you need to verify the execution state of the vRA Active Directory Policy related workflows, you can find them at System / vRealize Automation / AD integration in the vRO client.