Deux petites actus Microsoft à regarder cette semaine : les connexions Remote PC passent en disponibilité générale dans Windows App sur Windows, et Azure Virtual Desktop fait évoluer ses host pools avec le modèle Regional. On commence par Windows App, puis on passe à AVD, avec quelques manipulations simples pour voir concrètement de quoi il retourne.
Pas besoin de refaire tout votre lab pour découvrir ces évolutions. Pour Windows App, on regarde l’ajout d’un PC et le presse-papier. Pour AVD, on vérifie le nouveau choix de scope sur un pool de test, sans déployer de VM.
Petit article aujourd’hui, donc petit sommaire qui va avec :
- 1. Windows App : ajouter ses PC distants
- 2. Azure Virtual Desktop : découvrir les Regional Host Pools
1. Windows App : ajouter ses PC distants
Remote PC dans Windows App sur Windows passe en GA : connexions enregistrées et favoris, sans compte professionnel ou scolaire dans l’application, avec authentification sur la cible. C’est l’annonce de Remote PC connections in Windows App on Windows is now generally available, sur Microsoft Tech Community.
L’intérêt est facile à voir : garder sous la main les connexions vers les machines que vous utilisez souvent dans une seule unique application que vous utilisez déjà pour vos accès Windows 365 et Azure Virtual Desktop :
On va commencer par une seule cible, puis regarder un réglage qui mérite toujours un contrôle : le presse-papier.
Ce que cela change pour vos connexions
Le scénario est celui d’une machine que vous connaissez déjà et à laquelle vous avez le droit de vous connecter. Le nom saisi dans Windows App désigne cette cible : ce n’est pas une recherche automatique de tous les PC du réseau.
Préparez donc le nom réel de l’ordinateur, ou son adresse IP, avant de commencer :
Un nom convivial pour la carte vous aidera ensuite à retrouver le lab sans confondre plusieurs machines :
Autre détail important : ne pas ajouter de compte professionnel dans Windows App ne dispense pas de fournir les identifiants acceptés par le PC distant. Pour isoler ce point, vous pouvez utiliser un profil Windows de lab non connecté à votre compte d’entreprise, puis un compte de test autorisé sur la cible. Il n’est pas nécessaire de retirer les comptes de votre poste de travail habituel.
Test n°1 : ajouter un PC et ouvrir une session
Pour cet essai, prévoyez Windows App à jour, un PC Windows 11 Pro ou Windows Serveur avec le Bureau à distance activé, un compte autorisé sur cette machine et un accès réseau de confiance. Conservez NLA et le pare-feu. Les prérequis côté PC sont détaillés dans Enable Remote Desktop on your PC.
Sur le PC distant, ouvrez Paramètres, puis Système et Bureau à distance. Vérifiez que l’accès est activé et que le compte choisi est autorisé. La machine doit être allumée et joignable.
Sur le poste client, ouvrez Windows App à jour et choisissez Add a remote PC, ou le bouton d’ajout si vous êtes déjà dans l’application.
Dans PC Name, saisissez le nom exact ou l’adresse IP de votre PC de lab, puis cliquez ici :
Dans Additional settings, donnez un nom convivial à la carte, par exemple PC de lab. Conservez les autres réglages pour le premier essai et notez leur état.
Choisissez Add & Connect, puis authentifiez-vous avec le compte autorisé sur le PC :
Si une alerte de certificat apparaît, vérifiez la cible et le certificat avant de poursuivre :
Dans un terminal de la session distante, lancez les commandes ci-dessous. Le nom de machine et l’identité doivent correspondre à ce que vous aviez prévu :
hostname
whoami
ipconfig
Déconnectez la session, fermez puis rouvrez Windows App et relancez la carte enregistrée. Notez si une nouvelle demande d’identifiants apparaît et si la connexion aboutit :
Ce qu’on cherche à vérifier : la bonne machine, le bon compte, puis une reconnexion depuis l’entrée sauvegardée. Les commandes de l’interface sont décrites dans « Connect to a remote PC », onglet Windows, de Get started with Windows App to connect to devices and apps.
Si la connexion ne s’ouvre pas
Commencez par vérifier le réseau, sans toucher aux mots de passe ni désactiver les protections. Depuis Windows PowerShell sur le poste client, la commande suivante contrôle le port RDP standard de la machine que vous indiquez. Si votre lab utilise un port personnalisé, remplacez -CommonTCPPort RDP par -Port suivi du port configuré.
$RemotePC = 'Nom ou adresse IP du PC de lab'
Test-NetConnection -ComputerName $RemotePC -CommonTCPPort RDP -InformationLevel Detailed
TcpTestSucceeded : True confirme que le test TCP aboutit. Cela ne prouve pas que vos identifiants sont valides ou que votre compte a le droit d’ouvrir une session. Si le test échoue, vérifiez la cible, son état, le chemin réseau ou le VPN et les règles autorisées. Un échec ne désigne pas automatiquement le pare-feu. La commande est documentée dans Test-NetConnection (NetTCPIP).
Test n°2 : vérifier le copier-coller
La procédure Remote PC de Microsoft indique que les redirections sont désactivées par défaut sur une nouvelle connexion :
Dans les paramètres de la carte, retrouvez l’accès aux ressources locales et activez uniquement le presse-papier si l’option est disponible et autorisée. Enregistrez, puis reconnectez-vous.
Faites les essais avec des fichiers locaux et distants. Ces nouveaux marqueurs permettent d’éviter de prendre un ancien contenu du presse-papier pour le résultat du nouvel essai :
2. Azure Virtual Desktop : découvrir les Regional Host Pools
Autre actualité, cette fois dans Azure Virtual Desktop. Les Regional Host Pools sont GA depuis septembre 2026 ; leurs métadonnées sont régionalisées pour améliorer la résilience en réduisant les dépendances interrégionales. Le statut est confirmé dans What’s new in Azure Virtual Desktop ?, rubrique « September 2026 ».
Au lancement, seules East US 2 et Central US sont disponibles ; une réplication vers une région jumelée reste possible. Voir Now generally available : Regional resiliency for Azure Virtual Desktop, publié le 30 septembre 2026. Pour notre essai, on retient East US 2 avec des données de lab, pas comme recommandation d’hébergement pour vos données européennes.
Le réglage à repérer est Deployment scope. La région des métadonnées et celle des VM restent des choix distincts : sélectionner Regional n’est pas une opération de déplacement de vos session hosts. Pour un administrateur, la première vérification utile est donc le type d’objets créé et leur compatibilité.
Ce que signifie Regional pour un host pool
La page Regional Host Pools décrit une infrastructure de service dédiée aux objets régionaux. Le sujet concerne notamment la manière dont les métadonnées sont stockées et les dépendances de cette infrastructure. Ce n’est pas une option qui recrée automatiquement les VM, déplace les profils FSLogix ou modifie vos applications.
Pour votre lab, gardez donc deux vérifications simples : la région retenue doit proposer le scope Regional, et les objets que vous associerez au pool doivent être compatibles avec ce nouveau scope. Un groupe de ressources commun ne suffit pas à rendre une association valide.
La GA ne signifie pas non plus que toutes les régions Azure proposent immédiatement le nouveau modèle. Vérifiez la disponibilité au moment du test. Si le champ n’est pas visible dans la région choisie, ne continuez pas avec les valeurs par défaut en pensant avoir créé un pool régional.
Test n°3 : créer un pool Regional, sans VM
Utilisez une subscription et un groupe de ressources de lab, avec les permissions de création nécessaires. Ce test crée des objets AVD, pas un environnement complet : aucune ouverture de bureau n’est attendue puisqu’on n’ajoute pas de session host.
La procédure de référence est « Create a host pool with standard management » dans Deploy Azure Virtual Desktop.
- Dans le portail Azure, ouvrez Azure Virtual Desktop, puis Host pools et Create. Utilisez uniquement le groupe de ressources réservé au lab.
- Sur Basics, choisissez votre subscription et le groupe de ressources. Donnez un nom identifiable au pool de test pour le retrouver facilement après déploiement.
- Dans Location, choisissez East US 2 pour cet exemple. Dans Deployment scope, sélectionnez explicitement Regional. Si le champ n’apparaît pas, arrêtez l’essai et vérifiez la disponibilité.
- Choisissez Pooled pour le type de pool, Desktop pour le type de groupe préféré et la gestion standard. Ne configurez pas de session host configuration pour cet essai.
- Ne créez aucune VM et ne rattachez pas le groupe d’applications à un workspace existant. Le test porte sur la création des objets, pas sur une session utilisateur.
- Dans Review + create, relisez la région, le scope et les ressources annoncées. Le portail crée également le groupe d’applications Desktop par défaut. Lancez la création seulement si le résumé correspond au périmètre prévu.
Après déploiement, contrôlez le scope dans les propriétés du pool ou la colonne Deployment scope de la liste. La valeur attendue est Regional :
Voici d’ailleurs la commande PowerShell pour créer un pool d’hôtes régional :
New-AzWvdHostPool -ResourceGroupName "testrg" -Name "xyz" -Location "centralus" -DeploymentScope "Regional"New-AzWvdHostPool -ResourceGroupName "testrg" -Name "xyz" -Location "centralus" -DeploymentScope "Regional"Le piège à retenir : ne pas mélanger les scopes
Si vous poursuivez le lab avec un workspace, gardez une chaîne homogène. Le groupe d’applications hérite du scope de son host pool et ne peut être enregistré que dans un workspace du même scope. Les règles sont détaillées dans « Deployment scope and object relationships » du guide de déploiement.
Pour prolonger ce même test, vous pouvez créer un workspace Regional dans le lab :
Vérifiez le scope du workspace avant l’association :
Si le groupe n’est pas proposé ou reste grisé, contrôlez son scope et une éventuelle association existante avant de toucher aux permissions.
Cette association valide la configuration des objets ; sans session host, elle ne fournit toujours pas un bureau utilisable.
Avant d’envisager un déploiement plus large
Gardez le nom du pool, la région choisie et une capture du scope obtenu avec vos notes de test. Ce contrôle ne démontre pas un basculement en cas de panne régionale. Pour une utilisation en production, examinez séparément les VM, les profils, les applications et la supervision : la page Regional Host Pools signale encore une limitation sur la remontée des erreurs et checkpoints dans Log Analytics, à confirmer pour votre déploiement GA.
