Link to home
Start Free TrialLog in
Avatar of delkent
delkentFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Mapped Drives via Group Policy Preferences sometimes failing to connect

Hi,

We recently changed all of the drives that are mapped for users from being applied via a login script (several actually, hence a desire to more away from them) to being applied with Group Policy Preferences.  They have worked fine for a good few weeks but for the last 2 weeks or so, network drives have been unavailable to some users once logged in to Windows.  It's only affecting some users.  The vast majority get their drives connected without issue.

When a drive fails to connect it is listed in 'Computer', sometimes displayed ok and sometimes with a disconnected red cross - either way, if it's not working it will produce the error message when clicked on:

"An error occurred while reconnecting <drive letter>: to <DFS Namespace path>.
Microsoft Windows Network: The network path was not found.
This connection has not been restored"

Once this happens, I still find I can use a UNC path from RUN to connect ok.  I can ping the server by both Name and IP.  Interestingly the Network window fails to display all of the network devices.

We initially suspected a DNS issue and found that there was some config problems with the way DNS was set on some NICs.  However, although we have corrected these, the problem still persists.  We also have 2 servers on the site that are both capable of DNS queries.  An NSLookup confirms that the client PCs are using the Primary DNS Server and can communicate with it and resolve DNS queries without issue.

I have been looking in to this for a while and have certainly tried things such as resetting Winsock with the command 'netsh winsock reset' - flushing the DNS cache of a client.  I find that resetting the Winsock will get the drives back after the required reboot and the user is ok for the rest of the day but after shutting down and coming back in the next morning, the problem resurfaces.



Further Info:
*Even if I log in as a domain admin = same problem.
*A user that has never logged on to the particular client machine before = same problem.
*One client PC has been wiped and rebuilt and this has permanently resolved the problem for that machine.
*All problem machines are Windows 7 (there are a few XP machines but they have not encountered the problem)
*Mixture of desktop/laptop.  Laptops are a mixture of wired/wireless, so unlikely to be a wifi issue
*Log on server/AD is Windows 2008 R2 Standard

*The Event Viewers reveal the following entry:
The user <drive letter> preference item in the <GPO> Group Policy object did not apply because it failed with error code '0x8007000f The system cannot find the drive specified.' This error was suppressed

* I have added a new drive mapping that is exactly the same destination as another one but instead of mapping using the DFS Namespace, it is mapped using the true UNC path.  When the mapped drives next fail to connect properly, I intend to check if the single UNC drive still works (DFS issue??)

*I intend on testing the following  GPO option if the above step does not reveal anything helpful:
enable “Process even if the Group Policy objects have not changed” option in “Drive maps preference extension policy processing” policy which is located at [Computer Configuration | Policies | Administrative Templates | System | Group Policy]

--------------

So as you can probably tell, I'm scratching my head.  Any ideas or help would be much appreciated.  Any questions or further info I can supply, please ask.  Thanks for your time.
Avatar of Gabriel Clifton
Gabriel Clifton
Flag of United States of America image

How are your mapped drives applied in group policy, create, update, or replace. I use replace and recommend it. with that setting, if the drive is not there create it, if it is there re-create it much like having a batch script use net use delete before creating the drive.
Avatar of delkent

ASKER

Thanks for the response.  They are currently on Update.  Which reminds me, and is probably worth mentioning...

There are 2 physical sites.  Site a) is the problem site where some of the machines have the problem but most are ok.  Site b) has more than double the amount of client PCs, none of which have experienced the problem thus far.

They are the same AD forest/domain with an AD server (GC) in each site.  Each of these servers is a DNS server so clients get DNS queries answered by their local server.

I mention this as both are using the same GPO with all mapped drives set to Update and only one location has some problems.
ASKER CERTIFIED SOLUTION
Avatar of netballi
netballi
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of delkent

ASKER

I'm not sure why approx 6 computers would suddenly have problems with the domain membership/computer account.  If it helps formulate any ideas, I can tell you that out of the laptops, there is one that is used by a staff member who frequently travels between sites a & b.  Without making any changes whatsoever, if he is at site A then he gets the problems of a lack of connected mapped drives but if he is at site B everything works properly and as expected.  No removing from domains and rejoining or flushing DNS or resetting Winsock is required for this situation to occur.
Avatar of delkent

ASKER

I have gone with the suggestion of removing from the domain (checked DC Rep) and the rejoining.  All seems ok at the moment, although no way of telling if it was just the reboot that sorted it, which sometimes happens.

I will monitor over the next 3 days which is time before I am next onsite.  Multiple logins, reboots and shutdowns to test.  Will feed back results either negative or positive.  Thanks.
Any news yet?
Avatar of delkent

ASKER

I'm not entirely convinced this is the solution as I have seen one machine have the same problem once after running the fix.  But all machines and the one as just mentioned have all been fine since.  The very fact it is on multiple machines suggests this should be more of a server issue than client-side.  

Either way though, thanks for the solution, it seems to be doing the trick at the moment.