Using DFSRMIG to move to from FRS to DFSR for Sysvol
-
Yes, we are using RestorePoint for Backups. Somehow is pauses replication. I am assume due to DFSR using VSS?
-
@texkonc That is the most likely issue,
https://community.spiceworks.com/topic/241234-dfs-replication-crashes-every-night-during-backup -
Out of that list I look to only need 4 of them since I have SP1. Clearing it with the client for reboots.
-
@texkonc Awesome!! Hopefully those issues are gone then.
-
I got a Sysvol out of sync warning on one of the older DC's that will be going away. Meh, it is going offline for a week this weekend anyway to verify nothing else breaks. DHCP was moved. Static DNS on the member servers were updated. no critical apps.
My guess is that some network equipment might point to it. -
@texkonc said in Using DFSRMIG to move to from FRS to DFSR for Sysvol:
DHCP was moved. Static DNS on the member servers were updated. no critical apps.
My guess is that some network equipment might point to it.If it is going away then let it be. Too much hassle for a system that is going out.
-
Yup in 24 hours it will be offline for a week, then powered back up and demoted. We need to see what breaks before demoting. No need to spin wheels to try and fix it.
All replication test I have done are clear except for the vss backup issue. -
Got those DFS-R patches listed above installed.
Logged into the server that was complaining \servername\sysvol\domain.com\policies
Added an empty txt file.
UNC to the other DC's same sysvols, its there on both.
Deleted it from one of the newer DC's and the delete was gone across the board.
Next set of backups start in 15 min, so I will check on it in an hour. -
Created a bogus GPO
saw it add on all the sysvol folders.
had to refresh for it to show on the other server.
No permission mis match error.
Deleted GPO.
Gone from all.
So we can say that Sysvol is happy on all 3 servers.
Now here is to hoping the backup pause errors go away.
@dbeato -
@texkonc Awesome, thanks for updating the post.
-
I guess my biggest concern is what is going to happen to AD when we power up the old servers to demote them and drop them from the domain? It wont use the old Data from those DC's right? Since the roles are on one of the new servers, it is the authoritative one and says replicate from me right?
-
@texkonc If it is a big concern, why power them on? Use AD cleanup tools to remove them from AD.
-
@texkonc Seize the FSMo Roles (If any) from the old AD DCs and then as @JaredBusch cleanup AD.
-
@texkonc said in Using DFSRMIG to move to from FRS to DFSR for Sysvol:
I guess my biggest concern is what is going to happen to AD when we power up the old servers to demote them and drop them from the domain? It wont use the old Data from those DC's right? Since the roles are on one of the new servers, it is the authoritative one and says replicate from me right?
Correct, that is the way it should work. And my experience has shown that back in the 2008 days was the case.
The only time that isn't the case is when you bring them up in authoritative restore mode.
-
@texkonc said in Using DFSRMIG to move to from FRS to DFSR for Sysvol:
it is the authoritative one and says replicate from me right?
Actually, unless you have RODCs all the DCs are authoritative for the AD database. The FSMO roles info will be singlely the responsibility of the role holder, but the stuff like usernames/passwords/OU those can be updated on any AD and replicated to any other.
In your case, your online DCs will have the newest copies of things, so the old one won't have anything to send out, only records to receive and update itself.
-
@dbeato said in Using DFSRMIG to move to from FRS to DFSR for Sysvol:
@texkonc Seize the FSMo Roles (If any) from the old AD DCs and then as @JaredBusch cleanup AD.
Roles were cleanly moved before shutdown. No seizing necessary.
