In this series we will see how to automate the creation of a tenant in vCAC using vCO. There are multiple tasks to provision a tenant in vCAC, so even though it is an automation product itself, there’s no reason why you shouldn’t look at automating parts of it too. In part 3 we look at installing the vCAC plugin for vCO
Navigate to the Configuration webpage, in my case https://localhost:8283/
In this series we will see how to automate the creation of a tenant in vCAC using vCO. There are multiple tasks to provision a tenant in vCAC, so even though it is an automation product itself, there’s no reason why you shouldn’t look at automating parts of it too.
In part 2 we will create the AD Users, Groups and OUs to support the vCAC tenant. In this example we will create:
In this series we will see how to automate the creation of a tenant in vCAC using vCO. There are multiple tasks to provision a tenant in vCAC, so even though it is an automation product itself, there’s no reason why you shouldn’t look at automating parts of it too.
In parts 1 and 2 we will look at the AD requirements for a tenant. Since most organisations will likely use AD for authentication we will create the minimum users and groups required for a vCAC tenant in a structure that lends itself to further expansion.
Need to create a random password in vCO, maybe to be able to create a user account in Active Directory or elsewhere? I created an action for this task which can be reused in any workflow. The code for this is below.
There’s one input passwordLength to determine how long you want the password to be.
The action can be used in a workflow like so:
Alternatively, you can download the action to import into your own vCO install from my vCOModules repository on GitHub, where I’m beginning to store modules of generic actions I use.
While using the Create a user group in an organizational unit Active Directory workflow in vCenter Orchestrator 5.5.1 I noticed an unexpected result after the group had been created in AD.
Although the group was successfully created, the SamAccountName attribute appeared to have been populated with a seemingly random string and not the name of the group as I would have expected.
Apart from being a bit inconsistent for my liking this could have potentially undesired results from applications querying AD using the SamAccountName property.