Migrating Horizon from VMware to Omnissa: Why a Parallel Connection Server Deployment Is Often the Safest Approach

March 5, 2026 fabio1975App Volumes, Horizon, Instant Clone, OMNISSA, Unified Access Gateway, Upgrade, vCenter, VDI, vmware2 Comments

The transition from VMware Horizon to Omnissa Horizon introduced more than just a branding change. Starting with Horizon 2412 and continuing with later releases such as 2503 and 2506, several architectural and configuration elements have been modified.

These changes include licensing format updates, ADAM/AD LDS database modifications, registry key renaming, folder restructuring, and updated group policy templates.

While the official upgrade path works, in many environments a parallel deployment strategy can significantly reduce risk and allow end users to validate the new platform before switching production workloads.

This article outlines the key changes introduced by Omnissa and explains why building a new Horizon pod alongside the existing one can be a practical migration strategy.

Key Changes Introduced with Omnissa Horizon

1. New Licensing Model

Beginning with Horizon 2412, Omnissa introduced a new licensing mechanism and licensing portal.

During the transition phase, both VMware and Omnissa license keys are temporarily accepted, but this compatibility window is limited. Later releases, such as 2503.1 ESB and 250,6 rely entirely on the Omnissa License Module (OLM).

If a valid Omnissa license key is not installed after upgrading, the Horizon Console may enter a restricted or degraded mode.

Relevant KB and documentation references include:

• KB 6000212 – Horizon licensing transition guidance

• KB 6000745 – Omnissa rebranding changes and affected components

2. ADAM / AD LDS Database Changes

One of the most important backend changes affects the Horizon LDAP (ADAM/AD LDS) database.

Historically, Horizon used application partitions referencing the VMware namespace.
With the Omnissa rebranding, new environments now use the horizon namespace.

Example:

Old partition naming:

dc=vdi,dc=vmware,dc=int

dc=vdiglobal,dc=vmware,dc=int

New partition naming:

dc=vdi,dc=horizon,dc=internal

dc=vdiglobal,dc=horizon,dc=internal

Omnissa provides a migration script to update the partition names after upgrading all pods to newer versions, such as 2503.

Relevant documentation:

• KB 6000797 – ADLDS partition migration for Horizon

3. Registry Key and File System Changes

The rebranding also impacted multiple components of the Horizon installation:

Component	Previous Location	New Location
Installation folder	C:\Program Files\VMware\VMware View	C:\Program Files\Omnissa\Horizon
Logs	C:\ProgramData\VMware\VDM\logs	C:\ProgramData\Omnissa\Horizon\logs
Registry keys	HKLM\Software\VMware, Inc.\VMware VDM	HKLM\Software\Omnissa\Horizon
ADAM DB instance	VMwareVDMDS	OmnissaHzeDS

Because registry paths changed, Group Policy templates (ADMX) were also updated and must be replaced during upgrades.

Failure to update the ADMX files can lead to policies silently no longer applying.

Why a Parallel Horizon Deployment Can Be a Better Migration Strategy

Although a direct upgrade of the Connection Servers is supported, the number of changes introduced with the Omnissa transition makes a greenfield-style deployment attractive.

Instead of upgrading the existing servers, consider deploying new Connection Servers alongside the current environment.

Advantages include:

1. Opportunity to Upgrade Windows Server

New Connection Servers allow administrators to deploy a modern operating system, such as:

• Windows Server 2022 or later (Windows 2025 is a like option)

This avoids performing multiple upgrades on the same system.

2. User Acceptance Testing

With a parallel deployment, you can:

• publish test desktop pools

• provide pilot users access

• validate authentication flows

• verify DEM and App Volumes integration

Users can test the environment before the production switch.

3. Reduced Upgrade Risk

Upgrading in place modifies:

• ADAM database

• registry keys

• services

• folder paths

A clean installation avoids potential issues caused by legacy configurations.

Example Parallel Migration Architecture

A typical migration architecture might look like this:

Existing Environment

• Horizon Connection Servers

• Unified Access Gateways

• Instant Clone pools

• DEM and App Volumes

New Environment

• New Omnissa Connection Servers

• New Omnissa Unified Access Gateways

• Same vCenter Server

• Same Active Directory

• Same desktop images

• Same DEM*

• Same App Volumes*

*After migration, it will be upgraded.

This allows a staged migration.

Key points:

• vCenter Server can remain unchanged

• Desktop pools can be recreated or migrated

• User profiles continue to work through DEM

Migrating Instant Clone Desktop Pools

In environments heavily using Instant Clones, rebuilding pools manually can be time-consuming.

Automation scripts can accelerate the process by exporting and recreating pools through the Horizon APIs.

In my environment, I use a PowerShell-based migration script that reads the configuration of Instant Clone pools and recreates them on the new pod.

This allows administrators to migrate:

• pool configuration

• entitlements

• naming patterns

• provisioning settings

with minimal manual effort.

This is the link to the script

OMNISSA/OMNISSA – Export and Import Desktop and Entitlements v7.ps1 at main · fabio1975/OMNISSA

Reusing DEM and App Volumes

Existing deployments of

• Omnissa Dynamic Environment Manager

• Omnissa App Volumes

can usually remain unchanged during migration.

However, compatibility must always be validated using the official interoperability matrix.

Relevant documentation:

• Horizon interoperability matrix

• App Volumes compatibility with Horizon

• DEM compatibility with Horizon

Official documentation:

• https://interopmatrix.omnissa.com/

These matrices confirm supported combinations between:

• Horizon versions

• App Volumes

• Dynamic Environment Manager

• vCenter Server

• ESXi

Suggested Migration Workflow

A practical migration process could look like this:

Deploy new Connection Servers with Omnissa Horizon
Deploy new Unified Access Gateways
Connect the new pod to the existing vCenter
Validate App Volumes and DEM compatibility
Recreate or migrate Instant Clone pools
Perform pilot user testing
Switch production access
Decommission legacy Connection Servers
Create the news GPO for Horizon (we need use the new GPO Templates)
Upgrade the Horizon Agent, DEM and App Volumes

Final Thoughts

The transition from VMware Horizon to Omnissa Horizon introduces several structural changes that go beyond simple branding.

Changes in licensing, LDAP partitions, registry paths, and policy templates can complicate traditional upgrade workflows.

For many environments, especially large VDI deployments, deploying new Connection Servers in parallel offers a safer and more flexible migration strategy.

It provides an opportunity to modernize the infrastructure, validate compatibility with components such as App Volumes and DEM, and allow users to test the platform before the final cutover.

Migrate VMware Horizon Client settings to Omnissa Horizon Client with DEM

January 21, 2026January 22, 2026 fabio1975Horizon, Horizon Client, OMNISSA, Powershell, Script, VDILeave a comment

With the rebranding of VMware Horizon Client to Omnissa Horizon Client, one of the often overlooked aspects is the migration of user settings.

In the context in which I had to operate, the main need was to replicate the Horizon Client settings (from VMware to Omnissa version) in a VDI context. The basic settings to be copied were those of “Drive & Folder Sharing”

In enterprise environments – especially non-persistent VDI managed with Omnissa Dynamic Environment Manager (DEM) – it is critical to ensure that:

• The user’s settings are retained

• The migration takes place only once

• There is no impact on subsequent logons

In this article, we look at how to automatically migrate Horizon client settings:

• by:

%AppData%\VMware\VMware Horizon View Client

•at:

%AppData%\Omnissa\Omnissa Horizon Client

using a PowerShell script that is properly integrated into Omnissa DEM.

Prerequisites

Configuring DEM to export customizations of:

• VMware Horizon Client

• Omnissa Horizon Client

• Audit registry key

Precisely:

Approach

The solution is based on three key concepts:

1.PowerShell script in user context

2.Logon Task in Flex Configuration (DEM)

3.Condition based on HKCU registry key to ensure one-time execution

The registry key is saved in the user profile and managed by DEM, making the solution compatible with:

• Floating VDI

• Non-persistent desktops

• DEM profiles

PowerShell Scripts

The following script:

• Check if the migration has already taken place

• Copy settings, if any

•writes a registry key to block subsequent executions

# ==============================
# Omnissa Horizon Client Migration
# ==============================

$SourcePath = Join-Path $env:APPDATA "VMware\VMware Horizon View Client"
$DestinationPath = Join-Path $env:APPDATA "Omnissa\Omnissa Horizon Client"

# Registry key (per-utente)
$RegPath = "HKCU:\Software\Omnissa\Migrations"
$RegName = "HorizonClientSettingsMigrated"

# ---- Controllo se già eseguito ----
if (Test-Path $RegPath) {
    $Migrated = Get-ItemProperty -Path $RegPath -Name $RegName -ErrorAction SilentlyContinue
    if ($Migrated.$RegName -eq 1) {
        exit 0
    }
}

# ---- Verifica sorgente ----
if (-not (Test-Path $SourcePath)) {
    # Scriviamo comunque la chiave per evitare retry inutili
    New-Item -Path $RegPath -Force | Out-Null
    New-ItemProperty -Path $RegPath -Name $RegName -Value 1 -PropertyType DWORD -Force | Out-Null
    exit 0
}

# ---- Creazione destinazione ----
New-Item -Path $DestinationPath -ItemType Directory -Force | Out-Null

# ---- Copia contenuto ----
Copy-Item -Path "$SourcePath\*" `
          -Destination $DestinationPath `
          -Recurse `
          -Force `
          -ErrorAction SilentlyContinue

# ---- Scrittura chiave di completamento ----
New-Item -Path $RegPath -Force | Out-Null
New-ItemProperty -Path $RegPath -Name $RegName -Value 1 -PropertyType DWORD -Force | Out-Null

exit 0

We place the script in the DEM Config share by creating a folder calling it script. In my case

C:\DEMConfig\Script

Configuration in Omnissa DEM

The script must be configured as a Logon Task so from the DEM console:

• User Environment→ Logon Tasks

• Name:

Migrate Horizon Client Settings (VMware → Omnissa)

• Command:

powershell.exe -ExecutionPolicy Bypass -NoProfile -File \\fs02.poultry.lan\DEMConfig\Scripts\Migrate-HorizonClientSettings.ps1

Condition (fundamental)

• Hive: HKEY_CURRENT_USER

• Key: Software\Omnissa\Migrations

• Value: HorizonClientSettingsMigrated

is not equal to 1

This is the video where I try all the steps

SSL Certificates in an Omnissa Horizon + Omnissa Access World: Why They Matter More Than You Think

October 24, 2025 fabio1975Certificate, Horizon, PKI Microsoft, Private CA, Public CA, ssl, TRUESSO, Unified Access Gateway, VDI, Workspace One AccessLeave a comment

Let’s be honest: certificates are not the most exciting thing in IT. They don’t sparkle, they don’t blink, and they rarely impress your CIO in a slide deck. But if you’re running an Omnissa Horizon environment (also with Omnissa Access integration), SSL certificates are the unsung heroes that make your infrastructure secure, trusted, and usable.

In this post, let’s break down why certificates matter, where they should live in your Horizon world, and how they unlock some pretty cool features like True SSO.

The Basics: Why SSL Certificates?

At their core, SSL/TLS certificates do three things:

1.Encrypt traffic – so that nobody can sniff your users’ RDP or Blast traffic.

2.Prove identity – so your clients know they’re talking to the real Horizon server, not some sneaky impostor.

3.Build trust – because “untrusted certificate” pop-ups are the fastest way to kill user confidence.

In Horizon, these are not “nice to haves”—they’re essential.

Public vs Internal CA: Which Flavor Do You Need?

In most deployments, you’ll be juggling two kinds of certificates:

• Public CA Certificates: Perfect for components exposed to the internet—like your Unified Access Gateways (UAGs). Public certs ensure that external clients (home users, contractors, BYOD devices) connect without scary warnings.

• Internal Microsoft CA Certificates: Handy for internal components—like Connection Servers—especially if all your clients are domain-joined and trust your Microsoft enterprise CA. They’re cheaper (sometimes free) and give you tighter control.

Pro tip: You don’t have to pick one or the other. Most production environments mix both.

Certificates in the Horizon Architecture (The Big Picture)

Think of the certificates as passports:

• The UAG needs a passport recognized globally (public CA).

• The Connection Servers can survive with a local passport (internal CA).

• True SSO hands out temporary passports at the border (short-lived certs) so users don’t need to fumble with passwords.

Certificates on Connection Servers

Your Horizon Connection Servers are the brains of the operation. By default, they come with a self-signed certificate. That’s fine for a lab, but in production it’s a recipe for distrust and compatibility issues.

Replacing it with either:

• An internal CA-issued cert (for domain-only environments)

means your Horizon Clients and web browsers connect seamlessly and securely. Bonus: no frantic helpdesk calls about “why does Horizon keep saying untrusted connection?”

Here are more details on how to install the certificates

Certificates on Unified Access Gateways (UAGs)

The UAG is your secure doorway to Horizon from the outside world (more time behind a load balancer). And here, public CA certs are king. Imagine asking a remote contractor to install your company’s internal root CA certificate just to connect—that’s not going to fly.

With a trusted public certificate:

• Users get smooth experience from the get-go.

• Browsers, Horizon Clients, and even thin clients connect without any fuss.

• You avoid troubleshooting nightmares tied to certificate trust chains.

Here are more details on how to install the certificates

The Secret Sauce: Certificates and True SSO

Now, let’s talk about one of Horizon’s coolest features: True SSO.

True SSO lets users log into Horizon desktops and apps with their identity from Omnissa Access—no extra password prompts or integrate with other SAML idP. Behind the scenes, Horizon uses short-lived, smart card-like certificates to authenticate the user to the desktop.

Guess what makes this magic possible? Certificates.

• A trusted internal CA (usually Microsoft AD CS) issues these ephemeral certificates.

• The Horizon infrastructure validates them and grants access seamlessly.

• The user just experiences fast, passwordless login.

So, without properly set up certificates, True SSO doesn’t fly.

Here are more details on how to install the certificates (coming soon)

Wrapping It Up

Certificates might not be glamorous, but in an Omnissa Horizon + Omnissa Access environment they are foundational:

• They secure Connection Servers for internal trust.

• They harden UAGs with public-facing credibility.

• They power True SSO, giving users a smooth, passwordless experience.

Think of them as the quiet guardians of your virtual desktops: invisible when done right, but disastrous if ignored.

So next time you see a certificate renewal reminder, don’t sigh. Smile. Because your Horizon users—and your future self—will thank you.

How to Test an NVIDIA Video Card with Omnissa VDI: A How-To Guide

April 29, 2025April 29, 2025 fabio1975Blender, NVIDIA, OMNISSA, Omnissa Community, Omnissa TechInsider, Unigine Heaven, VDI, vGPU, vSphere, vsphere 8u2Leave a comment

Have you just set up a VDI and want to see if your cool NVIDIA video card is doing its job? Don’t worry, I understand you. There’s nothing more frustrating than spending a fortune on hardware and then finding that the GPU sleeps while the processor does all of it. In this article, I explain in a simple (and fast) way how to test the Nvidia video card within a VDI.

Tested environment

NVIDIA Tesla M10 (not the latest model, but still supported by vSphere and NVIDIA and limited cost for my homelab)

vSphere 8.x (thanks to licenses as vExpert)

Omnissa Horizon 2503 (Thanks to licenses like Omnissa Tech Insider and Omnissa community)

Supermicro as HW

Guest OS Windows 11 2412

NVIDIA drivers installed on ESXi and Windows 11 guest VDI

Configuring the NVIDIA Card: Configuring the Card as Direct Shared

Virtual machine HW: Add the desired cut of the NVIDIA card size

In this link, there are more details on the NVIDIA cards’ size

Virtual GPU Software

First question: But can it be done?

Yes, and it must be done. With modern VDI – we are talking about environments such as those managed with Omnissa (formerly VMware EUC) – it is possible to assign GPUs to virtual machines using technologies such as vGPUs. The problem? It is not always clear if the GPU is really used.

Step 1: Verify that the GPU is mapped

First of all, log in to your VDI (Windows or Linux, little changes) and open the Task Manager or a terminal. In Windows, go to GPU > Performance. If you see “NVIDIA” somewhere, you’re on the right track.

Or use nvidia-smi (yes, it also works in VDI if the drivers are in good shape). It will tell you everything: from the memory used to the temperature, passing through the active processes. It’s like the GPU use.

Step 2: Make the video card work

At this point, test it seriously. What?

Open an app that uses graphics acceleration (e.g., a CAD, a 4K video, or even just YouTube at full quality).

If you’re on Windows, you can also use a lightweight benchmark like Unigine Heaven or Blender

On Linux or more closed environments, you can use command-line tools or scripts to make test renders.

During these tests, keep an eye on nvidia-smi or the Task Manager. If the GPU stays at 0%, there’s something wrong (spoiler: it’s often a driver or vGPU assignment issue).

Step 3: Monitor WHIT style

For continuous monitoring, you can install the NVIDIA System Management Interface or use third-party tools built into the Omnissa environment, such as those included in Horizon (Horizon Performance Tracker) or management plug-ins.

Bonus: Don’t forget the logs

Check the host machine and VM logs. Often, there you will find clues to understand if the GPU passage was successful or if there is something blocking everything.

Ultimately?

Testing an Nvidia GPU on a VDI is not complicated, but it takes a method. With the right tools and a keen eye, you can make sure that your graphics assets are really being used, and that the end user (or yourself) doesn’t have to put up with unnecessary lag or jerking.

Want help scripting an automated test? Write. Or… Launch nvidia-smi (with the -l parameter, it goes into automatic refresh) and see if the vGPU wakes up.

Some suggestions

To get the most out of NVIDIA GPUs in a VDI environment, you need to sign a license agreement. Here is the link Virtual GPU (vGPU) Software Free 90Days Trial | NVIDIA for a 90-day trial (the one I used for testing)

To perform top benchmarks, you have to remove the cap present by default on vSphere for FPS (I would recommend keeping FPS equal to or lower than the Hz value of your monitor, otherwise, we may have a non-optimal fluidity of the images). The cap is deactivated by putting this value in the Advanced settings of the VM’s pciPassthru0.cfg.frame_rate_limiter=0

EUC, un futuro luminoso per Horizon

May 9, 2024May 9, 2024 fabio19752024, App Volumes, Broadcom, cloud, Dem, EUC, Horizon, Horizon 8, OMNISSA, VDI, vmwareLeave a comment

In questi giorni c’è molto fermento nel mondo dell’EUC (‘End-User Computing) in merito alla comparsa sul mercato di un nuovo nome.

Ma partiamo con ordine, nel lontano 2008 mi avvicino al modo delle VDI (Virtual Desktop Infrastructure) inizialmente con l’automatizzazione di aule corsi, grazie a VMware e al suo prodotto che allora era stato appena rinominato in Horizon View (se non sbaglio precedentemente si chiama VMware VDM….. ancora oggi, nelle installazioni dei Connection Server, troviamo una cartella VDM sotto c:\ProgramData).

A diagram of a timeline

Description automatically generated with medium confidence

Col tempo le soluzione VDI di VMware sono evolute in maniera importante con l’aggiunta prima della tecnologia linked clones e poi con le instant clone (tecnologie che permettono di semplificare notevolmente la vita dell’amministratore delle postazioni di lavoro).

Abbiamo visto l’affiancare a Horizon soluzioni che permettono di sfruttare al meglio le VDI come App Volumes, DEM (Dynamic Environment Manager), Workspace One ecc.…

Poi dall’on-premise è stato portato anche sul Cloud con soluzione come Horizon Cloud on Microsoft Azure.

Anche per la mia carriera lavorativa il mondo delle VDI ha lasciato un solco importante dal 2021 sono vEXPERT (Con specificità nel mondo EUC) e dal 2024 sono EUCExpert e collaboro con VMware/Broadcom nel deploy.

Mi direte ok sono cose che ormai conosciamo ma quindi che cosa è successo??

Bene, sappiamo tutti che VMware è stata acquisita da Broadcom e una delle prime dichiarazioni della nuova proprietà è stata quella di non volere investire sull mondo EUC.

Ma quindi che succede?

Tutto i prodotti EUC di VMware sono riconosciuti tra i leader del mercato dei prodotti VDI e Desktop as a Service sono stati comprati da KKR (Fondo Americano nato nel 1977) per cui nasce Omnissa

Nata con persone VMware per garantire la stessa qualità e lo stesso sviluppo in innovazione che è stato garantito in questi anni.

In cui continua o parte una nuova vita (scegliete voi) per tutti i prodotti EUC che molti noi conosciamo e apprezziamo (Horizon ecc…)

Ne vedremo sicuramente delle belle e ci aspetta un futuro luminoso!

VMware Workspace One Access, VMware Horizon, and FIDO2 device

March 8, 2024March 8, 2024 fabio1975FIDO2, Horizon, MFA, NFC, PASSWORD, VDI, Workspace One Access, WS1A, YubikeyLeave a comment

Publishing VDI outside our company network is an activity that has become a necessity for many companies since COVID-19 (employee smart working, workstations dedicated to consultants, etc.). In all the implementations, that I have done in recent years, one of the key points of my installations is the need to implement MFA solutions to increase the level of security.

In this post, I want to explain how to configure the integration of Workspace One Access WS1A, Horizon, and FIDO2 devices (I use a Yubikey 5 Series with NFC and Fingerprint)

A black usb flash drive with a yellow circle and a gold circle

Description automatically generated A hand holding a phone with a sign in the screen

Description automatically generated A green computer with a white cloud in the screen

Description automatically generated

What is VMware WorkSpace One Access?

A screenshot of a computer

Description automatically generated

Workspace ONE Access (vmware.com)

What is VMware Horizon?

A screenshot of a computer

Description automatically generated

VMware Horizon | VDI Software Solutions | VMware

What is FIDO2?

FIDO2 enables users to leverage common devices to easily authenticate to online services in both mobile and desktop environments.

The FIDO2 specifications are the World Wide Web Consortium’s (W3C) Web Authentication (WebAuthn) specification and FIDO Alliance’s corresponding Client-to-Authenticator Protocol (CTAP).

FIDO2 – FIDO Alliance

What is Yubikey 5 Series?

Multi-protocol security key, eliminate account takeovers with strong two-factor, multi-factor, and passwordless authentication, and seamless touch-to-sign. Multi-protocol support allows for strong security for legacy and modern environments. A full range of form factors allows users to secure online accounts on all of the devices that they love, across desktops and mobile.

Multi-protocol support; FIDO2, U2F, Smart card, OTP, OpenPGP 3
USB-A, USB-C, NFC, Lightning
IP68 rated, crush resistant, no batteries required, no moving parts

USB-A YubiKey 5 NFC Two Factor Security Key | Yubico

Configure Workspace one Access(WS1A) SaaS for use FIDO2 authentication

Enable Authentication methods on WS1A.

Go to integrations -> Authentication Methods -> Click on FIDO2 -> Enable FIDO2 Adapter

A screenshot of a computer

Description automatically generated

Now we need to associate the authentication method to Identity provider (created to integrate WS1A with Active Directory)

Go to integrations -> Identity providers -> Click on correct IdP -> Flag FIDO2

A screenshot of a computer

Description automatically generated

After associating the FIDO2 to IdP we need to create the policy to enable self-services FIDO2 device registration (it is possible to pre-configure the FIDO2 device registration)

Go to resources -> Policies -> Click on default_access_policy_set -> Edit

A screenshot of a computer

Description automatically generated

Create to rule:

Rule 1 -> enable self-service registration FIDO2 Device

Rule 2 -> enable the login with only FIDO2 Device

In the next image, there are the Policy Rule configurations

A screenshot of a computer

Description automatically generated

Self-service registration key

Insert the Yubikey 5 into to USB port and log to the Workspace One Access portal.

Now the web portal requires two choices:

To register the device we need to select Register

Now we need to select the authenticator

A screen shot of a computer

Description automatically generated

Select another device

Select Security Key where store the passkey

A screenshot of a computer security system

Description automatically generated

Insert the security pin

A screenshot of a computer

Description automatically generated

Touch the key (there is a fingerprint ….)

A screenshot of a computer

Description automatically generated

A screen shot of a computer security

Description automatically generated

Add a name for the Security Key

A screenshot of a phone

Description automatically generated

Now you are ready to log in with the security key

User Experience login

Access to company workspace one access website

A screen shot of a sign

Description automatically generated

A screenshot of a computer security

Description automatically generated

Insert PIN number associated with FIDO2

A screenshot of a computer security

Description automatically generated

Now touch the key for fingerprint authentication Chiara2013!

A black and white screen with white text

Description automatically generated

You are redirected to Workspace One catalog portal

A screenshot of a computer

Description automatically generated

If you want to show and reset the User FIDO2 device you need to:

Login to Workspace One Access SaaS admin console, go to Accounts, Users and click on the user that you want to reset the device association

A screenshot of a login page

Description automatically generated

Select two-factor authentication

A white and blue rectangle

Description automatically generated

And delete the FIDO2 security key

A screenshot of a computer security key

Description automatically generated

Otherwise, the administrator can associate the new device with the user.

Configure ControlUp for VMware Horizon Instant Clone VDI monitoring

December 9, 2023December 9, 2023 fabio1975Agent, ControlUP, ESXi, Horizon, Logon Time, VDI, vmwareLeave a comment

In this guide, we will analyze how to configure ControlUP COP (ControlUP on-Premise) to monitor a VMware Horizon 2309 infrastructure with Instant Clone Desktop Pools (we will not cover the installation part of the product)

The following steps are required:

Control UP COP Server Component Installation (Optionally use an external SQL instance or SQL EXPRESS present in the Server component installation)
Installing the Control UP Console (Can also be installed on the same server)
Installing Agent Control Up on the GoldImage
Horizon Infrastructure Inventory
VirtualMachine Inventory (For this step we can also implement an automatism)

Requirements for the server part:

COP Server	COP Server	Console Machine
Machine	Windows Server	Windows Server orWindows
Operating System	Windows Server supported versions:2022,2019,2016	Windows Server supported versions:2022,2019,2016 OR Windows 11, 10
CPU*	2 CPUs	2 CPUs
Memory*	8 GB RAM	8 GB RAM
Disk Space*	10 GB	10 GB
Required Software & Permissions	.NET Framework 4.8 or later PowerShell 5.x or later	.NET Framework 4.5 or later

Requirements for Part DB:

MSSQL Versions (Standard, Enterprise, or Express)	Maximum Database Size	Collation
2022,2019,2017,2016,2014	10 GB	SQL_Latin1_General_CP1_CI_AS

Requirements for the VDI part:

ControlUp Agent	ControlUp Agent
Machine	No server installation necessary. Deployed onto Windows machines that are monitored by ControlUp(Linux monitored via API).
Operating system	Windows Server supported versions: 202220192016 (Core or Full)ORWindows 11, 10
Required installed software	.NET 4.5 or later
TCP PORT	40705

A Service Account to access the Horizon infrastructure:

The Read-Only role is sufficient for all monitoring purposes. If you want to perform built-in Horizon actions, then the service account needs the following permissions:

Enable Farm and Desktop Pools
Manage Machine
Manage Sessions
Manage Global Sessions (Cloud Pod architecture only)

So what is needed is:

Download the version of ControlUP COP from the VMware site

A screenshot of a computer

Description automatically generated

Download the on-premise version

Perform the basic installation

Once the COP version is installed and the console is installed, log in to our ControlUP installation

A screenshot of a computer

Description automatically generated

How to install the agent on the GoldImage:

The agent MSI file is on the downloaded file zip from VMware Portal
Open the Real-Time Console and go to Agent Settings and copy your Agents Authentication Key. The key is used to connect the Agent to your ControlUp environment.

A screenshot of a computer

Description automatically generated

Run the installation of the MSI package on the machine where you want to install the Agent.
During the installation, paste the authentication key that you copied from the Real-Time Console.

A screenshot of a computer

Description automatically generated

Complete the installation. The Agent is installed on the machine and the machine can be monitored from the Real-Time Console.
Take the snapshot
Deploy the new master image on Desktop Pool

Now from the ControlUp Management console, we are able to:

Connect our Vmware Horizon infrastructure
Connect the instant clone machine

Add Horizon infrastructure:

A screenshot of a computer

Description automatically generated

Add the infrastructure info

A screenshot of a computer

Description automatically generated

Click on OK

A screen shot of a computer

Description automatically generated

Add the pod to the console

A screenshot of a computer

Description automatically generated

Now on the left panel, we have our Horizon infrastructure added.

A screenshot of a computer

Description automatically generated

To monitor correctly our instant clone (after adding the agent) we need to discover the VM like a Machine

A screenshot of a computer

Description automatically generated

Search with the partial name of the VDI machines

A screenshot of a computer

Description automatically generated

Select cancel

A screenshot of a computer error message

Description automatically generated

We are VM on the left control panel in black status

A screenshot of a computer

Description automatically generated

After a few seconds the VDI VM Goes to Green

A screenshot of a computer

Description automatically generated

Auto connect state must be enabled (this function is important when the instant clone VDI is removed and recreated).

A screenshot of a computer

Description automatically generated

Now we can monitoring the Instant-Clone VDI

Check the VDI logon duration

Now we can manage and control the infrastructure, for example, to check the logon duration

A screenshot of a computer

Description automatically generated

What happens when VDI instant clones are regenerated?

If a user disconnects from his VDI of the instant clone type, it is destroyed and recreated, on the ControlUp side this is put in the Red -> Yellow state until it returns to Green

When recreating

A screenshot of a computer

Description automatically generated

After recess

A screenshot of a computer

Description automatically generated

Dynamic inventory

For a dynamic inventory of VDI, we can use Synchronization with Universal Sync Script (I’ll talk about this in a future post)

EUC Synchronization with Universal Sync Script (controlup.com)

After installation, we can schedule or start manually the script to sync my ControlUP with my EUC infrastructure.

References:

How to Deploy the Agent on Your Master Image for PVS/MCS/Linked/Instant Clones (controlup.com)

EUC Synchronization with Universal Sync Script (controlup.com)

ControlUp On-Premises

Steps for Upgrade Horizon 23xx to the next version

November 29, 2023November 29, 2023 fabio1975Broadcom, EUC, Horizon, Upgrade, VDI, vmwareLeave a comment

The release of new versions of VMware Horizon 8 each quarter of the year (to provide new features and resolve any security holes) entails the need to have a consolidated, conservative update procedure with the least impact on users.
Below I report the procedure that I am using successfully.

User impact:

Users already connected to the VDI do not encounter problems or disconnections
Users who need to connect during update activities may have problems (normally a maintenance window is declared)

Steps

Restarting the Connection Servers Operating System (One at a time is a step preparatory for committing any pending Windows updates), after each reboot check from the Horizon web console that everything is ok
Disable Provisioning
Shut down all three Connection Servers
Snapshot of the VMs hosting the Server connection
Turn on the Connection Server (One at a time), after each reboot check from the Horizon web console that everything is ok
Backup DB Adam (C:\Program Files\VMware\VMware View\Server\tools\bin\vdmexport.exe > vdmconfig.ldf)
Disable and Updating one Connection Server ( disabling the Connection Server being updated puts the connection server offline for the load balancer on the top of the connection servers and it is not used for authenticating users and assigning VDI) and after upgrade enable the Connection Server.
Repeat the previous step for all Connection Servers
If necessary, reapply the customizations
Check from the console that everything is ok

After the horizon upgrade, test the Desktop Pool:

Try a connection from internal
Try a connection from external
Delete a VDI machine
Publish a new Master Image

For upgrading three Connection servers all steps necessity of two hours
During the activities, the users connected to the VDI do not encounter any problems

The next step, after complete the Connection Servers upgrade, is to update the Horizon agent on the master image and delete the Connection Servers snapshot

421 Unknow

October 11, 2023October 11, 2023 fabio1975421 Unknow, Connection Server, Horizon, UAG, VDILeave a comment

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)

Use Horizon VDI and VPN client

August 3, 2023August 3, 2023 fabio1975Agent, Client, Horizon, Subnet, VDI, vmware, VPNLeave a comment

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:

BIOLNX

vmvirtual.blog

Menu

VDI

Migrating Horizon from VMware to Omnissa: Why a Parallel Connection Server Deployment Is Often the Safest Approach

Key Changes Introduced with Omnissa Horizon

Why a Parallel Horizon Deployment Can Be a Better Migration Strategy

Example Parallel Migration Architecture

Migrating Instant Clone Desktop Pools

Reusing DEM and App Volumes

Suggested Migration Workflow

Final Thoughts

Migrate VMware Horizon Client settings to Omnissa Horizon Client with DEM

SSL Certificates in an Omnissa Horizon + Omnissa Access World: Why They Matter More Than You Think

How to Test an NVIDIA Video Card with Omnissa VDI: A How-To Guide

Tested environment

First question: But can it be done?

Step 1: Verify that the GPU is mapped

Step 2: Make the video card work

Step 3: Monitor WHIT style

Bonus: Don’t forget the logs

Some suggestions

VMware Workspace One Access, VMware Horizon, and FIDO2 device

Configure ControlUp for VMware Horizon Instant Clone VDI monitoring

Steps for Upgrade Horizon 23xx to the next version

421 Unknow

Use Horizon VDI and VPN client