bts86
asked on
DFS stopped working after server restore
I recently restored a file server using a bare metal restore. On the surface all seemed well.
Days later I have noticed that DFS replication to another server is not functioning. There are no errors in either servers event logs. There are only 2 servers in the replication group.
Running a propagation test from either server results in the following error: (fs02 is the server that was restored)
There are also errors and warnings in a health report:
This error was on the other server:
This warning on the restored server:
It seems like a permissions issue, but im not sure what permissions need to be checked. I did find something strange though on the restored server. The permissions for the dfsrprivate folder matched the other server but the folder icons themselves show a lock over the folder. Also the staging folder and its subfolders size shows 0 bytes even though if you go into the subfolders, there are frx files with sizes greater then 0 bytes.
Days later I have noticed that DFS replication to another server is not functioning. There are no errors in either servers event logs. There are only 2 servers in the replication group.
Running a propagation test from either server results in the following error: (fs02 is the server that was restored)
Replication group Office Share, replicated folder Shared Folders on member fs02.xxx.local: A new propagation test file cannot be created. Cannot create propagation test folder under replicated folder. Access is denied.
There are also errors and warnings in a health report:
This error was on the other server:
Inconsistent configuration detected (invalid object).
Affected replicated folders: All replicated folders on this server.
Description: The DFS Replication service detected invalid msDFSR-Subscriber object data while polling for configuration information. Additional information includes Object DN: CN=8b791ae3-9f27-4b22-bdab
Last occurred: Monday, December 29, 2014 at 10:41:13 AM (GMT-5:00)
Affected replicated folders: All replicated folders on this server.
Description: The DFS Replication service detected invalid msDFSR-Subscriber object data while polling for configuration information. Additional information includes Object DN: CN=8b791ae3-9f27-4b22-bdab
Last occurred: Monday, December 29, 2014 at 10:41:13 AM (GMT-5:00)
This warning on the restored server:
WARNINGS (There is 1 warning to report)
Reference member returned no replicated folders.
Description: Backlog calculations cannot be performed because the reference member returned zero replicated folders.
Last occurred: Monday, December 29, 2014 at 11:29:23 AM (GMT-5:00)
Suggested action: For information about troubleshooting backlog problems, see The Microsoft Web Site.
Reference member returned no replicated folders.
Description: Backlog calculations cannot be performed because the reference member returned zero replicated folders.
Last occurred: Monday, December 29, 2014 at 11:29:23 AM (GMT-5:00)
Suggested action: For information about troubleshooting backlog problems, see The Microsoft Web Site.
It seems like a permissions issue, but im not sure what permissions need to be checked. I did find something strange though on the restored server. The permissions for the dfsrprivate folder matched the other server but the folder icons themselves show a lock over the folder. Also the staging folder and its subfolders size shows 0 bytes even though if you go into the subfolders, there are frx files with sizes greater then 0 bytes.
arnold
the error says it all. you should use robocopy to make sure that there were no recently created files on the recently restored server that have been modified. If there were copy the ones that have changed to the "functional" member repeat for every share. file level backup of the share/s on the restored system. Then using the non-restored member as a reference, reconfigure the DFS replication group for each share. This should reset the referencing and replication will resume.
ASKER
I backed up both server and re-synced data using a 3rd party program then deleted the replication group and re-created it.
I am still getting the same errors when I run diagnostic reports and nothing copies between servers.
I am still getting the same errors when I run diagnostic reports and nothing copies between servers.
A reset of the replication group is what will lead to the synchronization of the references.
There is also a lag time between the update of the DFS-R into the AD and when it is seen by the dfs-r members.
use dfs management and verify topology.
The errors will likely continue until the pre-existing files on both ends are rechecked.
The other option is often to remove one of the existing replication members. waiting for 20-30 minutes, and adding it back with one way replication from existing member to the newly added one. Then revalidate topology to establish the two way communications.
When you see the errors in the diagnostic report does it deal with missing files from the existing to the recently restored, or the other way around, i.e. missing files from the restored not being copied to the member that was functional during the restore of the other.
There is also a lag time between the update of the DFS-R into the AD and when it is seen by the dfs-r members.
use dfs management and verify topology.
The errors will likely continue until the pre-existing files on both ends are rechecked.
The other option is often to remove one of the existing replication members. waiting for 20-30 minutes, and adding it back with one way replication from existing member to the newly added one. Then revalidate topology to establish the two way communications.
When you see the errors in the diagnostic report does it deal with missing files from the existing to the recently restored, or the other way around, i.e. missing files from the restored not being copied to the member that was functional during the restore of the other.
ASKER
Files are not being copied in either direction.
Right now I've removed one of the targets from its namespace so that I have everyone working on one server at least.
Ill give it some time and see if everything updates. If not, ill try re-adding the member I removed from the namespace as a one-way and see if it starts working.
Could it also be a bad entry in AD and could rejoining the servers to the domain be a possible fix?
Right now I've removed one of the targets from its namespace so that I have everyone working on one server at least.
Ill give it some time and see if everything updates. If not, ill try re-adding the member I removed from the namespace as a one-way and see if it starts working.
Could it also be a bad entry in AD and could rejoining the servers to the domain be a possible fix?
DFS has two components the published side that deals with the access. and the replication side that deals with keeping the two synchronized.
Remove the member that youjust restored from the replication group presumably you've already removed it from the published group.
Let the changes propagate tomorrow, check on the DFS tab in one of the clients to make sure this DFS is listing only the member/s that were not restored.
At this time, go through the replication group and add the recently restored member to the replication group with the existing member as the master against whom the contents would be validated.
if your OS is 2008 and newer, look at the dfsutil to resolve these errors if the above procedure does not resolve it.
Remove the member that youjust restored from the replication group presumably you've already removed it from the published group.
Let the changes propagate tomorrow, check on the DFS tab in one of the clients to make sure this DFS is listing only the member/s that were not restored.
At this time, go through the replication group and add the recently restored member to the replication group with the existing member as the master against whom the contents would be validated.
if your OS is 2008 and newer, look at the dfsutil to resolve these errors if the above procedure does not resolve it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Glad all went well , was it all smooth?
ASKER
yes, it seemed the database was bad on the restored server. After it rebuilt itself, replication began to work again