Ondrej Žilinec – IT Blog

I implemented DFSR replication in our customer between two locations. There are people opening same files on both locations and they want to use Office document locking feature. This locking mechanism is based on creation of temporary files (~*). So I removed file exception (~*) from DFSR Replicaiton Group and allowed to replicate temporary Office files. When I create and open Word document on one location two files are were: WORD.docx and ~$WORD.docx. And when I created new Excel document two files were created: EXCEL.xlsx and ~$EXCEL.xlsx.

On other location only two files were replicated (created): WORD.xlsx and ~$WORD.xlsx:

When I closed Word and Excel temporary files dissapeared and docx and xlsx files replicated correctly.

So let’s look why those files were not replicated. In some Technet articles I found that DFSR doesn’t replicate temporary files. More info is here and here.

It’s nice to know that DFSR doesn’t replicate files marked as temporary. So let’s look at those opened Word and Excel files.

WORD.docx

– Only archive attribute set (0x20)

~$WORD.docx:

– Archive attribute (0x20) and Hidden (0x02)

EXCEL.xlsx

– Only archive attribute set (0x20)

~$EXCEL.xlsx

So utility fsutil cannot open data from this file. It looks that Excel opens its files different way as Word does. And that’s why file ~$EXCEL.xlsx didn’t copy to other location, because DFSR cannot access this file while it’s opened in Excel.

This Excel behaviour causes that Office locking mechanism is not working over DFSR.

Let’s hope Microsoft will fix this in other release Office 🙂

Have a nice day,

Problem

I had one problem with DFSR. I had two servers. Server01 in located in Location01 and Server02 located in Location02. There is DFSR Replication Group configured between those two servers. Replication worked in one direction – from Server01 to Server02, but it didn’t work from Server02 to Server01.

Findings

When I looked into backlog of Server02 using command:

dfsrdiag backlog /rgname:Rep_Group /rfname:Rep_Folder /SendingMember:SERVER02 /Receivingmember:SERVER01

I found out that there is lots of files stuck in queue – backlog. All of them were called Thumbs.db. These files are used by Windows Explorer to store thumbnails of files in directories.

Solution

I fixed issue by clearing conflict directory using following commands. I had to find out GUID for my replication folder:

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderconfig get replicatedfolderguid,replicatedfoldername

And then run procedure to clear conflict directory:

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where “replicatedfolderguid=’GUID’” call cleanupconflictdirectory

After directory clearance replication stared to work.

But I wanted to prohibit to create Thumbs.db files on network shares. I don’t know about any setting that would disable it on client machines so I had to restrict creation on servers. I decided to create File Screen to prohibit Thumbs.db creation on servers.

1. On server go to Server Manager — Roles — File Services — Share and Storage Management — File Server Resource Manager — File Screening Management:

2. Right-click on File Groups and create new File Group:

– Name it

– Include file “Thumbs.db” into list

3. Right-click on File Screen Templates and create new screen template:

– Name it

– Make sure you have selected Active screening

– Select new created group “Thumbs.db”

4. Enable file screening on directory. Right-click on File Screens and create file screen.

– Select Path where File Screen should apply

– Select new created File Screen Template

And screen file is sucessfully set.

One more step I took was delete all Thumbs.db files from server’s disk. I run following powershell command in share directory:

Get-ChildItem -Force -Recurse | where { $_.Name -like “Thumbs.db”  } | Remove-Item -Force

And that’s all for today play with DFSR.

Today I was solving issue with not replicating DFSR server in Full Mesh topology. Here are couple helpful commands to work with DFSR:

To look if any replication is in progress:

dfsrdiag replicationstate

To look if there is anything in backlog:

dfsrdiag backlog /rgname:Rep_Group /rfname:Rep_Folder /SendingMember:SERVER01 /Receivingmember:SERVER02

To disable debug logging:

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

To set maximum debug files:

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

To set maximum lines in one log file:

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

To look for replication folder GUID:

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderconfig get replicatedfolderguid,replicatedfoldername

To clean up conflict directory:

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where “replicatedfolderguid=’GUID'” call cleanupconflictdirectory

That’s all folks for today,

Most of you probably already updated Active Directory infrastructure from Windows 2003 to Windows 2008 R2. What I see most is that administrators do not upgrade DFS replication subsystem for SYSVOL shares. Before Windows Server 2008 (also R2) was released FRS (File Replication System) is used. In Windows 2008 R2 there is new version released and it’s called DFSR (Distributed File System Replication).

FSR

FSR uses NTFS volumes’ USN journal to determine when a change has occured to a file and triggers replication. When FSR detects file close it gathers information about file and it’s attributes. It also checks file’s MD5 hash. If MD5 hash changes it will trigger replication. If file has changed whole file is send to FSR replication partners.

DFSR

First benefit of DFSR is that it doesn’t replicate whole file, but just a changed data in the file. To be able to check only changes in files it uses RDC (Remote Differential Compression) compression algorithm.

Read more…