General VMM Feedback

Do you have an idea or suggestion based on your experience with VMM? We would love to hear it! Please take a few minutes to submit your idea in the one of the forums available on the right or vote up an idea submitted by another VMM customer. All of the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building VMM.

This forum (General Feedback) is used for any broad feedback related to VMM. Be specific on your feedback. The more specific, the easier and quicker for us to review. Please be concise!! For more information, please see User Voice How to FAQ .

I find it frustrating when I'm moving a lot of resources around, to have to clear out the "missing" items from the library. Library should be just treated like file explorer essentially. When its gone, its gone. If people like a audit trail, the offer a "keep history for x days" then show as missing......for x days. That would be better.

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

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?

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

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.

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.

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…

It would be great to have a tool where I could add wim file, point it to internet, select updates, and the result would be fully patched VHD. (I know there are multiple things which already exists, but this would be really handy as the tools are not straightforward - converteindowsimage.ps1,dism, sccm...)

Addin functionality to add a VM to a DPM protection group on creation (Template). Make it fairly simple like the ASR integration. View protection group / DPM server in console without custom fields.
You could have a backup group for DPM servers in fabric computers, and assign them to host groups.
If a cluster or host group is protected by DPM, install the agent onto new hosts as they are added.

Fix the issue with using the DPM and VMM module at the same time maybe.

We need to have a Scale-In button for Services as we have Scale-Out button, this is confusing. However in Orchestrator we have Scale-In and Scale-Out. At the moment we need to right click the VM and delete the instance in order to Scale-in.

VMM Service seems to be very sensitive to all kinds of issues, including very small ones (network glitches, IP from non-existing pool specified for Bare Metal Deployment, etc.) and whenever something like that occurs it just crashes interrupting everything that was running before and not resuming/restarting it afterwards (i.e. cross cluster VM migration, Bare Metal Deployment, VM deployment, etc.). It would be nice if it could handle those issues in a more reliable fashion and in cases when in really needs to crash, resume or restart corresponding activities.

It would be nice if there was a good way to inject execution of custom scripts or either a way to trigger MDT (and\or SCCM) task sequence (with a support of TS initiated reboot) as a final deployment step once the host got all the needed settings from SCVMM but before it become available for placement. This step is needed to automate installation of vendor specific drivers/tools (and other software) that for whatever reason cannot be injected into the template VHDX. Currently, the workaround is to use the GUIRunOnce attribute together with auto logon in the unattend.xml file, but that's not always reliable and there's no way to know for sure if the host configuration is finished and whether it's safe to initiate post deployment activities.

It would be nice if there was a good way to inject execution of custom scripts or either a way to trigger MDT (and\or SCCM) task sequence (with a support of TS initiated reboot) as a final deployment step once the host got all the needed settings from SCVMM but before it become available for placement. This step is needed to automate installation of vendor specific drivers/tools (and other software) that for whatever reason cannot be injected into the template VHDX. Currently, the workaround is to use the GUIRunOnce attribute together with auto logon in the unattend.xml file, but that's…

This has been a known issue for close to 3 years now. Not sure how the product team (or team that creates and tests the MP) is missing it. Would love to see a fix if one hasn't already been developed...

Often times it becomes a problem when something settings get changed either through Hyper-V console or within Failover Cluster manager which makes the look in SCVMM inconsistent and may require multiple refreshes of host\cluster\vm configuration to bring it back to the synced state back again. It would be really nice if VMM agent would catch all those changes and notify VMM immediately instead of relying on periodic refresh only.

It would be nice if MPIO was supported during Bare Metal Deployment as it would make the process more resilient to SAN network spikes and not duplicate detected disks if the same LUN is presented via multiple paths.

Today we badly miss a Comprehensive patch managemt nsolution for the datacenter. SCCM is focused on single system patching, VMM just Patches the fabric and has many shortcomings. Today we use custom Scripting Solutions that are hard to mantain.
VMM is the place where to implement the datacenter patching, we need:
- maintenance Windows
- ability to set different environments (test, pilot, poduction at least)
- ability to set relationships between systems
- great compliance reporting
- straightforward tshooting logging and tools
- ability to have pre and post custom actions
...
- service dependencies (