asked on

New-PSDrive command ran inside a PowerShell Group Policy User Logon script

For our Windows 10 machines, we have a script that checks the userSharedFolder attribute in AD for the logged on user, and maps this UNC path to L: drive. It runs inside the logon session, but I can't get it to work when used as a PowerShell user logon script.

Here it is...

Import-Module ActiveDirectory
$share=Get-ADUser -Identity $env:USERNAME -Properties * |select userSharedFolder
Remove-PSDrive -Name L
New-PSDrive -Name "L" -PSProvider FileSystem -Root $share.userSharedFolder -Scope Global -Persist

The script works when I run it line by line in PowerShell ISE, I get the output...

Name            Used (GB)      Free (GB)      Provider      Root
----            ---------      ---------      --------      ----
L             327.89        172.11      FileSystem      \\server\share

And the drive maps in Windows Explorer.

But when I add it to as a Group Policy PowerShell user logon script, the drive does not map in Windows.

I've then enabled PowerShell Transcripts in Group Policy, and checked the text file for a transcript of what happened during the logon process, and I get the same output as above, so the mapping does happen inside the powershell session, but nothing gets mapped in Windows Explorer.

This is not an ExecutionPolicy issue, because all scripts that are run from the PowerShell Scripts tab of the User Logon Scripts section of Group Policy are automatically run as 'ExecutionPolicy Bypass'.

I have other powershell scripts launched this way, doing other things, and these run fine from the 'PowerShell Scripts' tab.

This is not a Group Policy issue either - because the transcript proves that the script does run, and completes.

The problem I something to do with the context/environment in which the script runs, but I don't know enough about PowerShell to know more than that.

My understanding of the -Persist switch above was that it would create the mapping in Windows Explorer too.

I've tried adding a "-Scope Gobal" switch to the command but to no avail.

I know there are other (less elegant) options, such as launching the script from a batch file, or using 'net use' instead of New-PSDrive, but this should work, and I want this script to be as self-contained as possible.

Any ideas what's wrong here?

Thanks.

Logon scripts are delayed by default in win10. 5 minutes delay.
See https://support.microsoft.com/en-us/kb/2895815 for the policy to configure this. 0 would mean "run immediately" as it was on win7.

ASKER

Hi McKnife, thanks for your help. As it happens I already had this policy setting set.

However, this wouldn't have been the cause of my problems anyway, because the transcripts show that the script does indeed run on logon. It's just that Windows Explorer doesn't seem to be get the instruction.

Ok.
So either start logging the results into a file or use group policy preferences for file mappings instead which is the MS-recommended way.

ASKER

Hi, I've enabled verbose Event Logging for PowerShell via GPO, and I've enabled the transcripts that I was referring to. Can you explain what other types of logging I can do with this?

GP Preferences is not possible here, because the mapping is done by grabbing the UNC path from an attribute in each user's AD object, not by using AD Group membership. We have 3000 users and 45 different "L-drives", and no groups associated with the different L-drives. But even if we did, I wouldn't want to have 45 different file mappings in GPP.

No, what I meant was redirecting the output of the script. Please read about Start-Transcript to get an idea of how that is done.

[Edit by Qlemo]

Hi and sorry. I can't explain that in a timely manner now. Please try it if you find the time.

I guess you did the transcript already. Maybe you can create another script to run after the above one (but not called from its session), to see if the drive is visible there.

ASKER

OK, I did what you suggested and added a separate ps1 script in the list, after the original one, in the powershell login scripts tab. The only thing in this script was...

L:
dir

I logged off/on and checked the transcripts again, and the transcript of the new script had a long list of the contents of the L-drive, so basically this proves that the mapping was there doesn't it.

Then it should persist. Strange.

ASKER

I've tried more than one machine as well, same result.

ASKER

Shown below is the full output of the PowerShell transcript file, in case it might help. Notice the "PS>$global:?" at the end of the output. Is this anything to worry about? Does this mean that perhaps the Global parameter isn't being read properly?

Clutching at straws here really...

**********************
Windows PowerShell transcript start
Start time: 20160720114722
Username: DOMAIN\USER
RunAs User: DOMAIN\USER
Machine: VMGWYN10 (Microsoft Windows NT 10.0.10586.0)
Host Application: -ExecutionPolicy ByPass -File MapLDrive.ps1
Process ID: 2156
PSVersion: 5.0.10586.63
PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0.10586.63
BuildVersion: 10.0.10586.63
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1
**********************
PS>CommandInvocation(MapLDrive.ps1): "MapLDrive.ps1"

Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- --------
L 328.20 171.80 FileSystem \\server\share

PS>$global:?
True
**********************
Windows PowerShell transcript end
End time: 20160720114728
**********************

The last line means "success".

ASKER

Any more wisdom on this?

I have tried setting it in GP as a normal logon script (i.e. not PowerShell), by running powershell.exe and having

-ExecutionPolicy Bypass -File (path to .ps1)

as parameters, but it still doesn't map the drive in Windows Explorer.

Again, it maps just fine when ran manually inside a Windows session.

Anything else I can try?

My last resort would be to use "net use" wrapped inside the powershell script. However I don't know enough PowerShell to know how to do this. Could you adapt the following command to use 'net use' instead of New-PSDrive?

New-PSDrive -Name "L" -PSProvider FileSystem -Root $share.userSharedFolder -Scope Global -Persist

Thanks.

I've still no clue what goes wrong with it, everything looks fine, and the setting should persist ...
The net use line replacing your PSDrive one is (you can directly call executables):

net use L: $($share.userSharedFolder) /p:yes

Open in new window

ASKER

Thanks for the command. But, this is getting stranger. The net use command doesn't work either. I check the PS transcripts and it says "The command completed successfully" as I would expect. Also the dummy script that I had after it which only had 'dir' on L: works as well, so again the script is able to pass instruction into other scripts, but not into Windows Explorer.

I've checked it now on Windows 7 (also with PowerShell 5), and it works! But doesn't on the two Windows 10 machines that I've tried. So it's looking a bit more sinister now, like it's a Windows 10 problem or perhaps a specific update that causes this.

David Johnson, CD

A PSDrive is only valid within powershell.

Import-Module ActiveDirectory
$share=Get-ADUser -Identity $env:USERNAME -Properties * |select userSharedFolder
test-path $share.userSharedFolder -count 1
#Remove-PSDrive -Name L
Net use L: /delete
#New-PSDrive -Name "L" -PSProvider FileSystem -Root $share.userSharedFolder -Scope Global -Persist
net use L: $share.userSharedFolder

Open in new window

ASKER

Hi David. I trïed the 'net use' command in my last post, but that doesn't work either.

As for PSDrive, the official Microsoft document of the New-PSDrive command says "You can use the Persist parameter of New-PSDrive to create Windows mapped network drives."

David, that has changed with PS 3. New-PSDrive -Persistent is able to create classic drive mapping for use outside of PS.

ASKER

OK, I've got the answer now. It's a weird UAC thing. Despite the UAC slider being at the bottom, I also need to set...

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLUA
0

And now my drives map no problems.

Doing that renders a lot of the in-build apps no to work (without changing more). E.g. try to run the calculator.

ASKER

Ah yes, it would appear that you're correct!

Now that we know that my original problem is related to UAC, do you know of any other way to circumvent UAC to help me get my drives mapped?

@Qlemo: Not quite (and we had that discussion before) - calc and all modern apps will work without any other config changes for non-admins. Only for local admins your worries apply.

ASKER

Even if these worries are only applicable to local admins, I still need to find a way to neutralise them, because we have a few people (i.e. the entire IT department), who are local admins, so I don't want a situation where some apps are not available to us.

Is either of the following possible?

1. Somehow 'enable' my PowerShell script so that it doesn't come under UAC's radar.
2. Turn off UAC in a way that admins can still open native Windows apps.

Thanks.

- change your concept to gpp, there will be a way to migrate that easily
- ask Microsoft support why it behaves like that

ASKER

Although I guessed the number of GP Prefs items that I would need to be 45 earlier, it is actually 79. That will just make logons sluggish.

Apart from calculator, what other apps would be affected if I set EnableLUA to 0?

> That will just make logons sluggish.
Please explain. I don't see this.

> Apart from calculator, what other apps would be affected if I set EnableLUA to 0?
Only the "modern apps", the built-in ones that come installed with windows: edge, photo app, news app... But you don't need to run as administrator, not even the IT department or developers do. Have a look at my article to get an idea for a setup that makes it easy to run as non-admin: https://www.experts-exchange.com/articles/24599/Free-yourself-of-your-administrative-account.html

ASKER

Well I'd have 79 GPP items, each one with item-level targeting, so wouldn't it take a long time to go through all of those, querying AD 79 times?

Compared to a three-line powershell script that does one query to AD.

I don't get this at all - Microsoft want us all to use UAC, they also want admins to use powershell. In GPMC they even have an extra 'PowerShell Scripts' tab in the Logon Scripts section of a GPO. So what's point of this is they're making it impossible for us to use PowerShell scripts on logon?

Yes, I can massively re-engineer my environment, create 79 new AD groups and 79 new GP preference items, or I can remove local admin privilieges from 50 people, but that's not really the point.

I am willing to make an experiment and test this with 79 AD security groups. I guess you won't even notice much. https://helgeklein.com/blog/2015/11/how-group-policy-impacts-logon-performance-1-cses/ is a good read, by the way. It consists of three 3 articles. Also read http://evilgpo.blogspot.de/2014/11/showdown-wmi-filter-vs-item-level.html

Will be testing soon, maybe tomorrow morning.

ASKER

Thanks for the literature - I'll get reading. And thanks for your testing it is much appreciated.

ASKER CERTIFIED SOLUTION

membership

Create a free account to see this answer

Signing up is free and takes 30 seconds. No credit card required.

ASKER

Hi McKnife, many thanks for conducting that test. I shall definitely do that if there's no way of using New-PSDrive. I have a call open with Microsoft about this at the moment, trying to get them to admit that it's a bug in Windows 10. If nothing comes of the call I'd go GPP.

Thanks.