Update to Microsoft Desktop Virtualization API v. 2023-09-05 by August 2, 2024 to avoid any impact


Older Microsoft Desktop Virtualization API version(s) utilized for your Azure Virtual Desktop host pool resource will no longer support ‘get’ actions for registration token retrieval as of August 2nd, 2024.


 The affected API versions are as follows:  

  • 2019-01-23-preview 
  • 2019-09-24-preview 
  • 2019-12-10-preview 
  • 2020-09-21-preview  
  • 2020-11-02-preview  
  • 2020-11-10-preview  
  • 2021-01-14-preview 


On August 2nd, 2024, these affected API versions will no longer support the retrieval of the registration token. Users on older versions will not be able to use the 'get' action to retrieve the token. However, with the newer versions, a new 'post' action can be used to securely retrieve the token:


Action Required 

  1. Review any workflows you may have that rely on readers retrieving access tokens and update them to extract the registration tokens for a host pool in a new way.
  2. Ensure you are using up to date versions of the Microsoft Desktop Virtualization API.  

To take action, here are examples of how to extract the registration tokens for a host pool and update to the 2023-09-05 API version using Bicep and ARM templates. 


If you are using Bicep templates in your deployment:

retrieveToken.bicep - module used to retrieve the registration token from a host pool by using a patch operation:


@sys.description('Optional. Host Pool token validity length. Usage: \'PT8H\' - valid for 8 hours; \'P5D\' - valid for 5 days; \'P1Y\' - valid for 1 year. When not provided, the token will be valid for 8 hours.')
param tokenValidityLength string = 'PT8H'

@sys.description('Generated. Do not provide a value! This date value is used to generate a registration token.')
param baseTime string = utcNow('u')

param vLocation string

param vHostPoolName string

param vHostPoolType string

param vPreferredAppGroupType string

param vMaxSessionLimit int

param vLoadBalancerType string

resource hostPool 'Microsoft.DesktopVirtualization/hostPools@2023-09-05' = {
  name: vHostPoolName
  location: vLocation
    properties: {
    hostPoolType: vHostPoolType
    preferredAppGroupType: vPreferredAppGroupType
    maxSessionLimit: vMaxSessionLimit
    loadBalancerType: vLoadBalancerType
    registrationInfo: {
      expirationTime: dateTimeAdd(baseTime, tokenValidityLength)
      registrationTokenOperation: 'Update'

@sys.description('The registration token of the host pool.')
output registrationToken string = reference(hostPool.id).registrationInfo.token



sample.bicep - example of usage of retrieveToken.bicep module to extract the registration token:



@sys.description('AVD Host Pool resource ID. (Default: )')
param hostPoolResourceId string

var varHostpoolSubId = split(hostPoolResourceId, '/')[2]
var varHostpoolRgName = split(hostPoolResourceId, '/')[4]
var varHostPoolName = split(hostPoolResourceId, '/')[8]

// Call on the hotspool
resource hostPoolGet 'Microsoft.DesktopVirtualization/hostPools@2023-09-05' existing = {
  name: varHostPoolName
  scope: resourceGroup('${varHostpoolSubId}', '${varHostpoolRgName}')

module hostPool 'retrieveToken.bicep' = {
  name: varHostPoolName
  scope: resourceGroup('${varHostpoolSubId}', '${varHostpoolRgName}')
  params: {
    vHostPoolName: varHostPoolName
    vMaxSessionLimit: hostPoolGet.properties.maxSessionLimit
    vPreferredAppGroupType: hostPoolGet.properties.preferredAppGroupType
    vHostPoolType: hostPoolGet.properties.hostPoolType
    vLoadBalancerType: hostPoolGet.properties.loadBalancerType
    vLocation: hostPoolGet.location

@sys.description('The registration token of the host pool.')
output registrationToken string = hostPool.outputs.registrationToken




If you are using ARM templates in your deployment:


  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "",
      "templateHash": "15215789985349638425"
  "parameters": {
    "hostPoolName": {
      "type": "string"
    "location": {
      "type": "string"
    "baseTime": {
      "type": "string",
      "defaultValue": "[utcNow('u')]"
  "variables": {
    "expirationTime": "[dateTimeAdd(parameters('baseTime'), 'PT1H1M')]"
  "resources": [
      "type": "Microsoft.DesktopVirtualization/hostPools",
      "apiVersion": "2023-09-05",
      "name": "[parameters('hostPoolName')]",
      "location": "[parameters('location')]",
      "properties": {
        "maxSessionLimit": 2,
        "hostPoolType": "Personal",
        "loadBalancerType": "Persistent",
        "preferredAppGroupType": "Desktop",
        "registrationInfo": {
          "expirationTime": "[variables('expirationTime')]",
          "registrationTokenOperation": "Update"
  "outputs": {
    "token": {
      "type": "string",
      "value": "[reference(resourceId('Microsoft.DesktopVirtualization/hostPools', parameters('hostPoolName'))).registrationInfo.token]"



Additional Support  

If you have any questions, comments, or concerns about this, please feel free to post a comment.

2 Replies
WARNING! Secrets should never be used in the output section of an ARM template. The value will be stored in plain text in the portal and can be seen by anyone with the Reader role. The registration token should be passed to a key vault secret resource within the same deployment and referenced using the "getSecret" function in Bicep when it is needed: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/key-vault-parameter?tabs=azure-.... Or use a key vault reference in JSON ARM templates: https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/key-vault-parameter?tabs=az...

@Logan_SillimanRegarding retrieveToken.bicep, it appears that the registration token is updated each time the module is invoked.  Is it safe to execute multiple deployments with this module concurrently?