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:


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

IMA Service Fails with the Following Events: 3989, 3634, 3614

/ / /

We have run into an issue where we have Provisioning Service 6.1 and XenApp 6.5 working together. After we update the vDisk (say, for Windows Update) we run through a script that does things like the “XenApp Prep” to allow the XenApp 6.5 ready for imaging. It appears that there is a bug in the XenApp Prep that sometimes causes it to not fully get XenApp 6.5 ready for rejoining the farm. The initial symptoms I found were:

Event ID 4003
“The Citrix Independent Management Architecture service is exiting. The XenApp Server Configuration tool has not been run on this server.”

I found this CTX article about it, but nothing of it was applicable.

I did procmon traces and I found the following registry keys were missing on the bad system:

A broken system missing the Status Registry key

A working system with the Status key. Note Joined is “0”

After adding the Status Registry key:

I tried restarting the service and the progress bar got further but then still quit. Procmon showed me this:

That is ACCESS DENIED when trying to see that registry key. It turns out that the IMAService does not have appropriate permissions to read this key. The Magic Permissions on a working box and what you need to set here looks like this:

Notice that none of the permissions are inherited and “NETWORK SERVICE” is added with full control to this key. Now when we try and start the Citrix Independent Management Architecture service we get the following errors:

To correct these errors the local host cache needs to be rebuilt. To fix that we need to run:
Dsmaint recreatelhc
Dsmaint recreaterade

After doing that, we can start the IMA Service and MFCOM. If instead of IMA Service starting you get the following error message:

Ensure the following registry is populated:
Read More

Troubleshooting Audio issues in Citrix XenApp

/ / /

We recently ran across an issue with XenApp 6.5 where we were publishing an application that required the “Beep” but it wasn’t working.  The following is the troubleshooting steps I did to enable audio to work on that application.

First we created a Citrix policy to enable audio.  This policy looked like so:

We filtered on a user security group to enable the client audio redirection and added that filter group to the application.  From the original appearance of things, this should have been sufficient to enable client redirection.  But it did not.  So I wanted to verify that the policy was actually applying to the user account.  To do that, you login to the system with a user account and check in Regedit for the value “AllowAudioRedirection”.  If it’s set to 0x1 then the Citrix group policy has evaluated that client redirection should be enabled for your session.

Unfortunately, I still did not have audio redirection working…

Citrix advises that you can use dbgview.exe to further troubleshoot the Citrix Receiver to assist.  I launched dbgview.exe and started the trace and launched the application from the Webinterface.

“00000043 0.60113800 [7752] CAMSetAudioSecurity: Wd_FindVdByName failed”

CAM is a virtual channel (Virtual Channel Priority for Audio) and we can see it’s failing.  I then used the Citrix ICA creator and launched the application using that.  The dbgview for that output looks like so:

00000013 0.44386363 [4496] CAMSetAudioSecurity: success

We can see that the audio virtual channel was able to successfully latch and I confirmed I had audio in the application.

From here the issue appeared to be when I launched the application from the webinterface or desktop shortcut.  I then compared the two ICA files, the one from the web interface and the one I created separately to see what was different.  The difference was glaringly obvious.  The working ICA file had “ClientAudio=On” and the broken one had “ClientAudio=Off”.

Curious, I launched AppCenter and clicked through the applications settings and saw the following:

“Enable legacy audio” was unchecked.  I checked it and then logged off and logged back on the web interface and when I downloaded the ICA file, “ClientAudio=On” and I had audio.  I then unchecked that setting and confirmed it manipulated the ICA file as with it unchecked the ICA file generated had “ClientAudio=Off”

Who knows why it’s called “legacy audio”.  May as well just call that option “Enable audio” as that would be more accurate.  The Citrix documents on this setting says the following:

To enable or disable audio for published applications

If you disable audio for a published application, audio is not available within the application under any condition. If you enable audio for an application, you can use policy settings and filters to further define under what conditions audio is available within the application.

  1. In the Delivery Services Console, select the published application for which you want to enable or disable audio, and select Action > Application properties. 
  2. In the Application Properties dialog box, click Advanced > Client options. Select or clear the Enable legacy audio check box.

Emphasis is mine.

Anyways, and now we have our applications with working audio and everything seems to be good again 🙂

To summarize the enable audio for a XenApp application you must:
1) Enable “legacy” audio
2) Enable a Citrix policy to configure audio redirection
3) Done.

Read More

Powershell script to manipulate “Register this connection’s addresses in DNS”

/ / /

We run a multihome NIC setup with our Citrix PVS servers and the “Provisioning” Network is a seperate VLAN that is only used by the PVS servers and goes no where.  Unfortunately, however, the “Provision” NIC can register itself in the DNS, causing devices outside of the Provisioning network (everyone) to resolve to the incorrect address.  To resolve this I ran this script across all my vDisks to remove the ability of the provision network to register itself as available in DNS.:

As you can see above, we have two NICs, “Provision” and “Production”.  We do not want “Provision” registerted so it gets the $false,$false set, whereas “Production” gets $true,$false.

Read More

How to enable “Adaptive Display” in XenApp 6.5

/ / /

Contrary to the documentation in the Group Policy settings for Citrix, XenApp requires the following settings configured for Adaptive Display to be enabled:

User settings
Minimum Image Quality
This setting specifies the minimum acceptable image quality for Adaptive Display. The less compression used, the higher the quality of images displayed. Choose from Ultra High, Very High, High, Normal, or Low compression.
By default, this is set to Normal.

Moving Image Compression
This setting specifies whether or not Adaptive Display is enabled. Adaptive Display automatically adjusts the image quality of videos and transitional slides in slide shows based on available bandwidth. With Adaptive Display enabled, users should see smooth-running presentations with no reduction in quality.
By default, this is set to Enabled.

Target Minimum Frame Rate
This setting specifies the minimum frame rate you want. The minimum is a target and is not guaranteed. Adaptive Display automatically adjusts to stay at or above this setting where possible.
By default, this is set to 10 frames per second.

Progressive Compression Level
Set to Disabled

Even though the GPO’s state these only apply to XenDesktop, they also apply to XenApp and can be confirmed if you publish HDX Monitor 3.0 on a XenApp server and monitor the ICA session, you can see the transient quality increasing or decreasing depending on your scenario.

Read More

Enable advanced logging on the XTE service of a XenApp server

/ / /

Back in February or March we did Windows updates on our PVS XenApp servers and then sometime after the servers do not allow anyone to login.

The issue can crop up as a CGP Tunnel error message, a protocol driver error message or something along those lines.  We do not know why it’s happening or why it only happens after we apply Windows updates from that time period.  The odd thing is it’s intermittent as well, we can launch 20 systems from 1 vDisk that has the updates applied and everything will be fine for 2 weeks then, suddenly, 5 of the systems won’t allow logins via ICA with the errors.  Rebooting the servers sometimes fixes it, sometimes not.  Very intermittent and very weird.  So I attempted to troubleshoot this issue again by adding:

to the httpd.conf in the XTE folder of a server that was exhibiting these issues.  The log levels are listed here:

After adding those lines and restarting the XTE service the issue resolved itself!  Frustrating to be sure, and I will look at adding this line to our vDisk image so that when it crops up we’ll have more diagnostic data to look at.

Read More

(OS 10061)No connection could be made because the target machine actively refused it. : Unable to connect to the CGP tunnel destination (

/ / /

(OS 10061)No connection could be made because the target machine actively refused it.  : Unable to connect to the CGP tunnel destination (

We got this error on a XenApp 6.5 provisioning server

We utilize Citrix PVS for our XenApp servers.  After updating our XenApp vDisk using our usual method and rebooting the server we got the above error.  Since we versioned it we had our usual servers working without issue, and a couple of “test” versions failing.  I started troubleshooting this using the google method of shotgun trying the first 5 error/solutions.  This included, disabling re-enabling ICA listener, setting the listener on only one NIC interface (which it was, I toggled it for all then just one), deleting the ICA listener and recreating it.  None of them worked so I started troubleshooting.

I encountered this error today and started troubleshooting.  The first step I did was trace the path to the error using Procmon.exe.  This, unfortunately, did not reveal anything of substance.  What I found with this error is the network process is almost exactly the same for both.  I can see XTE.exe communicating via 2598, I can see, what appears to be it handing it off to IMASrv.exe.  At this point is when it causes that error message to be displayed on the bad machine, but IMASrv.exe continues on the good machine.

At this point I’m thinking that maybe the IMA settings for session reliability have become corrupted.  It was suggested to me to disable session reliability and see if it works by a colleague of mine.

The odd thing about resetting the IMA policy is that it isn’t even set in the first place.

“Add” means it is not set

But I disabled it anyways in the IMA policy in AppCenter, NOT in group policy.  After setting session reliability to disabled I restarted the IMA Service on the server and the XTE service.  The XTE service refused to start, I assume because we disabled it, and the IMA service came up.  I then connected to the application via 1494 without issue.  At this point I removed the session reliability setting again.

Click “Remove”

And then waited a minute or so and restarted the IMA Service and XTE Service.  The XTE service came up cleanly, running netstat -a only showed 2598 was listening and I retried the application hosted on the troublesome server.

BANG, it worked like a charm.  I wish I knew why it was happening with more detail, unfortunately, this is as far as I got and I cannot make the error occur again.

The next time this occurs I would like to try stopping the IMA Service and removing this file:
C:\Program Files (x86)\Citrix\FarmGpo\FarmGpo.bin

I think that contains the local IMA policy that may have been corrupted and causing my issue.


I believe I have fixed the issue here.  It appears it may be a NIC binding issue.

Read More

Retrieving Citrix user accounts via PowerShell

/ / /

Retrieving Citrix user accounts via PowerShell

Here’s a neat little two liner to pull all the AD accounts associated with Citrix applications:


Read More

AppV and Application Compatibility

/ / /
I was having an issue with a old application that we want to run on our Citrix XenApp 6 farm; Microsoft Enterprise Reporting 7.5 SP4 (7.5.303). Namely, it wouldn’t run. It’s not compatible with Server 2008 R2 unless you’re running SP5. Well, we’re going to get rid of it in a few months but we want to get rid of our 4.5 farm. So, we need to migrate the application to XenApp 6 and Server 2008R2 from Presentation Server 4.5 and Server 2003 SP1.

First thing I did was setup a Server 2003 SP1 box and installed the AppV sequencer on it and sequenced the application. I then set it to run on 2008R2 64bit and moved the package over to it. It would crash. Analysing the crash logs would present to me the error… ERAPP32 was crashing its heap. In order to get it to work I had to set it to run in compatibility mode for XPSP3. Once I set this it worked flawlessly. So what I needed to do was push this fix to the rest of our Citrix servers before deploying the AppV application. If you’ve ever read ACT (application compatibilty toolkit) and merging it with AppV it’s kind of a difficult job.

But there is a easier way.

Stored in the registry is the AppCompatFlags key that contains the applications and the shims you can apply to an application. If you put the path to your AppV application it will actually enable it to run in the compatibility mode that you specify. This was my registry entry:

And now the application works almost wonderfully (ER is a painful application)


Read More

Utilizing PowerShell to make Citrix VM Templates

/ / /

Because my company doesn’t utilize provisioining servers for deploy new Citrix XenApp servers, I’ve had to come up with a couple of PowerShell scripts to make VMWare Templates that I can then deploy multiple XenApp servers. You need VMWare PowerCLI to run this script. This is my script:

This script does the following:
1) Sets the inputs from a piped in object (get-vm VMTOTEMPLATE | create-template)
2) Sets a series of variables ($vm, $name, $newname, $date, $templatename, etc.)
3) We setup a startup script on the target server to make into a template that:
a) Removes the computer from the domain
b) renames the computer to a generic name (XATEMPLATE)
c) Adds registry keys that will allow sysprep to run
d) Configures XenApp to “Image” mode
e) Shuts itself down once running the script is complete
f) deletes the script from running on startup
4) We then set the target to autologin with the local admin user name and password so the startup script in step 3 will be run
5) Begins the cloning by making a new-vm with the target machine
6) We unplug the NIC from VMWare so that when it starts up the script won’t actually remove the machine from the domain, but will remove itself from the domain
7) start the clone
8) the PowerCLI will now wait till the machine turns itself off…
9) Then it will reconnect the NIC, remove any stale templates and then makes a new template and then removes the clone VM.

Done! 🙂

Read More