In this blog post, I am going to cover the setup of the Active Directory integration with vRealize Automation using LDAPS.
Cloud Assembly supports integration with Active Directory servers to provide out of the box creation of computer accounts in a specified Organizational Unit (OU) within an Active Directory server prior to provisioning a virtual machine.
Note: to join to AD within the Guest OS, you can use CloudConfig properties or vSphere CustomizationSpec.
The VMware official documentation doesn’t really call out LDAPS configuration, only LDAP. So after helping a customer configure this, I thought I’d quickly write something up.
To get started, login into vRealize Automation and select Cloud Assembly.
When trying to upgrade an attached Tanzu Kubernetes Grid Cluster via Tanzu Mission Control (TMC), that is either created by a Tanzu Management Cluster, or via the Tanzu Kubernetes Grid Service (vSphere with Tanzu), the console gives you an error message similar to:
API Error: Failed to upgrade cluster: (target=mc:01G4BGAVKHHB6C3JJ5R0WA44NM, intentId=01G4CMP025ZHEBQ000E4SM996H): admission webhook "default.validating.tanzukubernetescluster.run.tanzu.vmware.com" denied the request: updates to immutable fields are not allowed (invalid argument)
I’ve captured some screenshots below of the process.
The Cause
Tanzu Mission Control doesn’t keep information about the Tanzu Clusters CNI configuration. Today, TMC doesn’t support upgrading clusters that are provisioned using Callico. This is not documented in the TMC Documentation.
If you provision a cluster using TMC, it will use the Antrea CNI, and you cannot change this.
Below you can see that my cluster was provisioned using the Callico CNI.
The Fix
Upgrade the Tanzu Cluster outside of Tanzu Mission Control.
In years gone by, costing of your technology platforms was covered in a product called vRealize Business for Cloud. Since the move to the 8.x code based, this product was EOL’d.
The main functions where customers saw value, to provide costings for your datacenter and virtual machines, was wrapped up into vRealize Operations.
This blog post is going to deep dive into the costing capabilities within vRealize Operations across your on-premises datacenters, and what happens when you start to consume VMware on Hyperscaler solutions, such as VMware Cloud on AWS (VMC).
Configure the Global Currency Setting
The first action is setting the global currency for the vRealize Operations instance. There are two important things to note when undertaking this configuration:
This can only be set once
This setting cannot be changed once it is set
To configure:
Click on Administration
Click on the Global Settings Tile
Click on the Cost/Price heading
Click to “Set currency”
Select your currency from the list and click “Set Currency”.
You will get a dialog to say the configuration has taken place.
Now below you can see that this setting is in place and there is no button/clickable option to change it.
Configuring Cost Settings
Now that the global currency is configured, we can start configuring all the cost settings for our Datacenter platforms.
I had the pleasure of working with a customer who wanted to use property groups within vRealize Automation, to provide various configuration data to drive their deployments. They asked some queries about how to use property groups that went beyond the documentation, so I thought it would also make a good blog post.
What are property groups?
Property groups were introduced in vRealize Automation 7.x and sorely missed when the 8.x version was shipped. They were reintroduced in vRA 8.3.
When you several properties that always appear together in your Cloud Templates, you can create a property group to store them together.
This allows you to re-use the same properties over and again across Cloud Templates from a central construct, rather than replicate the same information directly into each cloud template.
The benefit of doing this, is that if you update any information, it is pushed to all linked cloud templates. Potentially this could be a disadvantage as well, so once you use these in production, be mindful of any updates to in-use groups.
There are two types of property groups. When creating a property group, you select the type. You do not have the ability to change or convert the type once the group has been created.
Input property groups gather and apply a consistent set of properties at user request time. Input property groups can include entries for the user to add or select, or they might include read-only values that are needed by the design.
Properties for the user to edit or select can be readable or encrypted. Read-only properties appear on the request form but can’t be edited. If you want read-only values to remain totally hidden, use a constant property group instead.
Constant property groups silently apply known properties. In effect, constant property groups are invisible metadata. They provide values to your Cloud Assembly designs in a way that prevents a requesting user from reading those values or even knowing that they’re present. Examples might include license keys or domain account credentials.
Getting Started with a Input Property Group
Ultimately the Input Property Group works the exact same way as Inputs you specify on the cloud template directly. The group option simply provides a way to centralise these inputs for use between cloud templates.
Create an Input Property Group
Click on Design Tab
Click Property Groups from the left-hand navigation pane
Continue reading vRealize Automation – Active Directory Integration – Configure LDAPS 
