Storage Migration Service - Cutover Fails/hangs During Rename and Reboot Source Server Step

Copper Contributor

Hi folks. We are using the Storage Migration Service to migrate several servers from 2K8 R2 to 2019 and running into some issues during the various parts of the Cutover phase.

This particular post deals with the Rename and Reboot step of the Cutover phase which we last attempted April 29, 2019(still working with Support, but no solutions yet).

Details below:

1) We have an active case open with Support, but I wanted to Post to the Community to see if we get lucky.

2) We were able to get to the "Start Cutover" phase and it began around 5:30 PM CST on our last try.

3) Following it's progress, the process got through the final copy(approximately 600GB of data) and rename of the source server showing it was 44% done around 7:30 PM CST.

4) The source server never completed a reboot, but it did change the name and NIC settings.

5) The last update we saw on the Admin Center page was "44% Adding the source computer to the domain..."

6) We left it at this message until 10:30 PM CST. At this time I went ahead and manually rebooted the source server, hoping it would continue the process.

7) It didn't and since I was running out of time in my Change Window, I renamed the original server back, reset the NIC settings, and restarted it to get it back up and available.

8) I also disconnected the NIC on the new server to make sure we had no conflicts while we continued to troubleshoot.

As of today 6/20/19, the new server has been put back on the network, I've wiped out the target drive and re-created it, reset it's network info, set up a new Migration Job, and going to try another Cutover this weekend.

Any tips, suggestions, or other ideas appreciated.

 

Thanks,

 

Don K

 

8 Replies

@DrKuhlmanI'm seeing the same thing in our lab test and struggling to see where it is going wrong. Did you ever get this resolved?

 

Thanks,

Mark

Hmmm - weirdly worked when I tried it again tonight without changing anything, so ¯\_(ツ)_/¯

Hi @HidMov 

First, I apologize for not answering your question sooner - user error on my part because I didn't see the email notification that you posted : (

We did try it again on another server and had similar issues, so we haven't resolved it yet.

We went ahead and did a manual migration - old school with Robocopy, manual rename, re-ip etc. to get that one done.

 

Best,

 

Don

 

Hi @HidMov - just replied to your first post, I'm glad you were able to get a successful Cutover - with no changes - very interesting. Did you go in and restart the process from the Cutover phase, and it just worked?

 

We may try again on another smaller server, if we do, I'll share my experience.

Meanwhile, I've got several more servers to get done in the near future, so I'm proceeding using old-school manual methods for now.

 

Thanks for sharing though!

 

Don

 

Hi @DrKuhlman 

 

I started the process over again and it just worked. Only difference was the Orcestrator server and the source/destination servers had gone through a reboot. I've since run the process again on fresh VM's and it worked right the way through except it didn't re-IP the destination to the source IP, but I've raised that as a separate query. Best of luck when you try SUS again!

@DrKuhlmanI came across this exact issue and I was able to determine what caused it in my scenario. I pulled up the debug on the proxy in the events section and found an error that said the said source server was not reachable at the new hostname it applied. When I attempted to ping it, it could not resolve the address. I found that DNS record had not been created for the new hostname. I also found that the original entry was a static entry. Once I added the A record in my local DNS for the new name of the source server, it was able to get past this upon next attempted cutover. Hope this helps!

I had same issue when migrating from 2008 file server to 2019 in test environment. First time it failed due to can't communicate with source server. Then I ran second time and when it was waiting for the source server, I quickly login to the source server and disabled the firewall (at this stage source server was removed from domain but no server name change) . Rest of the process went smoothly and finished successfully.

@DrKuhlman I came across the same issue today, in my case both source and destination file server was on cluster, I resolved it by manually performing the task.

I found the following issues.

1. The existing (source) cluster name was not renamed.

2. The DNS record with new temporary IP was not created.

3. The computer object of cluster name (temporary name for source cluster) was not created.

 

SOLUTION!

1. Created new DNS record with New IP of source cluster.

2. Create the computer object for the new cluster name of the source server.

 

As soon as created above record, the wizard which was stuck at 41% got completed in the next minute!!!

 

In short what action the Wizard is intended to do and got stuck due to some reason I did that step manually and the long awaited migration got completed.

 

Regards, 

Mohammed Sadique