Performance

“An error occurred while making the requested connection” – Citrix Web Interface

2013-07-22
/ / /

So I’m getting the dreaded “An error occurred while making the requested connection” while trying to launch some applications from our Citrix Web Interface.  It started happening suddenly but I’m tasked with figuring out why.  First thing I did was go to the Web Interface and check the event logs.  I found the following:

 

This wasn’t much help, but I was able to narrow down that this was happening on one set of our servers that are split across two DC’s.  One set of servers at BDC was fine, the other set of servers at ADC had a subset of servers that were not.  Doing a qfarm /load showed the problematic servers had no users on them at all, and no load evaluators were applied that would be causing our issue.

Logging into the server it was deteremined that it’s DNS was registered to the wrong NIC (it was a PVS server that was multi-homed) and even worse for some of the servers, the NIC IP address was an old address and the new address wasn’t even resolving!

For some reason it now appears our Windows 2008 servers are not registering their DNS on startup.  To resolve this issue for us we added a startup script with the simple command “ipconfig /registerdns” and within a few seconds the IP address is registered within DNS correctly and with the correct NIC.  We suspect that something is misconfigured at ADC as BDC does not have this issue nor does it need this tweak, but this is our work around until that is resolved.

Read More

How to enable “Adaptive Display” in XenApp 6.5

2013-06-11
/ / /

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

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

2013-05-27
/ / /

 

This has been an ongoing problem for us (Unable to connect to the CGP tunnel destination (127.0.0.1:1494)

I may have found out why it was happening in our environment.  We are using Provisioning Services and with it we are using two NIC’s, one for the Provisioning Services and one for Standard networking.

It appears the XTE service became configured to use the Provisioning Services NIC.  This was verified in the httpd.conf in the C:\Program Files (x86)\Citrix\XTE\conf folder.

Provisioning NIC and Production (network) NIC

 

httpd.conf as was when the system booted (and non-functional)

When I traced the XTE service using procmon.exe and wireshark with this non-functional conf this is what I saw when I attempted to launch the application:

You can see it attempt to connect to itself via 1494 but then nothing else happens
Wireshark shows virtually nothing on the network and nothing related to IMA
When I edited the file to have the Production NIC…

 
then restarted the XTE service and retraced via Procmon and Wireshark…
We now see tons of activity and the application now launches without issues.

================EDIT===============

We have now found why we are getting this error, and why we are getting it intermittently.  The issue is we are using PVS with multi-homed NIC’s.  One NIC (LanAdapter 1) is the “Provisioning” network, and the second NIC (LanAdapter 2) is the “Production” network.  The Provisioning network is on a completely seperate vLan and sees no traffic outside of it’s little network.  The ICA Listener was attaching itself to the Provisioning network instead of the production network, so when we tried to connect to the server it would fail with the CGP tunnel error because the outside network cannot talk to the Provisioning network.  To attempt to resolve this issue one of our techs (Saman) created a group policy preference registry key that set the following value (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server\WinStations\ICA-TCP – LanAdapter):

By setting it to “2” we could ensure the ICA listener is always listening on LanAdapter 2, our production network.  Unfortunately, a Windows Update appears to have caused either Group Policy Registry Preferences to execute (sometimes) *after* the IMAService service started, or allowed the IMAService service to start *before* Group Policy Registry Preferences.  IMAService will recreate that file every second restart.  To resolve this issue I created a startup script that executes after 65 seconds, deleting the httpd.conf file and restarting the appropriate services until the httpd.conf file is recreated.

In my testing it appears you need to restart the “IMAService” service twice to get it to recreate the httpd.conf file.  Because of this, I created the script to retry up to 3 times to try and regenerate the file.

Read More

Corrupted VHD files

2013-05-14
/ / /

Corrupt VHD files…  We utilize PVS and when we were attempting to update the target device software utilizing Hyper-V we got several error messages saying the VHD is corrupted.  The actual root of the issue is that PVS makes 16MB block size VHD files (thanks SAMAN!) and Windows 2008 only reads VHD files that are 512KB or 2MB block sized files.

Attempting to mount the VHD file via disk management fails as well.  The only utility that would mount the VHD file that was generating the error messages at the end of this post is the Citrix CVHDMount utility available via PVS (C:\Program Files\Citrix\Provisioning Services\CVHDMount.exe)

Since our Hyper-V server was separate from the PVS server, we needed to install the drivers to allow CVHDMount.exe to work.  In order to do this you need to install the drivers in this folder:
C:\Program Files\Citrix\Provisioning Services\drivers

You can right-click “Install” on the cfsdep2.inf file.

For the other driver you need to open Device Manager, go through “Add new hardware…”, “Add legacy hardware” and then browse to the drivers folder and add the cvhdbusp6.inf.

Now we would mount the disk as a drive letter using this command line:

At this point you need to set the disk to “Offline” in Disk Management.

From here we can now add the disk as a physical disk to Hyper-V.

And we can now do the Target Device Update.  Error messages seen during this troubleshooting:

 

Read More

Citrix PVS bootup failure with the Boot Device Management ISO

2013-05-01
/ / /

We had an issue recently with some Citrix Provisioning Servers (PVS) that were not getting a DHCP address when booting off of the Boot Device Management ISO (BDM.ISO).  What was happening is the server would just show this:

DHCP Discover ._._._._.

DHCP maximum number of retries reached.

When booting off of PXE or a WinPE CD I was getting DHCP without issues.

When I did a Wireshark of the line I saw the BDM.ISO boot send out DHCPDISCOVER packets but it never received a response.  I then Wiresharked the WinPE and PXE boots and saw the DHCPDISCOVER packet, followed by a DHCPOFFER, and so on.  When I examined the two packets I saw the BDM.ISO DHCPDISCOVER packet actually was a BOOTP unicast whereas the PXE and WinPE packets were BOOTP broadcast.  Thinking we had a DHCP Relay issue we checked our DHCP server (an InfoBlox server) and checked the logs for the MAC Address and here is what we saw when we booted with the BDM.ISO:

BDM.ISO DHCP traffic

The DHCP server was not responding to the DHCPDISCOVER.  This only occurred with the unicast packet and for some reason was “load balance to peer”.  However it’s setup, it appears UNICAST BOOTP packets are setup for load balancing but not sending a response.

PXE/WinPE DHCP traffic

The DHCP server is responding to a BROADCAST BOOTP packet in a very different way.  There is no load balancing going on and the server responds to the DISCOVER packet.

Unfortunately, we did not resolve this issue when I wrote this.  We got our farm to work by pointing the DHCP Relay to the previous DHCP server that is configured in such a way to resolve this DHCP request and present an DHCP OFFER.  Hopefully our network guys will get the DHCP fixed on the proper server.  If you are experiencing similar issues you may have a similar issue where the DHCP at your site is handling unicast DHCPDISCOVER packets differently then broadcast packets.

Read More

Citrix HDX Engine has encountered a problem and needs to close we are sorry for the inconvenience.

2013-03-08
/ / /

The scourage of many a Citrix tech.

Citrix HDX Engine has encountered a problem and needs to close we are sorry for the inconvenience.

Numerous forum posts that I’ve seen without a solution.  I have encountered this across two companies and have encountered the same solution both times.

Symptoms:

1) When you click Debug you get this information

AppName: wifca32.exe
ModName: msvcr80.dll

2) Event viewer shows “Faulting application wfica32.exe…” “faulting module msvcr80.dll…”

3) The error dialog occurs after an application is launched (maybe between 10 seconds to 120 seconds afterwards).  The user can move the dialog out of the way and continue working without issue, however clicking the “Close” button will terminate the application.  Sometimes though, the error occurs before the application is fully launched.

Background:

The Citrix client opens virtual channels as it connects to the server.

Overview of client-server data exchange using a virtual channel.
1. The client connects to the XenApp Server. The client passes information about the virtual channels it supports to the server.
2. The server-side application starts, obtains a handle to the virtual channel, and optionally queries for additional information about the channel.
3. The client virtual driver and server-side application pass data using the following two methods:
If the server application has data to send to the client, the data is sent to the client immediately. When the data is received by the client, the WinStation driver de-multiplexes the virtual channel data from the ICA stream and immediately passes it to the client virtual driver.
If the client virtual driver has data to send to the server, the data is sent the next time the WinStation driver polls it. When the data is received by the server, it is queued until the virtual channel application reads it. There is no way to alert the server virtual channel application that data was received.
4. When the server virtual channel application is finished, it closes the virtual channel and frees any allocated resources.

Issue:
If your application starts and the dialog box appears afterwards; we can conclude one of the virtual channels has crashed.  Usually, if this scenario appears it’s because your application has “Don’t wait for printers”.  If your application does not have this checkbox then sometimes the application will crash before the application is loaded.  With this knowledge we have narrowed down our culprit.  Printers.  An example of a printer list with a client that was having this issue:

We have a Citrix policy to only map the default printer, but during the virtual channel creation, all printers become connected to the server.  I was able to verify this with procmon; watching as it iterated through the registry keys for each printer.

A simple test to determine if a bad printer is causing your issue is to disable the Print Spooler service:

Click Stop

After stopping the service and terminating any existing sessions, relaunch the application.  If you no longer get an error (as in my case) then the issue is during the virtual channel creation of one of the faulty printers.  I cleaned up the printers that the user had, removing all non-needed ones and they did not encounter the error message afterwards.  There issue was resolved.  I have seen that cleaning up a printer queue is sometimes not enough and the printers need to be deleted and recreated.  I’ve yet to encounter a printer that I’ve recreated that has caused the issue to persist, but I guess it’s possible.

In the example above after deleting the users printers and restarting the print spooler the printers came back.  The user did not have permission to delete the printers from the HKLM so I needed to do so manually.

So ensure you test restarting the printer spooler and see if the printer comes back to the user to ensure the user has appropriate rights to remove the printer.

Read More