We are running Windows 8.1 Pro x86

I am really curious as to why the drive restriction group policy causes the error message to pop up:

"This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator."

It does not prevent from actual saving so functionality is not lost but it really annoys our end users and we're getting a lot of complaints. We cannot use the workaround of hiding drives instead of restricting as this still presents security issues. This is happens when saving (or clicking on a button like "Browse" that opens the 'Open' dialogue box) in all Office 2013 applications, Internet Explorer, Paint, Notepad, and probably most others. I've looked at many forums and no suggestions for workarounds have succeeded for us to get rid of this error message and in fact, I read a post that stated that someone contacted Microsoft and they said this was by design and there is no workaround. I find this very unfortunate that we either have the choice of compromising security or annoying our end users. It seems to me like the new dialogue box in Windows 8.1 (and maybe 8?) attempts to access the local drive under the logged in user's account before it actually opens up the dialogue box which conflicts with the group policy that restricts access to the drive.

Has anyone at all had any luck getting this to go away without removing the restrictions? It seems like the answer is either buried in the Windows code or somewhere in the registry.

Thank you in advance for your time!

Hi,

I tested this issue in my Windows 8.1 machine, after I set a drive registriction via group policy, update the policy, I also encountered the same error when I click Open or Save as

 I have another E drive available, after I click "OK", then contiune to open\save in E drive, the process is performed successfully. Next time, when I click Open\saves it will automatically rediected to E drive and passes the restrictions error message. Seems this is the default behaviour. Maybe we can treat this as a workaround.

Thank you for your time and response! Unfortunately, we have the machine locked down pretty tight (they are public use computers that require heavy restriction) and it is set to restrict all drives so access is limited to the local profile. We did try testing your method, however, by adding the Desktop as an allowed location in the Office policy (which would not solve the issue for the other applications but was good for a test) using the path %userprofile%\desktop. When choosing that location, it does not throw the error but unfortunately, it does not remember like it did for your with the E: drive so it still always throws the error when first loading the dialogue box no matter what I do. If you're able to confirm that this is simply by design and we're just expected to inform our users to click through the errors, then I guess that's the accepted answer. Although, do you think that there might be a registry key value that is set after you save to the E: drive for the first time? Maybe we could set that value to %userprofile%\desktop if it's doing the redirection after the first save through registry. Thanks again!

UPDATE: It seems that after the first save on the desktop for Internet Explorer and Paint (not sure which others yet) it stops throwing the error but still can't bypass the error in Office applications.

Hi,

Same result as yours, fine with internet Explorer and notepad or other applications but in my Office application, seems it doesn't remember my choice and insists informing me of the restrictions. I'm afraid to say thatit's by design.

I've tried to use process monitor to trace the process but didn't find any valuable information.

If you have interests, I'd like to share process monitor with you:

https://technet.microsoft.com/en-us/library/bb896645.aspx?f=255&MSPPError=-2147217396

Thank you for testing this as it is nice to see consistency! We have run Process Monitor and came up with the same results that nothing seemed out of the ordinary. To me it just seems that no matter what, Office applications always attempt to access the local C: first before accessing any other location. What is your opinion?

UPDATE:

It seems that I have found an interesting workaround. It turns out that, when saving an Office document by choosing the browse button for saving to OneDrive (takes a little longer to load), the error message does NOT present itself. Then, If I choose the Desktop location under Favorites in the dialogue box (I can't remember if that was always available as a favorite or one that we deployed as %userprofile%\desktop), it also does not throw the error message and lets you save to the desktop. Choosing anything else other than the Desktop location listed under favorites or saving to OneDrive seems to cause the error message to pop up so you have to be careful. I suppose this would require OneDrive to be set up properly for Office but I am totally out of ideas for what else could be used as a workaround. Must be part of Microsoft's push to ease users onto the cloud? We are planning on utilizing OneDrive in our scenario so the workaround may be acceptable (although it may be the only one).