asked on
Issues with GPP Mapped Drives and Home Drive over wifi and VPN
Hi Experts,
I’ve been wrestling with this issue for a couple weeks and have used online forums extensively in hopes of finding a solution. So far, I have come close a few times to thinking I have stumbled onto the culprit, but so far no luck. It’s time to engage with you experts and hopefully get a resolution.
In a nutshell, my Windows 10 laptop users (only two so far) have issues connecting with the GPP mapped drives and even the home folder mapped via the user account profile settings over the VPN and even when booting up on our local network via wifi. For the mapped drives, it’s usually an error about “system cannot find the path specified” and the home folder will show the files, but everything is greyed out and some items have a grey “X” on them. GPUpdate doesn’t always fix the issue. Sometimes they will restore after sitting for a while. Accessing the shares or folders via DFS path works fine.
I will explain my environment and the issues in more detail below.
• We have a hub and spoke DFSR environment that was built from scratch prior to migrating off a troublesome hosted VDI.
• Each site has three virtual servers (DC/DNS, File/DFSR, DHCP/Print)
• I’m using folder redirection for Desktop, Documents and Favorites and have Offline Files enabled. They are configured via DFS path.
• DFSR is organized so that user home folders are replicated to the site the user works at. Namespace target referrals are only enabled at the local site. If the site server went down, I can enable the target at the colo and have the users reboot.
• The user’s home drive is mapped as drive U: in the user profile. It maps via the DFS path.
• We have many mapped drives that are setup in Group Policy Preferences (with Reconnect set). The user population is not technical and is used to mapped drives, so they need to stay for now. We also have some legacy apps to consider.
• I did not disable IPv6 when setting things up because I found articles that said it would break things.
• I have one WINS server at the central colo and all servers and clients are configured to point to it.
• In group policy, I have the “wait for network” setting enable.
• I was initially using our Pulse VPN, but switched to Microsoft’s VPN while troubleshooting. I have it set to use the remote gateway for routing, just to ensure that is not the issue. I have also tried logging the client on via the VPN and that doesn’t resolve the issue.
For the desktop users, things have been working fine all along. Logins can be slow at times due to the Folder Redirection and Offline File settings. I have two Windows 7 laptop users who have been trouble free, but not sure if they try to connect over the VPN. The real trouble started when I deployed a Windows 10 Pro laptop to one of our directors. He was losing access to his mapped drives and alternately his home folder (drive U:). This was both from home over the VPN as well as at work over the wifi.
At first, I thought it was hardware or OS corruption and we got the laptop replaced, only to find the same issue with the new one. I then joined my personal Windows 10 Pro laptop to our domain and discovered I had the same issues. I have searched the online forums and tried many things that I found, but to no avail. Some things I can remember:
• Tried disabling UNC hardening on Win10 client
• Tried adding DNS suffix setting on client TCP/IP settings
• Changed GPP mapped drive setting from Replace to Update
• Changed all my paths in Group Policy drive mapping to point to \\<domain>.org\<target> instead of \\<domain>\<target>. This seemed to work for the first couple of bootups, but then it was failing as well.
• Tried un-configuring Offline Files on a test account.
• Removed the home directory from the test account profile and mapped it via GPP using \\<domain>\<target>\<path>
• On one forum, someone suggested configuring DFS to only use DNS by setting the “dfsdnsconfig” parameter on all namespace servers. I thought this might be promising due to the issue above where I had initial success referring to the FQDN, but this configuration is a huge undertaking (see https://community.spiceworks.com/how_to/74644-setup-dfs-to-use-dns) and since I have WINS running in my environment, I’m not sure my issue is related to NetBIOS.
• I have resisted trying some of the more creative solutions, like logon scripts with built-in delays, since I have to imagine there is a correct way to do this.
• I did create a UNC/DFS shortcut to the user’s home folder and placed it on his desktop. When he can’t access his U: drive, he can at least get to the files via the shortcut.
My big question is, for wifi and VPN users, do I have a correct configuration? I know there are timing issues with Group Policy and I also know that GPP only runs once at login. Is it just not possible anymore (post XP) to use mapped drives, even over a VPN or wifi? Is there something different in Windows 10? What would Microsoft suggest I do? What would you suggest I do?
Thanks!
I’ve been wrestling with this issue for a couple weeks and have used online forums extensively in hopes of finding a solution. So far, I have come close a few times to thinking I have stumbled onto the culprit, but so far no luck. It’s time to engage with you experts and hopefully get a resolution.
In a nutshell, my Windows 10 laptop users (only two so far) have issues connecting with the GPP mapped drives and even the home folder mapped via the user account profile settings over the VPN and even when booting up on our local network via wifi. For the mapped drives, it’s usually an error about “system cannot find the path specified” and the home folder will show the files, but everything is greyed out and some items have a grey “X” on them. GPUpdate doesn’t always fix the issue. Sometimes they will restore after sitting for a while. Accessing the shares or folders via DFS path works fine.
I will explain my environment and the issues in more detail below.
• We have a hub and spoke DFSR environment that was built from scratch prior to migrating off a troublesome hosted VDI.
• Each site has three virtual servers (DC/DNS, File/DFSR, DHCP/Print)
• I’m using folder redirection for Desktop, Documents and Favorites and have Offline Files enabled. They are configured via DFS path.
• DFSR is organized so that user home folders are replicated to the site the user works at. Namespace target referrals are only enabled at the local site. If the site server went down, I can enable the target at the colo and have the users reboot.
• The user’s home drive is mapped as drive U: in the user profile. It maps via the DFS path.
• We have many mapped drives that are setup in Group Policy Preferences (with Reconnect set). The user population is not technical and is used to mapped drives, so they need to stay for now. We also have some legacy apps to consider.
• I did not disable IPv6 when setting things up because I found articles that said it would break things.
• I have one WINS server at the central colo and all servers and clients are configured to point to it.
• In group policy, I have the “wait for network” setting enable.
• I was initially using our Pulse VPN, but switched to Microsoft’s VPN while troubleshooting. I have it set to use the remote gateway for routing, just to ensure that is not the issue. I have also tried logging the client on via the VPN and that doesn’t resolve the issue.
For the desktop users, things have been working fine all along. Logins can be slow at times due to the Folder Redirection and Offline File settings. I have two Windows 7 laptop users who have been trouble free, but not sure if they try to connect over the VPN. The real trouble started when I deployed a Windows 10 Pro laptop to one of our directors. He was losing access to his mapped drives and alternately his home folder (drive U:). This was both from home over the VPN as well as at work over the wifi.
At first, I thought it was hardware or OS corruption and we got the laptop replaced, only to find the same issue with the new one. I then joined my personal Windows 10 Pro laptop to our domain and discovered I had the same issues. I have searched the online forums and tried many things that I found, but to no avail. Some things I can remember:
• Tried disabling UNC hardening on Win10 client
• Tried adding DNS suffix setting on client TCP/IP settings
• Changed GPP mapped drive setting from Replace to Update
• Changed all my paths in Group Policy drive mapping to point to \\<domain>.org\<target> instead of \\<domain>\<target>. This seemed to work for the first couple of bootups, but then it was failing as well.
• Tried un-configuring Offline Files on a test account.
• Removed the home directory from the test account profile and mapped it via GPP using \\<domain>\<target>\<path>
• On one forum, someone suggested configuring DFS to only use DNS by setting the “dfsdnsconfig” parameter on all namespace servers. I thought this might be promising due to the issue above where I had initial success referring to the FQDN, but this configuration is a huge undertaking (see https://community.spiceworks.com/how_to/74644-setup-dfs-to-use-dns) and since I have WINS running in my environment, I’m not sure my issue is related to NetBIOS.
• I have resisted trying some of the more creative solutions, like logon scripts with built-in delays, since I have to imagine there is a correct way to do this.
• I did create a UNC/DFS shortcut to the user’s home folder and placed it on his desktop. When he can’t access his U: drive, he can at least get to the files via the shortcut.
My big question is, for wifi and VPN users, do I have a correct configuration? I know there are timing issues with Group Policy and I also know that GPP only runs once at login. Is it just not possible anymore (post XP) to use mapped drives, even over a VPN or wifi? Is there something different in Windows 10? What would Microsoft suggest I do? What would you suggest I do?
Thanks!
VPNWindows Networking
Last Comment
Seth Simmons
ASKER
I forgot to update this thread on what turned out to be the primary issue. The clients aren't getting the DFS Namespace (the short NetBIOS version) resolved to a DC in a consistent manner, especially on initial login. My current work around is placing an entry in the client's lmhosts file. This has acted like a miracle cure, but I still need to figure out why the clients needs this bandaid.
Maybe this new bit of info will trigger some ideas from a few experts?
Maybe this new bit of info will trigger some ideas from a few experts?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.
I have recommended this question be closed as follows:
Accept: MalibuKen (https:#a41809822)
If you feel this question should be closed differently, post an objection and the moderators will review all objections and close it as they feel fit. If no one objects, this question will be closed automatically the way described above.
seth2740
Experts-Exchange Cleanup Volunteer
I have recommended this question be closed as follows:
Accept: MalibuKen (https:#a41809822)
If you feel this question should be closed differently, post an objection and the moderators will review all objections and close it as they feel fit. If no one objects, this question will be closed automatically the way described above.
seth2740
Experts-Exchange Cleanup Volunteer
1. I changed the Slow-link Mode Latency value to 1, per this article: https://technet.microsoft.com/en-us/library/hh968298(v=ws.11).aspx.
This seemed to eliminate the issue with the mapped drives becoming unavailable after they were already available.
2. I turned off Hybrid Boot on the client by setting this registry key: HKEY_LOCAL_MACHINE\SYSTEM\
This seemed to fix the issue where mapped drive were not available immediately after boot-up on wifi.
The article that included this fix was: http://serverfault.com/questions/725206/windows-8-1-10-gpo-mapped-drives-wont-connect.
I will update my progress after further testing.