| Server 2008, DFSR and RO DC's |
|
|
| Written by Richard Thompson (source http://blogs.technet.com/filecab), Thursday, 07 February 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Following the release to manufacturing of Windows Server 2008 earlier this week there have been a bombardment of blog posts regarding various new features, etc regarding this release. One of the most interested I've read was by The Storage Team. This post describes how Windows Server 2008 uses DFSR and Read Only domain controllers interact with particular emphasis on the Sysvol share: 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 (UpdateSequence Number) journal. Entries in the journal inform DFSR about what changes have occurred on thefile 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’sinternal state machine is designed such that it will never replicate out changes, which it has identified tobe of local origin, to its replication partners. Therefore, even if the RODC has an outbound connection toits peers, the DFS Replication service will never replicate out local modifications on this outboundconnection. This is illustrated in Figure 1 below. d) DFSR reverts ‘new’ local changes: When the DFS Replication service notices local changes which havenever been replicated out before, it reverts those changes without letting them replicate out. Forexample, if an administrator created a new file/folder in the SYSVOL folder on an RODC, the newfile/folder that has just been created will be deleted by the DFS Replication service. This prevents otherreplication partners from ever seeing that change. If the application which created the file still holds ahandle 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 changeto an existing file/folder, it takes steps to overwrite the changes to that file and re-synchronizes the filewith 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). 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 ConfigurationsAs 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. To read the blog post and see the images go to:http://blogs.technet.com/filecab/archive/2008/02/04/how-does-dfsr-function-on-read-only-domain-controllers.aspx
Powered by JoomlaCommentCopyright (C) 2006 Frantisek Hliva. All rights reserved.Homepage: http://cavo.co.nr/ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Next > |
|---|
|