Share via

GPP Drives maps causing slow logon due to unavailable file servers - and how to make sure they won’t


Michael here again, and this time I would like to discuss the Group Policy preferences drive maps feature and some caveats on the way.

The Group Policy Preference is a powerful new feature introduced with Windows Vista and later. Using the GPP opens a lot of new options like creating registry keys, copying files, creating scheduled tasks and many more.

One of the options in GPP is drive mapping. Using this feature allows us to map network drive for a client during logon, something that was previously done mostly using logon scripts.


In this post I would like to discuss one caveat when using GPP drive maps.

Many organizations have a logon script aging longer than any IT admin can remember, and no one can really say what drive maps are needed and which ones are retired (located on not existing servers or shares and can be removed).

That’s the power of history.

Obviously mapping shares which are no longer required isn’t a good practice as this may cause longer logon time.

That’s the same with GPP drive maps!

When you’re trying to map a share on a server which no longer exists it will cause the GPP Client Side Extension processing (more about group policy processing to wait for the “Network path not found” error until it continues to the next share, and that may take a while (This error is reported from the network, so it really depends on your network topology, name resolution configuration etc’ to figure out how long it will take until you’ll get the error).

Here’s a couple of examples of the GPP processing times:

Mapping one share which is functioning properly:



We’ve mapped it in 671 milliseconds!!!! (was that way faster than doing net use or is it just me?? – note to self: compare mapping times).


GPP processing time with one bad mapping (really small environment 3 VMs in a dedicated virtual network):


Now we’re looking and 5.7 seconds of processing time during the user’s logon… not good..


2 bad mappings:


9.2 seconds

And it will keeping growing the more bad mapping you have.

I guess you got the point :-)

(BTW – if you’re asking how do I get those in event viewer – simple – I didn’t do anything, those are all outputted in the GroupPolicy Operational Log under EventViewer-> Application and Service Logs –> Microsoft –> Windows –> GroupPolicy –> Operational).


How do I know that was the reason?

I’ve enabled GPP Extension logging (as described by Ned here -, and looking at the log file you can see the following lines:

2010-11-10 18:20:25.978 [pid=0x3a0,tid=0x1e0] Starting class <Drive> - K:.
2010-11-10 18:20:25.978 [pid=0x3a0,tid=0x1e0] Set user security context.
2010-11-10 18:20:31.421 [pid=0x3a0,tid=0x1e0] Set system security context.
2010-11-10 18:20:31.421 [pid=0x3a0,tid=0x1e0] Properties handled. [ hr = 0x80070035 "The network path was not found." ]
2010-11-10 18:20:31.441 [pid=0x3a0,tid=0x1e0] EVENT : The user 'K:' preference item in the 'Drive Maps for Users {FAED146F-8938-4B9A-9705-BCA1B3ED0090}' Group Policy object did not apply because it failed with error code '0x80070035 The network path was not found.'%100790273
2010-11-10 18:20:31.441 [pid=0x3a0,tid=0x1e0] Error suppressed. [ hr = 0x80070035 "The network path was not found." ]

Took us ~6 seconds to verify the path was not found. (Note: That’s not GPPs fault.. that’s the Administrators fault trying to map folders on servers that are no longer there, GPP CSE is just doing what it’s told to do!).

So now the obvious question is how can we deal with it.

Since the GPP stores it’s data in XML file format under the relevant Group Policy in SYSVOL it shouldn’t be very difficult to read that XML and verify all paths are correct.

Here’s our sample screen shot of an XML file:



Using Powershell we have created the following 15 lines wonder:

 #This script accepts the path to the GPO GPT object as a parameter
#For example: "\\\SYSVOL\\Policies\{FAED146F-8938-4B9A-9705-BCA1B3ED0090}"

$currentErrorAction = $ErrorActionPreference
$ErrorActionPreference = "SilentlyContinue"
$drivesContent = Get-Content ($args[0] + "\User\Preferences\Drives\Drives.xml")
$drivesXML = [xml]$drivesContent
foreach ($drive in $drivesXML.Drives.Drive)
  $result = Test-Path $drive.Properties.path

  if ($result -eq $false)
     write-host "Error connecting to" $drive.Properties.path -ForeGroundColor Red
     write-host "This drive is mapped" as $drive.Name -ForeGroundColor Red
     write-host "------------------------------------------------------------------------------"

$ErrorActionPreference = $currentErrorAction

This script accepts as a parameter the path to the Group Policy Folder in SYSVOL (for example “\\\SYSVOL\\Policies\{FAED146F-8938-4B9A-9705-BCA1B3ED0090}” – important: Don’t forget to include the quotes!), and then accesses the well known location of the Drive Maps XML file (\User\Preferences\Drives\Drives.xml), reads the XML and outputs any validation errors to the screen.


Hopefully now you’ll be able to cut a couple of seconds in your user’s logon time and do some quick and simple periodic testing on your drive mapping GPOs to make sure everything is still in place.

BTW – Additions, upgrades and suggestions to the script are always welcome.