Utility SpotlightFile Server Migration Toolkit

Jeremy Moskowitz

Download the code for this article: Microsoft File Server Migration Toolkit 1.0 (1434 KB)

Admit it. You've got 'em. Those Windows NT and Windows 2000 file servers that you just can't seem to shake. You want to update your file servers to Windows Server 2003 SP1 or Windows Server 2003 R2, but there's a problem. Your users rely on Universal Naming Convention (UNC) paths to point to shares on your file servers,

and if you move the data from the original servers to the new servers, all those UNC paths will break. All of your users will call the help desk, and you'll have to go into hiding.

Or how about this problem. Say you started using Group Policy Software Installation and serving files using one file server. Now you have 50 Group Policy Objects (GPOs) deploying applications to your Windows XP and Windows 2000 machines. You're ready to turn off that original file server, but those 50 GPOs depend on it.

Just turning off these servers isn't an option. Simply copying the data to new shares on a new server won't work either. So what are you going to do? Microsoft has a cool tool to help you take control of your old file servers and seamlessly bring the data into the 21st century.

Introducing the File Server Migration Toolkit

The File Server Migration Toolkit (FSMT) is a free download available at microsoft.com/windowsserver2003/upgrading/nt4/tooldocs/msfsc.mspx. It consists of three parts: the DFS Consolidation Root Wizard, DFSconsolidate.exe, and the File Server Migration Wizard.

The DFS Consolidation Root Wizard is a GUI tool that works some serious magic. It lets you maintain the original UNC paths of the servers, even if you are planning to ultimately turn those servers off.

A command-line tool, DFSconsolidate.exe is called by the DFS Consolidation Root Wizard. While it's possible to use DFSconsolidate.exe on its own, I'm only going to discuss its use in conjunction with the DFS Consolidation Root Wizard.

The File Server Migration Wizard is a GUI tool that helps you plan your migration from the source servers to the target servers. It then performs the actual copying of original files to the target destination.

An Overview of Migrating Shares

The first thing you need to do is determine the source server, which is where files are currently stored, and the target server you want to migrate the files to. I'll work through an example to help you better understand what exactly is involved.

Consider the setup in Figure 1 as your starting point. You have a Windows NT® 4.0 file server (\\nt04) with three shares that contain user data. You also have a Windows® 2000 server with one share used to deploy software. The Windows XP machine needs access to the following:

• \\nt04\ntshare1
• \\nt04\ntshare3
• \\w2k\software

Meanwhile, the Windows 2000 machine needs access to these servers and shares:

• \\w2k\software
• \\nt04\ntshare2

Figure 1** Original Setup with Windows NT and Windows 2000 Servers **

Now you introduce a target file server called \\fileserver6 (see Figure 2). This new server running Windows Server® 2003 SP1 will be responsible for receiving the shares and requests. The ultimate goal is to consolidate the existing shares onto \\fileserver6 and turn off the Windows 2000 and Windows NT servers. But you need to perform this consolidation in a way that preserves the original paths of each of your shares. Yes, you read that correctly. You want to be able to access the data that was on the original servers (the ones being turned off) as if the data is still stored on those original servers. Basically, requests that use the original paths will be directed to the new Windows Server 2003 file server after the old servers have been shut off. And, of course, you want to make sure security is preserved all along the way.

Figure 2** Moving the Data to Windows Server 2003 **

Figure 3 shows a Windows XP machine accessing a directory of files on both \\nt04\ntshare1 and \\nt04\ntshare3. The goal is for this Windows XP machine to continue to perform the same commands, using the same UNC paths after you move the files and turn the original file servers off.

Figure 3** Windows XP Viewing Files Using UNC Paths **(Click the image for a larger view)

To make this happen, you'll use a part of Windows that has been around for a while, but still isn't in widespread use. The Distributed File System (DFS) accepts incoming connections and routes them to existing shares—this is sometimes called referrals. It's sort of like a share of other shares in that it basically allows you to hang existing shares off a new DFS share or, more technically, the DFS root.

There are two kinds of DFS roots: standard and domain-based. Standard roots live on only one server. Domain-based roots can be hosted by multiple servers, which means they're more fault tolerant. If one of the servers that hosts the domain-based root goes down—no problem. The referrals just keep on truckin'. To learn more about DFS, check out the Distributed File System Technology Center.

Before we get into the details, here's a quick overview of the steps you will perform to achieve your goal of moving data to a new file share while maintaining the UNC paths:

• Determine where you want to store your new files. In this example, you'll use fileserver6.contoso.com.
• Rename any file servers that you have plans to permanently retire. Since you're retiring them, the new name doesn't really matter. For this example, \\nt04 will become \\nt04-ret and \\w2k will become \\w2k-ret.
• Use the DFS Root Consolidation Wizard to reroute incoming requests for the retiring servers (\\nt04 and \\w2k) to the new location (\\fileserver6). Note that if you prefer, you could use two separate servers (one to hold the DFS roots and another to hold the files).
• Move all of the files from the shares on your original servers to the new file share location.

Getting Started with the FSMT and DFS Consolidation Wizard

The FSMT comes as a single installation but, as noted, it consists of three separate components. The File Server Migration Wizard is meant to be run directly on the target file server. However, you can run the DFS Consolidation Root Wizard and Dfsconsolidate.exe anywhere.

Note that the FSMT documentation makes special mention of Knowledge Base article 829885 which talks about a DFS hotfix. The implication is that this hotfix must be loaded on the target DFS server. However, this hotfix is built into Windows Server 2003 SP1 and therefore is not needed when the target server is Windows Server 2003 SP1. Still, the FSMT documentation fails to mention one critical step: be sure the DFS service is started and set to Automatic for future restarts.

After the FSMT is loaded, you must change the names of the nt04 server (to nt04-ret) and the w2k server (to w2k-ret), where I'm using "ret" to signify retired. Feel free to use different names that are meaningful to you. This is necessary so that when clients try to connect to \\nt04 or \\w2k, neither actually exists anymore. This allows you to fool those incoming requests into shimmying over to the new shares on \\fileserver6.

In my tests, renaming a Windows NT4 server wasn't as easy as I would have liked. Simply renaming it doesn't magically change the name in Active Directory® (as would happen if I renamed a Windows Server 2003 or Windows XP machine). I had to drop the machine into a workgroup, rename the machine, and rejoin the domain (contoso.com). And, of course, along the way several reboots were required. Finally, I had to delete an orphaned computer account for Windows NT4 using Active Directory Users and Computers. In contrast, renaming the Windows 2000 server was a snap. I just renamed the server and rebooted. No muss, no fuss.

Once your Windows NT and Windows 2000 servers are renamed, you're ready to run the DFS Root Consolidation Wizard. This is pretty straightforward, asking for only a minimum of information.

The wizard will want to know your DFS root server. This is the location where the DFS root will be held. In DFS terms, this will be a type of standalone root known as a DFS consolidation root, which exists solely on the server you specify. Note that the root cannot be on a domain controller. In this example, you are putting the DFS consolidation root on the same server where the files will ultimately go (fileserver6). However, you can create the root on a server cluster if you want to increase the redundancy of the consolidation root.

You'll specify the local path of the top-level folder where the consolidation roots are stored. If you were migrating 10 servers, there would be 10 consolidation roots underneath this top-level directory. For this example, the local path of the folder is c:\dfsroots. The subfolders under c:\dfsroots are used only by DFS. You will not be storing migrated data in this folder.

And the wizard will ask you to specify which servers to consolidate (see Figure 4). This is where you map the original name (in this case, \\nt04) to the current name (\\nt04-ret).

Figure 4** Mapping Old Names to New Servers **(Click the image for a larger view)

If the Wizard finishes without errors, you've completed the first big step. Now, before you do anything else, take a moment to try something out. Go back to your Windows XP machine (see Figure 3) and run those same dir commands to access \\nt04\ntshare1 and \\nt04\ntshare3. Without restarting the Windows XP machine (or even logging off and back on), note that those same dir commands continue to work! This is because the DFS Root Consolidation Wizard has mapped \\nt04 to \\nt04-ret.

Let's take a look at what really happened in the c:\dfsroots folder on fileserver6. In Figure 5, you can see that the wizard created a shared folder (the DFS consolidation root) to represent each server you plan to migrate. Under each DFS consolidation root is a special type of folder, known as a link folder, that represents each of the shared folders you plan to migrate.

Figure 5** New Shares Representing the Old Servers **

If you use Windows Explorer locally and drill down to one of the directories—say, ntshare1—you'll get an error. This is because DFS only provides a referral when the link folder is accessed via a UNC path. Also note that each server is now represented by a share called #servername (such as #NT04). This was created by the DFS Consolidation Wizard.

It is possible to use the DFS Consolidation Wizard if your shares are on domain controllers. However, the same rule applies for domain controllers as for regular file servers. That is, the server (domain controller) must also be renamed. Unfortunately, renaming domain controllers can be a real pain in the neck. Microsoft does have some domain controller renaming guidance in case you find this is something you need to do:

• For Windows NT 4.0 domain controllers, see support.microsoft.com/kb/150298.
• For Windows 2000 domain controllers, see support.microsoft.com/kb/296592.
• And for Windows Server 2003, see support.microsoft.com/kb/325354.

Keep in mind that the DFS Consolidation Wizard cannot directly help if you have hardcoded, persistent mappings. This means that if someone has used the /persistent flag while using the net use command to map a drive letter (or the corresponding Windows Explorer commands), those mappings will now fail. But if you're using login scripts to map the drive letters each and every time a user logs in, you'll have no problem. This is because every time a request goes to the old server name, a new lookup to the DFS is generated and routed appropriately.

Moving the Actual Files

To actually migrate the files, you create a project contained within the File Server Migration Wizard, which appears as an icon on the start menu. The beginning steps are straightforward. Create a new project, point the File Server Migration Wizard toward the new DFS consolidation root that you created earlier (fileserver6), and wait for the wizard to recognize the servers, as shown in Figure 6.

Figure 6** The File Server Migration Wizard Will Recognize Your Servers **(Click the image for a larger view)

At this point, you can specify which directory you want to place the new files in. For this example, they'll go in a new directory on fileserver6 called c:\migfiles.

A quick note on what is and is not copied. Obviously the files themselves are copied. In addition, the File Server Migration Wizard copies both NTFS and shared folder permissions. However, references to local groups are not copied. If local groups have permissions on the source's shared folders, you can use the command-line tool SubInACL.exe to adjust the permissions before or after the migration to replace the local groups. Alternatively, you can use a local group migration tool like the Active Directory Migration Tool.

After the project is formed, you can make any necessary minor adjustments (as shown in Figure 7). For instance, you might want to put the contents of ntshare1 in a directory named Sales Stuff instead of ntshare1. This might boggle the minds of your users, but you may have a valid reason.

Figure 7** Tweaking Settings for Each Share **(Click the image for a larger view)

Finally, you can step through the rest of the process by clicking the Continue button. The process is painless, but can take quite a while depending on how many servers you are consolidating. For lots and lots of servers, consider breaking up the effort into multiple projects—this will allow for some time for your servers to settle in and give you time to address any errors you may encounter.

Source and target servers are still available during the copying phase. In other words, there's no server downtime when copying files from the source server to the target server. And if there are errors during the copying process, you can try to fix the problem and recopy. A nice touch: since you can repeat this phase multiple times to fix errors, only failed copy attempts are retried. You don't need to copy the whole universe again if you've already copied 90 percent of it.

The last phase, which is called Finalize, should only be done when users won't be accessing the servers. In this phase, you disable any original access to the source shares and close any open connections. Additionally, all other project settings are locked.

After this, you're ready for the final test. Unplug the original servers from the network (but leave them running just in case). Then, as you did earlier on the Windows XP machine, use the dir commands to make sure you can access the copied servers using the original UNC path names.

Once you've confirmed everything is in order, you can turn off your old servers. Now they're free to be recycled, reformatted, and redeployed for another purpose. You can even make a fish tank out of them.

The Future

The FSMT is a great tool and it gets the job done. However, there are some small, nitpicky points I'd like to see addressed going forward.

As I mentioned, the FSMT uses what's called standalone DFS roots. The DFS root is put on one specific server. In this example, fileserver6 was used to store the standalone DFS root and acted as the storage point for the migrated files. However, you could have split the duty between file servers. That is, one server could have housed the DFS root while another was used to store the data. The problem with this approach is what would happen if the server holding the DFS root goes offline? That would be a major problem, as there would be no way to route to the new file server (or servers).

The ideal solution would be to use the more powerful domain-based roots which are fault tolerant. If the one server holding the DFS roots should fail, the fault tolerant domain-based DFS would kick in. Today, FSMT doesn't use domain-based, fault-tolerant roots, but I really wish it did. But as I mentioned earlier, you can try to work around this by putting the consolidation root on a set of clustered servers. If one node in the cluster goes down, referrals will continue. The FSMT product team tells me that all parts of FSMT are fully cluster aware and compatible. It will create cluster consolidation DFS roots and add cluster names instead of DNS aliases if roots are hosted on a cluster. That's a nice touch.

It's also unfortunate that you must rename the servers to perform any redirecting magic. I would love the ability to keep the server intact, name unchanged, and just redirect a specific share. This would allow me to keep using the server for whatever else it's doing, but still migrate specific shares. To do this, you would need symbolic links within the original share that would route requests to the new location. But right now Windows Server 2003 isn't quite there. Perhaps this will be possible in the next version of Windows Server, code-named "Longhorn".

The last note here is that you're not actually forced to turn off the servers you've migrated from. You can, if you want, keep the server online performing other roles. The problem is that this might make it difficult for other network services and clients to find the newly renamed machine. DFS is some pretty strong magic, but it's only for files. Other services won't be able to seamlessly find the renamed server.

Wrap Up

The FSMT is a cool solution that works as advertised. And the price—a free download—can't be beat. It should be noted that as good as the toolkit is, it's not meant to be a permanent solution.

The idea is that over time you should properly design your DFS, pointing users to the updated structure. Then you can phase out the roots you created. Essentially, the FSMT should bridge the gap as you bring your file servers into the 21st century.

Jeremy Moskowitz, MCSE and MVP in Group Policy, runs GPanswers.com, a community forum on Group Policy. His latest book is Group Policy, Profiles and IntelliMirror, 3rd edition (Sybex, 2005). Contact Jeremy at www.GPanswers.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.