Transferring Windows Server roles to a new server, Part I DFS
TL;DR: how to migrate one of the servers hosting DFS without affecting service.
Welcome to Part I of our PDC & DFS migration!
Part I: DFS
Part II: FSMO roles
Part III: Setup the new PDC
I am not a terribly original or creative individual. None of this information is new. As shown in the references at the bottom it is all available elsewhere. This simply puts the pieces together in one place to show how to stand up a new fileserver, add it to an existing DFS namespace & replication, and then remove the original file server so that it can be decommissioned. DFS allows the administrator to do this without the users even noticing. This is Part I, migrating other roles are in follow up parts.
The Distributed File System (DFS) is a nice feature for two simple reasons. It allows an administrator to create a DFS namespace and map it to multiple shared folders on multiple different servers. Additionally the administrator can configure those DFS Folder Targets to replicate. Once this is done users can simply navigate to the I Drive that is auto-mapped by GPO, while behind the scenes DFS is taking care of redundancy. The users will not notice if one of the servers goes down.
Our lab’s setup
For some background, the lab’s Windows domain is setup with a couple Domain Controllers, DNS, Distributed File System (DFS) with replication, one or two Windows 10 clients, some OUs, a couple users, the Local Admin Password Solution (LAPS), and some Group Policy Objects (GPOs) to standardize the systems. It is best to also have a handy method to transfer the roles to a new DC and the ability to decommission the original DC without bringing down the lab.
Everyone’s setup varies, but for the purposes of this write up I am running the environment off the free version of VMware ESXi and using Windows Server 2016, 2019, and Windows 10 Professional. The free version of ESXi can be managed through a web browser, but with Windows VMs and RDP this isn’t really a limitation. PSSession also aids remote administration without needing to rely on an ESXi console.
If the soon to be decommissioned VM is hosting one of those DFS Target Folders simply create a new shared folder on the replacement server and add it to the DFS replication. In this case I am using the Test Share I created in DFS to host installation packages for things like LAPS and some simple setup scripts I run on new domain systems. I mapped it to the I Drive on all domain systems via GPO.
In this case there are two Windows Server 2016 VMs named TestDC & BackupDC and one Windows Server 2019 VM named BackupDC3. The domain is test.local. The DFS namespace is test.local\Mishky’s Share. The subfolder being worked with is Test Share. BackupDC3 is being added so that TestDC can be removed later.
PowerShell is being used for several reasons. The primary rationale is that the first time these configurations are performed in a lab it involves a bit of trial & error and consulting CW6 Google. With PowerShell and the lowly Notepad though, commands can be copy/pasted back and forth and saved. This greatly simplifies the task the next time around, even if one doesn’t script it.
The other reason is that Microsoft expects one to know and use Server Core and PSSession.
Setup the new server
For simplicity’s sake I RDPed into the new server, BackupDC3, and ran PowerShell as an admin. First create the folder on the new server, share it, and set share permissions (the default is to give Everyone Read). Either RDP and run PowerShell as admin or PSSession into the new server and copy/paste:
New-Item “C:\Test Share” -ItemType directoryNew-SMBShare -Name “Test Share” -Path “C:\Test Share”Revoke-SMBShareAccess -Name “Test Share” -AccountName Everyone -ForceGrant-SMBShareAccess -Name “Test Share” -AccountName “test\Domain Admins” -AccessRight Full -ForceGrant-SMBShareAccess –Name “Test Share” -AccountName “test\Domain Users” -AccessRight Read -Force
Please note, the ‘-Force’ stops PowerShell from prompting and just changes the permissions.
Then set the NTFS permissions easily by simply copying them from the soon to be decommissioned server:
Get-ACL “\\TestDC\Test Share” | Set-ACL “\\BackupDC3\Test Share”
Verify the Share and NTFS permissions, run from the new server:
(Get-ACL -Path “C:\Test Share”).Access | Format-Table -AutoSizeGet-SMBShareAccess -Name “Test Share”
Please note, I use Test Share simply for hosting install packages, some setup scripts, etc, hence the permissions. Your mileage may vary. Share permissions of course can be set to Read, Change, or Full Control. NTFS permissions are much more granular, there’s a handy table that can be put into a PowerShell commands here.
Alternatively, if a script is preferred over manually changing the folder & ComputerNames and doing a copy/paste:
#Prep a new folder for adding to an existing DFS namespace$NewServer = Read-Host “Please enter the computername of the new server. Example: BackupDC3”$NewDirPath = Read-Host “Please enter the new folder’s path on the new server. Example: C:\Test Share”$NewDirName = Read-Host “Please enter the new folder’s share name. Example: Test Share”$OldFolder = Read-Host “Please enter an existing DFS target folder to clone permissions. Example: \\TestDC\Test Share”New-Item $NewDirPath -itemtype directoryNew-SMBShare -Name $NewDirName -Path $NewDirPathRevoke-SMBShareAccess -Name “$NewDirName” -AccountName Everyone -ForceGrant-SMBShareAccess -Name $NewDirName -AccountName “test\Domain Admins” -AccessRight Full -ForceGrant-SMBShareAccess –Name $NewDirName -AccountName “test\Domain Users” -AccessRight Read -ForceGet-ACL $OldFolder | Set-ACL \\$NewServer\$NewDirName
Please note that if the above is saved as a *.ps1 rather than copy/pasted into PowerShell ISE and simply run then a ‘Set-ExecutionPolicy Unrestricted’ is required. Obviously after running the *.ps1, set it back to Restricted.
Now that the new folder on the new server is ready, we will simply add it to the DFS Target Folders. I can never remember the feature’s name, so to avoid asking CW6 Google, this time anyway:
This shows the Windows features to install for DFS:
Add-WindowsFeature -Name FS-DFS-Namespace, FS-DFS-Replication -IncludeManagementTools
Add the shared folder on the new server to target folders on the existing DFS namespace:
New-DfsnFolderTarget -Path “\\test.local\Mishky’s Share\Test Share” -TargetPath “\\BackupDC3\Test Share” -ReferralPriorityClass SiteCostNormal
Add the new folder to DFS replication:
Get-DfsReplicationGroup -GroupName “test.local\Mishky’s Share\Test Share” | Get-DfsReplicatedFolder -FolderName “Test Share” | Add-DfsrMember -ComputerName BackupDC3Add-DfsrConnection -GroupName “test.local\Mishky’s Share\Test Share” -SourceComputerName TestDC -DestinationComputerName BackupDC3Set-DfsrMembership -GroupName “test.local\Mishky’s Share\Test Share” -FolderName “Test Share” -ComputerName BackupDC3 -ContentPath “C:\Test Share”
Finally confirm DFS Replication is setup via PowerShell:
Get-DfsReplicationGroup -GroupName “test.local\Mishky’s Share\Test Share” | Get-DfsReplicatedFolder -FolderName “Test Share” | Get-DfsrMembership
It can also be easily checked by running DFS Management in the GUI:
Lastly it is easy to navigate to the folder that we added to the DFS Folder Targets and Replication. The data should have automatically replicated from the existing members to our new server.
Remove the old server
Now it is time to remove the original server, TestDC, from the DFS Folder Targets and Replication. This will leave us with redundancy with the other two servers, BackupDC & BackupDC3, up and running. There are no users in this lab, but if there were they should not notice any interruptions in service.
This last step is rather quick and easy compared to the above. PowerShell is already running as admin so simply:
Remove-DfsnFolderTarget -Path “\\test.local\Mishky’s Share\Test Share” -TargetPath \\TestDC\Test ShareGet-DfsReplicationGroup -GroupName “test.local\Mishky’s Share\Test Share” | Get-DfsReplicatedFolder -FolderName “Test Share” | Remove-DfsrMember -ComputerName TestDC
Then just confirm in the GUI using DFS Manager:
Of course if the administrator changes their mind it is as easy as copy/pasting a couple of commands to add the original DFS Folder Target and Replication back. Removing the original server, TestDC, from DFS does not delete it’s shared folder or the contents thereof. Of course if this was a real network with actual users working in Microsoft Office and modifying files the administrator would want to specify which DFS Folder Target contains the most up to date data:
Set-DfsrMembership -GroupName “\\test.local\Mishky’s Share\Test Share” -FolderName “Test Share” -ComputerName BackupDC -ContentPath “C:\Test Share” -PrimaryMember $trueSet-DfsrMembership -GroupName “\\test.local\Mishky’s Share\Test Share” -FolderName “Test Share” -ComputerName TestDC -ContentPath “C:\Test Share”
In summary, the Distributed File System (DFS) is a nice feature for redundancy behind the scenes. Users can simply double click on the I Drive and don’t have to worry if one server goes down. DFS also makes it easy for administrators to add more file servers and decommission others without bothering the users. They can continue to utilize the same DFS namespace, or even easier the drive letter that a GPO automatically created for them.
This writeup is already getting rather long, so migrating FSMO roles will be covered in a follow up. Following that will be decommissioning the old server, performing a clean install of Windows Server 2019, bringing it back up, and adding it’s roles back to it.
Please note, while many of the old commands still work fine, Microsoft deprecated the term Flexible Single Master Operations (FSMO) in favor of Operations Masters.