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".

When creating a VM from template in SCVMM, the disk name (vhd file) is named the same as the VM name. 1. This makes it match the directory the vhd file is in. 2. Saves a step which if it is missed creates a VHD the same as VHD stored in the library server ("bad"). 3. This will save "errors" if people forget to rename the VHD file prior to creating the VM.

Yes, yes automation with PowerShell or some other product can address this but this should be the default behavior in SCVMM. As if you just spin up a bunch of VM's they all have the same name for the VHD file, which can be confusing. I would think this feature would not be that hard to add during VM creation using the SCVMM template. In a way the SCVMM template does it already for the name of the VM. Just use that var in creating the VHD as well.