Omnissa Horizon Desktop Pool without vCenter

2024年5月5日 LOG admin

原文：Omnissa Horizon Desktop Pool without vCenter — theDXT (Daniel Keer)

You usually want to connect Omnissa Horizon (formerly VMware Horizon) directly to VMware vCenter, but it can make sense to leave them disconnected from each other in some situations.

In this post, I’ll show you step-by-step how to install the VMware Horizon Agent without using the VMware vCenter integration. You can do this on persistent VDIs and Physical Machines.

Why Run Horizon Without vCenter Integration?

Most Horizon documentation assumes that Horizon and vCenter are joined at the hip. In a standard VMware environment that assumption holds: the Connection Server authenticates to vCenter, uses it to provision instant clones and full clones, powers machines on and off, takes snapshots, and pushes new images during a recompose. If you take vCenter away, a large part of the automation disappears.

What does not disappear is the part that actually delivers the desktop to the user. The Horizon Agent inside the guest operating system registers itself with the Connection Server over the network; the Connection Server then brokers a session and hands the client a Blast Extreme or PCoIP connection straight to the guest. That agent-to-broker relationship does not require vCenter at all — which is exactly why an unmanaged or “other sources” manual desktop pool works.

Situations where this is genuinely useful include:

Physical desktops and workstations. A physical PC that you want to publish through Horizon has no object in vCenter, yet it can still be pooled and brokered like a VDI.
Non-vSphere hypervisors. Guests running on Hyper-V, KVM/QEMU, Nutanix AHV, XenServer, or a public-cloud instance (EC2, Azure VM, GCP) can run the Horizon Agent even though there is no vCenter to integrate with.
Environments where another team owns vCenter. The Horizon administrator may not have vCenter privileges, or the organization may deliberately keep the EUC platform out of the virtualization platform’s management plane.
Labs, demos, and migrations. Standing up a proof of concept without touching the production vCenter is far lower risk.
Persistent, hand-built desktops. Image-management features (recompose, instant clone) are not required when machines are snowflakes that are patched in place.

How Horizon Behaves Without vCenter

It is important to be clear about what you keep and what you lose, because the behavior of the pool changes the moment vCenter integration is off.

Still works: agent registration and Machine inventory, manual desktop pools, dedicated and floating user assignments, Blast Extreme and PCoIP session brokering, HTML Access, Unified Access Gateway, GPO-driven agent configuration, printer and USB redirection, session recording, and connection to workloads through the tunnel.

No longer available: instant-clone and full-clone provisioning, automated power management (power-on and power-off schedules), recompose and push-image operations, snapshot-based refresh, automated pool maintenance, and the “vCenter” tab in the Horizon Console. Power state must be managed outside Horizon — for example by the hypervisor’s own scheduler, by Wake-on-LAN for physical machines, or manually.

In practice this means an unmanaged pool is a good fit for persistent machines that are expected to be available, and a poor fit for elastic “farm” workloads where hundreds of desktops churn every day.

Prerequisites

A guest operating system supported by the Horizon Agent you intend to install (Windows 10/11 Enterprise, or Windows Server 2019/2022 for multi-session hosts).
Horizon Agent version that matches — or is compatible with — the Connection Server version. Omnissa supports agent versions one major release back, so align them where possible.
Network reachability from the guest to the Connection Server: TCP 443 for the initial agent registration and brokering, UDP/TCP 4172 and UDP 4172 for Blast Extreme, plus the standard client-facing ports.
An account that holds the Horizon Administrator role on the Connection Server, used when the agent registers.
Accurate DNS and time on the guest. Agent registration fails surprisingly often because the guest cannot resolve the Connection Server FQDN or its clock is skewed enough to break TLS.

The Key Installer Switch: VDM_VC_MANAGED_AGENT

The whole trick is a single installer property. By default the Horizon Agent is installed in vCenter-managed mode: the agent expects its machine to be part of a vCenter-inventory pool and behaves accordingly. Setting the property VDM_VC_MANAGED_AGENT=0 tells the agent that no vCenter integration is present, so the agent registers with the Connection Server on its own and the machine can be added to an unmanaged pool.

From the command line the property is passed after the installer’s /v switch, which forwards parameters to the underlying MSI. The value is written into the registry at HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Agent\Configuration, where you can confirm it after installation.

The Process

The configuration will be divided into two sections. The first section covers the steps needed on the system that you will install the VMware Horizon agent on, and the second section covers the steps needed on the VMware Horizon Connection Server.

VMware Horizon Agent

Launch the VMware Horizon agent install with the command line argument /v VDM_VC_MANAGED_AGENT=0

If you prefer to control the install fully from a script, the same property can be driven through msiexec directly, which is what you would use in a deployment tool:

msiexec /i "VMware-Horizon-Agent-x86_64.exe" /qn ^
  VDM_VC_MANAGED_AGENT=0 ^
  VDM_SERVER=horizon.example.com ^
  ADDLOCAL=Core,USB,HTMLAccess ^
  /l*v C:\Windows\Temp\horizon-agent.log

In PowerShell the line continuation character is a backtick rather than a caret, and you can pass credentials with VDM_SERVER_USERNAME and VDM_SERVER_PASSWORD so the agent registers without an interactive prompt. Always keep the MSI log — it records the exact property set and is the fastest way to prove whether the zero was applied.

Click Next

Agreeto the general terms and clickNext.

Select IPv4and click Next.

Leave the features as default, or select the features you need and click Next.

Enter the address of the Horizon Connection Server and click Next.

If the account you are using to install the Horizon Agent isn’t an administrator in Horizon, you’ll need to specify the credentials for an account that is.

Click Install.

The Horizon Agent will now begin installing.

Click Finish.

Click Yesto reboot the system.

VMware Horizon Connection Server

Click on Inventory > Desktops.

Click on Add.

Select Manual Desktop Pool and click Next.

Set Machine Source to Other sources and click Next.

Select your User Assignments. I will use Dedicated.

Give your Desktop Pool an ID and Display name. I will use the name no-vCenter-VDI.

Set your Desktop Pool Settings as needed. I will be leaving this as default.

Set your Remote Display settings as needed. I will be leaving this as default.

Select the Machine you installed the VMware Horizon Agent on in the last section.

Review your settings. If all looks good click Submit.

Setup the user entitlements as you normally would.

When you log in to VMware Horizon, you can select the no-vCenter-VDI option. This option launches a Horizon session to your persistent VDI or physical machine while remaining fully independent from vCenter.

Dedicated vs Floating Assignments in a Manual Pool

A manual desktop pool supports dedicated assignments: once a user connects to a machine, that machine is bound to the user and stays theirs. This matches the persistent-machine philosophy of an unmanaged pool, where each desktop is patched and personalized in place.

Floating assignments are technically available, but they lose most of their value without vCenter, because the automatic “reset the desktop and hand it to the next user” cycle depends on snapshot and provisioning operations that vCenter performs. With floating assignments and no reset capability, whatever the previous user left behind — including local files and credentials in caches — remains on the machine. If you truly need floating, disposable desktops, you need vCenter plus instant clones.

Verifying the Deployment

After the reboot, confirm the agent registered correctly before you start troubleshooting the console:

# On the guest, confirm the agent service is running and the flag is set
Get-Service "VMware Horizon Agent"
Get-ItemProperty "HKLM:\SOFTWARE\VMware, Inc.\VMware VDM\Agent\Configuration" |
  Select-Object VDM_VC_MANAGED_AGENT, VDM_SERVER

On the Connection Server, the machine should appear under Inventory > Machines with a status of Available once you add it to the pool. If the agent is registered but the machine shows as Agent Unreachable, the problem is a network or firewall path between the guest and the Connection Server rather than the installer property.

Troubleshooting Common Problems

The machine never appears in the inventory. Usually DNS or firewall: verify the guest resolves the Connection Server FQDN and can open TCP 443 to it. Check the agent log in %ProgramData%\VMware\Logs\.
It appears, but sessions black-screen. This is a display-protocol problem rather than a brokering problem — see our write-up on the Omnissa Horizon unmanaged VDI black screen issue.
GPO settings are ignored. Agent behavior is largely driven by ADMX templates; apply them correctly as described in the VMware Horizon GPO templates guide.
Wrong network configuration in the guest. Port-group and VLAN mistakes at the hypervisor layer look like Horizon failures; the ESXi vSwitch, port groups and VLAN article covers that side.
TLS or certificate errors at registration. Confirm the guest trusts the Connection Server certificate chain and that its clock is synchronized.

When You Should Keep vCenter Integration

This approach is a deliberate trade: simplicity and independence in exchange for automation. If any of the following matter, connect vCenter instead — instant clones for rapid scale-out, automated pool provisioning, scheduled power management to save resources overnight, recompose-based image updates, or refresh-on-logoff for stateless desktops. The unmanaged manual pool is the right answer for persistent physical or foreign-hypervisor machines, and the wrong answer for a dynamically provisioned VDI farm.

I couldn’t find much documentation about this. However, I did find a brief mention of the VDM_VC_MANAGED_AGENT option in the Horizon documentation. You can read the Omnissa documentation about it here.

If you want to read more about Manual Desktop Pools, here is the Omnissa documentation about it.