RES WM11: Workspace Composer hangs at “Preparing applications”

Author: Ingmar Verheij

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.

2012-07-20 15:41:46.106	9336	9340	pfwsmgr	3	TestDesktop05	fysnAppAuthenticated; AppID=149 Title: Foodcare 7.2
2012-07-20 15:41:46.106	9336	9340	pfwsmgr	3	TestDesktop05	fysnAppAuthenticated; Group access: True
 . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .
2012-07-20 15:42:58.178	9336	9340	pfwsmgr	3	TestDesktop05	fysnAppAuthenticated; AppID=348 Title: Foodcare 7.5
2012-07-20 15:42:58.178	9336	9340	pfwsmgr	3	TestDesktop05	fysnAppAuthenticated; Group access: True

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

   MAC        : E8-39-35-BC-48-44
   IP-address : 172.22.5.72
   Subnetmask : 255.255.0.0
   Gateway    : 172.22.255.254
   DNS        : 172.22.0.101
                172.22.0.102
   WINS       : 172.22.0.101
                172.22.0.102

PRT2 PVS

   MAC        : E8-39-35-BC-48-46
   IP-address : 10.3.0.72
   Subnetmask : 255.255.0.0
   Gateway    :
   DNS        : 10.3.0.10

 

Wireshark

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

Domain Name Service(DNS)

9336	15:41:46.112480000	10.3.0.72	10.3.0.10	DNS	79	Standard query 0x7029  A S-FB02.(domain name)
9340	15:41:46.112785000	10.3.0.10	10.3.0.72	DNS	95	Standard query response 0x7029  A 172.22.30.46

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)

9330	15:41:46.119338000	172.22.5.72	172.22.0.102	NBNS	92	Name query NB S-FB02<20>
9331	15:41:46.119581000	172.22.0.102	172.22.5.72	NBNS	104	Name query response NB 172.22.30.46
9337	15:41:46.112495000	10.3.0.72	10.3.255.255	NBNS	92	Name query NB S-FB02<20>
9485	15:41:46.848322000	10.3.0.72	10.3.255.255	NBNS	92	Name query NB S-FB02<20>
9601	15:41:47.598340000	10.3.0.72	10.3.255.255	NBNS	92	Name query NB S-FB02<20>
22998	15:42:32.599479000	10.3.0.72	10.3.255.255	NBNS	92	Name query NB S-FB02<20>
22999	15:42:32.609878000	172.22.5.72	172.22.0.102	NBNS	92	Name query NB S-FB02<20>
23000	15:42:32.610088000	172.22.0.102	172.22.5.72	NBNS	104	Name query response NB 172.22.30.46
23111	15:42:33.345706000	10.3.0.72	10.3.255.255	NBNS	92	Name query NB S-FB02<20>
23214	15:42:34.095805000	10.3.0.72	10.3.255.255	NBNS	92	Name query NB S-FB02<20>

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)

9329	15:41:46.115273000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
9633	15:41:48.127141000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
9753	15:41:49.048990000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
9950	15:41:50.627077000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
10255	15:41:53.126873000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
10296	15:41:53.533092000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
10446	15:41:55.064234000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
10913	15:41:58.629237000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
11105	15:42:00.129075000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
14880	15:42:11.628545000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
16375	15:42:20.562882000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
22986	15:42:32.592154000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
23264	15:42:34.624671000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
23415	15:42:35.546457000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
23629	15:42:37.124595000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
23932	15:42:39.624402000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
23993	15:42:40.015005000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
24222	15:42:41.561767000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
24734	15:42:46.045997000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72
25184	15:42:49.626624000	HewlettP_bc:48:44	Broadcast	ARP	42	Who has 172.22.30.46?  Tell 172.22.5.72

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

Was once an enthusiastic PepperByte employee but is now working at Citrix. His blogs are still valuable to us and we hope to you too.