I have encountered an anomaly from a customer regarding the icons displayed for applications published by an RDS farm via Horizon. Specifically SAP LOGON.
The situation was as follows:
Where the SAP LOGON icon was grayed out and not well defined, the same situation was present with access via WEB.
After various analyses and attempts to solve it, I identified in the Horizon ADAM LDAP DB the presence of a mapping between the published application and the icons used
To access the ADAM LDAP DB, follow the instructions in this KB
Once connected to the DB, we will be able to find our published application under Applications and check the associated icon or icons in the properties.
In my case, the pae-IconDN field was populated by 10 entries. In the image below, I show the status of the field
By removing the first 8 Entries (by trial and error), I was able to restore the correct situation
Some points of attention:
The icons in question (for example, the 10 of SAP LOGON) are all downloaded to the Horizon client cache located in C:\Users\%USERNAME%\AppData\Local\Omnissa\Omnissa Horizon Client\Icon Cache, but there is no link between the file name with the icon image and the ADAM LDAP DB (at least, I didn’t find it)
If we publish another SAP GUI or remove and republish the current one, the problem may recur, and it is necessary to intervene in the same way
Following a migration of published applications from the Citrix platform to the Omnissa environment, the customer realized that the sessions to the unused applications (IDLE) were never closed. The application is still open (but the application is not used) and the session on the RDSHost server remained active.
In order to meet the customer’s needs, it is necessary to operate on Active Directory GPOs and on RDS Farm configurations created on Horizon.
GPO Active Directory
There is a setting to configure to enable the Session Time Limits.
There is a special parameter to set form disconnect RDS Empty Session on the RDS Farm Configuration
The user experience is as follows:
The user starts an application published by horizon (e.g. the SAP GUI) and works on it.
The session is left in IDLE (because the user went to home after work, and locked the PC) and from RDSHost side I can see that the session goes into IDLE:
When the time set in the GPO expires, the user will receive the following message
If the user does not do anything within 2 minutes, the session is marked as disconnected and the application (user side) is closed. RDSHost session state change from Active to Disconnect.
The Disconnected state is what allows Horizon to trigger.
Once the time set on the Horizon side FARM has expired, in the Empty Session timeout parameter, the session is removed.
When we upgrade the Horizon Connection Servers or install Windows Patches on Guest OS where we have the Connection Server role, there is information that we can “save live”
This information is about the location of FSMO roles.
Normally the FSMO roles are located in the last installed Connection Server with a replica function.
We can check this location with some simple steps, I can try to explain:
Create an RDP session with a Connection Server Guest OS
Start a Command Prompt
Run the LDP command
We connect to LDAP
We Bind as a currently logged user
Insert the BASE DN to show the tree(CN=Schema,CN=Configuration,CN{ID})
Now on the right form of LDP we can see the connection server hostname owner FSMO role.
In this case, the FSMO is located on the CS2209B connection server.
The FSMO role is possible to move to another Connection Server with this simple command:
vdmadmin -X -seizeSchemaMaster
To launch the previous command from the Connection Server we want to take the FSMO role
Omnissa engineers worked very hard at last end of 2024 year-end in 2025 start year to rebrand the application (Connection Server, Dynamic Environment Manager, App Volumes … ) to remove all VMware logo and info (It is necessary to Broadcom request for Copyright. .)
Now we have the first effect with the new look and design for App Volumes Manager (Version 2412) and
Horizon Edge Gateway Appliance is required to entitle your environment to Horizon subscription licenses, services and management features hosted in the Horizon Control Plane Services. To enable subscription license entitlement, Horizon Edge Gateway Appliance must be deployed in each Horizon Pod.
The Horizon Edge Gateway Appliance is deployed as a virtual appliance from vSphere® Web Client and paired to one of the Connection Servers in the pod. As part of the pairing process, the Horizon Edge Gateway Appliance virtual appliance connects the Connection Server to the Horizon Cloud Service to manage the subscription license. With a subscription license for Horizon, you do not need to retrieve or manually enter a license key for Horizon product activation.
One of the first checks to do before deploying the Horizon Edge Gateway Appliance is to verify the correct communication with the Omnissa cloud services to which it must connect.
To perform this operation there is a specific tool that “Horizon Cloud Service – next-gen Edge Subnet URL Checker tool”, it can also be used to perform post-installation checks when there are communication problems like this:
The Horizon Edge Gateway allows Omnissa Horizon 8 environments to connect to the Omnissa Horizon® Cloud Service™. Deploying a Horizon Edge Gateway Appliance for Horizon 8 deployments on vSphere is accomplished by accessing the Horizon Universal Console, which is the administrative interface for the Horizon Cloud Service.
Horizon Edge Gateway Appliance is required to entitle your environment to Horizon subscription licenses, services, and management features hosted in the Horizon Control Plane Services. To enable subscription license entitlement, Horizon Edge Gateway Appliance must be deployed in each Horizon Pod.
How any virtual appliance it is necessary to upgrade to a new version.
In my situation, I had a customer with an old version of Horizon Edge Gateway (2.3.4.1) and on the Horizon Cloud portal we saw info that said a new version of Edge
The procedure to upgrade is very simple and is like to the procedure for the first install
After click to view
We are redirected to the maintenance tab where it is displayed some information.
After selecting “Upgrade” we can start with the activity.
First, we need to download the last Horizon Edge Gateway Appliance.
We had collected the information of actual Edge deploy like
Network Configuration (such as IP Address, Gateway, NetMask and PortGroup)
Now we are ready to log in to Virtual Center where we want to deploy the Appliance with insert some information, including the fundamental paring code that we can find on this screen:
Shut down the old Edge Gateway.
Deploy the OVA appliance:
We need to insert the standard information for ova deploy and insert the paring code and the network information
After deploying, on the Horizon Cloud portal under Resources and Capacity, we found that the Horizon Edge is Disconnected.
Now it is only a question of time…. or we can force with re-validate the info by clicking on edit configuration.
The last step is to insert the information to connect the Horizon Edge to the Connection Server (on-prem deployment)
Enter on the actual Horizon Edge
We need to edit the Horizon Connection Server information because it is necessary to validate the trust with the Connection Server SSL certificate and insert the password for the service User.
If you have a Horizon Enterprise Plus or Horizon Universal subscription license, the last Horizon versions have a function to manage the Horizon Agent Update.
You have two scenarios:
Automatic map the upgrade to your Connection server infrastructure
Manually add the Agent upgrade package
I tested this feature in my Home Lab
Enable Automatic upgrade to your Connection server infrastructure
Enable Omnissa Horizon Cloud Portal form of Horizon Agent Auto Upgrade feature
With enabling the Agent Auto Upgrade you can see, without any action, the Horizon package to use for upgrade (this new package is directly downloaded from the Omnissa Site)
If you use this method you can skip the next paragraph and go to Schedule Agent upgrade
Manually loaded the JSON and agent file
Otherwise, you can manually download the JSON file from the customer portal by Omnissa
Omnissa Horizon Standard and Enterprise Plus Subscriptions
Download the files you need
Upload them to a WEB site (Local/Internal or Public), in my case I use an Azure storage account
As blob containers
Which are accessible via WEB (obviously I recommend putting special restrictions)
Let’s configure our POD by entering the appropriate section of the interface via WEB of the connection servers
Enter the URL of our storage account with the name of the JSON file indicated
In the various activities carried out in the year that is ending, load balancing and the other availability of Horizon solutions for both access from the Internet and from the company LAN were among the activities that required multi-handed work between the teams that deal with IT technologies within the company (Security, Network, EUC, Servers …).
While these synergies are easy to manage in the context of small companies, when working with large companies, timely planning and design become very important to avoid infrastructural changes (even minimal) that can convert into delays in the delivery of the infrastructure due to the need to re-engage a different team.
One of solutions used to balance access to Omnissa Horizon services is NSX Advanced Load Balancer.
Normally, the publication of Omnissa VDI solutions is carried out using the virtual appliances Unified Access Gateway (UAG) where “Omnissa Unified Access Gateway enables secure remote access from an external network to a variety of internal resources provided by Omnissa Workspace ONE and Horizon deployments.”
Natively UAGs have their own HA solution, but it has the requirement of having 3 Public IP Addresses and creating three public FQDNs.
The use of NSX Advanced Load balancer allows various UAG balancing solutions:
Single VIP with Two Virtual Services
Single L4 Virtual Service
(n+1) VIP
In my HomeLab I have tested the various solutions indicated above,
the most interesting is the one that I propose you try for the following reasons:
• Robust enough to handle the persistence issues
• Works well in environments where users come behind the NAT
• Ease of configuration
• Better visibility and logs
Additionally, the standard ports of the Blast and PCo protocols will not be used, as this can easily expose the solutions to potentially malicious individuals.
The infrastructure that I will propose also requires a change to the “classic” UAG configurations on the URLs used for the Blast and PCOIP protocols.
In the implementation that we will do, we will take as an example only the part of the Blast protocol
The following flow explains the step when a user tries to access Omnissa VDI, the flow has two ports opened for primary and secondary traffic:
Port 443 – This is for XML API traffic
Ports 5001 to 5002 – Horizon internal ports opened for L7 primary XML traffic to handle redirected traffic
Ports 30001 to 30002 – Blast
Where:
Client L7 request comes to AVI LB https://horizon.pollaio.site/
AVI LB chooses 1 pool member (say UAG1) and send back to client a 307 redirect Location https://horizon.pollaio.site:5001
Client sends request on redirected port https:// horizon.pollaio.site:5001
AVI LB (L7) sends requests to UAG1 https:// horizon.pollaio.site:5001 (Port Traslation)*
UAG1 responds back with XML payload
AVI LB parses the XML response and replace the L4 ports (to client) https:// horizon.pollaio.site:30001 (blast)
Client sends L4 request for Blast to AVI LB
AVI LB sends request to UAG https:// horizon.pollaio.site:30001*
UAG1 responds back to AVI LB
AVI LB responds back to client
The main aspect is the correct configuration of TCP and UDP ports between the various corporate network segments:
Source
Destination
Protocol
Port
Unified Access Gateway
Horizon Agent
UDP
22443
Unified Access Gateway
Horizon Agent
TCP
22443
Unified Access Gateway
Horizon Connection Server
TCP
443
Horizon Client
Virtual Service AVI
TCP
443
Horizon Client
Virtual Service AVI
UDP
443
Horizon Client
Virtual Service AVI
TCP
5001
Horizon Client
Virtual Service AVI
UDP
5001
Horizon Client
Virtual Service AVI
TCP
5002
Horizon Client
Virtual Service AVI
UDP
5002
Horizon Client
Virtual Service AVI
TCP
30001
Horizon Client
Virtual Service AVI
UDP
30001
Horizon Client
Virtual Service AVI
TCP
30002
Horizon Client
Virtual Service AVI
UDP
30002
Configurazione NSX ALB
Create a Virtual IP
Create a Custom Health Monitor for UAG
Create a UAG Pool
Install the SSL certificate Required for L7 VIP
Create a Virtual Service for UAG
Binding DataScripts to the Virtual Service
Create a Virtual IP
To create a custom health monitor, navigate to Applications > VS VIPs.
Click Create.
Create a Custome Health Monitor
To create a custom health monitor, navigate to Templates > Profiles > Health Monitors.
Click Create.
Select the VMware Cloud that was created for Horizon.
Enter the following details in the New Health Monitor screen
Create UAG Pool
Navigate to Applications > Pools.
Select the cloud from the SelectCloud window.
Click Next.
Click Create Pool.
In the CREATE POOL screen, update the details as shown below:
In the Servers tab, add the Server IP Address of the UAG servers.
In Health Monitor tab, select the appropriate Health profile as shown below:
Installing the SSL certificate Required for L7 VIP
The public certificate must be imported into AVI LB it need the same imported in to UAG.
The certificate to be imported must be in PEM format.
Once imported, ensure that the CA certificate is properly linked.
Here are the steps to import the certificate
To import a CA Certificate, navigate to Templates > Security > SSL/TLS Certificates.
Click Create.
Select Root/Intermediate CA Certificate.
Provide a name to identify the certificate later
Upload or Paste Certificate File
VALIDATE and SAVE
Creating Virtual Service for UAG
To create the new virtual service,
Navigate to Applications > Virtual Services.
Click CREATE VIRTUAL SERVICE > Advanced Setup.
Bind the virtual service VIP.
Use the System-HTTP-Horizon-UAG as the Application Profile.
Configure the virtual service as shown below:
In the Service Port section, click Switch to Advanced and configure the service ports.
Bind the pool and the SSL certificate added,
Click Next.
Click Next and Save the configuration.
NOTE:
Two ports are opened for primary and secondary traffic:
Port 443 – This is for XML API traffic
Ports 5001 to 5002 – Horizon internal ports opened for L7 primary XML traffic to handle redirected traffic
Ports 30001 to 30002 – Blast
Configure DataScript
Binding the Horizon DataScript on the Virtual Service
From the UI, navigate to Applications > Virtual Services.
Edit the virtual service that was created.
Go to Policies > DataScripts.
Click Add DataScripts.
Under Script To Execute, select System-Standard-Horizon-UAG.
Click Save DataScript and click Save.
System-Standard-Horizon-UAG is embedded AVI Load Balancer Datascript
UAG Configuration
Modify each UAG’s Blast and PCoIP external URL fields to use the custom ports added in the NSX Advanced Load Balancer port map (From the UI, Edit Pool > Servers tab under New Pool or Edit Pool page).
Modify the Blast external URL to include the custom port for UDP.
For example, https://<ENAV_PUBLIC_FQDN>.com:<BLAST-CUSTOM-PORT>/?UDPPort=<BLAST-CUSTOM-PORT>.
