QuickPost – Citrix published applications don’t refresh Explorer views

A quick bit of problem-solving today, as I’ve just noticed this issue reappear when it was previously fixed.

When you’re publishing Citrix Virtual Apps on Server 2019 or an upstream version of Windows 10 (including Windows 10 Enterprise Multi-User, which I concede is the Windows 10 version you are most likely to publish applications on), you may notice this odd and slightly annoying issue. When a user is in a “common file dialog” (so they’re using something like the Open or Save As menu in an application, and it allows them to browse using the Explorer interface), if they create a new folder or file, the view isn’t automatically refreshed, hence the user can’t see their new folder or file until they refresh the view manually. The same problem applies if they were to delete a folder or file from this dialog – there’s no refreshing of the view, so the user must run a manual refresh before the file or folder disappears. There’s a short video of me demonstrating the problem in action below.

“Well that’s not that much of an issue, they can just press F5,” I hear you say. That’s true – but what if the user doesn’t know how to initiate a manual refresh, or if they spend a long time each day making new folders and files whilst performing their daily tasks? Why should they put up with or try to work around this particular problem, when it wasn’t a problem on the previous version of the operating system? In truth – it was a problem on Server 2016, but it was fixed by a patch from Microsoft….and now they’ve reintroduced the same issue.

The actual problem lies with how Citrix’s implementation refreshes the view, and that Windows Server 2019 (or later) operating systems don’t respect this. Citrix issued an advisory around this along with a workaround – it’s linked here – but this technote a) doesn’t mention that it affects published apps on Windows 10 and Windows 10 MU as well, and b) that it doesn’t just affect published instances of explorer.exe – it actually affects all published applications.

The fix is correctly referenced within the Citrix article, but it needs to be taken a step further.

The Registry value in the article is the one you need to change, but the key part is – you need to put in a separate entry for every published application process you have.

Firstly, obtain the published application process names. If we had published versions of Explorer and Notepad++, for example, these are the process names we would have:-

• explorer.exe
• notepad++.exe

Next, create Registry keys under the following root key for each process name (including the .exe extension)

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\processname.exe

So in this example I’d create two Registry keys

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\explorer.exe

and

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\notepad++.exe

In each of these keys named processname.exe, you need to create an identical value within:-

• Key – HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\processname.exe
• Value – DontUseDesktopChangeRouter
• Type – REG_DWORD
• Data – 1

Now, in keeping with this article being done in the medium of video (because it is kinda difficult to simply do screenshots to show refresh issues!), here’s me inputting the required Registry fixes.

And most importantly, does it work? Well we can address that in a quick video too 🙂

To be fair, this is quite an annoyance for users who rely on pure published applications. I don’t tend to do a lot of deployments where it is just published applications – and it’s even more rare to see them on Windows 10 or Windows 10 MU, but I guess that might start to change – but if you do encounter these sorts of deployment, it’s a pretty impactful issue, although not a show-stopper by anyone’s standards.

Obviously if you have loads of published applications it can be a pain to enumerate the required Registry values you need to implement the fix, but some creative scripting should be able to help you out. You could feed in the executable names by querying Citrix via PowerShell and simply create the Registry keys and their associated values from there – I may add this to the article if I ever end up needing to do it.

I am aware there are some other fixes floating around on the Interwebs for this issue (some a bit simpler), but this is the one that worked reliably in my environment. Obviously, for different deployments, your mileage may vary.

Stay tuned for some more logon times stuff which should be upcoming in the next week or so.