Hi folks, Ned here again. We created DFSR Cloning in Windows Server 2012 R2 to make initial synchronization faster. Today I talk about file attributes, how they sneak inefficiency into your cloning process, and what can you do about them.
Let’s get to it.
Attributes are simply
on files and folders that describe special states, like hidden or read-only. They often don’t change the file in a meaningful way. DFSR handles attribute changes with a few methods.
If you change these attributes, DFSR does replicate the attributes to the other server:
If you change these attributes, DFSR does not trigger replication of the attributes to the other server (but if the file is altered in another way that does trigger replication, these attributes come along for the ride):
There is the FILE_ATTRIBUTE_TEMPORARY attribute (good call, Dragos!), which makes DFSR ignore the file .
This is normal, day-to-day replication – Bobby Joe in Accounting sets the quarterly report to hidden and read-only, then DFSR updates all the other replicated copies of that file with these attributes. This gets more interesting in DFSR Cloning. The cloning process bypasses the step of always exchanging file information between servers during initial sync, by simply providing the new server with a copy of the old server’s database. This means that when you perform Import-DfsrClone , we need to check the local copy of the preseeded data with whatever is in the imported database. If the file dates, file sizes, or file ACL differ, we know that someone messed with the file between the export and the import, at least on this destination server.
However, we also check the attributes – if they differ between the preseeded files and the database records, we consider the file mismatched. Any mismatched files replicate to the destination using the normal initial sync mechanism, after cloning completes. Unlike usual, this is a full file replication, not just the metadata.
In other words:
#2 is out of your control, and frankly, who cares? You created a replication topology, there’s no worry about it actually replicating. #1 is avoidable. What could be changing these files? Here are some possible culprits:
That’s all fine, but how to tell if you are getting attribute-based cloning inefficiency? After all, when you look at your event logs after cloning, you only see a count of mismatches. Those could be anything:
Four? That’s not so bad.
To the debug logs!
First, look for lines that start with “
[WARN] DBClone::IDTableImportUpdate Mismatch record was found
”. For instance, here is our file with that warning:
Look closely. The ACL hashes match, the write times match, and the files sizes match. But the attributes?
20150616 15:00:01.037 2980 DBCL 4054 [WARN] DBClone::IDTableImportUpdate Mismatch record was found. Local ACL hash:3D1F6474-928B8530-1E0A6559-5F02A2C7 LastWriteTime:20150605 16:52:48.545 FileSizeLow:402432 FileSizeHigh:0 Attributes:128 Clone ACL hash:3D1F6474-928B8530-1E0A6559-5F02A2C7 LastWriteTime:20150605 16:52:48.545 FileSizeLow:402432 FileSizeHigh:0 Attributes:32
Aha! To the Internet !
A 128 is FILE_ATTRIBUTE_NORMAL. Someone removed the archive bit. Ok, that’s not too bad. How about:
To the calculator! We know that 32 is a file with the archive bit. 34-32=2. A value of 2 is FILE_ATTRIBUTE_HIDDEN. Starting to make sense?
I wonder why it’s hidden?
Ok, one more:
Got the hang of it? Good. What a strange set of files names…
Call me Hank
To the wrap-up! At Microsoft these are often called “learnings”, which makes me want to hurtle across the conference table and shake the person until they admit that learnings isn’t a $%#^#^%& word.
Don’t monkey with file attributes on the destination server. For that matter, don’t changes any files in any fashion on the destination while cloning; this adds inefficiency. Letting users party on the downstream file server isn’t a good idea – you are about to enable replication and DFSR will reconcile the differences. If users on the destination alter files first, their changes will go buh-bye.
What part didn’t you understand?
Not to mention the confusion if you start seeding data onto your destination while they accessed it. “Hey Martha, what’s with this empty share? Oh, now it has some files. And some more. And some more. Ok, I’m going to lunch.”
You don’t have to do anything if you run into attribute changes causing less efficient replication – DFSR will fix everything up by performing initial sync on just those files. Seeing a couple of mismatches is no reason to get in a twist. If a sizable number mismatch, however, you need to evaluate what’s going on and decide if fixing the issue and re-importing is going to save you time in the end.
I want to thank Jeroen de Bonte , Dutch Microsoft Support Engineer extraordinaire , for working with us these behaviors, which pointed out that we had no documentation on it. Good man.
Until next time,
- Ned “Destitute and in Disrepute” Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.