First published on TECHNET on Dec 15, 2005
A customer noticed that after deleting a replicated folder from a replication group, some subfolders under the DfsrPrivate folder (which is under the local path of the replicated folder) remained on the volume. This behavior is by design--DFS Replication does not clean up some internal folders that can have user data on a member after it is no longer participating in replication. Our DFS Replication gurus explain the details:
A customer noticed that after deleting a replicated folder from a replication group, some subfolders under the DfsrPrivate folder (which is under the local path of the replicated folder) remained on the volume. This behavior is by design--DFS Replication does not clean up some internal folders that can have user data on a member after it is no longer participating in replication. Our DFS Replication gurus explain the details:
When a replicated folder is deleted from configuration, DFS Replication first marks it as tombstoned in its internal database (but does not delete any database records for it). After the tombstoning period (hard-coded to 60 days) has expired, DFS Replication will delete the database records and the staging files for that replicated folder (typically under DfsrPrivate), but it will not delete the rest of DfsrPrivate since that also contains folders like ConflictAndDeleted and PreExisting that may contain content the administrator is interested in preserving.
--Jill
Updated Apr 10, 2019
Version 2.0
