{"id":4134,"date":"2012-07-23T09:45:27","date_gmt":"2012-07-23T07:45:27","guid":{"rendered":"https:\/\/ingmarverheij.com\/?p=4134"},"modified":"2012-07-23T09:58:51","modified_gmt":"2012-07-23T07:58:51","slug":"workspace-composer-hangs-at-preparing-applications","status":"publish","type":"post","link":"https:\/\/ingmarverheij.com\/en\/workspace-composer-hangs-at-preparing-applications\/","title":{"rendered":"RES WM11: Workspace Composer hangs at “Preparing applications”"},"content":{"rendered":"

Users who logon with RES Workspace Manager 2011 experienced a long delay ( > 1minute) and mentioned that the Workspace composer hangs at \u201cPreparing Applications\u201d. After the delay the desktop was shown as expected.<\/p>\n

\"RES<\/a><\/p>\n

Short version<\/h2>\n

The delay was caused by a check  for the existence of executables (forced by the \u201cHide application if executable was not found\u201d). 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. <\/p>\n

The issue is described  in Q202451<\/a> in the RES knowledge base (login required).<\/p>\n

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.<\/p>\n

<\/p>\n

Long version<\/h2>\n

The Workspace Analysis of the test user (TestDesktop05) wasn\u2019t very helpful, it showed a gap of 1 minute and 13 seconds between \u201cStart preparing menus\u201d and the next action (user setting sampling).<\/p>\n

\"TestDesktop05<\/a>
After enabling the RES trace file (see Q201489<\/a>) and restarting the RES Workspace Manager Agent more detailed information was captured (don\u2019t forget to give modify<\/em> permissions to the test user on the trace file).<\/p>\n

\"Enable<\/a>\"Enable<\/a><\/p>\n

In the trace file the same gap was visible during the \u2018RetrieveMenus; Checking app authentication\u2019 <\/em>phase in function \u2018fysnAppAuthenticated\u2019<\/em>. Apparently the application with ID 149 and title \u2018Foodcare 7.2\u2019 caused the delay. <\/p>\n

2012-07-20 15:41:46.106\t9336\t9340\tpfwsmgr\t3\tTestDesktop05\tfysnAppAuthenticated; AppID=149 Title: Foodcare 7.2\t\n2012-07-20 15:41:46.106\t9336\t9340\tpfwsmgr\t3\tTestDesktop05\tfysnAppAuthenticated; Group access: True\t\n . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . .  . . . . . . \n2012-07-20 15:42:58.178\t9336\t9340\tpfwsmgr\t3\tTestDesktop05\tfysnAppAuthenticated; AppID=348 Title: Foodcare 7.5\t\n2012-07-20 15:42:58.178\t9336\t9340\tpfwsmgr\t3\tTestDesktop05\tfysnAppAuthenticated; Group access: True<\/pre>\n
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. <\/p>\n
\"RES<\/a>\"RES<\/a><\/p>\n
 <\/h5>\n
Network Interface Cards<\/h5>\n
The server (S-TS72) is a Citrix XenApp server streamed via Citrix Provisioning Server (PVS). Therefore the server has two network interface cards:<\/p>\n
PRT1 LAN<\/strong><\/p>\n
   MAC        : E8-39-35-BC-48-44\n   IP-address : 172.22.5.72\n   Subnetmask : 255.255.0.0\n   Gateway    : 172.22.255.254\n   DNS        : 172.22.0.101\n                172.22.0.102\n   WINS       : 172.22.0.101\n                172.22.0.102<\/pre>\n
PRT2 PVS<\/strong><\/p>\n
   MAC        : E8-39-35-BC-48-46\n   IP-address : 10.3.0.72\n   Subnetmask : 255.255.0.0\n   Gateway    : \n   DNS        : 10.3.0.10<\/pre>\n
 <\/p>\n
Wireshark<\/h4>\n
A network trace in Wireshark<\/a> showed the network requests that where sent:<\/p>\n
Domain Name Service(DNS)<\/strong><\/p>\n
9336\t15:41:46.112480000\t10.3.0.72\t10.3.0.10\tDNS\t79\tStandard query 0x7029  A S-FB02.(domain name)\n9340\t15:41:46.112785000\t10.3.0.10\t10.3.0.72\tDNS\t95\tStandard query response 0x7029  A 172.22.30.46<\/pre>\n
Resolving the name S-FB02<\/strong> to an IP address is done via DNS, right after pwwsmgr.exe<\/em> logged the application in the REStrace.log. The response was given in a few milliseconds and returned the ip address 172.22.30.46<\/strong>.<\/p>\n
Remark: The DNS request was sent via the pvs<\/em> network, which it shouldn\u2019t (wrong NIC priority). Fortunately the pvs <\/em>network has a stub-zone for the same domain,<\/p>\n
 <\/p>\n
NetBIOS Name Service (NBNS)<\/strong><\/p>\n
9330\t15:41:46.119338000\t172.22.5.72\t172.22.0.102\tNBNS\t92\tName query NB S-FB02<20>\n9331\t15:41:46.119581000\t172.22.0.102\t172.22.5.72\tNBNS\t104\tName query response NB 172.22.30.46\n9337\t15:41:46.112495000\t10.3.0.72\t10.3.255.255\tNBNS\t92\tName query NB S-FB02<20>\n9485\t15:41:46.848322000\t10.3.0.72\t10.3.255.255\tNBNS\t92\tName query NB S-FB02<20>\n9601\t15:41:47.598340000\t10.3.0.72\t10.3.255.255\tNBNS\t92\tName query NB S-FB02<20>\n22998\t15:42:32.599479000\t10.3.0.72\t10.3.255.255\tNBNS\t92\tName query NB S-FB02<20>\n22999\t15:42:32.609878000\t172.22.5.72\t172.22.0.102\tNBNS\t92\tName query NB S-FB02<20>\n23000\t15:42:32.610088000\t172.22.0.102\t172.22.5.72\tNBNS\t104\tName query response NB 172.22.30.46\n23111\t15:42:33.345706000\t10.3.0.72\t10.3.255.255\tNBNS\t92\tName query NB S-FB02<20>\n23214\t15:42:34.095805000\t10.3.0.72\t10.3.255.255\tNBNS\t92\tName query NB S-FB02<20><\/pre>\n
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<\/strong>. <\/p>\n
The same request is sent via the pvs <\/em>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<\/em> network.<\/p>\n
After 46 seconds <\/strong>the request is repeated, apparently the system was satisfied.<\/p>\n
 <\/p>\n
Address Resolution Protocol (ARP)<\/strong><\/p>\n
9329\t15:41:46.115273000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n9633\t15:41:48.127141000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n9753\t15:41:49.048990000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n9950\t15:41:50.627077000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n10255\t15:41:53.126873000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n10296\t15:41:53.533092000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n10446\t15:41:55.064234000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n10913\t15:41:58.629237000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n11105\t15:42:00.129075000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n14880\t15:42:11.628545000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n16375\t15:42:20.562882000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n22986\t15:42:32.592154000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n23264\t15:42:34.624671000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n23415\t15:42:35.546457000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n23629\t15:42:37.124595000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n23932\t15:42:39.624402000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n23993\t15:42:40.015005000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n24222\t15:42:41.561767000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n24734\t15:42:46.045997000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72\n25184\t15:42:49.626624000\tHewlettP_bc:48:44\tBroadcast\tARP\t42\tWho has 172.22.30.46?  Tell 172.22.5.72<\/pre>\n
The system wasn\u2019t 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).<\/p>\n
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 <\/em>(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).<\/p>\n
After sending 20 requests<\/strong> and getting no answer <\/strong>the system returns with an error: No network proivder accepted the given network path.<\/p>\n
<\/h4>\n
\"No<\/a><\/p>\n
 <\/p>\n
Conclusion<\/h2>\n
The feature to hide an application if the executable does not exist is a nifty feature, it\u2019s 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. <\/p>\n
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.<\/p>\n
What adds to the frustration is the difficulty to troubleshoot the issue: there\u2019s no indication why there\u2019s a big delay. So here\u2019s a feature request for RES: Please add a warning in the users\u2019s event log (workspace analysis) so the admin knows what\u2019s causing the delay.<\/p>\n
Example:<\/h5>\n
\"TestDesktop05<\/a><\/p>","protected":false},"excerpt":{"rendered":"
Users who logon with RES Workspace Manager 2011 experienced a long delay ( > 1minute) and mentioned that the Workspace composer hangs at \u201cPreparing Applications\u201d. 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 \u201cHide application if executable […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"site-container-style":"default","site-container-layout":"default","site-sidebar-layout":"default","disable-article-header":"default","disable-site-header":"default","disable-site-footer":"default","disable-content-area-spacing":"default","footnotes":""},"categories":[290],"tags":[39,485,487,486,372],"class_list":["post-4134","post","type-post","status-publish","format-standard","hentry","category-workspace-management","tag-res","tag-trace","tag-wireshark","tag-workspace-composer","tag-workspace-manager"],"_links":{"self":[{"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/posts\/4134","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/comments?post=4134"}],"version-history":[{"count":3,"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/posts\/4134\/revisions"}],"predecessor-version":[{"id":4143,"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/posts\/4134\/revisions\/4143"}],"wp:attachment":[{"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/media?parent=4134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/categories?post=4134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ingmarverheij.com\/en\/wp-json\/wp\/v2\/tags?post=4134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}