1. Inventory your file servers that are being replaced during the migration. Note down server names, IP addresses, shares, replicated folder paths, and the DFSR topology. You can use IPCONFIG.EXE , NET SHARE , and DFSRADMIN.EXE to automate these tasks. DFSMGMT.MSC can be used for all DFSR operations.
2. Stop further user access to the old file server by removing the old shares.
Note : Stopping the Server service with command NET STOP LANMANSERVER will also temporarily prevent access to shares.
3. Remove the old server from DFSR replication by deleting the Member within all replication groups. This is done on the Membership tab by right-clicking the old server and selecting “Delete”.
4. Optional, but recommended: Use REPADMIN /SYNCALL and DFSRDIAG POLLAD to force AD replication and polling of configuration changes to occur faster in a widely distributed environment.
5. When the server being removed has logged a DFSR 4010 event log entry for all RG’s it was participating in, the storage being replicated previously can be disconnected from that computer.
6. Rename the replacement server to the old server name. Change the IP address to match the old server.
Note: This step is not strictly necessary, but provided as a best practice. Applications, scripts, users, or other computers may be referencing the old computer by name or IP even if using DFS Namespaces. If it is against IT policy to use server names and IP addresses instead of DFSN – and this is a recommended policy to have in place – then do not change the name/IP info; this will expose any incorrectly configured systems. Use of an IP address is especially discouraged as it means that Kerberos is not being used for security.
7. Bring the new replacement server or cluster online and attach the old storage. Verify files are accessible at this point before continuing with DFSR-specific steps.
Note: newly attached storage that each volume will have previous DFSR configuration info stored locally, including a database and other folders:
8. Remove the old DFSR configuration folder before configuring DFSR on the replacement server. This requires you delete via a CMD prompt using the RD command as Windows Explorer does not allow file deletion in this folder:
RD “<drive>:\system volume information\DFSR” /s /q
Critical note : this step is necessary to prevent the DFSR service from using previous database, log, or configuration data on the new server and potentially overwriting data incorrectly or accidently causing spurious conflicts. It must not be skipped.
It is also important to note that the "\system volume information" folder is ACLed only to allow SYSTEM access to it, but that all subfolders are ACLed with the built-in Administrators group. If you want to browse or DIR the SVI folder directly, you must add your permissions to it after taking ownership. If you just want to delete its contents directly, you can, thanks to having the Bypass Traverse Checking privilege.
9. Add the new server as a new member of the first replication group if this server is a hub being replaced and is to be considered non-authoritative for data.
Note: For steps on using DFSR clusters, reference:
- Deploying DFS Replication on a Windows Failover Cluster – Part I
- Deploying DFS Replication on a Windows Failover Cluster – Part II
- Deploying DFS Replication on a Windows Failover Cluster – Part III
Critical note : if this server is the originating copy of user data – such as the branch server where all data is created or modified– delete the entire existing replication group and recreate it with this new server specified as the PRIMARY . Failure to follow this step may lead to data loss, as the server being added to an existing RG is always non-authoritative for any data and will lose any conflicts.
10. Select the previously replicated folder path on the replacement server.
Note : Optionally, you can make this a Read-Only replicated folder if running Windows Server 2008 R2. This must not be done on a server where users are allowed to create data.
11. Complete configuration of replication. Because all data already existed on the old server’s disk that was re-used, it is pre-seeded and replication should finish much faster than if it all had to be copied from scratch.
12. Force AD replication and DFSR polling.
13. When the server has logged a DFSR 4104 event (if non-authoritative) then replication is completed.
14. Verify that servers are replicating correctly by creating a propagation test file using DFSRDIAG.EXE PropagationTest or DFSMGMT.MSC ’s propagation test.
15. Grant users access to their data by configuring shares to match what was used previously on the old server.
Note : This step is recommended after replication to avoid complexity and user data changing while initial sync is being performed. If necessary for business continuity, shares can instead be made available at the phase where the replacement server was brought online.
16. Add the new server as a DFSN link target if necessary or part of your design. Again, it is recommended that file servers be accessed by DFS namespaces rather than server names. This is true even if the file server is the only target of a link and users do not access the other hub servers replicating data.
17. The process is complete.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.