View User Experience Settings

From vmWIKI
Jump to: navigation, search

Originating Author

Michelle Laverick

Michelle Laverick.jpg

Barry Coombs

Screen Shot 2014-04-28 at 09.41.39.png

Video Content [TBA]

Introduction View User Experience Settings

Version: Horizon View 5.1

There are many locations where you can make changes to the way that VMware View functions. Although VMware likes to refer to some of its settings as “policy” based, the product currently lacks an object called policy that can be attached to user, desktop pool or group. So as such it’s perhaps fairer to say we have settings that have different scopes. But don’t confuse VMware “policies” with, say, Microsoft GPOs – they aren’t comparable.

Global Settings

One of the most obvious places to make changes is in the Global Settings. Held under View Configuration and Global Settings after clicking edit there is a dialog box that applies to all users connected via View to their virtual desktop.


Some of these settings we feel are self-explanatory, such as the Session Timeout values and the pre-login and forced log-off messages. However, for completeness we want to take you through each of these settings and explain the meaning, usage and impact.

Settings Meaning, Usage and Impact
Session Timeout Total length of sessions, regardless of activity. Default of 600 minutes is 10hrs. Warning: It’s tempting to set a low tolerance on this value in effort to free up resources in the system, from users who leave themselves login for excessive time. Be careful. This can and does annoy users. Users who work remotely via Citrix XenApp Server constantly moan about this being set in Citrix/TS/RDS. They literally have to hang around the computer waiting for the timeout message before they can take a coffee break! Getting logged out often involves a lengthy re-login process and wasted time loading up programs all over again…
Use SSL for client connections* Turns off SSL for Connection Server – disable for local LAN connections where security might not be such a priority. However, it must be enabled for Smart Card Authentication. In the past, VMware has referred to this as a “Direct Connection”
Re-authenticate secure tunnel connections after network interruption* Forces a re-logon if you use a 3rd party VPN connection to connect to the Connection Server. Setting has no effect if you disable SSL for Client Connections
Message Security Mode Nothing to do with end-user messages! Concerns the security mode used between View server services. Enabling this will cause problems with older versions of View. If this is the case, either leave disabled or set the mode to mixed. In a pure View 5.x environment you can set “enabled” however, the View Security Servers file would need modifying for it to work. More about security servers in chapter 22.
Disable Single Sign-on for Local Mode Disables the single sign-on feature. Despite logging on to their corporate computer with domain credentials, users would have to supply login details to the View Client. You can enable this if your company policies decree that this sort of “pass-through” login is unsecure.
Pre-Login Message* Displays mainly for legal reasons a message to a user prior to login to the system. A sample message appears below:


Display warning before forced logoff* As we saw earlier in the recompose, refresh and rebalance of linked clones, users do receive messages when admin tasks affect the availability of their desktop
* Indicates that changes here require a restart of the Connection Server and any replicas

Global, Pool and User Policies

Putting these global setting to the side for the moment, let’s turn to VMware “Policy” settings. The use of quotation marks is deliberate, as we think it’s important not to see VMware Policies in the same light as, say, Microsoft GPOs. Within the View Administration webpages - there is no VMware policy object that is attached to an OU, rather there is a global location where we can set our preferences. We can over-ride these settings by using policies that are created for each desktop pool you create; these in turn can be over-ridden by User policies. If set, User policies over-ride all settings specified globally or on pool policies. The other thing to make clear is whilst Microsoft GPO’s offer a blistering and sometime bewildering array of settings – VMware View policy settings actually control a relatively small subset of configuration options. For example the vast majority of the settings that impact the user experience are to be found on the properties of the desktop pool they use.

As you might expect, the settings themselves are the same, all that changes is the scope of those changes – Global, Pool and User. These currently cover three main areas:

• View Policies (General Settings)

• Local Mode (Controls Local Mode - aka Local Mode Desktop - settings)

• Persona Management Policies

You can find global policies in the Policies and Global Policies – whereas Pool Policies can be found at Inventory, Select Pools then select the pool, followed by click in the Policies tab. It’s also in this location that you find the per-user policies or “Overrides”. Notice in the screen grab below there is a “User Overrides” option. The important thing to note is that the overrides are for individual users, not groups in AD. I find that a little strange, but I assume VMware think the Pool represents a “group”, although its perfectly possible for more than one AD group to be assigned to the pool. Sadly, that’s where the logic of VMware Policies fall down – it’s been the case since VMware View first had a policy feature.


Given what we know about the functionality of VMware View “policies” – its fair to ask where the best place to assign them would be – globally, pool or per user. We’re inclined to recommend using global policies first because there are more options then use the pool policies for “exceptions” to the rule – and user policies as exceptions to both global and pool policies. This should keep your administration to a minimum while allowing you maximum control.

As with the “Global Settings” feature there are a lot of options here to explain. You can view these setting by selecting Policies and Global Policies in the View Administration webpages. The page is broken up into general “View Policies” and “Local Mode” policies. Below is a copy of the View Policies dialog box:


The table below explains the settings available:

Settings Meaning, Usage and Impact
Multimedia Redirection (MMR) If you have been operating in this space for some time you might know that VMware rivals offer features where certain media formats are redirected out of the remote session to be rendered directly on the client using the network bandwidth?) at the client side. This is popular with thin clients that have support for a rich set of codecs. It’s not to be confused with “content redirection” where by using file associations in Windows you can cause .doc files to be loaded into a virtual desktop session when they are double-clicked or redirect the opening of a file to the local client device. If you feel your local clients will have insufficient bandwidth then turn this setting to “deny”. For example in a branch office you might find the rendering of multimedia within the View session offers a better QoS than being locally rendered.
USB Access This allows USB access to printers and USB sticks attached to the local client device. USB storage devices offer a wonderful way for users to funnel information out of your organization. So you may wish to disable this feature – but consider also that users could use cloud based storage solutions such as and
Remote Mode Setting this to “deny” effectively switches off the ability for the user to login to a desktop over the wire – and limits View to local mode only.
PCoIP Hardware Acceleration and Priority Used with ESX hosts that possess the Teradici APEX server offload card to enhance the user’s experiences. It also allows for different priority settings – you may recall we covered this in chapter 15 all about Teradici.

As for “Local Mode” there are a number of options available within Global Polices:


The table below explains the settings available:

Settings Meaning, Usage and Impact
Local Mode This enables and disables the “Local Mode” feature. It seems harmless enough but beware of denying access whilst a desktop is checked out, as this would stop a user from checking the desktop back into View. At the same time remote connections would be stopped because of the current checkout – the effect is to render the user desktop inaccessible either locally or remotely.
User-initiated rollback This allows a user to revert their desktop to its previous state before checking it out. This allows the remote desktop to become released, and all the changes to be discarded. The critical thing here is not so much the action but whether you think your end-users are capable of managing this feature.
Max time without server contact View stores an expiration policy on the local device, which is in turn encrypted. By default users are allowed to run in an offline or local mode for up to 7-days. It’s a matter of opinion whether this is a reasonable length of time given a user could check a desktop out just before going on holiday for example. Once the period has elapsed the View client displays a message and suspends the desktop. The desktop cannot be resumed until the user is connected back to the View server infrastructure.
Target replication frequency By default there is no replication because this setting and the “User deferred replication” are set to be off. Enabling target replication frequency instructs the View client to copy any changes in the local desktop file system to corresponding remote desktop or persistent disk. The idea is rather synching back large amounts of data at the time the user “checks in” to the local mode desktop – View attempts to keep the differences in the local desktop in synch with the centralized system. This of course, consumes bandwidth, possibly in a location where it may be scarce limited
User deferred replication This allows a user to temporarily stop a replication event – up to a maximum of two hours. It could be deployed by the user to defer a replication job that is interfering with their work.
Disks replicated By default all the virtual disks of a full-virtual machine are replicated. As such this setting only affects virtual desktops created using the linked clone feature. It allows an admin to determine whether it is just persistent disks that are replicated or just OS disks – or both are replicated.
User-initiated check-in Allows a user to check their desktop back into View
User-initiated replication Allows a user to manually trigger a replication of their local mode desktop back to the datacenter.

Using VMware ADMs with Microsoft GPOs

As we saw in the previous chapter there are a number of VMware developed ADM files that can be imported into Microsoft AD group policy system. These can be used to control the View environment including agents, clients and virtual desktops. Additionally, there are ADM files which allow you to have tight control over PCoIP settings.

You can find the .ADM files on the C: drive of the Connection Server at C:\Program Files \VMware \VMware View \Server \Extras \GroupPolicyFiles. You might notice their file names reflect the old name for View – it was once called “VMware Virtual Desktop Manager”

Agent Polices

To deploy View agent policies, start by creating a GPO in the top-level container that holds your virtual desktops. In our case we created a “View Agent Settings” GPO on the “View Desktops” OU.


Next import the .ADM file into the policy that helps us control these settings. You can do this by right-clicking the + User Configuration +Policies and right-clicking +Administrative Templates


Currently the agent based policy from the vdm_agent.adm file only contains one setting which covers how View handles time zone synchronization. This is not to be confused with the VMware Tools time synchronization which merely addresses the virtualization problem of clock-drift.


It is possible for the user to be in one time zone, and for the virtual desktop to be another. Such a case could occur in a stock trading system where an individual in San Francisco in Pacific Time gets up early in the morning in time for the opening bell of the NYSE in Eastern Time. The question here is what time stamp should be used for any activity of the end-user – the time where they are physically located, or the time where the application they are using is located. By default View assumes the time should reflect where the user is geographically located. This policy allows the administrator to invert this configuration. The policy setting appears to be checked on the first connection and no refresh or reboot was needed to apply it. It is also possible to make this configuration using the client policies – but it should not be set twice.

Client Polices

In contrast to the agent based .ADM there are lots of settings and configuration options for the View Client. Bear in mind that these policy settings only apply to Windows Clients running the Windows Client, and obviously do not apply to other clients supported by View such as the Apple Mac client.


It’s worth mentioning that some of these settings are the same as the Global Settings and Global Policies options. In this case we decided to pick out some favourites of ours that have proved popular in production environments.

Settings Meaning, Usage and Impact
Enable the Shade and Pin the Shade Both of these settings are mutually exclusive of each other. The “shade” is the toolbar that in View session is full screen.


When it is “unpinned” this “shade” disappears. The “shade” can be disabled all together, or made to be always “pinned” so it is visible at all times. VMware has appeared to adopted the Microsoft usage of English with the “Enable the Shade” option – so you do you find yourself setting disable on “enable the shade” to remove the taskbar from the user!

Don’t check monitoring alignment on spanning View has for some time supported multiple monitors. However, it has quite exacting requirements – the monitors must have the same heights and widths depending on whether they are orientated side-by-side or one on top of the other. That might not be possible – this setting overrides this requirement.
Security Settings:

Display option to login as current user

Default value of the “Login in as current user” checkbox

These two settings work together to control the View “pass-through” login feature – that allows the View client to take the current logged-in credentials of the user, and pass them on to the View Client. When used together you can enable the feature, and prevent a user from changing it. A “next-next” install would not normally enable pass-through authentication. Nor would it set the default FQDN for the Connection or Security Server. Using these policies allows you to preconfigure the client for use with zero end-user interaction. As can be seen by this login box from a clean installation:


Scripting Definitions:

Server URL

DesktopName to select


This parameter allows you to populate the “Connection Server” field in the View client. Used with the options discussed above, it can help automate the configuration of the client.

The “DesktopName to Select” can be used to automatically select and open a particular desktop pool. If configured, all a user needs to do is double click the View icon – and they would be automatically logged in with their credentials to the desktop. This assumes you have a fully trusted certificate for the connection (certificates are covered in Chapter 21) and that you don’t have a pre-login message configured in Global Settings

The “DesktopLayout” policy requires the “DesktopName to select” option to be enabled as well – and controls if the virtual desktop is set to be full-screen, windowed or enabled for multi-monitor.

Connection Server Policies

VMware View also ships with an .ADM file for the connection servers called vdm_server.adm. Currently this only contains one setting “Recursive Enumeration of Trusted Domains”, and it has quite a lengthy and somewhat obtrusive description:

Determines if every domain trusted by the domain in which the server resides is enumerated. In order to establish a complete chain of trust, the domains trusted by each trusted domain are also enumerated and the process continues recursively until all trusted domains are discovered. This information is passed to View Connection Server in order to ensure that all trusted domains are available to the client on login. This property is enabled by default. When disabled, only directly trusted domains are enumerated and connection to remote domain controllers does not take place. Note: In environments with complex domain relationships — such as those that use multiple forest structures with trust between domains in their forests — this process can take a few minutes to complete.

So much depends on your AD structure and whether you have multiple forest structures with trust demands in their forests. If you do then enumerating all these domains could take some time – and may build a list that ultimately the user would probably never select. Disabling this automatic enumeration could speed things up, but limit the selectable domains to those within a forest.

PCoIP Tuning Policies

Along side client configuration GPO templates, there are also options that allow us to control the performance of the PCoIP protocol. If you are looking for detailed information on this subject, VMworld 2011 EUC Session EUC1987 “VMware View PC-over-IP Performance and Best Practices” would be an excellent starting point. This session explains some of the improvements in the PCoIP protocol in View 5.0, and some of the tuning that can be done. If you are unable to access the session a very good white paper exists at this location which has been recently updated to include the enhancements to PCoIP in View 5:

The white paper covers optimization across the board but also includes a section just about PCoIP tuning. If you are interested in learning more about optimizing the wider network for PCoIP then we would recommend the helpfully entitled “VMware View 5 with PCoIP – Network Optimization Guide”.

This covers the settings we are mentioning here in some detail, but also includes useful scenarios as well.

PCoIP is often used over the WAN, and therefore some optimization relative to the bandwidth, latency and lossy nature of these types of networks can be beneficial. The important aspect to understand here is that the WAN varies massively from one organization to another. So on a modern corporate network you might enjoy extremely good links from one site to another. If the user is a Teleworker on a dedicated ADSL or cable line they might experience very moderate latency to the virtual desktop. Branch offices might actually have less rich bandwidth capabilities because these links could be shared and split between a modest number of users. Finally, truly remote locations such as an overseas call centre may have very long packet round-trip times that are heavily shared by a large number of users. So before you consider optimizing or tuning the PCoIP protocol it’s important to identify what type of WAN traffic you may be dealing with. In reality this could mean having to compromise on the quality of the user experience, to get the response times that users expect. For this reason you may want to isolate these users into distinct desktop pools in their own computer OU so that only those virtual desktops receive the policy.

The PCoIP. ADM template can be imported into computer based policy within a group policy object, and contains many settings. Not all of these settings concern performance, . some settings are merely associated with whether certain features are available – such as using the clipboard. We will focus on the settings that VMware identify as being critical in a WAN environment.


As you might know PCoIP has a number of codecs it can use to build up the user’s screen – and PCoIP selects the right codec to deal with different types of screen data including icons, graphics, video, text and photo. At the heart of PCoIP is something called “build to lossless” where the protocol presents screen updates as quickly as possible in a lossy format, and then in the background progressively improves the quality of what is present on screen. The appearance to the user is that certain images become crisper the longer they stay on the screen until such point that graphics are displayed in a lossless state. It can be quite difficult to demonstrate this experience unless you have a connection to the View Infrastructure that is on a narrow link such as a 3G connection (and you should be careful as this can seriously eat into your data allocation in your plan). View 5.0 introduces a new option to turn off this “build to lossless” feature, and this can reduce the bandwidth consumed by as much as 30%. By switching off “build to lossless” bandwidth is saved by not unnecessarily improving the screen display to the users. There are some applications that function and are useable in a state that VMware calls “perceptually lossless”. It’s essentially the distinction where the image presented is lossy, but the end-user really can’t tell the difference. If you want an analogy for this – consider a simple pop-song of the modern era encoded in a MP3 format at 256kbps or 512kps. Only the classical music connoisseur might notice the difference in quality. The same applies to the visual cortex. The “build to lossless” is easily turned off in the GPO – and yet again you will find yourself enabling a policy setting to disable a feature!


Note: Notice that not only must enable the policy, you usually have to accept the option as indication that you understand the implications of changing this setting. VMware also recommend reducing the quality of audio delivered to the desktop in WAN environments where bandwidth may be constrained. Of course you do have the option of turning audio off altogether, but many people would recommend that some lower quality audio is better than none at all. The default audio quality is set at 500kps, VMware recommend a value of 50-100kps is still functional enough to be useable – this acquaints to phone call or FM Radio quality audio. The policy setting is called “Configure the PCoIP session audio bandwidth limit”:


VMware also recommend that it is possible to degrade the frame rate used in video playback. The default frame rate is 30, and VMware recommend that this can be reduced to 10-15 based on the variability of your network – without significantly degrading the end-user experience. The settings to control the frame rate is held in the policy setting called “Configure PCoIP Image quality levels”, the policy controls not just the frame rate, but also the maximum and minimum image quality as well:


Additionally, with the PCoIP policy settings it is possible to limit the maximum bandwidth allocated to a session. This is set relative to your link and can assist in maximizing the numbers of concurrent sessions you can support – it can also assist in helping the PCoIP protocol estimate bandwidth consumption. The highest configurable value is 90,000 kbits/second. The policy setting is called “Configure the maximum PCoIP session bandwidth”.


Logic would decree that it is also possible to set the minimum amount of bandwidth to the PCoIP protocol, which can be used to reserve an allocation of bandwidth to a session - this is referred to in the GPO as the “Configure the PCoIP Bandwidth Session Floor” setting. With both of these settings it is important to configure a value that could lead to the network link being oversubscribed. Misconfiguration of these particular settings could lead to degraded rather than improved performance.

There are of course a range of settings and techniques that can be used to control the PCoIP protocol which are outside the scope of VMware technologies and Microsoft GPOs. To achieve the best results you may wish to look at the new performance monitoring counters that ship with View 5.0. VMware recommends looking at the buffers on the routers of UDP traffic and configuring them to absorb 50-100ms of traffic. At the heart of any stateful adaptive protocol management like PCoIP or VOIP are well planned and implemented priority settings, to ensure these protocols are treated as being more important than other traffic where packet delays are easier to tolerate. You may also want to look to see if you are getting any excessive packet re-ordering, packet loss or packet fragmentation around the PCoIP protocol – all of which can collectively affect performance. The PCoIP settings in the GPO policies do allow you to modify the Maximum Transmission Unit (MTU) size so it fits within your existing MTU values on the wider network. With that said it would be highly unusual for the default setting of a 1300 MTU value to be changed.


Finally, View 4.6 and later introduced a new “gateway” mode that enabled PCoIP to work across firewalls and the Internet without first setting up a VPN session. However, if you still intend to use VPN access first before users establish a VPN session (and therefore do not use the new “PCoIP Gateway” mode on the Security Server) VMware recommend using VPN-over-UDP or VPN in Datagram Transport Layer Security (DTLS is equivalent of SSL but for UDP packets) mode as this has been shown to lead to better performance.


As we have seen VMware “polices” are very different to other policies systems you may have used in the past. They lack some of the depth and breath of the policy systems present in other technologies. Nonetheless we think the introduction of these policy settings in View 4.5 represents a step in the right direction for the product. It chimes well with the increased focus on the policy features in the core vSphere5 platform. At the moment you will probably find the policy settings that allow you to control the View Client – and that will assist in the mass deployment of it to Windows PC’s useful. Anything that reduces the interaction of the end-user with configuration settings has got to be a priority.

In our next chapters we will move away from building up the user environment. We will be refocusing on the server infrastructure of View. If you have been following this book to the letter you currently will have just one Connection Server. This means there is no provision of high availability. Additionally, a Connection Server on its own cannot be used to give the end-user access to their desktop across the Internet. The resolution to these issues is to create a Connection Server replica and introduce a new role to our environment - that of the Security Server. Once we have the Security Server in place this will naturally raise other issues such as having valid and trusted certificates that prove the authenticity to the end-user of the environment they are connecting to. Neither the Connection Server or the Security Server have a built-in load-balancing component so we will round off these new server roles with two examples of load-balancing technologies with Microsoft Network Load-Balancing (MS-NLB) and F5’s BIG-IP Virtual Edition.