Home > Blogs > VMware Consulting Blog > Tag Archives: PCOIP

Tag Archives: PCOIP

Control-Alt-Delete in the World of VDI

by Mike Erb

When I was still working as an Escalation Engineer for VMware® Global Support, there was a time-honored tradition among the Broomfield center’s EUC support group: If you left your computer unlocked and walked out of eyesight, you’d always come back to a surprise.  The HR folks would probably be unhappy at such an unauthorized use, but a quick flip of the screen with Ctrl-Alt-Up and a dash back to your desk, leaving their display inverted and the surrounding engineers glancing over for the inevitable reaction, was worth the risk.

Continue reading

VMware Horizon View Secret Weapon

Andreas LambrechtBy Andreas Lambrecht

Over the last couple of years, I have worked on many challenging Horizon View projects with different business, technical and security requirements. Finding the balance between these points is not always easy. During design workshops and the discussions with desktop management teams and security departments the following questions come up over and over again:

“How can we apply different settings (e.g., clip boards, redirection, printing, etc.) to the user session or desktop based on the user’s location?”

“How can we apply PCoIP optimization to the user session or desktop based on the user’s location?”

Note that these can be internal (LAN or office) or external (Internet or home office) connections.

From the Horizon View architecture point of view we can create different desktop pools with different hardening policies and PCoIP settings, but this means the user will have two different virtual desktops: one for internal and one for external. This may not be optimal in terms of the end user experience because they expect the same virtual desktop behavior in both working environments; when they disconnect the session in the office they expect to continue working on the same document from home without encountering issues. And here is the challenge: ensuring a positive end user experience vs. security policies/PCoIP optimization.

After some research on this particular use case I found a way to manage this requirement without additional costs – while using out-of-the-box Horizon View features. This service comes with the Horizon View Agent as a standard feature and offers many capabilities. I call it the Horizon View Secret Weapon.

Let’s take a closer look at what this secret weapon looks like and what it offers. There are three main ingredients:

  1. VMware Horizon View Script Host Service
  2. System information sent to View Desktop upon user connect or reconnect.
  3. Start Session Script. But note, the intelligence of this script depends on the use case, the security requirements and the ingenuity of the script owner.

Official recommendation: Use start session scripts only if you have a particular need to configure desktop policies before a desktop session begins. As a best practice, use the View Agents CommandsToRunOnConnect and CommandsToRunOnReconnect group policy settings to run command scripts after a desktop session is connected or reconnected. Running scripts within a desktop session will satisfy most use cases. For details, see “Running Commands on View Desktops” in the View Administration document.

For some requirements you can use the View Agents CommandsToRunOnConnect and

CommandsToRunOnReconnect group policy settings, as mentioned above. But what if this is a computer setting or view desktops setting that needs to be configured before the desktop session starts, e.g., PCoIP optimization, clipboard redirection, etc. This is where the secret weapon kicks in and can help fulfill this requirement.

Note: To apply PCoIP optimization there is no need to reconnect because these settings are set before the session or PCoIP protocol start.

In this example I would like to cover a use case with the following technical requirements.

Internal connect

Clipboard redirection:

  • Enabled in both directions

PCoIP settings:

  • BTL set to off
  • Maximum image quality 80
  • Minimum image quality 40
  • Maximum frames per seconds 20

PCoIP Audio limit:

  • 250 kbit/s

USB access:

  • Enabled


  • Enabled

External connect

Clipboard redirection:

  • Disabled in both directions

PCoIP setting:

  • BTL set to off
  • Maximum image quality 70
  • Minimum image quality 30
  • Maximum frames per seconds 16

PCoIP Audio limit:

  • 50 kbits/s

USB access:

  • Disabled


  • Disabled

First, we must enable the VMware Horizon View Script Host Service on each View Desktop where we want View to run the start session script (e.g., on the base image for a Linked Clone Pool). The service is disabled by default.

To configure the VMware View Script Host Service:

  1. Start the Windows Services tool by entering msc in the command prompt.
  2. In the details pane, right-click on the VMware View Script Host service entry and select Properties.
  3. On the General tab, in Startup type, select Automatic.
  4. If you do not want the local system account to run the start session script, select This account, and enter the details of the account to run the start session script.
  5. Click OK and exit the Services tool.

ALambrecht 1
For more details see “Dynamically Setting Desktop Policies with Start Session Scripts.“

Now we need to find a way to differentiate between an internal and external connection. Here we can draw on the information the Horizon View client has gathered about the client system when a user connects or reconnects to the View Desktop, or we can use the values sent directly from the View Connection Server. This can be any variable from the list (see link below) but I would recommend using ViewClient_Broker_DNS_Name. The reason for this choice is simple: if the user connects from the outside (external connect) the authentication will be managed by the View Connection Server that is paired with the View Security Server. But keep an important View Architecture rule in mind; the View Connection Server paired with the View Security Server should be used exclusively for external connections.

For more details see “Client System Information Sent to View Desktops.”

Important note: The start session variables have the prefix VDM_StartSession_ instead of ViewClient_. This is important for our scripts and is described below.

We are now at the point where we need to talk about the most important ingredient of the secret weapon. But before we start writing the script we need to set some registry values to make the start session script available for execution.

  1. Start the Windows Registry Editor by entering regedit at the command prompt.
  2. In the registry, navigate to HKLM\SOFTWARE\VMware, Inc.\VMware VDM\ScriptEvents.
  3. Edit > Select New > Key, and create a key named StartSession.
  4. In the navigation area, right-click StartSession, select New > String Value, and create a string value (REG_SZ) “Bullet1” and at the command line enter (wscript C:\Program Files\VMware\VMware View\Agent\scripts\bullet1.vbs) .
  5. This will invoke the start session script. Click OK.

Note: As a best practice, place the start session scripts in the following location: %ProgramFiles%\VMware\VMware View\Agent\scripts. By default, this folder is accessible only by the SYSTEM and administrator accounts.

ALambrecht 2

  1. Navigate to HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Agent\Configuration.
  2. Edit > Select New > DWord (32 bit) Value, and type RunScriptsOnStartSession and type 1 to enable start session scripting.

ALambrecht 3

  1. Navigate to HKLM\SOFTWARE\VMware, Inc.\VMware VDM\ScriptEvents.
  2. Add a DWord value called TimeoutsInMinutes.
  3. Set a data value of 0.

ALambrecht 4

For more details see “Add Windows Registry Entries for a Start Session Script.”

Here is a simple script example which covers the technical requirements of this use case.


‘ This script dynamically applies specific session settings based on

‘ the user location.

‘ Author: Andreas Lambrecht VMware PSO CEMEA.

‘ Date: October 2015


Option Explicit

On Error Resume Next


Dim objShell

Dim WshShell

Dim objWMIService

Dim strComputer

Dim colServiceList

Dim objService

Dim WScript


strComputer = “.”

Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

Set objShell = CreateObject(“WScript.Shell”)


‘ Check to see if the user was authenticated and has assigned the session

‘ by the “external” View Connection Servers, which is paired with

‘ View Security Server or by the “internal” View Connection Server.

‘ Based on the result this script will set appropriate settings.


If objShell.ExpandEnvironmentStrings(“%VDM_StartSession_Broker_DNS_Name%”)=”NAMEOFYOURCONNECTIONSERVER1″ Or objShell.ExpandEnvironmentStrings(“%VDM_StartSession_Broker_DNS_Name%”) = “NAMEOFYOURCONNECTIONSERVER2” Then


‘ Apply the settings for external connect

‘ – Stop and disable TP Auto Connect Service and TP VC Gateway Service

‘ – Disable enable_build_to_lossless

‘ – Set minimum_image_quality to 30

‘ – Set maximum_initial_image_quality to 70

‘ – Set maximum_frame_rate to 12

‘ – Disable Use image settings from Zero client, if available

‘ – Disable server_clipboard_state in both directions

‘ – Set audio_bandwidth_limit to 80

‘ – Exclude all USB devices


Set colServiceList = objWMIService.ExecQuery _

(“Select * from Win32_Service where Name = ‘TPAutoConnSvc’ OR Name = ‘TPVCGateway'”)


For Each objService in colServiceList

If objService.State = “Running” Then



Wscript.Sleep 5000

End If

Set WshShell = CreateObject( “WScript.Shell” )

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.enable_build_to_lossless”, 0, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.minimum_image_quality”, 30, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.maximum_initial_image_quality”, 70, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.maximum_frame_rate”, 12, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.use_client_img_settings”, 0, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.server_clipboard_state”, 0, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.audio_bandwidth_limit”, 80, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\VMware, Inc.\VMware VDM\Agent\USB\ExcludeAllDevices”, “true”, “REG_SZ”

Set WshShell = Nothing




‘ Apply the settings for internal connect

‘ – Start and enable TP Auto Connect Service and TP VC Gateway Service

‘ – Disable enable_build_to_lossless

‘ – Set minimum_image_quality to 40

‘ – Set maximum_initial_image_quality to 80

‘ – Set maximum_frame_rate to 20

‘ – Disable Use image settings from Zero client, if available

‘ – Enable server_clipboard_state in both directions

‘ – Set audio_bandwidth_limit to 250

‘ – Disable Exclude all USB devices


Set colServiceList = objWMIService.ExecQuery _

(“Select * from Win32_Service where Name = ‘TPAutoConnSvc’ OR Name = ‘TPVCGateway'”)

For Each objService in colServiceList

If objService.State = “Stopped” Then



Wscript.Sleep 5000

End If

Set WshShell = CreateObject( “WScript.Shell” )

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.enable_build_to_lossless”, 0, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.minimum_image_quality”, 40, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.maximum_initial_image_quality”, 80, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.maximum_frame_rate”, 20, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.use_client_img_settings”, 0, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.server_clipboard_state”, 1, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin\pcoip.audio_bandwidth_limit”, 250, “REG_DWORD”

WshShell.RegWrite “HKLM\SOFTWARE\Policies\VMware, Inc.\VMware VDM\Agent\USB\ExcludeAllDevices”, “false”, “REG_SZ”

Set WshShell = Nothing


End If


Now the secret weapon is ready for use.

Once the secret weapon is implemented and is running, we need to validate whether the specified settings were applied accordingly.

There are four places where we can check the functionality of our solution:

  1. VDM Debug log for StartSessionScript

ALambrecht 5

In the red rectangle we can see that the Start Session Script was sucessfully applied before the PCoIP protocol starts.

For more details see “Location of VMware View log files (1027744).“

  1. PCoIP Server log for PCoIP optimization

ALambrecht 6

In this red rectangle was can see the PCoIP optimization for external connect, as specified in the script.

For more details see “Location of VMware View log files (1027744).“

  1. Management Tools > Services.exe for ThinPrint settings

ALambrecht 7

Here we can see that the ThinPrint services have been stopped and disabled, and the user is no longer able to print.

  1. Registry.exe for USB Access, PCoIP Optimization and Clipboard redirection

ALambrecht 8


ALambrecht 9

Finally we can see that all settings were applied as specified by the secret weapon.


Andreas Lambrecht is an experienced senior consultant and architect for VMware’s Professional Services Organization specializing in the EUC space. He has worked at VMware for the past 4 years with more than 15 years of experience in the IT industry. Andreas is certified VCP-DCV, VCP-DT, VCAP-DTA VCAP-DTD and also owns the ITIL v4 Foundation certification.

Perform Proactive Load Testing to Build a Successful Environment

Hans BaderBy Hans Bader

So, your company has bought a new set of hardware, referenced the latest white papers and reference architectures, and now will get the virtual machine (VM) densities promised, right? Well, maybe not. White papers and reference architectures are great starting points for designing and building your environment, but unless you are running the same workloads, your mileage may vary. The key to knowing what your infrastructure will support is to proactively perform load testing – before going into production.

Successful load testing is a considerable amount of work; it involves creating synthetic workloads, and understanding the metrics and the impact on the end-user experience. Holistic load testing will bring in different teams: storage, networking, compute, application development, software distribution and virtual infrastructure. Each of these teams has a stake in ensuring a good end-user experience.

Manage, Understand, and Set Expectations

Understand that the performance of a virtual desktop is all about the performance the end user (your customer) is seeing and perceiving. Gathering all the metrics from VMware vCenterTM, PCOIP logs and storage IOPS are all important, but ultimately it is the end-user’s perception and experience that is most important. It is easy for an administrator to say, “The VM has 2 GB out of 4 GB of memory free,” but if the user is experiencing poor performance due to network contention, the end user is still unhappy.

You must set the proper expectations and understand what you can test. Generating CPU and memory load inside the guest is relatively easy with tools such as Iometer. Iometer does a great job of generating compute load, but does not provide any user experience metrics. With remote desktops the challenge becomes testing PCOIP and client-desktop communication.

Have Your Plan in Place

Have your testing methodology, objectives and metrics documented in advance. It is important to develop your test design before starting the actual load testing process. Think it through completely; map the information flow for the entire load test process, entry points and process dependencies. If you are going to create a view pool of 1,000 desktops, will the LAN segment where you will be creating the desktop have enough IP addresses available? Do you know that anti-virus updates are a known pain point? Include these in your testing scenarios. Also include software updates if applicable.

Understand what is going to be tested and how the testing will impact end users. The end-user experience with virtual machines is more than just performance graphs of the VM in your vCenter inventory. Are you testing a local install of Microsoft Word, or a larger client-server based application? Many of the applications running in a virtual desktop are dependent on systems (databases, web services, etc.) that exist outside the desktop. Do you have an information flow diagram that shows all the systems an application may interact with? Do you know where the choke points are? Adequate desktop resources are not sufficient if you are load testing 1,000 desktops running a CRM application – but the environment can only scale to 750 users.

Your End Users Can Help You

During testing do not rely solely upon metrics: your testing must include “eyes on the glass.” Have actual users run through the test scenarios to understand how—as the load increases—the user experience may be impacted. An end user can establish what a good baseline is, what acceptable performance is, and when the end-user experience starts to degrade. These subjective user perceptions can be roughly mapped to network metrics, storage latency or memory usage.

Documented Test Plans

Leverage existing test plans where possible. Many times there are existing test plans for applications that have been developed in-house. These are company- specific and require domain subject matter experts to create and execute on. Utilizing these people can decrease the time and effort required to create and document your current test plans.

Test What is Real

This very important concept is often overlooked. Don’t simply consider CPU and memory consumption of a virtual machine. Running CPU Busy and generating 100 percent CPU usage inside a VM is not realistic. To generate accurate user experience loads you must use appropriate tools, such as:

Proper load testing of your new environment means testing both your architectural and physical designs. It is important to understand how the user load may impact your initial physical design. The number of hosts per cluster, desktops deployed per data store, and network connectivity all come into play. You may find you have been overly conservative in your resource assumptions; but you can change your cluster sizing and therefore obtain greater desktop densities.

During your load testing, use this time to understand the impact on typical administrative tasks while running the hosts. For example, how long does it take to spin up a new pool of 500 desktops when you are running a load test with 1,000 desktops? Or how long does it take to put a host in maintenance mode when it has 80 desktops running? The outcomes of these ancillary tests may change the way you administer your environment.

Expose the Weak Links

What if, during your load testing, you break something? Perhaps you’ll run out of DHCP addresses, the KMS server and your hosts start swapping, LUNS run out of space, and VMs crash. These events should not be considered failures, but rather successful tests. These events show you where to focus attention prior to the next load test so real users do not experience these problems during live operations. Yes, load testing can be a lot of work, and take a considerable amount of effort to do effectively, but the end results are worth it: end users and administrators are happy.

Plan for Remediation

Exposing a weak link during load testing is not a failure, but a positive result. You should ensure your testing plan has time built in to address any weaknesses that are uncovered or that you may have time to test again. The amount of time that has to be added depends on the amount of load that broke the system. If load testing early on with fewer users exposed a lack of DHCP addresses this is a relatively easy fix to a DHCP scope. On the other hand, if testing at full predicted load uncovered a storage performance bottleneck, the time to procure additional storage, install and configure could be much longer.

Testing Scenarios

Your first fully automated test should be a single system test—a single test to ensure your test plan runs through to completion. With no resource contention and no over-commitment on the hosts, this is your baseline. This should also be correlated with an actual user single system test, ensuring the user experience is what is expected.

For the second test, ramp up to 50 percent of what the calculated capacity is. This gives enough wiggle room so you can determine if your design assumptions are accurate. Do you have enough IP addresses? Is storage able to keep up? How are the memory stats?

Run a third test at 100 percent calculated capacity. This is where getting real users into the system is critical. How long does it take to login? Are the test scenarios within the acceptable parameters? Is the user experience acceptable? Have you met all your design criteria and business requirements?

Finally, a fourth test at more than 100 percent expected capacity should be run. Add more desktops, start a full anti-virus scan, perform a software update. No matter how well we design, we always have to plan for the worst-case scenarios. The unexpected removal of a host from a cluster dramatically impacts capacity. Put a host in maintenance mode or reboot it without putting it in maintenance mode. How does your environment perform under these extreme conditions?

“We must contemplate some extremely unpleasant possibilities, just because we want to avoid them.”

– Albert Wohlstetter, American nuclear strategist, 1960

For more information, be sure to check out the following VMware Education Courses:

Hans Bader Consulting Architect, VMware EUC. Hans has over 20 years of IT experience and joined VMware in 2009. With a focus on helping organizations being operationally ready, he works with customers to avoid common mistakes. He is a strong advocate for proactive load testing of environment before allowing users access. Hans has won numerous consulting awards within VMware.