First published on TECHNET on Dec 06, 2005
[Updating with minor edits for clarify]
Customers frequently ask about the “primary member” designation in DFS Replication. Although this sounds like it could be a single master setting (meaning that content only originates and changes on this member), the primary member is used only during initial replication. Think of the primary member as your “look like me” member during initial replication. In other words, after initial replication is complete, all other replication group members will have the same content as the primary member. After the replicated folder is initialized (as reported by event 4002 , changes can originate on any member and will get the default fence value .
Richard Chinn recently described some “under-the-covers” details primary members in the email snippet below.
The primary member designation is stored in AD. The bit should only be set on one replication group member in the whole replication group for each replicated folder. When this member starts up fresh (i.e., no DFSR database), DFSR notes it has the primary flag set and will go through initial sync as the primary. This means the data won’t be fenced to lose, and instead of waiting for to sync with other partners before allowing outbound replication, the primary member will go online after the existing content has been walked and loaded into the DFSR database. At this point the primary flag in AD will be cleared. Note this is completely local to the primary machine. The initial sync “doneness” is not a replication group wide “doneness.”
By clearing the flag after the member is ready to replicate, if initial sync crashes or the service restarts, that member will see the primary bit and reattempt the primary initial sync. If for some reason the primary member suffers a database loss after clearing the primary bit in AD but before any of its partners could complete initial sync, then the entire replicated folder (on all members) won’t replicate since all are designated non-primary. In this case, you’d need to use dfsradmin membership /set /isprimary:true to fix things up manually by specifying a single member as primary.
Another thing to note is the primary designation is only used and is only written during the initial sync process. If you have a working replication group and used dfsradmin to set primary on a replicated folder for a given member, DFSR will leave the bit alone. But if you subsequently delete the DB on that machine or more unfortunately if the DFSR internal database gets corrupted resulting in an automatic rebuild, then instead of being a “slave “ in initial sync, the machine will be a primary. This could be a bad thing since you now have a rogue primary coming up in a replication environment that is alive and well. Conflicts will result.
--Richard
