UPDATE – Remote Assistance Issue After January 2026 Windows Updates

April 13, 2026April 23, 2026 fabio1975Leave a comment

Following up on the issue “Remote Assistance can’t make the connection”, as already mentioned in last week’s KB, the root cause has now been clearly identified.

The problem is related to recent Microsoft updates released for Windows 11, which address the security vulnerability CVE-2026-20824.

More specifically, the issue is documented in the following KB:

Remote Assistance feature of Omnissa Horizon View Administrator console, not working after January 2026 Windows security update (KB5074109) (6001252)

Note: The solution to this issue is described at the end of this post.

When Does the Issue Occur?

A key point to understand is that the issue is triggered if the updates are installed on either side of the Remote Assistance session:

The target machine (the device receiving assistance)
The operator machine (the device providing assistance)

This means that even if your VDI environment is not patched, the error will still occur if the support operator is using a Windows 11 machine updated after January 2026.

The result is the well-known error:

Expected Fix

A permanent fix is expected to be released soon with Omnissa Horizon version 2603 (I hope )

Current Workaround

At the moment, if you want to provide Remote Assistance without removing Windows updates, you must follow a manual (and somewhat cumbersome) process.

Steps for the End User (Receiving Assistance)

Click on the Start (Windows) button
Search for and open Remote Assistance
Select “Invite someone you trust to help you”
Click “Save this invitation as a file”
Save the file and share it with the support operator
A security code will be displayed — share this code as well

Steps for the Support Operator

Open the received invitation file
Enter the provided security code
Click OK

Final Step

The end user will receive a prompt to approve the connection
Once approved, the Remote Assistance session will start

Final Considerations

This workaround allows you to continue providing support without uninstalling security updates, but it is clearly less efficient compared to the standard workflow within the Horizon console.

Until the official fix is released, it is important to:

Inform support teams about the behaviour
Adjust troubleshooting procedures accordingly
Plan for the upcoming Horizon upgrade

Update (April 2026)
The issue described in this article regarding Remote Assistance after the January 2026 Windows updates has been resolved starting from Horizon Agent 2603, with the introduction of a specific registry key.

✅ Solution for Horizon Agent 2603 and later

With Horizon Agent 2603, the issue can be resolved by configuring the following registry key:

HKLM\SOFTWARE\Omnissa\Horizon\RemoteAssistance\fEnableLHTicket

STRING with value set to 1

This key enables a new Remote Assistance user experience, changing the behaviour compared to previous versions.

🧑‍💻 New user experience

When this setting is enabled:

The Remote Assistance session follows a more modern workflow aligned with recent Microsoft security changes
End users receive clearer and more contextual notifications
Compatibility with the latest Windows security updates is ensured

With the key modified, when a Remote Assistance session is initiated, the VDI user will see a code displayed on their screen (similar to the image below) that they must communicate to the operator to allow the operator to connect.

Versions before 2603

For Horizon Agent versions earlier than 2603, the registry key is not available by default.

In this case:

You must open a support request with Omnissa
Support can provide a specific/custom Agent build
Only with that version will it be possible to enable the registry key

Recommendations

- Plan to upgrade to Horizon Agent 2603 or later whenever possible
- Validate the registry configuration within your environment before production rollout
- Test the new user experience to understand the behavioral changes

Checking Horizon Cloud Services Connectivity from Horizon Edge Gateway

March 6, 2026 fabio1975firewall, HCS, Horizon, Horizon Cloud Services, Horizon Edge Gateway, license, ProxyLeave a comment

It is important to remember that the Horizon Edge Gateway is not only used for enabling integration with Horizon Cloud Services, but it is also required in many environments for Horizon subscription licensing.

In modern deployments of Omnissa Horizon, subscription licenses are delivered through the Horizon Cloud control plane rather than through traditional license keys. To enable this mechanism, each Horizon pod must be connected to the cloud service using a Horizon Edge Gateway appliance.

When using subscription-based licensing:

• The Horizon Edge Gateway connects the Horizon pod to Horizon Cloud Services.

• The control plane synchronizes and delivers the Horizon license entitlement.

• No manual license key entry is required on the Connection Server.

For this reason, outbound connectivity to the Horizon Cloud endpoints is critical, not only for cloud services but also for maintaining a valid licensing state in subscription-based environments.

If the Edge Gateway cannot reach the required endpoints due to firewall restrictions, proxy configuration, or SSL inspection, administrators may experience issues such as:

• License synchronization failures

• Horizon services reporting licensing errors

• Problems during onboarding or control plane communication

In contrast, environments using term/perpetual license keys entered directly in the Horizon Console do not require a Horizon Edge Gateway, because licensing is handled locally within the pod.

Checking the connectivity

When deploying environments based on Omnissa Horizon integrated with Horizon Cloud Services (HCS), proper outbound connectivity from the Horizon Edge Gateway is critical.

This is the link for Port and Protocol Requirements for Deploying Horizon 8 Edge:

Port and Protocol Requirements for Deploying Horizon 8 Edge

In many enterprise environments, outbound communication toward the internet is tightly controlled through firewalls, proxies, or SSL inspection systems. While this is perfectly reasonable from a security perspective, it often introduces connectivity issues if the required endpoints are not properly allowed.

Even more commonly, the configuration works initially but breaks later because firewall rules are modified, security appliances are upgraded, or SSL inspection policies change over time.

For this reason, whenever issues arise with Horizon Cloud integration, the first thing to verify is whether the Edge Gateway can still reach the required Horizon Cloud Services endpoints.

Fortunately, the Edge Gateway provides a built-in diagnostic tool to help with exactly this scenario.

Using diagnostic.sh to Test Connectivity

The Horizon Edge Gateway includes a script called diagnostic.sh

This script performs a series of connectivity checks toward the Horizon Cloud Services endpoints required for proper operation.

The script validates:

• DNS resolution

• HTTPS connectivity

• Reachability of the required Horizon Cloud endpoints

• TLS handshake validation

This makes it extremely useful when troubleshooting issues caused by:

• Missing firewall rules

• SSL inspection interfering with TLS connections

• DNS resolution problems

• Proxy misconfigurations

Running the Diagnostic Script

And run this command:

The script will test connectivity against multiple Horizon Cloud endpoints and return the results directly to the console.

A successful test typically shows results like:

If a problem exists, the script will clearly indicate which test failed.

Why This Check Is Important

Connectivity to Horizon Cloud Services is essential for several platform features, including:

• Edge Gateway registration

• Horizon control plane communication

• Monitoring and service updates

• Validate the Horizon License

Because firewall and security policies frequently evolve in enterprise environments, it’s a good practice to periodically validate connectivity using the diagnostic tool.

Running the diagnostic script can quickly confirm whether the issue is related to networking or to another component of the Horizon environment.

Spoiler:

There may be proxy problems. For which proxy it is used, you can read this configuration file:

/opt/horizon/var/data/proxy.conf

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.

Horizon Cloud Service Next Gen Apis – Chapter 2

February 27, 2026February 27, 2026 fabio1975cloud, Cloud Horizon Omnissa, Horizon Cloud Service, Next Gen, Powershell, RestAPI, Syslog, UAG, Unified Access GatewayLeave a comment

Immagine che contiene testo, Neon, Segnali luminosi, Insegna al neon Il contenuto generato dall'IA potrebbe non essere corretto.

Set Syslog settings across UAG deployments

In this second article on working with APIs in Horizon Cloud Services, we will focus on a practical, security-relevant use case: configuring Syslog on Unified Access Gateways (UAGs) deployed through Horizon Cloud.

Whether you are running Horizon Cloud Service on Microsoft Azure or Horizon Cloud Service on vSphere, centralized logging is a fundamental component of any secure and well-governed environment. Proper Syslog configuration ensures that security events, authentication logs, and operational data generated by UAG appliances are forwarded to your SIEM or log management platform for monitoring, auditing, and incident response.

Instead of performing manual configuration tasks, we will explore how to leverage Horizon Cloud APIs to automate and standardise Syslog settings across UAG deployments, improving consistency, scalability, and operational efficiency.

Now when can explain the API we need to use and how to apply the syslog configuration on UAG (In this case, I used an HCS on vSphere, the new solution where we don’t deploy the Connection Server, but we use the HCS control panel to configure Pools, Entitlements and other…)

The first step is always the authentication process; I explained how to create the API token in my previous post (Horizon Cloud Service Next Gen Apis – Chapter 1), and now I won’t explain it again.

Let’s go…..

How to show UAG information

This command displays the UAG’s information

Invoke-RestMethod -Uri https://cloud-sg.horizon.omnissa.com/admin/v2/uag-deployments Method Get -Headers $Header

We have two UAG deployments connected to HCS, and the output displays two deployment ids:

The UAG id for HCS on vSphere is the second id.

Now I need to recover only the UAG IDs and OrgIDs

Invoke-RestMethod -Uri https://cloud-sg.horizon.omnissa.com/admin/v2/uag-deployments -Method Get -Headers $Header | Select-Object -ExpandProperty content | Select-Object id,OrgId

The UAG id that I need to use for identifying the deployment for HCS on vSphere is:

6994998bcb2a7086afaddf1c

I will use this ID to associate the syslog configuration with the UAG server.

How to set the correct parameters for Syslog configuration

We need to create a Body value like this:

$Body = @{
  orgId  = "8a4931b3-e6ac-44bf-9d25-723f4119e46f"
  projectId = "Pollaio-Project"
  name = "Pollaio-Configuration2"
  syslogEventCategory = "ALL_EVENTS"
  syslogServerProtocolSettingsCreateTO = @{
    sourceToSyslogServerProtocol = "TCP"
  }
  syslogFormat = "TEXT"
  syslogURI = "192.168.111.223:514"
  includeSystemMessages = $true
  sources = @(
    @{
      type = "UAG"
      id   = "6994998bcb2a7086afaddf1c"
    }
  )
}

Where:

Value	Description	Accept value
OrgID	It is the OrgId that we recovered with the previous command	String
ProjectId	ID of theCSP project that owns this data	String
Name	User defined name of the syslog server configuration	String
SyslogEventCategory	Events sent from the UAG appliance to the syslog server	[ ALL_EVENTS, AUDIT_EVENTS ]
sourceToSyslogServerProtocol	The protocol used to send data from the UAG appliance to the syslog server	[ UDP, TCP, TLS, MQTT ]
syslogFormat		[ JSON_TITAN, TEXT ]
syslogURI	Syslog server URI	String
includeSystemMessages	If true, system messages are sent to the syslog server	[ $True]
sources	List of sources associated with the syslog server: Type = Source for the syslog server. For es: UAG Id = Id of the source associated with the syslog server (The Id value that we recovered with the previous command

How to set the configuration for UAG

$Body = @{
  orgId  = "8a4931b3-e6ac-44bf-9d25-723f4119e46f"
  projectId = "Pollaio-Project"
  name = "Pollaio-Configuration2"
  syslogEventCategory = "ALL_EVENTS"
  syslogServerProtocolSettingsCreateTO = @{
    sourceToSyslogServerProtocol = "TCP"
  }
  syslogFormat = "TEXT"
  syslogURI = "192.168.111.223:514"
  includeSystemMessages = $true
  sources = @(
    @{
      type = "UAG"
      id   = "6994998bcb2a7086afaddf1c"
    }
  )
}

#Convert Body to JSON
$JsonBody = $Body | ConvertTo-Json -Depth 5
#Send POST request to create Syslog Server UAG configuration
Invoke-RestMethod -Uri https://cloud-sg.horizon.omnissa.com/admin/v1/syslog-server -Method Post -Headers $Header -Body $JsonBody

HOW to check SYSLOG Configuration on UAG deployment

Invoke-RestMethod -Uri https://cloud-sg.horizon.omnissa.com/admin/v1/syslog-server -Method Get -Headers $Header

The command output is like this:

Now I can see in my SYSLOG server the UAG Log

Horizon Cloud Service Next Gen Apis – Chapter 1

February 26, 2026February 27, 2026 fabio1975APIs, Horizon, Horizon Cloud Service, Postman, Powershell Script, RestAPILeave a comment

Immagine che contiene testo, Carattere, Insegna al neon, Neon Il contenuto generato dall'IA potrebbe non essere corretto.

If you are working with Omnissa Horizon Cloud Services, sooner or later you will want to automate tasks, integrate with external systems, or simply make your daily operations more efficient. (For example, configure SYSLOG server on Unified Access Gateway). This is where REST APIs come into play.

Through the HCS Omnissa REST APIs, administrators and developers can programmatically interact with the platform, retrieve information, trigger actions, and build custom integrations that go beyond the capabilities of the graphical interface. APIs enable consistency, scalability, and repeatability — all essential elements in modern IT environments.

In this post, we will explore how to get started with the HCS Omnissa REST APIs, understand the authentication process, and see practical examples of how they can simplify management and automation.

This is the first post about this topic … here Horizon Cloud Service Next Gen Apis – Chapter 2, the second Chapter where I write about configuring SYSLOG on UAG deployment

Configure an Account for API Token

Before interacting with the HCS Omnissa REST APIs, you need a properly configured account that is authorised to perform API operations. In this section, we will review the prerequisites, required roles and permissions, and how to create or configure a dedicated service account to ensure secure and controlled access to the platform.

Connect to https://connect.omnissa.com and go to View My Profile under the account info.

Select API Tokens TAB and Generate A New API Token

Configure the new token, add Name and Token TTL (I suggest setting an expiration date to increase security)

About the scope of the token use, we need to select the appropriate permissions

Select the OpenID format

We can select if near the token expiration date, the system will send a mail notification.

And now we can select Generate

It will take some seconds and will display the Token ID,

It is important to save the token.

Obtain the Authentication Token

Authentication is a fundamental step when working with REST APIs. HCS Omnissa uses token-based authentication, which means you must first request and obtain a valid access token before performing any API calls. Here, we will walk through the authentication flow, explain the required headers and payload, and demonstrate how to retrieve and securely store the token for subsequent requests.

We can use, for example, Postman or PowerShell.

In the first step, I suggest using postman for handle the command, so we start Postman (Desktop or Web).

POST https://connect.omnissa.com/csp/gateway/am/api/auth/api-tokens/authorize

In the command output, we can see the access_token to use for sending other commands.

Test the APIs with Postman

Before moving to automation, it is always a good practice to validate API calls using a tool like Postman. In this section, we will configure a collection, set up authentication headers, and test sample API requests. This approach helps you understand request structure, responses, and potential error handling in a simple and interactive way.

In the next step, I use the RESTapi to list the Pools (in my environment are HCS on vSphere Pools):

GET https://cloud-sg.horizon.omnissa.com/portal/v2/pools

Command output

Automating with PowerShell

Once the API calls have been validated, the next step is automation. In this chapter, we will build a practical PowerShell script to authenticate, retrieve the access token, and execute REST API calls against HCS Omnissa. This will allow you to integrate API operations into your administrative workflows, scheduled tasks, or larger automation frameworks.

PowerShell command for generating an access token

$Header = @{
	    "Content-Type" = "application/x-www-form-urlencoded"
    }
$Body = @{
	    "refresh_token" = "<Token API created from the Connect Omnissa Portal"
    }
$Response = Invoke-RestMethod -Uri  https://connect.omnissa.com/csp/gateway/am/api/auth/api-tokens/authorize -Method Post -Headers $Header -Body $Body
$AccessToken = $Response.access_token

Powershell command to show the Pools

$Header =	@{
			"Content-Type" = "application/json";
			"Authorization" = "Bearer $AccessToken"
	}

Invoke-RestMethod -Uri https://cloud-sg.horizon.omnissa.com/portal/v4/pools -Method Get -Headers $Header

Horizon – Agent Update – Unable to see the last version

January 23, 2026January 23, 2026 fabio1975Agent Update, App Volumes, Dem, Horizon, OMNISSA, update, UpgradeLeave a comment

After updating Horizon to version 2512, I noticed that the latest versions (8.17) weren’t being displayed in the Agent Updates section.

To see the latest versions, I had to disable the Agent Update service on the Omnissa Connect side. Simply go to the Capacity section, select the relevant edge gateway,

and disable the specific option in the Features section.

Re-enable it after a few minutes.

After a few minutes, the latest versions also appeared in the Horizon console.

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

Migrazione delle impostazioni di Horizon Client da VMware a Omnissa con Omnissa DEM

January 21, 2026January 22, 2026 fabio1975Dem, Dynamic Environment Manager, Horizon, OMNISSA, Omnissa Horizon Client, RebrendLeave a comment

Con il rebranding di VMware Horizon Client in Omnissa Horizon Client, uno degli aspetti spesso sottovalutati è la migrazione delle impostazioni utente.

Nel contesto in cui ho dovuto operare la necessità principale era replicare le impostazioni dell’Horizon Client (dalla versione VMware a quella Omnissa) in un contesto di VDI. Le impostazioni fondamentale da copiare erano quelle del “Drive & Folder Sharing”

In ambienti enterprise – specialmente VDI non persistenti gestiti con Omnissa Dynamic Environment Manager (DEM) – è fondamentale garantire che:

• le impostazioni dell’utente vengano mantenute

• la migrazione avvenga una sola volta

• non ci siano impatti sui logon successivi

In questo articolo vediamo come migrare automaticamente le impostazioni del client Horizon:

• da:

%AppData%\VMware\VMware Horizon View Client

• a:

%AppData%\Omnissa\Omnissa Horizon Client

utilizzando uno script PowerShell integrato correttamente in Omnissa DEM.

Prerequisiti

Configurazione di DEM per esportare le personalizzazioni di:

VMware Horizon Client
Omnissa Horizon Client
Chiave di registro di controllo

Precisamente:

Approccio

La soluzione si basa su tre concetti chiave:

1.Script PowerShell in contesto utente

2.Logon Task in Flex Configuration (DEM)

3.Condition basata su chiave di registro HKCU per garantire l’esecuzione una sola volta

La chiave di registro viene salvata nel profilo utente e gestita da DEM, rendendo la soluzione compatibile con:

• VDI floating

• desktop non persistenti

• profili DEM

Script PowerShell

Lo script seguente:

• verifica se la migrazione è già avvenuta

• copia le impostazioni se presenti

•scrive una chiave di registro per bloccare le esecuzioni successive

# ==============================
# 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

Lo script lo posizioniamo nella share Config di DEM creando una cartella chiamandola script. Nel mio caso

C:\DEMConfig\Script

Configurazione in Omnissa DEM

Lo script deve essere configurato come Logon Task per cui dalla console di DEM:

• User Environment→ Logon Tasks

• Name:

Migrate Horizon Client Settings (VMware → Omnissa)

• Command:

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

Condition (fondamentale)

• Hive: HKEY_CURRENT_USER

• Key: Software\Omnissa\Migrations

• Value: HorizonClientSettingsMigrated

non è uguale a 1

Qui il video dove replico tutti i passaggi e provo il tutto:

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.

Replacing the Public Certificate on Your Omnissa Unified Access Gateways

October 24, 2025 fabio1975Certificates, Horizon, Public Certificate, UAG, Unified Access GatewayLeave a comment

So, you’ve got your shiny new public SSL certificate, and it’s time to make your Unified Access Gateways (UAGs) happy. Excellent choice — a properly installed certificate keeps your users safe, your browser warnings quiet, and your security team smiling.

In this post, I’ll walk you through how to replace or install a new public certificate on your Omnissa Unified Access Gateways.
We’ll use a PFX (PKCS#12) certificate file, since it neatly bundles the private key, certificate, and intermediates in one convenient package.

My Preferred Setup

I like to keep things clean and consistent, so instead of juggling multiple certificates, I use a single public certificate for all Unified Access Gateways in my deployment.

Here’s the trick:
When generating or requesting your certificate, make sure the Subject Alternative Name (SAN) section includes:

• The VIP used to access the UAGs through the load balancer (Normally, a public FQDN)

If you use the UAGs for internal access (for network segmentation), I suggest adding to SAN the internal UAG FQDN.

🔧 Step-by-Step: Installing the Certificate

(Insert screenshots of each step here)

1.Log in to the UAG admin console
Open your browser and connect to the UAG admin interface:

2.https://<UAG-FQDN>:9443/admin

3.Go to the TLS/SSL Settings
From the left menu, navigate to:
System Configuration → TLS Server Certificate Settings

4. Prepare your PFX file
You should already have your .pfx file ready, containing:

◦ Your public certificate

◦ Any intermediate certificates

◦ Your private key

You’ll also need the PFX password you set when exporting the file.

5 .Import the new certificate
In the TLS configuration page, click Select PFX, browse to your certificate file, and enter the password.
Then hit Save at the bottom of the page.

6. Wait for the magic
The Unified Access Gateway will automatically restart the Edge service to apply the new certificate.
Grab a coffee ☕ — it only takes a few seconds.

7 .Verify everything works
Once the UAG is back online, open the VIP URL in your browser or Horizon Client and check the certificate details.
Browser

Horizon Client

Bonus Tips

• Consistency is key: Replace the certificate across all your UAGs (behind the same Public FQDN).

• Backup the old cert: Always keep a copy of the previous working certificate — just in case something goes sideways.

• Keep a note of the certificate expiration date and plan your next renewal ahead of time (trust me, future-you will thank you).

IMPORTANT: Once you’ve changed the certificate, always verify that it works. Especially if you have thin clients, make sure they have loaded the necessary certificates (RootCA and SubCA) to validate the new certificate.

. That’s It!

You’ve successfully installed a new public certificate on your Omnissa Unified Access Gateways.
Your users now enjoy secure, trusted access — and you get the satisfaction of another clean green padlock in the browser.

BIOLNX

vmvirtual.blog

Menu