Horizon Sizing Estimator

Something which I discovered today which I am sure many partners will find useful is the Horizon Sizing Estimator tool. This is located at https://developercenter.vmware.com/group/dp/horizon-sizing-tool  this is available to partners only I believe. You can use the free lakeside assessment tool to generate the assessment data either via the free cloud based tool http://assessment.vmware.com or the free on site version.

Using this tool you can then generate a XML file which is then fed in to the sizing tool to help size your customer’s environment.  You can also manually specify a whole ton of other variables.

Screenshot 2016-02-01 20.25.32

Horizon View: USB Redirection Problems


USB redirection in View Client fails to make local devices available on the remote desktop, or some devices do not appear to be available for redirection in View Client.


  • The following are possible causes for USB redirection failing to function correctly or as expected.
  • USB redirection is not supported for Windows 2003 or Windows 2008 systems or for View desktops that are managed by Microsoft Terminal Services.
  • Webcams are not supported for redirection.
  • The redirection of USB audio devices depends on the state of the network and is not reliable. Some devices require a high data throughput even when they are idle.
  • USB redirection is not supported for boot devices. If you run View Client on a Windows system that boots from a USB device, and you redirect this device to the remote desktop, the local operating system might become unresponsive or unusable. See http://kb.vmware.com/kb/1021409.
  • By default, View Client for Windows does not allow you to select Human Interface Devices (HIDs) and Bluetooth devices that are paired with an HID for redirection. See http://kb.vmware.com/kb/1011600.
  • RDP does not support the redirection of USB HIDs for the console session, or of smart card readers. See http://kb.vmware.com/kb/1011600.
  • RDP can cause unexpected problems when using USB flash cards. See http://kb.vmware.com/kb/1019547.
  • Windows Mobile Device Center can prevent the redirection of USB devices for RDP sessions. See http://kb.vmware.com/kb/1019205.
  • For some USB HIDs, you must configure the virtual machine to update the position of the mouse pointer. See http://kb.vmware.com/kb/1022076.
  • Some audio devices might require changes to policy settings or to registry settings. See http://kb.vmware.com/kb/1023868.
  • Network latency can cause slow device interaction or cause applications to appear frozen because they are designed to interact with local devices. Very large USB disk drives might take several minutes to appear in Windows Explorer.
  • USB flash cards formatted with the FAT32 file system are slow to load. See http://kb.vmware.com/kb/1022836.
  • A process or service on the local system opened the device before you connected to the remote desktop.
  • A redirected USB device stops working if you reconnect a desktop session even if the desktop shows that the device is available.
  • USB redirection is disabled in View Administrator.
  • Missing or disabled USB redirection drivers on the guest.
  • Missing or disabled USB redirection drivers or missing or disabled drivers for the device that is being redirected on the client.


  • If a redirected device remains unavailable or stops working after a temporary disconnection, remove the device, plug it in again, and retry the redirection.
  • In View Administrator, go to Policies > Global Policies, and verify that USB access is set to Allow under View Policies.
  • Examine the log on the guest for entries of class wssm_usb, and the log on the client for entries of class wswc_usb.
  • Entries with these classes are written to the logs if a user is not an administrator, or if the USB redirection drivers are not installed or are not working.
  • Open the Device Manager on the guest, expand Universal Serial Bus controllers, and reinstall the VMware View Virtual USB Device Manager and VMware View Virtual USB Hub drivers if these drivers are missing or re-enable them if they are disabled.
  • Open the Device Manager on the client, expand Universal Serial Bus controllers, and reinstall the VMware View Generic USB Device driver and the USB driver for the redirected device if these drivers are missing or re-enable them if they are disabled.

The View virtual machine is not accessible and the View Administration console shows the virtual machine status as “Already Used”


If a desktop that is set to refresh or delete after log off is reset, the desktop goes into the Already Used state, or possibly the Agent Disabled state.

This security feature prevents any previous session data from being available during the next log in, but leaves the data intact to enable administrators to access the desktop and retrieve lost data or investigate the root cause of the reset. Administrators can then refresh or delete the desktop.

The View desktop can also go into the Already Used state if a virtual machine is powered on in another ESXi host in the cluster in response to an HA event, or if it was shut down without reporting to the broker that the user had logged out.



To resolve this issue, perform a refresh of the desktop using the View Administration console. For more information, see the VMware Horizon View Administration guide relevant to your version.

Alternatively, In View 5.1.2 and later releases, you can add a View LDAP attribute, pae-DirtyVMPolicy under OU=Server Groups, DC=vdi, DC=vmware, DC=int, and set the values below for the attribute.


The pae-DirtyVMPolicy values provide these options for the Refresh on logoff policy:

  • pae-DirtyVMPolicy=0: Mark virtual machines that were not cleanly logged off as Already used and block user access to them. This is the default behavior in View 4.6 and later releases.
  • pae-DirtyVMPolicy=1: Allow virtual machines that were not cleanly logged off to become available without being refreshed. View Client users can access these desktops.
  • pae-DirtyVMPolicy=2: Automatically refresh virtual machines that were not cleanly logged off. View Client users can access these desktops after the refresh operation is completed

Horizon View – vCentre Server (7 of 7)


The vCentre server is the management layer for managing the ESXi hosts. View integrates into the vCentre server to allow it to power on & off desktops. View composer talks to vCentre for any provisioning tasks that need to be ran e.g. Creating or deleting desktops and refreshing desktops at log off.

The vCentre server should be a dedicated vCentre server purely for the VDI Desktop environment and separate from any existing server environment.

Horizon View – View Client (6 of 7)


The View Client is the primary access method for accessing View Desktops, it can run on IOS,Android,Thin Clients, MAC and PC’s/Laptops.


With the latest release VMware have provided us with the ability to redirect client drives a feature which has been available to Citrix users for quite some time.  Check the latest Brian Madden review of this here.


Horizon View – View Agent (5 of 7)


The View Agent resides on the virtual desktop and provides features such as connection monitoring, virtual printing and access to local USB devices. The View Agent is installed by running the appropriate View Agent installer. An additional installer used to be required to add the HTML (Blast) access, this was referred to as the Feature Pack Installer but this is now included within the agent installer.


Horizon View Composer Service (4 of 7)


The View composer service is responsible for the creation and provisioning of the Virtual Desktops within vCenter.



  • Create a VM in vCenter with the View Agent installed (the Parent VM),
  • Shutdown the VM and create a Snapshot,
  • In View Manager, create a new Automated linked-clone pool.

What happens next (KB 1021506);

  1. View Manager creates the linked-clone entry in View LDAP and puts the virtual machine into the Provisioning state.
  2. View Manager calls View Composer to create the linked clone
  3. The View Composer Server creates the machine account entry in Active Directory for the new clone and creates a random binary password for the newly created computer account.
  4. If a replica for the base image and snapshot does not yet exist in the target datastore for the linked clone, View Composer creates the replica in the datastore. If a separate datastore is configured to store all replicas, the replica is created in the replica datastore. (In View 4.5 and later, replicas can be stored in a separate datastore.)
  5. View Composer creates the linked clone using the vCenter Server API.
  6. View Composer creates an internal disk on the linked clone. This small disk contains configuration data for QuickPrep or Sysprep. The disk also stores machine password changes that Windows performs every 30 days, according to the policy setting. This disk data ensures that domain connectivity is maintained when a checkpointed desktop is refreshed.


A recompose operation lets the administrator preserve the View Composer persistent disk and all user data inside this disk while changing the operating system disk to a new base image and snapshot. With recompose, an administrator can easily distribute operating system patches and new software to users. Recomposing between major operating system versions are not supported (XP >Vista, XP >Windows7, Vista >Windows7).

Because a new operating system  disk is created during a recompose, the clone is also customized again during the recompose operation. When the customization is completed, View Manager takes a new snapshot.

These steps occur during a recompose operation:

  1. View Manager puts the linked clone into the Maintenance state.
  2. View Manager calls the View Composer resync API for the linked clones being recomposed, directing View Composer to use the new base image and snapshot.
  3. If a replica for the base image and snapshot does not yet exist in the target datastore for the linked clone,View Composer creates the replica in the datastore. If a separate datastore is configured to store all replicas, a replica is created in the replica datastore.
  4. View Composer deletes the current operating system disk for the linked clone and creates a new operating system disk, linked to the new replica.
  5. The rest of the recompose cycle is identical to the customization phase of the provisioning and customization cycle.

Horizon View Security Servers (3 of 7)


Security servers in the DMZ communicate with the external View Connection Servers on the internal network. Security servers ensure that the only traffic that can enter the internal network is traffic on behalf of a strongly authenticated user. Users can access only the desktop resources that they are authorized to access.

The Security server is not on the domain and it is placed inside the DMZ in a workgroup.

The following ports are opened externally to this server.

  • TCP/80 (Web Access and Authentication port if SSL is not used)
  • TCP/443 (Secure Web Access and Secure Authentication)
  • TCP/4172 ( PCoIP protocol – Display protocol VMware View users)
  • TCP/8443 (HTML 5 Protocol – aka Blast Protocol used for access via a HTML 5 supported browser to access a VDI desktop without the need to install any client software)

The security servers establishes an IPSEC VPN to an connection server on the internal network which it is permanently paired too and has a 1:1 relationship with.

Horizon View Client Connection Process (2 of 7)


Below is a breakdown of the view client connection process, hopefully this will be useful to you if you are troubleshooting any connectivity issues.

  1. The View Client initiates a connection to the Connection Server or Security Server, providing a username and password. This occurs over TCP port 443, which is the standard HTTPS port.
  2. The Connection Server returns a list of entitled Desktops that the user has, and the user then selects one. The information bearing the user’s choice is sent back to the server. Again, this occurs over TCP port 443.
  3. The View Client initiates the PCoIP connection to the Desktop. This occurs over TCP port 4172.
  4. The View Client on the client device and the View Agent on the virtual desktop negotiates the PCoIP session. This happens over several back and forth communications on TCP port 4172.
  5. Once the session has been negotiated, the View Agent initiates a PCoIP data channel connection directly to the View Client. This now occurs over UDP port 4172.
  6. After that initial connection is created, the Control and Data sessions open up between the View Client and the View Agent over UDP port 4172. At this point, a connection to the Desktop is established.
  7. While the PCoIP communications over UDP port 4172 goes on, PCoIP also opens up a heartbeat connection between the Client and the Agent using TCP port 4172.
  8. The Client also opens up a heartbeat connection between itself and the Connection Server. This occurs over TCP port 443. This connection is established so that the Connection Server and View Administrator have some awareness of the current session.

View Connection Server (1 of 7)


The View connection server(s) acts as a broker for client connections. View Connection Servers authenticate users through Windows Active Directory and then assigns a user to the appropriate desktop.  The main functions of a View Connection Server are as follows

  • Authenticating users
  • Entitling users to specific desktops and pools
  • Assigning applications packaged with VMware ThinApp to specific desktops and pools
  • Managing local and remote desktop sessions
  • Establishing secure connections between users and desktops
  • Enabling single sign-on
  • Setting and applying policies


The configuration data is stored in a LDAP directory and is replicated amongst other connection servers.