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.
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.