Avd dynamic scaling, a lot of questions

Use Case 1: Keeping the Custom Script Private

When AVD dynamic scaling provisions a new session host, the custom script must be downloaded and executed at the appropriate stage of deployment. If the script is hosted in Azure Blob Storage behind a private endpoint, the download requires working DNS resolution, network connectivity, and authorization at that stage. If the host can access the storage account only after deployment, investigate the actual DNS configuration, private DNS zone links, subnet routing, and the component responsible for downloading the script. Do not assume that DNS propagation timing is the cause without checking the deployment logs and effective network configuration.

Private blob storage with managed identity

This is a suitable architecture when the deployment mechanism supports identity-based authentication for the script download. Create a user-assigned managed identity and grant it the Storage Blob Data Reader role at the narrowest practical scope, such as the script container. Attach the identity to the session host VM or make it available to the component performing the download, as required by that component's authentication model. Disable anonymous Blob access and public network access if the security requirements call for private-only storage.

Note that attaching a managed identity to a VM does not automatically authenticate a Custom Script Extension download. The standard Windows Custom Script Extension must be configured according to its supported download and authentication capabilities. If the extension cannot use the assigned identity to retrieve a protected Blob directly, use a bootstrap process that can authenticate and download the script, package the script in the image, or use another supported provisioning mechanism. A private endpoint still requires correct private DNS resolution and network connectivity. Managed identity provides authentication and authorization, not network access.

SAS URL with restricted storage access

If the deployment mechanism supports only a URL, a short-lived, read-only Shared Access Signature can provide authenticated access to the script without enabling anonymous Blob access. Scope the SAS to the required Blob, restrict its permissions, and use an appropriate expiration time. Protect the SAS URL as a credential and rotate it through an automated process.

A storage firewall can restrict access to selected networks, but the permitted network must match the actual download path. If the VM accesses Blob Storage through a service endpoint, configure the relevant subnet and storage service endpoint. If it accesses through a private endpoint, configure the private endpoint, DNS, and routing. Allowing a subnet through a storage firewall does not, by itself, make a private endpoint work or guarantee that a request from the deployment component will be permitted. Also verify whether the selected deployment mechanism supports the intended network path.

Before selecting either option, establish whether the custom script URL is consumed by the standard Custom Script Extension, a VM application, an ARM/Bicep deployment component, or the dynamic scaling product itself. The supported authentication options depend on that implementation.

Use Case 2: Managing ephemeral session hosts in Entra ID and Intune

Deleting an Azure VM does not automatically guarantee immediate deletion of its Microsoft Entra ID device object or its Intune managed-device record. For ephemeral AVD hosts, implement an explicit lifecycle cleanup mechanism so that stale objects do not accumulate and affect inventory, compliance reporting, dynamic group membership, or license management.

Intune device cleanup rules are useful for reducing stale-device visibility, but they are not a substitute for prompt lifecycle cleanup. They do not delete the corresponding Entra ID device object, and cleanup rules are based on inactivity rather than confirmation that the underlying Azure VM has been deleted. Their configured retention period must also be considered.

Event-driven cleanup

Use Azure Event Grid to subscribe to successful Azure resource deletion events, such as Microsoft.Resources.ResourceDeleteSuccess, scoped to the relevant resource group or subscription. Route matching VM deletion events to an Azure Automation runbook, Azure Function, or Logic App that initiates cleanup.

The workflow should identify the deleted VM and correlate it with the correct Entra ID device object and Intune managed-device record. Do not assume the Event Grid event contains all the identifiers needed for both directory services. Maintain a mapping of VM resource IDs, computer names, Entra ID device IDs, and Intune managed-device IDs, or use a controlled lookup process.

Once the workflow verifies that the VM is no longer present and that the records belong to that VM, use Microsoft Graph to delete the Entra ID device object and the Intune managed-device record. Handle retries, delayed events, missing records, and partial failures. Use a grace period if VM deletion and replacement can occur close together.

Daily scheduled reconciliation

If event-driven cleanup is not practical, use an Azure Automation runbook or another scheduled process to reconcile Azure VM inventory against Entra ID and Intune. Run it daily or at another interval appropriate to the rate of host creation and deletion.

The script should enumerate the intended ephemeral AVD hosts, check whether each corresponding Azure VM still exists, and identify the associated Entra ID and Intune records using stable identifiers. Delete only records that have been confirmed stale for a defined grace period. Do not rely solely on a computer-name prefix, because names can be reused and records may belong to replacement hosts.

For Microsoft Graph, the automation identity needs the permissions required to read and delete the relevant records. Application permissions commonly include Device.ReadWrite.All for Entra ID device objects and DeviceManagementManagedDevices.ReadWrite.All for Intune managed-device records, subject to the API operations and tenant authorization requirements. Grant admin consent and use least privilege wherever possible. The corresponding PowerShell operations include Remove-MgDevice and Remove-MgDeviceManagementManagedDevice.

My suggestion would be to use event-driven cleanup for prompt removal, backed by a scheduled reconciliation job that catches missed events and partial failures. Log every deletion, retain sufficient information to investigate failures, and validate the identity mapping before removing either record. Removing a device from an Entra ID dynamic group is not equivalent to deleting its device object, and deleting the Intune record is a separate operation.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin