Windows 8 and logon scripts

by lukeren at 2012-08-20 13:21:07

We’ve been using powershell logon scripts for some time now, and with the release of Windows 8, we had to give it a shot.
Our logon script is working for the most part, but the part that maps network drives doesn’t work, it doesn’t map any drives or give any errors.

The part that maps our drives look like this:

$mapdrive = Test-Path -path n:<br>if ($mapdrive -eq $false)
$(new-object -com WScript.Network).MapNetworkDrive(“n:”,"\file-server\share$")
Write-Host “Mapping N:”
Write-Host $error

The part that really makes me wonder, is if I run the script manually after login, it maps my drives.

Anyone else had similar issues, preferably with solutions too :slight_smile:
by poshoholic at 2012-08-20 13:36:02
Here are a few things that should help you resolve this:

1. There’s a KB article out for Windows 8 RC about net use failing under some circumstances. This may or may not apply. You can find out more about that here:
2. On Windows 8 (and therefore PowerShell 3), New-PSDrive now has a -Persist parameter that allows you to set the drive from PowerShell just like you might have done before using net use. For more information about this, see Get-Help New-PSDrive in PowerShell 3.0 on Windows 8.

That doesn’t answer your question about why this fails in your logon script but works interactively, but I would start by trying New-PSDrive with -Persist instead of using the WScript.Network COM object and see how well that works on Windows 8 as part of a logon script.
by lukeren at 2012-08-21 04:21:43
No such luck I’m afraid, the drive still isn’t visible after login.
There is however something in the logfile now (I’m running transcript).

This is the code:

New-PSDrive -Name P -PSProvider FileSystem -Root \fileserver\Users$$username -Persist

And this is what’s in the log:

Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
P 156,09 679,30 FileSystem \fileserver\Users$\sbj
by DonJ at 2012-08-21 06:28:19
It looks like Explorer might not be fully running when your logon script executes. This is a total hack, but try adding a loop to wait until explorer.exe shows up in the process list.

I’m not shocked you’re seeing this - Microsoft, for the most part, doesn’t map drives internally and I don’t think they fully understand why other people do :slight_smile:
by lukeren at 2012-08-21 07:10:37
Well, Navision (A Microsoft product!) doesn’t play well with UNC paths, so we kinda have to.
We wanted to get away from using them too, but no luck I’m afraid.

I’m all for hacks, I’m going to try this later :wink:
by lukeren at 2012-08-21 12:19:16
I did something else, I made a check whether or not explorer was running, and it was running when the script ran, so it’s probably not that …
If I get a solution, I’ll post it, but I’m not thinking this can be done “pretty”.
by lukeren at 2012-08-23 23:27:15
Found a solution, and as expected, the problem wasn’t with powershell.
Disabling UAC completely makes the drive mappings work.

Solution here: … etely.html

[quote]So, just open regedit and locate this key.


In the right pane look for “EnableLUA” and modify its value to 0. Close regedit.[/quote]
by poshoholic at 2012-08-24 08:01:44
Thanks for coming back with your solution. Right off the bat I wonder why this is necessary, so I searched around a bit and found this article:

If you open that article and scroll down to the Group Policy Scripts can fail due to User Account Control section, it describes why this is an issue. It seems that logon scripts are run with the highest privilege available, so for admin users they run in an elevated process and create drive mappings. Then the desktop is launched with a limited token, and the mapped drives are hidden from those users since they are only visible with the administrator, elevated token. For non-admin users it does not seem that this is an issue.

In that article they suggest scheduling a task to run the script so that the drives are mapped outside of the logon script. That sounds a lot less risky than disabling UAC completely, so personally I would do more research on that approach.
by lukeren at 2012-08-24 08:13:18
In the long run, I’ve found out, it isn’t a solution either.
When UAC is completely off, “metro” apps won’t launch.
Currently that’s not an issue since we’re not using any of those, but that will probably change.

Personally, I’ve always had UAC disabled, it’s so annoying to keep remembering to launch things “as administrator” and the prompt to confirm gets my blood boiling too…
Guess I’m just an old fart who’s not much for change :wink:

Thanks for digging up that article by the way :slight_smile:
by poshoholic at 2012-08-24 08:54:13
My pleasure. Disabling UAC didn’t seem like the right way to go. :slight_smile:
by dsf3g at 2012-08-27 11:59:27
BTW: you can also assign drive mappings directly through group policy now (with no need for a login script). Where I’m working we plan on moving in this direction in the near future.
by at 2012-09-01 15:31:29
If you haven’t done so already, I would highly recommend leveraging Group Policy Preferences for mapping drives. PowerShell is fantastic, but there is an existing scalable solution that should more than accommodate your needs. If you end up targeting by computer security groups, be sure to deploy (not sure if this will work in Windows 8 though, will be testing it soon).

I would echo the comments on not disabling UAC. It serves a valuable purpose.
by coderaven at 2012-09-05 10:23:30
I love the fact that PowerShell login scripts are available in Windows 7 and 8 and I try to use them when I can.

It looks like you are trying to create a drive mapping. My only comments to this is, there is no need to script it! Using a Group Policy Preference you can get the task done much easier and control what is going on. Your PowerShell script is using a Windows Scripting Host Com object as well that may not be installed by default in the next version of Windows.

I always try to remember what Ed Wilson says in his best Practices book (not a direct quote) → Why create a script to do something that is already handled well with another tool!

Hope this helps!