Home > Blogs > Horizon Tech Blog

Becoming “Location Aware” Using Horizon View

By Cynthia Hsieh, Director, Solution Management, End-User Computing, VMware

This blog is written to help you understand how location awareness can be done in VMware Horizon View. In the world of BYOD or “Bring Your Own Device,” it’s critical your IT organization knows your configuration 4W (who, what, where, when) and 1H (how). Namely, who is accessing? What device do you use to access? What workplace are you trying to join in? Where are you accessing from? When are you trying to access?…

This blog focuses on the client attributes provided by VMware Horizon View which you can leverage and design for location awareness.

Exploiting Location Awareness                                                

So, what did we add to the Horizon View client?  Specifically, we’ve added information to the user’s Volatile Environment registry key. The new field is:


For a real-world example, I connected to my development desktop from two different clients. Here are the results of my 1st login and connect:

And here are the results of my 2nd desktop connect:

Notice how the machine name changes. More importantly, I DID NOT logoff my client session. I just did a connect, disconnect and then reconnect.

Before we go further, I want to discuss the information Horizon View provides. If we’re going to exploit the information for location identity, we need to make sure we’re tracking the correct field. The product has done a great job of supplying client information to desktop applications, but there are some hidden dangers.

First, don’t use IP address or MAC address information unless you know your network cards will never fail or the clients will always be bound to the same IP address. Because these are never true, the information is good for logging, but not for location configuration.

Secondly, this information only comes from a Horizon View client in a non-kiosk mode. And, if you’re accessing your desktop through vSphere console, this information will not be present.

Now the fun part. Let’s exploit this information. At the VMworld 2013 BYOD tent, we come up with a cool simple application that uses this information in a new and exciting way called AppSecurity. AppSecurity shows or hides desktop icons depending upon the user’s “location” (e.g., their connecting machine name).

AppSecurity uses a simple .INI format file so you can easily play with location information. There are two headers within the .INI file. One for application desktop icons and the other for a “notification” message, should you want to tell your users whether they can have access to their games shortcuts or not.

First the application header, which has the following format:


where <ViewClient_Machine_Name> is equal to your machine name and <n> is a sequence number which starts from 0.

An example header might be:


Under the application header we have 3 fields: security, fileName and shortCutName. The following table describes these fields:

Field Value(s) Description
Security Hide or Show Specifies whether desktop icon should be displayed or hidden.
fileName <path> Specifies full path to executable.
ShortCutName <name> Specifies name of shortcut. Users will see this name underneath the application icon on their desktop.

Here is an example application section within .INI:

fileName=c:\program files\Microsoft Games\Chess\Chess.exe

Some caveats about the application section: If you specify an application to be hidden, you must also specify it to be displayed. That is, for EVERY machine name, you need to specify the security state of the application.

The sequence number must start at 0 and be incremented by 1 for each new application section. For example, if I’m working with two applications, I would specify



The second header controls user notification and is optional. When AppSecurity determines that a user has connected from a different location (i.e., the machine name is different), it displays a little “toaster” notification box in the lower right hand corner of the user’s desktop. This allows you to tell your users in a friendly way that their desktop has changed in an unobtrusive way.

The format of the notification section is as follows:


The fields for the notification section are as follows:

Field Value(s) Description
Notification <string> Specifies string to display.
Timeout <number> Specifies how long notification window is to be displayed in milliseconds – e.g., 1000 = 1 second. Default is 3000.
Width <number> Width of box. Default is 300.
Height <height> Height of box. Default is 150.

Putting it all together, here’s a full .INI file. Icons for Chess will be installed when the user is at home and Solitaire when they’re at work. (NOTE: This assumes your users are connecting via machines named “HOME” and “WORK.” To make this example work, you’ll need to change the machine names.)

fileName=c:\program files\microsoft games\chess\chess.exe

fileName=c:\program files\microsoft games\solitaire\solitaire.exe

fileName=c:\program files\microsoft games\chess\chess.exe

fileName=c:\program files\microsoft games\solitaire\solitaire.exe

notification=”You’re home. You may play chess.”

notification=”You’re at work. You may not play solitaire.”

In conclusion, we’ve seen how you can exploit new information supplied by the Horizon View Connector. In the next blog, staying in the same context, we’re going to take this location information one step further and talk about how you can exploit the View Connector for mobile devices – you know, where the machine name stays the same but a user moves about by manipulating location “proxy” information.

5 thoughts on “Becoming “Location Aware” Using Horizon View

  1. crear tienda

    I enjoy, result in I discovered what exactly I used to be taking a look regarding. You may have broken my some day time prolonged search for! Lord Cheers guy. Have got a wonderful evening. Cya

  2. forbsy

    Can Location based awareness be used to restrict users from accessing desktop pools? The issue is in higher ed there are lab machines that all students have access to (everyone entitled). That’s common for higher ed. Certain labs have licensed apps that only have enough licenses for that lab. I don’t want a student who is accessing the VDI environment from a location outside that lab to be able to launch a desktop from a lab with software license restrictions. Only students within the lab physical location can launch one of those desktops.
    How can location based awareness be used to achieve this? Something like, if the MAC of the end-point is not part of the allowed MAC pool, reject the request. It would be nice if the broker not only enforced user entitlements, but also restricted based on location based awareness variables.
    Using tags is not scalable.


  3. Brandon

    Since ViewClient_Machine_Name isn’t populated when a user access a VM from HTML access and the BLAST protocol, would using one of the IP address fields be an acceptable way to identify the remote client?


Leave a Reply

Your email address will not be published. Required fields are marked *