Launching a XenDesktop 5.5 or 5.6 desktop through an NetScaler Access Gateway throws the error: “Unable to launch your application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server. Protocol Driver error”

For those who may have come across one of my previous posts:

Attempting to launch a XenDesktop 5.5 or 5.6 desktop through an NetScaler Access Gateway throws the error: “Unable to launch your application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server. Protocol Driver error”
http://terenceluk.blogspot.com/2012/04/attempting-to-launch-xendesktop-55-or.html

… may recall that the error above was caused by the fact that you may have maxed out your concurrent user sessions configured on the Access Gateway.  What I recently discovered was that this error could also be caused by the access gateway not being able to contact the web interface server via session reliability using the TCP 2598 port.  If you encounter this error, you can perform a quick test by unchecking the Enable session reliability checkbox:

… to see if the Citrix XenDesktop virtual desktop launches and if it does, it means your Citrix access gateway was able to use the TCP 1494 port to communicate with the web interface servers.  One of the easiest ways to check to see if your access gateway can successfully communicate to the backend server via either the TCP 2598 or 1494 ports is to set up services in the Load Balancing –> Services node for both ports to see if the state is up or down:

Notice how in the above screenshot I have 3 services set up:

• sessionreliability_test
• ica-test
• http_test

The last http_test is not important as that’s just testing port 80 while the sessionreliability_test and ica-test are the services that allow us to test whether the Citrix access gateway can successfully communicate to the XenApp servers through TCP 2598 or 1494 port.  This trick is definitely useful and handy to know of while troubleshooting access gateway issues.  The following is what the service configuration looks like:

Prior to fixing my problem with the protocol driver error, my sessionreliability_test service’s state was down and what caused my problem was a missing SNIP (Subnet IP) on my NetScaler:

Hope this helps anyone who may encounter a similar issue in their environment.

Event ID 10128 errors are logged on a Windows XP master image for a Citrix XenDesktop VDA causing shadowing sessions with Citrix Desktop Director to fail

Problem

You’re attempting to use Citrix XenDesktop Desktop Director 2.1 to shadow a desktop catalog with Windows XP desktops but would continuously receive the error:

Failed to initiate Remote Assistance: You have insufficient permissions (error code 102). Refer to documentation for Remote Assistance configuration. View server event logs for further information.

Logging onto the Windows XP desktops and browsing the event logs show the following error logged:

The WinRM service is not listening for HTTP requests because there was a failure binding to the URL (http://+:80/wsman/) in HTTP.SYS.

No remote requests will be serviced on that URL.

User Action

Please use "netsh http" to check if ACL for URL (http://+:80/wsman/) is set to Network Service.

Additional Data

The error code received from HTTP.sys is 5: Access is denied.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Solution

This was only one of the issues that caused my attempts to shadow users with Desktop Director 2.1 to fail but what ended up fixing this error on the Windows XP image was a winrm command found in the following Citrix KB:

Enabling WinRM for Desktop Director
http://support.citrix.com/article/CTX125243

Once I ran the command:

winrm set winrm/config/Service @{EnableCompatibilityHttpListener="true"}

… the event log error found in the Windows XP desktops went away.

Attempting to run “Update Personal vDisk” throws the error “Personal vDisk inventory Is not supported on this machine.” on Citrix XenDesktop 5.6 VDA

Problem

You have just recently cloned one of your master image with Windows XP and ran sysprep to generate new identifiers for it but noticed that when you run the Update Personal vDisk process, you get the error:

Personal vDisk inventory Is not supported on this machine.

Solution

I’m not sure if this is by design but I’ve ran into this issue every time I do one of the following on a virtual desktop master image that had the Virtual Desktop Agent (VDA) installed onto it:

1. Run sysprep
2. Disjoin and rejoin to the domain
3. Rename the desktop in Windows

What ended up having to do in order to fix this was uninstall the VDA, reboot, reinstall the VDA and then run the Update Personal vDisk again.

Citrix ICA Service service crashes on XenDesktop 5.6 VDA (Virtual Desktop Agent) virtual desktop

Problem

You’ve recently installed an application that uses .NET Framework such as the IBM System i Access for Windows:

… and you notice that after the install, the Citrix ICA Service on the virtual desktop no longer starts:

Windows could not start the Citrix ICA Service service on Local Computer.

Error 1053: The service did not respond to the start or control request in a timely fashion.

DistributedCOM errors are found in the System event logs:

Event ID: 10010

The server {EFFFADEC-69AE-4CDB-86AF-4FA2B53C5CA5} did not register with DCOM within the required timeout.

Event ID: 10005

DCOM got error "1053" attempting to start the service PorticaService with arguments "" in order to run the server:

{EFFFADEC-69AE-4CDB-86AF-4FA2B53C5CA5}

Event ID: 7009

A timeout was reached (30000 milliseconds) while waiting for the Citrix ICA Service service to connect.

Event ID: 7000

The Citrix ICA Service service failed to start due to the following error:

The service did not respond to the start or control request in a timely fashion.

Event ID: 7036

The Citrix Audio Redirection Service service entered the running state.

Solution

The last few times I ran into errors as DCOM errors like these, it was caused by DCOM object permissions that could be fixed via the Computer Services administrative tools:

After searching for the unique IDs referenced in the event logs:

{efffadec-69ae-4cdb-86af-4fa2b53c5ca5}

{f719ecbb-1fb8-4dde-aafa-848f9e1479d4}

… I finally end up finding the Citrix PortICA COM Server DCOM object and noticed that when I switched the Log on as: setting from This account: Local Service to Local System account, the service would start:

While this fixed the issue, it wasn’t really an acceptable resolution due to security reasons and as soon as I switched the setting back to Local Service, the Citrix ICA Service would no longer start:

I proceeded to check the Report.wer logs:

Version=1

EventType=CLR20r3

EventTime=129785356418648736

ReportType=2

Consent=1

ReportIdentifier=500b65f6-830b-11e1-b990-005056816a51

WOW64=1

Response.type=4

Sig[0].Name=Problem Signature 01

Sig[0].Value=picasvc.exe

Sig[1].Name=Problem Signature 02

Sig[1].Value=6.2.100.77

Sig[2].Name=Problem Signature 03

Sig[2].Value=4f43b63c

Sig[3].Name=Problem Signature 04

Sig[3].Value=System.Configuration

Sig[4].Name=Problem Signature 05

Sig[4].Value=2.0.0.0

Sig[5].Name=Problem Signature 06

Sig[5].Value=4ca2ba8c

Sig[6].Name=Problem Signature 07

Sig[6].Value=1a6

Sig[7].Name=Problem Signature 08

Sig[7].Value=136

Sig[8].Name=Problem Signature 09

Sig[8].Value=IOIBMURHYNRXKW0ZXKYRVFN0BOYYUFOW

DynamicSig[1].Name=OS Version

DynamicSig[1].Value=6.1.7601.2.1.0.256.48

DynamicSig[2].Name=Locale ID

DynamicSig[2].Value=1033

UI[2]=C:\Program Files\Citrix\ICAService\picaSvc.exe

LoadedModule[0]=C:\Program Files\Citrix\ICAService\picaSvc.exe

LoadedModule[1]=C:\Windows\SysWOW64\ntdll.dll

LoadedModule[2]=C:\Windows\SYSTEM32\MSCOREE.DLL

LoadedModule[3]=C:\Windows\syswow64\KERNEL32.dll

LoadedModule[4]=C:\Windows\syswow64\KERNELBASE.dll

LoadedModule[5]=C:\Program Files (x86)\Citrix\Offline Plugin\system32\radeaphook.dll

LoadedModule[6]=C:\Program Files (x86)\Citrix\Offline Plugin\system32\CtxSbxHook.DLL

LoadedModule[7]=C:\Windows\syswow64\USER32.dll

LoadedModule[8]=C:\Windows\syswow64\GDI32.dll

LoadedModule[9]=C:\Windows\syswow64\LPK.dll

LoadedModule[10]=C:\Windows\syswow64\USP10.dll

LoadedModule[11]=C:\Windows\syswow64\msvcrt.dll

LoadedModule[12]=C:\Windows\syswow64\ADVAPI32.dll

LoadedModule[13]=C:\Windows\SysWOW64\sechost.dll

LoadedModule[14]=C:\Windows\syswow64\RPCRT4.dll

LoadedModule[15]=C:\Windows\syswow64\SspiCli.dll

LoadedModule[16]=C:\Windows\syswow64\CRYPTBASE.dll

LoadedModule[17]=C:\Windows\syswow64\SHELL32.dll

LoadedModule[18]=C:\Windows\syswow64\SHLWAPI.dll

LoadedModule[19]=C:\Windows\system32\msi.dll

LoadedModule[20]=C:\Windows\syswow64\ole32.dll

LoadedModule[21]=C:\Windows\system32\IMM32.DLL

LoadedModule[22]=C:\Windows\syswow64\MSCTF.dll

LoadedModule[23]=C:\PROGRA~1\Citrix\System32\MFAPHOOK.DLL

LoadedModule[24]=C:\Program Files\Citrix\ICAService\SCardHook.dll

LoadedModule[25]=C:\Program Files\Citrix\ICAService\twnhook.dll

LoadedModule[26]=C:\Program Files\Citrix\ICAService\cxinjime.dll

LoadedModule[27]=C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

LoadedModule[28]=C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\MSVCR80.dll

LoadedModule[29]=C:\Windows\system32\profapi.dll

LoadedModule[30]=C:\Windows\assembly\NativeImages_v2.0.50727_32\mscorlib\a1a82db68b3badc7c27ea1f6579d22c5\mscorlib.ni.dll

LoadedModule[31]=C:\Windows\system32\CRYPTSP.dll

LoadedModule[32]=C:\Windows\system32\rsaenh.dll

LoadedModule[33]=C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll

LoadedModule[34]=C:\Program Files\Citrix\ICAService\Citrix.Utils.Diagnostics.dll

LoadedModule[35]=C:\Windows\assembly\NativeImages_v2.0.50727_32\System\abab08afa60a6f06bdde0fcc9649c379\System.ni.dll

LoadedModule[36]=C:\Windows\assembly\NativeImages_v2.0.50727_32\System.ServiceProce#\6f2de1cb69aef1946760a70f355a3075\System.ServiceProcess.ni.dll

LoadedModule[37]=C:\Windows\assembly\GAC\Citrix.Diagnostics\1.0.21.0__7110990e26881462\Citrix.Diagnostics.dll

LoadedModule[38]=C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Configuratio#\66a5094e521e34aecd51e4bae30ac266\System.Configuration.Install.ni.dll

LoadedModule[39]=C:\Program Files\Citrix\ICAService\Citrix.Utils.COMServer.dll

LoadedModule[40]=C:\Windows\assembly\GAC\Citrix.Diagnostics.Recorder.Cdf\1.0.21.0__7110990e26881462\Citrix.Diagnostics.Recorder.Cdf.dll

LoadedModule[41]=C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Configuration\2d5bcbeb9475ef62189f605bcca1cec6\System.Configuration.ni.dll

LoadedModule[42]=C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Xml\130ad4d9719e566ca933ac7158a04203\System.Xml.ni.dll

LoadedModule[43]=C:\Windows\system32\VERSION.dll

LoadedModule[44]=C:\Windows\system32\apphelp.dll

FriendlyEventName=Stopped working

ConsentKey=CLR20r3

AppName=Citrix PortICA Controller

AppPath=C:\Program Files\Citrix\ICAService\picaSvc.exe

ReportDescription=Stopped working

Then the other logs found in the directory C:\ProgramData\Microsoft\Windows\WER\ReportQueue:

… yet still wasn’t able to figure out where the problem was.

After running out of ideas, I suddenly had the thought that perhaps I should check the Microsoft.NET Framework folders to see if anything was out of the ordinary:

Probably due to pure luck, I decided to start resetting the permissions on each folder while trying to restart the Citrix ICA Service service and noticed that as soon as I reset the C:\Windows\Microsoft.NET\Framework\v2.0.50727 folder, the service would begin to start:

I’m not exactly sure why taking ownership and then propagating the security settings from the C:\Windows\Microsoft.NET\Framework\v2.0.50727 folder fixed the issue but my guess is that the IBM application somehow modified the original folder permissions that the Citrix VDA relied on the folder thus preventing it from being able to properly access the files it needed.

Citrix XenDesktop 5.6 desktop catalog’s virtual desktops stuck at Unregistered State

Problem

You’ve just completed the deployment of a Citrix XenDesktop 5.6 desktop catalog pool with or without PvDs and assigned a desktop group to the catalog but notice that the State for some virtual desktops are stuck at Unregistered state:

You continue to wait but after minutes and hours, the state is still stuck at Unregistered.

Solution

While there can be many reasons why a subset of your desktops are stuck at this state, one of the reasons I’ve encountered is that the virtual desktop has hung.  Browsing to the virtual desktop’s Summary tab within the vSphere Client shows that VMware Tools is not running and no IP address has been picked up by the VMware Tools:

Opening up the console of the virtual desktop and sending Ctrl+Alt+Del shows that the virtual desktop is unresponsive:

If your desktop is stuck in this state and has become unresponsive, try sending a Reset command to the virtual desktop with the vSphere Client:

Once the virtual desktop successfully restarts and becomes responsive, check the state in Desktop Studio:

If your virtual desktop hasn’t hung as shown in this example, the next step is to try and log into the desktop via the console and check the event logs because the unregistered state usually means that your desktop’s VDA (Virtual Desktop Agent) is unable to contact the DDCs.  This can be caused by a misconfiguration in the DDC settings when you installed the VDA or the virtual machine does not have network connectivity to the DDC.