This post is really an extension of a previous post here when we discovered an issue of DFS replication after we migrated a client's domain from Win 2016 to Win 2022.
As outlined in that previous post, the migration went without issue until we slowly became aware of these additional issues when updating things like GPOs and them not being replicated between the two domain controllers.
After we discovered the GPOs not replicating properly we tested whether the NETLOGON folders were replicating and they too were affected by this issue. The easiest way to test the replication of the NETLOGON folders is to open two separate Windows File Explorer windows. Then within the address bar of Explorer window one one type in the UNC path like \\server1\netlogon, and in your second Explorer window type in \\server2\netlogon.
Replace the values of server1 and server2 in the examples above with the names of your servers. Now simply copy any file into the first Explorer window and see if it automatically gets replicated to the other server. Also, test by copying a file in the second window and see if that gets replicated to the other server. It's good to test both sides because sometimes you can have one side replicating properly, while the other doesn't. In our case, neither side was replicating. Leave these two windows open because we'll come back to these at the end of this article.
Essentially this typically happens after a server domain migration and in our case, the GC (Global Catalogue) server, which was the Win 2016 domain controller, was demoted to just a DC (Domain Controller) and the new Win 2022 was made the GC. This may have caused this problem, but to be honest, I honestly don't think anyone knows, even Microsoft themselves. So, Let's get to fixing the issue...
Firstly, to see the errors listed on your server, open the Event Viewer and navigate to the location outlined in the screenshot below:
In there you will typically find numerous errors and warning pertained to failed replications with error numbers ranging from 4612, 5002, 5014, 5614...... In our case the main issue was that the server was waiting for the initial replication.
We're going to be working within ADSI Edit MMC, so please ensure you have a verified server backup image in case you accidentally change some values that completely muck up your server configuration. This is VERY IMPORTANT, so don't proceed before doing this.
With that said, the steps outlined below will help you complete the rectification process. Please note, the server names in our case were RDSSB (Old Win 2016 server) and DNDSVR (New Win 2022 Server).
Open the Services MMC on both servers and stop the DFS Replication service as outlined in the screenshot below:
You can also stop the DFSR services on multiple servers by using PowerShell using the syntax below. This saves having to log onto multiple servers.
Get-Service -ComputerName rdssb -Name DFSR | Stop-Service
Replace rdssb in the example above with the server name on which you wish to stop the service.
No we're going to open the ADSI Edit MMC by opening Server Manager > Tools > ADSI Edit. In the screenshot below, you'll see the location of the SYSVOL Subscription item we're going to edit to make the system start replicating again.
Firstly, we're going to be working on the server we're planning on making the master or primary which in our case is the new Win 2022 server named DNDSVR. Double click the SYSVOL Subscription item to edit it and follow the screenshot below:
Now, we're going to be working on the server we're planning on making the fallback or secondary which in our case is the old Win 2016 server named RDSSB. Remember, you will need to do this for all the domain controllers in your environment. As outlined, in our case we only had two, but your environment may be different, so take that into account.
Go back to your ADSI Edit window and navigate to the Domain System Volume folder of the secondary server. Double click the SYSVOL Subscription item to edit it and follow the screenshot below:
We're now ready to replicate from our primary server to all other domains. Open a PowerShell windows as an Administrator and we're going to run a forced replication from DNDSVR. The command we're going to use is repadmin and you can learn more about the switches we used here... The command we used is as follows:
repadmin /sycall DNDSVR /AdePq
To summarise the /AdePq switch above:
/A Synchronizes all naming contexts that are held on the home server.
/d Identifies servers by distinguished name in messages.
/e Synchronizes domain controllers across all sites in the enterprise. By default, this command does not synchronize domain controllers in other sites.
/P Pushes changes outward from the specified domain controller.
/q Runs in quiet mode, which suppresses call back messages.
Replace DNDSVR in the syntax above to reflect the name of the server that you've nominated as the primary server. This is very important because this server will be used as the gold standard for the domain and everything from it will be replicated to all member domain controllers. Things like the NETLOGON folder and GPOs etc.
Once the PowerShell command is complete, scroll through the results in the PowerShell window to ensure the you have no replication errors. Once confirmed we can move onto the final steps.
Go back to your ADSI Edit windows and for both servers we're going to edit the SYSVOL Subscription like the following screenshot:
Make sure you do this for ALL your servers in the ADSI Edit MMC. Once complete, you can now start the the DFSR service on all your server via the PowerShell command line. The example uses the two severs in our environment:
Get-Service -ComputerName dndsvr -Name DFSR | Start-Service
Get-Service -ComputerName rdssb -Name DFSR | Start-Service
We've essentially completed the process now, so to test all we have to do is go back to our two Windows File Explorer windows we had open at the beginning of this article to see whether the replication service is working. Copy a file into the first window and check whether it gets replicated to the other and vice versa. Also, test whether when you delete a file from one, it should be deleted from the other and vice versa.
You can also test by creating or editing GPOs on both servers. When you add or edit a GPO in one, those changes should be reflected automatically on all the other servers in your environment.
Hopefully this has helped you rectify your replication issues in your environment.
If you've found this useful, you may want to sign up to our newsletter where you'll receive notices on when we post new articles and helpful "how tos". Just fill out your details below and we'll do the rest…
