Using DFSRMIG to move to from FRS to DFSR for Sysvol
-
Yeah, SMB v1, and file server and app server that will be migrated soon.
-
@texkonc How did it go after 5 days?
-
Everything is humming along fine. Only thing I can see that changed is that the backups (hourly continuous) on one of the older DC's that is also a file server for CAD engineers is very very busy and get the VSS lock pausing replication. the error just says it paused for backups or restores. My only concern with that is replication issues leading to tombstone. I want to try and get them to approve pulling the DC role from it and making it a seperate DC at that remote site. It is delayed for a while since its pushing through a site to site vpn.
-
roles are now transfered to the new DC. we can worry about that other server later.
-
@texkonc Awesome, DCs is pretty good to have it on its own.
-
@texkonc Are you using Shadow copies on this server?
-
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.
