Using Sysprep with View

Occasionally it is necessary to use Sysprep instead of Quickprep when creating a desktop pool with View. This usually is because of some legacy software requiring unique local computer identifiers (SIDs). I recently got asked about it because of some older antivirus software that needed it to centrally manage its in-OS agents.

A comparison of the two customization techniques can be found in the View Administration Guide on pages 95 and 96. KB article 2003797 gives a quick table of the differences:

Function	QuickPrep	Sysprep
Removing local accounts	No	Yes
Changing Security Identifiers (SID)	No	Yes
Removing parent from domain	No	Yes
Changing computer name	Yes	Yes
Joining the new instance to the domain	Yes	Yes
Generating new SID	No	Yes
Language, regional settings, date, and time customization	No	Yes
Number of reboots	0	1 (seal & mini-setup)
Requires configuration file and Sysprep	No	Yes

To setup and deploy a pool using Sysprep the high-level steps are as follows:

1. Copy the Sysprep files to the vCenter server (Note that this is only required for Windows XP as Windows 7 comes with sysprep). Full details on this are in KB article 1005593.
2. Create a Guest Customization Specification in vCenter.
3. Add a desktop pool and tell it to use sysprep and the guest customization spec you have created.

Create a Guest Customization Specification

• In vCenter from the Home page select the option for Customization Specification Manager.
• Add a New customization and on the Properties page enter a name. DO NOT use a custom sysprep answer file.

• Continue through the wizard until the Computer Name page. Set this to use the virtual machine name.

• Step through the wizard entering license keys, administrator password, time zone, etc until you get to the Network page.
• Make sure you leave the network at the default of typical settings. This will then use DHCP.

• On the Workgroup or Domain page leave this as the default. Any domain / administrator information entered here is not used. Instead the VM is joined to the domain using the guest customization settings defined in the pool settings through View Manager.

• On the last page Operating System Options make sure that the Generate New Security ID (SID) is checked. After all the whole reason we are using Sysprep is because unique SIDs are required for our use case.

• Finish the wizard.

Add a desktop pool

• In View Manager add a desktop pool as you would normally. The only deviation from using Quickprep comes on the last page for Guest Customization.
• Select the Domain. This list (normally only one in most environments) is what you defined when you configured the vCenter server in View Administrator and defined the Domains for View Composer. This settings is what will control which domain is joined and which credentials are used when customizing the linked clones.
• Select the appropriate AD container as normal.
• Select the option to Use a customization specification (Sysprep) and select the spec you created earlier.

• When you complete the wizard your pool should deploy although provisioning can be a bit slower than using Quickprep especially as there is an additional reboot of the linked clone required.

So what are the steps that take place when View customizes with Sysprep?

1. Once the linked clone disks have been created, View Manager puts the VM into the Customizing state.
2. View Manager calls the vCenter API customizeVM_Task to customize the VM with the customization specifications. 
3. View Manager powers on the linked clone.
4. Inside the Guest OS on the linked clone, the View Composer Agent sees that it is starting for the first time and calls NetJoinDomain with the machine password cached on the internal disk. 
5. The machine is now joined to the domain.
6. Sysprep is now run on the linked clone from within the guest.
7. The  View Composer Agent waits for Sysprep to finish before notifying the View Agent that customization is complete. Then the View Agent sends a message to the View Manager server.
8. The View Manager Server powers off the clone and takes a snapshot of the customized, powered off clone (to give us our refresh state).
9. View Manager puts the linked clone into the Provisioned state. If the VM is then powered on, it moves into the Available state.

Full details of these steps can be found on Andre Leibovici's blog.

Assigning ThinApps by group membership using the SDK

The SDK for ThinApp recently got an update to version 4.7.3 and this prompted me to revisit login scripts I had previously written using thinreg.exe

Download from here: http://communities.vmware.com/community/vmtn/developer/forums/thinapp

The SDK offers lots of advantages over thinreg and will be faster as it does not require Windows to shell out.

The one bit of preparation we need to do is for any desktop going to register ThinApps. With a View environment this is quite straightforward as you can do the following steps to the Master or Parent VM

1. Copy the ThinAppSDK.DLL (from the SDK download) into the Windows\System32 directory
2. In a CMD prompt (with Administrator rights) register the DLL with: REGSVR32.EXE THINAPPSDK.DLL

This now allows us to reference ThinApp objects and carry out different operations on them. Full details on the functions are in the PDF document that comes with the SDK download. The most common operations and the ones I was interested in to replace thinreg.exe are Register and UnRegister. In a VBScript we need the following:

First we need to create an object so we can call the ThinApp commands:
 Set TAManagement = CreateObject("ThinApp.Management")

We also need to create a  variable to hold the Package while we work with it.
 Dim Package

We can now set this variable to the thinapp we are going to work with:
 Set Package = TAManagement.OpenPackage(\\server\share\Adobe Reader 9.exe)

This now allows us to Register a package with: Package.Register 1

And Unregister a package with: Package.UnRegister

I put this together into this login script 
Here's a link to download the login script. just remove the .txt extension to leave this as a .vbs file - https://sites.google.com/site/vkiltblog/view_login_sdk.vbs.txt

Save the text down in a vbs file and add it into the GPO that you should have created and linked to the OU that houses the View desktops. See my previous post on details on setting up a GPO for View: GPO's for View

You may look at the script and ask why I'm not using wildcards, why I'm checking for group membership and why I'm checking for registry entries. The simple answer is to speed up the execution of the login script and provide minimal disruption to the user on login. If we use wildcards or don't check the registry then subsequent registers will always be attempted. This can cause the screen to flash and slow down the login. I prefer to specify the thinapp, the group entitled and the registry key so we don't even attempt a register or unregister if it's not necessary. It also makes unregister's cleaner.

To make this repeatable I put the register and unregister in functions and then defined the variables to call that with.

For each application we define the following:
 ADGroup = "Adobe Reader"
 FileName = "\\server\share\Adobe Reader 9.exe"
 RegKey = "Software\Thinstall\ThinReg\Adobe Reader 9_28503025"
 CheckReg = True
 DebugMsg = False

where:
 ADGroup = The AD Group that is entitled to the app
 FileName = "Full name and path of ThinApped exe"
 RegKey = "Registry Key created when registered under HKCU"
 CheckReg = True or False, where True will check the registry to see if the ThinApp has already been registered
 DebugMsg = True or False, where True will popup message on register or unregister

We can then call the function for each application to either register, unregister or do nothing.
 RegUnRegApp ADGroup, FileName, RegKey, CheckReg, DebugMsg

You can also change the DebugMsg variable to True and you will get a pop up message on each register or unregister. You can also turn off the Registry Check by changing CheckReg to False (this is useful when registering a new application and you don't know what registry key will get created by the register). Note that when we don't check the registry each time a user logs in, we will attempt to either register or unregister based on their group membership every time.

More scripting examples can be found here.

ThinApp SDK Login Script

'===========================================================
'<CUSTOMER> Login Script
'===========================================================

'===========================================================
' Set Environment Variables
'===========================================================
Const HKCR = &H80000000 'HKEY_CLASSES_ROOT
Const HKCU = &H80000001 'HKEY_CURRENT_USER
Const HKLM = &H80000002 'HKEY_LOCAL_MACHINE
Const HKUS = &H80000003 'HKEY_USERS
Const HKCC = &H80000005 'HKEY_CURRENT_CONFIG
Set WSHNetwork = WScript.CreateObject("WScript.Network")
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set objShell = CreateObject("Shell.Application")
Set TAManagement = CreateObject("ThinApp.Management")
Dim ThinAppType, Package, RegKey, CheckReg, DebugMsg


On Error Resume Next

Domain = WSHNetwork.UserDomain
UserName = ""

While UserName = ""
   UserName = WSHNetwork.UserName
   MyGroups = GetGroups(Domain, UserName)
Wend

'===========================================================
'Register ThinApps Based upon Group Membership using the SDK
'===========================================================
'USAGE: RegUnRegApp
'<ADGroup = The AD Group that is entitled to the app>,
'<FileName = "Full name and path of ThinApped exe">,
'<RegKey = "Registry Key created when registered under HKCU">,
'<CheckReg = True or False, where True will check the registry to see if the ThinApp has already been registered>,
'<DebugMsg = True or False, where True will popup message on register or unregister>


'=====================
'Register Adobe Reader
'=====================
ADGroup = "Adobe Reader"
FileName = "\\demo.vmware\data\apps\Adobe Reader 9\Adobe Reader 9.exe"
RegKey = "Software\Thinstall\ThinReg\Adobe Reader 9_28503025"
CheckReg = True
DebugMsg = False
RegUnRegApp ADGroup, FileName, RegKey, CheckReg, DebugMsg

'=====================
'Register Firefox 3
'=====================
ADGroup = "Firefox 3"
FileName = "\\demo.vmware\data\apps\Mozilla Firefox 3\Mozilla Firefox.exe"
RegKey = "Software\Thinstall\ThinReg\Mozilla Firefox 3_80d24cdd"
CheckReg = True
DebugMsg = False
RegUnRegApp ADGroup, FileName, RegKey, CheckReg, DebugMsg

'=====================
'Register Virtual IE 6
'=====================
ADGroup = "VirtIE6"
FileName = "\\demo.vmware\data\apps\VirtIE6\VirtIE6.exe"
RegKey = "Software\Thinstall\ThinReg\VirtIE6_742e9c48"
CheckReg = True
DebugMsg = False
RegUnRegApp ADGroup, FileName, RegKey, CheckReg, DebugMsg

'===========================================================
'Exit Script
'===========================================================
WScript.Quit


'===========================================================
'Subfunctions and Routines
'===========================================================
'===========================================================
'Function: RegUnRegApp - Register or UnRegister a ThinApp
'===========================================================
Function RegUnRegApp(ADGroup, FileName, RegKey, CheckReg, DebugMsg)
   If INGROUP (ADGroup) Then
      If NOT CheckReg Then
         RegisterPackage FileName, DebugMsg
      ElseIf NOT KeyExists(HKCU, RegKey) Then
         RegisterPackage FileName, DebugMsg
      End If
   Else
      If NOT CheckReg Then
         UnRegisterPackage FileName, DebugMsg
      ElseIf KeyExists(HKCU, RegKey) Then
         UnRegisterPackage FileName, DebugMsg
      End If
   End If
End Function

'===========================================================
'Function: RegisterPackage - Register ThinApp
'===========================================================
Function RegisterPackage(FileName, DebugMsg)
   Set Package = TAManagement.OpenPackage(FileName)
   Package.Register 1
   If DebugMsg Then MsgBox Package.InventoryName & " has been registered.", 4160, "ThinApp Registration Check" End If
End Function

'===========================================================
'Function: UnRegisterPackage - UnRegister ThinApp
'===========================================================
Function UnRegisterPackage(FileName, DebugMsg)
   Set Package = TAManagement.OpenPackage(FileName)
   Package.UnRegister
   If DebugMsg Then MsgBox Package.InventoryName & " has been unregistered.", 4160, "ThinApp Unregistration Check" End If
End Function

'===========================================================
'Function: GetGroups
'===========================================================
Function GetGroups(Domain, UserName)
   Set objUser = GetObject("WinNT://" & Domain & "/" & UserName)
   GetGroups=""
   For Each objGroup In objUser.Groups
      GetGroups=GetGroups & "[" & UCase(objGroup.Name) & "]"
   Next
End Function

'===========================================================
'Function: InGroup
'===========================================================
Function InGroup(strGroup)
   InGroup=False
   If InStr(MyGroups,"[" & UCase(strGroup) & "]") Then
      InGroup=True
   End If
End Function


'===========================================================
'Function KeyExists - This method uses WMI to check if a registry key exists
'===========================================================
Function KeyExists(Key, KeyPath)
   Dim oReg: Set oReg = GetObject("winmgmts:!root/default:StdRegProv")
   If oReg.EnumKey(Key, KeyPath, arrSubKeys) = 0 Then
      KeyExists = True
   Else
      KeyExists = False
   End If
End Function

GPO's for View

Best practice is to create a separate OU(s) for the View desktops and create GPOs for the OUs. By default, a user's policy settings come from the set of GPOs that are applied to the user object in Active Directory. However, in the View environment, GPOs should apply to users based on the computer they log in to.  We can enable loopback processing, to make the policy apply to all users that log in to a particular computer, regardless of their location in Active Directory.

To enable loopback on a GPO using the Group Policy Mgt tool on a Domain Controller and open the GPO.

• Expand the Computer Configuration folder and then expand the Administrative Templates, System /Group Policy folders.
• In the right pane, right-click User Group Policy loopback processing mode and select Properties.
• On the Setting tab, select Enabled and then select a loopback processing mode from the Mode drop-down menu.

I normally choose merge as the mode but you can also use replace to completely ignore the users normal GPOs.

• Merge - The user policy settings applied are the combination of those included in both the computer and user GPOs. Where conflicts exist, the computer GPOs take precedence.
•  Replace - The user policy is defined entirely from the GPOs associated with the computer. Any GPOs associated with the user are ignored.

Note that after changing this the View desktop has to apply its computer policy before this takes effect. The easiest and most reliable way is to reboot the OS.

By default I would then add some settings to the User Configuration part of the GPO to disable the Shutdown/ Restart options.

• Expand the User Configuration folder and then expand the Administrative Templates, Start Menu and Taskbar folders and change the following entries:
• Add LogOff to the Start Menu = Enabled
• Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands = Enabled
• Clear the recent programs list for new users = Enabled

There are other setting in the GPO that you may want to look at to remove or lock down the desktop. (Remove Run is a popular one).

Disable HotPlug from virtual desktops

I was talking to a customer yesterday who was running a pilot View environment. One of the questions that came up was how to stop end users right clicking on the remove hardware icon in the system tray and removing the NIC or hard disk. Obviously removing these from linked clones is not a good thing for the user on that desktop.

• Right-click the virtual machine and click Edit Settings.
• Click the Options tab.
• Click General > Configuration Parameters > Add Row.
• Insert a new row with the name devices.hotplug and value false.

I would normally do this to the master VM so all the linked clones have this setting.

There is a VMware KB article covering this (1012225): http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1012225

NIC Selection with vSphere Load Balancing

A customer asked me how the load balancing algorithms worked in vSphere and how even the distribution was with 'Route based in the originating virtual port ID’ which is the default policy. Note that the initial placement policy is also the same for the LBT (Load Based Teaming) policy.


I knew that we could check which pNIC a VM had been assigned to using ESXTOP and pressing n to look at the network info. (Unfortunately my lab where I took this screenshot only has a single NIC)

I went searching for the algorithm that is used to determine which pNIC is selected when a VM powers on and found the following:

Algorithm: (virtualPortID>>1) % numActiveNICs

Or in my basic understanding of maths notation:

pNIC selection = (virtualPortID / 2) modulo numActiveNICs

(modulo =  Given two positive numbers, a (the dividend) and n (the divisor), a modulo can be thought of as the remainder, on division of a by n.)

As an example: A NIC team has vmnic3, vmnic4, vmnic5 (active in this order).

Therefore vmnic3 = 0, vmnic4 = 1, vmnic5 = 2

So if we look at the port-ids on a vSwitch we can use this to work out which pNIC the VM will be assigned to.

/net/portsets/<vswitch>/ports/> ls

    67108865/

    67108873/ ===> 67108873 /2 = 33554436 modulo 3 = 0 (VM will use vmnic3)

    67108874/ ===> 67108874 /2 = 33554437 modulo 3 = 1 (VM will use vmnic4)

Tuning PCoIP

I've been working with a few customers and partners recently on View deployments where we needed to tune PCoIP to particular network scenarios or to cope with limited bandwidth and try and squeeze the best performance out of the available resources. Normally I would start by tuning PCoIP parameters manually using the PCoIP tuning guide but I thought I would document the most common settings and what has worked well for many installations.

The bit to look at in the guide is from page 28 onwards with regard to tuning for the locations or sites with constrained bandwidth: http://www.vmware.com/files/pdf/view/VMware-View-5-PCoIP-Network-Optimization-Guide.pdf

One of the first changes I would have traditionally made was to reduce the frame rate to 15 (you can go considerably lower but test in increments to make sure you are still getting a good user experience) but there are lots more options and considerations that I will cover below.

Back to Basics: Tweak the User Interface Visual Effects

Before we get into tuning the protocol it’s worth starting with the desktop image and ensuring that we are not causing extra screen changes and thus additional traffic.

• Set Visual Effect to Best Performance
• Disable Desktop Wallpaper
• Disable Screen Saver or set it to None
• Revert back to the classic Start menu
• Disable Themes (if possible)
• Disable additional fading
• System icon and text changes
• Disable any unnecessary Windows services - Help and Support, Windows Audio (if you don't need sound), Wireless, Remote Registry (be careful, though: some applications need this service, so make sure you properly test), Error Reporting and any other service that is not needed

A good place to start on this is the Optimization Guide for Windows 7. This will help you tune down the visual effects and also disable unnecessary services that would otherwise consume resources. There are even a couple of attached scripts that you can use to make all the changes for you.

http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf

Using a GPO

There are a few ways that you can change the PCoIP parameters, but to be clear we are going to make these changes on the virtual desktop(s).

1. Use a Group Policy (GPO)

• For local isolated changes to a specific VM, copy this file to c:\windows\inf within the windows VM and implement using your group policy editor.
• Larger deployments can apply the pcoip.adm to an Organizational Unit (OU), or apply the settings to the template prior to deployment

1. Apply the setting directly to the registry.

Usually I would recommend using a GPO applied to an OU. The GPO files are located on the View Connection Server in C:\Program Files\VMware\VMware View\Server\Extras\GroupPolicyFiles. Copy them over to somewhere you can get to from your Group Policy Admin tool and add the ones you need into the group policy you are applying to your desktops.

Edit the Group Policy you want to apply these to and expand the Computer Configuration until you see the Administrative Templates. Right click on it and add in the templates you copied over.

If you want to make the changes directly to the registry of the virtual desktop (the master VM may make more sense), you can do so at the following location in the View desktop:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin_defaults\

PCoIP Tuneable Parameters

Build-to-Lossless - pcoip.enable_build_to_lossless

If you want to maximize bandwidth savings vs. lossless image quality, this gives you the option to disable PCoIP build to lossless in favour of build to perceptual lossless. 

When BTL is disabled, PCoIP rapidly builds the client image to a high quality, but lossy image. By default, if the image remains constant, PCoIP would continue to refine the image in the background until it reaches a fully lossless state. Stopping the build process when the image reaches the "perceptually lossless" stage can deliver significant bandwidth savings -- for typical office workflows, we are seeing around a 30% bandwidth reduction.

Be careful when disabling Build-to-Lossless if your users require high image quality or there is a need to provide lossless imaging (e.g. medical, graphic design).

PCoIP Network Parameters

Maximum PCoIP Session Bandwidth (Kbps) - pcoip.max_link_rate

Specifies the maximum bandwidth, in kilobits per second, in a PCoIP session. The bandwidth includes all imaging, audio, virtual channel, USB, and control PCoIP traffic.

When this setting is disabled or not configured on an endpoint, the endpoint imposes no bandwidth constraints. When this setting is configured, the setting is used as the endpoint's maximum bandwidth constraint in kilobits per second.

• Set the maximum bandwidth on a user to prevent them from impeding other users productivity.
• Be careful not to set too low since the ability to peak is key to desktop performance

• Setting applies to the soft host only.
• Value is in Kbps
• Ranges between 100 and 1,000,000; and must be set in increments of 100
• Default value is 900,000.
• Setting to 0 = no bandwidth constraints

PCoIP Session Bandwidth Floor (Kbps) - pcoip.device_bandwidth_floor

This setting determines the lower bound PCoIP will throttle down to when bandwidth is required but there is congestion detected on the network. PCoIP will still concede bandwidth below this value when it is not needed. The default value is 0, which means that no minimum bandwidth is reserved.

PCoIP session MTU (bytes) - pcoip.mtu_size

Typically, you do not have to change the MTU size. Only change this value if are seeing packet fragmentation due to VPN or other encapsulation.  This setting applies to the server and client. If the two endpoints have different MTU size settings, the lowest size is used.

If this setting is disabled or not configured, the client uses the default value of 1300 bytes in the negotiation with the server.

PCoIP Image Quality Levels

Minimum Image Quality (30-100) - pcoip.minimum_image_quality

This determines the lower bounds of image quality “compression” when network congestion triggers increased build-to-lossless.

The default value here is 50 (from a range of 30 to 100) and in most deployments this value has worked well.

Use this to balance image quality and frame rate for limited-bandwidth scenarios. A lower value allows higher frame-rates, but with a potentially lower quality display. A higher value provides higher image quality, but with potentially lower frame rates when network bandwidth is constrained. When network bandwidth is not constrained, PCoIP maintains maximum quality regardless of this value. Find a good medium that works for you.

Maximum Initial Image Quality (30-100) - pcoip.maximum_initial_image_quality

A lower bound on the image quality that PCoIP tries to deliver “immediately” when screen updates occur. The higher this setting the more “pixel perfect” initial screen updates will be at the cost of higher bandwidth peaks.

The range is 30 to 100 and the default value is 90. In most deployments, values have varied between 70 and 90. This setting behaves as follows:

·         A higher initial image quality means that larger bandwidth bursts will be used when refreshing or updating a larger end-user screen change

·         A lower initial image quality means that less bandwidth bursts will be used when refreshing or updating a larger end-user screen change:

Maximum Frame Rate (1-120) - pcoip.maximum_frame_rate

This setting determines the maximum frequency of client screen updates. Lower values will reduce bandwidth when there are high rates of motion that need to be rendered.

·         A higher value can use more bandwidth but provides less jitter, which allows smoother transitions in changing images such as video.

·         A lower value uses less bandwidth but results in more jitter.

The default value is 30, but you could safely drop this to 15 unless you need an HD movie experience. This setting deals with the frequency of frames, or how many frames per second at which your end-user screen refreshes. Of course, the higher the rate the better the experience; the lower the rate the less data you send across the wire. So, be sure to test:

Audio

PCoIP Audio Policy (1/0) - pcoip.enable_audio

Determines whether audio is enabled in PCoIP sessions. Unless audio is explicitly needed, this setting should be disabled to save significant bandwidth and improve the user experience:

PCoIP Session Audio Bandwidth Limit (Kbps) - pcoip.audio_bandwidth_limit

This setting will limit the maximum bandwidth that audio traffic can consume. PCoIP can still dynamically adjust this setting down based upon current network conditions. Setting this value below 50Kbps may result in no audio being transmitted at all.

PCoIP Encryption Algorithm (1/0)

pcoip.enable_salsa20_256_round12

pcoip.enable_aes128

Some have had better performance setting this to Salsa256 than to AES128, but be sure to run your own tests and validate:

Client-side Cache - pcoip.image_cache_size_mb

This allows you to configure the PCoIP client image cache size (default of 250MB). The client uses image caching to store portions of the display that were previously transmitted and reduce the amount of data that is retransmitted (min 50 MB to a max of 300 MB.)

Network Best Practice

• PCoIP is a real-time protocol so ensure that it gets proper QoS/CoS classification
• Classify PCoIP traffic as real-time interactive, typically just below VoIP
• Insure that QoS/CoS mappings are preserved across WAN links
• Utilize the View Security Server for remote access as it is the most efficient remote access solution.
• If you must use VPN, avoid SSL-based solutions. Use IPSEC, L2TP/IPSEC, GRE, DTLS VPN solution that support UDP tunnelling.
• Insure that PCoIP is bypassed on all WAN acceleration devices.
• Insure that PCoIP is bypassed or trusted on any IDS/IPS devices in the network path and in endpoint protection software.
• Prefer fixed bandwidth WAN circuits over “burstable” circuits. Make sure you understand your use case well and perform accurate measurements to allow for proper circuit sizing.
• If you must use “burstable” circuits insure that the CIR is high enough to cover all existing high priority traffic and the total average traffic for all PCoIP sessions.
• PCoIP may see high packet loss when it consumes burst bandwidth.
• Carriers tag burst packets as “out of contract” and low priority.
• May artificially limit the total bandwidth PCoIP “sees” across the circuit.
• Utilize WRED for congestion avoidance:
• Avoid tail-drop.
• Do not configure WRED on the physical interface as it will override all other QoS policies.
•  Avoid use cases where round-trip latency is greater than 300ms.
• Do not utilize per-packet load balancing as this will cause out of order packet delivery leading to PCoIP perceived packet loss.
• Insure that affinity or session “stickiness” is enabled.

PCoIP Tuning Guidelines

• Disable Build-to-lossless
• First and easiest way to shave 10-15% bandwidth.
• Only enable when there is a defined requirement for pixel perfect accuracy (Medical, CAD/CAM, Graphic Design)
•  Configure the maximum session bandwidth
• For low bandwidth links set the limit at or slightly below (10%) the maximum link rate.
• Even on the LAN it may make sense to apply a limit.
•  Configure the session floor when:
• PCoIP is experiencing packet loss but the network link has plenty of headroom
• May not always improve user experience
• Packet loss is seen on WiFi or 3/4G networks
• Be careful to avoid unintentional oversaturation
• Configure the maximum frame rate
• In almost all cases the maximum frame rate can be reduced to 18-20fps with little noticeable impact.
• Settings below 15fps may be noticeable in use cases which require rich media
• Task workers without media requirements can often utilize settings as low as 6-8fps without significant visual impact
• Examine the PCoIP Server log files and WMI Image stats to determine average frame rate for desired use case:
• Configure the maximum initial image quality
• When on a WAN link with constrained bandwidth reduce this setting to 60-70%
• For use cases that use large amounts of multimedia/video – large impact
• Setting this value too low may result in noticeably “fuzzy” or “blurry” images
• Configure the minimum image quality:
• This value must be below the maximum initial image quality setting
• The default value of 50% is acceptable for most cases
•  Configure the audio bandwidth limit:
• For use cases that utilize significant amounts of audio - legal/medical transcription for example – reducing audio bandwidth may increase user density
• Audio bandwidth limit is a target, not a literal value
• Vary the audio bandwidth limit between 450Kbps – 50Kbps until the desired mix of bandwidth savings and audio intelligibility is achieved
•  Configure the Client-side cache size:
• When using thin client devices with limited RAM using a larger cache size than the device can support may lead to dropped sessions
• Reduce the cache size until connections are unaffected, typically 50-100MB

Summary

• Always start with the basics before resorting to PCoIP tuning
• Majority of PCoIP issues are external to the protocol
• Optimize VDI Base image
• Insure proper implementation of network configuration QoS/CoS, UDP tunneling through VPN, etc.
• Proper network sizing for desired use case.
• Utilize the information in the PCoIP logs and real-time WMI counters to determine where the trouble spots are:
• Determine proper settings to adjust:
• Vary one item at a time, make as few changes as possible
• Test, test, and re-test against the intended use case. Utilize a repeatable set of user actions and/or a scripted set of actions to validate the impact of changes

PCoIP Ports and Traffic

[EDIT] I've updated this for View 5.1 which made one change in that the Security Servers and Connection Servers instances negotiate IPSec and respond on UDP 500. (I also made a typo on the USB port).

I’ve been asked by a few people recently what ports need to be opened between different components in a View environment using PCoIP.

All of this information is avaliable in the View Architecture Planning Guide but I have found it useful to boil this down to a couple of simple diagrams.

http://pubs.vmware.com/view-51/topic/com.vmware.ICbase/PDF/view-51-architecture-planning.pdf#page=66

Internal LAN connections.

External Clients connecting through a PCoIP gateway.

Speeding Up Provisioning Linked Clones in View 5.1

I’m not going to go into detail on why changing the way that View provisions and creates linked clones with Composer is a good idea. If you are running on recent hardware with a well designed solution that provides good disk I/O you can benefit from increasing the number of operations Composer will do concurrently.

Wayne over on IT Blood Pressure covered this for View 5.0 in a Feb blog.

There is information on this is the Best Practices Whitepaper and instruction  on how to change the setting in View 5.0 and previous versions in KB article 1013760

What’s new is that changing this has become easier with View 5.1 as the setting for pae-SVICreationRampFactor can now be made through the View Administrator GUI

Under View Configuration and Servers, Edit your vCenter Server Settings. If you press Edit on the vCenter Server Settings box that appears you will get the following dialog. Change the last setting to increase the provisioning operations concurrency and speed up certain operations.

Change this in increments, test the effect and only do this if your hardware (and Composer) configuration can cope.