Problem with vRA 8.x AD integration and extensibility subscriptions in VPZ

[maslow]

Hey guys,

I have a problem with our new vRA 8 environment ... we are successfully running vRA 7 environments, but we would like to migrate them soon to vRA 8.

So we started with setting up vRA 8.1, soon there was an update so we moved to 8.2. Today we upgraded to 8.3. We have a clustered vIDM consisting of 3 nodes and also a vRA cluster consisting of 3 nodes. In the default vRA tenant we added a new tenant. Then we created a VPZ for that tenant and linked the VPZ to the tenant.

But our problems persist in every version ...

1. AD integration not working

Within the created new tenant we set up the AD integration to create computer accounts in AD for the newly deployed VMs. The AD integration is linked with our project in the tenant. The user has the delegated permissions in AD to create and delete computer accounts. I also verified this by creating and deleting AD objects via Powershell with that user. Firewall rules are also in place to allow traffic from vRA to AD DCs. So far so good ... Once we deploy new VMs, no AD account is created... with the Custom Spec we set up in vCenter the new VMs are then finally added to AD (which works as it uses the same user in the custom spec, so user and permissions to add to AD are fine). But as the AD computer accounts were not per-staged by the vRA AD integration, the accounts are created in the default Computers OU 😞

Nothing changed here, regardless of which vRA 8 version ...

2. Extensibility subscriptions with workflows in newly created tenants doesn't work

In the newly created tenant we allocated a VPZ to we want to use our IPAM. So we created the vRO workflows for reserving and deleting IP addresses with Netbox IPAM. Once we add a subscription, it never gets called ... Same in all vRA 8 versions. Actually, in a lot of states the events are not triggered when added in the tenant.

We found out, that the events get triggered in the default tenant ... Dunno why, but if we add our subscriptions for the new tenant within the default tenant, they get called. Is that normal behavior with vRA 8 and VPZ, that you cant use the extensibility within the created tenants but only from the default tenant?!

These two points are really blocking us in getting forward with our migrations, hope you have some thoughts or ideas for us 🙂

Greetings,
Morti

[maslow]

What we found out so far:

regarding 1

It seems to be a bug in 8.x version if you are using VPZ. Once you are not using Cloud Accounts directly in your tenant but a VPZ, AD integration is not triggered. Once we add our vSphere Cloud Account and use resources directly without VPZ, AD integration works like a charm ...

regarding 2

Seems to be a "feature" that the extensibility workflows are only triggered through default tenant and not within the tenant itself, if you use VPZ. Once you dont use VPZ like above in 1 and directly use your resources, the workflows are triggered like a charm within the tenant itself ...

So seems to be a little bit buggy for me up until vRA 8.3, we also still experience an old known issue back from version vRA 8.0.1 that is mentioned in the release notes: https://docs.vmware.com/en/vRealize-Automation/8.0.1/rn/vRealize-Automation-801-releasenotes.html

• Unable to deploy VMs with using both vSphere and NSX network from different network profiles.

  When deploying VMs from different network profiles, the user receives an error:

  "Allocation filter error: Unable to find a common placement for compute 'Cloud_vSphere_Machine_1' and its associated network resources on region '/provisioning/resources/provisioning-regions/82caf58d876e46755997f33352ec8'. Reason: network filter: host does not conform with the network configuration based on the networks of the blueprint and the selected network profile 'net1'Original Task Error: Allocation filter error: Unable to find a common placement for compute 'Cloud_vSphere_Machine_1' and its associated network resources on region '/provisioning/resources/provisioning-regions/82caf58d876e46755997f33352ec8'. Reason: network filter: host does not conform with the network configuration based on the networks of the blueprint and the selected network profile 'net1'"

  This occurs only when networks from two different network profiles are used in the same blueprint.These networks can be either only vSphere networks or both vSphere and NSX networks.

  Workaround: Use networks from the same network profile.

And tada, if we only use one profile, problem is gone. So for us this might work as we are using an external IPAM. But if you want to have two NICs on your VM and use the vRA IPAM for example, you need to use two profiles, one for every NIC. So this constellation doesnt work at the moment. Another huge bug ...

I am going to report these three findings we had to the support. I hope they will do something about these very soon 😕