Discussion:
DFSR file version regressions
(too old to reply)
Jeff Vandervoort
2007-04-17 16:38:59 UTC
Permalink
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.

Currently, the 2 servers are on the same AD site. Soon, one server will be
moved to a branch office (different AD site), at which point we will be
using DFSR to back up the branch office's data using the main office's
server.

DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS partner to
which referrals are currently enabled is the main office's server. When the
branch office is deployed, I will change all referrals to the branch office
server.

The DFS share is in production. During a 2.5-day outage of the server that
is NOT enabled for referrals, users reported new versions of files were
overwritten with old versions. And, again, after the non-referral server was
back up, got the same reports. Previous Versions is enabled on both servers;
users were able to restore correct versions from Previous Versions. That
also tells me this is not a problem with closing the file without saving
it...this is a system problem.

1. Still gathering info, but at least some of the files were .XLS files.
This thread--

http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7

--implies that there is a known issue with .XLS files (among others). We are
getting the message cited by "dan0". I gather we need this hotfix if only
because we have .XLS files, but is the hotfix specific to the issue of new
files being overwritten with obsolete versions?

2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch office
server (referrals disabled) after it was brought online?

3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be prevented
from happening again?
--
Jeff Vandervoort
JRVsystems
Ned Pyle [MSFT]
2007-04-19 00:32:13 UTC
Permalink
Install Windows Server 2003 SP2 to fix this and many other known DFSR
issues. This is the recommended solution.

Otherwise you will need to open a (free) case here at MS and request hotfix
http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will be
moved to a branch office (different AD site), at which point we will be
using DFSR to back up the branch office's data using the main office's
server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS partner
to which referrals are currently enabled is the main office's server. When
the branch office is deployed, I will change all referrals to the branch
office server.
The DFS share is in production. During a 2.5-day outage of the server that
is NOT enabled for referrals, users reported new versions of files were
overwritten with old versions. And, again, after the non-referral server
was back up, got the same reports. Previous Versions is enabled on both
servers; users were able to restore correct versions from Previous
Versions. That also tells me this is not a problem with closing the file
without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS files.
This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others). We
are getting the message cited by "dan0". I gather we need this hotfix if
only because we have .XLS files, but is the hotfix specific to the issue
of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be prevented
from happening again?
--
Jeff Vandervoort
JRVsystems
Jeff Vandervoort
2007-04-19 03:22:22 UTC
Permalink
Hmmmm...PSS just told me this morning that the DFSR fixes in WS2003 SP2
would *not* help my file regression issue, and they requested that I upload
150MB worth of DFSR & directory services reports for analysis! Not saying I
don't believe you, but I still need to see what the other tech tells me.

Client's highest priority is getting this server deployed, higher priority
than SP2, unless SP2 turns out to be on the critical path for functionality.
I'll review the SP2 (or-KB925332 hotfix) situation with the client, if
necessary, after I get the feedback from the other tech.

Thanks.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
Install Windows Server 2003 SP2 to fix this and many other known DFSR
issues. This is the recommended solution.
Otherwise you will need to open a (free) case here at MS and request
hotfix http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will
be moved to a branch office (different AD site), at which point we will
be using DFSR to back up the branch office's data using the main office's
server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS partner
to which referrals are currently enabled is the main office's server.
When the branch office is deployed, I will change all referrals to the
branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of files
were overwritten with old versions. And, again, after the non-referral
server was back up, got the same reports. Previous Versions is enabled on
both servers; users were able to restore correct versions from Previous
Versions. That also tells me this is not a problem with closing the file
without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS files.
This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others). We
are getting the message cited by "dan0". I gather we need this hotfix if
only because we have .XLS files, but is the hotfix specific to the issue
of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Ned Pyle [MSFT]
2007-04-19 14:33:09 UTC
Permalink
The other tech you spoke to is mistaken if he was saying that the XLS issue
is not rolled into SP2 - it is.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
Post by Jeff Vandervoort
Hmmmm...PSS just told me this morning that the DFSR fixes in WS2003 SP2
would *not* help my file regression issue, and they requested that I
upload 150MB worth of DFSR & directory services reports for analysis! Not
saying I don't believe you, but I still need to see what the other tech
tells me.
Client's highest priority is getting this server deployed, higher priority
than SP2, unless SP2 turns out to be on the critical path for
functionality. I'll review the SP2 (or-KB925332 hotfix) situation with the
client, if necessary, after I get the feedback from the other tech.
Thanks.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
Install Windows Server 2003 SP2 to fix this and many other known DFSR
issues. This is the recommended solution.
Otherwise you will need to open a (free) case here at MS and request
hotfix http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will
be moved to a branch office (different AD site), at which point we will
be using DFSR to back up the branch office's data using the main
office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all referrals
to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of files
were overwritten with old versions. And, again, after the non-referral
server was back up, got the same reports. Previous Versions is enabled
on both servers; users were able to restore correct versions from
Previous Versions. That also tells me this is not a problem with closing
the file without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS files.
This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others). We
are getting the message cited by "dan0". I gather we need this hotfix if
only because we have .XLS files, but is the hotfix specific to the issue
of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Jeff Vandervoort
2007-04-19 23:54:24 UTC
Permalink
If you go back to my OP, you'll see the main concern is files regressing to
older versions during replication after a server outage. The fact that most
are Excel files may be relevant, and that I see the messages the other
poster mentioned, may be a red herring. Worth fixing, certainly, but not our
primary interest ATM.

Users of this DFS share live mostly in XL, but now report at least 1 Word
file regressed, so I'm inclined to think the XL connection is really not a
connection.

Is the XL fix specific to regressions?
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
The other tech you spoke to is mistaken if he was saying that the XLS
issue is not rolled into SP2 - it is.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
Hmmmm...PSS just told me this morning that the DFSR fixes in WS2003 SP2
would *not* help my file regression issue, and they requested that I
upload 150MB worth of DFSR & directory services reports for analysis! Not
saying I don't believe you, but I still need to see what the other tech
tells me.
Client's highest priority is getting this server deployed, higher
priority than SP2, unless SP2 turns out to be on the critical path for
functionality. I'll review the SP2 (or-KB925332 hotfix) situation with
the client, if necessary, after I get the feedback from the other tech.
Thanks.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
Install Windows Server 2003 SP2 to fix this and many other known DFSR
issues. This is the recommended solution.
Otherwise you will need to open a (free) case here at MS and request
hotfix http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will
be moved to a branch office (different AD site), at which point we will
be using DFSR to back up the branch office's data using the main
office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all referrals
to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of files
were overwritten with old versions. And, again, after the non-referral
server was back up, got the same reports. Previous Versions is enabled
on both servers; users were able to restore correct versions from
Previous Versions. That also tells me this is not a problem with
closing the file without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others).
We are getting the message cited by "dan0". I gather we need this
hotfix if only because we have .XLS files, but is the hotfix specific
to the issue of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Ned Pyle [MSFT]
2007-04-20 14:02:54 UTC
Permalink
It was specific to improper conflicting of data, so that you'd see newer
versions in the ConflictAndDeleted folder and older (or totally missing)
files in the RF. It could apply to other office files as well, as well as
JPG's and a few other file formats generated by particular applications that
do weirdo temp file creation.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
Post by Jeff Vandervoort
If you go back to my OP, you'll see the main concern is files regressing
to older versions during replication after a server outage. The fact that
most are Excel files may be relevant, and that I see the messages the
other poster mentioned, may be a red herring. Worth fixing, certainly, but
not our primary interest ATM.
Users of this DFS share live mostly in XL, but now report at least 1 Word
file regressed, so I'm inclined to think the XL connection is really not a
connection.
Is the XL fix specific to regressions?
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
The other tech you spoke to is mistaken if he was saying that the XLS
issue is not rolled into SP2 - it is.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
Hmmmm...PSS just told me this morning that the DFSR fixes in WS2003 SP2
would *not* help my file regression issue, and they requested that I
upload 150MB worth of DFSR & directory services reports for analysis!
Not saying I don't believe you, but I still need to see what the other
tech tells me.
Client's highest priority is getting this server deployed, higher
priority than SP2, unless SP2 turns out to be on the critical path for
functionality. I'll review the SP2 (or-KB925332 hotfix) situation with
the client, if necessary, after I get the feedback from the other tech.
Thanks.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
Install Windows Server 2003 SP2 to fix this and many other known DFSR
issues. This is the recommended solution.
Otherwise you will need to open a (free) case here at MS and request
hotfix http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server
will be moved to a branch office (different AD site), at which point
we will be using DFSR to back up the branch office's data using the
main office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all
referrals to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of
files were overwritten with old versions. And, again, after the
non-referral server was back up, got the same reports. Previous
Versions is enabled on both servers; users were able to restore
correct versions from Previous Versions. That also tells me this is
not a problem with closing the file without saving it...this is a
system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others).
We are getting the message cited by "dan0". I gather we need this
hotfix if only because we have .XLS files, but is the hotfix specific
to the issue of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few
hours before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Patrick Seeber
2007-04-25 17:08:59 UTC
Permalink
Hey Ned,

I installed SP2 on Monday evening, and I still am having *deleted* files
re-appearing... files that are either "saved" or "saved as" do not hold the
changes... It appears that the SP2 doesn't have all the bugs squashed yet.

This is for your own personal FYI... I will be calling in for MS help... I
will post any *fix* that works for the group.

I appreciate your efforts! I have gathered several useful tid bits here...

Patrick
Post by Ned Pyle [MSFT]
It was specific to improper conflicting of data, so that you'd see newer
versions in the ConflictAndDeleted folder and older (or totally missing)
files in the RF. It could apply to other office files as well, as well as
JPG's and a few other file formats generated by particular applications
that do weirdo temp file creation.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
If you go back to my OP, you'll see the main concern is files regressing
to older versions during replication after a server outage. The fact that
most are Excel files may be relevant, and that I see the messages the
other poster mentioned, may be a red herring. Worth fixing, certainly,
but not our primary interest ATM.
Users of this DFS share live mostly in XL, but now report at least 1 Word
file regressed, so I'm inclined to think the XL connection is really not
a connection.
Is the XL fix specific to regressions?
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
The other tech you spoke to is mistaken if he was saying that the XLS
issue is not rolled into SP2 - it is.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
Hmmmm...PSS just told me this morning that the DFSR fixes in WS2003 SP2
would *not* help my file regression issue, and they requested that I
upload 150MB worth of DFSR & directory services reports for analysis!
Not saying I don't believe you, but I still need to see what the other
tech tells me.
Client's highest priority is getting this server deployed, higher
priority than SP2, unless SP2 turns out to be on the critical path for
functionality. I'll review the SP2 (or-KB925332 hotfix) situation with
the client, if necessary, after I get the feedback from the other tech.
Thanks.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
Install Windows Server 2003 SP2 to fix this and many other known DFSR
issues. This is the recommended solution.
Otherwise you will need to open a (free) case here at MS and request
hotfix http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for
more information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server
will be moved to a branch office (different AD site), at which point
we will be using DFSR to back up the branch office's data using the
main office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all
referrals to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of
files were overwritten with old versions. And, again, after the
non-referral server was back up, got the same reports. Previous
Versions is enabled on both servers; users were able to restore
correct versions from Previous Versions. That also tells me this is
not a problem with closing the file without saving it...this is a
system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others).
We are getting the message cited by "dan0". I gather we need this
hotfix if only because we have .XLS files, but is the hotfix specific
to the issue of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few
hours before it is put in production at the branch office. Can this
be prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Patrick Seeber
2007-04-26 20:44:55 UTC
Permalink
After some time with a MS Tech, this is what I now know.

If you have a namespace and replication group setup, and you delete it, then
set it back up you may experience this issue.

A potentially easy work around is to break the replication and namespaces,
wait for DFS-R to setter (DFS Evt ID 4010 logged in DFS Evt Log), then
rename the directories to a new name, then rename back to the original name.
I don't know about you, but I have UNC's in use for all sorts of automation.

Now that you have renamed the shared directories to their original names,
re-establish your Namespace and Replication partners. Apparently there is
some hidden info that buggers the whole mess (technical term) up if you
build Namespace and Replication partners on previously DFS'd folders with
out renaming those folders.

I have not had time to try this, and won't until Friday, but it is the first
step / attempt to fix this for my environment.

HTH

YMMV!

I will be curious to know if this is the case at your site Jeff...

Patrick
Post by Patrick Seeber
Hey Ned,
I installed SP2 on Monday evening, and I still am having *deleted* files
re-appearing... files that are either "saved" or "saved as" do not hold
the changes... It appears that the SP2 doesn't have all the bugs squashed
yet.
This is for your own personal FYI... I will be calling in for MS help...
I will post any *fix* that works for the group.
I appreciate your efforts! I have gathered several useful tid bits here...
Patrick
Post by Ned Pyle [MSFT]
It was specific to improper conflicting of data, so that you'd see newer
versions in the ConflictAndDeleted folder and older (or totally missing)
files in the RF. It could apply to other office files as well, as well as
JPG's and a few other file formats generated by particular applications
that do weirdo temp file creation.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
If you go back to my OP, you'll see the main concern is files regressing
to older versions during replication after a server outage. The fact
that most are Excel files may be relevant, and that I see the messages
the other poster mentioned, may be a red herring. Worth fixing,
certainly, but not our primary interest ATM.
Users of this DFS share live mostly in XL, but now report at least 1
Word file regressed, so I'm inclined to think the XL connection is
really not a connection.
Is the XL fix specific to regressions?
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
The other tech you spoke to is mistaken if he was saying that the XLS
issue is not rolled into SP2 - it is.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
Hmmmm...PSS just told me this morning that the DFSR fixes in WS2003
SP2 would *not* help my file regression issue, and they requested that
I upload 150MB worth of DFSR & directory services reports for
analysis! Not saying I don't believe you, but I still need to see what
the other tech tells me.
Client's highest priority is getting this server deployed, higher
priority than SP2, unless SP2 turns out to be on the critical path for
functionality. I'll review the SP2 (or-KB925332 hotfix) situation with
the client, if necessary, after I get the feedback from the other tech.
Thanks.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
Install Windows Server 2003 SP2 to fix this and many other known DFSR
issues. This is the recommended solution.
Otherwise you will need to open a (free) case here at MS and request
hotfix http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for
more information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server
will be moved to a branch office (different AD site), at which point
we will be using DFSR to back up the branch office's data using the
main office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main
office's server. When the branch office is deployed, I will change
all referrals to the branch office server.
The DFS share is in production. During a 2.5-day outage of the
server that is NOT enabled for referrals, users reported new
versions of files were overwritten with old versions. And, again,
after the non-referral server was back up, got the same reports.
Previous Versions is enabled on both servers; users were able to
restore correct versions from Previous Versions. That also tells me
this is not a problem with closing the file without saving it...this
is a system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among
others). We are getting the message cited by "dan0". I gather we
need this hotfix if only because we have .XLS files, but is the
hotfix specific to the issue of new files being overwritten with
obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the
branch office server (referrals disabled) after it was brought
online?
3. The server will be down at least twice more for at least a few
hours before it is put in production at the branch office. Can this
be prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Jeff Vandervoort
2007-04-27 04:15:34 UTC
Permalink
Thanks for the feedback, Patrick!

BTW, I'm now on WS2003SP2 on the 2 servers involved in this problem.

I couldn't honestly tell you at this point if I've set up DFS & DFSR more
than once on these folders before the problem occurred. This is my first DFS
experience since R2 was released, so it's very possible I did it more than
once.

I definitely did NOT do this at the time the rollbacks occurred, though.

In the process of trying to troubleshoot this problem, though, I did delete
the replication group and the "backup" folder target. Then, after a couple
days, deleted the now-out-of-date folder that was left behind and re-created
the folder target and replication group. However, server and network links
were up the whole time (outages have been the trigger here). No reports of
rolled back files...yet, anyway. So maybe that's an equivalent option? We'll
see.

The acid test for my site is downing the server, then bringing it back up.
I've done that once for about an hour today, and will be doing it a few more
times before the new server is finally in production. Will keep an eye on it
and report back.

If PSS's explanation is correct, that's pretty scary. Any KB articles that
describe the problem & workaround?

If one has to do this perfectly the first time, or go through this folder
renaming nonsense, that's not a very robust design. It deserves a KB article
until there's a hotfix.
--
Jeff Vandervoort
JRVsystems
Post by Patrick Seeber
After some time with a MS Tech, this is what I now know.
If you have a namespace and replication group setup, and you delete it,
then set it back up you may experience this issue.
A potentially easy work around is to break the replication and namespaces,
wait for DFS-R to setter (DFS Evt ID 4010 logged in DFS Evt Log), then
rename the directories to a new name, then rename back to the original
name. I don't know about you, but I have UNC's in use for all sorts of
automation.
Now that you have renamed the shared directories to their original names,
re-establish your Namespace and Replication partners. Apparently there is
some hidden info that buggers the whole mess (technical term) up if you
build Namespace and Replication partners on previously DFS'd folders with
out renaming those folders.
I have not had time to try this, and won't until Friday, but it is the
first step / attempt to fix this for my environment.
HTH
YMMV!
I will be curious to know if this is the case at your site Jeff...
Patrick
Post by Patrick Seeber
Hey Ned,
I installed SP2 on Monday evening, and I still am having *deleted* files
re-appearing... files that are either "saved" or "saved as" do not hold
the changes... It appears that the SP2 doesn't have all the bugs
squashed yet.
This is for your own personal FYI... I will be calling in for MS help...
I will post any *fix* that works for the group.
I appreciate your efforts! I have gathered several useful tid bits here...
Patrick
Post by Ned Pyle [MSFT]
It was specific to improper conflicting of data, so that you'd see newer
versions in the ConflictAndDeleted folder and older (or totally missing)
files in the RF. It could apply to other office files as well, as well
as JPG's and a few other file formats generated by particular
applications that do weirdo temp file creation.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for more
information.
Post by Jeff Vandervoort
If you go back to my OP, you'll see the main concern is files
regressing to older versions during replication after a server outage.
The fact that most are Excel files may be relevant, and that I see the
messages the other poster mentioned, may be a red herring. Worth
fixing, certainly, but not our primary interest ATM.
Users of this DFS share live mostly in XL, but now report at least 1
Word file regressed, so I'm inclined to think the XL connection is
really not a connection.
Is the XL fix specific to regressions?
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
The other tech you spoke to is mistaken if he was saying that the XLS
issue is not rolled into SP2 - it is.
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for
more information.
Post by Jeff Vandervoort
Hmmmm...PSS just told me this morning that the DFSR fixes in WS2003
SP2 would *not* help my file regression issue, and they requested
that I upload 150MB worth of DFSR & directory services reports for
analysis! Not saying I don't believe you, but I still need to see
what the other tech tells me.
Client's highest priority is getting this server deployed, higher
priority than SP2, unless SP2 turns out to be on the critical path
for functionality. I'll review the SP2 (or-KB925332 hotfix) situation
with the client, if necessary, after I get the feedback from the
other tech.
Thanks.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle [MSFT]
Install Windows Server 2003 SP2 to fix this and many other known
DFSR issues. This is the recommended solution.
Otherwise you will need to open a (free) case here at MS and request
hotfix http://support.microsoft.com/kb/925332
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no
rights. Please read http://www.microsoft.com/info/cpyright.htm for
more information.
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a
DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server
will be moved to a branch office (different AD site), at which
point we will be using DFSR to back up the branch office's data
using the main office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main
office's server. When the branch office is deployed, I will change
all referrals to the branch office server.
The DFS share is in production. During a 2.5-day outage of the
server that is NOT enabled for referrals, users reported new
versions of files were overwritten with old versions. And, again,
after the non-referral server was back up, got the same reports.
Previous Versions is enabled on both servers; users were able to
restore correct versions from Previous Versions. That also tells me
this is not a problem with closing the file without saving
it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among
others). We are getting the message cited by "dan0". I gather we
need this hotfix if only because we have .XLS files, but is the
hotfix specific to the issue of new files being overwritten with
obsolete versions?
2. Is there any other reason why new files on the main office
server (referrals enabled) could be overwritten by old files from
the branch office server (referrals disabled) after it was brought
online?
3. The server will be down at least twice more for at least a few
hours before it is put in production at the branch office. Can this
be prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Patrick Seeber
2007-04-23 17:17:11 UTC
Permalink
Really glad I have found this thread. I have been battling this issue
heavily since last week...

Our site topology is multiple servers at 3 sites for BCP purposes only. The
remote sites are not manned, and there should be no reason for this issue to
be occurring - the other sites should only be catching the changed files
from the primary site. It is a mesh configuration using private T-1's for
replication. Bandwidth is not now, nor has it been, an issue.

Been thinking that this could be a "site latency" issue - primary site is
most heavily used, no one at the 2 other target sites to change files, only
files that are changing are at the primary server site.

This may have been validated over the past weekend. A weekend user reported
no "file save as" issues on any files while they were the only user working.
Still don't have a for sure reason on this.

Errors saving files have already been reported by staff today, after an
uneventful weekend.

Hope to see an easy fix on this soon!

Patrick
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will be
moved to a branch office (different AD site), at which point we will be
using DFSR to back up the branch office's data using the main office's
server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS partner
to which referrals are currently enabled is the main office's server. When
the branch office is deployed, I will change all referrals to the branch
office server.
The DFS share is in production. During a 2.5-day outage of the server that
is NOT enabled for referrals, users reported new versions of files were
overwritten with old versions. And, again, after the non-referral server
was back up, got the same reports. Previous Versions is enabled on both
servers; users were able to restore correct versions from Previous
Versions. That also tells me this is not a problem with closing the file
without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS files.
This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others). We
are getting the message cited by "dan0". I gather we need this hotfix if
only because we have .XLS files, but is the hotfix specific to the issue
of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be prevented
from happening again?
--
Jeff Vandervoort
JRVsystems
Jeff Vandervoort
2007-04-24 02:29:42 UTC
Permalink
Are you on WS2003 R2/SP1, R2/SP1 + any of the hotfixes mentioned in the
thread, or R2/SP2?
--
Jeff Vandervoort
JRVsystems
Post by Patrick Seeber
Really glad I have found this thread. I have been battling this issue
heavily since last week...
Our site topology is multiple servers at 3 sites for BCP purposes only.
The remote sites are not manned, and there should be no reason for this
issue to be occurring - the other sites should only be catching the
changed files from the primary site. It is a mesh configuration using
private T-1's for replication. Bandwidth is not now, nor has it been, an
issue.
Been thinking that this could be a "site latency" issue - primary site is
most heavily used, no one at the 2 other target sites to change files,
only files that are changing are at the primary server site.
This may have been validated over the past weekend. A weekend user
reported no "file save as" issues on any files while they were the only
user working. Still don't have a for sure reason on this.
Errors saving files have already been reported by staff today, after an
uneventful weekend.
Hope to see an easy fix on this soon!
Patrick
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will
be moved to a branch office (different AD site), at which point we will
be using DFSR to back up the branch office's data using the main office's
server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS partner
to which referrals are currently enabled is the main office's server.
When the branch office is deployed, I will change all referrals to the
branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of files
were overwritten with old versions. And, again, after the non-referral
server was back up, got the same reports. Previous Versions is enabled on
both servers; users were able to restore correct versions from Previous
Versions. That also tells me this is not a problem with closing the file
without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS files.
This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others). We
are getting the message cited by "dan0". I gather we need this hotfix if
only because we have .XLS files, but is the hotfix specific to the issue
of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Patrick Seeber
2007-04-24 14:29:29 UTC
Permalink
Hello Jeff,
As of last night we are now 2003 R2 SP2

I have one user who still hasn't seen any improvement already. Open excel
file, make change, save as, new name, close, re-open, reverted to original
version.

New versions - 2 of them - show up in the local, primary server conflict and
deleted... still searching on the other 2 servers...

Patrick
Post by Jeff Vandervoort
Are you on WS2003 R2/SP1, R2/SP1 + any of the hotfixes mentioned in the
thread, or R2/SP2?
--
Jeff Vandervoort
JRVsystems
Post by Patrick Seeber
Really glad I have found this thread. I have been battling this issue
heavily since last week...
Our site topology is multiple servers at 3 sites for BCP purposes only.
The remote sites are not manned, and there should be no reason for this
issue to be occurring - the other sites should only be catching the
changed files from the primary site. It is a mesh configuration using
private T-1's for replication. Bandwidth is not now, nor has it been, an
issue.
Been thinking that this could be a "site latency" issue - primary site is
most heavily used, no one at the 2 other target sites to change files,
only files that are changing are at the primary server site.
This may have been validated over the past weekend. A weekend user
reported no "file save as" issues on any files while they were the only
user working. Still don't have a for sure reason on this.
Errors saving files have already been reported by staff today, after an
uneventful weekend.
Hope to see an easy fix on this soon!
Patrick
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will
be moved to a branch office (different AD site), at which point we will
be using DFSR to back up the branch office's data using the main
office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all referrals
to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of files
were overwritten with old versions. And, again, after the non-referral
server was back up, got the same reports. Previous Versions is enabled
on both servers; users were able to restore correct versions from
Previous Versions. That also tells me this is not a problem with closing
the file without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS files.
This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others). We
are getting the message cited by "dan0". I gather we need this hotfix if
only because we have .XLS files, but is the hotfix specific to the issue
of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Patrick Seeber
2007-04-24 15:53:20 UTC
Permalink
Okay, more data:
for a period of time, I hijacked a user's WS.
Initially, I had the issue of not being able to save changes. WS was
correctly mapped to the primary DFS/DFS-R local server. Both Excel and Word
exhibited the cannot save, cannot file/save as any changes to a file. I did
check the WS updates status, and no updates were pending for MS Office - XP,
.NET updates for 1.1, 2.0, and 3.0 were ready. Only the .NET 1.1 updates
have been applied. In our environment, .NET 2.0 and 3.0 are not fully
approved on our WS.

Suddenly, even before the updates were applied, everything began to function
just as it should and all changes were saved, regardless of method of saving
or opening of files.

This appears to be "intermittent" at this point. The other possibilities
could be network latency, or server load based in some manner. We are
pretty much Gig Ethernet desktop to server.

More domain info for you:
3 sites, all connected by private T-1 to each other. All reside in the same
domain, and sites are defined and the different subnets are correctly
described.

All 3 servers are in multiple namespaces. This particular namespace -
home - is the only known area of issue (so far) Referral order is
Overridden - S1 is local and the first among all targets. S2 is off site
and last among targets of equal cost, S3 is last among all targets. Today,
everyone seems to be assigned the proper primary server S1.

Primary Server Specs - Server 2003 R2 SP2 - I assume hot fixes are rolled up
and I am current on "patches". The Home namespace resides on a RAID5 drive
C:. System memory is 3Gb. XEON 2.8Ghz processor, hyperthreaded I suspect.
Performance monitor reveals periods of rather high disk queue length
counters - these do not sustain for any extended duration....

What else do you need to know? This is becomig a big deal around here...

I appreciate the assistance!

Patrick
Post by Patrick Seeber
Hello Jeff,
As of last night we are now 2003 R2 SP2
I have one user who still hasn't seen any improvement already. Open excel
file, make change, save as, new name, close, re-open, reverted to original
version.
New versions - 2 of them - show up in the local, primary server conflict
and deleted... still searching on the other 2 servers...
Patrick
Post by Jeff Vandervoort
Are you on WS2003 R2/SP1, R2/SP1 + any of the hotfixes mentioned in the
thread, or R2/SP2?
--
Jeff Vandervoort
JRVsystems
Post by Patrick Seeber
Really glad I have found this thread. I have been battling this issue
heavily since last week...
Our site topology is multiple servers at 3 sites for BCP purposes only.
The remote sites are not manned, and there should be no reason for this
issue to be occurring - the other sites should only be catching the
changed files from the primary site. It is a mesh configuration using
private T-1's for replication. Bandwidth is not now, nor has it been,
an issue.
Been thinking that this could be a "site latency" issue - primary site
is most heavily used, no one at the 2 other target sites to change
files, only files that are changing are at the primary server site.
This may have been validated over the past weekend. A weekend user
reported no "file save as" issues on any files while they were the only
user working. Still don't have a for sure reason on this.
Errors saving files have already been reported by staff today, after an
uneventful weekend.
Hope to see an easy fix on this soon!
Patrick
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will
be moved to a branch office (different AD site), at which point we will
be using DFSR to back up the branch office's data using the main
office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all referrals
to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of files
were overwritten with old versions. And, again, after the non-referral
server was back up, got the same reports. Previous Versions is enabled
on both servers; users were able to restore correct versions from
Previous Versions. That also tells me this is not a problem with
closing the file without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others).
We are getting the message cited by "dan0". I gather we need this
hotfix if only because we have .XLS files, but is the hotfix specific
to the issue of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Patrick Seeber
2007-04-24 16:57:49 UTC
Permalink
More Data:
User profile seems to be a non-issue. I have experience this version
regression issue first hand under my administrative access profile.

Tested with Word 2003 and 2007 - this makes no difference. The new 2007
DOCX format is no more predictable than Word 2003.

Saved files are going to Conflict and Deleted with the new changes.

Looks like SP2 didn't git it fixed.

Patrick
Post by Patrick Seeber
for a period of time, I hijacked a user's WS.
Initially, I had the issue of not being able to save changes. WS was
correctly mapped to the primary DFS/DFS-R local server. Both Excel and
Word exhibited the cannot save, cannot file/save as any changes to a file.
I did check the WS updates status, and no updates were pending for MS
Office - XP, .NET updates for 1.1, 2.0, and 3.0 were ready. Only the .NET
1.1 updates have been applied. In our environment, .NET 2.0 and 3.0 are
not fully approved on our WS.
Suddenly, even before the updates were applied, everything began to
function just as it should and all changes were saved, regardless of
method of saving or opening of files.
This appears to be "intermittent" at this point. The other possibilities
could be network latency, or server load based in some manner. We are
pretty much Gig Ethernet desktop to server.
3 sites, all connected by private T-1 to each other. All reside in the
same domain, and sites are defined and the different subnets are correctly
described.
All 3 servers are in multiple namespaces. This particular namespace -
home - is the only known area of issue (so far) Referral order is
Overridden - S1 is local and the first among all targets. S2 is off site
and last among targets of equal cost, S3 is last among all targets.
Today, everyone seems to be assigned the proper primary server S1.
Primary Server Specs - Server 2003 R2 SP2 - I assume hot fixes are rolled
up and I am current on "patches". The Home namespace resides on a RAID5
drive C:. System memory is 3Gb. XEON 2.8Ghz processor, hyperthreaded I
suspect. Performance monitor reveals periods of rather high disk queue
length counters - these do not sustain for any extended duration....
What else do you need to know? This is becomig a big deal around here...
I appreciate the assistance!
Patrick
Post by Patrick Seeber
Hello Jeff,
As of last night we are now 2003 R2 SP2
I have one user who still hasn't seen any improvement already. Open
excel file, make change, save as, new name, close, re-open, reverted to
original version.
New versions - 2 of them - show up in the local, primary server conflict
and deleted... still searching on the other 2 servers...
Patrick
Post by Jeff Vandervoort
Are you on WS2003 R2/SP1, R2/SP1 + any of the hotfixes mentioned in the
thread, or R2/SP2?
--
Jeff Vandervoort
JRVsystems
Post by Patrick Seeber
Really glad I have found this thread. I have been battling this issue
heavily since last week...
Our site topology is multiple servers at 3 sites for BCP purposes only.
The remote sites are not manned, and there should be no reason for this
issue to be occurring - the other sites should only be catching the
changed files from the primary site. It is a mesh configuration using
private T-1's for replication. Bandwidth is not now, nor has it been,
an issue.
Been thinking that this could be a "site latency" issue - primary site
is most heavily used, no one at the 2 other target sites to change
files, only files that are changing are at the primary server site.
This may have been validated over the past weekend. A weekend user
reported no "file save as" issues on any files while they were the only
user working. Still don't have a for sure reason on this.
Errors saving files have already been reported by staff today, after an
uneventful weekend.
Hope to see an easy fix on this soon!
Patrick
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server
will be moved to a branch office (different AD site), at which point
we will be using DFSR to back up the branch office's data using the
main office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all
referrals to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of
files were overwritten with old versions. And, again, after the
non-referral server was back up, got the same reports. Previous
Versions is enabled on both servers; users were able to restore
correct versions from Previous Versions. That also tells me this is
not a problem with closing the file without saving it...this is a
system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others).
We are getting the message cited by "dan0". I gather we need this
hotfix if only because we have .XLS files, but is the hotfix specific
to the issue of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few
hours before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Jeff Vandervoort
2007-04-24 16:52:52 UTC
Permalink
Patrick
Post by Patrick Seeber
As of last night we are now 2003 R2 SP2
I have one user who still hasn't seen any improvement already.
That's discouraging...I was planning on recommending to the client that we
upgrade to SP2 to see what happens. Esp. since I haven't been able to
reproduce the problem myself, making testing tough.

In my case, it's not intermittent; it's quite predictable: When the server
to which referrals are disabled is down for a time, or the network
connection to it is lost, files roll back to old version when everything's
back up. (Except all works smoothly when I deliberately disconnect the
server for testing purposes!)
--
Jeff Vandervoort
JRVsystems
Post by Patrick Seeber
Hello Jeff,
As of last night we are now 2003 R2 SP2
I have one user who still hasn't seen any improvement already. Open excel
file, make change, save as, new name, close, re-open, reverted to original
version.
New versions - 2 of them - show up in the local, primary server conflict
and deleted... still searching on the other 2 servers...
Patrick
Post by Jeff Vandervoort
Are you on WS2003 R2/SP1, R2/SP1 + any of the hotfixes mentioned in the
thread, or R2/SP2?
--
Jeff Vandervoort
JRVsystems
Post by Patrick Seeber
Really glad I have found this thread. I have been battling this issue
heavily since last week...
Our site topology is multiple servers at 3 sites for BCP purposes only.
The remote sites are not manned, and there should be no reason for this
issue to be occurring - the other sites should only be catching the
changed files from the primary site. It is a mesh configuration using
private T-1's for replication. Bandwidth is not now, nor has it been,
an issue.
Been thinking that this could be a "site latency" issue - primary site
is most heavily used, no one at the 2 other target sites to change
files, only files that are changing are at the primary server site.
This may have been validated over the past weekend. A weekend user
reported no "file save as" issues on any files while they were the only
user working. Still don't have a for sure reason on this.
Errors saving files have already been reported by staff today, after an
uneventful weekend.
Hope to see an easy fix on this soon!
Patrick
Post by Jeff Vandervoort
2 WS2003 R2 servers with a DFS namespace containing a DFSR-replicated share.
Currently, the 2 servers are on the same AD site. Soon, one server will
be moved to a branch office (different AD site), at which point we will
be using DFSR to back up the branch office's data using the main
office's server.
DFS referrals are enabled to only 1 of the 2 shares, ensuring
(theoretically) that users are using only the one server. The DFS
partner to which referrals are currently enabled is the main office's
server. When the branch office is deployed, I will change all referrals
to the branch office server.
The DFS share is in production. During a 2.5-day outage of the server
that is NOT enabled for referrals, users reported new versions of files
were overwritten with old versions. And, again, after the non-referral
server was back up, got the same reports. Previous Versions is enabled
on both servers; users were able to restore correct versions from
Previous Versions. That also tells me this is not a problem with
closing the file without saving it...this is a system problem.
1. Still gathering info, but at least some of the files were .XLS
files. This thread--
http://groups.google.com/group/microsoft.public.windows.server.dfs_frs/browse_frm/thread/ee0f3ba09543ebeb/c4490042866db0a7?lnk=st&q=%22not+all+files+in+dfs+namespace+replicating+correctly%22&rnum=1&hl=en#c4490042866db0a7
--implies that there is a known issue with .XLS files (among others).
We are getting the message cited by "dan0". I gather we need this
hotfix if only because we have .XLS files, but is the hotfix specific
to the issue of new files being overwritten with obsolete versions?
2. Is there any other reason why new files on the main office server
(referrals enabled) could be overwritten by old files from the branch
office server (referrals disabled) after it was brought online?
3. The server will be down at least twice more for at least a few hours
before it is put in production at the branch office. Can this be
prevented from happening again?
--
Jeff Vandervoort
JRVsystems
Continue reading on narkive:
Loading...