albertwt (30th June 2014)
Just a quick thread to confirm my logic...
Moving from a physical box (2003 Storage Server) to a new 2008 R2 VM, just want to shift the data over (around 500GB) as is and get up and running on the new VM...
Was going to use Robocopy to shift everything over using this command...
Was wondering if to up the /R and /W times in case there's any network hiccups, saw 5 and 30 mentioned as reasonable options?Code:robocopy \\source_server\d$\data \\dest_server\d$\data /E /V /R:0 /W:0 /COPYALL /LOG:data_copy.log
The other thing with Robocopy... if I run this command say 2 weeks before the migration to do an initial seed can I run it again just before the migration and it'll just hoover up the bits that have changed since or does that require the /MIR switch?
Once that completes I export the registry key from the old server using this method...
Saving and restoring existing Windows shares
Import the key onto new server (making sure before I copy the data the drive letters match). Stop Server service, restart Server service and I should have all the shares available under the new server name.
Then if I want to make life really easy for myself remove old server from the domain and shut down then reconfigure the new VM with the IP address and network name from the old server. In theory it should then appear to users and GPOs to be exactly as everything was before...
(I know FSMT is there as well but I prefer the Robocopy method as it gives me a bit more control.)
I am going to be doing the same thing in a few weeks. You will need to use the /MIR switch yes. Doing this will make any changes that happened on your old server to the new oneThe other thing with Robocopy... if I run this command say 2 weeks before the migration to do an initial seed can I run it again just before the migration and it'll just hoover up the bits that have changed since or does that require the /MIR switch?
If both servers are on the same domain this will make the job eaiser if your not comfortable with robocopy
Download details: Microsoft File Server Migration Toolkit 1.2
Yes it will do all the things that you are afrer, I would use the /ZB switch also, it will take a little longer but you will have a much more robust and hassle free transfer experience. You can use the /MIR option the second tome to just quickly update it. I have done this several times in the last couple of months for various schools and it has worked well. You do want to lower the retry count as otherwise it will hang up on a failed file for ages. I would also pipe the log file to a text document for later looking over. Its just the /LOG:"filename.txt" switch.
Not sure about the share restore, registry stuff as I have not done that bit but your plan seems sound.
Thanks for the replies, originally liked the look of FSMT but seen enough threads with weird behaviours that I feel happier with Robocopy and knowing exactly what's going on.
So we're up to the following code initially then...
And once that's done nearer to the time go for...Code:robocopy \\source_server\d$\data \\dest_server\d$\data /E /V /ZB /R:0 /W:0 /COPYALL /LOG:data_copy.log
Or just go for the tape restore, just thinking which one will work out quicker reallyCode:robocopy \\source_server\d$\data \\dest_server\d$\data /MIR /V /ZB /R:0 /W:0 /COPYALL /LOG:data_mirror.log
Last edited by gshaw; 1st June 2011 at 01:51 PM.
what does the /zb switch actually do please?
If it were me I'd break the job down into smaller ones, just in case you get a few copy errors.
Personally I would use your backup in this situation, its a great way of checking if you actually are backing up everything that is needed
I use backupexec 2010.
Sleeping thread resurrection time!
Had a slight change of plan with this after some of our teams were restructured, just moving our shared areas for now as the user folders need more work to sort them out for Windows 7.
I'm now looking at using this command first to seed the initial copy of the data, one batch file per shared folder to be copied...
Then when coming to the migration unshare the source folder (i.e. no more changes possible), run this...Code:robocopy "D:\Source Folder" "\\newfileserver\d$\TEMPAREA\Source Folder" /E /V /ZB /R:0 /W:0 /TEE /COPYALL /LOG:Source_Folder.log
After which point I then move the transferred files from TEMPAREA to their new home (and also replace all the copied permissions with those of the new folder they live in due to merging multiple folders into one for some areas)Code:robocopy "D:\Source Folder" "\\newfileserver\d$\TEMPAREA\Source Folder" /MIR /V /ZB /R:0 /W:0 /TEE /COPYALL /LOG+:Source_Folder_MIRROR.log
Did a test with our IT shared area and it copied everything over, MIR removed deleted files and added new ones... so far so good... have I missed anything?
(as you can tell this process makes me very paranoid being that it only gets moved once every 5-6 years!)
We use robocopy nightly for our backup of user data, and it's never had an issue with long file names
From what I remember everything copies but you get trouble working with the files after e.g. renaming and saving. We cleaned up the files before the migration which removed any doubt.
The scripts and robocopy pre-sync / difference sync method worked a treat, had them running on schedule overnight then did the shares the next day.
There are currently 1 users browsing this thread. (0 members and 1 guests)