How does DFSR function on Read Only Domain Controllers?

How does DFSR function on Read Only Domain Controllers?

  • Comments 2
  • Likes

In Windows Server 2008, the DFS Replication service can be used for replication of the SYSVOL share between domain controllers operating in the Windows Server 2008 domain functional level. The DFS Replication service supports replication of the contents of SYSVOL share between Read Only Domain Controllers (RODC) as well. This blog post explains how the DFS Replication service performs replication activities on a Read Only Domain Controller. The below behavior is limited only to the SYSVOL replicated folder on RODCs and does not apply to regular non-SYSVOL replicated folders in Windows Server 2008.

Reverting local changes

On a Read Only Domain Controller, the DFS Replication service reverts all changes that have been made locally. When an administrator makes a change (modify/create/delete etc.) to the contents of the SYSVOL share on an RODC, the administrator will not be blocked from making the change. However, the DFS Replication service will take steps to revert those changes in the background. The changes will not be replicated out to other replication member servers (other domain controllers). Let’s take a look at how things work under the hood.

a)       DFSR identifies local changes: The DFS Replication service keeps track of all changes which it has made to the contents of a replicated folder during the process of installing updates from its replication partners (other domain controllers). In other words, any change which has been replicated in from other replication member servers is marked as such. All other changes are local modifications, which the service needs to rollback (undo).

 

b)       DFSR regularly monitors for changes: The DFS Replication service is a consumer of the NTFS USN (Update Sequence Number) journal. Entries in the journal inform DFSR about what changes have occurred on the file system and that is how DFSR knows it needs to replicate modified content in its replicated folders.

 

c)       DFSR never replicates out changes made locally on the RODC: On an RODC, the DFS Replication service’s internal state machine is designed such that it will never replicate out changes, which it has identified to be of local origin, to its replication partners. Therefore, even if the RODC has an outbound connection to its peers, the DFS Replication service will never replicate out local modifications on this outbound connection. This is illustrated in Figure 1 below.

 

d)       DFSR reverts ‘new’ local changes: When the DFS Replication service notices local changes which have never been replicated out before, it reverts those changes without letting them replicate out. For example, if an administrator created a new file/folder in the SYSVOL folder on an RODC, the new file/folder that has just been created will be deleted by the DFS Replication service. This prevents other replication partners from ever seeing that change. If the application which created the file still holds a handle open to it, the DFS Replication service will perform the deletion when the file handle is closed.

 

e)       DFSR over-writes local changes to ‘existing’ files: When the DFS Replication service encounters a change to an existing file/folder, it takes steps to overwrite the changes to that file and re-synchronizes the file with the contents from a Read Write enabled domain controller. Here’s how this happens:

 

i)                     The DFS Replication service keeps track of local updates which have occurred. When it encounters an update to an existing file/folder, it checks the record corresponding to that file in its database.

ii)                   It then requests its replication partner (a Read Write enabled domain controller) to provide the version information for that file.

iii)                  The DFS Replication service checks to see if the version of the file on the Read Write enabled domain controller is safe to replicate in (i.e. if the version of the file on the partner is the same/fresher than the one which has just been changed locally on the RODC).

iv)                  Thereafter, the DFS Replication service on the RODC downloads the contents of the file from the partner Read Write enabled domain controller and overwrites the version present locally (which had earlier been modified).

DFSR reverts local changes on an RODC 

Figure 1: DFSR reverts local changes on an RODC.

f)        Regular replication activity is unaffected: When the DFS Replication service receives an update from its partner Read-Write enabled domain controllers, it notes this fact in the version information for that file. Therefore, when this update is installed by the service locally on the RODC, that update will not be mistaken as a locally originating change and will therefore not be reverted.

 

Supported Configurations

As a result of the way the DFS Replication service uses version information on Read Write enabled domain controllers to undo changes that occur locally on the RODC, the following connection related requirements assume significance.

NOTE: Please note that no user/administrator intervention is required since Active Directory on Windows Server 2008 automatically configures connections between domain controllers to adhere to these requirements.

a)       It is required that each RODC be connected to at least one Read Write enabled domain controller.

 

b)       RODCs are possible only as leaf nodes. Thus neither an RODC nor a Read Write enabled domain controller should be connected to an RODC.

Valid and Invalid RODC connections 

Figure 2: Valid and Invalid RODC connections.

-------

Mahesh Unnikrishnan

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • PingBack from http://damon.supervidsdigest.info/dfsr.html

  • The Windows Server 2008 R2 Beta is now available. If you’re participating in the beta program or are