VMware vRealize Orchestrator Not Logging In

This occurred for me when upgrading to or installing a new vCenter 7 and replacing the self-signed certificate. I tested in a lab and was able to successfully install both vCenter 7 and Orchestrator 8.3. I was able to successfully configure both appliances and log in, as well. I did use vSphere Authentication as the Orchestrator’s Identity Provider. As soon as I replaced the self-signed certificate on vCenter, I immediately received the following when logging into Orchestrator:

Uh-oh! So after two weeks or so and lot’s of doing this and that and trying this and that, I think I finally found the resolution. This is actually in the VMware documents, but the document is not quite complete with the information needed to successfully run the commands. Here is the document, https://docs.vmware.com/en/vRealize-Orchestrator/8.3/com.vmware.vrealize.orchestrator-install-config.doc/GUID-66B37DF2-052E-44A0-929E-E4F53E1BCCE3.html. I have detailed the process in full later in this blog post.

For Completeness Sake

For completeness sake, I am going to show the entire process. Please feel free to scroll to the interesting sections below to resolve. I am not going to show how to deploy the appliances, just that they will be in vSphere and available as a starting point.

Install and Check Services

Installed, configured, and checking the services for a “known good”.

VMware vCenter 7.0

When I navigate to my vCenter appliance, I can see that it is using an untrusted certificate.

I perform the necessary steps to continue on. Your browser may be different and your organization’s policies may be different. If your organization is using HTTP Strict Transport Security (HSTS), you will likely be unable to continue without some very tricky manipulation or replacing the self-signed certificate to a known and trusted certificate. This is likely how or why you are in this predicament in the first place and had to search for this blog post.

The log in window is presented to me.

I verified I was able to successfully log in.

VMware vRealize Orchestrator

Navigate to the Orchestrator 8.3 appliance, I am presented with the following.

Since this appliance is fresh, I need to click on the Start the Control Center link and establish an authentication provider. I have to log in with the root account.

Click on Configure Authentication Provider

On this page, I chose vSphere for the Authentication mode setting and the Host address is my vCenter 7 appliance. I am presented with an Accept Certificate box. This will accept the current self-signed certificate, since that is all that is available. NOTE: You could wait to do this step until after you alter the TLS certificate on vCenter, but this article assumes you did not or that you already had an Orchestrator appliance deployed like I did.

Complete the Identity Service window with an administrative or service account that allows users to be queried. Click Register.

Type in a group to use as an Admin group, I used admins, then click the Search button.

A window will display that allows you to pick a security group based off your search criteria. Click Save Changes.

The Orchestrator appliance will be configuring in the background. This is not a fast process! Click on the home icon and choose Validate Configuration. You will see a message stating that a server restart is required…This will automatically happen after a two minute wait. Please be patient here…

You can continue clicking the Refresh button until you have all green check marks. This signifies the appliance rebooted and all services are back up.

Go back to the vco tab in the browser and choose the START THE ORCHESTRATOR CLIENT link. You should be presented the VMware vSphere log on screen. This signifies that your authentication provider is set up correctly to use vSphere. Try logging in.

I can verify that I can successfully log in without trouble.

Let’s Break This!

Replacing the vCenter Server TLS Certificate in vSphere Client

Log in to vCenter server if you are not already. Lot’s of assumptions in the next few sections…I am going to assume you are logged in with an administrative user that also can perform cryptographic operations (https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-17568345-E59E-43A8-A811-92F8BE9C7719.html), then navigate to Menu > Administration > Certificate Management.

I am going to assume you know how to request a Certificate Signing Request (CSR), have already had the certificate signed, and have the necessary certificates in possession. If not, here is a VMware resource to get you started: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-E0609A99-A8D1-4336-BD3B-DE707E261A63.html. Under Machine SSL Certificate, click on Actions > Import and Replace Certificate.

In my case, I chose to use Replace with external CA certificate(requires private key) option and clicked the Next button.

Add in the machine certificate, the root and intermediate certificates chained together (for the chain, I always start with the root and add the intermediate certificates below), and the private key file. Click the Replace button.

If the certificates are successfully replaced, you should get logged out relatively quickly. Give this a few minutes as the vCenter server services are rebooting in the background.

Click the Login button after a few minutes. You may get a no healthy upstream message. Be patient and refresh your browser periodically, there is a lot going on with these appliances.

Eventually, you should get the vCenter log in screen. You can verify that your vCenter is secured by looking for the lock symbol. Go ahead and log back in to verify you can.

Click the Launch vSphere Client (HTML 5) button. Enter your credentials.

Click the Login button.

You may receive a Error occurred while fetching vmca root cert: com.vmware.vcenter.certificate_authority.get_root message. This just indicates that the vCenter server services are not fully restarted, yet. There may be a running task in Recent Tasks. Once this is complete, the message will go away after you refresh the User Interface (UI) or the browser window. Again, be patient as this may seem like an eternity in computer time or that it is broken, but it should come back up.

Again, be patient as this may seem like an eternity in computer time or that it is broken, but it should come back up.

We can confirm that we have logged in and that the message went away.

VMware vRealize Orchestrator

Ok, let’s try to log into the Orchestrator appliance.

So far, it looks promising. Click on the Start the Orchestrator Client link. Warning: you may actually get logged in. This is most likely due to a cookie on your browser. If you close your browser and try to log in again, you will most likely not be able to log in. That is what we are going to fix.

Enter your credentials and click the Login button.

Et voilà! There we are for us English speakers, the broken UI that is extremely frustrating to fix.

The Fix

Here is the article from VMware on how to solve this (https://docs.vmware.com/en/vRealize-Orchestrator/8.3/com.vmware.vrealize.orchestrator-install-config.doc/GUID-66B37DF2-052E-44A0-929E-E4F53E1BCCE3.html). Unfortunately, not all the details are there to run the commands and if you are not experienced with the underlying technology of the Orchestrator appliance, like I wasn’t and really still am not, then this will just likely frustrate you even further. Let’s break this down…I added an indicator where I added steps to the original documented procedure.

1. Log in to the vRealize Orchestrator command line as root. (Added) I used an SSH session, but you can do this on the console with VMRC. I just wanted to be able to copy and paste commands.

2. (Added) Obtain the name of the <vRO pod> you will need for the next step.

kubectl -n prelude get pods

3. Run the kubectl -n prelude exec command. (Added) I used the last line from the clue in the example command of vco-server-app. I really did not know and the document does not explain.

Command from document.

kubectl -n prelude exec -it <vRO pod> -c vco-server-app -- bash

Command used with the <vRO pod> substituted.

kubectl -n prelude exec -it vco-app-77c8fb6659-fsr5v -c vco-server-app -- bash

4. Run the rpm command.

rpm -hiv --nodeps /vco-cfg-cli.rpm

5. Navigate to the /usr/lib/vco-cli/bin/ directory.

6. Run the following ./vro-configure-inner.sh trust commands.

From the document.

./vro-configure-inner.sh trust --alias vco.vsphere.lookup-service.ssl.certificate --uri <vSphere-Auth-Provider-URI> --accept

With substituted <vSphere-Auth-Provider-URI>

./vro-configure-inner.sh trust --alias vco.vsphere.lookup-service.ssl.certificate --uri vcsa70.aaronrombaut.com --accept

A lot of information will scroll past. I am only including a screenshot of the end of the command.

From the document.

./vro-configure-inner.sh trust --alias vco.sso.ssl.certificate --uri <vSphere-Auth-Provider-URI> --accept

With substituted <vSphere-Auth-Provider-URI>

./vro-configure-inner.sh trust --alias vco.sso.ssl.certificate --uri vcsa70.aaronrombaut.com --accept

A lot of information will scroll past. I am only including a screenshot of the end of the command, again.

7. Log out of the vRealize Orchestrator Appliance by using the exit command and log in again. (Added) If you only type exit here once, you will only exit the rpm command. You actually have to end the SSH session or console. You can type exit a second time to close the SSH session.

8. Run the following deploy.sh commands.

/opt/scripts/deploy.sh --onlyClean

A lot of information will scroll past. I am only including a screenshot of the end of the command. This command will take a few minutes to complete.

/opt/scripts/deploy.sh

A lot of information will scroll past. This command will take even longer to complete than the last command. Notice: if you prematurely end this command, your appliance will likely not be recoverable. Trust me when I tell you this. Learn from my pain…

You may even see messages that state Exit code and + return 0 like the screenshot below.

This is not complete, yet. Keep waiting until you see the following screen. (If you are nervous or impatient, get up and take a walk, this seriously takes a really long time, the appliance is going through a restart as part of this process).

Confirm VMware vRealize Orchestrator Appliance Configuration

Navigate to the appliance. Click on the Start the Orchestrator Client link to log on.

Type in your credentials and click the Login button.

Assuming everything went well, you should now be able to log back into the VMware vRealize Orchestrator appliance without error.

Please let me know if this helped you or if something I typed did not line up with what you experienced.

Windows Server Shutdown Event Tracker

Every time I log in to my Windows Servers, I am greeted with the Shutdown Event Tracker. I know I cleanly shutdown, restarted, or only logged off, though. This has been an issue in my lab as well as on customer networks. I wanted to see if there was an easy and reliable fix, which turns out, there is!

Open Registry Editor (regedit.msc).

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability

There are likely two keys here, DirtyShutdown and DirtyShutdownTime that are present. Simply delete these two keys and you should no longer get the Shutdown Event Tracker on subsequent logons.


Using PowerCLI in Smart Card Based Environment

ref: https://kb.vmware.com/s/article/67789

Problem

You work in a hardened environment and you don’t have an administrative username and password because you only have smart cards or tokens.

Resolution

According to VMware, this is expected behavior. Uh, what?

Workaround

According to VMware, “Use Windows SSPI to pass through the Windows logged session Smart Card credentials to PowerCLI to authenticate to vCenter.”

What does that even mean? That was a lot of words that didn’t really explain how to “work around” the issue. So, let’s break it down.

Windows SSPI is Security Support Provider Interface. More details can be found here, https://docs.microsoft.com/en-us/windows/win32/rpc/security-support-provider-interface-sspi-

The optimal way to address this is to have a dedicated workstation or server in the data center that you can log into with PowerShell and PowerCLI installed. Since you are hopefully logging in with your administrator token and your administrator account has either been given permission directly on vSphere or through a security group, then you should be able to just log into the server when you try to use Connect-VIServer (https://vdc-repo.vmware.com/vmwb-repository/dcr-public/85a74cac-7b7b-45b0-b850-00ca08d1f238/ae65ebd9-158b-4f31-aa9c-4bbdc724cc38/doc/Connect-VIServer.html). The credential of the currently logged on user, that’s you, will get passed along with the request.

VMware Authentication Proxy in a DoD Hardened Environment

If you work in IT in the DoD in any capacity, then you know your systems can be a pain to work with if you followed a Security Technical Implementation Guide (STIG). This can be even more of a pain when following a commercial vendor’s installation or configuration documentation, since they write in the general sense and can’t possibly know every quirk in our environment.

From the Windows Server 2016 STIG, (Finding ID: V-73691) the LAN Manager authentication level must be set to send NTLMv2 response only and to refuse LM and NTLM.

From the VMware vSphere 6.5 ESXi STIG, (Finding ID: V-94023) the ESXi host must use the vSphere Authentication Proxy to protect passwords when adding ESXi hosts to Active Directory.

So even though the current STIG is only referencing vSphere 6.5, this can still be used for newer versions. During the configuration of a vCenter Server 7.0 Authentication Proxy, I found that the proxy kept not authenticating. After reviewing the logs on the Domain Controller, it was found that Likewise was sending the authentication to the Domain Controller with an NTLM response and not NTLMv2.

Reconfigure the Likewise service to send NTLMv2 and try to configure the Authentication Proxy again. This time, the configuration should be successful. You can further test by adding an ESXi host to vCenter and ensure it properly joins the domain.

Before configuring NTLMv2 on Likewise

ref: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-DFA95E13-EC95-4951-B94F-6D08CCFAC188.html

  1. Click the ENABLE link.
  2. Click the EDIT link.

Fill in the Domain, Domain User, and Domain Password settings. Click the SAVE button.

Notice the Operation failed! message.

You can also view the log located at /var/log/vmware/vmcam/vmcam-sca.log. Below is an excerpt, notice the Enter password for Service.vSphereAuth line. That indicates that it was not sending the correct password because we know that we typed it into the window.

I ended up tailing the log with the following so I could see in real-time what was occurring.

tail -f /var/log/vmware/vmcam/vmcam-sca.log

Configuring Likewise to Send NTLMv2

Run the following bold commands, the rest is for context.

/opt/likewise/bin/lwregshell
\> cd HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> list_values
    "SendNTLMv2" REG_DWORD 0x00000000 (0)
    "Support128bit" REG_DWORD 0x00000001 (1)
    "Support56bit" REG_DWORD 0x00000001 (1)
    "SupportKeyExchange" REG_DWORD 0x00000001 (1)
    "SupportNTLM2SessionSecurity" REG_DWORD 0x00000001 (1)
    "SupportUnicode" REG_DWORD 0x00000001 (1)
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> set_value SendNTLMv2 1
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> list_values
+   "SendNTLMv2" REG_DWORD 0x00000001 (1)
    "Support128bit" REG_DWORD 0x00000001 (1)
    "Support56bit" REG_DWORD 0x00000001 (1)
    "SupportKeyExchange" REG_DWORD 0x00000001 (1)
    "SupportNTLM2SessionSecurity" REG_DWORD 0x00000001 (1)
    "SupportUnicode" REG_DWORD 0x00000001 (1)
HKEY_THIS_MACHINE\Services\lsass\Parameters\NTLM> quit
/opt/likewise/bin/lwsm restart lwio
Stopping service reverse dependency: lsass
Stopping service reverse dependency: rdr
Stopping service: lwio
Starting service: lwio
Starting service reverse dependency: rdr
Starting service reverse dependency: lsass

Go back to vSphere Client and configure the Authentication Proxy again. You may have to disable and enable the service again if you didn’t restart the service while connected through SSH. This time, it should work without an error. If you are tailing the log, then you should see Active Directory domain added successfully at the bottom.

From here you can Import the vSphere Authentication Proxy Certificate to ESXi Host.

Installing VMware App Volumes 4 Manager – Part 1

ref: https://docs.vmware.com/en/VMware-App-Volumes/4/com.vmware.appvolumes.install.doc/GUID-2E6F56D8-E657-4290-BAE7-E18E7556ADDC.html (VMware App Volumes Installation Guide)

ref: https://docs.vmware.com/en/VMware-App-Volumes/4/com.vmware.appvolumes.install.doc/GUID-25B53F4E-C22B-4DBD-A253-D7FA33D965BF.html (Installing App Volumes)

I will start out this post to mention that if you try to install App Volumes 4 and are stuck on the SQL database portion trying to get Windows Integrated Authentication (WIA) working, you are not alone. I have spent countless hours troubleshooting this and looking for documentation. Documentation seems to be almost non-existent regarding the database requirements, besides which version to use, but nothing specific on database settings or user/computer/other authentication settings. It is very frustrating.

I will also mention that I have installed MS SQL Server 2016 and have set up TLS certificates on the Windows guest as well as configured SQL Server to use the certificate. I have also added the App Volumes server computer account to the database permissions. Please see the following articles, Configuring Microsoft SQL Server for VMware Horizon View, MSSQL SSL/TLS Certificate Chain Fix, and Adding a Computer Account to MS SQL Server for a VMware App Volumes Manager Database, for more information. If you read and follow the three articles provided, you will not encounter an error when configuring the App Volumes Manager database authentication!

I am going to assume that you have some level of technical proficiency if you are this far along in your journey and will not add mundane details like how to mount an ISO or what buttons to click unless following a particular workflow and feel the details are absolutely necessary. Let’s get started…

After downloading App Volumes 4 (https://my.vmware.com/web/vmware/downloads/info/slug/desktop_end_user_computing/vmware_app_volumes/4_x), mount the ISO to your App Volumes server. Navigate to the Installation directory.

Double-click setup.exe.

Click Next.

Check the I accept the terms in the License Agreement checkbox (you did read all that, right?) and Click Next.

Choose the Install App Volumes Manager radio button since we are installing the App Volumes Manager. Click Next.

Not Shown! – You may be presented with a Windows User Account Control (UAC) prompt. Move past this accordingly. The installation up to this point has been a bootstrap of sorts. The next screens will do the actual Manager installation.

Déjà vu? Groundhog Day? Now we proceed with the actual installation of App Volumes Manager. Click Next.

Choose the Connect to an existing SQL Server Database radio button. Click Next.

There is a lot going on at this step. If you read the beginning of this post and followed the two additional articles provided, you should not have any trouble using Windows Integrated Authentication here. To quickly recap:

  • Your MS SQL server and App Volumes Manager servers can resolve DNS forward and reverse lookup records
  • Your MS SQL server has a TLS certificate in the local machine certificate store
  • The user running your MS SQL service has been provided access to the MS SQL server’s private key
  • The MS SQL server has been configured to use the machine’s TLS certificate
  • The MS SQL service or server has been restarted.
  • The App Volumes database has been created.
  • The App Volumes server account (the computer account) has a log in on the MS SQL server and is associated with the App Volumes database. Adding a Computer Account to MS SQL Server for a VMware App Volumes Manager Database
  1. Enter the FQDN for the MS SQL server.
  2. Choose the Windows Integrated Authentication radio button.
  3. Click the Browse… button. If your authentication works properly, this is a good test as it will either show you the databases or it will present you an error.

Choose the database specified for use with App Volumes and click Next.

4. Check the Enable SQL Server certificate validation checkbox.

Click Next.

Almost there, if you are to this point, the hardest part of the installation is over! Leave the default ports unless you like to complicate your life. Click Next.

Optional: Change the installation location if necessary.

Click Next.

Click Install. Take a break! The installer will need a few minutes to install the software.

Confirm that the Wizard completed successfully. See Troubleshooting section below if you did not have a successful installation.

Click Finish.

You have completed the install, but there are some prerequisite steps to take to make the configuration easier and work the first time. Check out the article here: Installing VMware App Volumes 4 Manager – Part 2.

Troubleshooting

Be sure to read the finished dialog! You may receive the following, reporting that the Wizard ended prematurely. You will have to open up the logs and investigate; navigate to your installation directory and look at the logs. The issue that generated the following screenshot for me was either a self-signed certificate issue or a SQL Server issue because I didn’t add the App Volumes Manager server login to the MS SQL server and assign it to the App Volumes database (see below for specific error message and how to fix). Delete the Cloud Volumes directory and try the installation again.

From the inst_ruby_script.log file, you see the following:

E, [2020-11-19T11:43:30.666302 #3196] ERROR -- : ERROR: 28000 (18456) [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Login failed for user 'AARONROMBAUT\APP-001V$'.
E, [2020-11-19T11:43:30.666571 #3196] ERROR -- : ["script/odbc_driver_validator.rb:145:in drvconnect'", "script/odbc_driver_validator.rb:145:inconnect_using_conn_string'", "script/odbc_driver_validator.rb:34:in odbc_connection'", "script/odbc_driver_validator.rb:76:invalidate_conn_and_version'", "script/odbc_driver_validator.rb:183:in <encoded>'", "script/odbc_driver_validator.rb:2:inRGLoader_load'", "script/odbc_driver_validator.rb:2:in `
'"]
Unable to connect to SQLServer. Exiting with status -1.

To resolve this, follow this article: Adding a Computer Account to MS SQL Server for a VMware App Volumes Manager Database.

Configuring Microsoft SQL Server for VMware Horizon View

Software being used:

  • Microsoft SQL Server 2016
  • Microsoft SQL Server Management Studio 18.4
  • VMware Horizon 7.12.0

Configure Microsoft SQL Server

After installing Microsoft SQL Server, a few things need to be configured:

1. Ensure TCP port 1433 is open on any firewall software running on the server.

2. Add a machine certificate to local machine personal store (certlm.msc)

2a. Be sure to add the account that runs the SQL service to the private key. See this post for more details. MSSQL SSL/TLS Certificate Chain Fix

3. Add certificate to Microsoft SQL server. (ref: https://support.microsoft.com/en-us/help/316898/how-to-enable-ssl-encryption-for-an-instance-of-sql-server-by-using-mi)

4. Open Sql Server Configuration Manager. Right-click Protocols for <INSTANCE-NAME>, choose Properties.

5. Click on the Certificate tab.

6. Choose the machine certificate you added earlier, click OK.

7. Back on the Sql Server Configuration Manager window, double-click TCP/IP.

8. Ensure the following settings:

9. Check the Active, Enabled, IP Address, and TCP Port settings. Modify as necessary and click OK. If you do make any modifications, be sure to restart the SQL service.

Creating the VMware Horizon Database and User

  1. Open Microsoft SQL Server Management Studio.
  2. Ensure the SQL server authentication is set to SQL Server and Windows Authentication mode. VMware Horizon does not use Integrated Windows Authentication. (https://docs.vmware.com/en/VMware-Horizon-7/7.12/horizon-installation/GUID-1360BFDF-9F90-47FD-8B6C-E842CF951A53.html)

3. Right-click Databases and choose New Database…

4. Fill in the Database name with a meaningful name. Click OK.

5. Expand Security and Right-click Logins.

6. On the General page, fill in the Login name with a meaningful name. Also choose a password and uncheck Enforce password policy unless you use a strong password. Change the Default database and Default language accordingly.

7. On the Server Roles page, check the sysadmin role.

8. On the User Mapping page, check the database name you created earlier. Click OK.

Configure the Event Database on Horizon View Connection Server

ref: https://docs.vmware.com/en/VMware-Horizon-7/7.12/horizon-installation/GUID-E04FDAC2-AD7B-4B09-B6E0-4A541646869B.html

Deploy VMware Unified Access Gateway with PowerShell

Each version of the Unified Access Gateway will also have PowerShell scripts available in a .zip file. For this post, I am using Unified Access Gateway 20.09. The components can be downloaded from https://my.vmware.com/web/vmware/downloads/info/slug/desktop_end_user_computing/vmware_unified_access_gateway/20_09. You will want to the appliance itself as well as the PowerShell scripts. For this post, I am going to use the FIPS version.

You are also going to need the ovftool that can be downloaded from https://code.vmware.com/web/tool/4.4.0/ovf. In this post, we are going to need the newest version, 4.4.1. Make sure you have installed the ovftool on your Windows machine you are going to deploy from. Also, ensure you can access ovftool from the command line. You may have to add this to the System PATH.

Optionally, you can use an Integrated Development Environment (IDE) of your choice. For this post, I am going to use Visual Studio Code, available at https://code.visualstudio.com/download.

I have TLS certificates from Let’s Encrypt, so I am going to deploy with them as well. For me, this is how I have created my directory structure.

  • certs – contains all of my TLS certificates needed
  • ova – contains the ova I am going to deploy
  • uag-001v_setting.ini – this is the settings file I use for one of my Unified Access Gateways (UAG). You would need one per UAG you want to deploy.
  • uagdeploy.ps1 – PowerShell script included in the PowerShell scripts zip
  • uagdeploy.psm1 – PowerShell module included in the PowerShell scripts zip

The following is my uag-001v_settings.ini file. You can get the “barebones” file after deploying and configuring at least one UAG in vSphere. Then you can export the settings and modify as necessary.


[General]
eth0ErrorMsg={"netmask":"SUCCESS","ip":"SUCCESS","defaultGateway":"SUCCESS"}
#netInternet: Portgroup used in vSphere for Internet/DMZ facing interface
netInternet=DMZ
#ip0: IP address for the netInternet interface
ip0=10.10.10.30
diskMode=
#source: The location of the OVA to deploy
source=.\ova\euc-unified-access-gateway-fips-20.09.0.0-16949983_OVF10.ova
#ip1: IP address for the internal interface
ip1=192.168.92.30
#defaultGateway: IP address for the gateway on the netInternet interface
defaultGateway=10.10.10.1
#target: User ([email protected]), 
#target: vCenter(vcenter.aaronrombaut.com), 
#target: host location (/Datacenter/host/Cluster/vmh-001p.aaronrombaut.com)
target=vi://[email protected]:[email protected]/Datacenter/host/Cluster/vmh-001p.aaronrombaut.com
#ds: Datastore to install to
ds=Synology-LUN01
netmask0=255.255.255.0
#netManagementNetwork= Portgroup used in vSphere
netManagementNetwork=LAN
#netBackendNetwork: Portgroup used in vSphere
netBackendNetwork=LAN
ip0AllocationMode=STATICV4
#name: Name of the Unified Access Gateway appliance
name=uag-001v
deploymentOption=twonic
ip1AllocationMode=STATICV4
netmask1=255.255.255.0
authenticationTimeout=300000
fipsEnabled=true
sysLogType=UDP
uagName=uag-001v
clockSkewTolerance=600
locale=en_US
tls12Enabled=true
tls13Enabled=false
ipMode=STATICV4
requestTimeoutMsec=10000
ipModeforNIC2=STATICV4
tls11Enabled=false
clientConnectionIdleTimeout=360
tls10Enabled=false
adminCertRolledBack=false
cookiesToBeCached=none
enableHTTPHealthMonitor=false
snmpEnabled=false
maxSystemCPUAllowed=100
healthCheckUrl=/favicon.ico
quiesceMode=false
#dns: The Domain Name System server in use
dns=192.168.92.10
isTLS13SetByUser=false
isCiphersSetByUser=false
tlsPortSharingEnabled=true
ceipEnabled=false
bodyReceiveTimeoutMsec=15000
monitorInterval=60
maxConnectionsAllowedPerSession=16
cipherSuites=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
adminPasswordExpirationDays=90
httpConnectionTimeout=120
#dnsSearch: The domain name to use in queries
dnsSearch=aaronrombaut.com
isTLS11SetByUser=false
sessionTimeout=36000000
syslogSystemMessagesEnabled=false
ssl30Enabled=false
#ntpServers: Servers for providing time in the infrastructure
ntpServers=time.cloudflare.com
#sshEnabled: Leave this blank to NOT enable ssh which is recommended in Production
sshEnabled=

[Horizon]
#proxyDestinationUrl: URL for the VMware Horizon Connection Server
proxyDestinationUrl=https://hzn7cs-001v.aaronrombaut.com
disableHtmlAccess=false
rewriteOriginHeader=false
healthCheckUrl=/favicon.ico
proxyDestinationIPSupport=IPV4
queryBrokerInterval=300
matchWindowsUserName=false
windowsSSOEnabled=false
pcoipDisableLegacyCertificate=false
gatewayLocation=External
securityHeaders={"X-Frame-Options":"SAMEORIGIN","Strict-Transport-Security":"max-age=63072000; includeSubdomains; preload","X-Content-Type-Options":"nosniff","Content-Security-Policy":"default-src 'self';font-src 'self' data:;script-src 'self' 'unsafe-inline' 'unsafe-eval' data:;style-src 'self' 'unsafe-inline';img-src 'self' blob: data:","X-XSS-Protection":"1; mode=block"}
proxyDestinationUrlThumbprints=
tunnelExternalUrl=https://myhorizon.aaronrombaut.com:443
blastExternalUrl=https://myhorizon.aaronrombaut.com:8443
radiusClassAttributeList=
smartCardHintPrompt=false
logoutOnCertRemoval=false
redirectHostMappingList=
proxyPattern=(/|/view-client(.*)|/portal(.*)|/appblast(.*))
pcoipExternalUrl=72.225.4.11:4172

[SSLCert] #External facing
pemPrivKey=
pemCerts=
#pfxCerts: The location where the certificates are located
pfxCerts=.\certs\myhorizon-prod.p12
pfxCertAlias=

[SSLCertAdmin] #Internal facing
pemPrivKey=
pemCerts=
#pfxCerts: The location where the certificates are located
pfxCerts=.\certs\myhorizon-prod.p12
pfxCertAlias=

[PackageUpdates]
packageUpdatesScheme=OFF

Open an elevated PowerShell window and navigate to the working directory. You will want to type the following to start the deployment:

.\uagdeploy.ps1 .\uag-001v_settings.ini

Enter and re-enter the root password and admin password.

Enter Yes or No if you want to join the VMware Customer Experience Improvement Program (CEIP).

Enter the password for the vCenter you specified in the settings.ini file above.

You should receive a “deployed successfully” message at the end. From here, you should be able to navigate to the appliance in a web browser and if you used certificates, your page should be accessible, securely. For me, I access the UAG at https://uag-001v.aaronrombaut.com:9443.

If you have other Unified Access Gateways to deploy, just modify the settings.ini file and deploy. Make sure you have records for each UAG added to your DNS forward and reverse lookup zones.