We went to DCPromo a newly stood up Windows Server 2019 VM into an existing domain and it would not let us do so.
Suffice it to say, we needed to migrate File Replication Service (FRS) to Distributed File System Replication (DFSR).
The process is actually quite simple so long as Active Directory and replication are healthy.
Ned Pyle has an article that has three methods in it:
We followed method one as a just-in-case during business hours. No hiccups were experienced and once done:
A simple way to keep an eye on things is to open File Explorer and plug the following in the Address Bar: \\Domain.Com
So long as DNS is healthy and SYSVOL and NETLOGON are there the process is humming along as expected.
NOTE: Make sure a backup is taken of the PDCe and a System State as well!
Philip Elder
Microsoft High Availability MVP
MPECS Inc.
Co-Author: SBS 2008 Blueprint Book
www.s2d.rocks !
Our Web Site
Our Cloud Service
1 comment:
Hi Phillip,
I've been a little surprised how 'quiet' articles have been coming out of MS other than "better consider migrating SYSVOL repl to DFSR, since FRS is (being) deprecated". Knowing there is an abundance of businesses running with FRS in their domains, I was always looking for MS to post an article regarding the options for deploying Server 2016 v1709 or even 2019 in a DC capacity: Would 1709 deploy in the traditional update way (to DCs) and if so, would smarts be built-in to detect the SYSVOL nature of the domain and slam the brakes on? Would an in-place upgrade to Server 2016 v1709 or later detect and abort in the same way (I saw an article once where in-place was still mentioned as an option, without reference or comment to FRS)? Or would the only option be a fresh install of the OS?
At least there is verbiage out there now for those who haven't hit that hurdle yet.
What is clear: People need to not hold their breath in the hope MS will automate the migration. That would require gambling with way too many assumptions.
When it comes to the actual migration from FRS to DFS-R, I've performed a good number. Ned's 'streamlined' article is one I would pass on to customers or consultants where performing a migration was out of scope or required more attention than time allowed. Ned Pyle is always a fun read or presenter ... even if he is a flaming lib! :)
OK - really to my point for leaving a comment:
In its easiest implementation, as you stated, migrating from FRS to DFSR is very straight-forward. What IS important and worth emphasising is ensuring ALL prerequisites are met BEFORE even considering changing the 'state'.
Personally, even with prerequisites being met, I absolutely still step through the migration phases/states incrementally. The one time I specified state 3 and let the tool handle states 1 & 2 without stopping (just for laughs ... in a private lab environment with only 2 DCs) ... sure enough the non-PDCe failed.
I've a 100% success rate stepping through states 1, 2, and 3 individually/incrementally. Where more than 1 DC is in play, patience is needed. Even more patience the more hops with AD replication. There can be significant time savings forcing replication / forcing DFSR to read from AD, but I strongly recommend not proceeding with the next state until the status is reported as healthy after triggering each state.
Finally, I've wondered about the timing of maybe starting with some gigs on the side. You're an example of someone who has gone with 2019 DCs with a domain still reliant on FRS and undoubtedly there is plenty of earning potential with each passing day as more adopt 2016 v1709+ or 2019. And importantly, MANY are not technically equipped with AD knowledge and should not even try migrating themselves - Lord knows I've dealt with enough IT consultant that had no business attempting it.
Ned's article links to the 52 page document that it was based off. Dry reading, but fun for some. Even though the streamlined version will get you there, an understanding of what's going on behind the scenes might be a good thing.
-Stuart Rowe
Working with AD since Server 2000.
Post a Comment