Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, February 25, 2011 12:00 AM
I been running into this error message for the past several days. I know the files listed are not in use by a user. The really odd thing is that some of the file listed don't have an extension and I don't understand what it's referring to.
I believe resetting the DFSR Server will fix this, but this error message has occured on several different occasions and I'd like to determine why this is occurring and solve the problem at hand.
Can you help me solve this one?
All replies (13)
Tuesday, March 1, 2011 4:06 PM âś…Answered
As of now, my only resolution to this is to restart the DFSR service on the affected server so that these errors will clear from the report. The MS workaround Scorpio pointed me to doesn't lend itself well to long term use of monitoring the health of replication groups.
Is the DFSR team working to resolve the fact that DFSR doesn't post any Anti-Events after shared files are replicated? Resolving this would produce an accurate Health report without the need to restart the DFSR Service every time there is a sharing violation that has already been resolved automatically.
Friday, February 25, 2011 5:02 AM | 1 vote
Hello Cale_S,
This issue occurs in the current implementation of DFSR because no anti-events are triggered when the files are replicated. Therefore, the reporting state of the files remains as "sharing violated."
To determine the real state of the file, use the DFSRDIAG BACKLOG command to check for sharing violations. The command output provides a list of the first 100 files that are not replicated.
Please check here for the detail explanation.
The DFSR Diagnostics Report shows "sharing violations" events in Windows Server even though the files have already been replicated
http://support.microsoft.com/kb/973836
Hope it helps.
Scorprio
TechNet Software Assurance Managed Newsgroup MCTS: Windows Vista | Exchange Server 2007 MCITP: Enterprise Support Technician | Server & Enterprise Admin | System Architect
Friday, February 25, 2011 8:31 AM
From the error, it is caused that some files are not closed for some time so they cannot be replicated. From the file list, MDB files should be a database file, so it is possible that it is keeping in open status.
Actually it is not recommanded to use DFSR on database file or any similar files which will be accessed frequently or keep in open status as it will cause confliction issue.
For the other 3 files, as there is no extension name we cannot confirm the exact type. Check if they are also open by any process. You can use Share Folders snap-in in MMC to check. Or download the tool named Handle.exe from Microsoft site.
Shaon Shan |TechNet Subscriber Support in forum |If you have any feedback on our support, please contact [email protected]
Friday, February 25, 2011 7:19 PM
Thanks Scorpio, this explanation makes sense. I performed the backlog command and no it reports not backlog, both servers are in sync.
So now, while I understand why this is occurring, the problem now becomes an issue of having a report that is not accurate and up to date. Do you have any suggestions on how to resolve this problem?
Friday, February 25, 2011 7:21 PM
Shaon Shan, thanks for your reply. I understand your point about databases and why they are not recommended. I am less concerned about the databases and more perplexed by the files with no extension. I have tried the shared folders snap in, however I only know about the problem after the fact when the files are no longer actively in use. I discovered another file that is very similar and it appears that it may have been created by excel when a document crashed or a similar event. Do you know anything about this or how this type of file is created?
Friday, February 25, 2011 7:25 PM
The date on the left is the date Modified and the date on the right is the date created. After seeing the the temp excel file our bogus file with no extension were created at the same time, I'm convinced that excel was the program that generated this document. I just don't know why. Do you?
Saturday, February 26, 2011 2:21 AM | 3 votes
Hi Caleb_S,
After performing long time research on this issue, I have got some clue. Here is my investigation result.
First, the reason why Excel generate temporary file like 733D5E00 is due to the working manner of Office Suite.
When Excel saves a file, Excel follow these steps:
- Excel creates a randomly named temporary file (for example, Cedd4100 with no file name extension) in the destination folder that you specified in the Save As dialog box. The whole workbook is written to the temporary file.
- If changes are being saved to an existing file, Excel deletes the original file.
- Excel renames the temporary file. Excel gives the temporary file the file name that you specified (such as Book1.xls) in the Save As dialog box.
Please refer to:
Description of the way that Excel saves files
http://support.microsoft.com/kb/814068
Description of how Word creates temporary files
http://support.microsoft.com/kb/211632
AS Access is one family member of Office Suite, I believe that Access has the same manner of generating temporary file like what Excel and Word do, which could be the reason of generating temp file (ex. 9400EF00) on your server.
To try to get the insight on what happen with these temporary files are not replicated through DFS-R, I performed a deep research on DFS-R replication.
**Possible Root Cause: **
The possible cause of issue is because these are temporary files. By design, DFSR does not replicate files if they have the temporary attribute set on them, and it cannot be configured to do so.
The reason DFSR does not replicate files with the temporary attribute set is that they are considered short-lived files that you would never actually want to replicate. Using the temporary attribute on a file keeps that file in memory and saves on disk I/O. Therefore applications can use it on short-lived files to improve performance.
You may find more detailed explanation and solution to the issue from the following Directory Service team blog
DFSR Does Not Replicate Temporary Files
http://blogs.technet.com/askds/archive/2008/11/11/dfsr-does-not-replicate-temporary-files.aspx
(1) Please check the DFS debug log files which are located in the %Systemroot%\Debug folder on the problematic member server, to see if you can find File Attribute = 0x120 when the time of the issue occur.
Please note:
File Attributes is a bitmask that indicates which attributes on the File were set.
0x120 indicates the temporary attribute is set because that is 0x100 (TEMPORARY) and 0x20 (Archive) = 0x120.
RESOLUTION:
(2) Set the file attribute (remove Temporary attribute from file) using PowerShell.
PS D:\temp> $a = get-childitem XXXX.mdb
PS D:\temp> $a.attributes
Archive, Temporary
PS D:\temp> $a.attributes = ($a.attributes -band 0xFEFF)
PS D:\temp> $a.attributes
Archive
PS D:\temp>
PS D:\temp> fsutil usn readdata XXXX.mdb
Major Version : 0x2
Minor Version : 0x0
FileRef# : 0x011d00000000bc6e
Parent FileRef# : 0x0001000000000027
Usn : 0x0000000000000000
Time Stamp : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x0
File Attributes : 0x20
File Name Length : 0x14
File Name Offset : 0x3c
FileName : myfile.pdf
PS D:\temp>
(3) One simply to fix this issue is to avoid someone open and edit and save the mdb files on the DFS serve when DFS-R tries to replicate them. Please consider closing the mdb file Access software (DB) when DFS-R works.
Hope this can be clear and helpful for you.
Scorprio
TechNet Software Assurance Managed Newsgroup MCTS: Windows Vista | Exchange Server 2007 MCITP: Enterprise Support Technician | Server & Enterprise Admin | System Architect
Monday, February 28, 2011 4:02 PM
Hey Scropio,
I checked the file attributes as you suggested. The attributes on the 8 Digit all caps files (ie. 2E43BF10) are:
"+ attributes 0x20"
It doesn't appear to be a temp file. Additionally, I have only actually seen these files on the server in this one instance that I have posted the picture of. In all other instances, these files are no longer present when I go to look for them. This indicates, as you showed me above in your first post, that these files had problems replicating at one point, but no "anti-event" is generated, so it appears in the report.
It's possible these files are being accessed by a user in a remote office across the wan. (the server in that office is not apart of the replication group). Would slow access to these excel files generate this issue in this replication group? Do you have any other suggestions?
While this issues are not posing a problem to users or files, the main problem that this presents, is to me as the admin, trying to review various DFSR reports and getting information that is not relevant anymore.
Thanks for your continued help.
Tuesday, March 1, 2011 8:09 AM
For the file "~$license Table.xlsx", it is certain a temp file. When we open or create an Excel file, a temp file like this will occur. You can find it in Explorer with "show hidden file". If you keep press Save on Excel, you will also find a "file with no extension name" like the 733D5E00 one.
There is a bug (I cannot find the related thread at present but I reproduced the issue before) which will cause the temp file still exists after closing the Excel file. So I think the 2 files are corrupted temp file of Excel as SM mentioned.
Shaon Shan |TechNet Subscriber Support in forum |If you have any feedback on our support, please contact [email protected]
Thursday, March 3, 2011 6:19 AM
Hi,
Thank you for let us know that restart DFSR service can help workaround this issue.
As they are temp files, you may also have a try to just delete them to see if it will work. Meanwhile this case will be recorded. Thank you for the suggestion.
Shaon Shan |TechNet Subscriber Support in forum |If you have any feedback on our support, please contact [email protected]
Thursday, March 3, 2011 4:19 PM
Shaon, you are welcome. I hope that the underlying issue causing this can be resolved. If so, and you are aware of it, please do post back to this forum.
As for the temp files, they are not there when I go to look for them. They are indeed temp, but they are not seen as TEMP to the DFSR service as DFSR is trying to replicate them.
Restarting the DFSR service daily just doesn't seem to be a very good solution and I would like to work towards solving the underlying issue. Is there anything else that can be done?
What are the key things I need to look at in order to determine the health of a replication group is good?
Thursday, August 11, 2011 3:13 PM
The issue that brought me here was slightly different, in that the 4302 errors listed files that had been deleted from all DFS-R partners (3 servers on LAN), which I suppose still qualifies as "replicated".
The DFSRDIAG BACKLOG command does show a clean backlog, and restarting the DFS-R service on the indicated servers cleared their respective warnings from the Health Report.
So, I'll add my request that if we're going to have that cool Health Report (which is nice), then it should reflect reality.
Thank you,
Gary
Thursday, March 1, 2012 10:48 AM
Hi Scorpio,
I have the same issue. Event ID 4304 on my DFS server that sometimes lead to the file being moved to the conflict and deleted items folder.
I have confirmed that the temporary files created by a VBScript running on a .xls spreadsheet that are 8 characters long (like your 733D5E00). They have also been set with the 0x20 attribute and NOT the 0x120 attribute that would exclude them automatically from replication.
I thought that a good solution would be to add a "file filter" to the replication group that will exclude those files from replication. Something like "*.tmp, *.???????0.*" But I can't seem to find the correct format for the file attribute- any ideas on this?
Thanks, Bevan