DFS-R servers having different content...
Greetings,
We're running 2 - 2012 R2 boxes configured for DFS-R.
Recently we found out that 2 users were seeing different content in a single folder. When I checked on it, SERVER 2 has all the files, SERVER 1 has half. The server with half the files, appears to have the newer items, but none of the ones from the Initial File Transfer.(all of this is thru viewing their own shares, thru their own Consoles)
Not a big deal, was just going to force replication and be done with it. Except for, that it didn't work.
When I browse SERVER 1 from SERVER 2, SERVER 2 sees SERVER 1 as having all the same files it does and vise vera. Replication works perfectly in both directions. Diag reports, prop reports, all show ZERO issues.
Any clue on why these servers are seeing the same file content on their partner, when they do not have the same file content?
(there is no back log btw)
Thanks for any help, I am perplexed.
We're running 2 - 2012 R2 boxes configured for DFS-R.
Recently we found out that 2 users were seeing different content in a single folder. When I checked on it, SERVER 2 has all the files, SERVER 1 has half. The server with half the files, appears to have the newer items, but none of the ones from the Initial File Transfer.(all of this is thru viewing their own shares, thru their own Consoles)
Not a big deal, was just going to force replication and be done with it. Except for, that it didn't work.
When I browse SERVER 1 from SERVER 2, SERVER 2 sees SERVER 1 as having all the same files it does and vise vera. Replication works perfectly in both directions. Diag reports, prop reports, all show ZERO issues.
Any clue on why these servers are seeing the same file content on their partner, when they do not have the same file content?
(there is no back log btw)
Thanks for any help, I am perplexed.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The reports state there is nothing wrong (minus the normal violations from open files)
http://www.eventid.net/display-eventid-4302-source-DFSR-eventno-8451-phase-1.htm
event id 4302
Also prop test and prop report. Nothing is wrong with it.
Any new docs created replicate in both directions without issue, takes about 2-3 seconds.
http://www.eventid.net/display-eventid-4302-source-DFSR-eventno-8451-phase-1.htm
event id 4302
Also prop test and prop report. Nothing is wrong with it.
Any new docs created replicate in both directions without issue, takes about 2-3 seconds.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
It appears i'm rocking a 0x121 on that file.
It would appear, I have a bunch of temps that are not temps. :(
It would appear, I have a bunch of temps that are not temps. :(
ASKER
ASKER
Arnold knows what is up!
You have to identify what creates these files, it might be an issue inherent in it. The one I ran into with this same issues, a user was using print preview/to an OXPS/XPS output.
In the case, the user is creating PDFs instead.
In the case, the user is creating PDFs instead.
ASKER
So far all the files that fail are from the initial file transfer. Anything new(created by all/any the users in the department 'only 3 people') replicates.
Here is something you might find useful. Using powershell to strip the temp status of a file/s.
https://social.technet.microsoft.com/forums/windowsserver/en-US/9164f02c-b81b-477a-b9b3-e71dcd10248e/forum-faq-temporary-files-are-not-replicated-by-dfsr
https://social.technet.microsoft.com/forums/windowsserver/en-US/9164f02c-b81b-477a-b9b3-e71dcd10248e/forum-faq-temporary-files-are-not-replicated-by-dfsr
ASKER
There are a mix of PC's accessing these files, mostly Win 7 though.
I'll give that item a try.
Thank you!