Group Policy replication change
Before I start the SYSVOL replication changes in windows server 2008, I would like to explain how the GPO has been replicated in windows server 2003 and earlier versions
Understanding SYSVOL/GPO replication
Group policy template (GPT) and group policy container (GPC) are two types of Group policy settings, Its stored in two different locations and uses different replication technology to replicate the changes, however both should be available up-to-date on domain controller to function properly
Group policy templates are stored in SYSVOL, it’s a folder structure in SYSVOL share on a domain controller, if you create a new Group Policy it will create a Group policy templates folder on SYSVOL share for the new policy that contain the group policy setting related to this policy, GPT folder name would be Globally Unique Identifier (GUID) of the GPO that you created, you can view all the GPT folders from the below Path (it’s a default GPT path)
C:\Windows\Sysvol\Sysvol\DomainName\Policies
Group Policy template (GPT) is replicated by SYSVOL through FRS, FRS uses state-based replication. As soon as there is a change to any file under the Sysvol folder structure, replication is triggered and entire file get replicated
Group policy containers are stored in Active Directory, mostly all the GPO setting are stored in GPT (Group policy templates), GPC only have the reference information of the corresponding GPO, like GPT path, GUID of the GPO, version information, WMI filter information, and a list of components that have settings in the GPO, you can view the GPC from Active Directory Users and Computers (ADUC)
\System\Policies
Group policy container (GPC) is replicated through Active Directory replication
Note: By default the Group Policy Management Editor console (GPME) uses the PDC Emulator so that all administrators can work on the same domain controller, if you want a different Domain controller you can change through Group Policy Management console (GPMC)
File Replication Services (FRS)
I will try to explain step by step, let say you modify the Policy A from Server001 and how this change get replicated to Server002 (Server002 is a downstream replication partner for server001)
• Once you modify the Policy A from server001, the corresponding GPT folder on SYSVOL gets updated on the server001 (also updates the Group policy containers in Active Directory on server001)
• NTFS will change the USN journal according to the file and folder change.
• FRS monitors the USN journal for changes on the SYSVOL folder
• FRS updates the inbound log on server001, FRS not only updates the local changes on inbound log, also updates the inbound log for the changes from entire upstream replication partner (all inbound partners)
• FRS creates a file in staging folder on server001 by using APIs (backup application programming interfaces) based on the change.
• This change has been updated on outbound log on server001 by FRS. And also send change notification to entire downstream replication partner about the change (all outbound partners)
• Server002 get the change notification from Server001 and store the change order in inbound log, Server002 copies the staging file from Server001 to the staging folder on Server002. Server002 then update outbound log so other outbound partners can pick up the change
• Using Restore APIs, Server002 reconstructs the file and folder in the preinstall folder, and then FRS renames the file or folder into the replica tree
In FRS replication process the entire changed file and folder get replicate to source to destination server
What is NTFS USN journal?
Logs all the changes to an NTFS volume, including file creations, deletions, and changes, Separate log on each NTFS volume and it has a size limit (Windows server 2003 SP2 & Windows server 2008 is 128 MB) if require you can increase the size up to 2 TB, however MS Recommends increasing by 128 MB for every 100,000 files/folders
What happens when the NTFS USN change journal fills up?
If the USN journal log fills up then NTFS will be overwrite the old entry’s, that’s why in some scenarios before the change get updated, NTFS delete the entries in USN journal log, it’s called journal_wrap
USN journal wrap Error
An error that occurs when large numbers of files change so quickly that the USN journal must remove the oldest changes (before FRS has a chance to detect the changes) to stay within the specified size limit, to resolve this issue you have to perform a non-authoritative restore also called D2
Morphed folder
Replication conflict will occur if identically named directories are created in different servers, to resolve this conflict FRS create a folder and this folder called morphed folder
Let’s say two identical directories are created in different replication members, FRS identifies the conflict during replication, and the receiving member protects the original copy of the folder and renames (morphs) the later inbound copy of the folder. The morphed folder names have a suffix of “_NTFRS_xxxxxxxx,” where “xxxxxxxx” represents eight random hexadecimal digits.
Version vector join (vvjoin)
Till now we are discussing about the SYSVOL replication, how the SYSVOL replication works for the newly added replication partner, newly added replication member doesn’t have any updates, and it should build the folder structure from the beginning, this process is called vvjoin, in which a downstream partner joins with an upstream partner for the first time.
Vvjoin is a CPU-intensive operation that can affect the performance of the server and increase the replication traffic
Distributed File System (DFS)
Now we are coming to the point, how the SYSVOL replicating using DFS and how it’s been improved to provide better replication performance, to use this feature you should have Windows Server 2008 domain functional level that means all the domain controller has to be Windows Server 2008
SYSVOL replication using DFS is called DFS-Replicated SYSVOL (DFSR)
DFSR is a multimaster replication engine and changes that occur on one of the replication member are then replicated to all of the other servers in the replication group
DFSR also monitors the NTFS for the update sequence number (USN) journal to detects changes on the volume, and then DFSR replicate the changes only after the file closed
And before sending or receiving a file, DFSR uses a staging folder to stage the file
If any changes in SYSVOL share, FRS replicate the entire file unlike the DFSR, DFSR replicates only the changes blocks and not the entire file, sounds like a attribute level Active Directory replication, it compare the source and destination file using remote differential compression (RDC), it reduce the SYSVOL replication traffic
Other improvements are… (Difference between DFRS and FRS)
• DFSR and Journal Wraps, DFSR also monitors the NTFS change journal, but DFSR always heals itself hence no Journal Wrap error
• Morphed files and folders automatically taken care of
• FRS silently fails if the volume SYSVOL resides on < 1GB of free space
• Copies the changes on files and folder not entire files and folder
• Uses Version Vector tables to confirm the changes, also to resolve the conflicts
• Support read-only replication on a particular members in which users cannot add or change files
• You can also make the changes to the SYSVOL folder of an RODC
• DFSR does not require the version vector join (vvjoin) operation
Before I start the SYSVOL replication changes in windows server 2008, I would like to explain how the GPO has been replicated in windows server 2003 and earlier versions
Understanding SYSVOL/GPO replication
Group policy template (GPT) and group policy container (GPC) are two types of Group policy settings, Its stored in two different locations and uses different replication technology to replicate the changes, however both should be available up-to-date on domain controller to function properly
Group policy templates are stored in SYSVOL, it’s a folder structure in SYSVOL share on a domain controller, if you create a new Group Policy it will create a Group policy templates folder on SYSVOL share for the new policy that contain the group policy setting related to this policy, GPT folder name would be Globally Unique Identifier (GUID) of the GPO that you created, you can view all the GPT folders from the below Path (it’s a default GPT path)
C:\Windows\Sysvol\Sysvol\DomainName
Group Policy template (GPT) is replicated by SYSVOL through FRS, FRS uses state-based replication. As soon as there is a change to any file under the Sysvol folder structure, replication is triggered and entire file get replicated
Group policy containers are stored in Active Directory, mostly all the GPO setting are stored in GPT (Group policy templates), GPC only have the reference information of the corresponding GPO, like GPT path, GUID of the GPO, version information, WMI filter information, and a list of components that have settings in the GPO, you can view the GPC from Active Directory Users and Computers (ADUC)
Group policy container (GPC) is replicated through Active Directory replication
Note: By default the Group Policy Management Editor console (GPME) uses the PDC Emulator so that all administrators can work on the same domain controller, if you want a different Domain controller you can change through Group Policy Management console (GPMC)
File Replication Services (FRS)
I will try to explain step by step, let say you modify the Policy A from Server001 and how this change get replicated to Server002 (Server002 is a downstream replication partner for server001)
• Once you modify the Policy A from server001, the corresponding GPT folder on SYSVOL gets updated on the server001 (also updates the Group policy containers in Active Directory on server001)
• NTFS will change the USN journal according to the file and folder change.
• FRS monitors the USN journal for changes on the SYSVOL folder
• FRS updates the inbound log on server001, FRS not only updates the local changes on inbound log, also updates the inbound log for the changes from entire upstream replication partner (all inbound partners)
• FRS creates a file in staging folder on server001 by using APIs (backup application programming interfaces) based on the change.
• This change has been updated on outbound log on server001 by FRS. And also send change notification to entire downstream replication partner about the change (all outbound partners)
• Server002 get the change notification from Server001 and store the change order in inbound log, Server002 copies the staging file from Server001 to the staging folder on Server002. Server002 then update outbound log so other outbound partners can pick up the change
• Using Restore APIs, Server002 reconstructs the file and folder in the preinstall folder, and then FRS renames the file or folder into the replica tree
In FRS replication process the entire changed file and folder get replicate to source to destination server
What is NTFS USN journal?
Logs all the changes to an NTFS volume, including file creations, deletions, and changes, Separate log on each NTFS volume and it has a size limit (Windows server 2003 SP2 & Windows server 2008 is 128 MB) if require you can increase the size up to 2 TB, however MS Recommends increasing by 128 MB for every 100,000 files/folders
What happens when the NTFS USN change journal fills up?
If the USN journal log fills up then NTFS will be overwrite the old entry’s, that’s why in some scenarios before the change get updated, NTFS delete the entries in USN journal log, it’s called journal_wrap
USN journal wrap Error
An error that occurs when large numbers of files change so quickly that the USN journal must remove the oldest changes (before FRS has a chance to detect the changes) to stay within the specified size limit, to resolve this issue you have to perform a non-authoritative restore also called D2
Morphed folder
Replication conflict will occur if identically named directories are created in different servers, to resolve this conflict FRS create a folder and this folder called morphed folder
Let’s say two identical directories are created in different replication members, FRS identifies the conflict during replication, and the receiving member protects the original copy of the folder and renames (morphs) the later inbound copy of the folder. The morphed folder names have a suffix of “_NTFRS_xxxxxxxx,” where “xxxxxxxx” represents eight random hexadecimal digits.
Version vector join (vvjoin)
Till now we are discussing about the SYSVOL replication, how the SYSVOL replication works for the newly added replication partner, newly added replication member doesn’t have any updates, and it should build the folder structure from the beginning, this process is called vvjoin, in which a downstream partner joins with an upstream partner for the first time.
Vvjoin is a CPU-intensive operation that can affect the performance of the server and increase the replication traffic
Distributed File System (DFS)
Now we are coming to the point, how the SYSVOL replicating using DFS and how it’s been improved to provide better replication performance, to use this feature you should have Windows Server 2008 domain functional level that means all the domain controller has to be Windows Server 2008
SYSVOL replication using DFS is called DFS-Replicated SYSVOL (DFSR)
DFSR is a multimaster replication engine and changes that occur on one of the replication member are then replicated to all of the other servers in the replication group
DFSR also monitors the NTFS for the update sequence number (USN) journal to detects changes on the volume, and then DFSR replicate the changes only after the file closed
And before sending or receiving a file, DFSR uses a staging folder to stage the file
If any changes in SYSVOL share, FRS replicate the entire file unlike the DFSR, DFSR replicates only the changes blocks and not the entire file, sounds like a attribute level Active Directory replication, it compare the source and destination file using remote differential compression (RDC), it reduce the SYSVOL replication traffic
Other improvements are… (Difference between DFRS and FRS)
• DFSR and Journal Wraps, DFSR also monitors the NTFS change journal, but DFSR always heals itself hence no Journal Wrap error
• Morphed files and folders automatically taken care of
• FRS silently fails if the volume SYSVOL resides on < 1GB of free space
• Copies the changes on files and folder not entire files and folder
• Uses Version Vector tables to confirm the changes, also to resolve the conflicts
• Support read-only replication on a particular members in which users cannot add or change files
• You can also make the changes to the SYSVOL folder of an RODC
• DFSR does not require the version vector join (vvjoin) operation
No comments:
Post a Comment