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. Bring the new DFSR server online.
3. Optional but recommended : Pre-seed the new server with existing data from the hub.
Note : for pre-seeding techniques, see Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)
4. Add the new server as a new member of the first replication group.
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
5. Select the server being replaced as the only replication partner with the new server. Do not select any other servers.
6. Create (or select, if pre-seeded) the new replicated folder path on the replacement server.
Note : Optionally, you can make this a Read-Only replicated folder if running Windows Server 2008 R2. Make sure you understand the RO requirements and limitation by reviewing: http://blogs.technet.com/b/askds/archive/2010/03/08/read-only-replication-in-r2.aspx
7. Complete the setup. Allow AD replication to converge (or force it with REPADMIN.EXE /SYNCALL ). Allow DFSR polling to discover the new configuration (or force it with DFSRDIAG.EXE POLLAD ).
8. At this point, the new server is replicating only with the old server being replaced.
9. When done, the new server will log a 4104 event. If pre-seeding was done correctly then there will be next to no 4412 conflict events (unless the environment is completely static there are likely to be some 4412’s, as users will continue to edit data normally).
10. Repeat for any other Replication Groups or Replicated folders configured on the old server, until the new server is a configured identically and has all data.
1. Select the Replication Group and create a “New Topology”.
2. Select a hub and spoke topology.
Note: You can use a full mesh topology with customization if using a more complex environment.
3. Make the new replacement server the new hub. The old server will act as a “spoke” temporarily until it is decommissioned; this allows for it to continue replicating any last minute user changes.
4. Force AD replication and DFSR polling again. Verify that all three servers are replicating correctly by creating a propagation test file using DFSRDIAG.EXE PropagationTest or DFSMGMT.MSC ’s propagation test.
5. Create folder shares on the replacement server to match the old share names and data paths.
6. Repeat these steps above for any other RG’s/RF’s that are being replaced on these servers.
Note : this phase is the only one that potentially affects user file access. It should be done off hours in a change control window in order to minimize user disruption. In a reliably connected network environment with an administrator that is comfortable using REPADMIN and DFSRDIAG to speed up configuration convergence, the entire outage can usually be kept under 5 minutes.
1. 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.
2. 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”.
3. Wait for the DFSR 4010 event(s) to appear for all previous RG memberships on that server before continuing.
4. At this point the old server is no longer allowing user data or replicating files. Rename the old server so that no accidental access can occur further. If part of DFS Namespace link targeting, remove it from the namespace as well.
5. 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.
6. Force AD replication and DFSR polling. Validate that the servers correctly see the name change.
7. 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.
8. Replication can be confirmed as continuing to work after the rename as well.
9. 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.