Group Policy: Mapped Drives via Client Side Extensions and UAC
Introduction
Most people remember the good old times of scripting, when everything that needed to be done on mass deployment was dumped into a file in plaintext format and saved in the ‘netlogon’ directory shared out from any domain controller on the network and the users that needed it would be configured with the simple name of the script. It was good times, with every person organizing the scripts how they want (one script per user, one script per department, or one script period with If-Then verifiers to direct the flow of the script and provide whatever is necessary) it was quite simply good old fashion chaos.
Windows 2008 UAC
Along came Windows Server 2008 – the introduction of User Account Control, and suddenly anyone used to using the \contoso.local\netlogon path to save/modify scripts was in for a shock as Access Denied errors were being thrown left and right. People quickly determined a work around was to design the script in a normal directory and then copy it into the actual local path of the netlogon folder (%windir%\sysvol\sysvol\domain\scripts), this way they would be prompted with UAC to copy the file but it would go successfully. The workaround however did little alleviate the frustration for people directly modifying the scripts already located there, and it took some more time for word to spread that if you launched Notepad as administrator (right click on it, and Run As Administrator) then you would be able to directly change the files hosted in the sysvol directory –although sadly the \contoso.local\netlogon path is still out of reach.
Group policy & UAC
Let’s jump to a newer generation, more used to change, and take a look at how the ‘correct’ method for deploying printers and mapped drives are as of Windows Server 2008. Group Policy Objects have been around for a long time, and while they were nice to setup restrictions and certain windows settings did little in the way of mass deployment for printers and mapped drives. In Windows Server 2003 R2 a method came out on how to deploy printers via Group Policy objects, unfortunately it was sloppy, not intuitive and required the ‘pushprinterconnections.exe’ client to be run on every client which was achieved with…login scripts obviously.
The Mapped Drives and Printers CSE (Client Side Extensions) option in Group Policy introduced in Windows Server 2008 was a huge change, where it was –more or less- intuitive and also didn’t require any extra configuration; except one caveat. Windows XP and Windows Vista required that you install Group Policy Client Side Extensions update from Microsoft Update. Without this update, the settings wouldn’t work. So let’s get to the guts of it, assuming you setup a Group Policy Object labeled Mapped Drives, and configured two mapped drives. Now you have the policy linked to the entire domain so every user should have a S: and U: drive, however due to some unknown issue three computers don’t have the drives showing up, where do you go to diagnose and how do you resolve it?
Generally speaking, what you want to do is force a gpupdate first (from command line gpupdate /force), pay attention to the results of the gpudpate and make sure no errors occur. Also at the same time pay attention to the Event Viewer Application logs as Group Policy errors will be listed there for every CSE object that fails to apply, along with a reason for the failure.
If your gpupdate /force finishes and the drives aren’t showing up, your next question is (before you logoff and logon); what version of Windows am I running? It’s worth noting that Windows XP, Windows Vista, and Windows 7 will always prompt you to logout at the end of the gpupdate /force in the event a CSE object was successfully applied that requires you to. While printers will apply without requiring a login/logout, Drive Maps will always require you to re-login after being applied and gpupdate should prompt you to logout. If you’re not getting that prompt either
Drive maps weren’t applied successfully because they or the policy was filtered out (check RSOP, GPRESULT, and the Link of the GPO as well as Item Level Targeting for each drive)
The version of Windows running doesn’t have the ability to read the CSE options and apply them successfully. If you’re running Windows Vista, or Windows XP this is when you want to hit the Windows Update site and download the optional update ‘Group Policy Client Side Extensions’ once that’s installed, reboot and gpupdate /force to ensure you’re being prompted to logout.
Please note that being prompted to logout is NOT an automatic sign that the Client Side Extensions are installed, in the event another policy is enabled that will require logout (like Redirected Folders) you will still be prompted to since it’s not related to Mapped Drives. If you’re being prompted, follow the rest of your diagnostics and if you can’t find anything else to be the cause come back and check Windows Update.
If you are getting that prompt, the check Event Viewer and look for an error, if there’s no error at all then we’re back to 2a, you’re filtering the policy or object out. Check your links and Item Level Targeting to make sure they’re set correctly. If you’re getting an error in event viewer it’ll most likely be something along the lines of ‘Access Denied’ or ‘path not found’ either one of those is fairly self-explanatory on how to resolve so I won’t go into those here.
The final thing you want to be on the lookout for, and for this one we actually had to get Microsoft PSS involved since it was under a time constraint and couldn’t figure it out fast enough; is make sure you logout and login twice in the event it doesn’t work. Sometimes it will happen where the computer is acting faster than the network, and in these instances the Group Policy object will try to apply the drive map before the network is ready for it causing it to error out with a path not found. A second logout and login brings the drives up normally but you’ll notice this occur every OTHER login where it works, and doesn’t work. The solution here is to set a Computer Policy GPO (or part of the same one) to ‘Always wait for network at Computer Startup and Logon’ (see http://technet.microsoft.com/en-us/magazine/gg486839.aspx)
There is one more gotcha that comes into play as of Windows Vista. User Account Control plays absolute havoc as we're sure the designers didn’t understand how far reaching the implementation of UAC would be when the idea first came about. The quick answer to this one is turn UAC off, however we strongly recommend you leave it ON always. We happen to be a huge fan of UAC, both because of its complexity and the challenges it provides in the life of Senior Technical Lead and (less importantly) because of the security it provides, without it we would be wasting a lot more of my time cleaning viruses and infections than we would be fixing interesting things –like how to make old programs work around UAC.
In a very very oversimplified description of how UAC works, it creates two on the fly profiles for every Admin account. In the event an Administrator (irrespective of local admin or domain admin) is logged on to a system, he’s actually running on what’s known as a ‘limited profile’ which is unable to actually do anything outside of itself. Any global settings will require elevation in order to be adjusted or changed. Clicking ‘yes’ (or continue for Vista) is quite literally opening the doors to whoever the 'yes' is for, and saying ��Make yourself at home!’. It is important to note that anything running elevated runs under a separate profile that for security purposes anything running on the Limited Profile is not able to access, and anything on the Elevated profile itself, can’t interact directly with anything on the Limited Profile either.
None of the extra security really causes a problem, at least not for us in this context; there are hundreds of developers that hate UAC out there and of course every Corporate IT administrator that has to support software from 2008 and older has a POA where the first step is to turn it off. The issue we’ll experience here is with the multiple profiles. Even though they’re not REALLY two separate profiles, because of the way UAC forces Windows to restrict the interaction between the Elevated profile and the Limited profile, the drive maps (which are PROFILE specific) will not cross from the limited profile to the elevated profile, and vice versa.
This generally isn’t a problem, as it seems for Windows Vista and Windows 7, during logon the limited profile is loaded first and therefore the drive maps display correctly under both Users and Administrator accounts. It is something to keep in mind however, because if an admin needs to run an application hosted on a map drive (or relying on a mapped drive) they won’t be able to since the mapped drive isn’t available on the elevated profile. The way around this is to launch command prompt as an admin and then use the net command to map the drive for the Elevated profile. (“net use x: \servername\share”), obviously this isn’t a permanent solution but can be used for one time installs and upgrades, a permanent solution would be to find a way to run the application under the normal limited profile.
Wrapping up, Windows 8 it seems switched the way logon occurs, and if you’re an Administrator the logon occurs Elevated. Because of this, drive maps get mapped under the elevated profile, so when Explorer launches under the limited profile the drive maps actually don’t happen. A lot of you might remember when Windows 8 first came out, Drive Maps published via Group Policy weren’t visible on Administrator accounts, Microsoft eventually fixed this however the logon still occurs during elevation which still causes one more issue that Microsoft has yet to resolve. I’ve been unable to find this referenced anywhere else, but the issue is in the event you’re using Drive Maps going to a NAS that’s not on a Domain and therefore you have saved credentials in Group Policy (or anytime you have saved credentials in Group Policy) on a Windows 8 client, the drives WILL map, however you’ll be unable to open them with the error: “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.” (See KB: http://support.microsoft.com/kb/938120 to see this behavior is by design)
So far the only workable solution found for this is to (unfortunately) turn UAC off.
If anyone has come across this and come up with a fix, PLEASE comment/edit this article and let us know.
Glossary
| UAC | User Account Control |
| NAS | Network-Attached Storage |
| GPO | Group Policy Object |
| CSE | Client Side Extensions |
| RSOP | Resultant Set Of Policy |
| POA | Plan of Action |
| PSS | Product Support Services |