Hi David,
The DO_NOT_REMOVE_NtFrs_PreInstall_Directory hidden folder is used as an
inbound staging area by the File Replication Service (FRS). By default, the
only users given access (and the only ones that should have access to this
folder) are members of the Administrators group and the local system
account.
When the user logs on to a client computer, the client attempts to download
the user's roaming profile (if one is specified). When the client attempts
to download the profile it tries to download every file and folder in the
profile. What is happening is the client is trying to download the
DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder which the user does not have
permission for.
Now, you do *not* want the DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder
as part of the user's profile. To solve this problem the best solution is to
not create DFS links directly to user's profiles. Instead, create one link
called something like UserProfiles. In the UserProfiles share, create
folders for each individual user. For example:
\\mydomain.com\DFSroot\UserProfiles\maubert
Mydomain.com is the domain, DFSroot is the DFS root, UserProfiles is the
link name that points to a share called UserProfiles, and maubert is a
folder inside of the UserProfiles share.
In the properties for the user account, you then setup the subfolder - not
just the link as the user's profile path. So in the above example the
profile path for the user should be set to
\\mydomain.com\DFSroot\UserProfiles\maubert.
This way the client only needs to download all the files and folders in the
maubert folder - not the root of the UserProfiles share which contains the
DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder.
By the way, the reason this worked before but does not work now is because
you enabled replication. When replication was enabled the
DO_NOT_REMOVE_NtFrs_PreInstall_Directory folder was created in the share of
each replica.
Having said all this, having multiple replicas for the same link is *not*
recommended for data like user profiles and user documents (i.e. how you
have it configured now). This is because data that is frequently written to
on multiple replicas can become out of sync. Having multiple replicas works
best when the data is written to infrequently - such as a software
distribution point.
If you want to have multiple replicas of your user profiles there is a
workaround, but it is limited. Go ahead and configure the link the way I
describe above and create multiple replicas. Configure automatic replication
for all replicas. Then, disable all but one of the replicas (right-click the
replica and then click Take Replica Offline/Online). Offline replicas appear
with a yellow exclamation icon over them.
When clients now look for a replica of the link, they will only be directed
to the one replica that is still online - they will not be directed to any
of the offline replicas. This ensures that clients only write data to one of
the replicas. Additionally, FRS will still replicate the data among all the
replicas - even if a replica is configured as "offline." The limitation to
this solution, however, is that there is no automatic failover. If the
server holding the only online replica goes offline, an Administrator will
manually need to select a new replica by bringing it online in the DFS
console (ensure the old replica is taken offline also).
------------------------------------------------------------------
Mike Aubert
MCSE, MCSD, MCDBA
(e-mail address removed)
Note the "news2" in my email address is temporary and may be changed in the
future, remove it to email me at my Permanente address.
This posting is provided "AS IS" with no warranties, and confers no rights.
