VMware Horizon GPO Templates

原文：VMware Horizon GPO Templates — theDXT (Daniel Keer)

In this post, I will detail step-by-step how to install the Omnissa Horizon (formerly VMware Horizon) GPO templates.

Technically speaking you can fully use Horizon without any of the GPO templates however there are a lot of useful settings in them that you can configure.

Before installing the Horizon GPO templates I recommend you create a Central Store. Here's how to Create Active Directory Central Store.

I recommend making a note that you've added an extra GPO template to the Central Store.

Why the Templates Are Worth Installing

Horizon works perfectly well on defaults. A golden image with the Horizon Agent installed, a Connection Server with a desktop pool, and a client that points at the right URL will give users a working virtual desktop without a single group policy object in the picture. The templates matter once you move past "it works" into "it works the way we need it to".

A virtual desktop is not a physical PC, and the difference shows up in places Group Policy is the natural place to control:

• Redirection and device control — USB redirection allow and block lists by device class or VID/PID, client drive redirection, clipboard direction (client-to-agent, agent-to-client, both, neither), printing and thinprint behaviour, and scanner redirection.
• Session and display behaviour — Blast protocol options, H.264/HEVC encoding selection, adaptive transport and bandwidth settings that determine how the session feels over a congested WAN link.
• User environment — Persona Management settings, application profiling integration, and the behaviour of the remote desktop features that make a VDI session feel like a local machine.
• Diagnostics — Performance Tracker and logging options that make it possible to answer "why is this session slow" with data rather than opinion.

Because these settings live in ADMX templates, they are enforced by Group Policy like anything else: they survive reimaging, they apply consistently to every desktop in the pool, and they can be scoped with WMI filters or security group filtering. Doing the same work with registry preferences is possible, but you lose the ADMX documentation, the validation and the readable reporting in Group Policy Management Console.

What's in the Horizon GPO Bundle

Omnissa ships the templates as a separate download called the Horizon GPO Bundle, which is distinct from the Connection Server and Agent installers. It contains a set of ADMX files covering the different Horizon components — the agent's remote desktop features, the Horizon Client, Persona Management, and Performance Tracker — plus matching ADML files in one or more languages.

The important detail, and the one that surprises people: the templates apply in two different places. Settings aimed at the agent belong in a policy that applies to the virtual desktop itself, because that is where the agent runs. Settings aimed at the client belong in a policy that applies to the physical endpoint the user connects from. Installing the whole bundle into the Central Store makes both sets available, but a single GPO for both audiences is a configuration mistake waiting to happen.

The exact set of ADMX files differs between Horizon versions, and Omnissa has renamed several templates since the transition from VMware, so list the contents of the extracted bundle before you copy anything. If you are unsure which template a given policy comes from, the GPMC tree shows the category under which each setting appears.

Why Use a Central Store

The Central Store is the recommended way to hold ADMX files because it keeps a single copy of the templates in SYSVOL rather than a copy on every administrator's workstation. Without it, each admin's GPMC reads templates from their own C:\Windows\PolicyDefinitions folder, and if those copies differ by version you get the classic symptom of settings appearing or disappearing depending on who opened the GPO — and occasionally a policy that silently rewrites itself when someone with older templates saves it.

In a Central Store, GPMC ignores the local templates entirely and reads only from the store, so everybody sees the same thing. That consistency is worth the ten minutes of setup, and it is a prerequisite for the rest of this guide — see Create Active Directory Central Store for the procedure, which amounts to creating a PolicyDefinitions folder under the domain's SYSVOL Policies path and copying the operating system's ADMX and ADML files into it.

The Process

• Download the Horizon GPO Bundle from Omnissa.

Horizon GPO Bundle Download

• Extract the contents of the VMware Horizon Extra Bundle zip file.

Extracting Horizon GPO Bundle

• Copy over all the files including the folder for your language to your Central Store. (even if your language isn't English copy over en-US too because it is used as a fail safe if something isn't translated in your language)

Copying Horizon GPO Bundle to the Central Store

• Now when you create a new GPO you will have VMware Horizon options listed under Computer and User configurations.

GPO with Horizon options

If you want to read more about the VMware Horizon GPO templates you can by reading the Omnissa documentation about it here.

Step Details and Gotchas

Downloading the bundle

The GPO Bundle is listed alongside the Connection Server, Agent and Client installers on the Omnissa download pages, and it is version-matched to the Horizon release you are running. Downloading the bundle for a different version than the agent you have in your golden image is a common source of confusion: the ADMX files are forward and backward compatible in the sense that they do not break, but a setting you are looking for may not exist in an older template set. Match the bundle to the release level of your Connection Servers.

If your organisation downloads through a managed portal or requires a signed-off access request, get that started early — the bundle is on the restricted download area, not on a public page, and waiting on entitlements is often the longest part of the task.

Extracting

Extract to a temporary working folder rather than directly into SYSVOL. You want to inspect the structure, confirm the ADML language folders, and have a clean copy to compare against if something goes wrong. Keep the extracted folder around as the reference copy for that Horizon version.

Copying the ADMX files

Copy the .admx files into the root of the Central Store's PolicyDefinitions folder, alongside the operating system templates. ADMX files are not recursive — GPMC reads .admx from the root and .adml from the language subfolder only — so a nested folder will simply be ignored and the settings will never appear.

Copying the language files

The .adml files go into the language subfolder, for example PolicyDefinitions\en-US. The guidance from the original post is worth repeating: always copy en-US even if your environment runs in a different language, because en-US is the fallback that GPMC uses for any string that has not been translated. Skip it and you get a policy tree full of blank labels or, worse, template load errors. If your admins work in German, French or Japanese, also copy that language folder — multiple language folders coexist without conflict, and each admin sees the language their own Windows install requests.

Keeping a record

Make a note that you have added a vendor template set to the Central Store, and note the version. The Central Store is shared infrastructure; six months later, when a colleague upgrades Horizon and replaces the ADMX files, the difference between "we added these deliberately" and "something changed" is the note in your build documentation. Some teams keep a small text file in the PolicyDefinitions root listing every non-Microsoft template set and its version — it takes a minute and it answers a whole class of future questions.

Using the Settings

Once the templates are in the store, create a GPO linked to the appropriate scope and browse to Computer Configuration > Policies > Administrative Templates or User Configuration > Policies > Administrative Templates. The Horizon categories appear as top-level nodes in the tree, and every setting inside them behaves like a native policy: Enabled, Disabled or Not Configured, with options exposed in the same pane.

A practical split that works well in most environments:

• A desktop GPO, linked to the OU containing your VDI machines, holding the agent-side settings: redirection policy, session features, Persona Management, Performance Tracker.
• A client GPO, linked to the OU containing managed endpoints, holding client-side settings only.
• A user GPO, where the setting is genuinely per-user rather than per-machine, such as parts of the clipboard or drive redirection behaviour.

Keep the redirection decisions in one place. If USB blocking rules are spread across three GPOs with conflicting values, the resulting behaviour depends on link order and enforcement flags, and debugging it costs far more time than centralising it would have. The same discipline that applies to any policy set — export and archive working configurations before you change them, as described in GPO Export and Import — pays off here.

Maintaining the Templates

Every Horizon upgrade brings an updated GPO bundle, and the templates should be refreshed at the same time as the agents. The mechanics are simple: extract the new bundle, replace the matching .admx and .adml files in the Central Store, and note the new version. Do not leave old and new versions of the same ADMX file side by side with different names, because GPMC will load both and the tree will show duplicate categories that write to the same registry keys.

Before replacing, take a copy of the current template set. If a Horizon upgrade renames a policy or removes a deprecated setting, GPOs that used the old setting keep their stored value but no longer expose it in the editor, which looks alarming in a change review until you confirm that the policy is still applied. Checking a small pilot pool after each refresh is the cheapest way to catch that.

Troubleshooting

• The Horizon node does not appear. Check that the .admx file is in the root of PolicyDefinitions and that a matching .adml exists in the language folder that your GPMC is requesting — usually en-US. A missing or mismatched ADML is the single most common cause.
• Template load error when opening a GPO. Almost always an ADML mismatch or a renamed ADMX file still referenced by a policy. Fix the language file first.
• Settings visible but not applying. Confirm the GPO is linked to the OU containing the machine or user, that the Horizon Agent is actually installed on the target, and remember that many agent-side settings are read at agent start or at session start rather than live.
• A setting disappeared after an upgrade. The policy was deprecated or renamed. Check the Omnissa release notes for the Horizon version, and consider the configuration companion, Omnissa Horizon locked.properties Settings, for properties that moved out of the template into the Connection Server configuration file.
• Conflicting values between GPOs. Use the Group Policy Results wizard against a specific machine; the winning GPO and the reason it won are shown explicitly, which is far faster than comparing settings by eye.

Wrapping Up

Installing the Horizon GPO templates is a short job — download, extract, copy, verify — but the payoff is access to the settings that turn a default VDI deployment into one that matches your organisation's security and user-experience requirements. The two habits that make it maintainable are using a Central Store so every administrator sees the same template set, and always copying the en-US language files even in non-English environments. Add a note to your build documentation when you do it, and refresh the templates on the same schedule as your Horizon upgrades.