AVD Hibernate on Azure Local
We're working to deploy AVD on Azure Local to improve performance of our apps. We have a set of users that work infrequently, but have a need to keep their session persistent between "Shifts". In a personal host pool setup, we're finding our current options cost prohibitive with the avd management costs for azure local based deployments. A solution that would allow hibernating the VMs during periods of inactivity would be the best case for our needs.
Need insight to domain join failures for session host configuration
We are trying to use the session host configuration for a new AVD host pool. We have confirmed that it can join computer to the specified OU without difficulty when we do it manually, and that the key vault access is intact since the local admin is created without issue. But any new session hosts fail to join to the domain. They're created with all other specifications. If we try to add them manually it seems to create some kind of instability in the FSLogix where it will then permanently hang for users when trying to log off. It would be good if we had insight to the domain join failures so we don't have to manually join them. In the deployment I can see the network, the VM, and a DSC, but that DSC is only for joining to the AVD Host pool. I don't see anything in it to join using the key vault credentials.Integrate AVD Session Launch at the Windows Login Screen (Similar to Windows 365 Boot)
I propose that Azure Virtual Desktop (AVD) be integrated directly into the Windows login process, similar to how Windows 365 Boot operates. Currently, users must first log in locally and then manually start the AVD client. By enabling AVD to launch as part of the initial login (with Single Sign-On support), the transition from the local environment to the cloud-hosted desktop would become seamless, mirroring the convenience provided by Windows 365 Boot. (What is Windows 365 Boot? | Microsoft Learn) Benefits: Enhanced User Experience: Users would access their AVD session immediately after logging in, streamlining their workflow. Simplified Process: Eliminates the need for additional login steps or manual client launches, reducing complexity and potential errors. Efficiency Gains: Particularly beneficial for thin clients and shared environments, this integration would lead to a more efficient deployment and use of resources.Pad Session host name with Leading Zeros
When adding session hosts to a pool you declare a prefix and the template will append an incrementing number to the end. but this number is not a consistent length due to the lack of leading zeros. and in large host pool, this causes the hosts to not sort properly Current Example of Bad Sort Desired Test-VM-1 Test-VM-1 Test-VM-001 Test-VM-2 Test-VM-10 Test-VM-002 Test-VM-3 Test-VM-11 Test-VM-003 Test-VM-4 Test-VM-12 Test-VM-004 Test-VM-5 Test-VM-2 Test-VM-005 Test-VM-6 Test-VM-3 Test-VM-006 Test-VM-7 Test-VM-4 Test-VM-007 Test-VM-8 Test-VM-5 Test-VM-008 Test-VM-9 Test-VM-6 Test-VM-009 Test-VM-10 Test-VM-7 Test-VM-010 Test-VM-11 Test-VM-8 Test-VM-011 Test-VM-12 Test-VM-9 Test-VM-012
Provision AVD VM's with requested drive size, rather than resizing/upsizing
When building new Azure Virtual Desktop hosts via the AVD portal, if you select an OS disk size for the host that is anything other than the default 128GB, the host is provisioned with a 128GB disk and then resized/upgraded as part of the VM's build process. The problem with this is that the OS volume is still the default 128GB and needs to be manually extended after the host has been built. This detracts from the otherwise impressively polished process of provisioning AVD hosts in the Azure portal, where it's clear a lot of automation already takes place as the VM is created and set up for AVD. I have not been able to find mention of the need to extend the OS Volume after provisioning in the Azure Virtual Desktop documentation, nor was it clear that this would be required when selecting 256GB OS Disk size during host creation. If the host were created with a 256GB OS Disk from the beginning (rather than upsizing) I anticipate this would solve the need to extend the OS volume manually afterward. Alternatively, if its possible to automate extending the OS volume to utilise the full disk size after it has been resized that would also address the problem
Save settings and RDP data locally or to the cloud
Have the ability to encrypt and save settings and RDP data (IP Address, optional credentials, etc.) locally or to the cloud so as to enable an easy and quick reprovisioning of the app on a new device. Imagine having to setup new RDP connection profiles for 50+ devices. It's time consuming.
