QuickPost – publishing Windows Explorer in Citrix and RDSH

I know that many customers using virtualized solutions such as Citrix Virtual Apps or Remote Desktop Session Host often publish an instance of Windows Explorer (or File Explorer, as it is now known) to allow users to browse filesystems and network shares. But is doing this such a good idea?

Vendor stance

It’s difficult to get a steer, either from Microsoft, Citrix or any other vendor, as to whether you even should publish an instance of File Explorer. File Explorer (explorer.exe) is actually the full Windows shell and has a significant amount of processing and functionality attached to it. Users in published application environments often like to use it, as it gives them almost a “semi-desktop”, allowing them to navigate around filesystems and invoke applications from within the same session, and often you may even see savvy users invoking it from within other published applications. From an administrative perspective, though, it can be a pain – the seamless integration with the local desktop can often cause confusion and if access to virtual channels is restricted, there’s the potential for a lot of frustration.

Citrix have a document published that explicitly states “Microsoft does NOT recommend running Explorer.exe as a published application because the published Explorer.exe application runs as a separate process with restricted access to the desktop“, but this is an old technote and still lists “XenApp” and “XenDesktop” as the products it applies to. In conversations with Microsoft, they seem reluctant to be drawn on whether they actually recommend this or not. The same goes for Citrix – they appear reluctant to nail their colours to the mast regarding this issue, and this probably boils down to the fact that they know they have large customers who publish File Explorer as a matter of course, and don’t wish to upset those applecarts. In a support situation, they possibly may lean back on any oddities around a published version of File Explorer as caveats towards the “we generally wouldn’t recommend this” approach.

Years ago, it used to be common practice to create a copy of Windows Explorer and call it explorer2.exe or something similar, but this shouldn’t be done any more. This can cause your session to become unresponsive, as there are certain internal dependencies that the application requires (I’ve seen this same odd behaviour when copying executables such as the Registry Editor to other folders or locations as well).

I’ve often heard it mentioned that a published File Explorer is preferable to publishing a shared desktop, as it uses less resources. There’s an element of truth to this – a published Explorer session uses approximately twenty processes (in my lab), whereas a full desktop on the same machine uses twenty-eight processes, but the overhead of those extra eight processes is almost completely negligible once the logon is completed. In terms of user density, I struggle to see how there is any benefit to publishing Explorer + apps in a shared session, rather than a full desktop.

In terms of desktop versus apps, I also personally prefer to publish a desktop, because it offers a self-contained “bubble” that the user works within, rather than having to have applications integrated with their local desktop. Obviously this is a personal preference and many enterprises like the published applications approach because of that very integration with local apps, but I can’t help but think that publishing File Explorer in this model just leads to confusion. YMMV, IMHO, etc.

So as far as publishing File Explorer goes, it remains very much a muddy, murky area in terms of support. I think it is best to categorize it as “supported, but not encouraged as a best practice”.

Options

If you are intent on publishing File Explorer, there are a number of ways that Citrix recommend doing it to get the best performance.

Standard published Explorer

You can publish it simply by setting out an application pointing to c:\windows\explorer.exe as below

In later versions of Windows, this seems to work moderately reliably, but it can be temperamental. You can add a command line option to make the Explorer window open in a particular folder, if required (the below example added a command-line option to an H: drive which is the user’s home folder)

You can add other paths to the parameters to open File Explorer at other folders – even Windows special folders (which you can add by using things like shell:mycomputerfolder)

There are also a bunch of switches you can use with File Explorer, which need commas before any further parameters after the switch

• /e – opens with default view
• /separate – opens in separate process (e.g. explorer.exe /separate)
• /select [object] – selects the file or folder in the window (e.g. explorer.exe /select,c:\windows)
• /root [object] – opens a window view of the object (e.g. explorer.exe /root,c:\windows)
• /expand [object] – expands a view of the specified object and accepts environment variables (e.g. explorer.exe /expand,%programfiles%)

And there are also some undocumented ones that I have no idea what they do as well, feel free to test!

• /LoadSavedWindows
• /Factory
• /NoShellRegistrationCheck
• /NoUACCheck
• /NoShellRegistrationAndUACCheck
• /RunFirstLogonAnim

Published through the browser

If you have any issues when publishing File Explorer or when users are running it (and you may well do, it can often behave pretty unreliably), there are a few other ways you can skin this cat. One of these is publishing Internet Explorer with a drive path as a parameter. Obviously, though, Internet Explorer is not intended to be around for that much longer, so there may be a slight lack of longevity in this method.

You can’t do the same with Chrome and Edge Chromium, however, as these browsers open the filesystem within their own browser window rather than spawning an instance of File Explorer.

Citrix published content

Another option, if you have issues with publishing File Explorer directly, is to use Citrix to publish content (assuming you’re running Citrix!) You can publish files, documents, local folders, URLs, UNC paths, FTP paths, etc.

Publishing content always feels a bit weird because you have to do it from the command line rather than through Studio. You will need to run the commands from the DDC or a client with the Citrix PowerShell modules loaded

asnp Citrix*

New-BrokerApplication –ApplicationType PublishedContent –CommandLineExecutable [UNC path or folder path] -Name [published application name] -DesktopGroup [Delivery Group name]

Once this is done, you should see the application appear in Studio

This should work in pretty much the same fashion as the other options above.

Third-party utilities

There is also the option to publish a third-party file management application rather than using File Explorer itself. Whilst this is a perfectly feasible option (and you can run self-contained executables rather than a full installation), unless your users are used to using the application in question, it can become rather frustrating and unproductive for them. If you do choose to go this route, there are loads of options out there. Shown beneath is Explorer++, which is one of the simpler ones.

Some known issues

There are a few issues around published File Explorer instances, besides the usual “it’s a bit unstable and we don’t really think you should use it as a quasi-desktop” reaction.

Firstly, you can see problems where the published Explorer instance fails to launch or launches and disappears, due to an old Terminal Services timer. This can be rectified on Citrix platforms by setting the following Registry value

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI
Type: DWORD
Value: LogoffCheckerStartupDelayInSeconds
Data: 00000010

On some operating systems, you may see issues with the files and folders not updating correctly in your published File Explorer (whether this be content or timestamps). Apply the following Registry value to resolve it

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\EXPLORER.EXE
Type: DWORD
Value: DontUseDesktopChangeRouter
Data: 1

Another common issue with published Explorer instances is other processes not exiting correctly when the session is closed. Because this is essentially the Windows shell, many (but not all) of the processes you see active within a desktop session may also launch. Pay particular attention to AV processes, Citrix WEM agents or other profile management tools, App-V or other application delivery technologies, etc. – anything that appears to stay open after the user has exited the primary application. On Citrix platforms, the LogoffCheckSysModules Registry value may help address this.

Windows 10 and search failures when using published Explorer

Now, we are going to have a special section dealing with Windows 10 and some possible problems with published File Explorer. “Hold on,” I hear you shout, “why on earth would anyone publish an application on Windows 10?” Well, let’s not forget we now have something called Windows 10 Multi-User which runs on Azure Virtual Desktop, and Microsoft are trying to generate a lot of traction in this space. Azure Virtual Desktop doesn’t just do desktops (despite the confusion the name generates) – you can do published applications. And if you’re invested into the operating system, and you’re a pure published applications shop, and you’re one of those odd enterprises who like to publish Windows Explorer – then you might well find that you want to do it, despite Citrix and Microsoft surreptitiously suggesting that it’s probably not a good idea.

The good news – publishing File Explorer on Windows 10 Multi-User (or, indeed, Windows 10 single-user, although why you’d do that would be a mystery) works OK. The application starts and renders fine.

The bad news – the Search functionality is broken. It’s not that the search fails, or can’t find anything, or throws an error – you physically cannot click into or use the “Search This PC” function in the top right-hand of your published Explorer window. Given that users have these Explorer instances to browse (often very deep and complex) filesystems, hobbling the Search functionality completely is a pretty big blow.

Now there are some instances where it works. If you take the brokering out of the equation (be that Citrix, VMware, whatever) and publish an instance of File Explorer on pure native Azure Virtual Desktop, the Search works fine. If you publish a full brokered desktop on Windows 10, it is fine, and if you publish the File Explorer application on a brokered Server OS, it also works fine. It’s only specifically on Windows 10 (any version) with a published File Explorer where there is a third-party broker in the equation. You’d think that Citrix might recognize this as a bug, but they actually claim it works in their labs (although I tried six different environments and they all failed), so I was batted back to Microsoft’s RemoteApp team, who promptly batted it straight back to Citrix. Clearly, there aren’t enough people doing published Explorer on Azure Virtual Desktop via Citrix (or any other broker) for it to generate much concern.

All the other tricks mentioned above also fail in exactly the same way – the app launches OK but the Search functionality is unable to be used. Running as an administrator has the same issue, calling File Explorer from other apps generates the exact same problem, running multiple instances makes no difference, starting the Search service makes no difference (I didn’t expect it to, given that the service is used for indexing, rather than simply being able to search), and old tricks like AlternateShellStartup also have no positive effect.

But – I did find one, peculiar, way of making it work. If you launch the executable for Control Panel – control.exe – this actually launches File Explorer. For a long time, the Control Panel has simply been a special folder within the shell itself, so it needs File Explorer to function. The key is though, if you call Control Panel this way, the published File Explorer instance has a functional search!

But a user doesn’t want to start their published Explorer in the root of Control Panel and have to browse up – we want to allow them to be at My Computer, My Documents, Desktop….wherever they are used to it opening. How can we do this, to leverage the Control Panel’s secret powers and solve this Windows 10 Search issue?

The key is – well, keystrokes. If you can send the required number of keystrokes to the published application as it launches, you can navigate the user into the required folder. You can do this with PowerShell (here’s a handy guide to many of the keystrokes) – simply launch control.exe, wait for a specified period, then send the required keystrokes. In its simplest form, you can just hit Alt + UP ARROW and the window will move up a level to the Desktop. Here’s the code for that (the % is the ALT key)

control.exe
start-sleep 2
$wshell = New-Object -ComObject wscript.shell;
$wshell.SendKeys('(%("{UP}"))')

which takes you to this view in published Explorer (with functional Search!)

If you want to navigate to other folders (for instance, This PC), then simply add the required keystrokes. We’ve added in {UP} (up arrow) and {ENTER} after 1 second delays – the delays may not be needed, dependent on testing

control.exe
start-sleep 2
$wshell = New-Object -ComObject wscript.shell;
$wshell.SendKeys('(%("{UP}"))')
start-sleep 1
$wshell.SendKeys('{UP}')
start-sleep 1
$wshell.SendKeys('{ENTER}')

This takes the user to this view as the root for their published Explorer

One thing to bear in mind is getting the delay right (an environment I did this in had the WEM agent starting up which caused a slight delay for the keystrokes to be sent).

You can then either set up a published app that calls powershell.exe with the execution policy and the script set as parameters

or, if you’re working in an environment where PowerShell scripts cannot be launched by the user, you could compile it into an executable using something like PS2EXE (although some AV scanners may choke on this) and then publish that executable to call the required applications

This is the only solution I’ve managed to find to the problem of publishing Explorer on Windows 10 (which should normally only be done on Multi-User) – hopefully an update will address it at some point but until then that should serve as a workaround.

Summary

Is publishing File Explorer a good idea? In my experience, it’s a bit of a pain and something that the vendors may well try to hide behind, but we have to accept the fact that not only do many places do it, but a lot of users also leverage the capability to run File Explorer from within a published application session so they can have a “desktop lite”. Given the choice, I’d always prefer to run a full desktop, but the pointers in this article should allow you to deal with published Explorer instances if they are active within your environment.

Coming soon – more logon times stuff, FSLogix and Teams, as well as some performance testing within the browser. Stay tuned!