Azure WAN

Les stratégies de connexion entre des réseaux Cloud et/ou sur site sont déjà possibles grâce aux appairages, aux passerelles VPN et encore bien d’autres. Mais force est de constater qu’Azure WAN simplifie la mise en œuvre d’une architecture multi-réseaux. Et bien figurez-vous que j’ai justement pu enfin trouver le temps pour le tester cet Azure WAN ! 😎

Avant vous parler du test que j’ai réalisé sur ce service, commençons d’abord par quelques notions sur Azure WAN.

Qu’est-ce qu’Azure WAN ?

Azure WAN facilite la connexion des sites distants, des succursales ou des utilisateurs via un réseau centralisé. Cela permet d’intégrer plusieurs réseaux locaux (LAN) sur un WAN global, améliorant ainsi la connectivité et la gestion.

Azure WAN est un concentré de services réseaux déjà disponibles sur le Cloud Microsoft. Il propose de mettre en place et de gérer de façon simple et rapide différents types de liaison dans le Cloud et/ou sur site.

Mais seulement cette simplicité n’est pas un synonyme d’économie : Azure WAN propose dès les premiers liens des puissances assez grandes. Et qui dit performances, dit coûts.

Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.

Microsoft Learn

Voici quelques-unes des fonctionnalités principales :

  • Connectivité de branche (via l’automatisation de la connectivité à partir d’appareils partenaires Virtual WAN, comme SD-WAN ou CPE VPN).
  • Connectivité VPN de site à site.
  • Connectivité VPN d’un utilisateur distant (point à site).
  • Connectivité privée (ExpressRoute).
  • Connectivité multicloud (connectivité transitive pour les réseaux virtuels).
  • Interconnectivité ExpressRoute des VPN.
  • Routage, Pare-feu Azure et chiffrement pour la connectivité privée.

Microsoft Learn

Grâce à son interface unique et centralisée, les administrateurs réseau peuvent configurer et surveiller facilement l’ensemble du réseau WAN, incluant les connexions des utilisateurs, les VPN, et les passerelles virtuelles. Cela simplifie donc l’administration des réseaux complexes.

Dans quel cas considérer Azure WAN ?

Le service est idéal pour les environnements hybrides ou multicloud, en offrant une connectivité fluide entre les réseaux sur site et divers fournisseurs de cloud.

Azure WAN est avant tout une boîte à outils où les liaisons entre ressources Azure et/ou sur sites sont vraiment très simples à mettre en œuvre.

Quels SKUs sont disponibles pour Azure WAN ?

Azure WAN permet de réduire les coûts en diminuant la nécessité d’équipements réseau sur site. L’approche as-a-service signifie que les entreprises paient uniquement pour ce qu’elles utilisent, réduisant ainsi les coûts d’infrastructure.

A ce jour, 2 SKUs sont déjà disponibles pour Azure WAN. Microsoft nous expose via le tableau ci-dessous les différences :

Type de Virtual WANType de HubConfigurations disponibles
De baseDe baseVPN de site à site uniquement
standardstandardExpressRoute
VPN utilisateur (point à site)
VPN (site à site)
Transit de hub à hub et de réseau virtuel à réseau virtuel via le hub virtuel
Pare-feu Azure
NVA est un WAN virtuel

Autrement dit, l’Azure WAN de base, bien que gratuit (base + traffic), apportera seulement les connexions VPN site à site et aux réseaux virtuels Azure, mais certaines liaisons sont manquantes comme :

  • Connexion entre les hubs
  • Connectivité ExpressRoute
  • Connectivité VPN utilisateur/point à site
  • Connectivité de réseau virtuel à réseau virtuel Azure
  • Azure Firewall

Enfin, Il est malgré tout possible de migrer depuis le SKU Basic vers Standard, mais pas l’inverse :

Quels sont les autres coûts liés au services Azure WAN ?

La tarification du service Azure WAN est très fragmenté. La facturation dépendra des différents trafics réseaux, et donc se divisera potentiellement en une myriade de petits frais.

Dans l’image ci-dessous, pas loin de 13 différents types de transfert sont facturés par Microsoft :

Pour y voir plus clair sur le trafic réseaux d’Azure WAN, Microsoft propose différents scénarios concrets disponibles juste .

Tarification de la liaison :

Microsoft communique également via leur site web le détail tarifaire complet des liaisons réseaux possibles :

Tarification de la données en transit :

Microsoft nous rappelle ici les différents prix au Go de données transférées entre des réseaux sur Azure et/ou sur site :

Afin de comprendre comment déployer Azure WAN, j’ai décidé de recréer une petite infrastructure réseau, répartie sur plusieurs régions Azure :

Par manque de temps et de connaissances, je n’ai pas testé Firewall et la fonctionnalité BGP sur mon test d’Azure WAN.

Mon test d’Azure WAN :

Mon environnement WAN de test est constitué des éléments Azure suivants :

  • 1 Azure WAN avec 2 Azure Hub :
  • 4 réseaux virtuels Azure contenant chacun une machine virtuelle :
  • 2 VPN Gateway Site à Site :
  • 2 VPN Gateway Point à Site avec une configuration P2S VPN globale WAN :

J’ai recréé sur Azure différentes ressources pour simuler deux environnements sur site :

  • 2 réseaux en connexion site à site avec 2 passerelles VPN :
  • 2 réseaux en connexion point à site avec des PCs équipés du client Azure VPN :

Afin d’effectuer mes tests de connectivités entre tous ces réseaux, j’ai également déployé les machines virtuelles suivantes :

Afin d’avoir une vue d’ensemble de l’infrastructure WAN, Microsoft propose une cartographie fidèle avec toutes les liaisons internes et externes :

Toute la configuration WAN côté infrastructure Azure peut s’effectuer directement depuis la page du portail Azure dédiée à mon Azure WAN.

Configuration WAN :

Pour arriver à ce résultat, une fois le WAN déployé, j’ai créé ici les 2 hubs suivants :

J’ai activé les liaisons suivantes via la configuration de mon WAN :

Configuration des 2 hubs :

Pour chacun des 2 hubs, j’ai activé les passerelles VPN Site à Site et Point à Site (30 minutes d’attente par liaison) :

Connexions aux 4 réseaux virtuels Azure :

Depuis la page d’Azure WAN, j’ai connecté les 4 réseaux virtuels internes à mon infrastructure Azure à mes 2 hubs :

J’ai utilisé la route par Default pour chacune des liaisons :

Connexions aux réseaux locaux Site à site :

Depuis la page Azure WAN, j’ai créé 2 sites physiques respectivement connectés à mes 2 hubs :

Pour chacun des 2 sites, j’ai indiqué leur plan d’adressage respectif :

Une fois les 2 liaisons VPN Site à Site déployées et connectées, ces dernières sont alors bien respectivement visibles sur les 2 hubs :

Une fois toutes les connexions internes et externes en place, les différentes routes sont bien visibles sur chacun de mes 2 hubs :

Connexions Points à site :

Toujours sur la page Azure WAN, j’ai mis en place une configuration unique concernant le type de tunnel et la méthode d’authentification Entra ID :

Afin d’assurer une authentification via Entra ID, j’ai mis en place un tunnel Point à Site de type OpenVPN :

Comme mon précédent article parlant déjà du VPN Point à Site, j’ai configuré les informations suivantes en relation avec mon tenant Microsoft :

J’ai installé Azure VPN sur mes 2 PCs situés en mobilité :

La configuration VPN établie par mon WAN repose sur un FQDN unique. Cela permet d’établir la connexion Point à Site vers le hub le plus proche de façon transparente et automatique :

Poste 1 :

Poste 2 :

Une fois la connexion VPN cliente établie, les informations sont visibles sur le hub :

Mon environnement WAN est maintenant en place, il ne me reste plus qu’à tester les accès et la transitivité de l’infrastructure toute entière.

Tests des accès :

Pour cela, j’ai installé le service Azure Bastion sur le réseau virtuel contenant un PC en mobilité :

J’ai démarré la connexion Point à Site via Azure VPN en utilisant le SSO de l’OS :

J’ai pu ouvrir avec succès des connexions RDP vers toutes les machines virtuelles de mon WAN :

  • Second PC en mobilité ayant une connexion Point à Site ouverte sur l’autre hub
  • Serveur ayant une connexion Site à Site ouverte sur le même hub
  • Serveur ayant une connexion Site à Site ouverte sur l’autre hub
  • Serveurs ayant un appairage de réseau virtuel sur le même hub
  • Serveurs ayant un appairage de réseau virtuel sur l’autre hub

Le routage vers toutes les machines s’est donc effectuée sans aucun autre composant additionnel qu’Azure WAN lui-même 💪

Surveillance des liaisons :

Une fois le WAN en place, la surveillance des liaisons est indispensable afin d’y remédier au plus vite car ces dernières sont souvent critiques pour un ou plusieurs services de l’entreprise.

Pour cela des métriques sont disponibles via le menu Insights de mon Azure WAN :

De plus, Azure WAN peut s’appuyer sur le service Connection Monitor disponible sous Network Watcher afin d’établir des tests de connectivité et des règles d’alerte.

J’ai configuré Connection Monitor afin d’effectuer des tests ICMP vers Azure, mais aussi vers mes 2 sites physiques :

A peine les tests créés, Connection Monitor affiche les résultats :

Différentes informations sont disponibles sur ces tests :

Afin de simuler une panne, j’ai simplement éteint une machine virtuelle Azure sur site :

A peinte la machine virtuelle éteinte, Connection Monitor indique déjà des échecs dans les tests concernés :

Le détail du test en défaut nous affiche également le routage et même le lieu exact du blocage de la liaison :

Azure Monitor affiche également les 2 alerte déclenchée :

Grâce au groupe d’action configuré sur la règle de l’alerte créée par Connection Monitor, une notification par e-mail me parvient immédiatement :

Afin de retrouver une situation opérationnelle, je rallume la machine virtuelle sur site précédemment éteinte :

Quelques minutes plus tard, les alertes générées sont automatiquement résolues :

De retour sur Connection Monitor, tous les tests repassent alors en vert :

Conclusion

En résumé, Azure WAN offre une solution robuste, sécurisée et évolutive pour connecter et gérer les réseaux distribués à travers le monde. Il simplifie la gestion des infrastructures réseau tout en garantissant des performances et une sécurité optimales, ce qui en fait une option précieuse pour les entreprises cherchant à moderniser leurs infrastructures réseau.

Migrez un ancien OS Windows sur le Cloud Azure

De mon côté, l’aventure IT a commencé en décembre 1995 avec mon tout premier ordinateur : un 486 SX-33 développé par Intel. Je ne saurais me rappeler de sa quantité de mémoire vive, mais je pense que je pouvais les compter sur les doigts d’une seule main 🤣.

Plus sérieusement, que ce passe-t-il si une application métier, toujours fonctionnelle et devant perdurer, doit être migrée au plus vite pour une raison X ?

Microsoft a peut-être une réponse grâce au le service Azure Migrate :

Azure Migrate offre un service simplifié de migration, de modernisation et d’optimisation pour Azure. Toutes les étapes de pré-migration telles que la détection, les évaluations et le dimensionnement des ressources locales sont incluses pour l’infrastructure, les données et les applications. L’infrastructure extensible d’Azure Migrate permet d’intégrer des outils tiers, ce qui augmente l’étendue des cas d’utilisation pris en charge.

Microsoft Learn

Pour vous faire une meilleure idée d’Azure Migrate, un atelier exercice dédié à la migration vers Azure conçu par Microsoft avait déjà été détaillé sur ce blog juste ici.

Comme le montre le schéma ci-dessous, l’objectif de cet exercice est de migrer plusieurs serveurs virtuels gérés sous un serveur Hyper-V vers le Cloud Azure :

Qu’est-ce que Disk2vhd ?

Il s’agit d’un petit utilitaire très pratique développé par Mark Russinovich et disponible dans la suite Sysinternals :

Disk2vhd est un utilitaire qui crée des versions VHD (Virtual Hard Disk – Microsoft’s Virtual Machine disk format) de disques physiques à utiliser dans Microsoft Virtual PC ou Microsoft Hyper-V virtual machines (VMs). La différence entre Disk2vhd et d’autres outils physiques à virtuels est que vous pouvez exécuter Disk2vhd sur un système en ligne.

Microsoft Learn

Disk2vhd utilise la capacité d’instantané de volume de Windows, introduite dans Windows XP, pour créer des instantanés cohérents à un instant donné des volumes que vous souhaitez inclure dans une conversion. Vous pouvez même demander à Disk2vhd de créer les VHD sur des volumes locaux, même ceux en cours de conversion (bien que les performances soient meilleures lorsque le VHD se trouve sur un disque différent de ceux en cours de conversion).

Microsoft Learn

Au travers de ce nouvel article, je souhaitais tester avec vous la copie de plusieurs serveurs physiques fonctionnant sous d’anciens OS afin de tester un portage rapide et simple vers Azure :

  • Windows XP Professional
  • Windows 7 Professional x64
  • Windows 10 Enterprise x64
  • Windows Server 2008 R2 x64
  • Windows Server 2012 R2 x64
  • Windows Server 2016 x64

Pour cela, cet article repose sur la méthode de préparation d’un fichier VHD proposée par Microsoft et exposée juste ici, dont les principales commandes de préparation sont disponibles sur mon GitHub.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice de migration individuelle, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

N’ayant pas d’anciens serveurs physiques à disposition, j’ai choisi de les simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.

Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.

Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées :

Conservez les options par défaut, puis cliquez sur OK :

Cliquez ensuite sur Suivant :

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle hôte (Hyper-V) :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les deux rôles suivants :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

Attendez environ une minute que l’installation des 2 rôles se termine :

Lancez la commande suivante pour lancer un redémarrage immédiat de votre VM hôte (Hyper-V) :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour vous reconnecter à celle-ci, toujours via le service Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, couplé au serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Sur celui-ci, créez un nouveau volume :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Terminer :

L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.

Etape II – Création de la machine virtuelle invitée :

Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :

Stockez le fichier ISO sur le disque F de votre VM hôte (Hyper-V) :

Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :

Cliquez-ici pour créer votre machine virtuelle invitée :

Cliquez sur Suivant :

Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :

Choisissez Génération 1 :

Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :

Une fois la machine virtuelle invitée créée, modifiez sa configuration comme ceci :

Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows, puis cliquez sur OK :

Répétez les mêmes opérations pour les autres OS dont vous souhaitez tester la migration vers Azure :

Double-cliquez sur votre machine virtuelle invitée :

Cliquez-ici pour lancer le démarrage de la VM invitée :

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows :

Attendez que le démarrage de l’installation se lance, puis cliquez-ici pour ne pas renseigner de clef de licence Windows :

Choisissez une version Desktop de Windows, puis cliquez sur Suivant :

Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :

Sélectionnez l’installation personnalisée de Windows :

Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :

Attendez maintenant que l’installation de Windows commence :

Lancez le redémarrage de la machine virtuelle invitée :

Donnez à nom si nécessaire à votre compte local Windows et un mot de passe :

La machine virtuelle invitée avec l’ancien OS Windows est maintenant en place. Comme pour une machine physique, nous allons maintenant générer un fichier VHD afin de pouvoir préparer l’OS à être remonté sur Azure.

Avant cela, quelques modifications sont nécessaires.

Etape III – Génération du fichier VHD :

Sur votre VM hôte (Hyper-V), créez un nouveau dossier contenant une ou plusieurs versions de l’outil Disk2vhd selon l’ancienneté de l’OS concerné :

Partagez ce dossier sur le réseau :

Créez un second dossier dédié au VHD généré par l’outil Disk2vhd, puis partagez ce dossier sur le réseau :

Depuis la machine virtuelle invitée, ouvrez l’application Disk2vhd depuis le premier partage, puis sauvegardez votre fichier VHD sur le second partage :

Le traitement VSC peut prendre entre 5 minutes et 2 heures :

Le message de succès apparaît alors à la fin du traitement :

Effectuez ces mêmes opérations de génération du fichier VHD pour chacun des OS comme ceci :

Fermez la session utilisateur de votre machine virtuelle invitée :

Eteignez également votre machine virtuelle invitée :

Effectuez ces opérations d’arrêt pour chacune des machines virtuelles invitées :

Les machines virtuelles de départ sont maintenant toutes éteintes. Avant de pouvoir transférer le fichier VHD vers Azure, il est nécessaire d’effectuer plusieurs opérations au niveau de l’OS, mais également du fichier VHD.

Etape IV – Préparation du fichier VHD :

Pour cela, nous allons recréer de nouvelles machines virtuelles identiques, dans lesquelles nous allons passer plusieurs commandes PowerShell.

Toujours sur Hyper-V Manager, cliquez-ici pour créer une nouvelle machine virtuelle invitée :

Cliquez sur Suivant :

Modifier les informations suivantes, puis cliquez sur Suivant :

Choisissez Génération 1 :

Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :

Utilisez le même switch que précédemment, puis cliquez sur Suivant :

Rattachez le nouveau disque VHD généré via Disk2vhd, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :

Une fois la machine virtuelle invitée créée, modifiez le nombre de processeurs virtuels, puis cliquez sur OK :

Répétez les mêmes opérations pour les autres OS, puis double-cliquez sur une nouvelle machine virtuelle invitée :

Cliquez-ici pour lancer le démarrage de la VM invitée :

Depuis le menu Démarrer, recherchez Windows PowerShell ISE en mode administrateur :

Confirmez le risque sécuritaire en cliquant sur Oui :

Ouvrez le fichier de script suivant, disponible sur mon GitHub :

Lancez la commande System File Checker (SFC) afin de vérifier les fichiers systèmes Windows :

sfc.exe /scannow

Quelques minutes plus tard, SFC vous confirme le succès du contrôle :

Lancez la commande netsh afin de réinitialiser les paramètre proxy :

netsh.exe winhttp reset proxy

Ouvrez via CMD en mode administrateur afin de lancez l’utilitaire Diskpart :

diskpart.exe
san policy=onlineall
exit

Configurez l’heure UTC pour Windows :

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation -Name RealTimeIsUniversal -Value 1 -Type DWord -Force
Set-Service -Name w32time -StartupType Automatic

Modifiez le profil d’alimentation en performances hautes :

powercfg.exe /setactive SCHEME_MIN
powercfg /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOIDLE 0

Réinitialisez les variables systèmes par défaut :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name TEMP -Value "%SystemRoot%\TEMP" -Type ExpandString -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name TMP -Value "%SystemRoot%\TEMP" -Type ExpandString -Force

Réinitialisez par défaut certains services Windows :

Get-Service -Name BFE, Dhcp, Dnscache, IKEEXT, iphlpsvc, nsi, mpssvc, RemoteRegistry |
  Where-Object StartType -ne Automatic |
    Set-Service -StartupType Automatic

Get-Service -Name Netlogon, Netman, TermService |
  Where-Object StartType -ne Manual |
    Set-Service -StartupType Manual

Activez le service bureau à distance RDP :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name fDenyTSConnections -Value 0 -Type DWord -Force

Validez le port par défaut 3389 pour le protocole RDP :

L’auditeur écoute sur chaque interface réseau :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name LanAdapter -Value 0 -Type DWord -Force

Configurez le mode d’authentification au niveau du réseau (NLA) pour les connexions RDP selon l’OS :

Pour Windows Server 2012, 2016 et pour Windows 10 :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1 -Type DWord -Force

Pour Windows Server 2008 R2 et pour Windows 7 :

Set-Itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -value '0'
Set-Itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -value '0'

Définissez la valeur keep-alive :

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name KeepAliveEnable -Value 1  -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name KeepAliveInterval -Value 1  -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name KeepAliveTimeout -Value 1 -Type DWord -Force

Définissez les options de reconnexion :

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name fDisableAutoReconnect -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name fInheritReconnectSame -Value 1 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name fReconnectSame -Value 0 -Type DWord -Force

Limitez le nombre de connexions simultanées :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -Name MaxInstanceCount -Value 4294967295 -Type DWord -Force

Supprimez tous les certificats auto-signés liés à l’écoute RDP :

if ((Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp').Property -contains 'SSLCertificateSHA1Hash')
{
    Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name SSLCertificateSHA1Hash -Force
}

Activez le pare-feu Windows sur les 3 profils réseaux (domaine, standard et public) :

Set-NetFirewallProfile -Profile Domain, Public, Private -Enabled True

Ouvrez l’explorateur de fichiers Windows, cliquez sur le menu Réseau, puis changez l’option suivante :

Activez l’option suivante :

Convertissez la connexion actuelle en réseau privé :

Activer le service à distance PowerShell :

Activez les règles de pare-feu suivantes pour autoriser le trafic RDP :

Activez la règle des requêtes ping à l’intérieur du réseau virtuel :

Créez les règles suivantes entrantes et sortantes point vers le service DNS d’Azure :

Ouvrez CMD en mode administrateur afin de lancer l’utilitaire Diskpart :

chkdsk.exe /f

Lancez le redémarrage de la machine virtuelle invitée :

N’appuyez sur aucune touche afin de lancer le contrôle du disque :

Attendez la fin de traitement :

Réouvrez la session Windows de votre machine virtuelle invitée :

Ouvrez CMD en mode administrateur afin de définir les paramètres des données de configuration de démarrage (BCD) :

cmd

bcdedit.exe /set "{bootmgr}" integrityservices enable
bcdedit.exe /set "{default}" device partition=C:
bcdedit.exe /set "{default}" integrityservices enable
bcdedit.exe /set "{default}" recoveryenabled Off
bcdedit.exe /set "{default}" osdevice partition=C:
bcdedit.exe /set "{default}" bootstatuspolicy IgnoreAllFailures

#Enable Serial Console Feature
bcdedit.exe /set "{bootmgr}" displaybootmenu yes
bcdedit.exe /set "{bootmgr}" timeout 5
bcdedit.exe /set "{bootmgr}" bootems yes
bcdedit.exe /ems "{current}" ON
bcdedit.exe /emssettings EMSPORT:1 EMSBAUDRATE:115200

exit

Réouvrez Windows PowerShell ISE en mode administrateur :

Activez la collecte des journaux d’erreur :

# Set up the guest OS to collect a kernel dump on an OS crash event
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -Type DWord -Force -Value 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name DumpFile -Type ExpandString -Force -Value "%SystemRoot%\MEMORY.DMP"
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name NMICrashDump -Type DWord -Force -Value 1
# Set up the guest OS to collect user mode dumps on a service crash event
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
if ((Test-Path -Path $key) -eq $false) {(New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting' -Name LocalDumps)}
New-ItemProperty -Path $key -Name DumpFolder -Type ExpandString -Force -Value 'C:\CrashDumps'
New-ItemProperty -Path $key -Name CrashCount -Type DWord -Force -Value 10
New-ItemProperty -Path $key -Name DumpType -Type DWord -Force -Value 2
Set-Service -Name WerSvc -StartupType Manual

Vérifiez que le référentiel Windows Management Instrumentation (WMI) est toujours cohérent :

winmgmt.exe /verifyrepository

Assurez-vous qu’aucune autre application que TS n’utilise le port 3389 :

netstat.exe -anob | findstr 3389

Vérifiez les mises à jour Windows :

Lancez le redémarrage de la machine virtuelle invitée :

Depuis votre machine virtuelle hôte (Hyper-V), vérifiez la bonne ouverture de session RDP :

Eteignez votre machine virtuelle invitée :

Notre machine virtuelle invitée est maintenant prête à être migrée vers Azure. Pour cela, nous allons utilisez la commande PowerShell Add-AzVhd.

Etape V – Création de la machine virtuelle Azure :

Depuis le portail Azure, créez un nouveau groupe de ressources pour la machine virtuelle invitée dans le Cloud :

Depuis votre machine virtuelle hôte (Hyper-V), connectez-vous à votre environnement Azure via PowerShell ISE :

Lancez les commandes PowerShell Azure suivantes afin de créer un disque managé Azure depuis le fichier VHD local :

Add-AzVhd -LocalFilePath C:\data.vhd -ResourceGroupName rgname -Location eastus -DiskName newDisk

Une première étape de détection commence alors :

Suivi du calcul de Hash :

Pour finir par le transfert vers Azure :

Retournez sur le groupe de ressources Azure créé précédemment, constatez la présence d’un disque managé, puis cliquez dessus :

Cliquez ici pour créer la machine virtuelle :

Renseignez les informations de base :

Choisissez la taille de votre VM, puis cliquez sur Suivant :

Sur l’onglet Réseau, reprenez le même réseau virtuel que celui utilisé pour votre machine virtuelle Hyper-V, puis lancez la validation Azure :

Une fois la validation Azure passée, lancez la création des ressources :

Attendez quelques minutes le succès de la création de votre VM, puis cliquez ici :

Attendez quelques minutes le démarrage complet de votre VM :

Vérifiez le bon démarrage de votre VM en actualisant si besoin plusieurs fois le screenshot suivant :

Constatez la présence de l’avertissement Azure suivant :

Renseignez les identifiants renseignés lors de la création de votre VM invitée :

Constatez la bonne ouverture de session Windows :

Une fois la session Windows ouverte, installez l’agent pour les machines virtuelles Azure disponible sur cette page GitHub :

Exécutez le fichier MSI d’installation depuis une session PowerShell avec les droits administrateurs :

Cliquez sur Suivant :

Acceptez les termes et conditions, puis cliquez sur Suivant :

Attendez quelques minutes la fin de l’installation de l’agent :

Cliquez sur Terminer :

Quelques minutes plus tard, constatez la disparition de l’alerte Azure sur votre VM :

Vérifiez la bonne relation entre le management Azure et votre VM via le menu suivant :

La commande suivante doit vous retourner la configuration IP renseignée sur votre VM :

Effectuez un test d’arrêt de votre machine virtuelle :

Confirmez votre action en cliquant sur Oui :

Effectuez un test de démarrage de votre machine virtuelle :

Vérifiez le succès des 2 opérations via les notifications Azure :

Cliquez-ici pour rouvrir la session Windows ouverte précédemment via Azure Bastion :

Effectuez les mêmes opérations pour les autres anciens OS à tester :

Conclusion

Par cette démonstration, un portage rapide et en urgence de certaines anciennes versions Windows, client ou serveur, est parfaitement possible. Quelques manipulations de préparation sont nécessaires, mais ces dernières sont fonctionnelles pour les OS suivants :

  • Windows 7 Professional x64
  • Windows 10 Enterprise x64
  • Windows Server 2008 R2 x64
  • Windows Server 2012 R2 x64
  • Windows Server 2016 x64

Autopilot v2 💪💻🚨

Vous commencez enfin à maîtriser le service Autopilot de Microsoft et vous vous en servez déjà pour déployer vos postes ? Cela tombe très bien ! Microsoft vient justement de sortir il y a quelques mois la Préparation de l’appareil Windows Autopilot. Peut-on parler de cette nouvelle fonctionnalité comme d’un Autopilot en version 2 ? Oui et non, mais cela va encore plus démocratiser Intune auprès des services IT.

Cet article est donc une suite logique à un autre article détaillant la méthode Autopilot v1, déjà en place depuis assez longtemps. Au travers de ce nouvel écrit, nous allons tester l’intégration d’un PC via cette nouvelle méthode Autopilot v2, dont le nom officiel chez Microsoft est Préparation de l’appareil Windows Autopilot.

Quelles sont les différences entre Autopilot v1 et Autopilot v2 ?

Le fait de les appeler v1 et v2 un choix personnel afin de gagner en clarté, ce qui ne veut pas dire que la seconde est un remplacement complet de la première. Voici d’ailleurs une comparaison v1/v2 rédigée par Microsoft :

FonctionnalitéWindows Autopilot
préparation de l’appareil
(Autopilot v2)
Windows Autopilot (Autopilot v1)
FonctionnalitésPrise en charge des environnements Government Community Cloud High (GCCH) et ministère de la Défense (DoD). Expérience d’approvisionnement plus rapide et plus cohérente. Informations de surveillance et de résolution des problèmes en quasi-temps réel.Prise en charge de plusieurs types d’appareils (HoloLensSalle de réunion Teams). De nombreuses options de personnalisation pour l’expérience d’approvisionnement.
Modes pris en chargePiloté par l’utilisateur;Piloté par l’utilisateur; Préprovisionné. Déploiement automatique. Appareils existants.
Types de jointure pris en chargeRejoindre Microsoft Entra.Rejoindre Microsoft Entra.
Jointure hybride Microsoft Entra.
Inscription de l’appareil requise ?Non.Oui.
Que doivent configurer les administrateurs ?Stratégie de préparation des appareils Windows Autopilot. Groupe de sécurité de l’appareil avec le client d’approvisionnement Intune en tant que propriétaire.Profil de déploiement Windows Autopilot. Page d’état d’inscription (ESP).
Quelles configurations peuvent être fournies lors de l’approvisionnement ?Basé sur l’appareil uniquement pendant l’expérience out-of-box (OOBE).Jusqu’à 10 applications essentielles (métier), Win32, Microsoft Store, Microsoft 365). Jusqu’à 10 scripts PowerShell essentiels.Basé sur l’appareil pendant l’ESP de l’appareil. Basé sur l’utilisateur pendant l’ESP utilisateur. N’importe quel nombre d’applications.
Résolution des problèmes de création de rapports &Rapport de déploiement de la préparation de l’appareil Windows Autopilot : Affiche tous les déploiements de préparation des appareils Windows Autopilot. Davantage de données disponibles. Quasiment en temps réel.Rapport de déploiement Windows Autopilot : Affiche uniquement les appareils inscrits sur Windows Autopilot. Pas en temps réel.
Prend en charge les applications métier et Win32 dans le même déploiement ?Oui.Non.
Versions prises en charge de WindowsWindows 11, version 23H2 avec KB5035942 ou version ultérieure. Windows 11, version 22H2 avec KB5035942 ou version ultérieure.Toutes les versions actuellement prises en charge du canal de disponibilité générale De Windows 11.Toutes les versions actuellement prises en charge du canal de disponibilité générale Windows 10.

Mais cette nouvelle méthode pourrait correspondre à certains scénarios comme le suggère Microsoft :

Conditions requisesWindows Autopilot
préparation de l’appareil
(Autopilot v2)
Windows Autopilot
(Autopilot v1)
Government Community Cloud High (GCCH) et
Environnements du ministère de la Défense (DoD)
Scénario piloté par l’utilisateur
Scénario pré-provisionné
Scénario de déploiement automatique
Scénario d’appareils existants
Prise en charge de la réinitialisation d’Autopilot
Jonction Microsoft Entra
Jonction Microsoft Entra hybride
Réinitialisation de Windows Autopilot
Windows 11
Windows 10
Déployer des applications Win32 et métier
dans le même déploiement
Configuration et expérience de déploiement plus simples
Personnalisation étendue du déploiement
et expérience OOBE
Aucune exigence de pré-phaser les appareils
Installer plus de 10 applications pendant OOBE
Exécuter plus de 10 scripts PowerShell pendant OOBE
Surveillance en quasi-temps réel
Empêcher l’utilisateur d’accéder au Bureau jusqu’à ce que
les configurations basées sur l’utilisateur sont appliquées
Prise en charge d’HoloLens
Prise en charge des salles de réunion Teams
Interface de configuration du microprogramme d’appareil
(DFCI) Prise en charge de la gestion
Autopilot dans la cogestion

Pourquoi changer ce qui marche déjà ?

Comme le rappel l’excellent billet écrit sur le site de Synapsys, Microsoft a souhaité faire évoluer son service Autopilot créé en 2017 afin de pouvoir supporter un plus grand nombre d’appareils. Cela va permettre de gérer le provisionnement des Cloud PC Windows 365 ou pour des clients dont le tenant est sur une instance Gov du Cloud Microsoft :

Windows Autopilot Device Preparation vise à simplifier encore plus le déploiement des périphériques, en optimisant le temps global de préparation de celui-ci et en améliorant notamment la résolution des problématiques qui peuvent survenir pendant le déploiement ainsi que le reporting. 

Synapsys-groupe

Et bien sûr, plus besoin du hash 😎 :

La grosse nouveauté comparée à Windows Autopilot est qu’il n’est plus nécessaire d’importer le hash matériel pour pouvoir bénéficier du service. Autre nouveauté, le profil de déploiement sera à déployer sur un profil utilisateur et non machine. 

Synapsys-groupe

Ai-je besoin de licences spécifiques pour Autopilot v2 ?

Comme il est rappelé dans la documentation Microsoft, Autopilot v2 a besoin des mêmes licences que pour Autopilot v1. Voici une liste non exhaustive de licences ou combinaison de licences possibles :

  • Licence Microsoft 365 Business Premium
  • Licence Microsoft 365 F1 ou F3
  • Licence Microsoft 365 Academic A1, A3 ou A5
  • Licence Microsoft 365 Entreprise E3 ou E5
  • Licence Enterprise Mobility + Security E3 ou E5
  • Licence Intune pour l’éducation
  • Licence ID Microsoft Entra P1 ou P2 + Licence Microsoft Intune

Afin de se faire une meilleure idée sur Autopilot v2, je vous propose un petit exercice à réaliser sur une souscription Azure.

Dans cet exercice, nous allons effectuer les étapes suivantes :

Microsoft a même mis à disposition un très bon tutoriel pour Autopilot v2 juste ici :

Etape 0  –  Rappel des prérequis :

Afin de tester la fonctionnalité d’intégration proposée via Autopilot v2, nous allons avoir besoin de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une ou des licences contenant Intune et Azure AD Premium P1
  • Une Image OS de Windows 11, version 22H2 ou 23H2 générée après avril 2024 ou avec le KB5035942

Etape I – Configurer l’inscription automatique Windows à Intune :

Commençons par la configuration sur Entra ID.

Pour que la préparation des appareils Windows Autopilot (Autopilot v2) fonctionne, les appareils doivent être en mesure de s’inscrire automatiquement dans Intune. L’inscription automatique des appareils dans Intune peut être configurée automatiquement dans le portail Azure

Microsoft Learn

La méthode d’inscription à Intune avec Autopilot v2 ne diffère pas de la première : il est nécessaire de configurer une inscription automatique à Intune depuis le portail Entra ID.

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis cliquez sur cela :

Définissez le périmètre de l’inscription automatique MDM à Intune, puis cliquez sur Sauvegarder :

Restons sur le portail d’Entra ID afin d’autoriser les utilisateurs à joindre des machines à Intune.

Etape II – Autoriser les utilisateurs à joindre des appareils :

Pour rappel, il existe plusieurs types de jointures possibles à Entra ID, dont voici un lien vers un précédent article. Avec Autopilot v2, les utilisateurs ont toujours besoin d’être autorisé à joindre des postes à Entra ID.

Pour que la préparation des appareils Windows Autopilot fonctionne, les utilisateurs doivent être autorisés à joindre des appareils à l’ID Microsoft Entra.

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis activez cette option :

Continuons avec la création d’un premier groupe Entra ID dédié aux postes Intune.

Etape III – Créer un groupe d’appareils Entra ID :

La préparation des appareils Windows Autopilot utilise un groupe d’appareils dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Le groupe d’appareils spécifié dans la stratégie de préparation des appareils Windows Autopilot est le groupe d’appareils dans lequel les appareils sont ajoutés automatiquement pendant le déploiement de la préparation de l’appareil Windows Autopilot

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis créer un groupe dédié aux appareils automatiquement inscrits par Autopilot v2 :

Ajoutez le propriétaire Intune Provisioning Client ou avec son principal de service dont l’ID est le suivant : f1346770-5b25-470b-88bd-d5744ab7952c :

N’ajoutez aucun membre manuellement, puis cliquez sur Créer :

Continuons avec la création d’un second groupe Entra ID dédié aux utilisateurs Intune.

Etape IV – Créer un groupe d’utilisateurs Entra ID :

La préparation de l’appareil Windows Autopilot utilise un groupe d’utilisateurs dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Les utilisateurs membres du groupe d’utilisateurs spécifié dans la stratégie de préparation de l’appareil Windows Autopilot sont les utilisateurs qui reçoivent le déploiement de la préparation de l’appareil Windows Autopilot.

Microsoft Learn

Pour cela, restez sur le même menu qui précédemment d’Entra ID, puis créer un second groupe cette fois dédié aux utilisateurs concernés par le processus Autopilot v2 :

Ajoutez des membres manuellement ou dynamiquement en correspondance avec vos utilisateurs Autopilot v2, puis cliquez sur Créer :

Continuons avec la configuration de postes sous Intune.

Etape V – Affectation de la configuration Intune :

Pendant l’expérience OOBE (out-of-box experience) avant que l’utilisateur final ne soit connecté pour la première fois, la préparation de l’appareil Windows Autopilot permet de déployer jusqu’à :

  • 10 applications managées
  • 10 scripts PowerShell

Pour que les applications s’installent et que les scripts PowerShell fonctionnent correctement, ils doivent être affectés au groupe d’appareils créé pour la préparation des appareils Windows Autopilot.

Microsoft Learn

J’ai souhaité dans mon cas créer différents scénarios d’installation d’applications :

  • Applications intégrées au processus Autopilot v2 :
    • Microsoft Company Portal (Windows Store)
    • Global Secure Access (EXE)
  • Applications obligatoires pour les postes Intune :
    • Google Chrome (MSI)
    • Microsoft 365 Apps (Microsoft 365 Apps)
  • Applications disponibles pour les utilisateurs Intune :
    • Adobe Acrobat Reader DC (Windows Store)
    • Mozilla Firefox (Windows Store)
    • Notepad X (Windows Store)

Pour cela, rendez-vous dans le menu suivant d’Intune, puis rajoutez vos applications concernées :

J’ai également rajouté un script PowerShell, mais que je ne souhaite pas intégrer dans le processus Autopilot v2 car les applications installées ou les scripts PowerShell qui s’exécuteront systématiquement dans un contexte système.

Il ne nous reste maintenant qu’à créer la stratégie de préparation des appareils Windows Autopilot.

Etape VI – Création de la stratégie de préparation des appareils Windows Autopilot :

La stratégie Autopilot spécifie la façon dont l’appareil est configuré pendant l’installation de Windows et ce qui est affiché pendant l’expérience OOBE (out-of-box experience).

Microsoft Learn

Pour cela, rendez-vous dans le menu suivant d’Intune, puis cliquez sur le menu suivant :

Cliquez sur Créer :

Cliquez sur Suivant :

Nommez votre profil, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux postes Intune via Autopilot v2, puis cliquez sur Suivant :

Définissez les paramètres de configuration Autopilot v2 :

Personnalisez l’expérience OOBE :

Ajoutez les applications intégrées dans le processus Autopilot v2 :

Ajoutez si besoin les scripts intégrés dans le processus Autopilot v2, puis cliquez sur Suivant :

Modifiez les tags au besoin, puis cliquez sur Suivant :

Ajoutez le groupe dédié aux utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Cliquez sur Sauvegarder :

La configuration Autopilot v2 est maintenant terminée, il ne nous reste qu’à créer une machine virtuelle Hyper-V sur Azure pour ensuite créer des machines sous Windows 11.

Etape VII – Préparation de la machine virtuelle hôte Hyper-V :

Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :

Cliquez ici pour créer votre machine virtuelle hôte (Hyper-V) :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présente dans la famille Dsv3, puis cliquez sur Suivant :

Rajoutez un second disque pour stocker la machine virtuelle Windows 11, créée plus tard dans notre machine virtuelle hôte (Hyper-V) :

Conservez les options par défaut, puis cliquez sur OK :

Cliquez ensuite sur Suivant :

Retirez l’adresse IP publique (pour des questions de sécurité), puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez ici pour voir votre machine virtuelle Hyper-V :

Ensuite, cliquez-ici pour déployer le service Azure Bastion :

Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :

Peu après, constatez le déploiement réussi d’Azure Bastion via la notification Azure suivante :

Renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :

Autorisez le fonctionnement du presse-papier pour Azure Bastion :

Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :

Exécutez la commande suivante pour installer les 2 rôles suivants :

  • Rôle DHCP
  • Rôle Hyper-V
Install-WindowsFeature -Name DHCP,Hyper-V  –IncludeManagementTools

Attendez environ une minute que l’installation des 2 rôles se termine :

Lancez la commande suivante pour lancer un redémarrage de votre VM Hyper-V :

Shutdown -R

Attendez environ 30 secondes que le redémarrage se termine pour se reconnecter à celle-ci, toujours via Azure Bastion :

Une fois la session Bastion rouverte, ouvrez PowerShell en mode ISE :

Lancez le script suivant afin de créer un switch virtuel dans Hyper-V, et de type interne :

$switchName = "InternalNAT"
New-VMSwitch -Name $switchName -SwitchType Internal
New-NetNat –Name $switchName –InternalIPInterfaceAddressPrefix “192.168.0.0/24”
$ifIndex = (Get-NetAdapter | ? {$_.name -like "*$switchName)"}).ifIndex
New-NetIPAddress -IPAddress 192.168.0.1 -InterfaceIndex $ifIndex -PrefixLength 24

Lancez le script suivant afin de configurer un périmètre DHCP avec une règle de routage, et le serveur DNS d’Azure :

Add-DhcpServerV4Scope -Name "DHCP-$switchName" -StartRange 192.168.0.50 -EndRange 192.168.0.100 -SubnetMask 255.255.255.0
Set-DhcpServerV4OptionValue -Router 192.168.0.1 -DnsServer 168.63.129.16
Restart-service dhcpserver

Depuis la console Server Manager, ouvrez Hyper-V Manager :

Ouvrez le menu suivant :

Contrôlez la présence de votre switch virtuel créé précédemment :

Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM Hyper-V :

Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :

Sur celui-ci, créez un nouveau volume :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle Windows 11.

Etape VIII – Création de la machine virtuelle Windows 11 :

Pour cela, il est nécessaire de récupérer une image au format ISO de Windows 11 afin d’y installer l’OS.

Toujours sur la machine virtuelle Hyper-V, ouvrez le navigateur internet Microsoft Edge.

Rendez-vous sur la page suivante pour télécharger l’ISO de Windows 11, puis effectuez les actions suivantes :

Choisissez la langue désirée, puis cliquez sur Confirmer :

Cliquez sur la version 64 bits pour lancer le téléchargement :

Attendez quelques minutes pour que le téléchargement de l’ISO se termine :

Depuis votre VM Hyper-V, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows 11 :

Cliquez sur Suivant :

Modifiez les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :

Pensez à bien sélectionner Génération 2 :

Comme indiqué, cette option ne sera plus modifiable par la suite.

Modifiez la taille de la mémoire vive allouée à la VM Windows 11, puis cliquez sur Suivant :

Utilisez le switch créé précédemment, puis cliquez sur Suivant :

Cliquez sur Suivant :

Utilisez le fichier ISO de Windows 11 téléchargé précédemment, puis cliquez sur Suivant :

Cliquez sur Terminer pour finaliser la création de votre machine virtuelle Windows 11 :

Une fois la machine virtuelle Windows 11 créée, modifiez sa configuration comme ceci :

Dans la section Sécurité, cochez la case suivante pour activer TPM :

Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows 11, puis cliquez sur OK :

Double-cliquez sur votre machine virtuelle Windows 11 :

Cliquez-ici pour lancer le démarrage de la VM Windows 11 :

Appuyez sur n’importe quelle touche du clavier pour démarrer sur l’image ISO de Windows 11 :

Attendez que le chargement se termine :

La machine virtuelle est maintenant prête à recevoir l’OS Windows 11. Suivez toutes les étapes de l’installation pour le configurer et l’installer.

Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :

Lancez l’installation de Windows 11 :

Choisissez une version de Windows 11, puis cliquez sur Suivant :

Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :

Sélectionnez l’installation personnalisée de Windows 11 :

Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :

Attendez maintenant que l’installation de Windows 11 commence :

Lancez le redémarrage de la machine virtuelle Windows 11 :

Tout est bon, il ne nous reste plus qu’à voir si nouvelle méthode d’Autopilot v2 prend bien la suite de la configuration une fois l’utilisateur 365 authentifié.

Etape IX – Test Autopilot v2 :

Attendez quelques minutes que le redémarrage se termine :

Une fois l’interface Windows 11 affichée, sélectionnez le pays adapté, puis cliquez sur Oui :

Choisissez le clavier correspondant au vôtre, puis cliquez sur Oui :

Ajoutez si besoin un second clavier :

Attendez que l’installation de Windows 11 vérifie si de nouvelles mises à jour sont disponibles :

Le traitement peut être plus ou moins long :

Un redémarrage est même possible :

Afin que le processus Autopilot v2 fonctionne, configurez votre Windows 11 avec un des utilisateurs appartenant au groupe créé pour les utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :

Windows 11 se connecte alors au compte 365 pour en comprendre la configuration Autopilot v2 :

Le processus de préparation des appareils Windows Autopilot démarre alors :

Une fois le traitement terminé, cliquez sur Accepter :

Si besoin, déverrouillez la session Windows pour continuer :

Attendez la fin de configuration Windows :

Vous voilà enfin sur le bureau Windows 11 !

Attendez quelques minutes afin de voir le Company Portal s’installer automatiquement :

Le client Global Secure Access, est lui aussi installé automatiquement, ouvrant une fenêtre authentification avec possibilité SSO :

Environ 20 minutes plus tard, d’autres applications comme ceux liés à la suite Office, s’installent également de façon automatique :

Prenons en exemple l’installation manuelle de Mozilla Firefox :

L’installation manuelle via le Company Portal ne prend que quelques secondes :

Et l’application Firefox s’ajoute bien dans menu Démarrer de Windows :

Le script configuré en dehors de la Préparation de l’appareil Windows Autopilot (Autopilot v2) s’exécute bien dans le contexte utilisateur :

Enfin côté portail Intune, Microsoft propose également un nouveau rapport afin de surveiller l’état des déploiements Autopilot v2 :

Conclusion

J’espère que cet article vous aura permis de percevoir les avantages et l’intérêt possible de cette nouvelle méthode Autopilot v2. Bien entendu, et comme le rappelle Microsoft, ce nouveau type de déploiement ne pourra pas encore prendre en compte tous les scénarios ou toutes les configurations.

Modifiez la langue de votre VM

Grâces à la Marketplace Azure, il est très facile de trouver son bonheur quand on recherche une image particulière, déjà mise à jour et surtout adaptée au contexte du Cloud. Seulement, certaines personnalisations ultérieures sont souvent nécessaires, comme par exemple : la langue affichée. Certains vous diront que fois basique, mais c’est souvent essentiel pour de nombreux utilisateurs non anglophones.

Ayant récemment travaillé sur un environnement Azure Virtual Desktop aux exigences de langues spécifiques, je souhaitais trouver un moyen simple de changer la langue OS d’une machine virtuelle image template fonctionnant sous Windows 11.

Microsoft préconise cette approche pour AVD :

À compter de Windows 11, les comptes d’utilisateur non-administrateurs peuvent désormais ajouter la langue d’affichage et les fonctionnalités de langue correspondantes. Cette fonctionnalité signifie que vous n’aurez pas besoin de préinstaller des modules linguistiques pour les utilisateurs d’un pool d’hôtes personnel.

Pour les pools d’hôtes mis en pool, nous vous recommandons quand même d’ajouter les langues que vous prévoyez d’ajouter à une image personnalisée. Vous pouvez utiliser les instructions de cet article pour les versions à session unique et à plusieurs sessions de Windows 11 Entreprise.

Microsoft Learn

La méthode proposé par Microsoft pour les environnements Azure Virtual Desktop multisessions semble très convaincante et fera l’objet d’un prochain article sur ce blog.

En parallèle de cette méthode, je souhaitais vous en proposer une autre plus ancienne, mais toujours fonctionnelle, pour une VM Azure Virtual Desktop ou non.

Plein de choses sont d’ailleurs déjà possibles via des GPOs, mais je souhaitais configurer la langue directement dans mon image VM template.

Voici donc les quelques chapitres dans mon article :

Etape 0 – Rappel des prérequis :

Pour réaliser mon test, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Commençons par créer une machine virtuelle sous Windows 11.

Etape I – Création d’une machine virtuelle :

Comme vous pouvez le voir dans la copie d’écran ci-dessous, il n’est pas possible de choisir précisément la langue ou le pack de langues de notre OS :

Comme attendu, l’écran de démarrage est par défaut en anglais :

L’interface utilisateur l’est également :

Allons voir dans Language et région :

Seule la langue Anglais (USA) est disponible pour notre utilisateur administrateur :

Seul le pack Anglais (USA) semble installé :

Cela se confirme par la commande suivante :

Get-InstalledLanguage

Toutes les features et le clavier correspondant semblent déjà installés pour ce pack de langue :

Le pays est là encore défini sur USA, peu importe le région Azure utilisée :

De façon logique, le formatage Anglais (USA) y est également appliqué :

Continuons avec l’administration des paramètres de la langue :

Un clic pour consulter les 3 types de paramétrage :

Que ce soit pour l’utilisateur actuel, l’écran d’accueil ou pour un nouvel utilisateur, tout est configuré en Anglais (USA) :

Maintenant, notre but est donc de modifier la configuration en Anglais vers une configuration Français (Suisse). Pour cela, je me suis inspiré de l’article suivant écrit par Alexandre Verkinderen pour y parvenir.

Etape II – Modification de la langue via script :

Commençons par ouvrir une fenêtre PowerShell ISE :

Vérifions une seconde fois le ou les packs de langue installés par la commande suivante :

Get-InstalledLanguage

Exécuter le script PowerShell suivant en prenant soin de modifier certaines variables :

  • $regionalsettingsURL (ne pas modifier) : méhode automatisée ancienne, mais toujours valable et basée sur un fichier XML de configuration source
  • $RegionalSettings (ne pas modifier) : fichier XML de configuration de destination
  • $Language : modifier au besoin le language (liste)
  • $GeoId : Zone géographique (liste)
  • $TimeZone : Fuseau horaire par défaut (liste)
# Script to define regional settings on Azure Virtual Machines deployed from the market place
# Author: Created by Alexandre Verkinderen, modified by Jean-Loup Orgitello
# Blogpost: https://mscloud.be/configure-regional-settings-and-windows-locales-on-azure-virtual-machines/
#
########################################

#variables
$regionalsettingsURL = "https://raw.githubusercontent.com/jlou07/CHLang/main/CHRegion.xml"
$RegionalSettings = "C:\Region.xml"
$Language = "fr-CH"
$GeoId = "223"
$TimeZone = "W. Europe Standard Time"

#LanguagePack Suisse
Install-Language $Language

#downdload regional settings file
$webclient = New-Object System.Net.WebClient
$webclient.DownloadFile($regionalsettingsURL,$RegionalSettings)

#LanguagePack USA
unInstall-Language "en-US"
Start-sleep -Seconds 120

# Set languages/culture. Not needed perse.
Set-WinSystemLocale $Language
Set-WinUserLanguageList -LanguageList $Language -Force
Set-Culture -CultureInfo $Language
Set-WinHomeLocation -GeoId $GeoId 
Set-TimeZone -id $TimeZone

# Set Locale, language etc. 
& $env:SystemRoot\System32\control.exe "intl.cpl,,/f:`"$RegionalSettings`""

# restart virtual machine to apply regional settings to current user. 
Start-sleep -Seconds 40
Restart-Computer

L’installation d’un pack de langue prend environ 5 minutes :

La suite du script est assez rapide, à l’exception des 2 pauses ajoutées et d’un redémarrage OS :

L’ajout du pack de langue Français (Suisse) entraine également l’ajout du pack de langue Français (France).

Une fois le script terminé, la machine virtuelle redémarre toute seule comme indiqué dans le script :

Il ne nous reste qu’à vérifier l’impact sur notre utilisateur local.

Etape III – Contrôle des changements :

Reconnectez-vous à l’utilisateur après le redémarrage du script :

L’écran de démarrage est maintenant en Français (Suisse):

L’interface utilisateur l’est également :

Allons voir encore une fois dans Langue et région :

Seul le Français (Suisse) est disponible pour notre utilisateur administrateur :

Seul le pack Français (Suisse) semble cette fois installé :

Vérifions une dernière fois le ou les packs de langue installés via le script par la commande PowerShell suivante :

Get-InstalledLanguage

Presque toutes les features et le clavier correspondant semblent correctement installés pour notre pack de langue :

Le pays est maintenant encore défini sur Suisse, comme voulu :

De façon logique, le formatage Suisse est également appliqué :

Continuons avec l’administration des paramètres de la langue :

Un clic pour consulter les 3 types de paramétrage :

Tout est maintenant bien configuré en Français (Suisse) :

Conclusion

Certaines bonnes vieilles méthodes continuent encore de marcher. Dites-moi dans les commentaires si vous appliquez d’autres moyens pour y parvenir 😎

Associez un disque éphémère à votre AVD

Les disques éphémères existent depuis déjà quelques années sur Azure. Mais est-ce qu’un environnement de bureau à distance comme Azure Virtual Desktop associé à ce type de disque est possible ? Si oui, qu’est-ce que cela donne en termes de performances, mais également quelles en seraient les contraintes ?

Qu’est-ce qu’un disque éphémère sur Azure ?

Contrairement aux disques persistants, les disques éphémères sont :

  • temporaires et ne conservent pas les données au-delà du cycle de vie de la machine virtuelle.
  • Ils offrent généralement des performances supérieures aux disques persistants car ils sont directement attachés à l’hôte physique sous-jacent.
  • Ils sont également sujets à la perte de données en cas de panne de la machine virtuelle ou de redémarrage.
  • Leur prix est inclus dans le coût de la taille de la machine virtuelle.
  • Leur taille dépend exclusivement de la taille de la machine virtuelle choisie.
  • Peut se présenter sous deux formes possibles : cache ou disque temporaire (D).

L’excellente vidéo de John Savill vous permettra de bien comprendre le principe des différents disques éphémères sur Azure :

Quels sont les risques à utiliser un disque éphémère ?

Ces disques sont souvent utilisés pour des charges de travail temporaires qui ne nécessitent pas de stockage permanent ou pour des applications qui peuvent reconstruire leurs données en cas de perte.

Il est donc essentiel de sauvegarder les données importantes sur des disques persistants ou d’autres services de stockage Azure si la persistance des données est nécessaire.

Voici 2 pages utiles pour mettre en pratique les disques éphémères :

Comparé à un disque de système d’exploitation standard, un disque éphémère offre une latence plus faible pour les opérations de lecture/écriture et permet une réinitialisation plus rapide des machines virtuelles.

Microsoft Learn

Enfin, Microsoft a mis à disposition la FAQ suivante sur Microsoft Learn.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur Azure Virtual Desktop combiné à plusieurs types de disque :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les disques éphémères intégrés à un Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Préparation de l’environnement AVD :

Avant de pouvoir déployer un environnement Azure Virtual Desktop, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Nommez votre réseau virtuel, puis cliquez sur Vérifier:

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Cliquez-ici pour accéder à votre réseau virtuel :

Dans le menu suivant, cliquez ici pour déployer Azure Bastion :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Choisissez le type Partagé pour l’environnement AVD, puis cliquez sur Suivant :

Choisissez une image OS sous Windows 11 :

Sélectionnez la taille de VM suivante ainsi que le disque OS en Premium SSD :

Note : comme vous pouvez le voir, il n’est pas possible depuis l’interface actuelle d’AVD d’y spécifier un disque OS éphémère.

Joignez votre VM à Microsoft Entra ID, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :

Une fois le déploiement d’Azure Virtual Desktop terminé, cliquez-ici :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Cliquez sur le nombre de machines AVD hôtes :

Cliquez sur le premier hôte AVD :

Cliquez sur la machine virtuelle AVD correspondante :

Vérifiez la présence d’un disque OS managé Premium SSD, puis cliquez-dessus :

Vérifiez les caractéristiques du disque :

Notre environnement Azure Virtual Desktop est maintenant en place. Nous devons maintenant rajouter 2 machines virtuelles supplémentaires pour comparer les performances des disques :

  • Création d’une VM AVD avec un disque éphémère cache
  • Création d’une VM AVD avec un disque éphémère temporaire

Commençons par la machine virtuelle dont le disque OS sera sur le cache.

Etape II – Création d’une VM AVD avec un disque éphémère CACHE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre seconde machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v3 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le cache, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre seconde VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre seconde machine virtuelle :

Vérifiez également la jointure à Entra ID depuis la session Bastion et grâce à la commande suivante :

dsregcmd /status

Quelques secondes plus tard, le statut de votre seconde VM passe en disponible :

Continuons avec la création de la troisième VM dont le disque OS sera sur la partition temporaire.

Etape III – Création d’une VM AVD avec un disque éphémère TEMPORAIRE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre troisième machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v5 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le temporaire, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre troisième VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre troisième machine virtuelle :

Quelques secondes plus tard, le statut de votre troisième VM passe en disponible :

Nos 3 machines virtuelles sont maintenant opérationnelles. Pourtant nous ne voyons qu’un seul disque en tant que ressource Azure :

Pourtant le disque OS est bien présent sur la seconde VM :

Le disque OS est également bien présent sur la troisième VM, dont les IOPS sont très très élevés :

Pour nous y connecter avec des utilisateurs AVD, nous devons maintenant rajouter des droits à des utilisateurs de test sur celles-ci.

Etape IV – Connexions aux VMs de l’environnement AVD :

Sur ce même groupe de ressources, ajoutez les deux rôles Azure RBAC suivants pour vos utilisateurs de test :

Ouvrez ensuite le client Remote Desktop puis authentifiez-vous avec 3 utilisateurs différents :

Ouvrez ensuite 3 sessions AVD de telle façon à ce que chacun se retrouve seul sur une VM :

Sur chacune des 3 sessions AVD :

  • Ouvrez le gestionnaire des disques afin de constater les différentes tailles des partitions.
  • Téléchargez l’exécutable DiskSpd via ce lien Microsoft, puis décompressez l’archive ZIP à la racine du disque C.
  • Lancez le moniteur de ressources Windows.
  • Ouvrez une fenêtre PowerShell en mode administrateur, puis exécutez les 2 scripts de tests suivants :
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L C:\diskpsdtmp.dat > IOPS.txt
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L C:\diskpsdtmp.dat > Throughput.txt

Machine virtuelle AVD avec disque OS Premium SSD :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien de 300 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS CACHE :

Voici un tableau affichant les informations de la VM D8s v3 :

Le disque temporaire est bien de 64 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS TEMPORAIRE :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien la soustraction de 300 Go – 128 Go, soit environ 172 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Voyons ensemble les différentes de performances des 3 machines virtuelles AVD.

Etape V – Synthèse des résultats :

Pour plus de clarté, j’ai synthétisé tous mes résultats IOPS dans le tableau ci-dessous :

j’ai également synthétisé tous mes résultats Throughput dans le tableau ci-dessous :

Conclusion

Il n’y a rien à dire, l’écart de performances entre ces 3 types de disque est très impressionnant ! Et cet écart se creuse encore plus si on change la taille de la machine virtuelle TEMP en D16ds v5 :

De plus, j’ai utilisé le Calculateur Azure afin de comparer les prix des 3 types de disque selon les performances relevées plus haut :

Enfin, Microsoft nous rappelle certaines contraintes liées à l’utilisation de disque OS éphémères :

  • Un redimensionnement de la machine virtuelle avec un disque éphémère fera perdre toute la donnée modifiée :
  • Il n’est pas possible de désallouer les ressources machines quand un disque éphémère est utilisé :
  • Il n’est pas possible de sauvegarder une machine virtuelle quand un disque OS éphémère est utilisé :

En somme, ces points ne devraient pas être des blocages pour des environnements Azure Virtual Desktop dans la mesure où ces derniers, généralement, ne stockent pas d’informations utilisateurs et sont constitués à partir d’une golden image 😎🙏.

Azure Virtual Desktop sur Azure Stack HCI

Bonne nouvelle ! Azure Stack HCI 23H2 est maintenant disponible en GA. La 23H2 simplifie grandement la configuration et le déploiement des clusters HCI. Autre bonne nouvelle, AVD est aussi en GA sur Azure Stack HCI ! Si tester Azure Virtual Desktop via une solution cloud hybride et sans acheter quoi que ce soit vous intéresse, cet article est fait pour vous !

Un premier article avait déjà été écrit sur ce blog à propos d’Azure Stack HCI. La solution proposée par Microsoft vous permet de disposer d’une infrastructure hyperconvergée basée sur les technologies Azure :

Peut-on tester Azure Stack HCI sans investir dans du matériel physique ?

La réponse est oui grâce à Azure Arc Jumpstart ! Vous pouvez recréer un cluster Azure Stack HCI directement dans Azure. L’article précédemment écrit proposait la même approche, mais Jumpstart simplifie grandement le processus.

Qu’est-ce qu’Azure Arc Jumpstart ?

Il s’agit de solutions de type bac à sable proposées par Microsoft :

L’univers de l’Arc Jumpstart. Vous souhaitez explorer plusieurs environnements et découvrir toute l’étendue de Jumpstart ? Obtenez des scénarios automatisés de zéro à héros pour les serveurs compatibles avec Arc, Kubernetes compatible avec Arc, et plus encore. Parcourez les scénarios. Explorez des scénarios du cloud à la périphérie conçus pour répondre à des besoins sectoriels spécifiques.

Azure Arc Jumpstart

Comme le montre la page suivante, beaucoup de scénarios y sont proposés :

Mais qu’est-ce qu’HCIBox ?

En quelques mots : il vous permet d’essayer Azure Stack HCI directement dans Azure :

HCIBox est une solution clé en main qui fournit un bac à sable complet pour explorer les capacités d’Azure Stack HCI et l’intégration du cloud hybride dans un environnement virtualisé. HCIBox est conçu pour être complètement autonome au sein d’un seul abonnement Azure et d’un seul groupe de ressources, ce qui permettra à un utilisateur de se familiariser facilement avec Azure Stack HCI et la technologie Azure Arc sans avoir besoin de matériel physique.

Azure Arc Jumpstart

Combien coûte le service HCIBox ?

Les ressources HCIBox entraînent des frais de consommation Azure, qui dépendent des ressources Azure sous-jacentes telles que le calcul central, le stockage, le réseau.

Voici une idée de ce que peut représenter une HCIBox fonctionnant en 24/7 pendant 31 jours et hébergée en Suisse :

Enfin, une FAQ de la HCIBox est disponible juste ici.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice Azure Virtual Desktop fonctionnant grâce à un Azure Stack HCI construit dans une HCIBox elle-même hébergée sur Azure :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Préparation de l’environnement Azure :

Afin de pouvoir déployer les ressources Azure liées à la HCIBox, il est nécessaire d’avoir un quota CPU suffisant pour une famille particulière de machines virtuelles.

Pour cela, ouvrez votre souscription Azure, puis rendez-vous sur le menu suivant afin de vérifier que le quota de la famille ESv5 est au minimum de 32 cœurs :