I'm having trouble with a login script that I'm using to map network drives dynamically based on Active Directory settings. It seems to work perfectly for standard users, whether it's run as a GPO or interactively. However, for users with local admin rights, the script only maps the drives when executed interactively. Even though the GPO transcript indicates that the drives are being mapped successfully, they simply don't show up when I check in Windows Explorer or run Get-SMBMapping, even after restarting explorer.exe. The clients I'm testing with are running Windows 11 Enterprise versions 23H2 or 24H2.
I included the relevant part of the script, but the core issue is that it appears that when the script is executed via GPO for admin users, it runs in an elevated context instead of under their user context. This leads to the mapped drives being made under the Administrator account rather than the intended user. Has anyone encountered this issue or found a workaround?
3 Answers
It sounds like when the GPO runs for users with admin rights, it's executing in elevated mode, which is why the drives are mapped under the Administrator account instead of the user. For non-admin users, it runs correctly in their context. You might want to check the way your GPO is configured. It should default to user context; perhaps look into forcing it to not run elevated for admins? It’s a tricky situation!
The mapping script looks solid, but just to clarify, are you ensuring `$User` is available correctly in your context? It must be properly defined, or property bleeding could cause rendering issues. Make sure it’s set up before you call anything that relies on it!
I thought the same! Turns out he has it defined elsewhere. If you see the logging output, then it’s definitely locating it just fine.
Have you tried creating the `EnableLinkedConnections` registry entry? This might help access the mapped drives that are created under the elevated context. The Microsoft documentation covers it well and might just fix the issue you're facing!
I was skeptical about that at first since I thought it only mapped in one direction, but it actually lets you access those drives from both the user and the elevated context. Definitely worth trying it out.
Exactly! Administrators running login scripts often experience this problem. The key is that GPO scripts for admin users can sometimes auto-elevate. If it runs as SYSTEM instead of the user, that's why you see those issues.