Windows 8 networks drives not mapping via logon script with UAC enabled

Many enterprises attempting to tackle Windows 8 may find themselves in the same predicament we did, whereby existing logon scripts fail to map network drives when UAC is enabled. Unfortunately this isn't as simple to fix as it was in Windows 8, well that isn't strictly true, it is easy to fix by disabling UAC, but you introduce another problem, metro apps no longer work.

For those uninitiated, metro apps require UAC enabled to work, and in most circumstances UAC breaks drive mappings.

The root cause of this problem is that drive mappings are occurring in the under the wrong permission token.

When UAC is enabled, metro apps work, but drives are mapped with the privileged token, so you can't see them under windows explorer but if you open a command prompt as administrator you will be able to access those mapped drives.

When UAC is disabled, metro apps don't work, drives are still mapped with the privileged token but windows explorer is also started with the privileged token, so the mapping are visible.

The trick is being able to leave UAC enabled so metro apps work, but still mapping the network drives in the non-privileged context so they appear in explorer. Chances are if you have a complex logon script with HKCU registry edits, you probably want some of your logon script to run as privileged user (registry) and some as non-privileged user (drive mappings).

We tested a number of solutions that all had some downfalls:

• Disabling UAC and forfeiting the use of metro apps
• Playing around with different combinations of UAC group policy options
• Using the EnableLUA registry setting

None of the above could deliver mapped drives and working metro apps, however there is a solution.

The Solution

We use Kixtart scripting internally, so ideally we would like to keep these scripts when moving to Windows 8. I stumbled upon a function called RunAsInteractiveUser that was designed for Vista and Windows 7. The RunAsInteractiveUser function leverages windows task schedulers ability to run a task as the interactive user, therefor inheriting the unprivileged token if UAC is enabled.

This function allows programs to be launched as the non-privileged user when being launched from a privileged process on a system where UAC is enabled. 

We did a simple modification to our Kixtart script, when a Windows 8 system launches the logon script, the drive mapping section is ignored but is spawned with the non-privileged account. The code goes something like this.

;**** Windows 8 override/skips
if instr(@producttype,"Windows 8")
 ;if UAC is specified, only remap drives, skip rest of script
  if ($input = "uac")
    goto remap
  endif
  $RC=RunAsInteractiveUser("\\contoso.info\dfs\scripts\logon\logonuac.cmd", "", "c:\windows\temp\",1)
  ;exit
endif

We then use a batch file called logonuac.cmd to relaunch the logon script with a $input=uac argument, when this argument is specified the script only remaps the network drives and ignores the rest of the script.

1. GPO triggers user logon script with privileged token.
2. Logon script runs, if Windows 8 is detected it performs all actions with privileged token but skips drive mappings. The logon script is then relaunched with the $script=uac argument under the non-privileged token.
3. Logon script detects $script=uac and only maps network drives. After network drives are mapped, the logon script exits.

If you wanted to simplify you could move the drive mappings out of the main logon script into a separate script and use code something like.

if instr(@producttype,"Windows 8")
  $RC=RunAsInteractiveUser("\\contoso.info\scripts\logon\logonuac.cmd", ", "c:\windows\temp\",1)
else
    RUN '"\\contoso.info\scripts\logon\logonuac.cmd"
endif

This would map drives under Windows 8 systems with the privileged token and everything else as normal.

We spent days on this problem, hopefully this solution saves you time.

Alternatively if you are not running Kixtart and don't want to, you can look at the LaunchApp workaround script. You could also do something as simple as moving the logon script away from GPO and running it as a scheduled task on the local machine running as interactive user, this should also work.