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:
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:
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:
This avoids performing multiple upgrades on the same system.
2. User Acceptance Testing
With a parallel deployment, you can:
Users can test the environment before the production switch.
3. Reduced Upgrade Risk
Upgrading in place modifies:
A clean installation avoids potential issues caused by legacy configurations.
Example Parallel Migration Architecture
A typical migration architecture might look like this:
Existing Environment
New Environment
*After migration, it will be upgraded.
This allows a staged migration.
Key points:
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:
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
can usually remain unchanged during migration.
However, compatibility must always be validated using the official interoperability matrix.
Relevant documentation:
Official documentation:
These matrices confirm supported combinations between:
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.
