Files magically reverting back on file Server 2012R2

Hi experts,

at one of the customer we recently bumped with weird problem while MIGRATING from old Server 2008 to new Server 2012R2. Old Server 2008 was AD DC and simple file share server with Access Level Enumeration turned on (so users could only see those shares, which they have access to).
All shares were about 300GB in size.

In the migration process we first setup new Server 2012R2, then moved slowly all FSMO roles from old to new server.
For SHARES we decided to use DFS replication to migrate, which was probably the WORST decision in the process! And I think DFS is gulty for the main problem, despite of the fact that we turned DFS OFF few weeks ago.

- some users sometimes report, that some file on NEW server's SHARE simply is not the last saved file, which they edited last. Like, they were adding rows in some excel table every week, and if they look at the file TODAY, it has Last Modified date of 2 months ago!?
- also some users reported, that some files they created are simply missing from NEW Server's SHARE folder.

- 1st, I turned OFF CACHING on all shares
- 2nd, I turned OFF DFS replication for all folders
It has been more than 2 weeks now since those changes, but still files magically dissapear from time to time, or "revert back" to some older version from 2 months ago.
- I also checked for Previous Versions on NEW server, but for those particular files there's none. Only the FIRST version from upon migration.
- I checked in BACKUP, but there's again only the FIRST version of file, 2 months old

In EVENT LOGS I find nothing related....actually, I cannot find any error, only informational logs.
Don't know what to check, where to start diagnostics and how to prevent those magic to happen.
LVL 18
Andrej PirmanAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Lionel MMSmall Business IT ConsultantCommented:
What about the checking the shares menu in Server Manager (Server Manager\File and Storage Services)--see the menu in upper left of server manager and check the settings for the shares from there. In the long run you may be better off renaming the old folders (not deleting but renaming) and break the shares, then create new folders, then new shares and then copy/move the date from the renamed folders to the new.
It sounds like users are often accessing the old shares. Remember that Windows and Office will remember the old file paths, which is probably what is happening if you are not also using DFS namespace. I don't see DFS replication being the issue, though I would have used robocopy for such a small amount of data.

You need to disable read access to the old shares. That should have been done at cutover. Next, use robocopy to grab a copy of every file modified after your cutover date. If the same file has also been modified on the new server they will need to be manually merged.
Andrej PirmanAuthor Commented:

well, what we did upon migration was also to remove all shares and paths, pointing to OLD server from all workstations. This was done with a script, and verified manually:
- script checked all users DESKTOPS for any link, pointing to OLD server and changed it to NEW server
- another script removed all network shares, regardless of how they were created
- then new drive mappings were created with GPO and login scripts

We monitored SHARE USAGE on old server and only DFS connections were active, no other user's access was detected.

DFS Replication is OFF now.

What I found interesting on NEW SERVER was a gozillion of files (say, thousand of them) in \ConflictAndDeleted folder on DFS share. Here were all those changed files from NEW server, which were not saved to NEW server location, but instead to \ConflictAndDeleted folder.

Seems like magic is all over now, no "magically reverted" files anymore and we found all missing changed files now. Why this happened, I don't know.
Might be that DFS CACHE settings were too low or too high (for 300GB shares I setup 40GB of DFS Cache). Might also be that initial replication did not finish (in 3-4 days) before users were starting using those files.
But from my perspective, DFS is:
- not reliable
- not transparent regarding current status
- not recommended for large shares (over few GB)
It sounds like you were not familiar with DFS replication and the tools. You should ALWAYS make sure that the initial replication had taken place before granting access to the new shares.

It sounds like people started accessing the replicated files before replication took place. DFS-R will then overwrite those changes from the source server up until replication has completed for all files.

I use replication for drives above 300 GB no problem, but I know how to use it properly. When in doubt about the status of a replication set I run a diagnostic report. DFS-R is more fragile than robocopy, and can break if the DFS-R service has a dirty shutdown. For a migration, DFS-R should only be considered if robocopy won't work well (for example if the data is already part of a DFS-R replication group).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Andrej PirmanAuthor Commented:
Well, kevinhsieh, what you say seems absolutely true. I suspected DFS not finishing properly before shares on new server were published to users, but I said, hey:
- if file is already present on NEW server, then DFS did its job for particular file and everything should be OK
- if the file is not present on NEW server, then no conflict can occur

But in the process many reboots were issued, which were not "dirty" shutdown, but rather just interruption for DFS...which obviously started over after each reboot.

DFS diagnostic finished properly on 2 of 3 shares, but on 3rd share diagnostic NEVER finished (even after a two weeks). And that was about the time we decided to switch it OFF, mainly due to lack of progress control and mysteriously reverted files.

Will take your comment into account, but I doubt I will ever use DFS on production anymore.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.