… 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.

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:

Thursday, April 19, 2012

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:

Run sysprep

Disjoin and rejoin to the domain

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.

Wednesday, April 18, 2012

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:

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.

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.