Migrate VMware Horizon Client settings to Omnissa Horizon Client with DEM

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

.

Migrate VMware Horizon Client settings to Omnissa Horizon Client with DEM

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

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:

.

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

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

.

A red lock on a blue background

AI-generated content may be incorrect.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)

.

A screenshot of a computer

AI-generated content may be incorrect.

.

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.

A diagram of a network

AI-generated content may be incorrect.

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.

.

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

Replacing the Public Certificate on Your Omnissa Unified Access Gateways

.

Close-up of a screen with a lock and text

AI-generated content may be incorrect.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

A screenshot of a login form

AI-generated content may be incorrect.

Sign in with your admin credentials.

A screen shot of a computer

AI-generated content may be incorrect.

3.Go to the TLS/SSL Settings
From the left menu, navigate to:

System Configuration → TLS Server Certificate Settings

A screenshot of a computer

AI-generated content may be incorrect.

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.

A screenshot of a computer

AI-generated content may be incorrect.

A green rectangle with black text

AI-generated content may be incorrect.

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

A screenshot of a computer

AI-generated content may be incorrect.

Horizon Client

A screenshot of a login screen

AI-generated content may be incorrect.

.

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.

.

Replacing the Public Certificate on Your Omnissa Unified Access Gateways

Replacing the Self-Signed Certificate on Omnissa Connection Server with a Microsoft CA-Issued Certificate (or replacing the certificate to end to validation date)

.

Let’s be honest — that shiny self-signed certificate your Omnissa Connection Server came with is fine… until your browser or Horizon client starts screaming “Untrusted!” at every login. 😅

A screenshot of a computer error AI-generated content may be incorrect.


It’s time to fix that properly — by replacing it with a trusted certificate issued by your internal Microsoft CA.

In this guide, we’ll walk through the process step-by-step, ending up with a PFX certificate you can deploy to all your Connection Servers.

.

Why One Certificate for All Connection Servers?

Because simplicity is beautiful.
Maintaining a single certificate across all your Connection Servers reduces management overhead and avoids those awkward “name mismatch” warnings.

In the certificate, we’ll include all relevant hostnames as Subject Alternative Names (SANs):

• The hostname and FQDN of each Connection Server
• The VIP name (if you’re using a load balancer for internal access)

Example SAN list (2 Connection Servers and 1 VIP):

connection01.company.local

connection02.company.local

horizon-vip.company.local

connection01

connection02

horizon-vip

.

.

Step 1: Require the certificate as a PFX File

1. The certificate will be exported into a PFX file with:
◦ Exporting the private key
◦ Protect it with a strong password
◦ Save it somewhere safe (seriously, treat it like a password)

.

Step 2: Deploy the Certificate on All Connection Servers

Now that you have your shiny, trusted .pfx file, it’s time to put it to work.

Repeat the following steps on each Connection Server:

1.Open MMC → Certificates (Local Computer) again.

A screenshot of a computer AI-generated content may be incorrect.

A screenshot of a computer program AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

In Personal, there is a self-signed certificate (or an old certificate) installed by the Connection Server installation process

A screenshot of a computer AI-generated content may be incorrect.

2. Import the .pfx file under:

Personal > CertificatesA screenshot of a computer AI-generated content may be incorrect.

.

A screenshot of a certificate AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

3. When prompted, provide the password you used during export and select “Mark this key as exportable….”

A screenshot of a computer screen AI-generated content may be incorrect.

A screenshot of a certificate AI-generated content may be incorrect.

4. Verify that the certificate appears in the list with the private key (the certificate icon has a key)

A screenshot of a computer AI-generated content may be incorrect.

5. Remove the friendly name VDM from the self-signed certificate or the old certificate

A screenshot of a computer AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

6.Add friendly name VDM to new certificate

A screenshot of a computer AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

A red lines with black text AI-generated content may be incorrect.

.

.

Step 3: Restart the Horizon Connection Server Service

To make the change effective:

1. Open Services.msc
2 . Restart the VMware Horizon Connection Server service.
3 . Alternatively, you can simply reboot the server if you’re feeling extra cautious.

A screenshot of a computer screen AI-generated content may be incorrect.

Once restarted, the Connection Server should automatically pick up the new certificate.

You can confirm by opening the Horizon Administrator Console in your browser and checking that your connection is now secure and trusted ✅

We need to repeat steps 4 and 5 on all Omnissa Connection servers

.

Bonus: Keeping Things Clean

• Make sure all old or expired certificates are removed from the Personal store.
• Keep a note of the certificate expiration date and plan your next renewal ahead of time (trust me, future-you will thank you).
• If the Horizon is behind the Unified Access Gateway (for external connection and network segmentation, remember to change the Thumbprint on the UAG configuration)
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.

.

Done!

You’ve successfully banished the self-signed gremlin and brought your Horizon environment into the trusted world of PKI.

From now on, your users will enjoy clean, warning-free connections — and your security team will silently thank you for doing things the right way.

.

Replacing the Self-Signed Certificate on Omnissa Connection Server with a Microsoft CA-Issued Certificate (or replacing the certificate to end to validation date)

Using Windows Server 2025 in a Horizon Brownfield Setup (Yes, You Can)

.

Attention, I am experiencing some anomalies after activating the hybrid environment… I advise you to wait for news before proceeding.

LDAP replication fix: The April 8, 2025 update (KB5055523) introduced an LDAP replication issue when Windows Server 2025 is mixed with older Windows versions. The November 11, 2025 patch (kb5068861) resolves this issue

Hey, good news!

As of early August 2025, Horizon now supports Windows Server 2025 in brownfield environments. If you’re already running Horizon and thinking about tossing in a Server 2025 box, here’s the breakdown: what you need, what to tweak, and some handy commands to make it happen.

All information is taken from the official Omnissa KB (Windows 2025 support for Horizon brownfield installations (6000960) )

A jump into the past

Before… when trying to install the Connection Server Replica role on Windows Server 2025 and trying to insert it into a pod containing Windows Server 2016, 2019, and 2022, you would get this error:

A screenshot of a computer error AI-generated content may be incorrect.

.

Requirements

• Horizon version: Must be Horizon 8 v2503 or later. This is what enables full support for Windows Server 2025 in brownfield setups
• Windows Server Update

Ensure all Connection Server machines within the pod are updated with the Microsoft Windows 2025 February update or later release (for more details, check the official Omnissa KB)

All Windows 2025 machines hosting the Connection Server must have the Microsoft November 11, 2025 patch (or later) installed. This is required for:

  1. AD LDS functional level update: Without the required patch, updating the AD LDS functional level will cause the AD LDS instance to fail. Refer to Microsoft’s documentation: AD LDS service startup fails if updated without required patches.
  2. LDAP replication fix: The April 8, 2025 update (KB5055523) introduced an LDAP replication issue when Windows Server 2025 is mixed with older Windows versions. The November 11, 2025 patch (kb5068861) resolves this issue
• AD LDS Functional Level: This is the kicker:
◦ Windows Server 2025 uses AD LDS functional level 7 by default
◦ Older WS versions (2016–2022) often default their AD LDS to level 2, which is incompatible with WS 2025 replicas

Fresh installs on WS 2025 with Horizon v2503 will default to FL-7 for AD LDS. But if you’re joining WS 2025 to older Horizon Connection Servers that haven’t had their FL bumped, you’ll hit a replica error (“minimum level required by this version… is 7”)

Omnissa has released a script to upgrade FL to version 7 (Supported from Windows Server 2016 onwards)

.

.

Step-by-Step: What to Do

1. Verify you’re on Horizon 8 v2503+:
◦ Go to your Connection Server > About > Confirm version.
2. Check the current AD LDS functional level and Windows Server patch
◦ Download the PowerShell script (UpdateFunctionalLevel-v1.ps1) attached to the Omnissa KB and run it on all Connection Servers
◦ The script can be checked:
1. Windows Operating System and Patch Level of the Connection Server machines
2 . Current Functional Level of local and Global AD LDS
3. Upgrade the FL to 7 (Remember to create a VM snapshot and do a backup….)
◦ The same Omnissa script can upgrade the FL from 2 to 7:
1. Update the Functional Level of the current Pod
2 .Update the Functional Level of CPA
A screen shot of a computer AI-generated content may be incorrect.

.

All check and upgrade steps in my YouTube video:

https://www.youtube.com/watch?v=aR2qvvlY9gc

.

.

.

What You’re Looking At

Component

Requirement

Horizon version

v2503 or later

AD LDS Functional Level

Must be 7 (WS 2025 default), not 2

Action Required

Check and update FL before pod join

.

A Quick Tech Tip

“Horizon 2503 or later will set functional level to 7 for fresh install of the connection server on Windows 2025 and to 2 for anything before Windows 2025.”
— Omnissa internal forum 

So yeah—if you’ve done a fresh install on WS 2025 after Horizon 2503, you’re golden. But mixing in older AD LDS configs? That’s when things break… but this post is the answer.

.

Using Windows Server 2025 in a Horizon Brownfield Setup (Yes, You Can)

Logs Don’t Lie: Why You Need Syslog Enabled on Omnissa Access SaaS

A diagram of a server AI-generated content may be incorrect.

If you’re running Omnissa Access SaaS and you haven’t enabled syslog yet, here’s your gentle-but-firm nudge: do it now. No, seriously. Your SIEM is hungry, and syslog is the buffet.

Let’s dig into why syslog matters, and how you can set it up in less time than it takes to reboot a stubborn printer.

.

Why Should I Enable Syslog?

You might think, “Access logs are already there in the console. Isn’t that enough?”
Short answer:
Nope.

Longer answer:

• Centralized Security Monitoring: Syslog lets you push logs to a SIEM (like Splunk or SYSLOG, I suppose that Omnissa increases the supported SIEM), helping you detect anomalies like brute force attacks, unusual login patterns, or rogue authentication attempts.
• Compliance & Auditing: GDPR, ISO 27001, HIPAA — they all love detailed, timestamped logs.
• Operational Insight: Know exactly who did what, where, and when — across all your users and apps.
• Forensics & Troubleshooting: Ever tried to investigate a login issue without logs? Exactly.

.

What Events Can I Capture?

Omnissa Access can emit audit events, system events, user authentication, and admin actions. Think:

• User logins (successful & failed)
• Policy evaluations
• App launches
• Admin config changes (Policies, Rule etc.)

All this, neatly packaged as syslog messages you can parse, alert on, or just hoard like a proper security engineer.

.

How to Enable Syslog in Omnissa Access SaaS

Requirement

–TLS connection
–Expose to internet our syslog or SIEM. (For now it is only possible configuration, OK this are a point of attention for the Security… but you can manage with firewall rule and other configuration to increase the security)

Setting up syslog in Omnissa Access SaaS is surprisingly painless.

1.Login to the Omnissa Access SaaS Admin Console
Navigate to the
Integrations section in the Omnissa Access SaaS Admin UI.
2.Go to SIEM
You’ll find the syslog settings under
SIEM

A screenshot of a computer AI-generated content may be incorrect.

3.Enable Syslog Forwarding
Toggle it
on, and enter your syslog destination (IP or FQDN), port, and protocol (TCP or UDP).

A screenshot of a computer AI-generated content may be incorrect.

Where

◦ Appname

A tag appends to the syslog raw

◦ Chose Facility
◦ Choose the Severity
Select which log levels
◦ Hostname
Currently the syslog server needs to be published on the internet (this might cause some headaches) in order for the Access SaaS solution to be able to send logs.
◦ TCP Port
◦ Client Certificate
◦ Client Private Key
◦ Syslog Certificate
4.Save & Monitor
Save your settings and check your syslog server for incoming logs. A quick
tcpdump or tail on your syslog endpoint can help confirm delivery.

.

Bonus Tip: Test It!

Try logging in as a test user, change a policy, or simulate a failed login — and watch the logs roll in. If your SIEM lights up, congrats — you’ve just levelled up your visibility game.

My syslog, in this case for the test, is a normal RSYSLOG installed on UBUNTU OS.

I can see a lot of information:

A screen shot of a computer screen AI-generated content may be incorrect.

Where can we see this action:

–LOGIN (Failed or Successful) -> Administrator account or user account and the type of login (MFA/Local Password …)
–LAUNCH -> Application launched and the name of the application/VDI.
–LOGOFF

And many other information like configuration changes, deleted or viewed objects (such as policies).

.

Pro Tips

• TCP with TLS over UDP for reliable, encrypted delivery. (it is a requirement)
• Use log tagging or filtering on the SIEM side to categorise Omnissa logs separately.
• Integrate with alerting tools like PagerDuty or Slack for real-time reactions.

.

🏁 Final Thoughts

Syslog isn’t just for compliance checkboxes — it’s your window into what’s happening inside Omnissa Access. Whether you’re defending against intrusions or just troubleshooting a login issue on a Friday at 5 PM, you’ll thank yourself for turning it on.

So go ahead — feed your SIEM. You know it’s hungry. 🍽️

.

Logs Don’t Lie: Why You Need Syslog Enabled on Omnissa Access SaaS

Securing Horizon Event DB to SQL Server with TLS

.

Because Who Likes Sniffers Anyway?

So you’ve installed Horizon (2503 is last version) and got your Event Database humming along on a shiny SQL Server. But hold on a sec — did you remember to lock down that traffic with TLS encryption? Or are you letting your event logs float around in plain text like it’s still 1999?

Let’s fix that.
Here’s how to set up
SSL/TLS encryption between Horizon and your SQL Server, with a proper certificate from your Microsoft CA, and make sure your event data isn’t the low-hanging fruit on your network.

.

 Why bother?

Because:

• Anyone with Wireshark can eavesdrop on your events and see user logins, VM power actions, etc.
• Your security team will buy you more coffee if you’re nice to them.

.

The Plan

1.Request & issue a certificate from your Microsoft CA infrastructure.
2.Install the certificate on your SQL Server.
3.Configure SQL Server to force encryption using that cert.
4.Enable Horizon to use SSL for SQL connection
5.Test it and sleep better.

.

1. Request a certificate from your Microsoft CA

On your SQL Server, create a certificate request:

Use certreq or just the MMC GUI.
Here’s the quick-and-dirty via MMC:

1.Open mmc.exe ➔ Add the Certificates snap-in for Computer account.
2.Right-click Personal ➔ Certificates ➔ All Tasks ➔ Request New Certificate.
3.Select your Active Directory Enrollment Policy.
4.Choose a template that includes “Server Authentication” EKU (typically Web Server template).
5.Fill in the common name (CN) with your SQL Server’s FQDN (must match exactly what clients connect to).

(Example: sql01.contoso.local)

6.Enable that private Key is exportable
7.Finish and you’re done. Your cert should show up in Personal ➔ Certificates.

.

2. Install, verify and assign right permission to the cert

Technically it’s already installed, but verify:

• It’s under Computer -> Personal ➔ Certificates on your SQL Server .
• It has Server Authentication (1.3.6.1.5.5.7.3.1) EKU.
• The private key is present (little key icon when you look at the cert).

.

Now we need to assign to the user that starts the SQL server service the permissions to read the private key.

A screenshot of a computer AI-generated content may be incorrect.

.

A screenshot of a computer screen AI-generated content may be incorrect.

.

3. Tell SQL Server to use it

Configure SQL Server

1.Open SQL Server Configuration Manager.
2.Go to SQL Server Network Configuration ➔ Protocols for MSSQLSERVER ➔ Properties ➔ Certificate tab.

A screenshot of a computer AI-generated content may be incorrect.

3.Select your cert from the dropdown.

.

A screenshot of a computer AI-generated content may be incorrect.

If it doesn’t show up:

• Check that CN matches the machine’s FQDN.
• Make sure it has Server Authentication EKU.
• Ensure it’s in LocalMachine\My (Personal store).

Force encryption (optional but recommended)

Still in Protocols for MSSQLSERVER ➔ Flags tab ➔ Set Force Encryption = Yes.

A screenshot of a computer AI-generated content may be incorrect.

.

Restart SQL Service

You knew this was coming:

Restart-Service MSSQLSERVER

A screenshot of a computer AI-generated content may be incorrect.

.

Testing time

Use SQL Server Management Studio (SSMS) to connect, then run:

SELECT session_id, encrypt_option

FROM sys.dm_exec_connections

WHERE session_id = @@SPID;

If encrypt_option says TRUE, congrats! 🎉

.

What about Horizon?

Enable SSL with modification in the ADAM DB pae-enableDbSSL and set it to 1

1. Start ADSI Edit

A screenshot of a computer AI-generated content may be incorrect.

2.Connect to the ADAM DB

A screenshot of a computer AI-generated content may be incorrect.

A screenshot of a computer AI-generated content may be incorrect.

Remember that the Distinguished Name is different if you use the OLD ADAM Schema or the new Schema (the DN indicated in the image is the new schema with the rebranding Omnissa)

3.Go to OU=Properties > OU=Global > CN=Common and set the pae-enableDbSSL flag to 1 .

A screenshot of a computer AI-generated content may be incorrect.

4. Restart the omnissa Horizon Connection Server Service

A screenshot of a computer AI-generated content may be incorrect.

.

When you configure your Event Database settings in Horizon Administrator, it’ll negotiate TLS automatically if your SQL Server is set up for it.

Just make sure:

• Horizon connects via the FQDN matching the cert CN.
• The client OS trusts your CA (install the CA root cert if needed).

.

Done! Enjoy encrypted peace of mind.

Now your Horizon events are zipped up nice and secure in transit.
No more plain-text passwords, no more nosey packet sniffers. You
can go brag to your security team and earn those extra donuts.

.

.

Bonus topic!

Now I check the traffic from Horizon Connection Server and SQL Server

With Wireshark, we can check if the traffic is encrypted:

1. Install Wireshark and Npcap on the Windows server of one of your connection servers
2.Enable filter ((ip.src == <IP CS> && ip.dst == <IP SQL SERVER>)) || ((ip.src == <IP SQL SERVER> && ip.dst == <IP CS>))
3. Start the capture
4. Log in to the connection server and create an Event filter
5 . Check

A screenshot of a computer AI-generated content may be incorrect.

.

Whitout encryption

A screenshot of a computer AI-generated content may be incorrect.

With Encrypted

 

A screenshot of a computer AI-generated content may be incorrect.

Securing Horizon Event DB to SQL Server with TLS

Simplifying App Volumes Management with Recovery Admin in Version 2503

Introduction
With the release of App Volumes 2503, Omnissa has introduced a powerful new feature: Recovery Admin. Designed with IT administrators in mind, this addition simplifies troubleshooting and provides a safer, more streamlined way to handle App Volumes environments during critical issues.

What is Recovery Admin?
Recovery Admin is a dedicated role introduced to improve operational resilience. It grants restricted access to App Volumes when standard administrators are locked out—typically in cases where directory services like Active Directory are down or misconfigured.

Think of it as a “break-glass” account: always available, highly secure, and essential when traditional access paths fail.

Key Capabilities

  • Read-Only Access: Recovery Admin can inspect configurations, assignment states, and errors—helpful for diagnostics without risking accidental changes.This account is strictly limited to managing domain configuration and administrator roles and is not associated with any domain.

  • No Directory Dependency: This role doesn’t rely on external identity providers. Credentials are defined during the initial setup, so access is always guaranteed.

  • Audit-Ready: All Recovery Admin activity is logged separately to maintain accountability.

How to Enable Recovery Admin

  1. Log in to the App Volumes Manager UI.

  2. Go to Configuration > Recovery Admin Settings.

  3. Define a strong password and keep it secure.

Once configured, the Recovery Admin account is ready for use when needed—no domain authentication required.

Use Case Scenario
Imagine your domain controller is unreachable and no administrators can log in. With Recovery Admin, you still have access to read logs, inspect app assignments, and validate system health—all without needing to restore full AD services immediately. It’s a crucial safety net.

We can login with Recovery Admin from UI

Add ?recovery_admin=true at the App Volumes Manager URL

and we check if we are in recovery mode with the yellow banner on the top of the UI.

Best Practices

  • Use Recovery Admin strictly for emergencies.

  • Limit access to trusted personnel.

  • Rotate credentials periodically.

  • Monitor audit logs for unusual activity.

Conclusion
Recovery Admin in App Volumes 2503 is a small but significant feature that enhances platform reliability and administrator confidence. Whether you’re running a single site or managing a distributed environment, having a backdoor to recover and investigate without risking configurations is a game-changer.

Image