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.by poshoholic at 2012-08-20 13:36:02
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
[Environment]::NewLine
}
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
Here are a few things that should help you resolve this:by lukeren at 2012-08-21 04:21:43
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: http://support.microsoft.com/kb/2686098.
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.
No such luck I’m afraid, the drive still isn’t visible after login.by DonJ at 2012-08-21 06:28:19
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
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.by lukeren at 2012-08-21 07:10:37
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
Well, Navision (A Microsoft product!) doesn’t play well with UNC paths, so we kinda have to.by lukeren at 2012-08-21 12:19:16
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
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 …by lukeren at 2012-08-23 23:27:15
If I get a solution, I’ll post it, but I’m not thinking this can be done "pretty".
Found a solution, and as expected, the problem wasn’t with powershell.by poshoholic at 2012-08-24 08:01:44
Disabling UAC completely makes the drive mappings work.
Solution here: http://www.eightforums.com/general-disc … etely.html
[quote]So, just open regedit and locate this key.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
In the right pane look for "EnableLUA" and modify its value to 0. Close regedit.[/quote]
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:by lukeren at 2012-08-24 08:13:18
http://technet.microsoft.com/en-us/library/cc766208(WS.10).aspx
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.
In the long run, I’ve found out, it isn’t a solution either.by poshoholic at 2012-08-24 08:54:13
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
Thanks for digging up that article by the way
My pleasure. Disabling UAC didn’t seem like the right way to go.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 cookie.monster 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 http://support.microsoft.com/kb/2561285 (not sure if this will work in Windows 8 though, will be testing it soon).by coderaven at 2012-09-05 10:23:30
I would echo the comments on not disabling UAC. It serves a valuable purpose.
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!