Tag Archive: sysvol


http://support.microsoft.com/kb/2958414

Symptoms

On the clients we were seeing the following errors when executing the gpupdate command:

gpupdate - processing of group policy failed - registry-based policy settings

Event Viewer Logs

Log Name: System
Source: Microsoft-Windows-GroupPolicy
Date: 7/25/2014 10:46:45 AM
Event ID: 1096
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: mymachine.mydomain.local
Description:
The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LDAP://CN=Machine,cn={CF25ED30-3895-4147-8EB7-38789553F6A0},cn=policies,cn=system,DC=mydomain,DC=local. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.

On the DCs we were seeing the following events inside of Event Viewer -> Applications and Service Logs -> DFS Replication

Log Name: DFS Replication
Source: DFSR
Date: 7/25/2014 1:04:30 PM
Event ID: 4612
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DC02.mydomain.local
Description:
The DFS Replication service initialized SYSVOL at local path C:\Windows\SYSVOL\domain and is waiting to perform initial replication. The replicated folder will remain in the initial synchronization state until it has replicated with its partner DC01.mydomain.local. If the server was in the process of being promoted to a domain controller, the domain controller will not advertise and function as a domain controller until this issue is resolved. This can occur if the specified partner is also in the initial synchronization state, or if sharing violations are encountered on this server or the sync partner. If this event occurred during the migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes will not replicate out until this issue is resolved. This can cause the SYSVOL folder on this server to become out of sync with other domain controllers.

Additional Information:
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 2276C68D-BC24-46BF-B492-067919163EDA
Replication Group Name: Domain System Volume
Replication Group ID: D50C64AE-0A01-4F97-B838-069F0BCBE369
Member ID: 7ADF2D7C-7947-412C-A619-C0C0D72F6A9C
Read-Only: 0


Log Name: DFS Replication
Source: DFSR
Date: 7/25/2014 1:04:30 PM
Event ID: 5002
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DC02.mydomain.local
Description:
The DFS Replication service encountered an error communicating with partner DC01 for replication group Domain System Volume.

Partner DNS address: DC01.mydomain.local

Optional data if available:
Partner WINS Address: DC01
Partner IP Address: 192.168.1.5

The service will retry the connection periodically.

Additional Information:
Error: 1753 (There are no more endpoints available from the endpoint mapper.)
Connection ID: D50C64AE-0A01-4F97-B838-069F0BCBE369
Replication Group ID: 4DCE6A8E-6271-48B6-A0D0-5447718B8FAB

Solution

We ended up having to manually preform an authoritive synchronization between the two DCs.  As you may know, DFSR no longer uses the same steps as FSR to do an authoritive sync.  Below are my notes and expereinces on completing an authoritive DFSR sync.  You can find the ofificial notes from Microsoft here: http://support.microsoft.com/kb/2218556/en-us

  1. Logon to your primary DC
  2. Stop the DFS Replication service
    1. Click on the Start menu, select Administrative Tools, and then click ServicesServices
    2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop
  3. Open up ADSI Edit
    Server Manager - ADSI Edit
  4. Open up the Default naming context
    ADSI Edit - Connection Settings - Default naming context
  5. Navigate to the following
    1. CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name to replicate from>,OU=Domain Controllers,DC=<domain>
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume
  6. Change the following attributes to the following values
    1. msDFSR-Enabled=FALSE
      msDFSR-options=1
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - False
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Options - 1
      Both values applied
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Options - msDFSR-Enabled

      1. Note: If you cannot see msDFSR-options, uncheck Show only attributes that have values
        ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - Show only attributes that have values
  7. On the ALL other DCs, change the msDFSR-Enabled attribute to False
    ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - False
  8. Force Active Directory replication throughout the domain (ensure all sync resposnes terminate with no errors).
    1. repadmin /syncall primary_dc_name /APed
      repadmin -syncall -aped

      1. NOTE: Here is a list of what the switches mean
        1. /A: Perform /SyncAll for all NC’s held by <Dest DSA> (ignores <Naming Context>)
        2. /P: Push changes outward from home server (default: pull changes)
        3. /e: Enterprise, cross sites (default: only home site)
        4. /d: ID servers by DN in messages (instead of GUID DNS)
  9. Start the DFSR service back up on the authoritive DC
    1. Click on the Start menu, select Administrative Tools, and then click Services
      Services
    2. In the Name column, right-click DFS Replication or Netlogon, and then click Start
  10. Open up event viewer and navigate to Applications and Services Logs -> DFS Replication.  Verify you see Event ID 4114.
    Event Viewer - Applications and Services Logs - DFS Replication - Event 4114
  11. Navigate back to the following in ADSI
      1. CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name to replicate from>,OU=Domain Controllers,DC=<domain>
        ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume
  12. Set the value of msDFSR-Enabled to TRUE
    ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - True
  13. Execute the following via an elevated command prompt
    1. DFSRDIAG POLLAD
      1. NOTE: This is a utility apart of DFS Managment Tools.  I completed the guide successfully without running this command, but Microsoft recommends you do run this command.
  14. Force Active Directory replication throughout the domain
    1. repadmin /syncall primary_dc_name /APed
      repadmin -syncall -aped
  15. Wait a few minutes and you should see Event ID 2002 and 4602
    Event Viewer - Applications and Services Logs - DFS Replication - Event 4602 - Event 2002
  16. Navigate back to each of your secondary DCs and change the value of msDFSR-Enabled to TRUE
    ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - True
  17. Execute the following via an elevated command prompt
    1. DFSRDIAG POLLAD
      1. NOTE: This is a utility apart of DFS Managment Tools. I completed the guide successfully without running this command, but Microsoft recommends you do run this command. Force Active Directory replication throughout the domain
  18. Verify you see Event ID 2002 and 4602 on each of the secondary DCs
    Event Viewer - Applications and Services Logs - DFS Replication - Event 4602 - Event 2002

At this point, try running a gpupdate on your client.  If all has gone well, each of your shared SYSVOL folders on your DCs should contain the same amount of policies and your client should successfully pull down all policies.

gpupdate - success

Symptom:

You configure a logon script with a Group Policy object. In a multiple domain controller environment, this change requires that Active Directory and the Sysvol replicate this change to all the domain controllers. Before both Active Directory and Sysvol are fully replicated, a user logs on to the system and is authenticated by a domain controller that is not fully replicated, and the user experiences unexpected behavior.

Possible Causes:

  • In a multiple domain controller environment, changes to Active Directory have not yet completed replication.
  • In a multiple domain controller environment, changes to the Sysvol have not yet completed replication.

Diagnostic Tests:

Open EventVwr and check traces of FRS or DFS-R errors (use also dcdiag utility)

Run Netdiag.exe to check client network configuration and that DNS is configured and working correctly.

If the user has a roaming user profile, verify that he or she correctly receives the roaming user profile at logon.

Run Gpresult.exe to see if any Group Policy Settings are applied. If no Group Policy settings are applied, see “No Group Policy Objects Are Applied” later in this chapter.

To check the status of Active Directory and Sysvol replication on each server:

  1. Run Gpotool.exe to check the number of unique Group Policy objects available on the network, and the status of each of these Group Policy objects on each domain controller. The status output from Gpotool.exe indicates all necessary information to diagnose if Active Directory and Sysvol are synchronized for each domain controller that you can connect to.
  2. If you find that Sysvol is not synchronized between two domain controllers, place any text file on the Sysvol of one of the domain controllers. Confirm that it is replicated to the other domain controllers. If this fails, check the network connectivity between the domain controllers.
  3. If Active Directory is not synchronized between domain controllers, run Active Directory Replication Monitor (Replmon.exe), which can provide additional information about the state of Active Directory synchronization, and provide assistance in resolving the problem.
  4. Also if you are considering SCOM, install the DFS Management pack to monitor DFS replication status.
  5. if you are using Win 2008 R2 based DFS-R, then considering DFSRDIAG.exe utility to monitor replication status: http://blogs.technet.com/b/filecab/archive/2009/05/28/dfsrdiag-exe-replicationstate-what-s-dfsr-up-to.aspx
  6. Also you can use: dcdiag /test:frsevent (w2k3 DCs) and dcdiag /test:dfsrevent (W2k8R2 or greater errors) to test if there are any operation errors
  7. On W2k3 based DC: Check if there is a fixed FRS port on the registry (HKLM\system\currentcontrolset\services\NTFRS\parameters) on all DCs and are identicals.
  8. On W2k8R2 or greater based DC: Check if there is a fixed DFSR port (DFSRDiag dumpmachinecfg to identity the static port) on all DCs and are identicals.
  9. DFSRDiag les commandes les plus utiles: http://www.monbloginfo.com/2011/03/02/dfsr-les-commandes-les-plus-utiles/

DFS Replication dirty shutdown recovery process. Related system event log entries, e.g. Event ID 2212, refer to the same event as “unexpected shutdown”.

Sometimes, it is possible that the database and the file system get out of sync. Abrupt power loss on the server or if the DFSR service was stopped abnormally for any reason. Another example is if the volume hosting a replicated folder loses its power, gets disconnected or is forced to dismount. These exception conditions result in unexpected shutdown of DFSR database, as any of these can cause inconsistencies between the database and the file system. DFSR is designed to automatically recover from these situations starting with Windows Server 2008, and this behavior continued through Windows Server 2008 R2.

Technet blog: http://blogs.technet.com/b/filecab/archive/2012/07/23/understanding-dfsr-dirty-unexpected-shutdown-recovery.aspx

Article: http://support.microsoft.com/kb/2846759