RES WM11: Workspace Composer hangs at “Preparing applications”

Written by Ingmar Verheij on July 23rd, 2012. Posted in Workspace management

Users who logon with RES Workspace Manager 2011 experienced a long delay ( > 1minute) and mentioned that the Workspace composer hangs at “Preparing Applications”. After the delay the desktop was shown as expected.

RES Workspace Manager - Preparing applications

Short version

The delay was caused by a check  for the existence of executables (forced by the “Hide application if executable was not found”). Since the executable was stored on a non-existing network location the Workspace Composer had to wait until the operating system returned with a negative result.

The issue is described  in Q202451 in the RES knowledge base (login required).

I would recommend not to check for the existence of executables on a network locations if you not really need it, it adds unnecessary overhead.

Long version

The Workspace Analysis of the test user (TestDesktop05) wasn’t very helpful, it showed a gap of 1 minute and 13 seconds between “Start preparing menus” and the next action (user setting sampling).

TestDesktop05 - Workspace Analysis
After enabling the RES trace file (see Q201489) and restarting the RES Workspace Manager Agent more detailed information was captured (don’t forget to give modify permissions to the test user on the trace file).

Enable RES Trace - registryEnable RES Trace - ACL

In the trace file the same gap was visible during the ‘RetrieveMenus; Checking app authentication’ phase in function ‘fysnAppAuthenticated’. Apparently the application with ID 149 and title ‘Foodcare 7.2’ caused the delay.

The properties of the application in the RES Workspace Manager Console show that the executable is stored on a network location (on server S-FB02) and that it should hide the application if the executable was not found.

RES Workspace Manager - Foodcare 7.2 - GeneralRES Workspace Manager - Foodcare 7.2 - Settings

 
Network Interface Cards

The server (S-TS72) is a Citrix XenApp server streamed via Citrix Provisioning Server (PVS). Therefore the server has two network interface cards:

PRT1 LAN

PRT2 PVS

 

Wireshark

A network trace in Wireshark showed the network requests that where sent:

Domain Name Service(DNS)

Resolving the name S-FB02 to an IP address is done via DNS, right after pwwsmgr.exe logged the application in the REStrace.log. The response was given in a few milliseconds and returned the ip address 172.22.30.46.

Remark: The DNS request was sent via the pvs network, which it shouldn’t (wrong NIC priority). Fortunately the pvs network has a stub-zone for the same domain,

 

NetBIOS Name Service (NBNS)

Besides resolving the hostname of S-FB02 via DNS the system tries to resolve the name to an IP address via NBNS. The response was given within a few milliseconds by the WINS server (172.22.0.102) and returned the same IP address 172.22.30.46.

The same request is sent via the pvs network (10.3.0.72) but never got a response. This is as expected, there is no WINS server and the S-FB02 machine is attached to the pvs network.

After 46 seconds the request is repeated, apparently the system was satisfied.

 

Address Resolution Protocol (ARP)

The system wasn’t satisfied because the IP address could not be translated to a Media Access Control (MAC) address. Since the IP address is on the same subnet it needs the MAC address to communicate to the NIC of the remote server (S-FB02).

Translating the IP address to a MAC address is done via Address Resolution Protocol (ARP). Since it knows the IP address to resolve (172.22.30.46) is handled by the PRT1 LAN NIC (172.22.5.72) all requests are sent via the NIC with MAC address E8-39-35-BC-48-44 (where E8-39-35 is owned by the vendor Hewlett Packard).

After sending 20 requests and getting no answer the system returns with an error: No network proivder accepted the given network path.

No network provider accepted the fiven network path

 

Conclusion

The feature to hide an application if the executable does not exist is a nifty feature, it’s a great way of hiding shortcuts that would never word and irritate the user. It comes at a price though, especially if the executable is stored on a network location.

Since the process of checking for executables is synchronous the user (potentially) needs to wait a long time. Additionally it adds some overhead on the network since it checks the existence of executable each time the users logs in or refreshes its workspace. This customer frequently disconnects and reconnects because they roam there session through the hospital.

What adds to the frustration is the difficulty to troubleshoot the issue: there’s no indication why there’s a big delay. So here’s a feature request for RES: Please add a warning in the users’s event log (workspace analysis) so the admin knows what’s causing the delay.

Example:

TestDesktop05 - Workspace Analysis - Missing something here

Ingmar Verheij

At the time Ingmar wrote this article he worked for PepperByte as a Senior Consultant (up to May 2014). His work consisted of designing, migrating and troubleshooting Microsoft and Citrix infrastructures. He was working with technologies like Microsoft RDS, user environment management and (performance) monitoring. Ingmar is User Group leader of the Dutch Citrix User Group (DuCUG). RES Software named Ingmar RES Software Valued Professional in 2014.

More Posts - Website

Follow Me:
TwitterLinkedInGoogle Plus

Tags: , , , ,

Leave a comment

*

Donate

%d bloggers like this: