I need your help Server Based Computing / VDI Experts!

Hi Guys and Gals. I’m currently fighting the good fight with Microsoft support and require your help and backing in order to close down a long standing bug in the Windows Explorer Shell.

As you are all aware, hiding the c: drive and restricting access has been a utility we use frequently in shared computing and VDI environments. Restricting this functionality removes views of the shared drive from users and adds a layer of security and complexity* to ensure the users in question have access to only what they need in order to do their jobs day to day.

*I’m not looking to argue the merit of doing this either, it really depends on the business case or environment to dictate whether this option is set. I’m NOT saying it should be done in every case.

We all know it’s not fool proof, there are certain ways for users to circumvent this layer and I particularly don’t want to discuss them here to give potential devious users a landing page for idea’s!

The problem:

Prior to windows Vista, when you hide the c: drive and an application requests access to a c: drive folder, be it from an “open save dialog” or otherwise, Windows detects this event knows that the folder is restricted and merely redirects them to the desktop which they can see then browse to where they wish to open or save a document. This has worked fine to memory since windows server 2000.

But with the changes to Windows Vista’s windows explorer, repeating the above steps will result in the following annoying, unnecessary and interrupting error message “This operation has been cancelled due to.. bla bla blah”:


This issue can be easily recreated, simply hide and restrict the c: drive, then click start > run > browse… bang.

The more annoying problem here, is after the error message, windows simply redirects back to visible folder. In most cases this is the documents library. So the error message is simply poping up then reverting to the functionality seen in previous operating systems.

So to review:

  • Issue introduced in Vista / 2008 and above.
  • error message displays.
  • Previous redirect functionality is still there and occurs after ok is pressed.

To Microsoft!

Being a pedantic individual, along with my colleague we brought this to Microsoft support and somehow lost months in the conversation as follows:

  1. Microsoft then redirected us to RES Software.
  2. Who (although very nice about it) sent us back to Microsoft.
  3. At which point I got involved.

Now with the correct audience and suitable severity, this problem has been identified as “introduced in Windows Vista” as an “Added Security feature“. How an annoying pop up box, masking previous functionality is a security feature is anyones guess, but it’s bloody annoying…

We have raised this as a bug and have requested Microsoft to fix it. The change in question was deemed as large change or substantial change due to WIndows explorer being used by all of the operating systems and basically told, without significant backing, this change wont be implemented.

Bureaucracy and broken policies, yes but that doesn’t help my customer.

Here’s where I need you:

In order to bolster this change and fix an issue in our beloved operating systems for Server Based Computing and VDI environments I need to hear from you and your customers to confirm they have had this issue, or currently face the issue and wish for a fix.

  • If you are a customer and suffer this issue, email me.
  • If you are a consultant and have customers with this issue, email me.
  • If you or your customer have enterprise support with Microsoft, I ESPECIALLY want to hear from you.

What’s in it for you?

Microsoft have provided us a work around, as a process that watches window messages and suppresses this dialog box when it occurs. If you get in touch, I’ll recompile this application with Microsofts permission and pass it on to you for use in your environment while we get “The Man” to fix it!

This fix is a bit of hack, as it’s scraping window messages but it’s light weight and scalable. Use this process for now and I’ll provide you with updates on a fix as and when I get them.

How do you contact me?

Please drop me and email on andrew{at}andrewmorgan{dot}ie with the following information:

  • Customer name:
  • Affected users:
  • Has enterprise support: (yes/no)

Once I have that information, I’ll send you back an executable via dropbox and keep you updated on the call process. This information is merely going to be fed straight to Microsoft with my personal guarantee of confidentiality. No funny business.

If you can’t share customer information, but have suffered this issue in the past, no problem! Please comment on this blog post the number of seats that were affected and roughly how many times you’ve seen it.

That’s it!

Thanks for entertaining my request for help and hopefully you too want to get this issue fixed as much as I.

  1. Robert
    February 7, 2013 at 1:29 pm

    We’ve got the same issue – 60+ users are affected!

  2. Wayne
    February 7, 2013 at 3:22 pm

    Hi Andrew,

    I have seen this error affect about 100 users for a company at my previous company. I’m sure I shall see this again, so it would be great to see it fixed.



  3. Geert
    February 7, 2013 at 6:00 pm

    Seen it multiple times, affected users 100+, 40+, 200+

  4. February 7, 2013 at 7:24 pm

    Hi Andrew, yeah I’ve seen this a number of times as well. While WM makes it relatively easy to hide drives, unfortunately it drives this symptom to the surface; newer version Explorer doesn’t like having the C: drive hidden.

    One workaround which has been suitable in some scenarios is this: In RES Workspace Manager, chose the hide-drive option “Hide but allow access”. This in my experience prevents this from happening. Yeah, I know it isn’t perfect but at least it gets the C: drive off the user’s radar.

    If you combine it with some smart read-only blanketing security, it’s relatively little damage the user can do to the filesystem at that point.

    Hope this helps,
    Max @ RES

  5. February 7, 2013 at 7:53 pm

    We employ folder redirection for the common folders that users interact with and most applications default to the “My Documents” folder anyways (which, if redirected, won’t be on the C: drive). For Office apps, it’s easy to configure the default location (Options -> File Locations, or via GPO).

    Also, when we publish Explorer, we use this command line:

    C:\Windows\explorer.exe ::{450D8FBA-AD25-11D0-98A8-0800361B1103}

    Which ensures that Windows Explorer opens the user’s My Documents folder by default. Likewise, we modify the quick launch icon for Windows Explorer.

    It’s typically only with poorly written apps that we see that message pop up. Agreed though, it is really annoying and for some users confusing too.

    • February 7, 2013 at 7:55 pm


      I’ve seen this issue in word, lotus notes, winzip etc its annoying!

  6. alozzy
    February 7, 2013 at 8:12 pm

    For Office apps, you can also use the GP setting under “Microsoft Office 2010 -> File Open/Save dialog box -> Restricted Browsing”, which requires providing an explicit list of approved locations. It’s kind of cumbersome, but it does work if the user only needs to browse to a few locations (and any subfolders of those specified locations).

  7. frankvandebergh2
    February 7, 2013 at 9:30 pm

    We no longer use that policy setting at clients because restricting c: also breaks the instant start menu search feature when typing eg. Word

  8. February 8, 2013 at 12:26 am

    I agree, it’s a pain, and applaud you for trying to do something about it. Good luck with that. In the interim could you not use a script running in the background that uses the AppActivate and SendKeys functions? I’ve done this before to remove annoying pop up boxes so that users won’t complain. As you allude to, once you select OK (or hit enter) you get the desired result.

  9. February 8, 2013 at 10:18 am

    I am not sure what the workaround code does but if you could post what functions calls it is using with params. It needs to be a documented (MSDN documented) function to post. There may be a slick solution to fix these pesky apps that do this crap. Create an app compat fix /AKA basiclly a Detour http://research.microsoft.com/en-us/projects/detours/ if the bothersome app almost makes a poor programming error you can fix the bade code at run time by creating a Detour. Also there are some slick progrmming/debugging concepts which if used may help sort out some workable solutions.

    I’ve decided that virtualisation/virtualization is all a bunch of BS anyway. We as an IT world finally woke up and figured out that we have been doing everything wrong day one. Now we have all these little solutions to go patch things up and fix things. The cool thing is these pesky issues will always exist so we are in the right field 😉 Microsoft I think is trying to fix these issues long term by preventing the developers from writing crappy code and making sure that the OS has API’s that fix everything up in some black magic way. That is kind of what a Detour is.

    I would love to see 2 things, I have not tried to reproduce this yet. But 1) an xperf trace of the reproduction case 2) a user dump of the process that is currently displaying the dialog box, I assume here this is a shell thing so the process would be explorer.exe. But easier than that if you posted the “fix” API’s and params we may be able to come up with some create idea’s.

    Sorry just thinking outload here.

  10. Ian Aston
    February 10, 2013 at 5:17 pm

    Hi Andrew, give me a shout on email. I’d love to see this patched and happy to help in any way i can… 40,000+ affected users.

  11. Erik
    February 12, 2013 at 9:59 am

    many,many this.. from 20 users to 8000 users 😦

  12. February 19, 2013 at 8:31 am

    Like said on Twitter, we have seen this way to often not to get this fixed. With all reasons above MS should be able to work around this in a proper way.

  13. remi
    February 25, 2013 at 12:10 pm

    Hi Andrew same here 1300+ users

  14. March 11, 2013 at 9:42 pm

    Hello Andrew, I’d love to test your fix, just le me know by email. Thanks!

  15. March 12, 2013 at 9:30 am

    Hey all,

    Sorry for the delay, I’ve uploaded the Microsoft work around to my box.net account here:

    The delay was around me not being happy with Microsoft’s code, they were hard coding the message and as we may be dealing with multiple languages here it wouldnt have worked.

    Remember, I dont support this, Microsoft dont support this.

    This executable must be run in each users session, we’ve stress tested it to 30 users per machine and the performance overhead is tiny.


  16. Hans Hegeman
    March 12, 2013 at 7:32 pm

    It works great.

  17. April 10, 2013 at 8:58 am

    ~160 Users affacted and unhappy with it. Going to look into deploying your fix… though these OS things are hard sells.

  18. April 10, 2013 at 10:42 am

    Actually this was an easy sell! 🙂 Already tested and rolled out. Works like you would expect.

  19. April 25, 2013 at 2:44 pm

    We have found one problem with this. It seems at least some users (not much research into it yet) have a problem with the process lingering after “logoff”. This again causes “concurrent connection limit” problems because closing the last application does not trigger logoff. Clicking “log off” does, but many users just close all apps.

    I’d recommend adding RestrictedDrivePopupBlocker.exe to


    Value Name:LogoffCheckSysModules

    More info in http://support.citrix.com/article/CTX891671

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: