More testing of Windows 8 at my organization revealed another problem to troubleshoot. Our desktop management group policy automatically mapped a drive using Group Policy Preferences and mapped another through a logon script. The purpose of the logon script was to use local variables and map the drive directly to the folder with the user’s username. As it turns out, apparently logon scripts in Windows 8 behave a little differently than in Windows 7 where the script was working just fine.
The batch script was a straight forward ‘net use’ command to get the drive mapped with the %username% variable. A PowerShell script had the same results. The interesting trick was that the drive was actually getting mapped, it just wasn’t visible.
If you ran ‘net use’ in a command prompt, it would only list the one drive that used Group Policy Preferences and was visible under Computer. However, if you ran ‘net use’ in an elevated command prompt, it would list both drives as mapped, through Group Policy Preference and the logon script.
With logon scripts running at the highest privilege, apparently the drive was being mapped as administrator and not the regular user. There were two options, disable UAC completely (type ‘UAC’ in the Start Screen and slide the selector to the bottom) or use a Group Policy Preference instead to map the drive. Since I believe UAC has some value in protecting users from malware and software running without permission, I opted for the second route. I added to the already existing Group Policy a new preference for a new drive to be mapped.
Remember, you can find a list of System Defined Variables by pressing F3 when in the Drive properties. I set the Location of the drive to \ServerShare%LogonUser% and the drive mapping worked perfectly. I disabled the logon script and tested a few different instances on Windows 7 and Windows 8 to great success.
