Member Avatar for toxicandy

With windows server 2003 losing support in the coming weeks we have upgraded our 2003 servers to virtualized 2008 servers. The only problem we are having at the moment is with Group Policy and mapping drives. Previous to this upgrade we used a logon.vbs which "worked" but was nearing 10 years old and did have faults every once in a while. However since the change the script is a complete bust, broken, no drives map from it and so we have to run to each work station and remap drives manually. We have since removed the logon.vbs from being used and replayed it with the Drive Maps under User Configuration->preferences->Windows Settings. We are using replace with these drives and also Item level targeting to target the security group for different people. We have in total about 20-25 drives however we have some repeated drives (three instances of S:) but they are all to totally different groups that would not coincide with each other. So they should never have to be mapped onto the same computer, this still isn't the problem. Currently (Day 8) we have had 2 computers no grab any of the drives they were supposed to, both users were in the groups, we ran a gpupdate /force followed by a restart and still nothing, I then ran a gpresult /h and couldn't find anything as to why it would fail. DNS checked out fine and no one had any complications there. We also had 2 other computers that grabbed 4-5 drives correctly but missed one. Is there any big reason that sticks out in anyone’s mind why this is happening?

EDIT

Ran a Report from GPM on one of the computers and it came back with this under the drive maps:

Group Policy Drive Maps: Failed
Group Policy Drive Maps failed due to the error listed below.
The system cannot find the path specified.
Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 5/28/2015 8:39:31 AM and 5/28/2015 8:39:31 AM.

All paths are correct and the same policy works on a number of computers. When on their computer I am able to type the exact path mapped VIA the drive maps and it comes up perfectly fine.

Edited by toxicandy because: Added Report
  • 2 Contributors
  • 2 Replies
  • 822 Views
  • 1 Hour Discussion Span
  • Latest Post Latest Post by toxicandy

Dani AI

Generated

Short summary and likely root cause (for and ): after moving DCs you’re seeing sporadic drive‑map failures where the workstation can reach the UNC manually but the Group Policy Preference item reports a “path not found” error. That often means the Drive Maps XML that the client-side preference extension reads is missing/out-of-date on the Domain Controller the client contacted — the Drive Maps entries live in a Drives.xml under the GPO in SYSVOL. (learn.microsoft.com)

What to check first (quick, high‑value checks)

  • On every DC confirm the file exists and is identical:
    \<domain>\SYSVOL\<domain>\Policies\<GPO-GUID>\User\Preferences\Drives\Drives.xml — compare timestamps/contents across DCs.
  • Verify SYSVOL/GPO replication health (replication errors or an incomplete FRS→DFSR migration will leave some DCs without the newer GPO files). If any DC is behind, clients authenticating against it will get an incomplete GPO. (learn.microsoft.com)

Client and policy diagnostics

  • If you still have down‑level clients (Windows XP / Server 2003) they need the Group Policy Preferences client‑side extensions installed; otherwise those clients won’t process Drive Maps. Also remember item‑level targeting is evaluated in the user token at logon, so replication or token timing can cause misses. (support.microsoft.com)

Enable focused logging and an ordered workflow

  • Turn on Drive Maps preference logging/tracing (Computer Configuration → Administrative Templates → System → Group Policy → Logging and tracing) and reproduce; trace files default to C:\ProgramData\GroupPolicy\Preference\Trace and give exact reasons for each item failure. Then: (1) confirm Drives.xml on all DCs, (2) run AD/DFS replication checks and fix SYSVOL replication if required, (3) re-run the client with tracing on and inspect the trace. If replication was the issue, fixing it will immediately stop the intermittent failures. (learn.microsoft.com)

If the above still doesn’t find the problem, capture the Drives.xml from a working DC and a failing DC plus the DriveMaps trace output and compare — that data tells exactly whether the client is reading an old/missing preference or failing to access the target share during processing.

Recommended Answers

All 2 Replies

Member Avatar for CimmerianX

Did you map them before by IP, DNS name, or netbios name? Did you replicate the method exactly.

Off the top of my head you could have 2 issues here.
1) The method used to map the drive is not setup on the workstation. i.e. \server.here.local\share doesn't map because the workstation is using wrong dns, maybe an invalid hosts file entry.
2) Server load... if you have 100 PCs each mapping mulitple drives all at the same time of the morning (logon time), perhaps the guest os or host os is under load

Member Avatar for toxicandy

I think I may have something. We still have 2 windows 2003 servers to be moved over however 1 does have GPM on it and when we run
GPRESULT /R
The server that group policy was applied from changes between 3-4 servers which all have GPM on it. All the servers replicate GPM from the same server (we'll call it Server a)

So

Server A is our primary Domain Controller

Server B will replicate any changes made to GPM on Server A over so they are the same on Server B
Server C and Server D do the same as Server B.

But I did say that one was Server 2003 and as far as I know drive map doesn't work on Windows server 2003 correct? You have to use Logon.vbs instead? As I said in my main post, we disabed Logon.vbs and it replicated, as I just checked, across to all the other servers. So if someone used the server with 2003 on it when they logged in is it possible that policy was not applied but if they were lucky and it used one of the other servers where the drive map works that it applied smoothly and worked no problem?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.