Citrix

Quick Hit – ICA-TCP#0 and disconnected sessions

2014-09-26
/ / /

If you were to login to a Citrix server with your ID and you get ICA-TCP#0 as your session name, then disconnected your session, went to another computer and logged in (in the Metavision environment you don’t assume the exisiting session — you get a new one) you will actually take that sessionName “ICA-TCP#0” as the disconnected session made it available. If you reconnect to your disconnected session it will update the SessionName variable to ICA-TCP#1.

I bring this up because I was attempting to use this variable in the registry to determine a user’s process list but it fails because of the disconnected session maintaining that same value.

Read More

Citrix Desktop Director “The system is currently unavailable. Please try again or contact your administrator.”

2014-08-27
/ / /

We are attempting to add Citrix Desktop Director to our helpdesk.  We have a geographically spread organization across three cities connected by a huge ring network.  We setup one Desktop Director server and pointed it at two servers in Calgary (WSCTXZDC301 and 302).  We were able to login and all appears good.  We then setup our second Desktop Director server and pointed it to two servers in Edmonton (WSCTXZDC303 and 304).  With this server we were unable to login.  We were getting this error message:

“The system is currently unavailable. Please try again or contact your administrator.”

Well…  That helps.
Step 2 was the reproduce the issue and analyze the log.
So.  It appears there is a timeout and the XenAppCommands is not completing in time.  Is this because something was wrong with our ZDC?  To test this I used Remote-XAPSSession to test the command above in the log (Get-XAServer -OnlineOnly -ZoneName A,B,C).  With powershell remoting I connected to the ZDC 301 and 302 and ran the command and it completed within a second.  I then tried it against 303 and 304 and the command completed in….   17 seconds and 22 seconds.  Far exceeding the 10 second timeout.  Why was it taking so long?  It turns out that the ZDC is forced to contact the database with that command as opposed to utilize the LHC (local host cache).  Procmon shows lots of database communication and our two ZDC’s 303 and 304 are in Edmonton and the database resides in Calgary; communication round-trip makes those ZDC’s exceed 10 seconds.

So…  It turns out that Desktop Director should be pointed at a data collector that sits closest to the database.  If it is too far away you may exceed this timeout and your users will be unable to login.  Unforunately, I am unable to find a way to manipulate this timeout to increase it (even though that will cause poor performance, at least users can actually operate).

Read More

Quick one-liner to change vDisk on devices

2014-07-16
/ / /
Read More

Extend disk space on a VMWare PVS system

2014-07-14
/ / /
 
 

Read More

How To Convert a 16MB block size PVS VHD to a 2MB PVS VHD file using Hyper-V

2014-05-21
/ / /

If you’ve created a 16MB block size VHD file using Citrix PVS you’ve probably experienced that these disks are a touch more difficult to manage than the 2MB ones.  With 16MB block size VHD’s you cannot mount them in Windows natively, compact them, and manipulate them with regular VHD tools.  The only tool that I’ve been able to manipulate them with is PVS, specifically CVHDMOUNT.EXE.  This allows you to mount the VHD file as a hard disk, but even so you cannot manipulate the disk with lots of tools; the disk isn’t recognized at all.  This includes tools like Disk2VHD that you would think would make it easy to make it into a VHD.  Not so.

In order to convert from a 16MB block size PVS VHD you need to do the following steps:

1) Mount the VHD file using CVHDMount.exe (you may need to install the Provisioning Server role on it to get the CVHDMount.exe tools)

2) Go into Disk Management and set your disk to “Offline”

3) Open Hyper-V, right-click your server and go “New > Hard Disk…”

4) Choose the location and filename to save it.

5) Choose to copy from the PHYSICALDISK that corresponds to your VHD you mounted.

6) Click Finish.   And now you’re done!  🙂

Read More

Citrix, Internet Explorer and AppV

2014-04-24
/ / /

I wrote about the issue of Internet Explorer and AppV here before.  Long story short, Citrix changes the iexplorer.exe launch handle to point to its own stub of iexplore.exe.  I suggested changing the iexplore in the registry to point to the proper version of IE, but the Citrix version appears to be a FTA (File Type Association) stub of some sort.  Another solution would be to use the full path to iexplorer.exe (C:\Program Files (x86)\Internet Explorer\iexplore.exe) in the path of the published Citrix application.  This avoids the stub being launched.

Read More

Problems.txt file in Citrix Receiver 4.0/4.1 reports “Error 500”

2014-04-22
/ / /
Make sure you go to the PNA agent web folder on the designated server and set RequireLaunchReference=Off and remove the # in the WebInterface.conf file.

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

Read More

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

2014-04-21
/ / /

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:

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

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

2014-04-18
/ / /

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:

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.

Read More

Install VMWare drivers offline into a Citrix PVS vDisk

2014-02-28
/ / /

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

(e1000e found as our NIC driver)

(we see InterruptThrottleRate as a parameter)

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:

For the VMWare virtual machines we just had the one line:

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:

This mounted the vDisk as drive “D:”

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

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:

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!

 

Read More