I recently worked with Microsoft to resolve a problem in our Windows 8.1 environment where Group Policy Preference Drive Mappings to shares on the DFS were failing when users logged in immediately after a computer restart. Through the use of procmon boot logging, we were able to identify that the ApplySettingsTemplateCatalog.exe process, which is part of UE-V 2.1 and which is triggered at computer startup by the Microsoft\UE-V\Template Auto Update scheduled task, was attempting to access the DFS soon after the Offline Files service started and before the network was initialized. Offline Files recognized that the DFS was not available and transitioned the DFS root to offline mode. If a user logged on before Offline Files re-evaluated the DFS root two minutes later, the drive mappings would fail, along with any other attempts to access locations on the DFS.

To work around this problem, we added a one minute delay to the “at startup” trigger on the Template Auto Update task. The task therefore does not attempt to access a location on the DFS before the network is ready, and consequently Offline Files does not step in and take the DFS offline.

Some background on our environment and observations of the problem

Our users’ home drives are specified in each user’s account in AD. The home drive is connected to a path on the DFS and is assigned to drive letter H.

The Documents folder is redirected into the user’s home drive on the DFS via Group Policy and is automatically made available offline.

GPP drive mappings to shares on the DFS fail when users log on after a computer restart.

GPP drive mappings to non-DFS locations (shares on various servers) are always successful.

The Offline Files/Operational event log contains “Path disconnected” (Event ID 9) entries to the DFS root and the parent directory of the user’s home drive during boot and logon when the drive mappings fail. The log contains “Path reconnected” (Event ID 10) entries to the DFS root and the parent directory of the user’s home drive shortly after logon.

When the drive mappings fail, if File Explorer is opened immediately after logon, only the redirected Documents folder and the UE-V SettingsPackages folders are visible in the user’s home drive. Navigating into the Documents folder and highlighting a file shows the state as “Offline status: Offline (not connected).” in the details pane of File Explorer. This indicates that Offline Files has transitioned the path to “Auto offline mode”. After a few moments, the rest of the folders in the user’s home drive will appear in File Explorer and the state of the files in the Documents folder will change to “Online”.

If Offline Files is disabled via Group Policy, or if the CSC kernel driver is disabled via a registry value, the drive mappings are always successful.

If the CSC is re-initialized by creating the FormatDatabase registry value and rebooting the computer, the user is able to log in with successful drive mappings.

Obscuring the cause

As is often the case, I could have arrived at the cause more quickly if I had let the facts tell their story.

In the beginning of my troubleshooting, I ruled out a network problem by running a few Wireshark captures that showed that the computer was not attempting any network connections to the DFS when the drive mappings failed. This took a few hours, but was fun and informative, so it wasn’t a waste of time by any means.

I also spent considerable time making changes to the Offline Files settings in Group Policy, the GPP drive map options, and the user’s home drive, and testing the effects of these changes. I gained quite a bit of new understanding in these areas, but was, in hindsight, off base.

I would occasionally see that the HOMESHARE environment variable was missing, and that the HOMEDRIVE and HOMEPATH variables had incorrect values. This, too, was a very interesting observation that did not get me any closer to the cause of the problem.

The Offline Files Operational log entries, when matched up chronologically against the System log events, would have shown that the DFS was being transitioned offline before the network was up, but I was distracted by all of the user-specific elements involved. The problem was occurring much earlier in the startup process than I realized.

Procmon illuminates the root cause

At Microsoft’s suggestion, I enabled boot logging in procmon and captured the events during computer startup. With this new source of information available, I finally got around to looking at what was happening on the computer at the time that Offline Files was transitioning the DFS to offline mode.

The critical piece of the puzzle, I believe, was that we were locating our UE-V Template Catalog directory on the DFS as well. It was this path that was being evaluated on boot – not any path to do with the users’ home drives or the redirected Documents folder. When UE-V attempted to access the Template Catalog path before the network was initialized by way of the Template Auto Update scheduled task, Offline Files properly transitioned the DFS to offline mode. Offline Files transitioned the DFS back to online two minutes later, but by this time, the user had already logged on and the GPP drive mappings had already failed.

Closing thoughts

It seems to me that this problem would occur with some frequency, as it may be reproduced in what I imagine to be a pretty typical corporate environment:

1. hardware capable of starting up the Client Side Caching kernel driver and running the Template Auto Update scheduled task before the network is available
2. Offline Files enabled (it is enabled by default)
3. user home drives located on the DFS at a path like \\domain\dfsroot\users\%username%
4. Documents folder redirected to a location on the DFS like \\domain\dfsroot\users\%username%\documents
5. UE-V Template Catalog directory located on the DFS at a path like \\domain\dfsroot\data
6. GPP drive maps to shares on the DFS at paths like \\domain\dfsroot\public_documents

In this completely reasonable scenario, two pretty amazing Microsoft technologies, at their default settings, fail to work well together and cause the failure of a third technology.

The Microsoft support engineer handling this case also explained why the HOMESHARE variable was occasionally not set:

The HOMESHARE environment variable is set by the profile service while a user is logging in and has a home drive specified on their account. This will be set upon successful mapping of the home drive. If that is not mapped successfully then it is not set and HOMEDRIVE and HOMEPATH are set to c:\ and \USERS\<username> respectively. This is just a symptom of the root being taken offline earlier and maybe for a user that hasn’t logged onto the machine and cached any information yet with the root being offline. Also with the root being offline, the user’s home drive may map successfully, but other mapped drives that map into the DFS Namespace can fail.