————————————————————————————————————————————————————- This posting is provided “AS IS” with no warranties and confers no rights! Always evaluate/test everything yourself first before using/implementing this in production! This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years! DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ————————————————————————————————————————————————————- ########################### IAMTEC | Jorge’s Quest For Knowledge ########################## #################### https://jorgequestforknowledge.wordpress.com/ ###################
In the following article, I explained a scenario with test environments, where the SYSVOL replication breaks due to the use of snapshots. I also explained how to fix it.
Now, if you are using snapshots frequently to revert the test environment back to a certain state, fixing the SYSVOL will be part of that whole process. In addition, if you forget to fix the SYSVOL, you are working with a broken SYSVOL while not even realizing it, and that might have an impact one way or another.
Another approach to this problem is to disable the Generation ID process that detects any difference in the Generation ID between the VM and the registration on the computer account. That process is managed by the “Microsoft Hyper-V Generation Counter” (GenCounter) service. That service is not visible in the services.msc, but it is visible through Get-Service CMDlet. The idea is to disable that service on ALL DCs in the AD forest. The best way to achieve that is to configure a GPO in every AD domain, existing or new, that is linked to the “Domain Controllers” OU. That configuration in the GPO, tells every DC (RWDC and RODC) to DISABLE the “Microsoft Hyper-V Generation Counter” (GenCounter) service, but it will not stop it. A reboot of every DC, make sure that service is not started as it has been configured to be disabled. It is therefore a 2 step approach.
However, to configure a service in the System Services section of a GPO, the service itself must exist on the DC. Because the service does exist but is not visible, you can still not configure it through the GPMC. Another way to configure this is to use a registry preference. The downside of configuring this through a registry preference is that it tattoos the registry, meaning it will not be undone when you remove the configuration. When using a service in the System Services, it does not tattoo the system, and because of that it is preferred. Although not visible when you want to configure it, it is visible in the GUI if you want to remove it.
PS: please make sure to test this first in a test environment. DO NOT use it in any production environment!
That code would need to be used per AD domain and should be executed locally on 1 RWDC per AD domain. Remember, it should be used within all AD domains in the AD forest! Before using the code, configure first the name of either an existing GPO or a new GPO. In case of a new GPO, the code will create that GPO. With either an existing or new GPO, for it configuration to be affective, it must be linked to the Domain Controllers OU.
Just to be sure, a disclaimer: DO NOT USE SNAPSHOTS OR ANYTHING SIMILAR, OR ANY OF THE STEPS ABOVE IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT! Again: DO NOT DISABLE THE GENERATION ID PROCESS IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!
Please be aware, that when the Generation ID process is reenabled, after it has been disabled, it will detect a change which will trigger the behavior explained in the first part of the blog post. The fix of that is explained also in that first part.
Now, with a PERSONAL test environment that you use for regular testing of patches/updates, testing of AD features, security testing, scripting, testing AD-related products, used for learning/demoing, etc, etc, it is a common thing to use VM snapshots. The following are common steps in PERSONAL test environments:
Create and configure DCs and AD as needed
Shutdown ALL DCs in the AD Forest
For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
Boot up ALL or SOME of the DCs in the AD forest
Do whatever you need to do
When done, shut down all the DCs that were booted after the snapshot was created, and also revert all those DCs to the same snapshot. ==> Because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.
Do you need to perform updates on the DCs or AD, then follow the next steps:
Revert ALL DCs in the AD forest to the exact same snapshot as that is the snapshot containing the state of all DCs that all DCs know about each other ==> because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.
Boot up ALL DCs in the AD forest
Perform all required updates on either/both the DCs and/or AD
Shutdown ALL DCs in the AD Forest
For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
Delete the previous/older VM snapshot
Cheers,
Jorge
————————————————————————————————————————————————————- This posting is provided “AS IS” with no warranties and confers no rights! Always evaluate/test everything yourself first before using/implementing this in production! This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years! DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ————————————————————————————————————————————————————- ########################### IAMTEC | Jorge’s Quest For Knowledge ########################## #################### https://jorgequestforknowledge.wordpress.com/ ###################
————————————————————————————————————————————————————- This posting is provided “AS IS” with no warranties and confers no rights! Always evaluate/test everything yourself first before using/implementing this in production! This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years! DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ————————————————————————————————————————————————————- ########################### IAMTEC | Jorge’s Quest For Knowledge ########################## #################### https://jorgequestforknowledge.wordpress.com/ ###################
With many test environments, it is a common thing to create and configure a test environment with at least 1 AD domain and probably multiple domain controllers (DCs).
Before explaining what can happen and what all this is about, let’s just go back in time a bit to understand, why things work like they work.
Background
Apparently, one of the common things that occurred in production environments is that some admins created one or more snapshot of one or more virtual DCs before implementing changes, installing hotfixes/updates, and some even used it as a way to recover AD when needed. Another similar action on DCs running on physical hardware is restoring an image that contains the earlier state of the DC. The common cocktail of trouble, that resulted from any of these scenarios after reverting to a previous snapshot, is called USN rollbacks. With USN rollback, all other DCs have a higher USN for the DC that was reverted back through a snapshot. Put differently, the higher USN on the other DCs for the DC that was reverted back through a snapshot means those DCs all think that DC is already up-to-date, but in reality it is not. Updates from other DCs will therefore not replicate to that DC. This means inconsistencies, which in turn means different behavior. Examples of possible different behavior:
different results in LDAP queries
difference in authentication and authorizations
..and more.
The one and only solution of resolving the issues on a DC with USN rollback? Force demote the DC and clean up its metadata. After that repromote to a new DC.
More information about USN rollback can be found through the following links:
The quick and easy solution? Stop using snapshots with DCs!
The Microsoft solution? With Windows Server 2012, Microsoft introduced “Virtualization Safeguards For DCs” in both Windows and its hypervisor “Hyper-V”. Other virtualization platforms, like e.g. and amongst others VMWare, also implemented the same mechanism in their hypervisor to offer the same “Virtualization Safeguards For DCs”. The core solution is the support for VM-GenerationID by checking for it and comparing it. The process is explained in figure 1, and examples of events, when a DC is reverted to a certain snapshot state, are displayed in other figures.
Figure 1: The VM-GenerationID Check And Comparison Process
Figure 2: The Detection Of Generation ID And Its Current Value For The VMFigure 3: The Detection Of Generation ID And Its Current Value For The Computer Account In ADFigure 4: The Detection Of The Difference Between The Generation ID For The VM And The Generation ID For The Computer Account In AD
A Generation ID change has been detected.
Generation ID cached in DS (old value): 4655303322081246329 Generation ID currently in VM (new value): 9133133598227488399
The Generation ID change occurs after the application of a virtual machine snapshot, after a virtual machine import operation or after a live migration operation. Active Directory Domain Services will create a new invocation ID to recover the domain controller. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services aware backup application.
Figure 5: The Change Of The Invocation ID
The invocationID attribute for this directory server has been changed. The highest update sequence number at the time the backup was created is as follows:
The invocationID is changed when a directory server is restored from backup media, is configured to host a writeable application directory partition, has been resumed after a virtual machine snapshot has been applied, after a virtual machine import operation, or after a live migration operation. Virtualized domain controllers should not be restored using virtual machine snapshots. The supported method to restore or rollback the content of an Active Directory Domain Services database is to restore a system state backup made with an Active Directory Domain Services-aware backup application.
Figure 6: Configuring The Generation ID Value Of The Computer In AD With The Generation ID Value Of The VM ItselfFigure 7: The SYSVOL Being Initialized As Non-Authoritative
When there is a difference detected in VM-GenerationID between what the hypervisor knows and what the DC itself knows, it will trigger the “Virtualization Safeguards For DCs” to protect the AD environment from USN rollback. The following actions occur:
The identity of the database instance, a.k.a. the invocationID, is changed (Figure 5)
The RID pools the DC knows about are invalidated
A new RID pool is requested from the DC with the RID Master
The SYSVOL is put in non-authoritative mode by deleting either the NTFRS or DFS-R databases, while at the same time keeping the existing content of the SYSVOL that is used to pre-seed it. (Figure 7)
Any more recent changes or new objects in AD on other DCs that do not yet exist, are inbound replicated
Any more recent changes or new files in the SYSVOL on other DCs that do not exist yet, are inbound replicated. This, however, does require those other DCs to be either in normal mode, or authoritative mode.
Now after reading this, you might think: “Oh, that’s cool! I can now use snapshots to restore DCs without messing up the DCs or AD”. Well, actually, no! DO NOT DO IT!
The Impact Of The Solution
The “Virtualization Safeguards For DCs” are intended for production DCs. However, DCs are also used in test environments. For the larger TEST environments, the same rules apply as in production environments, as most likely those TEST environments are used by multiple teams, multiple applications and are continuously up and running.
However, if you have a PERSONAL test environment that you use for regular testing of patches/updates, testing of AD features, security testing, scripting, testing AD-related products, used for learning/demoing, etc, etc, it is a common thing to use VM snapshots. The following are common steps in PERSONAL test environments:
Create and configure DCs and AD as needed
Shutdown ALL DCs in the AD Forest
For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
Boot up ALL or SOME of the DCs in the AD forest
Do whatever you need to do
When done, shut down all the DCs that were booted after the snapshot was created, and also revert all those DCs to the same snapshot.
Do you need to perform updates on the DCs or AD, then follow the next steps:
Revert ALL DCs in the AD forest to the exact same snapshot as that is the snapshot containing the state of all DCs that all DCs know about each other
Boot up ALL DCs in the AD forest
Perform all required updates on either/both the DCs and/or AD
Shutdown ALL DCs in the AD Forest
For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
Delete the previous/older VM snapshot
Just to be sure, a disclaimer: DO NOT USE SNAPSHOTS OR ANYTHING SIMILAR, OR ANY OF THE STEPS ABOVE IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!
Now this looks easy, right? Are there any caveats to using these steps? Yes, there are! Have a look at the Virtualization SafeGuard for DCs in step 4 (the one about the SYSVOL).
Think about it, when reverting all DCs in an AD domain, all those DCs in the AD domain, are in a non-authoritative state and waiting to perform (initial) replication from a DC with either a normal or authoritative SYSVOL. Because all DCs in the AD domain are in a non-authoritative state, there is NO DC with either a normal or authoritative SYSVOL. Oops! The consequences are that all DCs are waiting for each in terms of SYSVOL replication. You might not even notice it immediately, but later on, you might experience weird behavior, like no SYSVOL replication, inconsistent SYSVOL content, inconsistent GPO behavior, etc
The Fix
Either immediately after reverting the snapshot, or later on if still possible, you need to repair the SYSVOL within an AD domain by marking 1 RWDC authoritative for the SYSVOL, and all others, incl RODCs, non-authoritative for the SYSVOL. The RWDC authoritative for the SYSVOL will initialize and mark itself as the primary member of the special and default DFS-R Replication Group called “Domain System Volume” with a DFS-R Replicated Folder called “SYSVOL Share”, while all other RWDCs/RODCs in that same AD domain, will also reinitialize and wait to perform initial replication from an RWDC with either a normal or authoritative SYSVOL.
When having multiple DCs in an AD domain, and even multiple AD domains with multiple DCs within the AD forest, that can be quite exhaustive to execute manually. Because of that, I have written some PowerShell code to do this automatically per AD Domain. The code can be executed on any DC, and by default, it will mark the RWDC with the PDC FSMO role as the RWDC with the authoritative SYSVOL, while marking all others as non-authoritative. If you need to have another RWDC to be authoritative, then specify its FQDN in the variable.
PS: please make sure to test this first in a test environment. DO NOT use in any production environment!
Cheers,
Jorge
————————————————————————————————————————————————————- This posting is provided “AS IS” with no warranties and confers no rights! Always evaluate/test everything yourself first before using/implementing this in production! This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years! DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ————————————————————————————————————————————————————- ########################### IAMTEC | Jorge’s Quest For Knowledge ########################## #################### https://jorgequestforknowledge.wordpress.com/ ###################
HIP 2021 starts tomorrow (Wednesday, December 1st)!
You can catch me going LIVE at #HIP2021 on December 2nd (Thursday) at 10:30am – 11:30am EST (16:30pm – 17:30pm CET) as I join in on the conversation about the hybrid identity world with my session, “Resurrecting After A Ransomware Attack – Be Secure, And Prepared!”!
You can still register for FREE using the following link:
————————————————————————————————————————————————————- This posting is provided “AS IS” with no warranties and confers no rights! Always evaluate/test everything yourself first before using/implementing this in production! This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years! DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ————————————————————————————————————————————————————- ########################### IAMTEC | Jorge’s Quest For Knowledge ########################## #################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
Cheers, Jorge ——————————————————————————————— * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ——————————————————————————————— ############### Jorge’s Quest For Knowledge ############# ######### http://JorgeQuestForKnowledge.wordpress.com/ ######## ———————————————————————————————
In the past I explained in multiple posts how to restore the SYSVOL on a DC when it is replicated through either NTFRS or DFS-R. Those procedures (including screen dumps) can be found through the following links:
In this post I will explain another method that is also available to restore the SYSVOL in an authoritative and non-authoritative way when it is replicated through DFS-R. The information posted here will be based upon the following Microsoft KB article:
In addition to what the KB article already mentions, this post will contain additional information such as PowerShell command lines used and screen dumps.
–
SYSVOL Replicated Through DFS-R – Authoritative Restore – Steps To Take
To perform an authoritative restore of the SYSVOL when using DFS-R, use the following steps (preferably on the RWDC with the PDC FSMO role!):
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="FALSE";"msDFSR-Options"=1} (this disables the replicated folder on this target and marks the target as primary, or in other words authoritative)
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a DOS command prompt
DFSRDIAG POLLAD
Event ID 4114 in the DFS Replication Event Log appears (after the first occurrence, this event will be repeated every 5 minutes):
Event ID 4008 in the DFS Replication Event Log appears:
Event ID 2010 in the DFS Replication Event Log appears:
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="TRUE"} (this re-enables the replicated folder on this target)
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a DOS command prompt
DFSRDIAG POLLAD
Event ID 4602 in the DFS Replication Event Log appears:
–
SYSVOL Replicated Through DFS-R – Non-Authoritative Restore On RWDC – Steps To Take
To perform an authoritative restore of the SYSVOL when using DFS-R on a RWDC, use the following steps:
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="FALSE"} (this disables the replicated folder on this target)
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a DOS command prompt
DFSRDIAG POLLAD
Event ID 4114 in the DFS Replication Event Log appears (after the first occurrence, this event will be repeated every 5 minutes):
Event ID 4008 in the DFS Replication Event Log appears:
Event ID 2010 in the DFS Replication Event Log appears:
As an optional steps, you can specify a specific replication (sourcing) partner for the SYSVOL
REMARK: If you do not use this method to specify the source computer, any Active Directory replication partner that has the SYSVOL replicated folder in the NORMAL state could end up being used as the source.
–
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="TRUE"} (this re-enables the replicated folder on this target)
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a DOS command prompt
DFSRDIAG POLLAD
Event ID 4614 in the DFS Replication Event Log appears:
Event ID 4604 in the DFS Replication Event Log appears:
–
SYSVOL Replicated Through DFS-R – Non-Authoritative Restore On RODC – Steps To Take
To perform an authoritative restore of the SYSVOL when using DFS-R on a RODC, use the following steps:
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="FALSE"} (this disables the replicated folder on this target) (execute this either on the RODC with sufficient permissions AND make sure you can access the Active Directory Web Service (ADWS) (tcp:9389) on the RWDC (through referral by RODC) from the RODC, OR execute this on the RWDC with sufficient access permissions)
You then either wait until the change that originated on an RWDC reaches the RODC, or you force inbound AD replication on the RODC. Within a DOS command prompt
REPADMIN /SYNCALL R2FSRODC5.ADDMZ.LAN /A /d /q
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a DOS command prompt
DFSRDIAG POLLAD
Event ID 4114 in the DFS Replication Event Log appears (after the first occurrence, this event will be repeated every 5 minutes):
Event ID 4008 in the DFS Replication Event Log appears:
Event ID 2010 in the DFS Replication Event Log appears:
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="TRUE"} (this re-enables the replicated folder on this target) (execute this either on the RODC with sufficient permissions AND make sure you can access the Active Directory Web Service (ADWS) (tcp:9389) on the RWDC (through referral by RODC) from the RODC, OR execute this on the RWDC with sufficient access permissions)
You then either wait until the change that originated on an RWDC reaches the RODC, or you force inbound AD replication on the RODC. Within a DOS command prompt
REPADMIN /SYNCALL R2FSRODC5.ADDMZ.LAN /A /d /q
Within a PowerShell command prompt
Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
Within a DOS command prompt
DFSRDIAG POLLAD
Event ID 4614 in the DFS Replication Event Log appears:
Event ID 4604 in the DFS Replication Event Log appears:
–
Cheers, Jorge ——————————————————————————————— * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ——————————————————————————————— ############### Jorge’s Quest For Knowledge ############# ######### http://JorgeQuestForKnowledge.wordpress.com/ ######## ———————————————————————————————
[1] When a backup application performs a system state restore, it must indicate that it has done so by setting the LastRestoreId registry value. The LastRestoreId is a GUID that is formatted as 00000000-0000-0000-0000-000000000000. The GUID has to be different each time a restore is requested. For example, if you have the LastRestoreId set as 10000000-0000-0000-0000-000000000000, for the next restore you have to set it to a different GUID, such as 20000000-0000-0000-0000-000000000000. For more information about setting LastRestoreId, see Registry Keys and Values for Backup and Restore.
As soon as the DFS-R Service starts, the following events appear with information about the non-authoritative restore.
Event ID 2109
Event ID 2110
Event ID 4106
Event ID 4108
SYSVOL Replicated Through DFS-R – Non-Authoritative Restore – Steps To Take
To perform a non-authoritative restore of the SYSVOL when using DFS-R, use the following steps:
Start the Registry Editor
Navigate to "HKLM\SYSTEM\CurrentControlSet\Services\DFSR"
Create a key called "Restore" (only time only)
Create a string value called "SYSVOL" (only time only)
For the string value called "SYSVOL" assign the value of non-authoritative
Navigate to "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore"
Create a key called "SystemStateRestore" (only time only)
Create a string value called "LastRestoreId" (only time only)
For the string value called "LastRestoreId" [1] assign the value of 10000000-0000-0000-0000-000000000000
Stop the DFSR Service
Start the DFSR Service
From the command-line the same can be achieved through:
[1] When a backup application performs a system state restore, it must indicate that it has done so by setting the LastRestoreId registry value. The LastRestoreId is a GUID that is formatted as 00000000-0000-0000-0000-000000000000. The GUID has to be different each time a restore is requested. For example, if you have the LastRestoreId set as 10000000-0000-0000-0000-000000000000, for the next restore you have to set it to a different GUID, such as 20000000-0000-0000-0000-000000000000. For more information about setting LastRestoreId, see Registry Keys and Values for Backup and Restore.
As soon as the DFS-R Service starts, the following events appear with information about the non-authoritative restore.
Event ID 2109
Event ID 2110
Event ID 4110
Event ID 4102
Event ID 4604
–
Cheers, Jorge ——————————————————————————————— * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ——————————————————————————————— ############### Jorge’s Quest For Knowledge ############# ######### http://JorgeQuestForKnowledge.wordpress.com/ ######## ———————————————————————————————
As soon as the NTFRS Service starts, the following events appear with information about the non-authoritative restore.
Event ID 13565
Event ID 13520
Event ID 13553
Event ID 13554
Event ID 13516
–
Cheers, Jorge ——————————————————————————————— * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ——————————————————————————————— ############### Jorge’s Quest For Knowledge ############# ######### http://JorgeQuestForKnowledge.wordpress.com/ ######## ———————————————————————————————
The SYSVOL contains logon scripts and GPOs for a particular AD domain. It replicates to all RWDCs and RODCs. When, during the promotion of the very first (W2K8/W2K8R2) RWDC, the DFL is configured with "Windows Server 2003" or lower, then the SYSVOL will use NTFRS as its replication mechanism. At a later stage when you increase the DFL to at least "Windows Server 2008", you can migrate the replication of the SYSVOL from NTFRS to DFS-R. The process for doing that is explained in the SYSVOL Replication Migration Guide: FRS to DFS Replication (Web Based) or SYSVOL Replication Migration Guide: FRS to DFS Replication (Word Doc).
However, when, during the promotion of the very first (W2K8/W2K8R2) RWDC, the DFL is configured with at least "Windows Server 2008", then the SYSVOL will use DFS-R as its replication mechanism right away and no migration is needed to migration the replication of the SYSVOL from NTFRS to DFS-R.
The use of DFS-R, compared to NTFRS, is way better in terms of performance and stability. DFS-R also works better with RODCs than NTFRS. When the SYSVOL on an RODC is adjusted locally, the changes will remain and will not replicate out because the RODC does not support Outbound Replication to any DC. Over time, if you do this too often you will get inconsistencies. To resolve these consistencies you may need to do a non-authoritative restore of the SYSVOL when replicated by NTFRS. If the same occured on the RODC and DFS-R is being used as the replication mechanism for the SYSVOL, then the local change would be detected and reverted as if nothing had happen. This makes sure the SYSVOL contents remains consistent on RODCs. For other differences see The Case for Migrating SYSVOL to DFSR.
The availability of the SYSVOL is very important for users, because if it is not available on a certain DC (RWDC or RODC), both users and computers cannot log on using that DC.
For both replication mechanisms I will explain how to do an authoritative restore or a non-authoritative restore of the SYSVOL using either replication mechanism.
Authoritative Restore
With an authoritative restore, the data that’s being restored is leading compared to all other versions of that same data on onther DCs. Taking that into account, when doing an authoritative restore on a RWDC, one should not forget that all other RWDCs and RODCs must do a non-authoritative restore.
Non-Authoritative Restore
With a non-authoritative restore, the data that’s being restored or that is in place is not leading compared to all other versions of that same data on onther DCs. To get the most recent data, the DC for which a non-authoritative restore was done must get the most recent data from another DC.
For the post on restoring the SYSVOL when replicated through the NTFRS mechanism see here.
For the post on restoring the SYSVOL when replicated through the DFS-R mechanism see here.
–
Cheers, Jorge ——————————————————————————————— * This posting is provided "AS IS" with no warranties and confers no rights! * Always evaluate/test yourself before using/implementing this! * DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/ ——————————————————————————————— ############### Jorge’s Quest For Knowledge ############# ######### http://JorgeQuestForKnowledge.wordpress.com/ ######## ———————————————————————————————
Jorge's Quest For Knowledge! 