Forum Discussion
Cutover Timeout recommended settings
Hello I'm trying to migrate a server to Azure. I'm in the cutover phase, it has a default timeout of 2880 minutes, which is 48 hours. Personally I can't have a file server "offline" for 48 hours d...
Ned,
Thanks for the reply!
It was stuck on "44% adding source computer to the domain". It did time out, a few minutes after 60, with FAILED status. I have the logs from the Orchestrator computer and the destination computer.
We checked on the source box, and it had been renamed to what we specified during the cutover wizard process. It had been removed from the domain, it was workgroup status. It was placed as DHCP, which we also specified during the cutover process (admittedly I thought this setting was what was going to be set on the Azure machine, and not change the source machine). In our case I'd prefer we not change the IP of the source box, and allow the Azure VM to retain what is currently set within Azure. Currently the Azure VM is set to DHCP.
We logged in with the local administrator account on the source box, renamed it back to the old machine name, and joined it to the domain. Users could connect to it, and the shares so we "recovered" and would like to try this again.
When we ran the validate step the process did give a PASS check mark on it. However it only ran the FIRST of what looked like 8 different checks, the other checks had NOT RUN on them.
NedPyle
Microsoft
MicrosoftAh good - I was worried our cancel at the 1 hour work was totally being ignored. I think our UI could be much more clear here, that’s good feedback.
We intentionally prevent the source from keeping the same IP address because many apps/scripts/users will continue to talk to the decommissioned source after cutover. In the new feature where you can skip migration of the network we will still require that. But we’re thinking of adding a 3rd “do nothing at all here and let admins operate at their own risk” mode.
If you try this again, if you get to the 44% phase, set the destination VMs IP back to working and let it register DNS, then the migration should start working within the dns replication and timeouts. We have that overall cutover timeout so high because many environments will not have converged their AD and DNS for many hours.
Do you have a screenshot of what you mean about the validate?
We intentionally prevent the source from keeping the same IP address because many apps/scripts/users will continue to talk to the decommissioned source after cutover. In the new feature where you can skip migration of the network we will still require that. But we’re thinking of adding a 3rd “do nothing at all here and let admins operate at their own risk” mode.
If you try this again, if you get to the 44% phase, set the destination VMs IP back to working and let it register DNS, then the migration should start working within the dns replication and timeouts. We have that overall cutover timeout so high because many environments will not have converged their AD and DNS for many hours.
Do you have a screenshot of what you mean about the validate?
I can see why you would do what you do by default with the changing of the IP address. In my case I would power off the old server after cutover to preserve state in case you had to roll back. I do think having a 3rd option of letting the admin proceed at their own choosing, highlighting some risks of proceeding without the recommended changes would be good practice. Allows for flexibility.
Ok, I'll test it again,
I've attached screens of the Validate source and destination devices step of the cutover wizard. it says PASS.
When looking further into it the MIGRATION TEST RESULTS screen that comes up when you click validation shows a bunch of things NOT RUN, but the first item that says WE CAN MIGRATE is marked as PASS.
- NedPyle
Oh that's busted. We should not be showing pass after not running! Does that repro every time you run validate?
Those screen shots are fresh. Happens every time...
