Windows 2008 DFS issue – files dissapear

dfs-riis-7windowswindows-server-2008

I have farm with 3 servers: 2 web and 1 DB. All servers are identical Windows 2008 R2 fresh installation.
2 servers running IIS7 websites and connect 3rd server as a back end DB.
IIS servers running several sites and each site points to dedicated sub directory under Inetpub.

DFS replication of whole Inetpub folder configured between these 3 servers and works perfectly except one thing:
When I put new file or modify existing file on one of the web sites directories, it replicates to all DFS members and accessible through IIS, however after 20 minutes it just dissapears (if this is a new file) or reverts to previous version (if the file was modified).
When I put the file under the root of Inetpub folder, it stays there.

Here what I tried until now:

  1. Modified the DFS replication topology from Full Mesh to Hub-and-Spoke
  2. Tried to disable links in order to eliminate "Master-Slave" issues.
  3. Tried to remove "Read Only" attributes from files and folders
  4. Tried to stop IIS in order to eliminate IIS locking issue.

I'm kinda out of ideas here. Any help will be appreciated.

Best Answer

Well good on you for trying something before posting here. But really what you need to do is use something like procmon along with DFSR debug logs to determine whats going on. If you can enable auditing on the file and you have a thorough audit policy, you can get audit events showing what/who caused the delete.

DFSR debug log analysis will show if DFSR activity is causing the file delete. http://blogs.technet.com/b/askds/archive/2009/04/09/dfsr-debug-log-series-wrapup-and-downloadable-copies.aspx has details which should help decipher the logs.

I also suggest ensuring the antivirus is configured correctly as per http://support.microsoft.com/kb/822158. The correct folders must be excluded from AV perspective.

At the end of the day, there could be any reasons why the file "disappears". It could be some acitivity which dfsr interprets as a request to delete. Else it could be some other process doing the delete. Hence the procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645) suggestion. A repro with Procmon running while filtered for the path of interest should show the process responsible for the delete.

Related Topic