Azure Host Pool validation environments and agent versions

Question

Azure Host Pool validation environments and agent versions

SebastianD-5208 0

Hello there,

we are currently trying to narrow down a problem regarding crashes in AVD & have noticed the different agent versions on our envionments.

Many of our hosts run on validation versions according to https://learn.microsoft.com/en-us/azure/virtual-desktop/whats-new-agent . (e.g. 1.0.15294.200, 1.0.15008.300, 1.0.15008.200)

Due to an error in our IaC configuration they corresponding hostpool had the validation environment flags set to "Yes" which I thought explained the agent version. However, after setting the host pool flag validation environment to "No", deleting and redeploying the hosts, they still get a non-production version of the avd agent.

Am I understanding the flag wrong? My expectation is, that non-validation environments shouldn't get validation versions of agents. Is there any way to force a downgrade of the agent or simply an install & fix on production versions only for a host pool?

0 comments

3 answers

Your answer

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 2

Yes, your understanding is largely correct. The Validation environment setting determines whether a host pool participates in the validation update ring and receives updates earlier than production host pools. However, it is not an agent version pinning or rollback mechanism.

When you change: ValidationEnvironment = No

you are preventing the host pool from receiving future validation updates, but Azure Virtual Desktop does not automatically downgrade session hosts that have already received a newer agent version.

A few things are worth checking:

1. Verify the host pool configuration

Get-AzWvdHostPool `
  -ResourceGroupName "<RG>" `
  -Name "<HostPool>" |
  Select-Object HostPoolName, ValidationEnvironment

Confirm that ValidationEnvironment is set to False.

2. Review your provisioning process

Since you mentioned an IaC issue, check whether Terraform, Bicep, ARM templates, DSC, custom scripts, or your VM image are:

Installing a specific AVD Agent version.
Containing a pre-installed AVD Agent.
Downloading a cached or bundled agent installer.
Applying additional configuration independent of the host pool setting.

3. Validate the agent version against the current release table

Do not assume a version is still a validation-only release based solely on its numbering. Compare the exact version with Microsoft's current AVD Agent release history:

https://learn.microsoft.com/azure/virtual-desktop/whats-new-agent

Some versions that were initially released through validation can later become part of the broader rollout.

Can you force a downgrade ?

There is no host pool setting that forces a downgrade or pins session hosts to a specific production agent version. The Validation environment flag only controls participation in the validation ring. Agent installation and updates are managed separately.

For troubleshooting, a useful test would be:

Create a new host pool with ValidationEnvironment=False.
Deploy a brand-new VM from a clean image.
Register it to the host pool.
Record:
- AVD Agent version
  - AVD Agent Boot Loader version
    - VM image/version
      - Provisioning method
      1. Monitor whether the agent updates and what version is ultimately installed.

If a completely fresh session host connected to a host pool with ValidationEnvironment=False still receives a version currently listed as a validation release, the next place to investigate would be the image or provisioning workflow rather than the host pool setting itself.

Also, for your crash investigation, make sure to capture both the AVD Agent version and the AVD Agent Boot Loader version, as they are separate components and can be relevant when correlating crashes with updates.

ValidationEnvironment=False is the correct production setting, but it does not trigger agent rollback or version pinning. I would focus on verifying the host pool configuration and tracing exactly how the agent is being installed during VM provisioning.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Answer 3

Allan Solomon Mejia 7,915

Hello @SebastianD-5208

The Validation Environment setting controls whether a host pool is enrolled to receive validation (pre-release) AVD agent updates, but changing the setting doesn't necessarily trigger an immediate downgrade if a session host has already received a newer validation agent.

A few points that may help narrow this down:

Verify that the host pool's Validation environment property is now set to No (or disabled) and that the change has propagated.
New session hosts should normally install the current production agent unless they're explicitly enrolled in the validation ring.
Existing hosts that have already installed a validation agent typically aren't downgraded automatically. The Azure Virtual Desktop agent is designed to move forward through the update channels rather than roll back.
If you've redeployed the session hosts and they're still installing validation builds, double-check that your IaC templates (Bicep/Terraform/ARM) aren't inadvertently setting the validation flag during deployment, and ensure you're registering the hosts with the intended host pool.

To help troubleshoot further, could you confirm:

Are you deploying with Terraform, Bicep, ARM, or another IaC tool?
What does the Validation environment property show in the Azure portal for the affected host pool?
Are these newly created session hosts, or are you reusing existing VM images?
Are all affected hosts reporting the same agent version, or is it mixed across the pool?

Microsoft doesn't provide a supported mechanism to manually force an older AVD agent version. If the host pool is no longer enrolled in the validation ring and newly deployed hosts continue to receive validation builds, that would warrant further investigation, as it could indicate a deployment configuration issue or a backend service behavior.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

SebastianD-5208 0 Reputation points

2026-08-06T14:03:04.91+00:00
Thanks a lot! Due to your confirmation that my expections are correct I checked our deployment again.

We are deploying via terraform and were using the following extension / module for the host pool join:

resource "azurerm_virtual_machine_extension" "vmext_dsc" { count = SOMENUMBER auto_upgrade_minor_version = true name = "NAME" publisher = "Microsoft.Powershell" type = "DSC" type_handler_version = "2.73" virtual_machine_id = ID settings = <<SETTINGS { "modulesUrl": "https://wvdportalstorageblob.blob.core.windows.net/galleryartifacts/Configuration_09-08-2022.zip", "configurationFunction": "Configuration.ps1\\AddSessionHost", "properties": { "HostPoolName": "${azurerm_virtual_desktop_host_pool.vdHostPool[0].name}" } } SETTINGS

As it turns our, this configuration module seems to deliver the latest validation version of the agent. Thats why I got the non-production version in my deployment, even though I had the validation environment setting on "No".

I have ran a quick test with the module linked/used in this article: https://learn.microsoft.com/en-us/azure/developer/terraform/create-avd-session-host ( https://wvdportalstorageblob.blob.core.windows.net/galleryartifacts/Configuration_1.0.03419.1309.zip ) which comes with a older version of the agent and apparently the flag to download the agent during setup.

With this we now have the current production version.

Quick side note if anyone is reading this: The article is using "UseAgentDownloadEndpoint": "true" which failed at least for my terraform runs wich an error like this:

Extension received an incorrect input: Cannot process argument transformation on parameter 'UseAgentDownloadEndpoint'. Cannot convert value "System.String" to type "System.Boolean". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.

I changed the terraform setting to "UseAgentDownloadEndpoint": true which now seems to be working.

So thanks a lot! I think we are clear now.
SebastianD-5208 0 Reputation points

2026-08-06T14:13:51.6933333+00:00

Ok, one rerun of terraform later the host pool updated its agent version 1.0.15008.300 (aka validation version) even though the host pool is set to validation environment "No" and initially the host got deployed with the latest production version.

I dont get it.

Any ideas are appreciated. I will probably troubleshoot some more tomorrow and/or disect the scripts from the dsc module.
Allan Solomon Mejia 7,915 Reputation points

2026-08-06T14:14:11.2533333+00:00
Hello @SebastianD-5208

Thanks for the update and for sharing your findings.

Based on your observations, this behavior is expected in some scenarios. The Host Pool validation environment setting determines the update channel, but Azure Virtual Desktop can still upgrade the agent if Microsoft determines a newer version is required (for example, due to servicing, compatibility, or reliability requirements). As a result, seeing the agent move from the latest production build to a newer validation build doesn't necessarily mean the host pool has switched to the validation environment.

To verify what's happening, I'd recommend checking:

Whether the VM has any Agent Update Maintenance Window configured.

The Azure Virtual Desktop Agent event logs (Applications and Services Logs > Microsoft > Windows > RemoteDesktopServices) for update activity.

The installed versions of both the Azure Virtual Desktop Agent and Agent Boot Loader.

Whether any DSC extension or deployment script is explicitly downloading a specific agent version during subsequent Terraform runs.

If the behavior continues, capturing the extension logs from the VM and comparing them with the deployment configuration would help determine whether the upgrade is being initiated by the deployment process or by the Azure Virtual Desktop service itself.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.
SebastianD-5208 0 Reputation points

2026-08-07T12:01:44.8566667+00:00
Thanks a lot. Unfortunately the RemoteDesktopServices Logs were truncated (I guess) and not reaching back to yesterday when the update occured.

I did some more testing today with the following results:

checked the scripts downloaded from the module by hand and by Claude. I am reasonably sure that those script wont perform updates if they find the registry keys corresponding to being host pool joined.

I deployed another vm to my testing host pool. As yesterday it got deployed with 1.0.14669.400. (latest prod version) Multiple restarts and reruns of terraform (without changes to the config/resource) didn't trigger any update.

Changed the terraform resource to force an update by the next run. Didn't trigger any update.

some time later the agent version updated to 1.0.15008.300 "on its own"

to note: The host pool i am testing on has 4 machines in it. Three of them were already deployed and on agent version 1.0.15008.300. Two of them were deployed before we switched the host pool property "validation environment" to "No" and had the version 1.0.15008.300 already installed. Just in case there is some kind of mix up or logic which forces all hosts to be on similar versions.

I checked the event log and saw some Windows Installer Event triggering the download & install of the agent update. Screenshot attached.

I checked the logs from C:\Program Files\Microsoft RDInfra and found the AgentInstall.txt with an install log for this new version which states among others: Action start 12:42:51: InstallValidate. Action ended 12:42:52: InstallValidate. Return value 1.

I dont know where this value is coming from (or if 1 is actually "true" which I for now just assume) but it kind of checks out. Full "AgentInstall.txt" attached.

As a next step I'll destroy the entire host pool and deploy it with the flag set to "No" from creation. Apart from that I'm at a loss what to do / where to search. Any input appreciated. Maybe I am searching in the completely wrong direction in regards to my initial problem but it just seems wrong for roughly 50% of our production deployments to be on an validation version of the agent. So I kind of want to resolve this.

AgentInstall.txt
SebastianD-5208 0 Reputation points

2026-08-07T13:37:25.8033333+00:00

Ok, test was quick. Even in completely fresh deployment of an host pool set to validation environment "No" my hosts (Windows 11 Enterprise multi-session) get deployed with the latest production release of the agent first and a couple of minutes later they update to some validation version. (here once again 1.0.15008.300)

I am seriously at a loss what to do / check next. Any help is apprecitated.
Allan Solomon Mejia 7,915 Reputation points

2026-08-07T15:07:48.9933333+00:00
Hi @SebastianD-5208

Thank you for performing the additional testing and sharing the Event Viewer logs.

The fresh deployment is particularly insightful. Since a newly provisioned session host initially installs the latest production agent and then, within a few minutes, automatically upgrades itself to 1.0.15008.300 (validation), it suggests the update is being initiated by the Azure Virtual Desktop agent update service rather than by your Terraform deployment or DSC configuration.

At this point, I'd recommend checking a few additional items:

Confirm the Host Pool still reports Validation environment = No:

*az desktopvirtualization hostpool show *

*--resource-group <resource-group> *

*--name <hostpool-name> *

--query validationEnvironment

Verify that all session hosts exhibiting this behavior belong only to that host pool and aren't receiving configuration from another deployment process.

Review the RD Agent logs under:

Applications and Services Logs > Microsoft > Windows > RemoteDesktopServices

Microsoft-RDInfra-RDAgent (if present)

Compare the behavior with a host deployed into a different host pool (also configured with validationEnvironment = No) to determine whether this is isolated to a specific host pool or region.

Since you've now reproduced the behavior on a clean deployment, and the MSI installer is being invoked automatically after the production agent is installed, this no longer appears to be caused by Terraform configuration or the UseAgentDownloadEndpoint setting.

One question that would help narrow this down:

Which Azure region is the host pool deployed in? If multiple customers in the same region are observing the same automatic upgrade, it could indicate a regional rollout or an issue with the AVD agent update service.

Given the evidence you've collected, I believe this would be a good case for a Microsoft moderator to escalate to the Azure Virtual Desktop engineering team. The fact that a clean deployment consistently transitions from the latest production agent to a validation build despite validationEnvironment = No is not expected behavior and merits further investigation.

Please don't forget "Accept the Answer" if this information helped you. This will help us and others in the community as well.
SebastianD-5208 0 Reputation points

2026-08-10T09:14:10.4166667+00:00
Thanks for your reply. In regards to your questions:

Host Pool is still set on "validationEnvironment": false according to portal and az command.

I deployed two hosts together with the host pool and both showed the same update behaviour at the same time. The only other "deployment near" process running in this environment ist salt stack which did nothing according to the logs. (apart from that, none of our salt states comes close to anything I would suspect of triggering an update)

Unfortunately I cant attach the .evtx log from the RemoteDesktopServices. Here are some entries I found notable/interesting but I'm lacking the knowledge to further connect them to the root issue. In chronological order. (see below point 4)

I have just deployed the same setup (same terraform configuration in a slightly reduced version, no salt stacke here!) to an empty testing environment and the behaviour was the same. Hosts get deployed with the latest prod version of the agent and within one hour they update to 1.0.15008.300. Host pool has validation environment set to "No". We are talking about west europe here. Same behaviour (as Ive written some posts ago) was observed in host pool the recently got switched from "Yes" to "No" where we added some hosts. (and the already existsing hosts where on 1.0.15008.300)

Some warnings along those lines pop up:

unable to retrieve SessionHostConfigurationLastUpdateTime from registry: System.FormatException: String was not recognized as a valid DateTime. at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles) at Microsoft.RDInfra.RDAgent.Service.RDAgentBrokerConfiguration.get_SessionHostConfigurationLastUpdateTime() in C:\__w\1\s\src\RDAgent\src\Service\AgentSettings.cs:line 3097

One Entry from the AgentBackgroundUpdater (with some entires removed):

Please note: This is a Windows 11 Enterprise multisession machine on version 10.0.26100 Build 26100. Dont know why this mesage states Windows 10.

GetUpdatedPackagesFromBrokerAsync Sending AgentCaps: ≤{"AgentVersion":"1.0.14669.400", "OSDetails":{"OSVersion":"10.0.26100.8875", "OSVersionFullDescription":"Windows 10 Enterprise multi-session"}, "SxSStackVersion":"rdp-sxs260519600", "StackType":2, "MonitoringVersion":"RDMonitoringAgentBootLoader_999.999.999.999", "GenevaVersion":"46.24.3", "WVDAgentManagerVersion":"", "SessionHostConfigurationLastUpdateTime":"0001-01-01T00:00:00", "AzureResourceId":"RESOURCEID", "BootLoaderVersion":"1.0.8925.0", "SessionHostTimeZone":"W. Europe Standard Time", "FlightConfig":null, "InRecoveryMode":false, "RdrSxSVersion":"", "SystemSettingsProxyVersion":"", "SessionHostMonAgentVersion":"", "Architecture":"X64"}≥

Still Source AgentBackgroundUpdater, as I said in chronological order

ProcessUpdatesAsync package info Version = 1.0.15008.300, Uri = ≤SOME mrsglobal URL≥, Flight info Microsoft.RDInfra.Shared.Common.FlightConfig

SetFlightContext set registry key to {"ConfigVersion":30555,"FlightSystemVersion":1}

OnBrokerResponseAsync: processing - ≤{"StatusCode":3,"StatusMessage":"IncorrectAgentVersion","Details":{"AgentExpectedVersion":"1.0.15008.300","AgentDownloadLocation":"SOME mrsglobal URL≥

assembly version is 1.0.14669.400

CheckAndApplyBypass EnableAgentVersionBypass : AgentByPassVersion is 1.0.15008.300

This is reported as ERROR: (rest is information)

CheckAndApplyBypass returning false on exception

From then in the logs read like the expected update messages for an agent update so I wont continue posting them.

I hope someone is able to find my mistake or we can escalate this. Thanks in advance.
Allan Solomon Mejia 7,915 Reputation points

2026-08-10T18:31:01.92+00:00
Hello Sebastian,

Thanks for the detailed logs. This is now much clearer.

The important entries are:

StatusCode: 3

StatusMessage: IncorrectAgentVersion

AgentExpectedVersion: 1.0.15008.300

followed by:

ProcessUpdatesAsync package info Version = 1.0.15008.300

That indicates the AVD broker/background updater is explicitly instructing the session host to move from 1.0.14669.400 to 1.0.15008.300. This is no longer pointing to Terraform, DSC, Salt, or the initial installation package.

Microsoft’s agent documentation does note that multiple agent versions can exist across environments during rollout, and that not every validation build reaches production. However, your clean reproduction is different: a host pool with validationEnvironment=false installs the production build first, then the broker explicitly reports a validation build as the expected version.

The SessionHostConfigurationLastUpdateTime parsing warning is interesting, but I wouldn’t modify that registry value manually. The stronger evidence is the broker response specifying 1.0.15008.300.

At this point I think you have enough evidence for escalation:

clean host pool created with validationEnvironment=false

clean session hosts

reproduced without Salt

initial production agent 1.0.14669.400

automatic update shortly afterward

AgentBackgroundUpdater receives IncorrectAgentVersion

broker explicitly expects 1.0.15008.300

reproduced in West Europe

Microsoft also documents that once installed, the AVD Agent is updated automatically, so blocking Windows Installer or trying to pin the MSI manually would not be a supported workaround.

=========================================================================

Microsoft Moderator Vinodh247-1375: Could this be escalated to the Azure Virtual Desktop engineering team? The broker appears to be assigning validation agent 1.0.15008.300 to newly deployed session hosts even though the host pool reports validationEnvironment=false.

=========================================================================

I would preserve the AgentBackgroundUpdater logs, exact UTC timestamps, host pool/resource IDs, and one affected session host for Microsoft to correlate against the broker-side rollout configuration.

@SebastianD-5208 Please don't forget "Accept the Answer" if this information helped you. This will help us and others in the community as well.
SebastianD-5208 0 Reputation points

2026-08-12T06:07:48.97+00:00

Hi Allan, big thanks for your help so far! Is there anything I can do to get the attention of MS Mods here?
Allan Solomon Mejia 7,915 Reputation points

2026-08-12T14:28:36.57+00:00

Sure @SebastianD-5208 , I'll call out another moderator to assist you.

Hello Sina Salam, can you please assist Sebastian on this? Thank you.
SebastianD-5208 0 Reputation points

2026-08-31T12:51:18.6166667+00:00

Just for the record, in case anyone stumbles across this. Issue is still unresolved and no one from MS contacted me.
Allan Solomon Mejia 7,915 Reputation points

2026-09-01T18:42:19.3433333+00:00

Hi @SebastianD-5208

You've received a response from one of our moderators (see the answer above) from @Vinodh247-1375 .

Please let us know if you need any further assistance.