Very disappointed in MS Office, DFS and such. Our replicated shares on only 600 MB give or take. Something MUST fix this bug.we are seeing it all over the place and its getting worse.yet This is INSANITY as both products are MS and they know the issue and need to send out a resolution link. I still dont see an answer or resolution. If anything else comes up - I'll let You know. I can tell for sure now, that it's definitely a DFSR and not an Excel issue. But this is only a guess, I had no chance to prove it. To lock during saving, and thus - the Excel issue. My thought is that probably under the very high load DFSR causes Excel files of we had 13Tb of replicated data, MS tested is 10Tb.Īlmost a month ago the user profiles were removed from replicated folders and replicated data size went down to 7Tb, the replication started working fine (yet), and the Excel issue Quite a lot of time to come up with this excuse only tells me that MS have no idea either, of what could be the reason. Also, our environment was a bit over MS tested solution Nothing else matters, it's just not supported. įinally, after 7 months of solving, Microsoft declared, that we can't replicate roaming user profiles between two servers with separate storage if they are configured as aįailover for user connection. Then a few more to find root causes of failure. We had a case open with Microsoft, but while solving this case we had a major DFSR fault (stopped replicating entirely), and opened another case to solve that fault.
The Excel problem is gone in our environment, as far as I know. Sorry I took so long to respond, but I was just double-checking things. Tuned up DFSR: Started a thread on Excel TechNet: The things I have already tried after searching and not finding anything that fits on the net: Backlog size and replication delay does not cause a problem for us, as long as no data is lost. Not noticed any correlation between the backlog size and the frequency of shared excel issues. Usually 0-20 items, and at peak times somedays it rises for short periods to 1000 or more items. Therefore if Excel still has a lock on file, DFSR will not intervene and wait for Excel to finish what it was doing. Why is Excel sometimes not renaming its temp files? As far as I understand, DFSR does not try to replicate a file if it's still in use
We have no problems at all with ordinary, not "shared" Excel files.Īlso, no event (no sharing violation, no conflict resolution or other) is logged in DFS log when the original file is deleted and temp If the DFSR replication is turned on for server folder containing the sharedĮxcel files, then the issues start, and go away if DFSR is turned off. The change that clearly triggers this is the DFSR replication. I haven't been able to reproduce the issue myself, but apparently this is happening quite often (we have several thousand excel files open at a time, and we get a few cases per day). To the original name, and remains like "2BE72000". The issue sometimes occurs when the users are saving a shared Excel file - the original file is deleted, and the TEMP file is not renamed
#0 DISAPPEARS IN EXCEL WINDOWS#
Users use mainly Excel 2010 on Windows 7, and also some use Excel 2007 on Vista. The files are being edited on a single primary server ONLY, secondary server is a passive backup and does not accept connections if primary is available. We have a problem while saving Excel files that are "shared" (multiple user editing) in DFS replicated network folder.Ģ x Server 2008 R2 (hosting shared Excel files in a network share, with two-way DFS replication between them)
0 kommentar(er)
