Cutover Timeout recommended settings

Thanks for the help Ned.

What I'd recommend instead for Azure IaaS currently is:

1. Migrate to an on-prem VM

2. Use ASR to move that VM to Azure, and then turn off ASR for that VM so it's not continuously protected (i.e. lift and shift), so you don't pay for anything. https://azure.microsoft.com/en-us/services/azure-migrate/

But you'll need to figure out why DNS registration is broken, or manually register the DNS entries so that cutover can complete (it will if you do that; we've had one lab here with no DNS auto-registration allowed and that was my solution there).

Ned,

Thanks for jumping in on this thread.  I have started another one around SMS Inventory process, and need assistance there as well, as I have three servers that are "failing" inventory.  They each take over 24 hours to progress very little. No indication in the logs as to what is wrong, and everything I end up manually cancelling.  Same environment as this one server that did inventory properly.

I would appreciate any thoughts you can share on this thread, if you have time.

I'm 0 for 3 on the support technicians for this case currently they're passing it to another group.

r/

john

Thanks, for the reply Ned

I'll check on the DNS registration.  From what I see in AD right now, it is set for nonsecure and secure updates, so the devices that get suffix and ip information and cannot be domain joined should show up appropriately.  This would be one of those boxes.  I'll check on it though.

So for this particular project i won't be able to wait until the skip the networking feature is available.

What exactly happens in the cutover piece?  I think I remember reading in the documentation that I could stop after transfer if I didn't want to actually assume the identity of the old file server on the new one.  If all I have to do is shut down the old file server, and rename the new one manually and I'm done then I'll do that manually.  If there are other steps that I'm missing out on with the cutover process can you share what happens?

Yes, until we give you the option to skip networking that I mentioned before (coming in an update in a month or two), IaaS VM is not something SMS currently supports. Anything you do right now is hacking. 

For the source computer though, that is something entirely unrelated and should be working fine here. Is the DNS  server IP address(s) being assigned by DHCP or set statically? I need to understand exactly how to repro this. That it's not registering with DNS is the real issue here - did your customer disable automatic DNS registration?

Ned,

How is this supposed to work.  I've been able to repro my issue EVERY TIME now.  All settings according to the documentation are correct from firewall ports and user account privileges.  Here's what I see happening.

To recap, I am taking an on prem file server, and cutting over to an IaaS VM in Azure which is supported by the documentation.

My VM in Azure is on a completely different subnet, and you CANNOT specify an IP address on the physical NIC, WITHIN windows, and have the IaaS VM be accessible.  So unless I'm cutting over an entire subnet of addresses that this on prem VM belongs to, MOVING the on prem vm address to the IaaS VM is going to fail.  It's going to fail regardless because the process sets an IP address within windows, which breaks Azure.

1.) at the beginning of the cutover process during the ADJUST SETTINGS part of the Wizard I cannot proceed unless I choose DHCP as my option for the SOURCE computer.  If I specify an address, the same address that the on prem NIC is set to, it won't continue.  I continue on this step with DHCP

2.) the process has removed the computer from the domain, and the process had changed the ip address on the server to DHCP and this is where it appears to fail, as the server gets a new address, but does not register with DNS.  DHCP at my customer location is handed out by a router in their network and not a Windows DHCP server.  DNS is handled by AD.  the DHCP server affixes the appropriate suffix to the computer when it gets a DHCP address, AND appropriate AD DNS servers, yet still does not register in DNS.

3.) The process reports 44% waiting to join the source computer to the domain.

4.) I login to the console of the VM through Hyper-V manager using a local account, and check the status of the box.  It is in a state of "this computer will be renamed on reboot" with the new name that I've specified as the name the computer will become.  I reboot the computer manually.

5.) I login to the console of the VM with a local account again. The VM does nothing.  I manually add it to the domain and it reboots.

6.) the progress indicator has now moved on the process, and proceeds to 72% "mapping network interfaces on destination computer"  This will fail because my machine is in Azure.  

NOW ONTO THE DESTINATION VM IN AZURE

7.) I attempt to connect to the VM  using the IP address dynamically assigned to the NIC from the Azure VNET. I cannot RDP into this box, my assumption is that the process has changed the ip address on the ONLY nic on this box to match the on prem IP address.

8.) I create a new nic, shut down my VM, attach the new nic, boot the VM, and am Able to connect to the box via RDP on the new NIC ip address which has been dynamically assigned by Azure.

9.) The machine is in a state of

a - removed from the domain

b - primary nic has assumed the ip configuration for the on prem network (which is not valid in azure)

c - machine name has not been renamed to the on prem VM name.

10.) I mark the NIC within Windows to be DHCP.  I restart the box.  It is appropriately set to DHCP

11.) The machine name is still set to it's current name, so I manually rename it to the on prem file server name.  Join it to the domain and restart.

12) the machine comes up renamed as the old file server on prem. Joined to the domain, the SMS cutover job stays at 72% and does not complete.

13) Upon each and every reboot of the server in Azure, the IP address of the first NIC assumes the IP Configuration of the on prem server within Windows.  

14.) My job times out at 60 min.  I'm unable to complete the process of cutting over from an on prem vm to an Azure VM. 

Ned, lemme know where you want me to send them.  I just started a new Get-SMSLOGS

I uploaded a set of logs for ticket 119012925004530 earlier today.  If you can somehow get them internally.  

john