Group Policies moved from Windows 2008 R2 to Microsoft Windows Server 2019 Datacenter - GPO issue with a mapped network drive

Eggs In Langley 1 Reputation point

Apparently this network mapping is working for some people and not for others.
The GPO policy is to take this:

\{OurFileServer\users\%logonuser%\My Documents as a network path and map to a network drive (F:)

System information.

  • We recently updated our DomainController from 2008 R2 server to Windows Server 2019 data center and this where our group policies were moved to.
  • OurFileServer is running on Windows 2008 RS. This is the server where we map a users's My Documents folder.
  • We added new Terminal Servers and these are running Windows Server 2019 data center.

I can't figure out why the F: drive is mapping for some users but not others since moving over to a 2019 server.
What other information can I provide that can help solve this issue?


Windows Server 2019
Windows Server 2019
A Microsoft server operating system that supports enterprise-level management, data storage, applications, and communications.
2,402 questions
Windows Group Policy
Windows Group Policy
A feature of Windows that enables policy-based administration using Active Directory.
2,011 questions
No comments
{count} votes

4 answers

Sort by: Most helpful
  1. Fan Fan 15,186 Reputation points

    Before going further, would you please tell how did you move the mapping drive, did you change this by replace the old network path with the new one?
    Did you confirm the permission configured on the new server?
    When you run gpresult /h report.html for the users not display the mapping drive , are there any errors in the report?
    Are there any other mapping drives for the users with the same drive letter?

    As you upgrade the DCs, the new DCs are working well ,right? You can check that by :
    Dcdiag /v >c:\dcdiag1.log
    Repadmin /showrepl >C:\repl.txt
    Repadmin /showreps * 

    Best Regards,

  2. Eggs In Langley 1 Reputation point

    Hello FanFan,

    would you please tell how did you move the mapping drive, did you change this by replace the old network path with the new one?

    I'm sorry, I do not understand what you mean here.. The mapping is done as a group policy and other than cloning the DC to a new server
    and upgrading the o/s to Window Server 2019 Datacenter, there was no change made to the group policy. The mapping that is failing is towards
    an existing file server that had no o/s upgrade. The file server remains with Windows 2008 R2 . This DC policy towards this file server did not get changed
    or altered in any way.

    I wasn't the person that did cloning/update, but as a part of our support team I'm trying to understand why the mapping has failed now.
    We do have other drive mappings as part of our group policy for drive mapping that did not fail. Only the mapping that pertains to the user's
    home directory appears to be our only mapping failure.

    run gpresult /h

    I did this and the report comes out clean and no errors were found.

    Dcdiag /v > c:\dcdag1.log

    As I was not familiar with this command I had to look it up. The command was not available on our 2019 server.

    Repadmin /showrepl >C\rptl.txt
    Repadmin /showreps *

    Again, not familiar with the command, but after reading about it I decided to run it to show only errors... so I did

    repadmin /showrepl /errorsonly

    No errors were found.

  3. Fan Fan 15,186 Reputation points

    So the only change was that the old 2008 DCs were replaced by the 2019 DCs.
    And now all the new DCs are working well with no errors.

    Then i would recommend you check more details by the GPSVC log for users not applied the mapping drive policy.
    For how to use the GPSVC , you can refer to :

    Best Regards,

  4. Philippe Levesque 4,701 Reputation points MVP


    From computer that does not work try to naviguate to the network share manually. Is it working ?

    If not, try with the FQDN


    Newer security patch in 2019 restrict more that with lanman.

    If it does not work, is it a share in SMB1? then enable SMB1 support please to try.