Forum Discussion
Cutover Timeout recommended settings
MicrosoftHi John. Can you tell me what the "State" column shows on the WAC cutover UI when it's stuck?
If you chose static IP for the destination, cutover to Azure isn't going to work automatically. Azure does not support L2 networks, it's just a whole new network - but then if you put on an on-prem IP address on that, the VM will become unreachable. We are adding an option in a coming update to skip static network migration to the source for this very reason. And we will give better hints and advice in the UI before you accidently shoot yourself.
The 60 minutes expiring should have ended this, that's just a bug on our end, perhaps in the UI itself. You can use Stop-SMSCutover to end this wedged cutover state. If you attempt the cutover again (until we provide the update to make Azure IaaS work properly), once you get to 44% you can just go set the VMs IP address to DHCP in Azure itself so that the cutover can resume and complete.
- Ned
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.
- NedPyleAh 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?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?
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.
