Understanding the behavior differences of SYSVOL replication in Windows Server 2008 RODCs

Hi, Ned here again. Are you tired of me blogging about DFSR and FRS yet? If so, stop reading. :)

Today I am going to describe the architectural differences of SYSVOL replication on Read-Only Domain Controllers in Windows Server 2008 – FRS versus DFSR. This makes another good case for taking the effort of getting your domain functional levels to 2008 and migrating off of the File Replication Service.

Before I get rolling, a mini-glossary:

RODC - Read-Only DC (Introduced in Windows Server 2008)
RWDC - Writable DC (introduced in Windows 2000 Server)
FRS - File Replication Service (introduced in Windows 2000 Server)
DFSR - Distributed File System Replication (introduced in Windows Server 2003 R2)

Running RODCs with FRS as the replication engine for SYSVOL

While FRS can be used, it has some significant downsides in its behavior if the environment is not carefully administered. Since RODCs are designed to be placed in locations that will not have administrators or very basic role-separated administrators, this can be problematic. FRS does not contain the full plumbing to undo changes, but instead only prevents changes from leaving the DC.

• Files/folders created, modified, or deleted replicate from RWDC to RODC.
• Files/folders created, modified, or deleted do not replicate from RODC to
  RWDC.
  
• All changes within SYSVOL on the RODC survive inbound replication unless the
  same file path was changed upstream.
  
  (Example Scenario)

1. SYSVOL contains 2 policies for Default Domain and Default DC.
2. On the RODC an administrator adds a folder called 'my stuff'.
3. He also manually deletes the registry.pol file from the Default DC policy.
4. He also changes a gpttmpl.inf file to contain no data.
   
   (Outcome)
   
5. The folder called 'my stuff' continues to exist forever, unless deleted on the RODC or created on the RWDC, replicated down, and then deleted on the RWDC.
6. The registry.pol file stays deleted until it is updated on the RWDC and replicated back down to the RODC.
7. The gpttmpl.inf file stays empty until it is updated on the RWDC and replicated back down to the RODC.

As you can imagine, using FRS to replicate RODC SYSVOL folders has some administrative caveats and is not recommended. FRS ,as a feature, has effectively been deprecated (as you can tell from here and the Windows Server 2008 administration tools – where did DFSGUI.MSC go?).

Running RODCs with DFSR as the replication engine for SYSVOL

DFSR offers some architectural advantages that make it very compelling for RODCs.

• Files/folders created, modified, or deleted replicate from RWDC to RODC.
• Files/folders created, modified, or deleted do not replicate from RODC to
  RWDC.
• All changes within SYSVOL on the RODC are undone immediately by the DFSR
  service (i.e. they revert to whatever the RWDC has currently, allowing for replication latency).
  
  (Example Scenario)
  

1. SYSVOL contains 2 policies for Default Domain and Default DC.
2. On the RODC an administrator adds a folder called ‘some goo’.
3. He also manually deletes the contents of the Default Domain policy.
4. He also changes a gpt.ini file to not contain any data.
   
   (Outcome)
5. The folder called 'some goo' is immediately deleted.
6. The missing contents of the Default Domain policy is replicated back in as fast as replication allows.
7. The unmodified gpt.ini file is replicated back in as fast as replication allows.

For these reasons, DFSR-based SYSVOL replication (available when running in Windows
Server 2008 Domain Functional Mode) is recommended.

PS: Have you downloaded Windows Server 2008 R2 yet and deployed DFSR in a test environment? You are in for some surprises there with read-only. You should check that out…

- Ned “My First Born Was Named USN Journal” Pyle