We will take 20 steps backwards by creating an ADDS or AD server just to in the end utilize our Azure AD authentication.

WVD should support native Azure AD join and authentication.

Currently invited guest users from other Azure AD tenants cannot access WVD in the "inviting" AAD. We are forced to create new "twin" user accounts.

Management of WVD via Intune and AAD, without on-prem AD requirement.

add true autoscaling like vm scaleset which will add host in hostpool if all session hosts are full with sessions or cpu/ram is full and remove session host if its not used or dont have sessions. also consider minimum / max session host count for each hostpool while scaling up/down.

whatever WVD autoscaling runbook we have on github is actually auto shutdown/start during peak / non-peak hours which is not true auto scaling.

At the time of writing WVD host pools can only contain VMs that run on Azure or Azure Stack Hub.
If hybrid networking is setup correctly, Host Pools can also be hosted on Azure Stack HCI. This opens up a broad use-case for organizations.

Logging into the portal and then again when connecting is a pain for users. Please enable true SSO.

What are the plans for supporting MSIX app attach on windows server. So far all I found was about windows 10 ent or multi session. MSIX is available on WS why not MSIX app attach.

As a bank, we have a concern of data leak when we allow user to use WVD to connect to on-prem server/services. We need to have the ability to:
- Allow copying data from user's endpoint (laptop, PC) to WVD
- Block copying data from user's endpoint (laptop, PC) to WVD
- Allow copying data from WVD to user's endpoint (laptop, PC)
- Block copying data from WVD to user's endpoint (laptop, PC)

Today if we allow or block, it will be bi-direction, which is not sufficient to address security risk: it could be either too loosely, or too strictly.

In the contact center scenario, the agent supervisor often has to monitor the service and help the agents by viewing the agent's screen. This functionality could be available to a user with a profile as a supervisor and not to the machine admin.
The WVD could have a functionality like that where teh Supervisor type the agente ID and connect to agente session to help or whatch the screen.

We use some Azure Automation to allow the users to Self Service their Logoff when application freeze the WVD session.

For WVD classic it was this command: invoke-RdsUserSessionLogoff and it worked fine.

For WVDv2 (Spring Update) it is this command: Remove-AzWvdUserSession

And it fails horribly because we make it a best practice to put a delete lock on the Resource Groups.

So please make "Remove-AzWvdUserSession" work when a Delete Lock is in place, or rename the command to invoke-AzWvdUserSessionLogoff.

Thank you very much!

Remove-AzWvdUserSession

As per WVD documentation (https://docs.microsoft.com/en-us/azure/virtual-desktop/data-locations), WVD only supports storing metadata in the United States (US) Azure geography. This is a request for WVD to provide an option to store metadata in Canada. Despite the at-rest encryption of WVD metadata, Canadian residency of this metadata is a strong requirement for many of the Canadian federal government departments and agencies.

When using either a WVD Desktop or App, Teams is using the System Time instead of the user's time zone when posting conversations. I can see the clock on a desktop and that matches my time zone. When I post a conversation, Teams is using the System Time of the server which is default UTC.

Add a session host deployment option so that we can deploy new session hosts straight away in drain mode. We have some scenarios where we need to do some tasks before allowing connections. Would be good to be in drain mode as soon as it's deployed.

Operating from South Africa I created a test VM on Windows Virtual Desktop and the response was not great considering that it was deployed it in South Africa North DC. The best RTT was measured at 226 ms whereby 150 ms or less is required for an acceptable experience. This was mainly due to the session controller service being managed from a US DC.

The lack of support for this is the single reason that Remote App could not be used in a customer scenario. Having to switch to a Full Desktop just for OneDrive sync creates multiple problems that could have been avoided if Remote App's could be used instead.
In this specific scenario, OneDrive is needed in the WVD environment because of certain tasks that require interaction with data on SMB shares and data in individual user OneDrive accounts from the WVD session.

Currently in a personal WVD Pool ( not a Pooled one) there is no way to simply unassign a user and mmake the same sessionhost vm available for other user. This create problem when a user resigns. The only option is to delete sessionhost and then uninstall and install the wvd remote agent with a newly generated token which is a very lengthy and tedious task to perform on a daily basis. It will be better if there is a simple unassign method using which a VM is ready to be available again in a Personal Pool

Seems like a straightforward ask that we be able to either configure a default feed (already possible with on-prem RDS) at time of install or through a command like parameter that can be passed to the MSRDCW.exe.

As a previous user mentioned, we need a more seamless way to deploy this functionally rather than asking users to perform “one more login.”