Preferred UAC configuration in Enterprises that use Login scripts to map drives

Question

In Windows 7, Vista and newer OS's, UAC will prevent logon scripts from mapping hard drives so that the following logon script code won't work:

Dim WshNetwork
Set WshNetwork = WScript.CreateObject("WScript.Network")

WshNetwork.MapNetworkDrive "g:", "\\\Saturn\data\"
WshNetwork.MapNetworkDrive "k:", "\\\Saturn\stuff\"

Administrators have a few choices when dealing with this issue:

• Disable UAC

• Microsoft's launchapp.wsf

• Linked Connections

• Group Policy Preferences

• ???

Question

What approach is the most practical and supportable approach to making login scripts "just work" in Enterprise environments?

If the "most preferred" solution isn't the one enterprises are doing in the real world, what approach are they taking?

Answer 1

Use Powershell and set your execution mode to allsigned. It's the best of the worst options for powershell execution methods, issue a code signing cert from your internal CA and sign your login scripts.

(new-object -com WScript.Network).MapNetworkDrive("g:","\\Saturn\data")
(new-object -com WScript.Network).MapNetworkDrive("k:","\\Saturn\stuff")

Powershell defaults to executing asInvoker, so unless I'm mistaken that should run sans UAC prompt.

Answer 2

I don't have this in enterprise environments but have some experience of it in a small business environment.

I would recommend either the basic net use s: \\server\share suggested by Safado but if you need logic I would recommend kixtart, it was recommended to me by a 3rd party contractor we had in and everything I've seen it do has been impressive including basic logic, drive and printer mappings based on a number of variables including OU, groups, and pc name. It also has some basic security features should you wish to deny users the ability to view the login script logic.

Answer 3

How about calling the "net use" command from your VBS logon script?

Even thought the script itself runs under the Administrator token, any programs started by the script will run under a Standard user token, which means that drives mapped this way will be available to the user.

Your example could be adapted to look like this:

Set shell = CreateObject("Wscript.Shell")

shell.Run "net use g: \\Saturn\data", 7, True
shell.Run "net use k: \\Saturn\stuff", 7, True

(The '7' causes the command to run minimised, to avoid command prompt windows from appearing on the screen. And 'True' waits for the command to complete before continuing)

Answer 4

The problem I and many others have ran into is if the domain user account is part of the local administrators group, then the GPO Logon Script will not run resulting which will not map the network drives/shares.

http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/54721cb2-7f59-467f-856a-2a2d799ed953

Here is a thread I was looking at....the NET USE will not work in a GPO either with both Win 7 or Win 8, but Ori might have something that might work, the only problem is it is a more complex process than what should just work without a certificate.

Answer 5

Honestly UAC should not be interfering with anything being called from a group policy regardless if its a login.vbs script or even an exe. My script which has had years to mature is suddenly useless with UAC turned on. My script not only maps drives automatically, but checks to makes sure when the drive is already mapped that its the one you want. Remaps the dirve if its not the one its assigned to be. My script also calls an installer which checks to see if an update is required for a particular program and runs the installer as an administrator so that the user logged in does not need to have administrative rights. If your environment is setup where the users can't install programs UAC is more of a hinderence then a help. I have to support MORE calls because something DIDN'T happen now.