Horizon View 5.3 Appendix F: Monitoring the View Event Database

One of the nice features of Horizon View 5.3 is the Events Database.  When its configured, the Events Database will collect and store any events from the Horizon View environment.

Unfortunately, VMware never built any notification tools into View to alert administrators when errors occurred and were recorded in the Events database.  There have been workarounds to this using PowerShell or SQL Mail to send database alerts, but this requires a scheduled task or SQL Agent job to ensure that it runs on a regular basis.

There is another option that can be used for Event database alerting.  Chris Halstead (Twitter: @chrisdhalstead) developed a tool called the Horizon View Event Notifier that recently became a VMware Fling. 

The Horizon View Event Notifier is a simple little application that is very easy to set up.  It’s so easy, in fact, that it doesn’t even have an installer – you just create a folder for the application and drag the executable and the config file into a folder and double-click to launch it.

Unfortunately, this simplicity carries a heavy price.  The Event Notifier cannot be run as a scheduled task or service.  It must run interactively, and if the server running the application is rebooted, an administrator will need to log in, restart the application, and then lock the computer or disconnect their session without logging out.  Chris has stated that this is one of the things he hopes to address in the next version of the program.

Configuring the Horizon View Event Notifier

After you’ve finished installing the Event Notifier, it’s time to start configuring it. 

1.  Click the settings tab.


2. Fill in the Name, DB Server, Database, Username and password fields.  If you have multiple View pods storing information in the same events database, you may need to enter your table prefix in the Table Prefix field. 

If you are connecting to a SQL Server instance, enter servername\instancename in the DB Server field.


3. Click Test Connection to verify that the Event Notifier Application can log into the database.

4. Click Save Changes to save the database information to the config file.

5. Select the type of events that you want to receive email alerts on and then click Save Changes.


6. Enter your email server, port number, sender address, and recipient address.

Note: The application does not appear to support email servers that require authentication, such as Gmail, at this time. 


7. Click Send Test Email to verify that email alerts work.

8. Click Save changes.

9. Click Start to have the application start monitoring your View Events database.

Note: The application will need to be launched and the start button clicked every time the computer is rebooted.

Do I Need It?

If you don’t have any other form of alerting configured for Horizon View Events, this program will help you maintain a healthy View environment.  It’s saved my bacon a few times when a recompose operation failed and left a pool unusable.  If I this tool hadn’t been in place, I would have had a flock of angry users with no desktops. 

Horizon View 5.3 Appendix E: Converting The View Group Policy Templates to ADMX

VMware View includes a set of Group Policy templates that can be used to centrally manage settings for View desktops and servers.   These templates are required for fine tuning the behavior of a Horizon View environment and the PCoIP and Blast protocols that are used when connecting to desktops.

Brian Suhr recently wrote a great article on how to deploy the Group Policy templates on Petri. 

There is one main drawback to the Group Policy templates that are included with Horizon View – they’re ADM files.  Prior to Windows Server 2008, Group Policy templates were deployed using ADM files.  If a non-standard ADM file was used as part of a Group Policy Object, that ADM file would be included with the group policy object when it is saved onto the domain Sysvol.  This leads to Sysvol bloat and can have a negative impact on Active Directory Replication.

Microsoft addressed this issue with updates to Group Policy in Windows Server 2008.  Server 2008 allowed Administrators to create a network-based “central store” where the new Group Policy template files are stored.  These templates could then be referenced by any workstation or server that was Vista/Server 2008 or newer when authoring or editing Group Policy without having to install them.

Converting the View ADM Files to ADMX

I haven’t found many tools that convert ADM files to ADMX files.  Microsoft has released a free conversion tool, but it didn’t convert the View ADM files properly, and a number of GPO settings did not work after using this tool.

The only other ADM converter tool that I was able to find was Syspro’s ADM Template Editor.  This $60 tool can edit existing ADM templates or convert them to ADMX files.  A 30-day free trial of the ADM Template Editor is available.

The first thing that you will need to do is download, install, and register ADM Template Editor.  Once you have done this, you can start converting the ADM files.

The steps for converting ADM files to ADMX files using the ADM Template Editor are:

1.   Copy the View ADM files to the server or workstation where ADM Template Editor is installed.  On a default installation of View, the ADM files are located in C:\Program Files\VMware\VMware View\Server\Extras\Group Policy on any Connection Server.

Group Policy Files Location

2.  Open ADM Template Editor.

3. To configure ADM Template editor to save new ADMX files directly into your Group Policy Central Store, go to Setup –> General Setup and enter the path to your Group Policy Central Store into the ADMX directory field. 

ADM Convert Pre-Step

Note: If your Active Directory Administrator has not set up a Group Policy Central Store, please refer them to this article.

4. Go to File –> Add Existing ADM file…

ADM Convert 2

5.  Select the ADM files you want to load and click Open.

ADM Convert 3

5.  Go to File –> Convert ADM to ADMX

ADM Convert 4

6.  Select the ADM file(s) you want to convert and click Convert.

ADM Convert 5

7.  The next screen allows you to change metadata before converting the ADM file.   Make any changes as required and then click OK.

ADM Convert 6

8. Go to File –> Save Files.

ADM Convert 7

9. Click Save As

ADM Convert 8

10. Save the files into a directory where you will be able to find them easily.

ADM Convert 9

11. Open the directory where you saved the ADMX files.  Copy the ADMX files and the language folder to your Group Policy Central Store.

Note: The converted Group Policy templates will not be available at remote Active Directory sites until replication occurs.

12. When you create a new Group Policy object, the converted ADMX templates should be available under Administrative Templates.

ADM Convert 11

VMworld Call For Papers Voting Closes Sunday

Voting on the VMworld call for papers submissions closes on Sunday night.  If you’re interested in helping chart the course of this year’s VMworld, you can vote at http://www.vmworld.com/voting.jspa.

If you do plan on voting, I would highly recommend voting for the following session:

Session 1500 – Auto Deploy Deep Dive by Rob Nelson

Rob previously presented on this topic at vBrownbag.

I have two submissions for this year’s conference:

Session 1352 – Automating Horizon View with PowerShell

Session 2690 – Managing Microsoft Active Directory and Exchange with vCenter Orchestrator

I would recommend that you look through the submission catalog if you have time.  There are a lot of good presentation ideas from community members, such as Kendrick Coleman’s “How to Turn a vSphere Administrator into a Goat” and a session by Brian Suhr and Chris Wahl on understanding virtual workloads.

Remember, you only have until Sunday night to vote and influence this year’s VMworld.

Horizon 6 and Profile Management? It’s Not the Big Deal That Some Are Making It Out To be…

When VMware announced Horizon 6 last month, there was a lot of excitement because the Horizon Suite was finally beefing up their Remote Desktop Session Host component to support PCoIP and application publishing.  Shortly after that announcement, word leaked out that Persona Management would not be available for RDSH sessions and published applications.

There seems to be this big misconception that without Persona Management, there will be no way to manage user settings, and companies that wish to overcome this shortcoming will need to utilize a 3rd party product for profile management.  A lot of that misconception revolves around the idea that there should only be one user profile and set of applications settings that apply to the user regardless of what platform the user logs in on.

Disclosure: Horizon 6 is still in beta.  I am not a member of the beta testing team, and I have not used Horizon 6.

There are two arguments being made about the lack of unified profile management in Horizon 6.  The first argument is that without some sort of profile management, users won’t be able to save their application settings.  The article quotes a systems administrator who says, “If you rely on linked clones and want to use [RDSH] published apps, it won’t remember your settings.”

This is not correct.  When setting up an application publishing environment using RDSH, a separate user profile is created for each user on the server, or servers, where the applications are hosted.  That user profile is separate from the user profile that is used when logging into the desktop.  In order to ensure that those settings follow the user if they log into a different server, technologies like roaming profiles and folder redirection are used to store user settings in a central network location.

This ability isn’t an add-on feature, and the ability to do roaming profiles and folder redirection are included with Active Directory as options that can be configured using Group Policy.  Active Directory is a requirement for Horizon environments, so the ability to save and roam settings exists without having to invest in additional products.

The other argument revolves around the idea of a “single, unitary profile” that will be used in both RDSH sessions for application publishing and virtual desktops.  There are a couple of reasons why that this should not be considered a holdup for deploying Horizon 6:

  1. Microsoft’s best practices for roaming profiles (2003 version, 2008 R2 version, RDS Blog) do not recommend using the same profile across multiple platforms, and Microsoft recommends using a different roaming profile for each RDSH farm or platform.
  2. Citrix’s best practices for User Profile Manager, the application that the article above references as providing a single profile across application publishing and virtual desktops, do not recommend using the same profile for multiple platforms or across different versions of Windows.

There are a couple of reasons for this.  The main reason is that there are settings in desktop profiles that don’t apply to servers and vice versa or across different generations of Windows.  There is also the possibility of corruption if a profile is used in multiple places at the same time, and one server can easily overwrite changes to the profile.

Although there may be some cases where application settings may need to roam between an RDSH session and a virtual desktop session, I haven’t encountered any cases where that would be important.  That doesn’t mean those cases don’t exist, but I don’t see a scenario where this would hold up adopting a platform like the article above suggests.