I think there is a concern with the new Web Client URLs. I thought to discuss this point here to give more clarity.
Update: The new web client URL works fine with all the browsers and gives the same experience as the previous web client URLs. I can't reproduce the below explained different experiences anymore. I think the issue was already there in the first screenshot below. It seems I used the wrong URL or it got redirected to the wrong web client URL.
It seems there is consent required for new client URLs only if you access them from the Microsoft Edge browser where you logged in to your personal profile. This is also applicable to all the other browsers if your work account doesn't appropriate license.
I have tested with Firefox and other browsers and the new web client URL just works just fine if the user account is assigned with the correct licenses and of course, the user is already logged with the current AVD web client URLs.
The following was the previous experience with web client URL when I tried to log in from Microsoft Edge Personal profile login and for the work profiles where you don't have the appropriate license to access AVD.
The change in the end-user experience with the new URL is going to create some confusion within the AVD community.
Overall consent message is going to create a lot of confusion for the end-users and IT admins because this was not the experience previously used AVD web client URLs.
If you don't have appropriate permissions on Azure AD, then this is going to create some delays in the transition process to new AVD URLs.
Select consent option Select "Server App" to give the consent to the back-end web app to a specific tenant Select "Client App" to give the consent to the front end client app to a specific tenant Please note that if you choose to consent to "Client App" only, then the user will need to consent at every sign-in. Also, allow 30 seconds delay between consenting "Server" and "Client" apps so that the changes are propagated in Azure.
You can use either SCCM (latest 2203) or Intune to manage AVD VMs (including multi-session). I would prefer the modern management with Intune and if your physical devices are Azure AD joined then AVD VMs should also be Azure AD Joined instead of Hybrid Azure AD.
Managing AVDs with SCCM is useful if you already have an SCCM infra in place and you know how to read SCCM Logs :) You can move AVDs slowly into Co-Management or Cloud Attach in a phased approach later.