As discussed in the following forum topic:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/917c90d5-f7f4-454c-825b-fe0f28592978/cannot-create-vm-from-gen2-template?forum=virtualmachingmgrhyperv

I am not able to fix whatever causes error 23352 to be thrown after
- Creating a new generation 2 Virtual machine
- Booting, installing and configuring the machine
- shutting down the machine
- Creating a VM template from the VM
- Enabling "Create a differencing disk using the specified disk as parent"
- Trying to create new virtual machines from the template.

After the VHDX was deployed to the host(s) and differencing disks are to be created, error 23352 ("VMM cannot find the device or this device is not valid for a boot device") is thrown.

KB2955362 suggests to manually set the boot device to the disk which contains the OS. I use that command, but it did not fix the issue.

There is no hint on what exactly may be the cause of this error.

Sometimes it helps to create a new VM template after changing the name of the VHDX file of the original VM. But sometimes this does not help.
In the forum topic mentioned above it was posted that this issue still occurs in SCVMM 2016.

With options like Dynamic Disk and Memory allowing you to get the most out of your resources. It would also make sense to allow end users to oversubscribe resources.

Turned off Virtual Machines count towards cloud limits and therefore users cannot easily switch between workloads in a lab environment without an offline Library. When users work with multiple VMs for a test and can switch multiple times in a day it makes little sense to force the Library usage as they cannot export VMs from the Library until the cloud is clear enough. This leads to countless lost hours waiting for VMs to import and export from the Library.

TL;DR - Is there any chance that VMMAgent will ever use SMB Multichannel for file transfers?

I understand that VMMAgent does stuff over 443 (or 80 if specified) for file copies. If there's an ODX-capable storage provider, then it will leverage that. Otherwise, it will try "Fast File Copy" and then BITS over HTTPS (or HTTP if specified).

My question (or feature request?) stems from the fact that Microsoft is pushing these great new technologies as the bee's knees - Storage Spaces Direct (S2D), SMB Multichannel, Converged Networking, VMM + WAS, etc. Why can't VMM use them?

In a multi-NIC environment, couldn't VMMAgent be improved to be a little "smarter"? If there's a faster route, use it. The ODX functionality is already built in to pass transfers over various protocols depending on providers, why not extend this to SMB Multichannel?

When adding a new Windows 2016 Hyper-V cluster to SCVMM, all VM's deployed to the new Windows 2016 cluster automatically deploy from SCVMM as a configuration version 8.0 machine. In order to allow time to upgrade all other Hyper-V Servers still running Windows 2012, it would be good to have the option to have a choice of configuration version of the VM. This is currently only possible if creating a VM directly on the Windows 2016 Hyper-V server itself. When creating VM's directly on a Windows 2016 Hyper-V server one can use the cmdlet "New-VM" and specify the configuration version using "-Version". The problem is that you cannot migrate any VM's off a Windows 2016 Hyper-V server back to a Windows 2012 R2 Hyper-V Server without the configuration version being 5.0. If any of our new Windows 2016 Hyper-V servers had an issue we will be in deep trouble, being unable to migrate any configuration version 8.0 VM's off to any other of our Windows 2012 R2 Hyper-V servers. Please consider adding this same option to SCVMM (New-SCVirtualMachine) and Windows Azure Pack (New-WAPackVMRole). This would be extremely helpful to maintain VM's across SCVMM, while we make progress in converting to Windows 2016 Hyper-V across all infrastructure.

It would be helpful to have an RSS Feed or email distribution so when "known Issues" internal to microsoft are "known", the community in general will also know.

for example, there was a hotfix for an issue created with UR12 for system center affecting replication. Our engineering team had to open a case with microsoft.

https://www.microsoft.com/en-us/download/details.aspx?id=54854

Admittedly, in this case, the title of the article for the hotfix does not imply that it fixes our specific replication issue which was caused by UR12 but when we call in and are told it is a "known Issue", it would be nice to "Know" it is a "known issue".

This has caused business risk for us since we do expect replication is happening in case of recovery so if this replication is not happening, we are at risk with downtime.

I realize communication can be an area of "you send to much" or "you don't send enough". In the case of known issues... I'd rather know of one and ignore than to not know and be troubleshooting.