December 5, 2014 at 11:58DFS Replication and Temporary Files
Hello!
This is my first publication, I hope that in the future I will write often.
If something is incorrectly designed, correct, I will fix it as it should.
I had to deal with an interesting feature of DFS Replication . And although the issue itself is not new, many can fill it with cones.
So, we have a stable working environment in which DFS replication is successfully configured and working. A replication group has been created, all the necessary servers have been added to it, the topology is correct, the schedule is fine, everything is fine ... until one day the new files added to the replicated folder stop being copied to the remote servers.
For example, I made a test environment in which there are only two servers - LAB-DC1 and LAB-FS1. On each of them there is a folder C: \ DFSR , between which replication should take place.
We copy two test files to this folder on LAB-DC1 and see that only one was replicated to the second server.
Why?
Because the DFS Replication mechanism is designed so that by design does not copy files that have the Temporary attribute set . We will use the fsutil command and see what attributes both of our files have.
The not-a-temporary-file.txt file has attributes 0x20 :
The temporary-file.txt file has attributes 0x120 :
Decoding these hexadecimal numbers is very simple. Each possible file attribute has its own hexadecimal value. Here are all the options:
From this list you can see that not-a-temporary-file.txt has only the “Archive” attribute , and temporary-file.txt has the “Archive” and “Temporary” attributes .
And all files for which “Temporary” is set will not be replicated using the DFS Replication mechanism .
It is very simple to remove this attribute from all attached files and folders using a small PowerShell script:
Remove the attribute and voila! Our “problematic” temporary-file.txt file was successfully copied to the remote server:
Where the “temporary” files come from in the network, the story is silent. I came from somewhere. In order to experiment, you can set the “Temporary” attribute for the file with your hands. To do this, you can also use a simple PowerShell script:
That's all, I hope that this article will help someone else in solving problems associated with the work of DFS Replication .
In the end, I would like to thank Craig Landis, who published a comprehensive article on this topic in his blog back in 2008 .
This is my first publication, I hope that in the future I will write often.
If something is incorrectly designed, correct, I will fix it as it should.
I had to deal with an interesting feature of DFS Replication . And although the issue itself is not new, many can fill it with cones.
So, we have a stable working environment in which DFS replication is successfully configured and working. A replication group has been created, all the necessary servers have been added to it, the topology is correct, the schedule is fine, everything is fine ... until one day the new files added to the replicated folder stop being copied to the remote servers.
For example, I made a test environment in which there are only two servers - LAB-DC1 and LAB-FS1. On each of them there is a folder C: \ DFSR , between which replication should take place.
We copy two test files to this folder on LAB-DC1 and see that only one was replicated to the second server.
Why?
Because the DFS Replication mechanism is designed so that by design does not copy files that have the Temporary attribute set . We will use the fsutil command and see what attributes both of our files have.
The not-a-temporary-file.txt file has attributes 0x20 :
The temporary-file.txt file has attributes 0x120 :
Decoding these hexadecimal numbers is very simple. Each possible file attribute has its own hexadecimal value. Here are all the options:
| READONLY | 0x1 |
| HIDDEN | 0x2 |
| SYSTEM | 0x4 |
| Directory | 0x10 |
| Archive | 0x20 |
| Device | 0x40 |
| Normal | 0x80 |
| TEMPORARY | 0x100 |
| SPARSE_FILE | 0x200 |
| REPARSE_POINT | 0x400 |
| COMPRESSED | 0x800 |
| OFFLINE | 0x1000 |
| NOT_CONTENT_INDEXED | 0x2000 |
| ENCRYPTED | 0x4000 |
From this list you can see that not-a-temporary-file.txt has only the “Archive” attribute , and temporary-file.txt has the “Archive” and “Temporary” attributes .
And all files for which “Temporary” is set will not be replicated using the DFS Replication mechanism .
It is very simple to remove this attribute from all attached files and folders using a small PowerShell script:
Get-ChildItem C:\DFSR -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}Remove the attribute and voila! Our “problematic” temporary-file.txt file was successfully copied to the remote server:
Where the “temporary” files come from in the network, the story is silent. I came from somewhere. In order to experiment, you can set the “Temporary” attribute for the file with your hands. To do this, you can also use a simple PowerShell script:
$file = Get-Item C:\DFSR\temporary-file.txt
$file.Attributes = 0x120That's all, I hope that this article will help someone else in solving problems associated with the work of DFS Replication .
In the end, I would like to thank Craig Landis, who published a comprehensive article on this topic in his blog back in 2008 .