Migrer automatiquement depuis Azure Virtual Desktop (classique)

Importante

Azure Virtual Desktop classique sera mis hors service le 30 septembre 2026. Les connexions aux ressources classiques seront bloquées après la mise hors service.

Pour éviter toute interruption, migrez les ressources classiques restantes vers des pools d’hôtes basés sur Azure Resource Manager avant le 30 septembre 2026.

L’outil de module de migration vous permet de migrer automatiquement votre organisation d’Azure Virtual Desktop (classique) vers Azure Virtual Desktop. Cet article vous explique comment utiliser cet outil.

Configuration requise

Avant d’utiliser le module de migration, assurez-vous d’avoir préparé les éléments suivants :

  • Un abonnement Azure dans lequel vous allez créer de nouveaux objets de service Azure.

  • Vous devez disposer du rôle de contributeur pour créer des objets Azure sur votre abonnement et du rôle d’administrateur de l’accès utilisateur pour affecter des utilisateurs aux groupes d’applications.

  • Au moins autorisations de contributeur aux services Bureau à distance (RDS) sur un locataire RDS ou les pools d’hôtes spécifiques que vous migrez.

  • La dernière version du module PowerShell Microsoft.RdInfra.RDPowershell.

  • La dernière version du module PowerShell Az.DesktopVirtualization.

  • La dernière version du module PowerShell Az.Resources.

  • Installez le module de migration sur votre ordinateur.

  • PowerShell ou PowerShell ISE pour exécuter les scripts que vous verrez dans cet article. Le module Microsoft.RdInfra.RDPowershell ne fonctionne pas dans PowerShell Core.

Importante

La migration crée uniquement des objets service aux États-Unis. Si vous essayez de migrer vos objets de service vers une autre zone géographique, cela ne fonctionnera pas. En outre, si votre déploiement Azure Virtual Desktop (classique) contient plus de 500 groupes d’applications, vous ne pourrez pas effectuer de migration. Vous ne pourrez migrer que si vous reconstruisez votre environnement pour réduire le nombre de groupes d’applications au sein de votre locataire Microsoft Entra.

Préparer votre environnement PowerShell

Tout d’abord, vous devez préparer votre environnement PowerShell pour le processus de migration.

Pour préparer votre environnement PowerShell :

  1. Avant de commencer, assurez-vous que vous disposez de la dernière version des modules Az.Desktop Virtualization et Az.Resources en exécutant les applets de commande suivantes :

    Get-Module Az.Resources
    Get-Module Az.DesktopVirtualization
    https://www.powershellgallery.com/packages/Az.DesktopVirtualization/
    https://www.powershellgallery.com/packages/Az.Resources/
    

    Si vous ne les faites pas, vous devrez installer et importer les modules en exécutant ces applets de commande :

    Install-module Az.Resources
    Import-module Az.Resources
    Install-module Az.DesktopVirtualization
    Import-module Az.DesktopVirtualization
    
  2. Désinstallez ensuite le module PowerShell RDInfra actuel en exécutant cette applet de commande :

    Uninstall-Module -Name Microsoft.RDInfra.RDPowershell -AllVersions
    
  3. Après cela, installez le module RDPowershell avec cette applet de commande :

    Install-Module -Name Microsoft.RDInfra.RDPowershell -RequiredVersion 1.0.3414.0 -force
    Import-module Microsoft.RDInfra.RDPowershell
    
  4. Une fois que vous avez terminé de tout installer, exécutez cette applet de commande pour vous assurer que vous disposez des versions appropriées des modules :

    Get-Module Microsoft.RDInfra.RDPowershell
    
  5. Maintenant, installons et importons le module de migration en exécutant ces applets de commande :

    Install-Module -Name PackageManagement -Repository PSGallery -Force
    Install-Module -Name PowerShellGet -Repository PSGallery -Force
    # Then restart shell
    Install-Module -Name Microsoft.RdInfra.RDPowershell.Migration -AllowClobber
    Import-Module <Full path to the location of the migration module>\Microsoft.RdInfra.RDPowershell.Migration.psd1
    
  6. Une fois que vous avez terminé, connectez-vous à Azure Virtual Desktop (classique) dans votre fenêtre PowerShell :

    Add-RdsAccount -DeploymentUrl https://rdbroker.wvd.microsoft.com
    
  7. Connectez-vous à Azure Resource Manager :

    Login-AzAccount
    
  8. Si vous avez plusieurs abonnements, sélectionnez celui vers lequel vous souhaitez migrer vos ressources à l’aide de cette applet de commande :

    Select-AzSubscription -Subscriptionid <subID>
    
  9. Inscrivez le fournisseur de ressources dans le portail Azure pour l’abonnement sélectionné.

  10. Enfin, vous devez enregistrer le fournisseur. Vous pouvez procéder de deux manières :

    • Si vous souhaitez utiliser PowerShell, exécutez cette applet de commande :

      Register-AzResourceProvider -ProviderNamespace Microsoft.DesktopVirtualization
      
    • Si vous préférez utiliser le Portail Azure, ouvrez le Portail Azure et connectez-vous, puis accédez à Abonnements et sélectionnez le nom de l’abonnement que vous souhaitez utiliser. Après cela, accédez au fournisseur> de ressourcesMicrosoft.DesktopVirtualization et sélectionnez Réinscrire. Vous ne verrez rien de nouveau dans l’interface utilisateur pour l’instant, mais votre environnement PowerShell doit maintenant être prêt à exécuter le module.

Migrer Azure ressources Virtual Desktop (classique) vers Azure Resource Manager

Maintenant que votre environnement PowerShell est prêt, vous pouvez commencer le processus de migration.

Pour migrer vos ressources Azure Virtual Desktop (classique) vers Azure Resource Manager :

  1. Avant de migrer, si vous souhaitez comprendre comment les ressources Classic existantes seront mappées avec de nouvelles ressources Azure Resource Manager, exécutez cette applet de commande :

    Get-RdsHostPoolMigrationMapping
    

    Avec Get-RdsHostPoolMigrationMapping, vous pouvez créer un fichier CSV qui mappe l’emplacement de vos ressources. Par exemple, si le nom de votre client est « Contoso » et que vous souhaitez stocker votre fichier de mappage dans le fichier « contosouser », vous devez exécuter une applet de commande qui ressemble à ceci :

    Get-RdsHostPoolMigrationMapping -Tenant Contoso -HostPool Office -Location EastUS -OutputFile 'C:\\Users\contosouser\OneDrive - Microsoft\Desktop\mapping.csv'
    
  2. Ensuite, exécutez l’applet de commande Start-RdsHostPoolMigration pour choisir s’il faut migrer un pool d’hôtes unique ou tous les pools d’hôtes d’un client.

    Par exemple :

    Start-RdsHostPoolMigration -Tenant Contoso -Location WestUS
    

    Si vous souhaitez migrer vos ressources vers un pool d’hôtes spécifique, incluez le nom du pool d’hôtes. Par exemple, si vous souhaitez déplacer le pool d’hôtes nommé « Office », exécutez une commande comme celle-ci :

    Start-RdsHostPoolMigration -Tenant Contoso -HostPool Office -CopyUserAssignments $false -Location EastUS
    

    Si vous n’indiquez pas de nom d’espace de travail, le module en crée un automatiquement pour vous en fonction du nom du locataire. Toutefois, si vous préférez utiliser un espace de travail spécifique, vous pouvez entrer son ID de ressource comme suit :

    Start-RdsHostPoolMigration -Tenant Contoso -HostPool Office -CopyUserAssignments -Location EastUS -Workspace <Resource ID of workspacename>
    

    Si vous souhaitez utiliser un espace de travail spécifique mais que vous ne connaissez pas son ID de ressource, exécutez cette applet de commande :

    Get-AzWvdWorkspace -WorkspaceName <workspace> -ResourceGroupName <resource group> |fl
    

    Vous devez également spécifier un mode d’attribution d’utilisateur pour les attributions d’utilisateur existantes :

    • Utilisez Copier pour copier toutes les affectations d’utilisateurs de vos anciens groupes d’applications vers Azure Resource Manager groupes d’applications. Les utilisateurs pourront voir les flux pour les deux versions de leurs clients.
    • Utilisez Aucun si vous ne souhaitez pas modifier les affectations d’utilisateur. Vous pourrez ensuite affecter des utilisateurs ou des groupes d’utilisateurs à des groupes d’applications avec le portail Azure, PowerShell ou l’API. Les utilisateurs pourront uniquement voir les flux à l’aide des clients Azure Virtual Desktop (classique).

    Vous ne pouvez copier que 2 000 attributions utilisateur par abonnement. Votre limite dépend donc du nombre de devoirs déjà dans votre abonnement. Le module calcule la limite en fonction du nombre de devoirs que vous avez déjà. Si vous n’avez pas assez d’attributions à copier, vous recevrez un message d’erreur indiquant « Quota d’attribution de rôle insuffisant pour copier les attributions d’utilisateur. Réexécutez la commande sans le commutateur -CopyUserAssignments pour migrer. »

  3. Une fois les commandes exécutées, le module met 15 minutes à créer les objets de service. Si vous avez copié ou déplacé des affectations d’utilisateurs, cela rallongera le temps nécessaire au module pour terminer sa configuration.

    Une fois l’applet de commande Start-RdsHostPoolMigration terminée, vous devriez voir les éléments suivants :

    • Objets de service Azure pour le locataire ou le pool d’hôtes que vous avez spécifié.

    • Deux nouveaux groupes de ressources :

      • Un groupe de ressources appelé « nom_locataire » qui contient votre espace de travail.

      • Un groupe de ressources appelé « Tenantname_originalHostPoolName » qui contient le pool d’hôtes et les groupes d’applications de bureau.

    • Tous les utilisateurs que vous avez publiés dans les groupes d’applications nouvellement créés.

    • Les machines virtuelles seront disponibles dans les pools d’hôtes existants et nouveaux afin d’éviter les temps d’arrêt des utilisateurs pendant le processus de migration. Cela permet aux utilisateurs de se connecter à la même session utilisateur.

    Étant donné que ces nouveaux objets de service Azure sont des objets Azure Resource Manager, le module ne peut pas leur attribuer des autorisations de Access Control basées sur des rôles (RBAC) ou des paramètres de diagnostic. Par conséquent, vous devez mettre à jour manuellement les autorisations et paramètres RBAC pour ces objets.

    Une fois que le module a validé les connexions utilisateur initiales, vous pouvez également publier le groupe d’applications pour plus d’utilisateurs ou de groupes d’utilisateurs, si vous le souhaitez.

    Remarque

    Après la migration, si vous déplacez des groupes d’applications vers un autre groupe de ressources après avoir attribué des autorisations aux utilisateurs, tous les rôles RBAC sont supprimés. Vous devrez réaffecter les autorisations RBAC des utilisateurs.

  4. Si vous souhaitez supprimer tous les objets de service Azure Virtual Desktop (classique), exécutez Complete-RdsHostPoolMigration pour terminer le processus de migration. Cette applet de commande supprimera tous les objets Azure Virtual Desktop (classiques), ne laissant que les nouveaux objets Azure. Les utilisateurs pourront uniquement voir le flux des groupes d’applications nouvellement créés sur leurs clients. Une fois cette commande exécutée, vous pouvez supprimer en toute sécurité le locataire Azure Virtual Desktop (classique) pour terminer le processus.

    Par exemple :

    Complete-RdsHostPoolMigration -Tenant Contoso -Location EastUS
    

    Si vous souhaitez compléter un pool d’hôtes spécifique, vous pouvez inclure le nom du pool d’hôtes dans l’applet de commande. Par exemple, si vous voulez compléter un pool d’hôtes nommé « Office », vous devez utiliser une commande comme celle-ci :

    Complete-RdsHostPoolMigration -Tenant Contoso -HostPool Office -Location EastUS
    

    Cela supprime tous les objets de service créés par Azure Virtual Desktop (classique). Il ne vous restera que les nouveaux objets Azure et les utilisateurs pourront uniquement voir le flux des groupes d’applications nouvellement créés sur leurs clients. Une fois que vous avez terminé la finalisation de votre migration, vous devez supprimer explicitement le locataire dans Azure Virtual Desktop (classique).

  5. Si vous avez changé d’avis au sujet de la migration et que vous souhaitez rétablir le processus, exécutez l’applet de commande Revert-RdsHostPoolMigration .

    Par exemple :

    Revert-RdsHostPoolMigration -Tenant Contoso -Location EastUS
    

    Si vous souhaitez rétablir un pool d’hôtes spécifique, vous pouvez inclure le nom du pool d’hôtes dans la commande. Par exemple, si vous souhaitez rétablir un pool d’hôtes nommé « Office », vous entrerez quelque chose comme ceci :

    Revert-RdsHostPoolMigration -Tenant Contoso -HostPool Office -Location EastUS
    

    Cette applet de commande supprime tous les objets de service Azure nouvellement créés. Vos utilisateurs voient uniquement le flux d’objets Azure Virtual Desktop (classique) dans leurs clients.

    Toutefois, l’applet de commande ne supprime pas l’espace de travail créé par le module ou son groupe de ressources associé. Vous devez supprimer manuellement ces éléments pour vous en débarrasser.

  6. Si vous ne voulez pas encore supprimer vos objets de service Azure Virtual Desktop (classique) mais que vous voulez tester la migration, vous pouvez exécuter Set-RdsHostPoolHidden.

    Par exemple :

    Set-RdsHostPoolHidden -Tenant Contoso -Hostpool Office -Hidden $true -Location WestUS
    

    Si vous définissez le status sur « true », les ressources Azure Virtual Desktop (classique) sont masquées. En le définissant sur « false », les ressources seront révélées à vos utilisateurs.

    Le paramètre -Hostpool est facultatif. Vous pouvez utiliser ce paramètre s’il existe un pool d’hôtes Azure Virtual Desktop (classique) spécifique que vous souhaitez masquer.

    Cette applet de commande masque les objets de flux utilisateur et de service Azure Virtual Desktop (classique) au lieu de les supprimer. Toutefois, il n’est généralement utilisé qu’à des fins de test et ne compte pas comme une migration terminée. Pour terminer votre migration, vous devez exécuter la commande Complete-RdsHostPoolMigration . Sinon, rétablissez votre déploiement en exécutant Revert-RdsHostPoolMigration.

Résoudre les problèmes de migration automatique

Cette section explique comment résoudre les problèmes fréquemment rencontrés dans le module de migration.

Je ne parviens pas à accéder au client

Tout d’abord, essayez ces deux choses :

  • Assurez-vous que votre compte d’administrateur dispose des autorisations nécessaires pour accéder au client.
  • Essayez d’exécuter Get-RdsTenant sur le client.

Si ces deux solutions fonctionnent, essayez d’exécuter l’applet de commande Set-RdsMigrationContext pour définir le contexte RDS et ADAL pour votre migration :

  1. Créez le contexte RDS en exécutant l’applet de commande Add-RdsAccount .

  2. Recherchez le contexte RDS dans la variable globale $rdMgmtContext.

  3. Recherchez le contexte ADAL dans la variable globale $AdalContext.

  4. Exécutez Set-RdsMigrationContext avec les variables que vous avez trouvées dans ce format :

    Set-RdsMigrationContext -RdsContext <rdscontext> -AdalContext <adalcontext>
    

Étapes suivantes

Si vous souhaitez découvrir comment migrer votre déploiement manuellement, consultez Migrer manuellement à partir d’Azure Virtual Desktop (classique).

Une fois la migration effectuée, découvrez le fonctionnement d’Azure Virtual Desktop en consultant nos didacticiels. Découvrez les fonctionnalités de gestion avancées sur Développer un pool d’hôtes existant et personnaliser les propriétés RDP.

Pour en savoir plus sur les objets de service, consultez la page Environnement Azure Virtual Desktop dans la case activée.