1

Greetings All,

Long story short, upgrading from a single server that was doing AD/DNS/DHCP to a new server with a virtualized DC and FPS. DC is done, dcdiag and repadmin dont show any glaring issues. Next step getting the files and shares across. This is my first server migration (DC & FPS) and is a part of my growing from helpdesk to a more admin role hence the reason for threads everywhere lol :).

So I am wanting to make this as quick and painless as possible because I only have a few days left at this branch. Little Green Man made this handy guide and it looks pretty painless and on the plus side it will take the directories and permissions across so in theory after all the PS commands done and dusted it should be a case of verify the permissions, change the login script, have everyone log off and back on and hey presto all done. The data is about ~76GB so it is not a lot of data to copy across.

In a separate thread ( here ) asci.white mentioned using robocopy because it is a cleaner solution and wont need me to upgrade my PS version which for the LGM guide I would have to do. A quick Google search reveals a SW thread for the following PS command:

ROBOCOPY "\\servername\sharelocation" "\\newservername\newsharelocation" /MIR /SEC /LOG:location:\nameoflogfile

Looks simple enough. :slight_smile:

And, because I love discussions and seeing other people’s viewpoint, there is a third option! :slight_smile: Using the File Server Migration Toolkit . Now it is not confirmed to work with 2016 so it is an unknown at this point but it does have some great steps such as stop sharing source folders. It will also provide you with a handy log after each step. Now the author for the third option mentions that robocopy might crash if it comes into contact with long file names and other weird and wonderful things.

So what option would be the cleanest and easiest? robocopy looks appealing but the potential for crashing has me looking at it sideways. My preference was leaning towards option 1 but step 6 on option 1 has me slightly puzzled so it would need testng first :). Any other mentions?

@billkindle @batman14

2 Spice ups
2

I would be looking to set up a DFS namespace and replication, add your old file server location and your new, let them replicate, then remove the old location.

1 Spice up
3

Never thought of that method to be honest. Will research it, thank you.

4

Windows Server Migration Tools

5

Why not create a test VM and try out your suggested approach. It would take you just a few minutes to spin up a VM. then try it!

1 Spice up
6

tfl I did that before coming up and it seemed to work okay and to be honest I am still leaning on doing option one. But I will fire up another two VM’s and test it again.

@thomaslee

7

One thing to be cautious of , is long file names and deep file paths. I had lots of trouble with this after doing a migration from W2K3 to W2K12.

1 Spice up
8

rod-it posted the best solution.

Simple to set up and you don’t have any problems with working on the wrong/old share.

9

Recently I did FS share migration which went quite smoothly. Source and destination Servers were virtual machines. And, both in same Vcenter. It was kind of os upgrade but not In- Place upgrade.

  • old VM had shares on one drive of 2 TB
  • new VM only with new OS
  • exported the hklm\system\current control set\services\lanman\shares & security (registry value in.reg)
  • power off the old VM and copied this file on new vm
  • removed the 2TB disk from Vcenter in VM edit setting
  • now added the same disk in new VM from edit setting
  • powered on the new VM, set the same IP and hostname as old
  • imported the .reg file
  • disk management brought the 2 TB disk online and set the same drive letter it was on old VM
  • that’s it …all shares and permission were intact and accessible on new VM.
2 Spice ups
10

Hiya

Personally I’d use Robocop it’s a good tool and never let me down.

I’d use the following command

Robocopy source destination /Mir /b /r:3 /w:0

Mir mirrors everything from source to destination

B coppies data in Backup mode in case files are locked.

R number of retries to copy something

W wait time before trying again

Good luck

Mike

11

Throw on /tee to the end of your command and the logging output will also be printed to the screen.

I have done this several times. Migrate from one server at a remote site to the main severs in the COLO. I create the new share on the main file server, set up the permissions I want the root dir to start with, then start the robocopy on a Thursday evening. Friday I check the logs for any skipped directories. I’ll then either shorten the folder name structure or set a drive map deeper in the tree and make the copy for whatever was skipped. Over the weekend, Saturday night I’ll change the GPO for the shortcuts or drive maps to the shares to the new location, reboot any clients that still have open files on the old server/share. Then on the old server/share I remove everyone else’s access to the share leaving only domain admin access, then run robocopy again to shuffle any new changes to the new server. After it is done, wait a week to fully kill the share, another week to delete the old files. Check for shadow copies is turned on and scheduled frequent enough the drive the new share is on, check for backups.

12

DFS replication might not finish in time. I don’t like it for migration. I like robocopy. If it crashes, figure out the issue and retry. I like to make the first run with the /create switch to setup the folder and directory structure, and then subsequent runs without it. Using /create minimizes directory fragmentation. Robocopy is good for multiple TB at a time in my personal experience. When cutting over to new shares, you should point to a DFS Namespace instead of directly to the \server\share. This will make future migrations easier because you won’t have to fix any shortcuts, drive mappings, linked Office documents, etc. The client side UNC path can remain the same when pointed at a DFS Namespace.

13

Well the steps I wanted to go?

SmigDeploy.exe is checking for prerequisites.
--------------------------------------------------------------------------------

Error: Windows Server Migration Tools cannot run on this operating system. Windo
ws Server Migration Tools can run only on computers that are running Windows Ser
ver 2012 R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008
.

So for anyone else listening Small Business Edition not compatible… Robocopy here I come…