AVD dynamic hostpool not updating

Question

AVD dynamic hostpool not updating

Hans van Deursen 50

We have set up an AVD dynamic host pool for testing.

The scaling plan properly ensures that a host is created when needed. However, the host is no longer removed after the rampdown.

We observe that the total sessions counter gets stuck.

If I log in with a user and then log out properly, the current sessions in the host pool overview are updated quickly. If I then go to Manage, Session Hosts, the total sessions on that host remain at 1.

Only when I put the host in drain mode are the actual sessions updated.

Additionally, the updating does not work properly, but that may be related to the above.

0 comments

2 answers

Your answer

Answer 1

Manish Deshpande 6,995 Microsoft External Staff Moderator

Hello Hans van Deursen,

Your dynamic host pool (using the preview dynamic autoscaling feature) relies on the scaling plan’s ramp-down settings, capacity threshold, and minimum host percentage to deallocate or delete hosts. The most common reasons hosts are not removed are missing RBAC permissions on the Azure Virtual Desktop service principal or the presence of (disconnected) sessions that prevent consolidation below the capacity threshold. The “stuck” total sessions count in the Session Hosts blade is a known portal synchronization behavior—overview refreshes in near real-time on session changes, but the detailed Session Hosts view may lag until a status-changing action (like enabling drain mode) triggers a refresh.

1.Verify and assign the required RBAC permissions (most frequent cause of scaling not working) The Azure Virtual Desktop service principal must have the Desktop Virtualization Power On Off Contributor role at the subscription level (not resource group or host pool).

In the Azure portal, go to your subscription → Access control (IAM) → Add → Add role assignment.
Select Desktop Virtualization Power On Off Contributor.
Under Members, choose User, group, or service principal and search for Microsoft Azure Virtual Desktop (or the app ID Microsoft.VirtualDesktop).
Assign and wait 5–10 minutes for propagation.
This permission is required for the scaling plan to start, stop, deallocate, or delete session hosts.

https://learn.microsoft.com/en-us/azure/virtual-desktop/autoscale-create-assign-scaling-plan?tabs=portal%2Cintune&pivots=dynamic

2.Review and adjust your scaling plan configuration

Go to Azure Virtual Desktop → Scaling plans → select your plan → Properties and Schedules.
In the Ramp-down phase, confirm:
- Capacity threshold (%) is set appropriately (e.g., 20–30 % for aggressive scale-down).
- Minimum percentage of active hosts (%) is low enough (e.g., 0 % or 10 % for testing).
- Force logoff of users is enabled (with notification and wait time) if you want hosts removed even when sessions are present.
- Maximum host pool size matches or exceeds your current hosts.
Save changes and allow the next evaluation cycle (triggered by session change events or periodic checks).
Tip for testing: Temporarily set Minimum percentage of active hosts to 0 % and enable force logoff to confirm scale-down works.

https://learn.microsoft.com/en-us/azure/virtual-desktop/autoscale-faq

3.Address the stuck total sessions counter in Session Hosts view

As you observed, enabling drain mode on the affected host forces the broker to refresh and update the session count (this is the expected way the portal reconciles the view).
Quick workaround:
1. In Manage > Session Hosts, select the host → Drain mode → Enable.
2. Wait for the session count to update.
3. Disable drain mode once verified.

For a permanent view, use PowerShell to check real-time status:

Get-AzWvdSessionHost -HostPoolName <YourHostPool> -ResourceGroupName <RG> | Select Name, Status, Sessions

Refresh the portal browser or wait a few minutes after logoff events—overview updates are faster than the detailed blade.

https://learn.microsoft.com/en-us/azure/virtual-desktop/drain-mode?tabs=portal

4.Enable diagnostics for visibility

On your scaling plan → Diagnostic settings → Add diagnostic setting.
Send ScalingPlanOperations and ScalingPlanEvaluation categories to a Log Analytics workspace.
This will log every scaling evaluation and help us (or you) see exactly why a host was or wasn’t deallocated. https://learn.microsoft.com/en-us/azure/virtual-desktop/autoscale-diagnostics

After applying the RBAC fix and reviewing the ramp-down settings, test a full logon/logoff cycle during ramp-down and let us know the results.

Thanks.

Hans van Deursen 50 Reputation points

2026-04-23T08:51:55+00:00

Hi Manish,

Thanks for trying to help me out.

I have checked the RBAC permissions and they are ok.

I also took a good look at updating the active sessions status. I can confirm that updating in manage-session hosts indeed does not happen automatically, as you mentioned. Thanks for that.

Now when I logon with 1 session, and I have a look the ScalingReasonMessage that says :

Active session hosts are at 16.67% capacity (1 sessions across 3 active session hosts). This is below the minimum capacity threshold of 40%. 0 session hosts can be drained and deallocated. Note: Scaling method is CreateDeletePowerManage, so some active session hosts that could have been deallocated might be set for deletion instead. Active session hosts available to delete is 0, but we can delete up to -1 active session hosts. Can delete as more deallocated session hosts. 0 deallocated session hosts are available to delete.

I was expecting that hosts would be deallocated and removed. Is this the right conclusion?

Or should I maybe adjust my scaling plan? For testing I have a maximum of 5 hosts, minimum of 1 host, and 40% threshold
Manish Deshpande 6,995 Reputation points Microsoft External Staff Moderator

2026-04-24T10:53:27.2833333+00:00
Hello @Hans van Deursen

Yes, based on the current configuration, autoscale is behaving as designed. It will not reduce below the enforced minimum percentage of active hosts, even when usage is very low. This is intentional to maintain a baseline of available capacity.

Recommended adjustments for testing (to allow hosts to be deallocated/removed):

1.Lower the Minimum percentage of active hosts (%) in the Ramp-down phase

Go to your scaling plan → Schedules → edit the Ramp-down phase.

Change Minimum percentage of active hosts (%) from its current value (likely contributing to the floor) to 0% or 10% for aggressive testing.

This tells autoscale it can reduce the number of running hosts toward your Minimum host pool size (you mentioned 1).

Save the changes. The scaling plan evaluates on session change events (logon/logoff) or periodically.

2.Review and adjust these related settings in Ramp-down:

Capacity threshold (%): 40% is reasonable, but you can test lowering it slightly (e.g., 20–30%) for more aggressive scale-down.

Force logoff of users: Enable this (with notification period) if you want autoscale to log off disconnected/idle sessions to free up hosts faster.

Load balancing algorithm: Depth-first is often better for scale-down testing as it concentrates sessions on fewer hosts.

Confirm Minimum host pool size = 1 and Maximum host pool size = 5 (as you set for testing).

3.Trigger a fresh evaluation

Have the single user log off completely.

Wait a few minutes (or force a refresh by toggling drain mode on one host temporarily).

Monitor the ScalingReasonMessage again in the diagnostics or portal.

Check the host pool overview and Manage > Session Hosts for changes in running/deallocated hosts.

After these changes, with only 1 session (or 0 after logoff), you should see hosts being deallocated (or deleted, depending on the exact dynamic logic) until it reaches your minimum host pool size of 1.

Detailed explanation of minimum percentage of active hosts :
https://learn.microsoft.com/en-us/azure/virtual-desktop/autoscale-create-assign-scaling-plan

Thanks,
Manish.
Havok 0 Reputation points

2026-04-24T11:09:20.2333333+00:00

I'm having the same issue I believe. My hosts use ephemeral disks and my minimum percentage of active hosts is 100%.

Originally during ramp down and off peak, it would delete hosts but now it tries to deallocate which is not possible due to use of ephemeral disks.

It turns out a delete lock on the resource group changed the behaviour and even after removing it the behaviour did not revert.

I had to modify the scaling plan, save, then modify it back to original for deletion to work again.
Manish Deshpande 6,995 Reputation points Microsoft External Staff Moderator

2026-04-27T14:23:27.1733333+00:00

Hello Hans

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Manish Deshpande 6,995 Reputation points Microsoft External Staff Moderator

2026-04-28T12:00:22.9466667+00:00

Hello Hans

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.

Answer 2

In a pooled Azure Virtual Desktop host pool that uses the session host configuration management approach and autoscale, autoscale decisions are based on host pool capacity and user sessions, and it also overwrites drain mode on pooled hosts.

Key points relevant to the described behavior:

Session host configuration management constraints
- When a host pool is configured with a session host configuration, all creation, update, and scaling of session hosts must be done through the Azure Virtual Desktop service using the native features (session host configuration, session host management policy, session host update, and autoscale). External or manual management tools designed for standard host pools must not be used for creating, updating, or scaling session hosts.
- The session host configuration persists for the lifetime of the host pool and is kept aligned with the session hosts via the session host update feature.
Autoscale behavior and drain mode
- For pooled host pools, autoscale overwrites drain mode on all VMs that are included in scaling. Any manual drain mode settings are not preserved during autoscale actions; autoscale will turn VMs on or off and change drain mode as needed according to the scaling plan.
- If a VM must be excluded from autoscale actions (including drain mode changes), an exclusion tag must be used. Without an exclusion tag, autoscale can change drain mode and power state even if drain mode was set manually.
How autoscale decides to turn off hosts
- Autoscale uses parameters such as capacity threshold, minimum percentage of hosts, maximum session limit per host, and the current number of user sessions to determine whether it can safely turn off a session host.
- During ramp‑down, autoscale will only turn off hosts when doing so keeps the used host pool capacity below the configured capacity threshold and still respects the minimum percentage of hosts. If turning off another host would violate either condition, autoscale will keep the host running even if it appears underutilized.
- Autoscale chooses the host with the fewest user sessions to turn off. If the force logoff setting is enabled for ramp‑down, autoscale can put the host in drain mode, notify users, and then forcibly sign them out after the configured wait time before shutting down the VM. If force logoff is not enabled and there are still active sessions, autoscale will not force those users off outside the ramp‑down phase.
Forced sign‑out limitations
- Forced sign‑out can only occur during the ramp‑down phase when the force logoff setting is enabled in the scaling plan. During off‑peak or other phases, autoscale does not forcibly sign out users; it waits for users to sign out before deallocating the VM.
- If the ramp‑down window is shorter than the configured wait time for forced sign‑out, users might not be forced off before the phase changes, and the VM will remain running with sessions.
Impact on “total sessions” and updates
- Because autoscale can override drain mode and only forces logoff under specific conditions, a host can remain available with sessions in certain phases, which may appear as “total sessions” not decreasing as expected.
- If session host update is configured, updates are applied according to the session host management policy (time zone, batch size, logoff delay, logoff message, and whether to leave new hosts in drain mode). If autoscale is simultaneously managing drain mode and host availability, hosts may not enter the expected state for updates unless the scaling plan and update schedule are aligned.

To restore expected behavior:

Ensure the host pool is indeed a pooled host pool using the session host configuration management approach and that all host lifecycle operations are done through Azure Virtual Desktop (not external tooling).
Review the scaling plan:
- Confirm capacity threshold, minimum percentage of hosts, and maximum session limit so that autoscale can safely turn off hosts during ramp‑down.
- Enable force logoff in the ramp‑down phase if hosts must be drained and shut down even when users remain connected.
- Ensure the ramp‑down duration is long enough to accommodate the wait time before forced sign‑out.
If a particular host must not be controlled by autoscale (for example, for testing update behavior), apply an exclusion tag so autoscale does not change its drain mode or power state.
Align the session host update schedule with the autoscale schedule so that hosts are in the correct state (including drain mode) when updates are applied.

References:

Share via

AVD dynamic hostpool not updating

2 answers

Your answer