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.
- 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.
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:
- 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.
- 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.
- 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.
- Also if you are considering SCOM, install the DFS Management pack to monitor DFS replication status.
- 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
- 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
- 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.
- 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.
- 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.