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.
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).
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).
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.
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.
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:
Nederlands 
English