How to Repair Server 2012 DFS Replication after Dirty Shutdown

and Journal Wrap

by Miguel Fra at 4:31 PM in Windows Server
When a server 2012 stops replicating with another member, changes are entered into a journal database.
If the replication process does not begin in a timely manner, the journal database runs out of space and
begins to overwrite itself. In DFS parlance this is known as a journal wrap. Once the journal is wrapped, it’s
rendered ineffective.

In this blog, I will demonstrate how to begin a new replication process. This of course, is a last resort, since
data will have to be replicated across all member servers. However, if you find yourself in a situation that
merits such action, the steps are outlined below.

In this scenario, we make the following design assumptions:

 We have two servers replicating across WAN connection, a source server and a target server.
 Both have Windows Server 2012 operating systems.
 The two servers stopped replicating long enough to cause a journal wrap.

After a dirty shutdown (loss of power), the DFS Replication will not commence automatically. It’s needs to
be started manually instead. You will know that you are in a dirty shutdown state because you will see the
following error in the DFS replication log of the server that is hosting the DFS:

Event 2213 The DFS Replication service stopped replication on volume... This occurs when a DFSR JET
database is not shut down cleanly and Auto Recovery is disabled.

When you encounter a dirty shutdown error, it’s best to resume the replication process and wait to see if
the replication begins again. If the journal is not in a wrapped state, the replication should begin to work.
Please note that you should have a backup of all data located in both the source and target server before
beginning the recovery processes that is outlined below.

How to Resume from a DFSR Dirty Shutdown State

To resolve the dirty shutdown state, scroll down to the bottom of the Event 2213 error message. Copy the
entire WMIC command in step 2, including the GUID to the clipboard. To do this, highlight the entire text
and press CRTL+C.
Next, run Windows PowerShell as an administrator. In PowerShell type the command CMD and press
enter (this is due to the fact that WMIC will not run from PowerShell natively, it requires the command
prompt)

Next, right click on the PowerShell screen and paste the clipboard contents. Once the WMIC command
has been pasted, press enter to execute the command.

Once the command is executed successfully, it should return a value of 0.

Monitor your replication folders until you feel that they are all replicating once again. There may be a
replication backlog so be patient, replication may take longer than usual. If after waiting sufficient time,
some or all of the replication folders are failing to replicate, the folder’s corresponding journal database
may be in a wrapped state.

Recovering DFS-R Replication from a Wrapped Journal State

The database that keeps track of DFS-R changes is located in the corresponding replicated folder in a
hidden file. We will need to delete this folder from both the source and target servers. This is an easy
recovery method however, it should be noted that if user’s have made changes in both the target server’s
data, it will be lost and replaced by the data that is located on the source server. For this reason, you
should keep a copy of the replication data from all replicating members.

To begin, open the DFS management console and locate the replication group that is not working. Right
click on it and select delete. Don’t worry, the contents will not be deleted.
After you have deleted replication group, open the folder on the authorative (source) server (the
authorative server is the one that contains the most update versions of all replicated files), . Select View->
Options-> View Tab and Show hidden files to display the Dfsrprivate subfolder folder. This is the folder
that contains the journal database.
In order to delete this folder, we must first stop the DFS-Replication service. Open the services
management console (services.msc) and stop the DFS Replication service.

Once it’s stopped, delete the DfsrPrivate sub folder. DO NOT delete the data files, we need those to seed
the replication process.

Now, for each replicating member (non-authorative server), stop the DFS-Replication service, locate the
replicating target folder and rename it to .old. This way you have a copy of the data in case some files
were updated on multiple servers during the time that the servers were not replicating and you need to
go back to find it.

Create a new folder and share it, this will be the new target folder. Do this for each replicating member
server.
When finished, re-start the DFS-Replication service on all of the servers.

Go back to the DFS Manager, right click on the DFS Namespace and select new folder. Name the folder
and click on the add button to find the target location. Point the target to the corresponding folder on
the authorative server. Expand the folder and make sure that you do not see the DfsrPrivae subfolder. if
you properly deleted it as outlined prior, it should not be shown.

Click OK to add the target folder. next, right click on the newly created folder under the DFS namespace
and select add folder target. Navigate to the replicating member server and look for the target folder. This
folder should be empty.
After you click OK, you should be prompted by the replication group creation dialog box. Proceed to
create a replication group with your desired settings.

When finished, open the target locations side by side using a UNC path and monitor the progress.
After a few minutes, you should see a new DfsrPrivate folder appear on the authorative server’s target
folder, indicating the creation of a new journal database. Shortly after that, your files will begin to
replicate to their target locations.

LikeComment
