A case was recently logged by one of my customers about problems with Windows Explorer as a published app.  Here is the problem description which I have copied from the case verbatim:

Customer tried to publish Internet 7 Explorer [sic] with the -e switch as a Windows Explorer replacement as per CTX922603 but this switch has been deprecated in IE7. Customer then tried to publish Windows Explorer but cannot see mapped drives.


What was the customer trying to do?

The customer environment is a large (>200) XenApp 5 HRP06 farm on Windows Server 2003 with SP2.

Internet Explorer 6 was published with the –e switch to run the app in explorer mode.  End users would sometimes map their own drives and these would then be displayed in the user’s session.

The customer was planning to replace IE6 with IE7 in their standard build for their XenApp servers. When publishing IE7 with the –e switch they found that Internet Explorer was no longer opening in Explorer mode.  Crucially if the user mapped a network drive in the session it was no longer being displayed in the list of network drives.  When running IE7 with the –e switch the customer experienced the issue described here: http://support.citrix.com/article/CTX112195.

The customer opened a case and I started to investigate this.  I found the following article on the Microsoft knowledgebase advising that the –e switch had been deprecated in IE7 (and future versions) as part of the separation of Internet Explorer from the shell: http://msdn.microsoft.com/en-us/library/ee330728(VS.85).aspx and a further article explaining how IE was being separated from the shell: http://support.microsoft.com/kb/928675.  From this we knew that we could no longer rely on IE to work around our drive mapping problem.  Future versions of IE will also not include this option.

So we then tried publishing Windows Explorer but found that he still could not see the network drives if he mapped them inside the session.  This seemed to leave us with no real way forward.


Mapping Drives

As I am sure all Windows admins know Explorer.exe is both the Windows Shell and the File Manager application for the Windows OS.  If you want to give your users the Windows file manager application then you can publish Explorer.exe as a seamless application.  XenApp has a function that monitors for Explorer.exe being launched as a published app, and prevents it from running in shell mode.

If we did not intercept explorer.exe in this way then a full desktop would ALWAYS be shown if you tried to launch explorer.exe.  The hook we use to prevent Explorer running in Shell mode can be disabled in the registry so that Explorer always runs in shell mode.  This is described in http://support.citrix.com/article/CTX108784.

When you map a network drive, an Operating System call WM_DEVICECHANGE is made to shown the addition of a device (WM_DEVICECHANGE is described on Technet here: http://msdn.microsoft.com/en-us/library/aa363480(v=vs.85).aspx).  This call is a shell call hence why the non-shell explorer.exe does not show the addition of the new drive.  The drive has in fact been mapped; if the user was to then open Notepad (for example and assuming session sharing kick in) the new drive would be visible.


How did we resolve the issue? 

Well, the short answer here is; we didn’t.  The issue of mapped drives appearing in Windows Explorer is a limitation of Terminal Services, and XenApp is unable to work around this. 

There is a Microsoft knowledgebase article that describes this problem in Windows Server 2008 R2: http://support.microsoft.com/kb/2508359.  We know from this case that this problem also occurs in Windows Server 2003.

Where possible I try to either resolve a case or at least give my customer a number of options to work around an issue.  It is easy (but not always very professional) to simply ask a customer to speak to another vendor about an issue.  In this case though, I was forced to ask my customer to raise this with Microsoft, and see if they can produce some sort of code update that may resolve this in the future.