I know System requirements for System Center Virtual Machine Manager (https://docs.microsoft.com/en-us/system-center/vmm/system-requirements?view=sc-vmm-2019) does not list Server 2012 R2 Hyper-V as being a supported Hyper-V host in a VMM 2019 environment. And there's a difference between "not officially supported" and "officially not supported". VMM 2019 simply does not allow you to install its agent on a Server 2012 R2 Hyper-V server:

Error (20523)
The verslon of the Windows operating system on the computer xxxxx is not supported for a host.

Recommended Action
Upgrade the operating system to Windows Server 2016 or a later supported version, and then try the operation again.

So if you're planning to upgrade from a Hyper-V 2012 R2 environment to Server 2019: you can't do it using VMM. We're adapting our plans using an intermediate 2016-environment, but that's not easy.

Funny thing: ESXi 5.1, which is even older than Hyper-V 2012 R2 IS supported... So please, Microsoft: support your own stuff if you want your customers to remain loyal and make it possible to migrate from a Server 2012 R2 Hyper-V environment to a Server 2019 Hyper-V environment using VMM.

Currently, a Service Template requires Machine Tiers defined by using a VM Template. This VM Template can be preexisting (in the Library) or created in the Service Template Designer.

At deploy-time, VM Templates will always mount an ISO file with an unattend.xml file, containing info like Windows License Key, hostname, IP addresses, etc. The deploy job will sit and wait until the VM is shutdown, which results in the job completing successfully.

Although uncommon, there is sometimes a need to deploy Windows VMs that are not sysprep'd, bypassing the out-of-box-experience (OOBE). An example of this would be in training or virtual lab environments, where you cannot script all customization out. Yes, you run the risk of IP and hostname conflicts, but if you're using SDN, this shouldn't be an issue.

There is currently no way to use Service Templates in this type of requirement (due to the above-described way VM Templates are deployed). If you actually specify a non-sysprep'd VHDX, this process will "work", but the VMM job will wait until it times out. You can manually shut down the VM (from Hyper-V or FCM) and trick VMM into thinking everything finished successfully, but that's obviously not the way to handle this.

I propose allowing for VM Templates to have an option to "bypass" the sysprep/OOBE step. I envision the Configure Operating System tab having this on by default, but perhaps a checkbox somewhere that allows for no configuration to be compiled into the unattend.xml and ISO.

SCVMM (VMM) & S2D should support cross-cluster migration of highly available VMs.

Migrations of highly-available VMs from one cluster to another while using S2D and SOFS as a storage solution (NOT hyper-converged) should be supported by VMM.

VMM has built-in functionality to allow migration of a VM from one cluster to another.

This does NOT work with HA VMs when your storage solution is SOFS on S2D. The VM will be placed in pause-critical, effectively a failed migration.

I believe this is a shortcoming on the part of Failover Clustering not properly handling storage communication, but not sure as this action isn't able to be automated outside VMM.

I have now tested this in Windows Server 2016, 2019, with VMM 2016 and 1807 and it doesn't work.

The VM is stopped in a 2016 environment and put into a paused-critical state in 2019. This appears to be due to some unseen error and the default AutomaticCriticalErrorAction, but I'm not sure.

This is functionality which worked under 2012 but S2D wasn't an option, so my guess is this is a failing as a combination of VMM, failover clustering and S2D w/SOFS as storage.

Note that this DOES WORK ONLY when migrating TO the Current Host Server (as shown in FOC Manager) on the target cluster.

Using a Logical Switch object for deployment in a cluster is a time saver and above all mitigates or removes human error by eliminating repetitive tasks. Problem arises AFTER the Logical Switch has been deployed and a modification/change is required, ex; if an additional vNIC is required upon adding it within the Fabric/Logical Switch it is NEVER flagged as non-compliant, hence can never be Remediated. If managing many servers and such a change is required, the only way is to either manually modify each server or create an additional Logical Switch, then remove/add logical switches. This is by no means the proper manner to address a networking change from a "management console".