Below are a few new important features in DFSR:

• DFSR can be used to replicate folders without it being a part of DFS or shared.

• When a file is changed, only the changed blocks are replicated, not the entire file. The RDC protocol determines the changed file blocks that needs to be replicated.

• DFS Replication uses a conflict resolution heuristic of last writer wins for files that are in conflict (that is, a file that is updated at multiple servers simultaneously) and earliest creator wins for name conflicts. Files and folders that lose the conflict resolution are moved to a folder known as the Conflict and Deleted folder. You can also configure the service to move deleted files to the Conflict and Deleted folder for retrieval should the file or folder be deleted.

• DFS Replication is self-healing and can automatically recover from USN journal wraps, USN journal loss, or loss of the DFS Replication database.

• You can configure DFS Replication to use a limited amount of bandwidth on a per-connection basis (bandwidth throttling).

• Better management and diagnostic tools (‘DFS management’, DFSR diagnostic health report and propagation test/reports, DFSRdiag etc.)

Addition with Windows 2008 R2:

• Support for Windows Failover Clusters

• Read-only Replicated Folders (now with true filter driver support)

• SYSVOL on Read-only Domain Controllers (leveraging the improved Read-only functionality)

For more information about DFS Replication, please refer to the articles below:

DFS Replication: Frequently Asked Questions (FAQ)

https://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx

DFSR Does Not Replicate Temporary Files

https://blogs.technet.com/b/askds/archive/2008/11/11/dfsr-does-not-replicate-temporary-files.aspx

Five Common Causes of “Waiting for the DFS Replication service to retrieve replication settings from Active Directory”

https://blogs.technet.com/b/askds/archive/2008/07/15/five-common-causes-of-waiting-for-the-dfs-replication-service-to-retrieve-replication-settings-from-active-directory.aspx

Get out and push! Getting the most out of DFSR pre-staging

https://blogs.technet.com/b/askds/archive/2008/02/12/get-out-and-push-getting-the-most-out-of-dfsr-pre-staging.aspx

Top 10 Common Causes of Slow Replication with DFSR

https://blogs.technet.com/b/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspx

DFSR replication dependencies:

• Connectivity with DC to get DFSR configuration (DSFR PollAD)

• AD Replication – with replication issues, the DFSR RG members might get different view of the DFSR RG configuration.

• RPC port connectivity between the DFSR members – RPC ports, the DFSR services are listening on should be allowed on the firewall.

• Enough free space on the drive hosting the replica to add more data and do staging.

• Access to the data (System account should not be denied access) – the DFSR service should be able to read/write and lock the files its replicating.

If there is any issue with any of the above dependencies, DFSR replication may stop or become slower.

A few times I’ve also observed that improper management of DFSR RG / RF can also lead to replication issues. Like…

• In Windows 2003 R2 and Windows 2008, it’s not recommended to disable or delete DFSR connection objects to force just one-way replication. The support for one way replication has been included from Windows 2008 r2. If you need to stop replication for some time either change the schedule on the connection objects or disable it for a sometime. Keeping the connection objects disabled or deleting one-way connection objects may see unexpected data deletion issues when the connection objects get re-created or may cause issues with DFSR database.

• Disabling and enabling of RG membership should not be done to stop replication for some time. This is because when a disabled membership is enabled again, the enabled member will perform an initial sync again.

• After changing DFSR configuration, it always recommended to wait for the AD replication to complete so that all DFSR members get the information about the change. If all DFSR members are not updated with the configuration stored in AD, then it may cause issues like a downstream server still replicating changes even if the connection objects is disabled using DFS management on the upstream server.

If you are suspecting or know that the DFSR replication between members is failing I suggest you collect the following logs. These logs will help you as well as the ‘Support Engineer’ you will work with if you create a ticket with Microsoft support.

From the servers involved in DFSR replication, collecting the following information would help:

1. DFSR diagnostic health report

2. DFSR propagation test and report

After a few minutes of running the DFSR Propagation test, you can run the Propagation report to get the status of the replication.

3. DFSR event logs in CSV format

4. Collect DFSR debug logs from the members from under c:\windows\debug folder

5. Run MSinfo32 and once loaded save it into a .nfo file.

Apart from the above logs a “Support Engineer” in Microsoft support may ask you to increase the DFSR debug log severity before collecting the debug logs. A SE may also send you a tool named DFSRInfo (Microsoft CSS Internal tool) to collect more information from the DFSR member.

The following controls the log settings and describes the defaults:

SETTING: Debug Log Severity
Default: 4
Range: 1-5
WMIC syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogseverity=5

SETTING: Debug Log Messages
Default: 200000
Range: 1000 to 4294967295 (FFFFFFFF)
WMIC syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set maxdebuglogmessages=500000

SETTING: Debug Log Files
Default: 100
Range: 1 to 10000
WMIC syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set maxdebuglogfiles=200

SETTING: Debug Log File Path
Default: %windir%\debug
WMIC syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogfilepath="d:\dfsrlogs"

NOTE: The path must be created manually; if not, at service restart, the default value %windir%\debug will be used.

SETTING: Enable Debug Logging (NOTE: Debug logging is enabled by default)
Default: TRUE
Range: TRUE or FALSE
WMIC syntax:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set enabledebuglog=true

-          Abizer Hazrat

The Current Release for Network Monitor is 3.4 and can be downloaded here.

There are 3 versions available:
NM32_IA64_setup.exe 6.4 MB  ----  Itanium Version.
NM32_x64_setup.exe  4.4 MB  ----  64bit Version.
NM32_x86_setup.exe  4.3 MB  ----  32bit Version.
Download the Version Compatible with the Server

Where the Sniffer is placed or which Computer Network Monitor is captured from is extremely vital in achieving the right diagnosis. In most scenarios, Capturing Network Monitor just from the 2 or more communicating Machines should be sufficient.

However, there may be a scenario for example, where one may wish to observe traffic from a machine whilst it is Booting. Obviously it is not possible to execute Network Monitor on that machine. To get around, the switch port to which the computer is connected is mirrored to another port on the switch.
We can now connect a laptop to the mirrored port and configure Network Monitor to run in a mode called Promiscuous on the laptop so as to now see packets from the Problem computer.

There may also be an intermittent issue which manifests once in a week or month for which the frequency/time of the issue cannot be predicted. It would be Resource Exhausting to execute Network Monitor on a computer for days waiting for an issue. In such cases, a light weight command line version of Network Monitor called nmcap can be leveraged to capture logs in a Circular or Chained format.

Let’s now look at how to Use the GUI version of Network Monitor:

• Once installed, launch Network Monitor.
  The Launched GUI will have 3 screens: Recent Captures; Getting Started and Select Networks.

• Let’s focus on the Select Networks Section:
  Here we see a List of all the Network Cards from which traffic can be captured.
  Notice the Highlighted P-Mode Button. Enabling it will Start Promiscuous Mode Captures.
  Do Note that it is enabled per Network Interface and hence Care should be taken to enable it for the Correct Network Interface.
  
  
  
• Once the Network Card has been Selected, Click New Capture to Create a New Capture Session:
  

• When ready to Reproduce the issue, Start the capture by clicking the Start Button:
  

• Once the Issue has been reproduced, Stop the trace:
  

• That is basically it.
  A Quick look at the Save Dialog Box:
  Network Monitor files are saved in CAP format.
  Either the all the Captured Packets can be saved or certain frames depending on what it is one is looking at and what filters have been applied.
  We shall talk about Filters in another Post.
  

• Another Option worth mentioning is Capture Settings:
  

Before beginning a Capture, you may wish to set a Capture Filter in order to capture only certain kind of traffic based on protocols, IP Addresses etc. Below is a ScreenCap of the Capture Settings Window. Again we shall discuss filters in future posts.

Let’s now look at how to Use the NMCAP, the command line version of Network Monitor:

• First and foremost, launch a command prompt in Elevated Mode.
• Browse to C:\Program Files\Microsoft Network Monitor 3
• Executing the command nmcap will produce the below output:

C:\Program Files\Microsoft Network Monitor 3>nmcap
Network Monitor Command Line Capture (nmcap) 3.4.2350.0
NMCAP Version = 3.4.2350.0
Try using nmcap /Usage or nmcap /Examples for help.

*It will be useful to explore the output of nmcap /Usage and nmcap /Examples

For now let’s look at a few example commands to capture packets:

• nmcap /network * /capture /file c:\filename.cap:50M
  The above command will capture packets from all Network Cards. The File will be limited to a size of 50MB and captured in a circular format.

• nmcap /network “Local Area Connection” /capture /file c:\filename.cap:50M
  The above command will capture packets from the “Local Area Connection” network interface. The File will be limited to a size of 50MB and captured in a circular format.

• nmcap /network * /capture /file c:\filename.chn:50M
  The above command will capture packets from all Network Cards. CHN specifies that the captures will be written to a chained series of files each limited to a size of 50MB each.

• nmcap /network * /capture “ipv4.address==1.1.1.1” /file c:\filename.cap:50M
  In the above command a Capture filter has been specified. So only traffic that includes
  the IP 1.1.1.1 as the Source or Destination for communication will be captured.

Cheers
Ajay Rodrigues

Active directory is multi-master i.e. all DCs in a domain (except for the RODCs in Windows 2008) hold a writable copy of the Active Directory database and can accept creation and modification request for objects in AD.

Active directory database (AD objects like users, computers, containers etc.) are replicated between DCs in domain/forest, so that..

• All DCs have the same view of the database.
• All DCs can authenticate data, respond to ldap queries/searches/modification etc. therefore load balancing the request is some manner.
• The Active directory data is available even if 1 DC is offline because the Additional DC will service most of the request.

Active Directory data takes the form of objects that have properties, or attributes. The values of the attributes define the object, and a change to a value of an attribute must be transferred from the domain controller on which the addition or modification occurs, to every other domain controller that stores a replica of that object.

Smallest unit of replication = Objects attribute value or a single value in a multi-valued attribute (2003 forest level onwards)

The objects in active directory are grouped in separate directory partition for Replication purpose.

• Schema Partition: Only one schema partition exists per forest. The schema partition is stored on all domain controllers in a forest, hence replicated to all. The schema partition contains definitions of all objects and attributes that you can create in the directory, and the rules for creating and manipulating them.

• Configuration Partition: There is only one configuration partition per forest. Second on all domain controllers in a forest, the configuration partition contains information about the forest-wide active directory structure including what domains and sites exist, which domain controllers exist in each forest, and which services are available. Configuration information is replicated to all domain controllers in a forest.

• Domain Partition: Many domain partitions can exist per forest. Domain partitions are stored on each domain controller in a given domain. A domain partition contains information about users, groups, computers and organizational units. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the global catalog with only a subset of their attribute values.

• Application Partition: Application partitions store information about application in Active Directory. Each application determines how it stores, categorizes, and uses application specific information.

Examples of application partition

• ForestDNSZones is part of a forest. All domain controllers and DNS servers in a forest receive a replica of this partition. A forest-wide application partition stores the forest zone data.
• DomainDNSZones is unique for each domain. All domain controllers that are DNS servers in that domain receive a replica of this partition. The application partitions store the domain DNS zone in the DomainDNSZones<domain name>.

Information used by DCs to track AD changes to be replicated and resolve replication conflicts.

• USN
• Version
• Originating TimeStamp
• Originating DSA (invocation ID)

**The above info is maintained at attribute level.

For details on how AD replication works, refer to the article below:

How the Active Directory Replication Model Works

https://technet.microsoft.com/en-us/library/cc772726(WS.10).aspx

AD replication usually does not require a lot of maintenance, provided the following stuff is in place:

• DNS name resolution.
• Network connectivity between domains.
• Mutual authentication.
• Proper disaster recovery methods followed.

But with any of the above missing, the AD replication between DCs may fail. Below are a few symptoms that maybe caused due to AD replication issues:

• User unable to logon with newly changed password.
• User getting locked out after password changes.
• Unable to logon to Application server/fileserver because the secure channel of the file server broken with the DCs.
• Creation of objects and modification made to objects not in sync across the domain, affecting application like Exchange.
• Inconsistency in name resolution, if the DNS zones are AD integrated.
• Group policy related changes may not apply to a set of computers/users.
• DFSR/FRS configuration changes may not be effective on all members.

So in scenarios where you suspect or know that the AD replication is broken in your environment, I suggest you collect the following logs. These logs will not only give you more information about the issue but will also help a 'Support Engineer' in case you create a case for the same with Microsoft Support.

• From a PDC or a DC in hub site which has connectivity with most of the DCs in forest, collect the following information:
• Repadmin /showrepl * /csv > Replication_summary.csv
• Dnslint /ad /s localhost /v /r DNSlint-AD

**collect Replication_summary.csv (to be reviewed using Ms Excel) and DNSlint-AD.htm

Sample ‘Repadmin /showrepl * /csv’ output

Sample ‘dnslint /ad /s localhost /v /r’ output.

•  In case you know the problem DCs
• Dciag /v > dcname_dcdiag.txt
• ‘Directory Service’ event logs. I prefer if it’s saved in CSV format.

• For issues like Lingering objects, apart from the above logs you can also collect the following events from all DCs in domain, using tools like eventcombmt.exe
• Event IDs to search for 1988, 1388, 2042.

How to use the EventCombMT utility to search event logs for account lockouts

https://support.microsoft.com/kb/824209

Below are a few articles that may help you understand and troubleshoot AD replication issues.

Troubleshooting Active Directory Replication Problems

https://technet.microsoft.com/en-us/library/cc738415(WS.10).aspx

Troubleshooting “RPC server is unavailable” error, reported in failing AD replication scenario.

https://blogs.technet.com/b/abizerh/archive/2009/06/11/troubleshooting-rpc-server-is-unavailable-error-reported-in-failing-ad-replication-scenario.aspx

-          Abizer Hazrat