Forum Discussion
Migrating from Server 2003 to Server 2019 using Storage Migration Service
NedPyle thanks. We gave up and moved to robocopy.
I had tried it again without CRC without significant impact on performance.
We had the OS fully patched in late June, so I assume it had the april update, unless you are saying that update is not in the normal stream of windows' updates.
For us, in our situation, for whatever reason it was simply not usable -- too many files disappeared, and there was no good way to account for them and ensure we could find and fix all the issues. It was too risky to use the tool the way it works, notably the way it reports errors. There should be a consolidated summary (an as-of summary after reruns as well) that shows open issues - files not sync'd and why. You shouldn't have to spend hours trying to find them in event logs, nor should you resort to (as I did) other tools to do complete folder directories and checksums and then do a differences on the old and new drive.
The risk of data loss given its poor performance, combined with poor error reporting, was just too great.
I hope there's a version 2 that would work - robocopy and checksum tools are not great tools. But they work. The simplicity of a log file that only shows errors (and very few of them, like locked files) is reassuring.
Linwood
Linwood Thanks. In the future, please do not give up and move to robocopy - open a support case so we can investigate. If there's a bug, the case is free. Otherwise, nothing will improve (robocopy spent 20 years being improved through support cases :) ). We have had tens of thousands of migrations, moved 10PB of data, and no one has reported the exact symptoms you are reporting, we'd like to understand what happened here.
That turning off CRC didn't help performance means there was something very wrong going on in this migration, the different will always be dramatic. Regarding the logs - did you look at the CSV logs that you can download after transfers, but find them to be inadequate? You shouldn't need to look at event logs, we have transfer logs for this reason - both complete and error-only.
In the future I will consider it, but opening a support case with Microsoft has historically been extremely frustrating if you are not a huge corporation with good contacts. I haven't opened a case in many years, and not for cost reasons -- it is just too awful an experience. Besides, the recommendation in the FAQ has that as the last option. It says:
To get support:
- Post a question on the Windows Server Tech Community
- Post on the https://social.technet.microsoft.com/Forums/en-US/home?forum=ws2019&filter=alltypes&sort=lastpostdesc
- Open a support case via https://support.microsoft.com/
So I picked the first option.
Anyway, I logged into the client to check a few things. 2019-06 CU had been installed, which should have included it. To make sure I downloaded the individual update and ran it, it says "is not applicable to your computer". So I presume we are current on that.
My memory is fading on the CSV files. I went back to look but had deleted the migration job when we gave up. So I can't comment on why I didn't use them -- didn't try, didn't work, couldn't make sense, stupidity, ignorance? I will tell you I spent HOURS on log files and just ended up confused.
I posted one of the errors above, the network name not found -- so what is that? Ok, I retract that question, I understand the error in principle, but why does Robocopy never fail with it, and LOTS of errors in storage migration? What is it doing differently that causes so many more failures on Storage Migration?
I really wish I could run a delta and give you more details, but we have things staged and keeping it updated with robocopy pending them getting an application ready to move, and if I start over just getting the first run with migration will take days, probably most of the week, and I don't think I can afford that.
I've got another 2019 server on that LAN staged for exchange that is held up for unrelated reasons, let me see, maybe I could pick a tree that had problems and just try migrating part of the drive.
More later if I can.
Linwood
Linwood Hi. Yep, I wrote that article. It's just ordered by likelihood of needing to pay, so I start with free options that don't often require logs and a case. If you open a support case for anything I own - Storage Migration Service, Storage Replica, SMB, DFSR, etc. and aren't getting anywhere, pinging me here or emailing me at nedpyle@microsoft.com will always get a reaction of my boot in someone's butt, I promise. :)
Yes, you have that fix.
I've found some folks simply just don't find the logs (as they pop out of the Details menu after transfers are done, which I don't consider super intuitive, and am making some changes to for easier discovery). So this is useful feedback for sure; if you don't remember, we did a bad job of making it visible.
The error is possibly a bug in SMS error handling, since as you point out, Robocopy doesn't see it (or handles it more robustly). We've found a number of conditions in customer networks and servers that cause that error, so we've started adding retry code in SMS to get around it - originally we'd just quit and move on, meaning that SMS started exposing a long existing underlying problem but didn't try to deal with it. But we've also found at least one straight up bug there in our code previously for certain conditions, so there's room for more to be found.
If you can grab logs with https://aka.ms/smslogs when you see the issue on your next server and open a case, then say "Ned Pyle told me he wanted to see your logs and maybe debug my server", we can short circuit the usual bureaucracy and figure out what's going on here. I can personally have one of my supportability PMs non-decrement the case if we find a bug.
- Ned
- My mistake -- the other server is W2016, since we couldn't get a compatible exchange server to run on 2019 that would co-exist with whatever version we had now. So I have no 2019 server to test against at present. Sorry.