File Server Migration from Failover Cluster to DFS

Hi Everyone,

Most well established companies (essentially.... OLD!), might not be up to date with the newer technologies. they might have a traditional file server, maybe Exchange 2007 or older, Windows XP etc. Although I did already write up some migration How-To's such as Migrating Active Directory or Migrating to Exchange 2013, I thought I would through a How-To guide how to migrate from a traditional File server to DFS infrastructure.

Now, please note... there are many ways to deploy DFS. some recommended, some don't take advantages of everything and some are just "are you out of your mind" type of deployments.

That being said, there is no right or wrong. There is only what fits your needs.
My scenario I will be the following:

Migrating from a File Server (clustered) into a two-DFS server solution.

In this How-To I am assuming the following:

  • You know how to create a cluster (if not, please review this How-To) and how to add a role.
  • You know the basics of what DFS-N and DFS-R do.
  • You're working with a minimum of Windows 2008 R2.
  • The new DFS servers are running Windows 2012 or 2012 R2.
  • you have Domain Admin rights


Overview of DFS

DFS is a "new-age" file server that allows for seamless flexibility, scalability and HA, Fail-over and replication without having anything reconfigured on the End-User side with no downtime! it's all real-time

It uses Active Directory's various features to determine cost,  naming scheme and "advertising".
for example...

Imagine you're mapping a user folder to all your users (a U: drive), in a traditional file server (cluster or not), your UNC path would be \\servername\usershare this is all fine but what is the file server is down? You would have to remap their U: drive to a brand new server.

with a DFS, this isn't an issue. no front-end user action is necessary because the format is the following: \\domain-fqdn\share

What's the advantage? the front-end user doesn't need to have any reconfiguration done. the failover, accessibility and mapping to an individual server is all done in the background. So the user keeps the same configuration all throughout.

Process or Migration:

  1. Install DFS Namespace and Replication on the two dedicated DFS servers.
    • Please keep in mind you need a Domain Functional Level of 2008R2
    • To keep it simple use the GUI in the Server Manager window and add the DFS-N (Namespace) and DFS-R (Replication) roles.
  2. Add DFS replication feature to Windows Clutster VIP
    • Within your Windows Failover Cluster, add a role and select the DFS Replication role.
    • In fact add the DFS-R role to each node of the file server cluster role.
  3. Create replication group between volumes/servers between the Legacy File server and DFS servers. Select the primary source as the Legacy File server.
    • The reason we create a replication group first is to create a live synchronization copy between the live (Legacy) file server and the 2 DFS server. Depending on the amount of files and the various IT resources/circumstances, this could take a while. as in hours for some. You can use mesh type of synchronization and ensure to declare the legacy file server as the "master".
  4. Create namespace.
    • Log into the new DFS server and create a namespace which maps to the synchronized volume. If you have multiple DFS servers which you will deploy for redundancy or lowest cost type of scenario, it will ask you if you'd like to create a replication group on a folder level. Just say no because the whole volume is being synchronized.
  5. Create/add all the U: folders into DFS. (more below....)
  6. Modify startup scripts/GPOs, AD account properties etc to point to DFS Namespace
    • a lot of people have either a startup script in AD that launches and maps their drives for them. 
    • some have the AD properties to map a drive letter to a path
    • Maybe GPO is your option.
    • essentially whatever method you use to map the User drives, ensure you cover all bases and change it to the DFS domain namespace.
After reading point #5, you're thinking..... Yo dude! easier said than done! I have hundreds if not thousands of users! do you expect me to add them one at a time? Forget this! especially since you've been giving us quite the high altitude instructions!

To that I say.... Relax! I got your back!
I have created a few Powershell scripts to help out with this! It will allow you to customize the variables and just run it! of course all I can promise is that they worked for me, I offer no guarantees on your end and test everything prior to just using it blindly.

When I created these scripts, my logic was like this...... we create the shares with Full control to everyone and the Security settings on the folder level (which are replicated over through DFS-R) will manage the folder access as needed.
You can get my powershell script in the text area below. Again.... test first and run at your own risk. I am not responsible for any mishaps. Please copy/paste the text and test script prior to running it (you might have to erase the first and last double quotes in the text)



Now, if you've run this script and you're happy what it does and understand essentially what it tries to do, you can either modify the script to add the DFS target folder on the second DFS file server or copy/paste this script below:




So now your migration live has been made  that much easier ! :)
Essentially we covered (in a somewhat vague manner i admin but it's intentional) the following:

Things to look out for!
DFS is not perfect! infact I do believe that uploading files to a common area where multiple people modify/open it should be SHAREPOINT! but that's not reality.

2 things I have noticed which you need to be on the look out for....

  1. Lock-Files
    • whenever multiple people open a file in the same folder, the 2nd person will get a warning that they can only open it in "Read-Only" mode. this is completely normal. But in DFS you might want to implement a scenario which takes advantage of Active Directory's Site and Services. which means it will direct the user to the closest server geographically located to them as advertised by AD Sites & Services. if a person in server A opens a file that is replicated to server B, the lock files don't synchronize along with them. This causes an issue because if a person opens the same file at Server B, They will have full read-write permissions. essentially you're burning the candle at both ends. NOT GOOD!
  2. DFS Repication.
    • DFS-R has it's advantages. such as live synchronization/replication. Instant failover and no adverse user experiences to the End-User. THIS IS IN THEORY!
    • I have had experiences where DFS-R fails and 3rd party solution needed to be involved.
    • please test adequately before using this method. for migration purposes, It worked like a charm and had no issues what so ever. But do go over the replication and compare that all files replicated over. you might have to run a robocopy command to ensure all files were indeed moved.
    • Replication Database can get corrupted and repairing it, is a giant pain!

All things considered though, DFS is a solid feature in my opinion and there should be no worry in implementing it if it aligns with the company's business requirements.
test, re-test and test again to make sure everything is covered there you go.

Just for the record, I was intentionally vague about the migration process because there are A LOT of ways to implement DFS so i didnt want to give specific instructions because there is a chance they might not apply. But my powershell scripts in most likelihood will help you out!

If there are any specific DFS questions, let me know and I will gladly answer them to the best of my ability.

Constructive Criticism is not only appreciated, I welcome and encourage them.

Until next time :)

No comments:

Post a Comment

Latest Post

Migrating File Server to Sharepoint Online

Hi Everyone, I ran across an interesting project and thought I'd share my experiences in this how to "Migrate an On-Premises file...