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:

1. Define the scenario
2. Describe the expected and the actual results
3. Describe what happens in order to understand why this scenario will create this result
4. List possible ways to change the operation of the Drive Maps preference extension to map a drive every logon instead of every other logon

1 - Define the Scenario

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.

3 - Why did this Happen?

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,” http://technet.microsoft.com/library/cc787386.aspx.

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:

1. At the first logon, Group Policy determines that it is processing in the foreground and calls the Drive Maps preference extension.
2. The Drive Maps preference extension determines that Group Policy is processing asynchronously, by default, because this is a client with Fast Logon Optimization enabled.
3. The Drive Maps preference extension does not apply any preference item settings on this logon because it needs to process synchronously when applying the preference item settings. Instead, Drive Maps will return a request for Group Policy to run synchronously on the next logon.
4. Group Policy waits for background processing for the user to log off.
5. If Group Policy processes in the background, the Drive Maps preference extension is not called during background processing because the NoBackgroundPolicy registry value is set to a 1 for the Drive Maps preference extension.
6. At some point, the user logs off which ends the first logon session. At this point, the Drive Maps preference extension has signaled for Group Policy to run synchronously, but has not applied the preference item settings.

End of second logon – Drive Maps preference items applied

Interactions with other policy settings

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.

1 - Set NoBackgroundPolicy reg value to 0 (not recommended)

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.

2 - Set Group Policy to always run synchronously

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.

3 - Set the reconnect option for 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.

See Also

Group Policy Troubleshooting portal page for the Technet wiki,
see http://social.technet.microsoft.com/wiki/contents/articles/2200.wiki-troubleshooting-portal.aspx#Group_Policy

Introduction to Preferences,
see http://technet.microsoft.com/library/cc731892.aspx