• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 777
  • Last Modified:

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.
0
meirionwyllt
Asked:
meirionwyllt
  • 15
  • 9
  • 6
  • +1
1 Solution
 
McKnifeCommented:
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.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
McKnifeCommented:
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.
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
McKnifeCommented:
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]
0
 
McKnifeCommented:
Hi and sorry. I can't explain that in a timely manner now. Please try it if you find the time.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
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.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Then it should persist. Strange.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
I've tried more than one machine as well, same result.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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
**********************
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
The last line means "success".
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
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

0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
David Johnson, CD, MVPOwnerCommented:
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

0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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."
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
David, that has changed with PS 3. New-PSDrive -Persistent is able to create classic drive mapping for use outside of PS.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Doing that renders a lot of the in-build apps no to work (without changing more). E.g. try to run the calculator.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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?
0
 
McKnifeCommented:
@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.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
McKnifeCommented:
- change your concept to gpp, there will be a way to migrate that easily
- ask Microsoft support why it behaves like that
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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?
0
 
McKnifeCommented:
>  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
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
 
McKnifeCommented:
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.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
Thanks for the literature - I'll get reading.  And thanks for your testing it is much appreciated.
0
 
McKnifeCommented:
Finished the test. Created one GPO with 79 GPP drive maps, each to a different share, each for a different security group (filtered within GPP through item level targeting).
Lightning fast logon, no difference noticeable if the GPO is linked or not.

Use GPP.
0
 
meirionwylltSenior Desktop EngineerAuthor Commented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

  • 15
  • 9
  • 6
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now