Powershell logon script not mapping DFS shares in Windows 10

Nov 23, 2016 5:41AM PST

We have implemented a Powershell logon script for all of our Windows 7 Clients, this performs many customer-related tasks during the logon process. This exact same script can also be manually started via a simple GUI, should some tasks need to be redone. We do not implement GPP as some of the specific tasks we want to perform cannot be achieved using GPP and we don’t want to have different components/mechanisms.

Now we are moving to Windows 10. We would like to retain the current logon script and continue to use this mechanism. Before anniversary update (1607) the script was also doing everything as expected. Now with Windows 10 (1607) everything is working as expected apart from the one following issue, which I cannot currently explain:

When the Logon Script is executed automatically during the Logon process via user GPO, all NON-DFS shares are mapped as expected, however DFS Shares aren’t. Once the Logon Script has finished, the user can execute the script manually and ALL the drives are mapped correctly this time.
The UAC configuration of the client is as follows:
- UAC is enabled
- Setting "User Account Control: Run all administrators in Admin Approval Mode" is set to "Enabled"
- Setting "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode” is set to ”Elevate without prompting"
- Regkey set [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "EnableLinkedConnections" = REG_DWORD 0x1 (1)
My troubleshooting steps and observations to date:
My script is writing an extended log during execution and I’m certain that during the Logon process itself, ALL DRIVES are being correctly mapped. I can successfully check the drive availability and I can even write files to the drives (during the logon process). However, the fact of the matter is….after the Logon Script completes (without errors), the DFS shares are not available/visible/accessible.
If I temporarily provide the exact the same drives with GPP, all drives are available after logon process. So this confirms that DFS is still configured correctly.
It appears that during the Logon process the script is not running in the exact same user context as AFTER the logon process. I do not understand why, nor do I understand where the difference lies.

Discussion is locked

Reply to: Powershell logon script not mapping DFS shares in Windows 10
PLEASE NOTE: Do not post advertisements, offensive materials, profanity, or personal attacks. Please remember to be considerate of other members. If you are new to the CNET Forums, please read our CNET Forums FAQ. All submitted content is subject to our Terms of Use.
Reporting: Powershell logon script not mapping DFS shares in Windows 10
This post has been flagged and will be reviewed by our staff. Thank you for helping us maintain CNET's great community.
Sorry, there was a problem flagging this post. Please try again now or at a later time.
If you believe this post is offensive or violates the CNET Forums' Usage policies, you can report it below (this will not automatically remove the post). Once reported, our moderators will be notified and the post will be reviewed.
- Collapse -
Nov 23, 2016 6:17AM PST

Looks like a bug, but maybe it's by design.
Contact your Microsoft support (which certainly is included with your enterprise system) and discuss the problem and possible solutions.

What I read in your post is that using GPP for linking to those DFS shares would be a very good work-around. Choosing between "it's not our policy in Windows 7, so we don't use it in Windows 10 either" and "we do it, since it's the only way" seems an easy choice. And maybe Microsoft will fix it in the next release of Windows 10, if it is an unintended bug.

- Collapse -
I agree.
Nov 23, 2016 7:11AM PST

I see Enterprise noted so you use that gold level support system next. You paid for that!

- Collapse -
Well which version of Windows 10
Nov 23, 2016 9:24AM PST

do you have? I read after the anniversary update WIndows 10 Pro would have group policies removed and you would need the Enterprise edition to change certain group policies.
I believe they did this because the consumers version are so dependent on the store and they don't want people disabling the store. Whereas most people using the Enterprise edition will want the store blocked.

- Collapse -
I use the W10 Home version for hours a day
Nov 23, 2016 9:35AM PST

And the windows store never rears its head. To me, this seems to be a lot of trouble for no payback. Other than paying a suitcase of cash for the Enterprise version.

Funny what folk will pay for.

- Collapse -
Dec 5, 2016 1:55AM PST

I've got the same issue i see this problem manifest sometime till from 8 and 8.1 but in 10 Anniversary is sistematic.
This Is my personal workaround: in GPO I create a Scheduled Task that runs every time a user logon that launch the logon script

It works like a charm ...

CNET Forums

Forum Info