Latest Blog Posts

Following on from the vRA 7 Enterprise Deployment Part 3, this blog continues the series with the installation of the vRealize Automation IaaS management agent on the IaaS nodes.

Since vRA 7.0 release, the vRA deployment wizard was introduced to complete the pre-requisite configuration and automated deployment of the vRA IaaS components. This is a massive improvement over the vRA 6.x procedure and more reliable. Before proceeding with the vRA Deployment Wizard, each vRA IaaS node requires the vRA Management Agent to be installed. Once installed, the host is registered with the primary vRA appliance.

Exception: Java 64-bit is required on the IaaS Web servers and cannot be pushed by the deployment wizard. You must install a supported 64-bit version of Java and add the “JAVA_HOME” system variable on each IaaS Web server you plan to use prior to commencing with the vRA Deployment Wizard.

As per the vRealize Automation Reference Architecture document, vRealize Automation 7 Reference Architecture, as per the Enterprise (previously known as Large) deployment model, you need to prepare 8 Windows Server VMs ensuring you meet the prerequisites for the vRA deployment wizard. This deployment guide assumes you have a Microsoft SQL Server already deployed which can be used to host the vRA IaaS database.

Ensure you adhere to the vRealize Automation Support Matrix and the Interoperability Guides.

Once you have prepared the following, you can continue with the vRealize Automation installation:

8 x Windows Server VMs

Installed a supported version of JRE x64

Configure the JAVA_HOME system variable

Ensure you have a supported Load Balancer configured with only the primary nodes enabled in the LB pools

Created and validated DNS Alias addressed to use for the vRA installation

Note: You need to perform these steps on the first Windows Server you will use as the primary IaaS Web Server host, ensuring that the server has full network access to all vRealize Automation and IaaS Web, Manager, DEM, and Proxy Agent servers to perform the Management Agent installation.

Click I Understand the Risks, and click Add Exception to accept the certificate.

Click Confirm Security Exception.

Log in using the user name root and the password you specified when you deployed the vRealize Automation appliance.

Click Login.

On the Welcome to the vRealize Automation Wizard page.

Click Next to continue.

On the End User License Agreement page, click I accept the terms of this agreement.

Click Next to continue.

On the Deployment Type page, select the Enterprise deployment option.

Click Next to continue.

Ensure Install Infrastructure as a Service is selected

On the Installation Prerequisites page:

Click on the vCAC-IaaSManagmentAgent-Setup.msi hyperlink to begin the download the Management Agent installer.

Click Save File to save the installer to a local folder on the primary IaaS Web Server host where you are performing the Management Agent installation from.

Browse to the local directory where you saved the installer, on the primary IaaS Web Server host.

Right click on the vCAC-IaaSManagementAgent-Setup.msi file and select Install.

When the setup wizard opens, click Next.

On the End-User License Agreement screen of the Management Agent Setup Wizard, check the box I accept the terms of this agreement.

Click Next.

On the Destination Folder screen, select a destination folder by clicking Change, or accept the default installation path.

The following table lists the host name information for the vRA IaaS nodes in my homelab, where the IaaS Management Agent for each IaaS Server component will be installed. You can use this table as a reference to complete the vRealize Automation Management Agent on all of the vRA IaaS Nodes.

IaaS Management Agent Deployment Information

Component

IaaS Management Agent

Required or N/A

Server FQDN

vRealize Automation Appliances

Appliance

(Management Agent N/A)

vratestlab01.testlab.com

vratestlab02.testlab.com

vRealize Automation Websites

IaaS Web Servers

(Management Agents Required)

vratestlab03.testlab.com

vratestlab04.testlab.com

Manager Service and DEM Orchestrator

IaaS Manager Servers

(Management Agents Required)

vratestlab05.testlab.com

vratestlab06.testlab.com

DEM Workers and Agents

IaaS Agent Servers

(Management Agents Required)

vratestlab07.testlab.com

vratestlab08.testlab.com

Microsoft SQL Server 2012

vRealize Automation IaaS Database

(Management Agent N/A)

sqltestlab01.testlab.com

This concludes part 4 of this vRealize Automation Enterprise installation series. I will continue with the vRA 7 deployment in part 5 of this series, where we can now start deploying vRA using the Deployment Wizard.

vRealize Automation Appliance Deployment Verification

Verify the Deployment of the First vRealize Automation Appliance

Go to the vRealize Automation appliance management console by opening a connection using its FQDN: https://vratestlab01.testlab.com:5480/

Accept the certificate by clicking I Understand the Risks and then clicking Add Exception.

Click Confirm Security Exception.

Log in with the user name root and the password you specified when deploying the vRealize Automation appliance.

The vRealize Automation Installation Wizard is displayed.

Caution – Stop Here and Do NOT Click Next. Verify that all other vRealize Automation appliances have been deployed and are running before proceeding to the next step

Do not cancel or exit out of the wizard at any time. If you exit the wizard, the tool assumes that you will be going through a manual installation and will not let you restart the wizard. Leave this page open and continue on to the next section.

Verify the Deployment of the Second vRealize Automation Appliance

Go to the vRealize Automation appliance management console by opening a connection using its FQDN. For example: https://vratestlab02.testlab.com:5480/

Accept the certificate exception by clicking I Understand the Risks, and clicking Add Exception.

Click Confirm Security Exception.

Log in using the user name root and the password you specified when deploying the vRealize Automation appliance.

The vRealize Automation Installation Wizard is displayed.

Caution – Stop Here and Do NOT Click Next. Verify that all other vRealize Automation appliances have been deployed and are running before proceeding to the next step

Do not cancel or exit out of the wizard at any time. If you exit the wizard, the tool assumes that you will be going through a manual installation and will not let you restart the wizard. Leave this page open and continue on to the next section.

I will continue with the vRA 7 deployment in part 4 of this series, where we can now start deploying the vRA IaaS nodes.

Continuing on from Part 1, where I upgraded the external PSC appliances, Part 2 of this post will now continue the upgrade sequence and upgrade the vCenter Server Appliance 6.0 to the 6.5d release. As previously with the PSC appliance upgrade, the vCSA 6.5 upgrade follows the same two stage approach. The first stage is to deploy a new appliance and the second stage is to copy the data from the 6.0 appliance to the new 6.5 appliance.

Stage 1 – Deploy the new vCenter Server Appliance

In stage 1, I will deploy the OVA file of the vCenter 6.5 appliance. Mount the ISO and navigate to the \vcsa-ui-installer\ directory and then to the required subdirectory for your OS:

For Windows OS, go to the win32 subdirectory, and run the installer.exe

For Linux OS, go to the lin64 subdirectory, and run the installer

For Mac OS, go to the mac subdirectory, and run the Installer.app

Ensure you have a full backup or snapshots of all the required machine before commencing.

I’m running my upgrade from a Windows machine so I will run \vcsa-ui-installer\ win32\installer.exe

Select Upgrade from the vCenter Server Appliance 6.5 Installer

The introduction provides an overview of the stages required to complete the upgrade. Click Next.

Accept the End User License Agreement and click Next

Enter the FQDN of the existing vCenter Server Appliance, this is the first vCSA 6.0 I installed, along with the required credentials. Then enter the ESXi host for the source vCSA. Click Next

Click Yes on the Certificate Warning to continue.

Enter the ESXi host FQDN where you would like the new vCSA 6.5 appliance deployed. Click Next

Click Yes on the Certificate Warning to continue.

Enter the name for the vCSA appliance VM and set a root password. Click Next.

Select the deployment size you would like for your environment. For my home lab, I selected Tiny

Select a datastore for the vCSA and if you would like to enable Thin Disk Mode. Click Next.

Now select a network with ephemeral port binding, this is temporary and the new vCSA appliance can be moved to another network after the upgrade has completed.

Enter the temporary network identity in the required fields. It’s worth noting at this point that the temporary names and IP addresses used during the upgrade all need to be resolvable by DNS. Once the upgrade has completed, the appliance frees the temporary IP address and assumes the network settings of the source 6.0 appliance.

Review the summary on the Ready to complete stage 1 page, verify the settings and then click Finish

Once the deployment has completed, click Continue to progress to Stage 2. If you close, you can continue with Stage 2 by navigating to the VAMI of the newly deployed vCenter Server appliance, https://vma01tmp.testlab.com:5480

After completing stage 1, you will be taken to stage 2 and the introduction page. Click Next.

Confirm the source vCenter Server and ESXi host information. This will be pre-populated from Stage 1 unless you closed the Upgrade after Stage 1. If so, you we need to re-enter the information. Click Next

A pre-upgrade check will run and display it’s results. The check highlighted an internal error during the vSphere ESX Agent Manager upgrade checks. I managed to find a resolution to this error in the VMware communities

Click UnregisterExtension and a new window will appear for the UnregisterExtension

Enter com.vmware.vim.eam in the value field and click Invoke Method

This unregisters the plug-in and results in void

Refresh the Managed Object Browser and verify the plug-in has been unregistered

Stop the vmware-eam service on the source vCSA appliance by running service-control –stop vmware-eam from the shell

Once the vmware-eam service is stopped, you can continue. Click Next

It’s likely you will be required to enter your password again due to the session expiring. Enter your password and click Log in

The pre-upgrade check will run again and display it’s results. This time, the check only highlighted that DRS should not be set to Fully Automated on the cluster where the ESXi host resides during the upgrade process. As in part 1, I configured the DRS Automation Level to manual.

You now need to select the data you would like to migrate form the course vCSA 6.0 appliance, I decided to take all of the data. Select the option for your environment and click Next

Review the summary information on the Ready to complete page, check I have backed up the source vCenter Server and all the required data from the database and click Finish

At this point, the installer will display a notice stating the source vCSA appliance will be shutdown once the network configuration has been enabled on the new vCSA 6.5 appliance. This is a useful option as the source vCSA configuration and data is left intact for easier rollback, if required. Click OK

If all goes well, the data should be copied and the source vCSA shutdown. The new vCSA 6.5 should be powered on and accessible with your source network identity. At this point I renamed the VMs in vCenter for convenience.

You now need to upgrade all vCSAs in your SSO domain before proceeding to upgrade the ESXi hosts. I will finish this blog series in Part 3 when I complete the upgrade of my ESXi hosts.

I was at a customer site recently where they had issues with ESXi hosts reverting to local authentication after joining an Active Directory domain. On further investigation, it transpired that the ESXi hosts can only communicate with some of the AD domain controllers as the majority are behind firewalls. As far as I’m aware, ESXi hosts are not AD site aware so when a query is made to the AD integrated DNS, any of the domain DCs could be returned, including those not accessible behind firewalls.

I was not provided with any further details on the ESXi hosts reverting to local authentication but this appeared to be a good use case for setting preferred domain controllers the ESXi host advanced settings. You can configure UserVars.ActiveDirectoryPreferredDomainControllers with preferred domain controllers, separated by comma, for the ESXi host to use for AD communication.

The PSC 6.5 appliance upgrade is broken into two stages, the first stage is to deploy a new appliance and the second stage is to copy the data from the 6.0 appliance to the new 6.5 appliance. Following the update sequence, I need to upgrade my PSCs first followed by my vCenter appliances then the ESXi hosts.

I’ll assume you know how to download the required ISOs from the VMware website.

Stage 1 – Deploy the new Platform Services Controller Appliance

In stage 1, I will deploy the OVA file of the Platform Services Controller 6.5 appliance. Mount the ISO and navigate to the \vcsa-ui-installer\ directory and then to the required subdirectory for your OS:

For Windows OS, go to the win32 subdirectory, and run the installer.exe

For Linux OS, go to the lin64 subdirectory, and run the installer

For Mac OS, go to the mac subdirectory, and run the Installer.app

Ensure you have a full backup or snapshots of all the required machine before commencing.

I’m running my upgrade from a Windows machine so I will run \vcsa-ui-installer\ win32\installer.exe

Select Upgrade from the vCenter Server Appliance 6.5 Installer

The introduction provides an overview of the stages required to complete the upgrade. Click Next.

Accept the End User License Agreement and click Next

Enter the FQDN of the existing Platform Service Controller, this is the first PSC 6.0 I installed, along with the required credentials. Then enter the ESXi host for the source PSC. Click Next.

Click Yes on the Certificate Warning to continue.

Enter the ESXi host FQDN where you would like the new PSC 6.5 appliance deployed. Click Next.

Click Yes on the Certificate Warning to continue.

Enter the name for the PSC appliance VM and set a root password. Click Next.

Select a datastore for the PSC appliance and if you would like to enable Thin Disk Mode. Click Next.

Now select a network with ephemeral port binding, this is temporary and the new PSC appliance can be moved to another network after the upgrade has completed.

Enter the temporary network identity in the required fields. It’s worth noting at this point that the temporary names and IP addresses used during the upgrade all need to be resolvable by DNS. Once the upgrade has completed, the appliance frees the temporary IP address and assumes the network settings of the source 6.0 appliance.

Review the summary on the Ready to complete stage 1 page, verify the settings and then click Finish

Once the deployment has completed, click Continue to progress to Stage 2. If you close, you can continue with Stage 2 by navigating to the VAMI of the newly deployed PSC appliance, https://psc01tmp.testlab.com:5480

After completing stage 1, you will be taken to stage 2 and the introduction page. Click Next.

A pre-upgrade check will run and display it’s results. The check highlighted below that DRS should not be set to Fully Automated on the cluster where the ESXi host resides during the upgrade process. I configured the DRS Automation Level to manual.

Select if you want to participate in VMware’s Customer Improvement Program (CEIP), click Next

Review the summary information on the “Ready to complete” page, check I have backed up the source Platform Services Controller and all the required data from the database and click Finish

At this point, the installer will display a notice stating the source PSC will be shutdown once the network configuration has been enabled on the new PSC 6.5 appliance. As this is my second upgrade attempt, due to upgrade issues with my first VCSA in part 2 and time constraints, this feature proved very useful to revert back to my vSphere 6.0 home lab for another day or so.

Click OK.

If all goes well, the data should be copied and the source PSC shutdown. The new PSC 6.5 should be powered on and accessible with your source network identity. At this point I rename the VMs in vCenter for convenience.

You now need to upgrade all PSCs in your environment before proceeding to upgrade the vCenter appliances. I followed the same procedure to upgrade my second PSC.

I will continue from here in Upgrading vSphere 6.0 U2 to vSphere 6.5d – Part 2 where I will upgrade my vCenter 6.0 appliances and ESXi 6.0 hosts.

Following on from vRA 7 Enterprise Deployment Part 1, this blog continues the series with some further planning and preparation before starting with the initial vRA Appliances deployment.

Generating Certificates

A production, distributed vRealize Automation deployment utilises Certificate Authority (CA) signed security certificates as each component communicates exclusively over SSL. While it is possible to import self-signed certificates on necessary components, this is not recommended in a production environment.

In my home lab, I have installed a Microsoft Certificate Authority. I followed this blog article to setup my Microsoft CA:

Creating and Publishing a Certificate Template

Referencing the KB article, I created the certificate template using the following steps.

Open the MMC console for Certificate Templates:

Click File and select Add/Remove Snap-in

Select Certificate Templates in Available Snap-Ins and click Add

Click OK

From the right pane, right-click Web Server template

Click Duplicate Template

In the Properties of New Template dialog box:

Click the General tab

Type the name of the template in Template name text box

In the Properties of New Template dialog box:

Click the Subject Name tab

Select the Supply in the request radio button

In the Properties of New Template dialog box:

Click the Security tab

Assign Full Control privileges to the domain administrator

Assign Full Control privileges to the computer issuing this certificate

Click OK

Open the MMC console for Certification Authority for the domain:

Right-click Certificate Templates

Select New > Certificate Template to Issue

In the Enable Certificate Templates dialog box:

Select the certificate created in the above steps

Click OK

Now the certificate template is published and ready to use. The table below details the certificates which are required for an enterprise large deployment with HA using embedded vRO instances.

vRealize Automation Certificate Requirements for High Availability

Certificate Common Name

Application Role

Encoding Needed

vra-portal.testlab.com

vRealize Automation Appliances

PEM and unencrypted key

vra-web.testlab.com

IaaS Web Servers

PKCS12

vra-mgr.testlab.com

IaaS Manager Services

PKCS12

Generating SSL Certificates

Now we will create the PKCS12 formatted certificates for the vRA IaaS Windows components and the PEM encoded certificate for the vRA appliances. You will need a machine with OpenSSL installed to generate the Certificate Signing Requests and format conversions plus access to the Certificate Services server to generate the signed certificates. The process shown below uses a Microsoft Active Directory Certificate Services.

Prepare for certificate generation using the following procedure:

Install OpenSSL on the machine where you will generate the certificates.

Create a base folder (D:\Certs in this example) with separate sub-folders for each vRealize Automation component.

Within the base folder, create three subfolders named as follows:

vrava

IaaSWeb

IaaSMgr

Log in to the Microsoft Certificate Authority web interface, for example:

This post will be part of a series detailing the steps required to deploy a vRealize Automation 7 large deployment implementation from the reference architecture. I would recommend reading the reference architecture before commencing with any vRA 7 install.

The vRealize Automation Reference Architecture document can be found here:

vRealize Automation Overview

Just in case you are not aware of VMware’s Automation product, here’s a brief introduction – VMware vRealize Automation provides a secure portal where authorised administrators, developers, or business users can request new IT services. In addition, they can manage specific cloud and IT resources that enable IT organisations to deliver services that can be configured to their lines of business in a self- service catalog.

vRealize Automation provides a secure portal where authorised administrators, developers or business users can request new IT services and manage specific cloud and IT resources, while ensuring compliance with business policies. Requests for IT service, including infrastructure, applications, desktops, and many others, are processed through a common service catalog to provide a consistent user experience.

You can improve cost control by using vRealize Automation to monitor resource and capacity usage. For further cost control management, you can integrate vRealize Business Advanced or Enterprise Edition with your vRealize Automation instance to expose the cost of cloud and virtual machine resources, and help you better manage capacity, cost, and efficiency.

The vRealize Automation documentation can be found at the VMware vRealize Automation Information Center:

New Features in vRealize Automation 7 since 6.2 release

vRealize Automation 7 includes several architectural changes that simplify configuration and deployment. The deployment wizard is a major improvement over the vRA 6.x release providing a more reliable and robust deployment method. The previous release was very sensitive, especially with the IaaS components.

Architectural Changes

The appliance database is now clustered automatically within the appliance. There is no longer any need for an external database load balancer or DNS entry.

The instance of vRealize Orchestrator is now clustered automatically within the vRA appliance.

Authentication is now handled by an embedded instance of VMware Identity Manager, known as Directories Management, within vRealize Automation.

vRealize Application Services functionality has been merged into vRealize Automation.

Deployment Changes

vRealize Automation deployments require two less load balanced endpoints as there is no need to balance the appliance database and an external SSO provider.

Four virtual machines can potentially be removed from the footprint for most deployments, though an external vRealize Orchestrator instance is still recommended for some situations.

A new deployment wizard which offers two types of installs, simple and enterprise. Simple is for installing vRA in a monolithic (non-distributed) fashion, enterprise assumes a fully distributed install

Deployment Recommendations

Keep the vRealize Automation, vRealize Business and vRealize Orchestrator appliances in the same time zone with their clocks synchronised. Otherwise, data synchronisation might be delayed.

Install vRealize Automation, vRealize Business Standard Edition, and vRealize Orchestrator on the same management cluster. Provision machines to a cluster that is separate from the management cluster so that user workload and server workload can be isolated.

Deploy Proxy Agents in the same data center as the Endpoint with which they communicate. VMware does not recommended placing DEM Workers in Remote Data Centers unless there is an express workflow skill based use case that requires it. All components except the Proxy Agents and DEM Workers must be deployed in the same Data Center or Data Centers within a Metro Area Network. Latency must be less than 5 milliseconds, and bandwidth must not be less than 1 GB/s between the Data Centers in the Metro Area Network.

Load Balancer

The following illustration outlines the vRA architecture for an enterprise deployment

The following table outlines the hardware specifications for the vRA components using the large deployment model in the reference architecture:

Server Role

Components

Required Hardware Specifications

Recommended Hardware Specifications

vRealize Automation Appliance

vRealize Automation Services,

vRealize Orchestrator, vRealize Automation Appliance Database

CPU: 4 vCPU

RAM: 18 GB (this may need to be increased for Directories Management sync)

Disk: 108 GB

Network: 1 GB/s

Same as required hardware specifications.

Infrastructure Web Server

Web site

CPU: 2 vCPU

RAM: 2 GB

Disk: 40 GB

Network: 1 GB/s

CPU: 2 vCPU

RAM: 4 GB

Disk: 40 GB

Network: 1 GB/s

Infrastructure Manager Server

Manager Service, DEM Orchestrator

CPU: 2 vCPU

RAM: 2 GB

Disk: 40 GB

Network: 1 GB/s

CPU: 2 vCPU

RAM: 4 GB

Disk: 40 GB

Network: 1 GB/s

Infrastructure DEM Server

(One or more) DEM Workers

CPU: 2 vCPU

RAM: 2 GB

Disk: 40 GB

Network: 1 GB/s (Per DEM Worker)

CPU: 2 vCPU

RAM: 6 GB

Disk: 40 GB

Network: 1 GB/s (Per DEM Worker)

Infrastructure Agent Server

(One or more) Proxy Agent

CPU: 2 vCPU

RAM: 4 GB

Disk: 40 GB

Network: 1 GB/s

Same as required hardware specifications

MSSQL Database Server

Infrastructure Database

CPU: 2 vCPU

RAM: 8 GB

Disk: 40 GB

Network: 1 GB/s

CPU: 8 vCPU

RAM: 16 GB

Disk: 80 GB

Network: 1 GB/s

Note: Typically disk sizes for vRA components host on Windows Servers are driven by customer standard build specifications. These need to be considered with the above table.

DNS and Host Name Resolution

All vRA components must be able to resolve each other by using a fully qualified domain name (FQDN).

The Model Manager Web service, Manager Service and Microsoft SQL Server database must also be able to resolve each other by their Windows Internet Name Service (WINS) name.

Note: vRA does not allow the use of an underscore (_) in host names.

Password Considerations

The vRealize Automation administrator password that you define during installation must not contain special characters.

In vRA 7.0.1, the following special characters are known to cause errors:

Double quote marks (“)

Commas (,)

A trailing equal sign (=)

Blank spaces

Non-ASCII or extended ASCII characters

Note: Passwords that contain special characters might be accepted when you enter them, but cause failures when you perform operations later.

Time Synchronisation

All systems must synchronise their clocks from an accurate time source. Installation will fail if system clocks are not synchronised.

Installation Accounts

The following table outlines the accounts required for a distributed installation, I used separate accounts for the IaaS components but you can consolidate the account requirements if your setup allows this:

Component

Account

Access

vRealize Automation Appliance

(VMware Identity Manager)

root

Default Tenant

administrator@vsphere.local

Website and Model Manager

testlab\svc_vra_iaas01

Access to IaaS SQL DB

Local Administrator on IaaS Web Servers

Manager Service and DEM Orchestrator

testlab\svc_vra_mgr01

Access to IaaS SQL DB

Local Administrator on IaaS Manager Web Servers

DEM Worker

testlab\svc_vra_pxy01

Local Administrator on IaaS DEM-W/Agent Servers

Proxy Agent

testlab\svc_vra_pxy01

Local Administrator on IaaS DEM-W/Agent Servers

vRA to vCenter

testlab\svc_vra_vc01

vRA to AD

testlab\svc_vra_ad01

vRO to AD

testlab\svc_vro_ad01

vRA to vRO

testlab\svc_vra_vro01

Load Balancer

The following table outlines the load balanced components required for a distributed installation: