Sync or Swim
Another look at offline folders that comes with a workaround.
- By Bill Boswell
on offline folder synchronization definitely brought
up some good points, but did not address the real problem according to
the way I read that person's question. I have a similar problem:
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 addressmany times there are some interesting
tidbits to be learned!
Help from Bill
Got a Windows or Exchange question or need troubleshooting
help? Or maybe you want a better explanation than provided
in the manuals? Describe your dilemma in an e-mail
to Bill at mailto:email@example.com;
the best questions get answered in this column.
When you send your questions, please include your
full first and last name, location, certifications (if
any) with your message. (If you prefer to remain anonymous,
specify this in your message but submit the requested
information for verification purposes.)
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
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
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
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.