Files and folders are simple in nature. They don't involve complicated software dependencies, like databases and...
websites. They're just objects stored on a file system. So, why is it rarely simple to transfer a bunch of them?
A Windows file server migration should be straightforward. Windows admins have the xcopy disk operating system command, robocopy and the Copy-Item PowerShell cmdlet at their disposal, with a source, destination and even a Recurse parameter to find every item in all subfolders. But unforeseen issues always seem to foul up large file migrations.
IT professionals typically overlook two topics before they perform a large Windows file server migration: Microsoft's New Technology File System (NTFS)/share permissions and open file handles. A typical scenario illustrates these concepts.
Say you've got a 500 GB file server with each employee's home folder stored on the \\FILESRV\Users file share. The IT department plans to map the folder as a network drive, via Group Policy Objects, on every user's desktop. But when it's time to move those home folders, things go wrong. It could be that the disk that stores the home folders is direct-attached. In that case, the admins must migrate it to a storage area network or transfer the data to a different logical unit number. All of that important data must move.
In this scenario, data isn't just cold storage -- this data changes every day. It also has a specific permission structure setup: Employees have full rights to their folders, managers have access to their employees' folders and other miscellaneous NTFS permissions are scattered about. The organization depends on 24/7 availability for this data.
Commercial tools are available to aid in a large Windows server file migration, including Quest's Secure Copy and Swimage. Microsoft offers the free File Server Migration Toolkit (FSMT), which recreates shares. FSMT is a great alternative to fiddling the switches in robocopy.
Use FSMT for file transfers
FSMT is a Windows feature, so the user installs it via PowerShell on the destination server:
Install-WindowsFeature Migration –ComputerName DESTINATIONSRV
Once FSMT installs, stay on the destination server, and use the SmigDeploy utility to create the deployment shares. The SmigDeploy tool makes the share on the destination server and performs the required setup on the source server. The syntax below assumes that the source server runs Windows Server 2012 and has an AMD64 architecture, while the share to migrate the profiles to is at E:\Users.
smigdeploy.exe /package /architecture amd64 /os WS12 /path E:\Users
Use a similar command if the source server runs an earlier version of Windows Server.
Once this script generates the E:\Users folder, create a share for it:
New-SmbShare -Path D:\Users -Name Users
Next, copy the deployment folder from the destination server to the source server:
Copy-Item -Path \\DESTINATIONSRV\Users -Destination \\SOURCESRV\c$ -Recurse
Register FSMT on the source server to continue. From the source server, change to the C:\Users\SMT_ws12_amd64 folder, and issue the command SmigDeploy.exe to make FSMT ready for use.
To perform the Windows file server migration, go to the destination server, and import the PowerShell snap-in that the feature installed:
Once the snap-in loads, type Receive-SmigServerData. This sets up the destination server to receive data from the source server once it's initiated. Go to the source server, and send all of the data to the destination:
Send-SmigServerData -ComputerName DESTINATIONSRV -SourcePath D:\Users -DestinationPath C:\Users -include all -Recurse
Enter the administrator password if prompted, then watch as the files and folders flow over to the destination server. This FSMT process copies the data and keeps permissions in place during the Windows file server migration.
Find must-have features in file-sharing programs
Lift-and-shift doesn't work for cloud migration
Know these vendors for enterprise file sync and share