Migrating a File server is not a difficult task, but for some reason people think this is impossible within a production environment without impact and without cost. With Microsoft's File Server Migration Toolkit migration is a breeze, but it may not be the tool you want to use. I'll explain how to use the File Server Migration Toolkit and when not to use it as a way of migrating an old File Server to a new one.
Besides covering how to use Microsoft's File Server Migration Toolkit 1.0 I'll also cover migrating an old file server using Distributed File System (DFS) and I'll also show you my pick in 3rd party synchronization tools. At the end of this post you'll find a table specifying the scenarios with their appriorate tool. When you use the table wisely all three ways involve no extra investment, while at the same time appeal to your every migration wish.
Microsoft File Server Migration Toolkit
The File Server Migration Kit is a good toolkit from Microsoft that you can use to accomplish two distinct goals with two Wizards:
- File Server Migration Wizard
- DFS Consolidation Root Wizard
File Server Migration Wizard
With the File Server Migration Wizard you can migrate files and folders from Microsoft Windows NT4, Microsoft Windows 2000 and Microsoft Windows Server 2003 file servers to a new Microsoft Windows Server 2003 file server or Microsoft Windows Server 2003 Storage Server.
I've found the wizard to be of much use, because it basically does every step in the migration of a file server to another file server, including sharing resources and setting appropriate rights on the target server and deleting the shares on the source server. What sets the Microsoft File Server Migration Toolkit apart from the others is you can configure the settings of the wizards up front, so you only have to run it when the time comes to migrate.
Big bang
The File Server Migration Wizard is an especially cool tool when you use it in a big bang way of migrating. I recommend not using it when you want to migrate within a scenario of coexistence (like a Functional Pilot) because it doesn't allow for schedule-based synchronization and bandwidth throttling. Furthermore it's not suitable for migrating a non-Microsoft Windows File Server.
DFS Consolidation Root wizard
The DFS Consolidation Root Wizard allows you to migrate DFS Roots while at the same time maintaining the original UNC paths. Just like the File Server Migration Wizard it does all the work for you, even making changes to DNS and WINS. The one thing the DFS Consolidation Root Wizard doesn't do is upgrading Distributed File System Roots to DFS-R after you migrated them to Microsoft Windows Server 2003 R2. You will have to use the How-To Jorge wrote. Just like the File Server Migration Wizard the DFS Consolidation Root Wizard allows you to configure the settings in a projectfile and use the projectfile when the time comes to make it happen.
Distributed File System (DFS)
One of the fun ways of migrating file servers in my opinion is using the Distributed File System. The technology wasn't developed to use as a migration technology, but in my opinion it definitely does the job.
What DFS does
Microsofts Distributed File System is one of the most useful inventions for making data available on multiple server (when you need it) in multiple sites with just one name. When you use multiple servers DFS ensures that the files and folders are identical on all the servers that add up to your DFS Namespace. DFS is available in Microsoft Windows 2000 Server, Windows Server 2003 and Windows Server 2003 R2.
Coexistence
With a Distributed File System achieving a pure coexistence situation is as easy as adding the new server to the existing DFS namespace and allowing the servers to replicate. You might want to do this after working hours and allowing ample time to replicate to avoid users complaining about missing files and folders. After the initial replication you can sit back and enjoy automatic replication between your old and new server. When you're done pointing your users and applications to the new server you can easily delete the old server from the DFS Namespace and be done.
Distributed File System really is a remarkable and enjoyable technology but using it is bound to a few rules that might not apply to your situation. You can only use DFS with Microsoft Windows 2000 Server and up, which means you can't use it to migrate Windows NT4 file servers. Bit level replication can be achieved when migrating a Microsoft Windows Server 2003 R2 file server to another Microsoft Windows Server 2003 R2 file server which makes DFS the preferred way of migrating in this (unlikely) scenario.
Synchronizing with a 3rd party tool
I've been a big fan of 2BrighSparks' Syncback since our company started using it to synchronize documentation between our fileserver, the fileserver of our customers and the encrypted laptops of our engineers. The freeware version of Syncback is free of charge, even for commercial use. You don't see that every day!
Using tools like Syncback allows you to very precisely plan your migration. Unlike the above two ways of migrating your file server this way allows you to not only migrate to a new server, but also to a new rights system (if you want to) a new folder structure (if you want to) and it doesn't care if the source file server is a Microsoft server. I've used the tool to migrate files and folders from Novell file servers and even Samba didn't make this tool sweat. The downside to using an all-round tool like this is that you have to configure every painstaking setting and besides synchronization do everything else yourself.
Coexistence
Just like in the above Distributed File System scenarios you can achieve coexistence by scheduling synchronization. A feature for bit level synchronization isn't available (not even in the SyncBack SE tool, which would cost you USD 25) which makes DFS a better choice when migrating Windows Server 2003 R2 servers on which you have a bunch of large files that change all the time. (PST and ISO files for instance)
When your customer is ready to phase out the old server all you have to do is change the logonscript to connect shares on the new servers and delete the shares on the old server. You can also make these shares read-only so you can track open files which makes it easier to track residual traffic to the old server. Alternatively you could make a DNS Alias record with the name of the old server directing to the new server…
Which one to use?
Just select your situation in the table below. After that scroll down.
Migrating files and folders on a Microsoft Windows NT4, 2000 or 2003 File Server or within a Microsoft Distributed File System on Microsoft Windows Server 2003 to another Microsoft Windows Server 2003 File Server in a 'big bang' way | Microsoft File Server Migration Toolkit | Big bang |
Migrating files and folders on a Microsoft Windows 2000 Server or Microsoft Windows Server 2003 to another Microsoft Windows 2000 Server of Microsoft Windows Server 2003 in a coexistence scenario | Distributed File System (DFS) | Coexistence |
Migrating files and folders between whatever kind of server to whatever kind of server while maintaining coexistence | 2BrightSparks SyncBack Freeware | Coexistence |
More information
Download the Microsoft File Server Migration Toolkit 1.0
Overview of the Microsoft File Server Migration Toolkit (Microsoft Whitepaper)
2BrightSparks Website
Download SyncBack Freeware v3.2.12
Solution Accelerator for Consolidating and Migrating File and Print Servers from Windows NT 4.0
Subject says it all. I'm trying to use the MS File Server Migration Toolkit to move a gigantic share (user home folders) from one drive to another (actually on the same server).
The initial copy took something like a day and a half. I've run a few more update copies since then, but haven't started the "finalize" process yet because I have no clue how long the share will be offline for. (All user homes are shared off of \fileserverusers%username% – none of the old style individual share-per-user.)
There are something like 7.1 million files/folders in total, 365GB of data.
From what I understand, the "finalize" takes the old share offline, compares and re-copies any new files, and then applies the permissions to the new folder tree. There's zero indication anywhere of how long to expect this to take though.
If I'm looking at a "few hour" thing, I can do it at night. If it will be more like another day-long process, I need to wait for a weekend.
I have used most of the utilities listed here and found they had one or more shortcomings. My friend told me about GS Richcopy 360 which helped me a lot in this complex file server migration process. Really loved it. Give it a try, maybe it can help you too!