Sync or Swim

Another look at offline folders that comes with a workaround.

• By Bill Boswell
• 08/19/2003

UserA is working on a Windows 2000 Professional workstation with My Documents redirected to a home folder on ServerA via Group Policy in a native AD environment. UserA makes changes to Document A and logs off.

The files synchronize as expected, by showing the server and path of the location being synchronized, \\ServerA\UserA.

UserB logs onto the same Windows 2000 Professional workstation with the separate policy redirecting folders to \\ServerB\UserB. Whether or not UserB makes any changes, when UserB logs off the same synchronization window pops up and shows synchronization occurring on both \\ServerA and \\ServerB. However, it ends with an error that there is insufficient permissions to synchronize with \\ServerA.

If I log back in as UserB and log off and choose "Setup" when the Offline Files are synchronizing, then I can uncheck which server I do not want to synchronize from this profile. This will then remove the error when UserB logs off. However, I sure don't want to make this profile change for every user.

I appreciate the topics you address—many times there are some interesting tidbits to be learned!
—Scott Krahn

Scott: After reading your excellent problem definition, I absolutely agree that I did not address the core issue when I answered the first reader on this subject. This whole business of redirected shell folders and offline caching turns out to present a very interesting situation.

I'd like to clarify a couple of points in Scott's scenario. Redirecting the My Documents folder to separate shares based on the user's folder is not a good idea. The better approach is to create a root share with the path \\ServerA\UserDocs then redirect the My Documents folders to that root share using basic redirection with the path; for example, a redirection path of \\ServerA\UserDocs\%username% creates individual user folders under the UserDocs share.

Setting NTFS permissions on the root folders to give the domain Users account Read/Execute/Traverse permission avoids the synchronization error without given the users Write/Create rights at the root of UserDocs. This meets your design specification of keeping users from finding a cranny where they can stuff their MP3 files and other data detritus.

The more interesting issue, though, is why redirected My Documents folders from multiple users of the same machine results in a synchronization event that touches all the shared folders.

Ignoring My Documents for a moment, let's do a test on a standard, run-of-the-mill shared folder:

Let's say UserA maps to \\serverA\Data and configures the mapped drive for offline folder caching. The icon for the share now changes to the double-headed arrow. (This assumes that the share has been configured to permit offline caching.)

If UserA creates a file in the mapped drive then opens the Synchronization Manager, he sees the \\serverA\Data UNC in the synchronization list. When he logs off, he sees a synchronization transaction for this UNC.

A little while later, UserB logs onto the same machine. UserB maps a drive to \\serverB\Apps and configures the mapped drive for offline folder caching. The icon for the share changes and he saves a file in the mapped drive.
When UserB opens Synchronization Manager, he sees the \\serverB\Apps UNC in the synchronization list. He does not see \\serverA\Data. This is what you'd expect, because these settings get stored in the Registry in HKEY_Current_User under Software | Microsoft | Windows | CurrentVersion | Netcache.

Now... let's do the same thing by redirecting My Documents. Configure two GPOs that redirect My Documents to two different locations, \\serverA\UserDocs and \\serverB\UserDocs. Link the first GPO to OU-A and the second GPO to OU-B. OU-A contains UserA and OU-B contains UserB.
UserA logs on and verifies that the My Document redirection has taken effect by looking at the path in the Properties window. UserA configures My Documents for offline caching and puts a file in it.

If UserA opens the Synchronization Manager after creating or modifying a file in \\serverA\Data, he sees the \\serverA\UserDocs UNC in the synchronization list. When he logs off, he sees the sync checks for this UNC.
Now UserB logs on and verifies My Document redirection and configures for offline caching and plops in a file.

Here's the change: When UserB opens Synchronization Manager, he sees the \\serverB\UserDocs UNC and the \\serverA\UserDocs UNC in the synchronization list. When he logs off, he sees both UNC paths doing a sync.
You'll see the same behavior if you manually redirect My Documents rather than using Group Policy Objects.

Just to drive home a point, I configured five different users in five different OUs with five different GPOs, each redirecting My Documents to one of five different servers. As each user logged onto a single desktop and configured My Documents for offline caching, the UNC path for that user would get added to the UNC paths for the other users in Synchronization Manager.

When I got to the fifth user, I went back and logged on as the first user. This user now showed all five UNC paths in Synchronization Manager. The same held true for the other users.

This problem would be more acute with Windows XP because, unlike Windows 2000, Windows XP automatically uses offline caching for redirected shell folders unless you set a Group Policy Object to prevent it.

Bottom line? I'm trying to find out why offline caching of redirected shell folders behaves differently than standard shared folders and what can possibly be done from a central policy to prevent this behavior. The shell folder offline cache entries do not get stored in a central repository in the Registry. They apparently get added to each user's HKCU Registry profile from the main offline folder cache database.

Only laptop users should use offline caching. Configure a Group Policy to block offline caching and link this policy to OUs that contain standard desktops. Laptop users don't tend to share their machines very often, so they would not build up many synchronization events. The workaround for those users would be to open Synchronization Manager and uncheck all UNC paths except their own.

Not a good solution, I know, but I hope to find a better one soon. For now, I hope this helps.