421 Unknow

After upgrading Horizon to 2306 2212.1 or 2111.1 we see this message when trying to connect from UAG

In the log, I see this error:

2021-09-24T22:05:34.737-07:00 ERROR (1B08-1A58) <SimpleDeamonThread> [h] (ajp:admin:Request190) Unexpected Origin: https://newname.net

2021-09-24T22:05:34.738-07:00 DEBUG (1B08-1A58) <SimpleDeamonThread> [v] (ajp:admin:Request190) Response 404 Not Found [close]

The fast solution is to set allowUnexpectedHost to true on the locked.properties file. This is located on each connection server in     c:\program files\vmware\VMware View\Server\sslgateway\conf. and restart the horizon connection services

Cross-Origin Resource Sharing (CORS) with Horizon 8 and loadbalanced HTML5 access. (85801) (vmware.com)

Error 421 while connecting to Horizon via HTML Web Console after an upgrade to 2306,2111.1 or Later (93915) (vmware.com)

421 Unknow

Use Horizon VDI and VPN client

For us consultants, the VDI used in the Horizon environment can also be useful for having environments where we can install customers’ VPN clients.
Normally we find ourselves having, if the customer does not have Horizon infrastructure to give us access from the outside (Through UAG, MFA … all possible security), different VPN clients to support our customers, with the consequence of possible problems of compatibility between clients and degradation of your laptop.

In my case, I have a Horizon infrastructure in my Home Lab and I have created my own VDI where to install the clients’ VPN clients.
The only change to make, to prevent my Horizon session from ending when I activate a VPN connection, is to enter the following registry key
HKLM\Software\VMware, Inc.\VMware VDM\IpPrefix = n.n.n.n/m (REG_SZ)

where in n.n.n.n is the subnet and m is the number of bits in the subnet mask. Specifically, the network that must be used for the connection between the horizon agent and the various components (Horizon Client, Connection server, etc..)

es:

Use Horizon VDI and VPN client

Horizon Client Linux, Domain User, and USB Redirect issue

We have a problem with USB redirection on the Linux client, the issue is present when a Linux guest OS (UBUNTU 20.04 in my case) is joined at the domain and we try to use a domain user to access the Linux to start a Horizon session with the Horizon client

The issue is “ USB initializing…” remain for all time and no USB device is redirected

A screenshot of a computer

Description automatically generated

In the log file /tmp/vmware-<user>/vmware-view-usbd-<pid session>.log we found

A screenshot of a computer program

Description automatically generated

With a Linux local user, the problem is not present.

Workaround

Add to /etc/passwd the domain user, for recover GID e UID use the command id <username>

A screen shot of a computer

Description automatically generated

After this, we need to restart the USB Arbitrator

After applying the workaround the problem is resolved

A screenshot of a computer

Description automatically generated

And I don’t have any error in the log file

A screenshot of a computer

Description automatically generated

Horizon Client Linux, Domain User, and USB Redirect issue

vSphere Distributed Switch health check

For us VMware systems engineers who every day find ourselves “dialoguing” with those who manage the network ecosystem, we can only find the vSphere Distributed Switch health check function useful.

  1. What these checks allow us to highlight:

These are some of the common configuration errors that health check identifies:

  • Mismatched VLAN trunks between a vSphere distributed switch and a physical switch.
  • Mismatched MTU settings between physical network adapters, distributed switches, and physical switch ports.
  • Mismatched virtual switch teaming policies for the physical switch port-channel settings.

The network health check in vSphere monitors the following three network parameters at regular intervals:

  • VLAN: Checks whether vSphere distributed switch VLAN settings match trunk port configuration on the adjacent physical switch ports.
  • MTU: Checks whether the physical access switch port MTU setting based on per VLAN matches the vSphere distributed switch MTU setting.
  • Network adapter teaming: Checks whether the physical access switch ports EtherChannel setting matches the distributed switch distributed port group IP Hash teaming policy settings.
  1. How to activate:

Access the network section of our vCenter

Select the vDS on which we want to activate health checks

A screenshot of a computer

Description automatically generated

And enable the check that interests us:

A screenshot of a computer

Description automatically generated

  1. Where to check the outcome of the checks?

Wait a few minutes and already first feedback we can have it on ESXi hosts using the vDS in question, where if there are problems the classic red dot will be displayed

A screenshot of a computer

Description automatically generated

For more details, access the network section of our vCenter and select the vDS in question

A screenshot of a computer

Description automatically generated

And we can see that on the vmnic0 and vmnic3 of the first host, there are vLANs of which we have a Portgroup but which are not proposed correctly on all the ports of the switches to which we have attested our hosts. Then we have to have the configuration verified by our colleagues in the network.

  1. How to turn it off:

Repeat the enabling steps but this time select disable.

  1. Risks in activating it (we always consider activating it for a short time)

Depending on the options that you select, the vSphere Distributed Switch Health Check can generate a significant number of MAC addresses for testing teaming policy, MTU size, vLAN configuration, resulting in extra network traffic.
Ensure the number of MAC addresses to be generated by the health check will be less than the size of the physical switch(es) MAC table. Otherwise, there is a risk that the switches will run out of memory, with subsequent network connectivity failures. After you disable vSphere Distributed Switch Health Check, the generated MAC addresses age out of your physical network environment according to your network policy.

More info:

vDS Health Check reports unsupported VLANs for MTU and VLAN (2140503) (vmware.com)

Enabling vSphere Distributed Switch health check in the vSphere Web Client (2032878) (vmware.com)

vSphere Distributed Switch health check

Enable copy and paste between Guest Operating System and Remote Console

Copy and paste operations between the guest operating system and remote console are deactivated by default. 

To enable it:

  • Browse to the virtual machine in the vSphere Client inventory
  • Right-click the virtual machine and click Edit Settings.
  • Select Advanced Parameters.
  • Add or edit the following parameters.

    isolation.tools.copy.disable False
    isolation.tools.paste.disable False
    isolation.tools.setGUIOptions.enable True
    These options override any settings made in the guest operating system’s VMware Tools control panel.
  • Click OK.
  • (Optional) If you made changes to the configuration parameters, restart the virtual machine.

Enable copy and paste between Guest Operating System and Remote Console

Prechecks fail during upgrade to vCenter Server 7.0 with the following message “The source appliance FQDN must be the same as the source appliance primary network identifier”

When upgrading vCenter 6.5x to version 7u3x we encountered the following problem

Text

Description automatically generated

Following this KB

Upgrading to vCenter Server 7.0 fails when case differs between FQDN and PNID (84355) (vmware.com)

We identify the problem in the fact that we have the hostname that differs from the PNID because one is all uppercase and the other lowercase.

From the following KB we find that we can not on vCenter 6.5 updatethe hostname

Cannot change the vCenter Server or Platform Service Controller 6.x hostname on versions prior to vCenter Server 6.7 Update 3 (2130599) (vmware.com)

To solve we proceed first with the update to the version of vcenter 6.7u3 that fixes the part of FQDN

Graphical user interface, text

Description automatically generated

Once updated to 6.7 relaunch the commands indicated by KB and see that the PNID and hostname coincide

Then we update to the vCenter version 7u3

Prechecks fail during upgrade to vCenter Server 7.0 with the following message “The source appliance FQDN must be the same as the source appliance primary network identifier”

Enabling Break-Glass URL Endpoint in Workspace ONE Access

A customer during the integration of Workspace One Access with Azure AD for MFA activation “locked out” the admin interface.

Prior to version 21.08, a URL was enabled by default on each Workspace One Access VSA for Break-glass URL Endpoint access.

https://< TENANT URL>/SAAS/login/0

from 21.08 onwards it was disabled because it was not security complaint for customer environments

To enable it, you must SSH or WEB GUI access one of the Workspace One Access VSA and run the following command:

hznAdminTool configureBreakGlassLogin enable -loginZero

and restart the horizon-workspace service with the following command.

Service Horizon-workspace restart

Text

Description automatically generated

At this point the “Emergency” URL is enabled again

Graphical user interface, application, website

Description automatically generated

And you can access it to fix the necessary policies.

To turn it off:

hznAdminTool configureBreakGlassLogin disable -loginZero

Service Horizon-workspace restart

Enabling Break-Glass URL Endpoint in Workspace ONE Access

Authenticator APP and Workspace One Access

It is very important to activate MFA (Multi-factor authentication) using applications such as Google Authenticator on corporate services exposed on the internet that require access using credentials.

If we talk about VMware Workspace One Access, a solution that allows us to publish applications and business services on the internet, it is mandatory to activate the MFA.

Since Workspace One Access version 22.09, you can use Authentication Applications such as Microsoft or Google.

Enabling MFA requires a few steps:

  • Enable the “Authenticator APP” authentication method on Workspace One Access
  • Ask the end user to install the APP on their phone or the company one (possibly we can use services that allow us to enrol automatically)
  • At the first access, the user will have to scan the QRcode that appears on the login page of Workspace One Access (in my case we try the access via WEB to workspace one access)

Enable the “Authenticator APP” authentication method on Workspace One Access

Access the Integration menu, select Authentication Methods, enable Authenticator App and select Configure.

Graphical user interface, text, application, email

Description automatically generated

We enable and possibly can change any classic account lock parameters etc …

Graphical user interface, text, application, email

Description automatically generated

At this point, we go to integrations, select identity provider and select our IDP related to the integration with AD

Graphical user interface, text, application, email

Description automatically generated

In the Authentication Methods menu select Authenticator APP

Graphical user interface, text, email

Description automatically generated

At this point, we just need to go and modify the policy used by our users by adding MFA for authentication

We go to the Resources, policies menu, select our policy and modify it

Graphical user interface, text, application, email

Description automatically generated

Graphical user interface, text, application, email

Description automatically generated

We select the rule of our interest (normally we select the one relating to access from public networks because we could reason that those who access from the company network have already done other methods of secure authentication …)

Graphical user interface, text, application, email

Description automatically generated

In the authentication methods used, we add the authenticator app

Graphical user interface, text

Description automatically generated with medium confidence

Graphical user interface, text, application, email

Description automatically generated

From now on, all users who log in to workspace one access and run with the rule we have modified we have the following user experience at the first login:

User experience at login

Go to WorkSpace One Access public URL.

If prompted, they will have to select the domain.

Graphical user interface, application

Description automatically generated

Then they will have to enter username and password

Graphical user interface, application

Description automatically generated

Finally, they will have a QRcode that they will have to use to configure their Authenticator APP (Microsoft or Google). So, in the selected phone app they will have to add an account by reading the QRCODE

Qr code

Description automatically generated

We access our smartphone and launch the authentication application that we will use (in my case I launch Google Authenticator)

Icon

Description automatically generated

We add the new account

Graphical user interface, text, application

Description automatically generated

We select the option to scan a QRCODE and scan it

Enter the passcode generated after scanning the QRCODE in the space provided under the QRcode code on the page WEB

Qr code

Description automatically generated

We will now have an account named WSA (Woekspace One:WSA) linked to our authenticator app

Graphical user interface, text, application

Description automatically generated

From the next login after entering your username and password you will be asked for the access code generated by the user application

Authenticator APP and Workspace One Access

Remove an instant clone desktop pool in a deleting state

If we are removing a desktop pool from a Horizon infrastructure and we find ourselves in a situation that remains in a deleting state:

Graphical user interface, text, application

Description automatically generated

We can force the removal as follows:

  • Remove any VDI VMs still in your vSphere infrastructure.
  • Remove VM template, replication and parent.

In my example, we have the following situation

Graphical user interface, text, application

Description automatically generated

To remove them we use the tool iccleanup.cmd, we find te command on the connection servers by launching the following command to access:

iccleanup.cmd -vc <ome of vcenter> -uid < admin user of vcenter>

We enter the account password

Run with the list command the list of service VMs to be deleted

Text

Description automatically generated

In my case, they are the VMs indicated with ID 2 and 3

We start from 2 and first launch the unprotect indicating with -I the number 2 (unprotect -I 2) and confirm by writing unprotect

Text

Description automatically generated

Then we delete with the question delete -I 2 and confirm by writing  delete

Graphical user interface, text

Description automatically generated

Let’s go back by writing Back

Relaunch the List command and verify that Index has taken the other chain of system VMs to be deleted

Text

Description automatically generated with medium confidence

Ha was taken as index 2

We review the operations of unprotect and delete once again for index 2

At the end of the vCenter  (they are service VM from other pools that should not be deleted)

Text

Description automatically generated

Already in this case, we may have deleted the DesktopPool that was in a deleting state.

If the Pool in question is still present and in a deleting state, we proceed to access the ADSI Edit console and modify the ADAM DB by deleting the references left to the pool in deleting state (in my case ICTPM)

  • Remove Desktop Pool from ADAM Database

To connect follow this KB:

Connecting to the Horizon View Local ADAM Database (vmware.com)

remove the pool from Adam as follows.

Graphical user interface, text, application

Description automatically generated

Graphical user interface, text

Description automatically generated

Remove an instant clone desktop pool in a deleting state