There are many potentially different circumstances involved with a file server migration. Are you preserving your domain? How was the old server setup? Was it a VM? A VM on a different platform than the one you are moving to? And, no doubt, countless more variables. This article is intended for the generally healthy file server and domain being moved to a new file server. If your existing system is a mess, you may just want to start over and this article won't really be appropriate.
A disaster recovery best practice (and in some cases, a compliance requirement) is to test your backups. Migrating between file servers can be a fantastic opportunity to do so.
Using this method, you can take your most recent full backup and restore it to the new server. You're not doing a full server restore, but a full data restore. A well designed file server has the file share data and the operating system living on separate volumes (drive letters). By restoring the data volumes to the new server, you are confirming your backups worked and any good backup software should handle the NTFS permissions as well.
Further, if you use full and differential or full and incremental backup models, you can perform your Full restore and then the subsequent differential or incremental backups, which are typically much smaller, can be restored far more quickly meaning there is a minimal time window where the server would have to be (should be) off-line from user access.
This method can generally be fast, but speed will depend on the file sizes you are both backing up and restoring. As a general rule, small file sizes, even on the fastest storage subsystem, can take considerably longer to copy and even restore than large files.
Advantages Summary: Tests backups. Can be pre-staged allowing minimal time to finalize.
Disadvantages Summary: Potentially slow depending on file sizes to be backed up and restored.
If you're virtualizing (and you should be unless you have a darn good reason not to), and your existing file server is not currently virtual, you can create a virtual copy of the data drive using the free Disk2VHD1 tool from Microsoft. This tool generally works fast and reliably to create a dynamically expanding VHD or VHDX that is compatible with Microsoft's Hyper-V Virtualization platform.
The tool does not directly copy files but rather reads the disk and recreates it in a single large file form. As a result, it often can run as fast as the disk subsystem allows and file sizes stored (large or small) will not matter. Additionally, it retains all NTFS permissions you may have assigned to the drive.
Advantages Summary: Fast, Creates a Fully Compatible Hyper-V virtual hard drive. Can make copying to and from intermediate media much faster.
Disadvantages Summary: Requires your destination VM to be a virtual machine on a supported platform. Does not facilitate testing your backup strategy.
There are many utilities that can be used to copy files and preserve permissions. Two of the more common tools from Microsoft would be XCOPY and ROBOCOPY.
Using XCOPY, the command I would use would be:
XCOPY "\\sourceServer\ShareName\*.*" "\\destServer\ShareName\" /E /C /H /X /K /I /V /Y >Copy.log 2>CopyErr.Log
The command parameters are:
At the end, I redirect output to a file called "Copy.log" and also create a separate error log file called "CopyErr.log"
Using Robocopy the command would look like this:
ROBOCOPY "\\sourceserver\ShareName" "\\destServer\ShareName" /E /COPYALL /R:0 /LOG:Copy.log /V /NP
Advantages Summary: Easily scriptable.
Disadvantages Summary: Once started, there's no pausing. Potentially slow. If the copy starts, it should be restarted from the beginning to ensure there are no file corruptions (on large volumes this can take a VERY long time.
Multiple tools from both Microsoft and third parties exist that can help you replicate data between two or more servers. Doing so can help ensure that data is available even in a disaster or at "full speed" to branch offices.
Distributed File System Replication (DFSR) is Microsoft's method for synchronizing the contents of two file shares. In conjunction with the Distributed File System Name Space, DFSR can make multiple servers share files to your users by having the user acces the file share via \\domain\share instead of \\server\share. DFSR and the DFS Name Space consolidates multiples servers behind one share that points to multiple servers. Especially in multi-site environments, this allows users at each site to "favor" access on their local server but fall back to other servers that may not be local in the event the local server (or their preferred server) is unavailable.
Using DFSR, it becomes easy to simply add another file server, allow it time to replicate the data from the other servers, and then remove an older server with little to no user notice. Users won't easily know which server they are connected to at any given moment.
DFSR works at the block level, meaning that if you have a 4 MB file and only change a small portion of that file, only that portion needs to be replicated to all the other servers on the network, not the entire file. This can greatly reduce replication bandwidth and ensure that changes reach all servers as soon as possible.
Other third party tools can be employed as well. cwRSync is a Windows port of a commonly used linux tool called RSync which synchronizes the contents of two folders.
Advantages Summary: Can enhance the overall reliability and accessibility of data on the network. Allows for easily adding additional file servers without reconfiguring end users or group policies.
Disadvantages Summary: Can take longer to setup and complete the migration process. Certain files may not replicate.
In most cases, I don't bother with share permissions. And since most servers only have a handful of shares, I often just recreate them as the time required to "migrate" them would be excessive by comparison. However, there can be cases (especially in environments concerned with compliance), where you may have extensive share permissions defined. The good news is that since Windows 2000 (and probably earlier) little has changed in how this information is stored which means how you can transfer it hasn't changed much either.
Shares are stored in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares. By exporting this key, you can get all the shares, drive paths, and permissions used by your shares.
HOWEVER, it's important to understand that when importing these shares to the new server, if the drive letters don't match, the shares won't transfer. For example, if your old server had a C: drive (with the OS), a D: drive which was your CD/DVD drive, and an E: drive which was your data drive, and you imported those share settings to a server with only a C: and a D: drive (where the data was on D: and there was no CD/DVD), then your shares would NOT transfer.
To ensure they do, make sure you assign the same drive letters on the new server as the old. Further, I would recommend editing the exported .reg file and removing the shares that don't apply or may already be shared on the new server - for example, the admin$ share and the c$. (Newer versions of Windows may not include these in the exported file / may not have them present in the lanmanserver registry location).
Which method you choose depends on what you are most comfortable doing, the time you have to complete the task, and the skill (and comfort level) you have with the technologies involved. If you believe one method is superior to another for your organization but lack the skills to implement it yourself, I strongly encourage setting up a lab system with virtual machines and playing with the technologies, simulating the process to see how it works and get comfortable. If you lack time and/or interest in doing that, I more strongly encourage you to hire a professional to handle the migration for you or work with you to complete it.
1. Disk2VHD creates Hyper-V compatible VHD and VHDX files. If you are using a different virtualization platform, you may need to use another tool or another method of transfer.