This topic walks through a single scenario for the Drive Maps preference extension, when the Replace action has been selected. The goal of this walk-through is to provide context for troubleshooting the Drive Maps preference extension.
Note: This topic applies to client-based computers, such as Windows 7, Vista and Windows XP, where Fast Logon Optimization is applied by default.
This topic will cover the following things:
An administrator applies a Group Policy logon script that maps a drive(s) for specific users to point to a location they need in order to do their jobs. This script first deletes all mapped drives that have persisted from the user’s previous session and
then maps the desired drive(s). In this way, the user will always start from a known set of mapped drive(s).
The administrator changes from using a logon script to using the Drive Maps preference extension because it’s easier to manage and maintain than a bunch of logon scripts. It’s well understood that all preference extensions do not enforce their settings.
In other words, if a drive is mapped through the Drive Maps preference extension user can change or delete the drive. For an introduction to Preferences, see
http://technet.microsoft.com/library/cc731892.aspx. But that’s okay because the administrator has read that the Replace action for Drive Maps will first delete the existing drive and then create the desired drive.
For example, a Drive Maps preference item is created to map drive Z: to the NETLOGON share of the DC (CONTOSO-DC). The New Drive Properties would look like the New Drive Properties figure show below.
All common properties have been left unchecked.
To test how this preference setting will work, the GPO that contains the new Drive Maps preference item is linked to the domain.
Expected Result: Drive Z: is mapped to
\\CONTOSO-DC\netlogon every time the user logs on to their computer.
Actual Result: Drive Z: is only mapped to
\\CONTOSO-DC\netlogon every other time the user logs on.
Note: This difference in when Drive Z is mapped will only be noticeable if either the administrator first deletes all mapped drives at the start of processing Group Policy or the user has changed Drive Z during their previous session.
The Drive Maps preference extension can only apply preference items when Group Policy is processing synchronously. For a discussion of the difference between synchronous and asynchronous processing, see “Troubleshooting Group Policy Problems,”
In addition to requiring to synchronous processing, the Group Policy engine only calls the Drive Map preference extension during foreground processing, never during background processing. The reason Drive Maps preference extension is not called during background
processing is because the NoBackgroundPolicy registry value associated with the Drive Maps extension is set to 1, do not process during background refresh. For more information about registry values associated with client-side extensions,
see KB article 216358, http://support.microsoft.com/kb/216358.
These two requirements result in the Drive Maps preference extension only being called every other logon, not every logon. It’s easier to see why this happens using a flowchart.
Figure 1 - Interaction between Group Policy infrastructure and Drive Maps preference extension
Note: This process flowchart assumes that the Drive Maps preference extension is the only CSE configured for Group Policy in order to simplify the discussion. More about the interactions with other CSEs will be said at the end
of this section.
Let’s walk through the process flowchart in order to understand why it takes two logons for the Drive Maps preference extension to apply the preference item:
End of second logon – Drive Maps
preference items applied
If there other CSEs that require synchronous processing have policy settings change, Group Policy may be signaled to run synchronously for an early cycle. In this case, all CSEs that require synchronous processing will also process their settings. This may
seem as if the application of the Drive Maps preference items is random, but the processing can still be traced from an understanding of when these settings should be processed. You can turn on logging and tracing for the Drive Maps preference extension to
see when the Drive Maps preference extension is called by Group Policy.
There are several alternatives that have been tried in order to make the Drive Maps preference extension process on every logon. Please add new suggested solutions as you discover them.
This solution has been suggested in several blog posts on the Internet. Looking back at figure 1, it seems that if the NoBackgroundPolicy registry value is set to ‘1’ (one), then the Drive Maps preference extension should be called during both foreground
and background Group Policy processing. This will then duplicate the behavior you see with other extensions that require synchronous processing, such as folder redirection and software installation.
Even with changing the value of NoBackgroundPolicy registry value to 0, if background processing does not run, possibly due to the user logging off early, then it will take two logons for the Drive Maps preference extension to process.
In this case, there is still no guarantee that the Drive Maps preference extension is called every logon with synchronous Group Policy processing. With the NoBackgroundPolicy registry set to 0, the Drive Maps preference extension may reapply settings every
logon, but could take up to two logons to sometimes apply.
And it is unclear what other impact setting the NoBackgroundPolicy registry key to 0 will have.
A better solution that will guarantee Drive Maps preference extension will be called every logon is given in the next solution.
It is the need to first signal Group Policy to run synchronously on the next logon that is causing the Drive Maps preference extension to reapply settings every other logon.
Instead, you can set the “Always wait for the network at computer startup and logon” policy setting. This can be found at:
Computer Configuration\Policies\Administrative Templates\System\Logon
If you enable this policy setting, client computers wait for the network to be fully initialized before users are logged on. Group Policy is applied in the foreground synchronously.
By enabling this policy setting, every user logon will be processed synchronously. The Drive Maps preference extension will determine every logon to be synchronous and therefore process the drive map preference settings every logon.
The down side to this change in behavior is that it takes more time to restart the computer and logon to the computer when Group Policy processes synchronously. The trade-off becomes choosing consistent behavior or slower logon times.
If the concern is making sure that the drives stay mapped as opposed to making sure the drive maps are not overwritten during the user session, a potential solution could be to use the reconnect option with the Drive Maps preference item.
The reconnect option is the same as mapping a drive using the /PERSISTENT attribute. This allows the state of the mapped drive to be saved between user logon sessions.
In this solution, use Create action to map a drive that persists between user logons.
This would allow for faster logons because Group Policy wouldn’t be forced to run synchronously every logon cycle.
The down side to this solution is that it assumes the user will not be changing the mapped drives. If there is a desire to control the initial state of all mapped drives for a user logon session, then the second solution would be the best solution.
Group Policy Troubleshooting portal page for the Technet wiki,
Introduction to Preferences,