App Volumes: VHD in-Guest vs Standard Mode

June 9, 2026June 9, 2026 fabio1975App Volumes, Horizon, OMNISSA, RDS, Share, VHD, VHD in-guest, Virtual ApplicationLeave a comment

Technical comparison and recommended use cases

INTRODUCTION

Omnissa App Volumes provides two distinct modes for delivering applications to Horizon users: the standard mode (VMDK/VMFS-based) and VHD in-guest mode, introduced to support non-persistent OS scenarios and advanced Instant Clone environments.

The choice between the two modes directly affects performance, scalability, and infrastructure requirements.

MODE COMPARISON

Standard Mode (VMDK)

• VMDK disk attach via vCenter API

• Mandatory needs a vSphere infrastructure as a prerequisite

• Limited support for multi-hypervisor environments

• Dependency on shared vSphere datastores

• Compatible with all Horizon desktop types

VHD in-Guest

• VHD mounted directly inside the guest OS

• Hypervisor-independent

• Compatible with Azure, AVD and physical environments

• VHD exposed via SMB share or UNC path

• Application packages and writable volumes are stored in a high-performance file share

• Compatible with all Horizon desktop types

TAKE NOTE! We can select the mode (VMDK or VHD) when installing the first App Volumes Manager. We can’t switch from VMDK to VHD mode, or from VHD to VMDK mode, after the first configuration.

VHD IN GUEST ARCHITECTURE

In this mode, the App Volumes Agent inside the guest mounts the VHD file from the configured UNC path using native Windows APIs. The AppStack content is then layered onto the filesystem via the App Volumes kernel filter driver, making applications available without extraction.

.	Note: In VHD in guest mode, the AppStack .vhd file must be reachable via UNC path from the guest. Network latency to the share directly affects mount times.

WHEN TO CHOOSE VHD IN-GUEST

1	Reducing vCenter dependency Environments with restrictive policies on vCenter API access or multi-cloud architectures.

2	Physical desktops or RDSH Scenarios where the workload runs on bare metal or RDS servers without vSphere hypervisor.

3	Azure Virtual Desktop (AVD) environments Non-vSphere infrastructure; inability to attach VMDK via vCenter. .

Microsoft Azure Edge and Omnissa-Managed Enterprise App Registration

May 22, 2026May 22, 2026 fabio1975Azure, Connect Omnissa, Enterprise Application, EntraID, HCS on Azure, Horizon, OMNISSA, securityLeave a comment

My Initial Experience

During the preparation activities for deploying a new Horizon Cloud on Azure environment, I was reading the official documentation at

https://docs.omnissa.com/bundle/UsingManagingHorizonCloud/page/DeployingaMicrosoftAzureEdge.html

and discovered the presence of a new and recommended deployment method: the “Omnissa-managed” mode.

I immediately wanted to test it, but in my Omnissa Connect console, this option wasn’t yet available.

I contacted support and they informed me that the feature would be released soon, but if I wanted to use it immediately, they could enable it through a Feature Flag. Obviously, I couldn’t say no to that opportunity! Once they provided my ORG ID and enabled the flag, the new option appeared while I was creating the EDGE in the Primary Provider section.

This is my journey with the Omnissa-managed method, and I’d like to share what I learned about this game-changing approach.

Introduction

Horizon Cloud on Microsoft Azure is evolving, and Omnissa has introduced a significant security enhancement that every administrator should know about. The new Omnissa-managed Enterprise App registration method represents a paradigm shift in how organizations handle service principal credentials. If you’re planning a Horizon Cloud deployment on Azure, understanding the difference between this new approach and the traditional manual method could be crucial for your security posture.

The Security Challenge

Historically, deploying Horizon Edge in Horizon Cloud on Azure required organizations to create and manage their own Azure Enterprise Applications. This approach meant handling sensitive service principal secrets—credentials that need to be carefully managed, rotated, and protected. The more systems that have access to these secrets, the higher the security risk.

The traditional single-tenant deployment method (Manual Enterprise App registration) placed the responsibility of secret management squarely on the customer organization. While this approach continues to be supported, it introduces additional operational overhead and potential security vulnerabilities.

Enter Omnissa-Managed

Omnissa has introduced a new Enterprise App registration method that fundamentally changes who manages the service principal secrets.

Key Benefits

1. Enhanced Security

Organizations no longer need to provide their sensitive secrets key information to Omnissa or manage it themselves in the context of Horizon Cloud deployment. The credentials remain under Omnissa’s direct management, reducing the attack surface and potential points of compromise.

2. Simplified Administration

Say goodbye to manual Enterprise Application creation and complex permission configurations. With Omnissa-managed registration, the setup process is streamlined. Omnissa handles the heavy lifting—you focus on deployment.

3. Reduced Operational Overhead

No more worrying about secret rotation schedules, credential lifecycle management, or complex authentication flows. Omnissa manages these operational concerns, freeing your team for other critical tasks.

4. Enterprise-Grade Security

By centralizing secret management with Omnissa, organizations benefit from enterprise-grade security practices, regular audits, and dedicated security expertise that Omnissa brings to the table.

Manual Registration: Still Available

For organizations with specific requirements or legacy configurations, the traditional single-tenancy method remains available. This manual Enterprise App registration approach allows organizations to maintain full control over their authentication setup if needed. However, unless you have specific compliance or architectural reasons, the manual approach introduces unnecessary complexity.

The Recommendation

Omnissa-managed is the recommended method for all new Horizon Cloud deployments on Azure. Omnissa has taken the guesswork out of enterprise app management and elevated the security baseline for everyone using Horizon Cloud.

If you’re currently on the manual registration path, consider planning a migration to the Omnissa-managed approach. The transition offers immediate security benefits with reduced administrative overhead.

Getting Started

Ready to leverage Omnissa-managed registration for your deployment? The process is straightforward:

1.Initiate your Horizon Edge deployment in Omnissa Connect

2.Select the Omnissa-managed option during the Primary Provider setup

3.Link your Azure subscription using the consent flow (click Consent Link)

4.Authorize Omnissa to create the Enterprise Application

Insert Azure Subscription credentials (in my case Global Admin User)

Now we can see the new enterprise application with Omnissa Logo.

5.Assign necessary roles (Contributor or appropriate custom roles) to the subscription

First, verify the role assignment status in Omnissa Connect:

Get the Object ID from the Omnissa Enterprise App:

Go to your subscription and select IAM (Identity & Access Management):

Select add role assignment

Search Contributor in Previleged admnistrator Role

Select Member and ad the Enterprise Application Object ID or name

6.Refresh and verify the role assignment in Omnissa Connect

Return to the Omnissa Connect wizard. If the role is still showing as “Role not Assigned”

Go back to the previous step and return to refresh (Omnissa Engineer should add a refresh button)

At this point, you’re ready to choose whether your EDGE will be an AKS (Azure Kubernetes Service) or a Virtual Machine.

The Omnissa-managed Enterprise Application has been successfully created and configured with the naming convention omnissa-horizoncloud-app-1, marked with Omnissa’s branding for easy identification.

Conclusion

The shift to Omnissa-managed Enterprise App registration represents a meaningful step forward in cloud security practices. By removing the burden of service principal secret management from customer organizations, Omnissa enables secure, simplified, and scalable Horizon Cloud deployments on Microsoft Azure.

Whether you’re planning a new deployment or evaluating your current infrastructure, the Omnissa-managed method deserves your attention. It’s security and simplicity working in harmony—exactly what modern cloud deployments should be.

Streamline Your Enterprise with Omnissa Connect and Microsoft Entra ID

May 21, 2026 fabio1975Azure, Azure Active Directory, cloud, EntraID, Federation, Horizon, OMNISSA, Omnissa ConnectLeave a comment

A guide to enterprise federation, single sign-on, and modern identity management

What is Omnissa Connect?

Omnissa Connect is a centralized platform service that provides IT administrators and users with a single sign-on (SSO) gateway to access and manage all Omnissa services, such as Workspace ONE and Horizon. It streamlines workflows by unifying access, identity management, and service onboarding into one intuitive interface.

Key features of Omnissa Connect include:

•Unified Identity: Single sign-on capabilities and seamless integration with third-party identity providers like Microsoft Entra ID and Okta through the Omnissa Identity Service

•Centralized Administration: IT owners can securely assign roles, set multi-factor authentication (MFA) policies, and manage OAuth applications or API tokens across the entire Omnissa ecosystem

•Subscription Management: Visibility into all Omnissa service subscriptions from a single location

What is Microsoft Entra ID?

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s cloud-based identity and access management service. It’s the foundation that millions of organizations use to manage employee identities, secure access to applications, and protect their digital assets.

Entra ID is likely already at the heart of your organization if you use:

•Microsoft 365 (Office 365, Teams, SharePoint)

•Azure cloud services

•Dynamics 365 or other enterprise applications

•Single sign-on (SSO) solutions for SaaS applications

Why Integrate Omnissa Connect with Microsoft Entra ID?

Connecting Omnissa Connect with Microsoft Entra ID through enterprise federation creates a powerful identity ecosystem. Here’s what you gain:

Single Sign-On (SSO)

Your users log in once with their corporate credentials and automatically gain access to Omnissa Connect—no separate usernames or passwords to remember.

Automatic User Provisioning

When you add or remove users in Entra ID, they’re automatically synced to Omnissa Connect. No manual account creation, no forgotten deprovisioning, no stale user accounts cluttering your systems.

Centralized Security

Manage all user access, permissions, and security policies from one central location. Apply multi-factor authentication (MFA), enforce password policies, and monitor access across your entire organization from Entra ID.

Reduced IT Overhead

Your IT team spends less time managing separate identity systems, resetting passwords, and troubleshooting access issues. Everything is automated and synchronized.

Improved Compliance

Maintain detailed audit logs of who accessed what and when. Meet regulatory requirements for access control and identity management with confidence.

A Real-World Example

Before Federation:

Sarah joins your company. The IT team manually creates accounts in Omnissa Connect, Microsoft 365, and four other systems. Sarah has to memorize 5 different passwords. When Sarah leaves three years later, the team forgets to deactivate her Omnissa Connect account, leaving a security gap.

After Federation:

Sarah’s first day: HR adds her to Entra ID. Omnissa Connect automatically creates her account and grants the right permissions. She logs in with her corporate email and password—the same one she uses for everything else. On her last day: HR removes her from Entra ID. Within seconds, Omnissa Connect and all other connected systems automatically deactivate her access. No manual steps. No forgotten accounts. No security gaps.

Is This Right for Your Organization?

Enterprise federation between Omnissa Connect and Entra ID is ideal if your organization:

•Already uses Microsoft Entra ID or Azure Active Directory

•Wants to simplify identity management and reduce IT burden

•Has multiple employees and wants to automate user provisioning

•Needs strong security controls and audit capabilities

•Is undergoing digital transformation and standardizing on cloud-based identity solutions

What’s Involved?

Configuring enterprise federation requires several steps—from verifying your domain to setting up the connection between systems to testing everything works smoothly. The process typically involves:

•Domain verification to prove your organization owns the domain

•Creating and configuring an Enterprise Application in Microsoft Entra ID

•Setting up authentication protocols and user attribute mapping

•Testing the setup before activating federation for all users

•Notifying users and helping them transition to the new authentication method

The Complete Step-by-Step Guide

While this overview covers the benefits and concepts, implementing enterprise federation involves detailed technical configuration. The complete guide is a comprehensive document with in-depth instructions, detailed screenshots, and step-by-step walkthroughs for both Omnissa Connect and Microsoft Entra ID configuration. Due to its length and technical depth, I share it directly with clients and organizations ready to implement the solution.

The complete guide includes:

•Detailed screenshots and instructions for each configuration step

•Exact fields to fill in on both Omnissa Connect and Entra ID

Ready to streamline your organization’s identity management?

If your organization is ready to implement enterprise federation between Omnissa Connect and Microsoft Entra ID, I’m here to help. Whether you need guidance on setup, troubleshooting during configuration, or best practices for managing the transition, I can provide a complete, step-by-step implementation guide tailored to your needs.

Get in touch to request the full technical guide and start your journey toward simplified, centralized identity management.

📧 Contact me for the complete implementation guide

Let’s simplify your organization’s identity and access management together.

Horizon 2603 is here!

April 16, 2026April 16, 2026 fabio19752603, ESXi, Horizon, OMNISSA, SQL Integrated Authentication, vCenter, vpshere, vSphereLeave a comment

A new version of Omnissa Horizon has just been released, and 2603 is not just another update — it’s an ESB (Extended Service Branch) release and marks an important transition point for many environments.

🔗 Release Notes:
https://docs.omnissa.com/bundle/horizon8-rnV2603/page/Horizon8-ReleaseNotes.html

First things first: end of support for vSphere 7

Let’s start with something critical:

Horizon 2603 ESB no longer supports vSphere 7.x

Horizon 2512 was the last release supporting vSphere 7
Starting from 2603, vSphere 8 is the required platform

This means one thing:
If you’re planning to move to this ESB, your vSphere upgrade is no longer optional — it’s mandatory

This is a key architectural checkpoint, especially for environments that have been delaying the jump to vSphere 8. (vSphere 7 is end of support)

Event Database + Integrated Authentication (finally!)

Now, let’s talk about one of my favorite new features.

Horizon 2603 introduces the ability to configure the Event Database on Microsoft SQL Server using Active Directory identities (Domain User with Integrated Authentication).

No more SQL authentication.

Why this matters:

Eliminates stored SQL credentials
Aligns with enterprise security best practices
Simplifies credential lifecycle management
Improves compliance and auditability

From a design perspective, this is a very welcome step toward a more secure-by-default architecture.

Final thoughts

This release is not just about new features — it’s about setting a new baseline:

✔️ ESB = long-term stability
✔️ vSphere 8 as the standard
✔️ Stronger security integration

If you were waiting for the “right moment” to modernize your Horizon platform… this is probably it.

In the next posts, I’ll dive deeper into the other new features and changes introduced in Horizon 2603 — stay tuned 👀

Need help testing or upgrading?

If you’re planning to:

Test Horizon 2603
Upgrade your existing environment
Move from vSphere 7 to vSphere 8 or 9

Feel free to reach out — happy to help with assessments, design, and upgrade strategies.

Have you already started testing Horizon 2603?
Or are you still planning your vSphere 8 migration?

Let’s discuss

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