Replacing DFSR Member Hardware or OS (Part 5: Reinstall and Upgrade)

Article
09/10/2010

Hello folks, Ned here again. Previously I explained how swapping out existing storage can be a method to migrate an existing DFSR environment to new hardware or operating system. Now in this final article I will discuss how reinstallation or an in-place upgrade can be used to deploy a later version of DFSR. Naturally this will not allow deployment of improved hardware and instead relies on existing infrastructure and storage.

Make sure you review the first four blog posts before you continue:

Background

The “reinstallation” method makes use of existing server hardware and storage by simply reinstalling the operating system. It does not require any new equipment expenditures or deployment, which can be very cost effective in a larger or more distributed environment. It also allows the use of later OS features without a time consuming or risky in-place upgrade. It also provides DFSR data pre-seeding for free, as the files being replicated are never removed. Previous OS versions and architectures are completely immaterial.

The downside to reinstallation is a total outage on that server until the setup and reconfiguration is complete, plus DFSR must be recreated for that server and perhaps for the entire Replication Group depending on the server’s place in data origination.

The “in-place upgrade” method also makes use of existing hardware by upgrading the existing operating system to a later version. This is also an extremely cost effective way to gain access to new features and also lowers the outage time as replication does not have to be recreated or resynchronized; once the upgrade is complete operation continues normally.

On the other hand upgrades may be impossible as 32-bit Win2003/2008 cannot be upgraded to Win2008 R2. As with any upgrade, there is some risk that the upgrade will fail to complete or end up in an inconsistent state, leading to lengthier troubleshooting process or a block of this method altogether. For that reason upgrades are the least recommended.

Requirements

For computers being reinstalled with a later OS there are no special requirements.
For computers being upgraded, they must meet the requirements for an in-place upgrade.

Note: A full backup with bare metal restore capability is highly recommended for each server being replaced. A System State backup of at least one DC in the domain hosting DFSR is also highly recommended.

For more information on installing Windows Server 2008 R2, review: https://technet.microsoft.com/en-us/library/ee344846(WS.10).aspx

Repro Notes

In my sample below, I have the following configuration:

There is one Windows Server 2003 R2 SP2 hub (HUB-DFSR) using a dedicated data drive provided by a SAN through fiber-channel.
There are two Windows Server 2003 R2 SP2 spokes (BRANCH-01 and BRANCH-02) that act as branch file servers.
Each spoke is in its own replication group with the hub (they are being used for data collection so that the user files can be backed up on the hub, and the hub is available if the branch file server goes offline for an extended period).
DFS Namespaces are generally being used to access data, but some staff connect to their local file servers by the real name through habit or lack of training.
The replacement OS is Windows Server 2008 R2. After installation – or as part of its slipstreamed image if possible - it will have the latest DFSR hotfixes installed.

I will upgrade one branch server and reinstall the other branch server. Because of the upgrade process clustering is not possible, but it would be in a reinstallation scenario.

Procedure

Note: this should be done off hours in a change control window in order to minimize user disruption. If the hub server is being replaced there will be no user data access interruption in the branch. If a branch server being upgraded is accessed by users however, the interruption may be several hours while the upgrade or reinstallation takes place. Replication - even with pre-seeding – may take substantial time to converge if there is a significant amount of data to check file hashes on in the reinstallation scenario.

Reinstallation

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 proceed to the next step.

6. Start the OS installation either within the running OS or from boot up (via media or PXE).

7. Select a “Custom (advanced)” installation.

8. Specify the old volume where Windows was installed and accept the warning.

Note: When the installation commences all Windows, Program Files, and User Profile folders will be moved into a new Windows.old folder. Other data folders stored on the root of any attached drives will not move – this includes any previously replicated files.

Critical note: Do not delete, recreate, or format any drive containing previously replicated data!

9. When the installation completes and the server allows you to logon with local credentials, rename it to the old computer name and join it to the domain.

10. Install the DFSR role and install latest patches described in https://support.microsoft.com/kb/968429.

11. 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.

12. 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.

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.

13. 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.

14. 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.

15. Force AD replication with REPADMIN / SYNCALL and DFSR polling with DFSRDIAG POLLAD.

16. When the server has logged a DFSR 4104 event (if non-authoritative) then replication is completed.

17. Validate replication with a test file.

18. Grant users access to their data by configuring shares to match what was used previously on the old server.

19. 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.

20. The process is complete.

Upgrade

1. Start the OS installation either within the running OS or from boot up (via media, WDS, SCCM, etc). Be sure to review our recommendations around in-place upgrades: https://technet.microsoft.com/en-us/library/dd379511(WS.10).aspx.

2. Select “Upgrade” as the installation type.

3. Allow the installation to commence.

4. When the installation has completed and you are able to log back on to the computer with domain credentials, DFSR will commence functioning normally as it had on the previous OS. There is no need for further configuration or topology changes. There will be no new initial sync.

5. Creating a new test file in the replication groups on the upgraded server will sync to all other servers without issue, regardless of their current OS.

6. At this point the process is done.

Final Notes

While treated with suspicion due to the complexity and poor experiences of the past, upgrades are fully supported and when they operate smoothly they are certainly the lowest effort method to deploy a newer server OS. With changes in servicing and disk imaging starting in Windows Server 2008, they are also less likely to have lingering effects from previous OS files and settings.

However, reinstallation also gets you a newer OS and that install type is guaranteed not to have lingering effects from a previous OS installation. With a small amount of extra work, a reinstallation becomes a better long term solution with fewer questions around supportability, all while re-using existing hardware and data.

This concludes my series on replacing hardware and operating systems within a given set of DFSR Replication Groups. I hope you’ve found it helpful and illuminating. Now I can go back to being slightly crass and weird in my writing style like usual. :)

Series Index

- Ned “off to find freakish clipart” Pyle