Slow screen refresh with Citrix Receiver 4.0 or 4.1 with old Citrix Farms

I was having an issue with very slow screen redraws with Citrix Receiver 4.1 with a MetaFrame 4.5 farm (although I've read online it's applicable to Presentation Server 4.0).  The fix is to enable the following registry key:


:Fix for slow graphics performance on Legacy Farm
IF '%PROCESSOR_ARCHITECTURE%'=='x86' (
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Seamless Windows" /v DeferredUpdateMode /d False /f
) ELSE (
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Virtual Channels\Seamless Windows" /v DeferredUpdateMode /d False /f
)

Adding that key resolved the issue and now Citrix Receiver 4.1 now updates correctly on the 4.5 farm.

EdgeSight Load Testing with a Single User account (XenApp 6.5)

I've been doing some EdgeSight Load Testing with XenApp 6.5; which I haven't done in a few months.  We have updated our Citrix servers since then with the newer HotFix RollUp (HFRU) pack and now I'm testing a new application.  Our typical setup is to use a single generic account and connect it via multiple sessions to the same Citrix server and capture some metrics (CPU, Network, Memory, etc).  In the past, this seemed to work pretty flawlessly but in the last week I was having issues.  By the time the 3rd session was connecting to the Citrix server, instead of creating a new session it would 'steal' the 1st session.  This prevented me from having more than 2 sessions connected to a server.

Well, it turns out Citrix modified their behaviour a bit but allowed a registry key to be set to change it back.  The new value was introduced in HFRU 2 and is as follows:

http://support.citrix.com/article/CTX136248

On Windows Server 2003, you can specify whether a user can reconnect to a session from any client device or only from the originating client. The From originating client only option is not present anymore in the Remote Desktop Services settings of the Windows Server 2008 R2 edition.
This feature enhancement allows you to implement the same functionality on Windows Server 2008 R2 through XenApp. To enable the feature, you must set the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Citrix
Name: ReconnectSame
Type: REG_DWORD
Data: 1
Note that if Workspace Control is enabled on the Web Interface, enabling the "Automatically reconnect to sessions when users log on" feature can result in side effects and users might have to launch the session twice to open a session from the non-originating client device.

Enabling that registry key and I can immediately restart my load testing without any stolen sessions.

Move ALL Windows 7/2008/2012 log files to another drive

# ===========================================================================================================
#
# Created by: Trentent Tye
#        Intel Server Team
#        IBM Canada Ltd.
#
# Creation Date: Apr 10, 2014
#
# File Name: Move-Log-Files.ps1
#
# Description: This script will be used to move all the log files from the default SYSTEMDRIVE to
#                   a drive of your choosing (in this case, D:\EventLogs).  We use this for non-persistent
#                   vDisks with a persistent write cache to keep these logs for troubleshooting purposes.
#
# ===========================================================================================================


# Change D:\EventLogs to some other destination if required.
$allLogs = Get-WinEvent -ListLog *
foreach ($logs in $allLogs) {
$filename = split-path $logs.LogFilePath -leaf
$logs.LogFilePath = “D:\EventLogs\$filename”
$logs.SaveChanges()
}

Install VMWare drivers offline into a Citrix PVS vDisk

I am attempting to disable interrupt coalescing for some testing that we are doing with a latency sensitive application and I have 2 VMWare virtual machines configured as such that work as expected.

The latency settings I have done are here:
http://www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf

Essentially, we turned off interrupt coalescing on the physical NIC by doing the following:
Logging into the ESXi host with SSH
# esxcli network nic list 
(e1000e found as our NIC driver)

# esxcli system module parameters list -m e1000e
(we see InterruptThrottleRate as a parameter)
# esxcli system module parameters set -m e1000e -p "InterruptThrottleRate=0" 

Then we modified the VMWare virtual machines with these commands:
To do so through the vSphere Client, go to VM Settings  Options tab  Advanced General  Configuration
Parameters and add an entry for ethernetX.coalescingScheme with the value of "disabled"

We have 2 NIC's assigned to each of our PVS VM's.  One NIC is dedicated for the provisioning traffic and one for access to the rest of the network.  So I had to add 2 lines to my configuration:
ethernet0.coalescingScheme = disabled
ethernet1.coalescingScheme = disabled

For the VMWare virtual machines we just had the one line:
ethernet0.coalescingScheme = disabled


Upon powering up the VMWare virtual machines, the per packet latency dropped signficantly and our application was much more responsive.

Unfortunately, even with the settings being identical on the VMWare virtual machines and the Citrix PVS image, the PVS image will not disable interrupt coalescing, consistently showing our packets as have higher latency.  We built the vDisk image a couple years ago (~2011) and the vDisk now has outdated drivers that I suspect may be the issue.  The VMWare machines have a VMNET3 driver from August of 2013 and our PVS vDisk has a VMNET3 driver from March 2011.

To test if a newer driver would help, I did not want to reverse image the vDisk image as that is such a pain in the ass.  So I tried something else.  I made a new maintenance version of the vDisk and then mounted it on the PVS server:
C:\Users\svc_ctxinstall>"C:\Program Files\Citrix\Provisioning Services\CVhdMount.exe" -p 1 X:\vDisks-XenApp\XenApp65Tn01.14.avhd

This mounted the vDisk as drive "D:\"

I then took the newer driver from the VMWare virtual machine and injected it into the vDisk:

C:\Users\svc_ctxinstall>dism /image:D:\ /add-driver /driver:"C:\Program Files\VMware\VMware Tools\Drivers\vmxnet3"

I could see my newer driver installed alongside the existing driver:
Published Name : oem57.inf
Original File Name : vmxnet3ndis6.inf
Inbox : No
Class Name : Net
Provider Name : VMware, Inc.
Date : 08/28/2012
Version : 1.3.11.0

Published Name : oem6.inf
Original File Name : vmmouse.inf
Inbox : No
Class Name : Mouse
Provider Name : VMware, Inc.
Date : 11/17/2009
Version : 12.4.0.6

Published Name : oem7.inf
Original File Name : vmaudio.inf
Inbox : No
Class Name : MEDIA
Provider Name : VMware
Date : 04/21/2009
Version : 5.10.0.3506

Published Name : oem9.inf
Original File Name : vmxnet3ndis6.inf
Inbox : No
Class Name : Net
Provider Name : VMware, Inc.
Date : 11/22/2011
Version : 1.2.24.0

Then unmount the vDisk:
C:\Users\svc_ctxinstall>"C:\Program Files\Citrix\Provisioning Services\CVhdMount.exe" -u 1

I then set the vDisk to maintenance mode, set my PVS target device as maintenance and booted it up.  When I checked device manager I saw that the driver version was still 1.2.24.0

But clicking "Update Driver..." updated our production NIC to the newer version.  I chose "Search automatically and it found the newer, injected driver.  I then rebooted the VM and success!

Time how long a WMI filter call takes

The following command will time how long a WMI filter call will take to execute on your server/PC.

$query = "Select * from Win32_Processor where AddressWidth = '32'"
Measure-Command { Get-WmiObject -Query $query }