Recently Jonathan has completed a File Server migration, and here he explains some gotchas that he encountered on the way.
So you need to migrate your old File server, maybe it’s hosted on a ‘no longer supported OS’, or you just need to move the server. How can you do this? What might you stumble on?
How you would migrate the server?
There are documents out there from Microsoft and others on how you can achieve the migration, there are tools that can help you by automating the process, but if you do this do you know for sure everything is copied exactly as you expect? You can do it manually with Robocopy; this is the method I am going to run through now.
- Create your new server and have the target volumes created and ready for the file services. Then using Robocopy we can copy the Source to the new Destination.
Make sure you catch everything, and a good go-to command for starters:
Robocopy {destination} {source} /MIR /COPYALL /XO /R:1 /W:1 /XD {"Exclusions"} /ZB /NP /MT:32
/MIR – Mirror a directory tree
/COPYALL – Copy All file info
/XO – Exclude Older – This is optional on the first run
/R:x – Number of Retries on failed copies (default is 1million)
/W:x – Wait between retries (default is 30 seconds)
/XD – Exclude Directories (Common to use /XD “RECYCLE.BIN” to exclude the recycle bin)
/ZB – Use Restartable; mode if access denied use Backup mode
/NP – No Progress – doesn’t display percentage copied (Speeds up with not having to display)
/MT:x – Multi-Threading enable and # of threads (my example shows 32 threads)Copy
Depending on your data size, this operation may take a long time to complete.
2. Once your copy is complete, and you have verified the dataset is what you expect you have a couple of options if they are just NTFS shares you might wish to copy the registry keys from the old server and import them on the new server. Of if you are using DFS, then you can create the new links to the shares and if you are happy to enable them.
- To copy the Registry keys you will need to Export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
Simply export this from your old server and import to the new server (Remember to change drive letters if they are not identical)
- With DFS – add the new server is to the folders, these can be disabled until you are ready for the new server to take over.
3. Once you have done step 2 you should have functioning shares available to your users and providing everything has gone right no one should see a difference
What might trip us up?
If you were to create the new location as a file share for example D:\OLDSVR-FILES and then drop your source into this, beware when you migrate the shares across, that you need to ensure the share location is correct as already mentioned, but also if you use DFS – ensure the DFS point to the share and not the root for example:
D:\OLDSVR-FILES\DFS-Share
Should be shared at DFS-Share as DFS-Share for example
If you were to create at the lower level \OLDSVR-FILES\DFS-Share then you may become foul of the share permissions and whilst things may appear to be correct you get spurious results.
So here if the permissions at OLDSVR-FILES are restricted to only 1 user, then the cascade effect would mean the shares from that point would be subjected to the more restricted rights. Where the share at DFS-Share level would have the correct permissions
Once you have your DFS share set correctly you can double-check their presentation by right-clicking on the address published folders and you should see a DFS tab, that should show you your shortcut, and this should reflect what you need, and then permissions will flow as before as you need them.
