Azure VPN Gateway est un service plébiscité pour sa sécurité, sa redondance et la simplicité de son intégration native dans Microsoft Azure. Cependant, pour des projets de plus petite envergure ou lorsque vous disposez déjà de compétences réseau et d’infrastructures maîtrisées, il peut être judicieux d’explorer des solutions open source ou des distributions spécialisées. C’est dans cette optique que nous verrons comment déployer un VPN OPNsense sur Azure.
Comment fonctionne un tunnel IPsec ?
Les tunnels IPsec se mettent en place en deux grandes étapes :
Phase 1 – IKE (Internet Key Exchange)
Les deux extrémités (pair A et pair B) négocient d’abord une association de sécurité IKE SA.
Elles s’authentifient mutuellement (certificat, clé pré-partagée, etc.) et conviennent des paramètres de chiffrement (algorithme, mode DH, durée de vie des clés).
À l’issue, un canal chiffré et authentifié est établi pour protéger les échanges de la phase 2.
Phase 2 – IPsec SA
Dans ce canal sécurisé, les pairs négocient plusieurs Security Associations secondaires (appelées Child SA), qui définiront le chiffrement et l’intégrité du trafic utilisateur.
Elles conviennent des sous-réseaux à protéger, des ports et protocoles autorisés, puis génèrent les clés de session IPsec.
Une fois la Child SA montée, le tunnel est opérationnel : tout paquet envoyé vers le sous-réseau distant est chiffré et encapsulé dans IPsec.
Qu’est-ce qu’une passerelle VPN Azure ?
Une passerelle VPN Azure (Azure VPN Gateway) agit comme un point de terminaison chiffré permettant d’établir des tunnels IPsec/IKE entre votre réseau on-premises (ou vos clients VPN individuels) et vos réseaux virtuels Azure.
Elle prend en charge plusieurs scénarios :
Site-à-Site (connexion permanente entre votre datacenter et Azure)
Point-à-Site (accès distant des utilisateurs)
VNet-à-VNet (liaison sécurisée entre réseaux virtuels)
Quels sont les SKUs disponibles pour les passerelles VPN Azure ?
Les passerelles VPN Azure se déclinent en versions classiques et zone-redondantes :
Génération
SKU
Tunnels S2S/VNet-to-VNet
Connexions P2S (IKEv2/OpenVPN)
Débit agrégé
BGP supporté
Zone-redondant
Gen 1
Basic
Max. 10
Non supporté
100 Mbps
Non
Non
VpnGw1
Max. 30
Max. 250
650 Mbps
Oui
Non
VpnGw2
Max. 30
Max. 500
1 Gbps
Oui
Non
VpnGw3
Max. 30
Max. 1000
1,25 Gbps
Oui
Non
VpnGw1AZ
Max. 30
Max. 250
650 Mbps
Oui
Oui
VpnGw2AZ
Max. 30
Max. 500
1 Gbps
Oui
Oui
VpnGw3AZ
Max. 30
Max. 1000
1,25 Gbps
Oui
Oui
Gen 2
VpnGw2
Max. 30
Max. 500
1,25 Gbps
Oui
Non
VpnGw3
Max. 30
Max. 1000
2,5 Gbps
Oui
Non
VpnGw4
Max. 100*
Max. 5000
5 Gbps
Oui
Non
VpnGw5
Max. 100*
Max. 10000
10 Gbps
Oui
Non
VpnGw2AZ
Max. 30
Max. 500
1,25 Gbps
Oui
Oui
VpnGw3AZ
Max. 30
Max. 1000
2,5 Gbps
Oui
Oui
VpnGw4AZ
Max. 100*
Max. 5000
5 Gbps
Oui
Oui
VpnGw5AZ
Max. 100*
Max. 10000
10 Gbps
Oui
Oui
Combien coûte les passerelles VPN Azure ?
Le prix de la passerelle VPN dépend du SKU choisi. Voici quelques tarifs :
SKU
Prix mensuel estimé (€)
Basic
22,95 €
VpnGw1
121,11 €
VpnGw2
312,33 €
VpnGw3
796,77 €
VpnGw4
1 338,57 €
VpnGw5
2 326,56 €
Attention : ces prix correspondent uniquement au coût de compute de la passerelle (744 heures d’utilisation par mois) et n’incluent pas les frais de transfert de données sortantes.
L’ancien VPN de type basique présentait un tarif particulièrement attractif :
Le service le moins cher est maintenant le SKU VpnGw1, mais le prix est plus élevé :
En comparaison, le service OPNsense déployé via une VM affiche un coût un plus faible :
Voici également le tarif appliqué pour le VPN OPNsense pour un engagement d’un an sur la machine virtuelle :
Qu’est-ce que la passerelle VPN OPNsense sur Azure ?
OPNsense VPN est la solution de création de tunnels sécurisés intégrée à OPNsense, un pare-feu/routeur open-source basé sur FreeBSD. Elle prend en charge plusieurs protocoles majeurs :
IPsec : idéal pour les liaisons site-à-site ou les connexions distantes, avec négociation IKEv1/IKEv2, clés pré-partagées ou certificats, et prise en charge de BGP pour le routage dynamique.
OpenVPN : pour les accès distants sur TCP ou UDP, avec authentification par utilisateur, certificats ou serveur RADIUS, et options de chiffrement AES-GCM.
WireGuard : un protocole moderne, léger et performant, offrant des temps de mise en place réduits et une empreinte cryptographique simplifiée.
Peut-on déployer la passerelle VPN OPNsense sur Azure ?
Oui, il est tout à fait possible de déployer OPNsense dans Azure en tant que machine virtuelle. Afin de voir si cela marche vraiment, voici les différentes étapes que nous allons suivre sur un environnement de test :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Pour tester mon environnement, j’ai également provisionné les deux machines virtuelles suivantes pour simuler des ressources opposées :
J’y ai également mis en place une passerelle Bastion :
Enfin, j’ai également déployé une passerelle VPN Azure pour tester le tunnel :
Commençons par créer une nouvelle machine virtuelle Azure contenant la passerelle VPN OPNsense.
Etape I – Préparation de la machine virtuelle OPNsense :
Pour cela, cliquez sur le lien GitHub suivant pour déployer le template ARM sur votre environnement Azure : https://github.com/dmauser/opnazure
Sélectionnez ensuite le scénario OPNsense souhaité et renseignez les informations de base, puis cliquez sur Suivant :
Conservez ou ajustez la taille de la VM, puis validez en cliquant Suivant :
Constatez la présence de deux sous-réseaux, Trusted et Untrusted, puis lancez la validation Azure :
Une fois la validation réussie, le déploiement des ressources démarre automatiquement :
Patientez quelques minutes, puis cliquez ici pour accéder aux ressources créées :
Copiez les adresses IP privées et publiques de la VM OPNsense :
Modifiez la règle de pare-feu pour autoriser l’accès HTTPS à la VM :
Vérifiez la présence du sous-réseau Trusted, puis copiez son plan d’adressage :
Connectons-nous maintenant à notre console d’administration OPNsense pour avancer sur la configuration de notre tunnel.
Etape II – Configuration d’OPNsense :
Ouvrez votre navigateur, collez-y l’IP publique de la VM OPNsense, renseignez les identifiants ci-dessous, puis cliquez sur Login :
Login : root
Mot de passe : opnsense
Changez immédiatement le mot de passe pour des raisons de sécurité :
Commencez par créer une clé partagée destinée au handshake IPsec :
Dans la section VPN IPsec, cliquez-ici pour créer une nouvelle connexion et choisissez vos propositions de chiffrement :
Renseignez les champs requis : l’IP locale de la VM OPNsense et l’adresse IP publique de la passerelle VPN Azure :
Ajoutez une authentification locale en réutilisant la clé partagée, puis enregistrez :
Répétez l’opération pour l’authentification distante, puis sauvegardez :
Éditez ensuite la section Child en renseignant les plans d’adressage respectifs, puis cliquez sur Enregistrer :
Cliquez sur Sauvegarder :
Enfin, cliquez sur Appliquer pour finaliser la configuration IPsec :
Dans la section pare-feu, constatez la règle sortante déjà préconfigurée :
Créez une nouvelle règle entrante pour autoriser l’accès depuis la passerelle VPN Azure :
Activez cette nouvelle règle pare-feu :
Sur le pare-feu OPNsense, ajoutez les règles nécessaires pour établir la liaison IPsec dans la section WAN :
La configuration OPNsense est maintenant terminée. La prochaine étape consiste à configurer la passerelle VPN Azure pour se connecter à la première.
Etape III – Configuration de la passerelle VPN Azure :
Copiez l’adresse IP publique de la passerelle VPN Azure :
Dans le Network Security Group de votre VM OPNsense, créez une règle pour autoriser l’IP de la passerelle VPN Azure :
Créez une Local Network Gateway en renseignant l’IP publique de votre passerelle VPN OPNsense et le plan d’adressage du sous-réseau Trusted :
Établissez ensuite la connexion VPN Azure pour finaliser l’interconnexion entre les deux passerelles :
Collez la clé d’authentification, puis enregistrez la configuration de la connexion :
Associez également une table de routage au sous-réseau Trusted, en y incluant le préfixe 0.0.0.0/0 afin de diriger tout le trafic via la VM OPNsense :
Tout est maintenant en place pour le test de connectivité entre nos deux machines virtuelles.
Etape IV – Test de la connexion VPN :
Retournez dans le menu des connexions IPsec OPNsense, puis cliquez ici pour démarrer la connexion IPsec côté OPNsense :
Attendez quelques secondes jusqu’à l’apparition de la Phase 2 de la connexion IPsec :
Une fois la Phase 2 affichée, cliquez ici pour visualiser le journal contenant les événements IPsec :
Constatez l’apparition des différents états de la connexion entre les deux passerelles VPN :
Vérifiez l’apparition de Security Associations dans la base de données IPsec :
Vérifiez l’apparition de Security Policies dans la base de données IPsec :
Retournez sur le portail Azure et observez le changement de statut de la connexion VPN Azure :
Démarrez les deux machines virtuelles de test pour valider la liaison :
Sur les deux VM de test, désactivez temporairement la règle de pare-feu ICMP suivante pour autoriser le ping :
Effectuez des tests de ping réciproques entre les deux machines virtuelles :
Interrompez la connexion depuis OPNsense :
Constatez la disparition de la Phase 2 dans la console OPNsense :
Vérifiez également l’échec du ping entre les deux VM :
Relancez la connexion IPsec depuis OPNsense et observez la réapparition de la Phase 2 :
Confirmez la reprise du ping sur les deux machines virtuelles de test :
Conclusion
Si Azure VPN Gateway reste la solution de référence pour une interconnexion cloud sécurisée et redondante, l’utilisation d’une VM OPNsense sur Azure offre une alternative open source particulièrement adaptée aux petits projets ou aux environnements où vous souhaitez tirer parti de vos compétences réseau existantes.
Vous gagnez en flexibilité de configuration, en contrôle détaillé des politiques VPN et en possibilité d’étendre facilement vers d’autres protocoles (OpenVPN, WireGuard).
Cette approche hybride combine la robustesse du cloud Azure et la puissance d’OPNsense pour bâtir un VPN sur mesure parfaitement aligné avec vos besoins.
Depuis déjà plusieurs années, l’augmentation croissante des menaces, qu’il s’agisse de rançongiciels, de pannes matérielles ou d’erreurs humaines, impose de repenser ses stratégies de sauvegarde dans le cloud. Plutôt que de gérer soi-même un compte de stockage Azure, Veeam Data Cloud Vault se présente comme un coffre 100 % managé, conçu pour simplifier et fiabiliser vos sauvegardes tout en respectant la règle 3-2-1-1-0.
Un premier article parlant de la sauvegarde des données 365 via la solution Veeam Data Cloud SaaS Backup est disponible juste ici.
Dans cet article, je vous guide pas à pas pour déployer votre coffre Veeam depuis Azure Marketplace, l’intégrer à Veeam Backup & Replication et tirer pleinement parti de ses fonctionnalités avancées.
Qu’est-ce que le concept 3-2-1 pour les sauvegardes ?
Le concept de la règle 3-2-1 a été formalisé par le photographe numérique Peter Krogh, et publié pour la première fois en 2005 dans son ouvrage The DAM Book: Digital Asset Management for Photographers
Il s’agit d’une règle simple et éprouvée pour garantir la sécurité et la résilience de vos sauvegardes :
3 copies des données
1 copie « live » : vos données actives sur le système de production
2 copies de sauvegarde : répliquées ailleurs, pour pouvoir restaurer en cas de défaillance ou de corruption
2 types de supports différents
Par exemple :
Un disque dur interne ou réseau (NAS)
Un autre support : bande LTO, SSD externe, ou stockage objet cloud
L’idée est de réduire le risque de défaillance matérielle simultanée : un même lot de disques peut tomber en panne, mais un disque dur + une bande ou un système cloud présentent des modes de panne différents.
1 copie hors site
Pour vous prémunir contre :
Vol, incendie ou inondation de votre site principal
Corruption logicielle ou rançongiciel (ransomware) qui toucherait tout votre réseau
Cette copie peut être :
Hébergée dans un cloud public (Azure Blob Storage, Amazon S3, etc.)
Stockée physiquement dans un autre bureau ou un coffre-fort externe
Répliquée chez un prestataire spécialisé
Et pourquoi parle-t-on maintenant de 3-2-1-1-0 ?
Le concept 3-2-1-1-0 est une évolution de la règle 3-2-1, pensée pour les menaces modernes (ransomware, erreurs de sauvegarde, etc.). Il rajoute ainsi :
1 copie hors ligne ou immuable (air-gapped/immutable). Cette copie n’est pas connectée au réseau (ou est protégée en écriture seule), de manière à rester intacte même en cas de ransomware ciblant vos systèmes connectés.
0 erreur de sauvegarde. Il faut vérifier régulièrement que chaque sauvegarde se termine sans erreur, et tester la restauration pour garantir l’intégrité et la disponibilité de vos données en cas de besoin.
Qu’est-ce que Veeam Data Cloud vault ?
Veeam Data Cloud Vault est un service de stockage cloud sécurisé, pré-configuré et entièrement géré par Veeam sur l’infrastructure Microsoft Azure. Voici une courte vidéo qui vous montre ce service :
Pourquoi passer par Veeam Data Cloud Vault à la place de créer directement un compte de stockage Azure ?
La configuration faite directement par Veeam est le premier avantage à passer par le service Veeam Data Cloud Vault : vous indiquez simplement votre volume de données à sauvegarder, et tout est provisionné sans aucun paramétrage Azure de votre part.
Voici ce que Veeam fait automatiquement pour vous :
Immutabilité et isolation « Zero Trust » intégrées Veeam Data Cloud Vault repose sur des mécanismes d’immutabilité natifs : chaque objet écrit devient en lecture seule pour la durée configurée, empêchant toute suppression ou modification accidentelle ou malveillante (ransomware). Cette couche d’isolation logique (air-gapped, c’est-à-dire isolée du réseau) est activée par défaut et n’existe pas automatiquement sur un compte de stockage classique sans configuration manuelle
Sécurité et chiffrement bout en bout Les transferts entre Veeam Backup & Replication et le Vault se font sur des canaux chiffrés via un certificat mutualisé, sans jamais exposer de clés ou de tokens. De plus, toutes les données sont stockées chiffrées au repos, sans configuration supplémentaire. Un compte de stockage classique exige la mise en place manuelle du chiffrement (Azure Storage Service Encryption) et la gestion des clés (Key Vault)
Conformité à la stratégie 3-2-1-1-0 Le Vault répond directement aux exigences :
1 copie hors site : vos backups sont sur l’infrastructure Veeam dans Azure.
1 copie immuable/air-gapped : garantie par la politique d’immutabilité native.
0 erreur : Veeam supervise automatiquement la réussite de chaque sauvegarde et vous alerte en cas de problème.
Un compte de stockage classique n’offre pas cette orchestration automatisée autour de la vérification d’intégrité et de l’immutabilité.
Combien coûte Veeam Data Cloud Vault ?
La partie des coûts proposée par Veeam s’avère intéressante. Contrairement au modèle « pay-as-you-go » (à l’usage) habituellement appliqué à un compte de stockage Azure, Veeam Data Cloud Vault propose un tarif forfaitaire par To incluant le stockage, les appels API, l’egress et les restaurations : plus de risque de « bill shock » lié aux opérations ou au trafic.
Deux SKUs sont proposés par Veeam : Foundation et Advanced :
Foundation débute à 14 USD / To / mois (facturé annuellement).
Advanced est à 24 USD / TB / mois, mais inclut un nombre illimité d’opérations de lecture/restauration.
On peut différencier ces deux offres de la façon suivante :
Granularité de l’emplacement
Foundation vous permet de choisir le pays où vos données seront stockées, Veeam/Microsoft sélectionnant ensuite la région exacte.
Advanced vous donne la main sur la région Azure précise (par exemple « West Europe » vs « North Europe ») pour optimiser latence, conformité ou réplication inter-zones.
Durabilité
Foundation s’appuie sur LRS (Locally Redundant Storage), garantissant « 11 nines » de durabilité (99,999999999 %).
Advanced utilise ZRS (Zone-Redundant Storage), offrant « 12 nines » (99,9999999999 %) en répartissant les données sur plusieurs zones de disponibilité.
Limites de lecture/restauration
Foundation applique une politique de fair use sur les appels de lecture et les restaurations.
Advanced propose des lectures et restaurations illimitées sans restrictions supplémentaires.
Qu’est-ce que contient le Fair Use de Veeam ?
La politique Fair Use de Veeam Data Cloud Vault définit une franchise gratuite d’opérations de lecture/restauration incluse dans votre abonnement, afin d’assurer une utilisation raisonnable et équitable des ressources :
Foundation Edition : Restauration ou récupération de données jusqu’à 20 % de la capacité totale souscrite sur une période d’un an, sans surcoût.
Advanced Edition : Restauration ou récupération de données jusqu’à 100 % de votre capacité activement consommée chaque année, sans surcoût.
Au-delà de ces seuils, les opérations de lecture, de récupération et l’egress sont facturés aux tarifs standards Microsoft applicables à la région concernée.
Quelles régions Azure supportentVeeam Data Cloud Vault ?
Voici les régions Azure prises en charge par Veeam Data Cloud Vault :
L’édition Advanced n’est pas disponible dans ces régions en raison de l’absence de support ZRS par Azure.
Comment tester Veeam Data Cloud Vault ?
De nombreuses vidéos sont déjà disponibles sur la chaîne YouTube de Veeam :
Voici les différentes étapes que nous allons suivre afin de tester la solution Veeam Data Cloud Vault sur un environnement de test :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de réaliser nos tests sur Veeam Data Cloud Vault, nous allons avoir besoin de :
Un tenant Microsoft actif
Une souscription Azure valide
Commençons par déployer la solution depuis Azure Marketplace.
Etape I – Déploiement de Veeam Data Cloud Vault :
Depuis le portail Azure, recherchez Veeam Data Cloud Vault :
Déployez la solution SaaS dans la souscription, le groupe de ressources et la nom de votre ressource :
Ouvrez la liste des plans disponibles :
Changez votre plan si nécessaire :
Lancez la validation Azure :
Une fois la validation réussie, lancez la création de la solution :
Attendez quelques minutes le temps de la configuration de Veeam Data Cloud Vault :
Une fois la configuration terminée, cliquez sur le bouton de finalisation :
Vérifiez les informations affichées, puis cliquez-ici pour activer la souscription. Selon ma compréhension, l’activation de celle-ci déclenche la facturation sur votre souscription Azure. Vous disposez alors de 72 heures pour vous rétracter une fois celle-ci activée :
Une fois la souscription Veeam activée, cliquez-ici pour basculer sur la console de gestion Veeam Data Cloud Vault :
Choisissez une authentification via Entra ID :
Veeam vous propose de créer votre premier coffre, vérifiez les informations puis cliquez sur Suivant :
Etant parti sur le plan Foundation, choisissez le Pays et non la région Azure, puis cliquez sur Suivant :
Attendez quelques minutes le temps du provisionnement et de la configuration des ressources gérées par Veeam :
Quelques minutes plus tard, le coffre Veeam est créé, copiez les informations suivantes afin de configurer votre application Veeam Backup :
Cliquez sur Suivant afin de terminer la configuration :
La fin de la configuration vous transporte sur le tableau de bord de Veeam Data Cloud Vault :
Du côté d’Azure, vous pouvez constater la ressource SaaS dans le groupe de ressources ; cliquez dessus pour retrouver le détail de la solution :
Un clic sur le lien de cette solution vous permet d’ouvrir l’URL d’accueil de Veeam Data Cloud Vault :
Un autre clic sur le lien ci-dessous vous ouvre votre propre instance de Veeam Data Cloud Vault :
Consultez ou créez au besoin vos coffres sur cette page :
Visualisez les souscriptions Azure sur cet écran :
Le volume de stockage est visible depuis ce même portail après un rafraîchissement de l’information :
L’information est visible sur ce portail après une ou plusieurs heures :
Les informations du volume total de stockage sont alors actualisées sur le tableau de bord principal :
Notre solution Veeam Data Cloud Vault est maintenant configurée et prête à recevoir des données. La prochaine étape consiste à configurer cette dernière depuis un outil de sauvegarde, comme Veeam Backup & Replication.
Etape II – Ajout d’un coffre Veeam :
J’ai créé une machine virtuelle depuis le Marketplace Azure la solution Veeam Backup & Replication pour réaliser les tests.
Une fois la console de gestion de Veeam Backup & Replication ouverte, ouvrez la configuration de l’infrastructure de sauvegarde :
Cliquez sur le type Veeam Data Cloud Vault :
Nommez celui-ci, cochez la case, puis cliquez sur Suivant :
Cliquez sur Ajouter, puis choisissez la connexion avec la clef du coffre :
Collez les informations précédemment copiées du coffre Veeam, puis cliquez sur OK :
Cliquez sur Suivant :
Renseignez un nouveau dossier créé sur le coffre, puis cliquez sur Suivant :
Définissez les informations du stockage local pour les restaurations rapides, puis cliquez sur Suivant :
Cliquez sur Appliquer :
Attendez quelques secondes la mise en place de la configuration, puis cliquez sur Suivant :
Une fois la configuration réussie, cliquez sur Terminer :
Constatez l’apparition du coffre dans la liste des répertoires de Sauvegarde :
Notre coffre Veeam est maintenant un répertoire de sauvegarde. Nous allons maintenant modifier une première police consacrée à la sauvegarde d’un partage de fichiers.
Etape III – Sauvegarde d’un partage de fichier sur le coffre Veeam :
Pour cela, retournez dans les travaux de sauvegarde déjà en place, puis cliquez sur l’un d’entre eux afin de le modifier :
Cochez la case suivante afin de configurer le coffre Veeam comme seconde destination de sauvegarde :
Cliquez sur Avancé :
Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :
Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :
Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :
Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement :
Une fois le premier travail de sauvegarde terminé, constatez le démarrage automatique du second travail de sauvegarde dédié au coffre Veeam :
Constatez l’apparition de sauvegarde du partage de fichiers et du nombre de points de restauration disponibles :
Retournez sur les répertoires de sauvegarde afin de visualiser la consommation d’espace sur votre coffre Veeam :
Testons maintenant la même approche de réplication de sauvegarde pour un stockage objet.
Etape IV – Sauvegarde d’objets sur le coffre Veeam :
Retournez à nouveau dans les travaux de sauvegarde objet déjà en place, puis cliquez sur l’un d’entre eux afin d’ajouter comme seconde destination de sauvegarde le coffre Veeam.
Cliquez sur Avancé :
Cochez la case suivante, configurez un mot de passe, puis cliquez sur OK :
Ajoutez en seconde cible le coffre Veeam, puis cliquez termine la modification de la police de sauvegarde :
Constatez l’apparition d’un second travail de sauvegarde, dont le déclenchement dépendra du premier auquel il est rattaché :
Lancez le premier travail de sauvegarde afin de tester le bon fonctionnement, puis constatez l’apparition de sauvegardes de fichiers objets :
Retournez sur les répertoire de sauvegarde afin de visualiser l’augmentation de la consommation d’espace sur votre coffre Veeam :
Terminons notre test par la restauration d’un fichier objet supprimé dans un conteneur Azure, dont la sauvegarde est répliquée sur le coffre Veeam.
Etape V – Restauration d’un fichier objet :
Supprimez un fichier sur un stockage objet :
Depuis Veeam Backup & Replication, retournez sur les points de sauvegarde associés au coffre Veeam, puis lancez la restauration d’un fichier objet :
Attendez quelques secondes le chargement des points restauration disponibles :
Cliquez sur le fichier supprimé à restaurer, puis déclenchez la restauration par écrasement :
Attendez quelques secondes le déclenchement du travail de restauration :
Attendez quelques minutes la fin du travail de restauration :
Constatez la réapparition du fichier sur le stockage objet :
Conclusion
En adoptant Veeam Data Cloud Vault sur Azure, vous déléguez la complexité opérationnelle et garantissez une protection de vos données conforme à la règle 3-2-1-1-0 :
Déploiement en un clic : plus besoin de scripts ni d’ARM templates.
Sécurité renforcée : immutabilité native et chiffrement bout-en-bout activés par défaut.
Surveillance proactive : Veeam supervise vos jobs et vous alerte immédiatement en cas d’anomalie.
Prévisibilité budgétaire : un tarif fixe par To incluant toutes les opérations et l’egress, sans surprises.
Que vous choisissiez l’édition Foundation ou Advanced, Veeam vous offre une solution SaaS prête à l’emploi, alliant performance, sécurité et tranquillité d’esprit 😎
Dans un contexte où la migration vers le cloud s’accompagne souvent de contraintes d’adressage et de sécurité, le NAT peut être vu comme une solution pouvant résoudre les problématiques de chevauchement d’adresses et de confidentialité. Vraiment ?
Attention ! Recourir au NAT pour masquer des conflits d’adresses n’est pas toujours une approche saine à long terme, car cela peut introduire une complexité opérationnelle accrue et des difficultés de maintenance ; il doit donc être considéré comme une solution transitoire ou de contournement.
Qu’est-ce que le NAT ?
Le NAT ( ou Network Address Translation) est un mécanisme qui permet de faire correspondre des adresses IP privées (non routables sur Internet) à une ou plusieurs adresses IP publiques (routables). Il joue un rôle clé dans la conservation des adresses IPv4 et dans la sécurisation des réseaux privés.
Voici une courte vidéo qui explique le principe du NAT afin de pallier le souci d’adresses IPv4 pour Internet :
Comment fonctionne le NAT ?
Lorsqu’une machine interne (par exemple 10.0.0.1) envoie une requête vers Internet (par exemple 200.100.10.1), le routeur NAT remplace son adresse source privée par une adresse publique (par exemple 150.150.0.1), et stocke dans sa table de traduction la corrélation :
Le routage du trafic impacte alors le traffic de données dans les deux sens :
Sortant : le paquet quitte le réseau interne avec l’adresse publique.
Entrant : la réponse revient à l’adresse publique, le routeur NAT consulte sa table et renvoie le paquet à la machine interne d’origine.
Quels sont ses avantages et ses limites au NAT ?
Avantages
Économie d’adresses IPv4
Masquage du réseau interne (sécurité renforcée)
Contrôle centralisé du trafic sortant/entrant
Limites
Complexité de dépannage (tables de traduction)
Certains protocoles (FTP actif, SIP, etc.) nécessitent des algorithmes NAT-aware ou des « NAT helpers »
Impact potentiel sur la latence et le débit
SNAT vs DNAT ?
En pratique, le NAT (Network Address Translation) se décline en deux grands modes :
Mode
Abréviation
Fonction principale
Exemple d’usage
Source NAT
SNAT (Source NAT)
Modifier l’adresse source et/ou le port d’une connexion sortante
Votre VM privée (10.0.0.5) → Internet apparaît avec l’IP publique du NAT Gateway
Destination NAT
DNAT (Destination NAT)
Modifier l’adresse de destination et/ou le port d’une connexion entrante
Internet (51.210.34.12:80) → redirigé vers votre VM privée (10.0.0.5:8080)
Règles de NAT sortantes : permettent de présenter votre réseau virtuel Azure à vos sites distants avec un plan d’adressage spécifique.
Règles de NAT entrantes : permettent à vos sites distants d’accéder au réseau virtuel Azure en utilisant un plan d’adressage différent.
Et le NAT dans Azure c’est possible ?
Un premier service, appelé Azure NAT Gateway, est conçu pour offrir un moyen simple, fiable et évolutif de gérer le trafic sortant depuis vos réseaux virtuels vers Internet ou d’autres services Azure, sans exposer vos machines virtuelles (VM) directement avec des adresses IP publiques :
Une passerelle NAT Azure est un service de traduction d’adresses réseau entièrement managé et hautement résilient. Vous pouvez utiliser Azure NAT Gateway pour autoriser toutes les instances d’un sous-réseau privé à se connecter à Internet, tout en restant entièrement privées. Les connexions entrantes non sollicitées depuis Internet ne sont pas autorisées via une passerelle NAT. Seuls les paquets arrivant en tant que paquets de réponse à une connexion sortante peuvent passer via une passerelle NAT.
Peut-on donc avoir un chevauchement d’adresses entre le LAN et un réseau virtuel Azure ?
La réponse est oui :
Les organisations utilisent fréquemment des adresses IP privées définies dans le document RFC1918 pour la communication interne dans leurs réseaux privés. Quand ces réseaux sont connectés à l’aide d’un VPN via Internet ou à l’aide d’un WAN privé, les espaces d’adressage ne doivent pas se chevaucher.
Si c’est le cas, la communication échoue. Pour connecter deux réseaux ou plus avec des adresses IP qui se chevauchent, le NAT est déployé sur les appareils de passerelle qui connectent les réseaux.
Voici un exemple d’architecture entre plusieurs sites appliquant différentes règles NAT :
Attention, Microsoft liste ici les contraintes pour la fonctionnalité NAT d’Azure VPN Gateway :
NAT est pris en charge sur les références (SKU) suivantes : VpnGw2~5, VpnGw2AZ~5AZ.
NAT est pris en charge pour les connexions intersites IPsec/IKE uniquement. Les connexions de réseau virtuel à réseau virtuel et les connexions P2S (point à site) ne sont pas prises en charge.
Les règles NAT ne sont pas prises en charge sur des connexions pour lesquelles l’option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.
La taille maximale du sous-réseau de mappage externe prise en charge pour le NAT dynamique est /26.
Les mappages de ports ne peuvent être configurés qu’avec des types NAT statiques. Les scénarios NAT dynamiques ne s’appliquent pas aux mappages de ports.
Les mappages de ports ne peuvent pas prendre de plages pour l’instant. Un port individuel doit être entré.
Les mappages de ports peuvent servir pour les protocoles TCP et UDP.
Et en pratique ?
Pour valider la fonctionnalité de NAT au sein de mon architecture Azure, j’ai mis en place un petit exercice de démonstration. Mon environnement se compose de deux réseaux distincts :
Le premier simulant un réseau on-premise
Le second correspondant à un réseau virtuel Azure
Le schéma ci-dessous présente ces deux réseaux créés dans mon environnement Azure :
Dans le portail Azure, j’ai donc créé deux réseaux virtuels configurés sur la même plage d’adressage (10.0.0.0/16) pour illustrer un cas de chevauchement :
Sur chaque réseau virtuel, j’ai provisionné une machine virtuelle, toutes les deux en 10.0.0.4 pour renforcer l’idée d’adressage complètement identique :
Pour établir la connectivité, j’ai déployé deux VPN Gateway de type VpnGw2, configurées en tunnel IPsec site à site entre elles :
J’ai commencé par ajouter des règles NAT sur la passerelle Azure :
Egress rules –> pour présenter votre réseau virtuel Azure avec un adressage translaté à votre réseau on-premise :
adresses internes : l’adressage IP configuré sur votre réseau virtuel Azure
adresses externes = l’adressage IP translaté vu par votre réseau on-premise
Ingress rules –> pour accéder à votre réseau on-premise avec des IP différentes de celles configurées :
adresses internes = l’adressage IP configuré sur votre réseau on-premise
adresses externes = l’adressage IP translaté vu par votre réseau virtuel Azure
J’ai répliqué la même logique avec une configuration opposée sur la passerelle VPN simulant celle de mon réseau on-premise :
Egress rules –> pour présenter ton réseau on-premise avec un adressage translaté à ton réseau virtuel Azure :
adresses internes : l’adressage IP configuré sur ton réseau on-premise
adresses externes = l’adressage IP translaté vu par ton réseau virtuel Azure
Ingress rules –> pour accéder à ton réseau virtuel Azure avec des IP différentes de celles configurées :
adresses internes = l’adressage IP configuré sur ton réseau virtuel Azure
adresses externes = l’adressage IP translaté vu par ton réseau on-premise
Enfin, j’ai créé deux passerelle de réseau local correspondant à chaque extrémité :
L’une pour présenter le réseau on-premise à la passerelle Azure
L’autre pour présenter le réseau Azure la passerelle on-premise
La première passerelle de réseau local contient l’IP publique de la passerelle VPN Azure et la plage d’adresses 10.0.0.0/16 :
La seconde passerelle de réseau local contient l’IP publique de la passerelle VPN on-premise et la plage d’adresses 10.0.0.0/16 :
J’ai ensuite établi la connexion site-à-site entre mes deux VPN Gateways (VpnGw2) en utilisant la clé pré-partagée définie lors de la création des ressources.
Lors de la configuration de la première connexion, j’ai directement rattaché les règles Ingress NAT et Egress NAT définies précédemment à cette connexion, afin que toute session transitant par le tunnel soit automatiquement traduite.
J’ai reproduit la même configuration sur la seconde connexion : la clé PSK identique, la même plage 10.0.0.0/16 et les règles NAT :
Pour faciliter la connexion de la VM hébergée dans le réseau virtuel Azure, j’ai ajouté le service Azure Bastion :
Une fois Azure Bastion en place, je me suis connecté à la machine virtuelle Azure directement depuis le portail :
Depuis la machine virtuelle Azure, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la VM simulée on-premise :
Depuis le même service Azure Bastion déployé sur le réseau virtuel Azure, j’ai ouvert une session RDP vers la machine virtuelle simulée sur le réseau on-premise en utilisant l’adresse IP externe traduite définie dans les règles NAT de la connexion VPN :
Depuis la VM simulée on-premise, j’ai alors effectué plusieurs tests de connexion vers l’adresse IP externe traduite de la machine virtuelle Azure :
Conclusion
Grâce à l’association d’Azure VPN Gateway et de règles SNAT, nous avons validé une communication bidirectionnelle transparente entre deux environnements au plan d’adressage identique, sans exposer d’IP publiques aux VM. Cette démonstration illustre la puissance du NAT dans Azure pour contourner le chevauchement d’adresses
Notez toutefois que s’appuyer durablement sur le NAT peut complexifier votre architecture et alourdir le dépannage ; il est donc recommandé de considérer cette solution comme une étape temporaire, en prévoyant à terme une refonte de votre plan d’adressage pour une architecture plus saine.
Réussir la migration d’une infrastructure IT nécessite un objectif clair, un plan d’action, des moyens humains et matériels, et …. , du temps devant soi. Mais il arrive que la migration ne soit pas un parcours de santé, mais plutôt jonché de contraintes impactant les stratégies décidés avant. Par exemple, que doit-on faire si la migration de VMs doit se faire finalement sans aucun accès au niveau hyperviseur ?
Différentes approches de migration ?
Lors d’une migration vers le cloud, plusieurs approches coexistent : le « lift-and-shift » (reprise à l’identique), la replatforming ou refactoring (adaptation partielle) et la reconstruction totale accompagnée de modernisation.
Si le lift-and-shift est souvent privilégié pour sa rapidité de mise en œuvre, il n’exploite pas pleinement les services cloud-native et peut engendrer un surcoût opérationnel à long terme.
À l’inverse, la refonte ou la reconstruction des applications, en recourant par exemple aux microservices, au serverless ou aux bases de données managées, permet d’améliorer la scalabilité, la résilience et l’agilité, tout en optimisant les coûts à terme.
Azure Migrate ?
Bien entendu, dans certains scénarios, notamment lorsqu’on fait face à des délais serrés, à des contraintes budgétaires ou à un manque de compétences, il est nécessaire de migrer en priorité les machines virtuelles existantes « telles quelles ».
On opte alors pour un lift-and-shift à l’aide d’outils comme Azure Migrate ou Azure Site Recovery, qui répliquent les VM sans toucher au code ni à l’architecture.
Pour vous donner un peu de matière, un ancien article parlant d’Azure Migrate vous détaille toutes les grandes étapes.
Mais que faire si l’accès à l’hyperviseur est restreint ?
Toutefois, si aucun niveau d’accès la couche hyperviseur n’est possible, la migration vers Azure s’en trouve alors un peu plus compliquée.
Dans le cadre d’Azure Migrate (et plus précisément du service de réplication Azure Site Recovery), on rencontre 2 rôles clés au sein de l’appliance de réplication déployée :
Serveur de traitement :
Installé par défaut sur le serveur de configuration, il reçoit les données de réplication envoyées par le Mobility Service installé sur vos machines sources.
Il optimise ces flux en effectuant de la mise en cache, de la compression et du chiffrement, puis les transmet vers votre compte de stockage Azure.
Serveur de cible principale :
N’est utilisé que lors du failback (reprise sur site) des machines dès lors qu’elles ont été basculées vers Azure.
Il reçoit alors les données répliquées en provenance d’Azure, reconstitue les disques (VHD/VMDK) et les écrit sur votre infrastructure on-premises pour restaurer les VM sur site.
En synthèse, le Process Server gère l’envoi optimisé des données vers Azure, tandis que le Master Target Server gère la réception et la restauration de ces mêmes données lors d’un retour en local.
En voyant cette excellente vidéo en mode tutoriel, je trouvais intéressant de tester par moi-même ce cas de figure, en partant d’un environnement VMware vers Azure, sans pouvoir utiliser l’accès hyperviseur.
Cet article est donc divisé en 2 démonstrations quasi-identiques :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Afin de réaliser nos 2 tests de migration, nous allons avoir besoin de :
Un tenant Microsoft actif
Une souscription Azure valide
Un environnement hypervisé (Hyper-V ou VMware)
Commençons par effectuer l’exercice de migration en partant du principe que nous pouvons déployer une machine virtuelle jouant le rôle de d’appliance de réplication sur VMware.
Test I – Appliance de réplication VMware :
Sur votre console hyperviseur, créez une machine virtuelle de type Windows Serveur afin d’y installer par la suite notre appliance de réplication :
Connectez-vous à celle-ci avec un compte administrateur local :
Si besoin, installez un navigateur internet récent :
Connectez-vous au portail Azure, puis recherchez le service Azure Migrate :
Cliquez-ici pour commencer un nouveau projet de migration :
Cliquez-ici pour créer le projet de migration :
Renseignez les toutes informations demandées, puis cliquez sur Créer :
Cliquez sur Découvrir afin d’installer l’appliance de réplication :
Renseignez tous les champs, puis cliquez sur Créer les ressources :
Conservez les options suivantes :
Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :
Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :
Lancez l’installeur de l’appliance de réplication :
Attendez quelques minutes la fin de la décompression :
Conservez ce choix, puis cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Rechercher le fichier clef, puis cliquez sur Suivant :
Conservez ce choix, puis cliquez sur Suivant :
Attendez que tous les contrôles soit effectués, puis cliquez sur Suivant :
Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :
Si cela est votre cas, cochez cette case, puis cliquez sur Suivant :
Cliquez sur Suivant :
Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 10 minutes la fin de l’installation de l’appliance de réplication :
Cliquez sur Oui :
Collez cette passphrase dans un fichier texte, puis sauvegardez-le :
Une fois l’installation réussie, cliquez sur Terminer :
L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur de vos machines devant être migrées dans le cloud Azure :
Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’appliance de réplication :
Attendez le succès de l’opération via la notification suivante :
Constatez la création de ressources dans le groupe de ressources précédemment défini :
Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez l’exécutable ci-dessous :
Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y l’exécutable précédemment copié ainsi que le fichier texte contenant la passphrase :
Retournez sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée vers Azure :
Sur cette machine virtuelle à migrer, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :
$PSversiontable
Toujours depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication :
Toujours depuis votre machine virtuelle à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :
Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :
Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted
UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent /CSType CSLegacy
cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>
Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :
Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :
Exécutez cette commande pour installer l’agent :
Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :
Avant de continuer, vérifiez le succès des opérations :
Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :
Cliquez ensuite sur Répliquer :
Renseignez toutes les champs, puis cliquez sur Continuer :
Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :
Sélectionner les machines à migrer, puis cliquez sur Suivant :
Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :
Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :
Sélectionnez le type de disque à utiliser pour les machines à migrée, puis cliquez sur Suivant :
Lancez la réplication en cliquant sur Répliquer :
Les notifications suivantes apparaissent alors :
Des ressources Azure liées au projet de migration sont alors créées :
Le compte de stockage commence à recevoir les premières données liées à la réplication :
Dans le coffre Recovery, la réplication commence elle-aussi à être visible :
Environ 1 heure plus tard, celle-ci est terminée :
Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :
Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :
Définissez la destination cible, puis cliquez sur Continuer :
Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :
La notification suivante apparaît :
Quelques secondes plus tard, celle-ci affiche le succès du déclenchement de la migration :
Cette migration est visible sur notre projet Azure Migrate :
Le coffre Recovery nous indique que la migration est terminée :
Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :
Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :
# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
-Name 'fDenyTSConnections' -Value 0
# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force
Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green
Collez ces commandes, puis lancez celles-ci :
Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :
Constatez l’ouverture de session Windows sur votre machine virtuelle migrée :
La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.
Continuons l’exercice de migration en partant cette fois du principe que nous ne pouvons pas créer une machine virtuelle jouant le rôle d’appliance de réplication sur l’hyperviseur, et que celle-ci doit donc alors être obligatoirement déployée sur Azure.
Test II – Appliance de réplication sur Azure :
Pour cette approche, commencez par créer un réseau virtuel Azure comprenant plusieurs sous-réseaux virtuels :
Un sous-réseau dédié à l’appliance de réplication.
Un sous-réseau dédié à Azure Bastion.
Un sous-réseau dédié à la passerelle VPN, pour connecter notre machine virtuelle à migrer à notre appliance de réplication hébergée sur Azure.
Créez une machine virtuelle ayant pour futur rôle l’appliance de réplication :
Connectez-vous à celle-ci via Azure Bastion :
Afin de connecter par la suite la machine virtuelle à migrer à l’appliance de réplication Azure, via une connexion Point à Site, des certificats sont nécessaires pour l’authentification IKEv2.
Pour cela, depuis l’appliance de réplication Azure, générez et exportez les certificats :
Un certificat racine auto-signé (à exporter en .cer pour Azure)
Un certificat client signé par ce root (à exporter en .pfx pour votre machine cliente)
Sur votre appliance de réplication Azure, ouvrez une fenêtre PowerShell, puis lancez le script suivant pour générer le certificat racine :
Ouvrez le gestionnaire des certificats utilisateurs afin de constater sa présence :
Afin d’enregistrer les données du certificat public dans Azure, exportez ce dernier depuis le gestionnaire des certificats utilisateurs :
Choisissez Non, puis cliquez sur Suivant :
Sélectionnez Format Base-64 encodé X.509 (.CER), puis cliquez sur Suivant :
Indiquez le chemin de sauvegarde, puis cliquez sur Suivant :
Ouvrez le fichier en base-64 avec un éditeur, puis copiez tout le texte (sauf -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----) :
Dans le portail Azure, rendez-vous sur la page de votre passerelle VPN, puis démarrez la configuration Point à Site :
Définissez un espace d’adressage, le type de tunnel en IKEv2, collez le texte en Base-64 que vous venez de copier dans Données du certificat racine, puis cliquez sur Enregistrer.
Après quelques instants, constatez la notification Azure suivante :
Télécharger le client VPN afin de configurer plus tard le client VPN Windows natif sur la machine virtuelle à migrer :
Toujours sur appliance de réplication Azure, recherchez le service Azure Migrate :
Cliquez-ici pour commencer un projet de migration :
Cliquez-ici pour créer un projet de migration :
Renseignez toutes les informations demandées, puis cliquez sur Créer :
Cliquez sur Découvrir afin d’installer l’appliance de réplication :
Renseignez tous les champs, puis cliquez sur Créer les ressources :
Conservez les options suivantes :
Cliquez sur le bouton suivant afin de télécharger l’installeur de l’appliance de réplication :
Cliquez également sur le bouton suivant afin de sauvegarder la clef utilisée par l’appliance de réplication pour s’enrôler au coffre Azure Recovery :
Une fois téléchargé, lancez l’installeur :
Attendez quelques minutes la fin de la décompression :
Conservez ce choix, puis cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Rechercher le fichier clef, puis cliquez sur Suivant :
Conservez ce choix, puis cliquez sur Suivant :
Attendez que les contrôles soit effectués, puis cliquez sur Suivant :
Définissez un mot de passe pour la base de données MySQL, puis cliquez sur Suivant :
Si cela n’est pas votre cas, cochez cette case, puis cliquez sur Suivant :
Cliquez sur Suivant :
Définissez les 2 liaisons réseaux, puis cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 10 minutes la fin de l’installation :
Cliquez sur Oui :
Collez cette passphrase dans un fichier texte, puis sauvegardez-le :
Une fois l’installation réussie, cliquez sur Terminer :
L’outil de configuration d’Azure Site Recovery s’ouvre automatiquement, ajoutez-le ou les comptes administrateur des machines devant être migrées dans le cloud Azure :
Retournez sur le portail Azure, rafraîchissez la page précédente, puis cliquez ici pour finaliser le processus d’enregistrement de l’application de réplication :
Attendez le succès de l’opération avec la notification suivante :
Constatez la création de nouvelles ressources dans le groupe de ressources précédemment défini :
Retournez sur l’appliance de réplication, rendez-vous dans le dossier suivant, puis copiez seulement l’exécutable ci-dessous :
Créez un dossier partagé réseau sur votre appliance de réplication, puis collez-y :
L’exécutable précédemment copié
Le fichier texte contenant la passphrase
Rendez-vous sur la console hyperviseur, puis connectez-vous à la machine virtuelle devant être migrée sur Azure :
Sur cette machine virtuelle, vérifiez la version de PowerShell installée (min 5.1) grâce à la commande suivante :
Installez le certificat root dans le magasin Trusted Root Certification Authorities du gestionnaire des certificats machines :
Installez le certificat client dans le magasin Personal du certificats utilisateurs :
Installez la configuration VPN Windows précédemment téléchargée depuis la page Azure de la passerelle VPN :
Lancez la connexion VPN :
Cliquez sur Connecter :
Vérifiez le statut de la connexion VPN :
Depuis votre machine virtuelle à migrer, vérifiez la connexion sur le port 9443 vers votre appliance de réplication Azure :
Toujours depuis cette VM à migrer, ouvrez le dossier partagé réseau de votre appliance de réplication de réplication :
Copiez les fichiers dans un nouveau répertoire local sur votre machine virtuelle à migrer :
Ouvrez un éditeur de texte afin de reprendre et préparer les commandes suivantes :
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted
UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /Silent /CSType CSLegacy
cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>
Modifiez les valeurs en rouge par l’adresse IP de votre appliance de réplication et le chemin du fichier contenant la passphrase :
Ouvrez l’invite de commande en mode administrateur, puis exécutez les commandes suivantes pour copier le programme d’installation sur le serveur à migrer :
Exécutez cette commande pour installer l’agent :
Exécutez ces commandes pour enregistrer l’agent auprès du serveur de configuration :
Avant de continuer, vérifiez le succès des opérations :
Retournez sur le projet Azure Migrate, puis cliquez sur Rafraîchir afin de voir apparaître la machine virtuelle à migrer :
Cliquez ensuite sur Répliquer :
Renseignez toutes les champs, puis cliquez sur Continuer :
Sélectionnez les informations d’identification à utiliser pour installer à distance le service de mobilité sur les machines à migrer, puis cliquez sur Suivant :
Sélectionner les machines à migrer, puis cliquez sur Suivant :
Sélectionnez les propriétés cibles pour la migration. Les machines migrées seront créées avec les propriétés spécifiées, puis cliquez sur Suivant :
Sélectionnez la taille de la VM Azure pour les machines à migrer, puis cliquez sur Suivant :
Sélectionnez le type de disque à utiliser pour les machines à migrer, puis cliquez sur Suivant :
Lancez la réplication en cliquant sur Répliquer :
Les notifications suivantes apparaissent alors :
Le compte de stockage commence à recevoir les premières données liées à la réplication :
Dans le coffre Recovery, la réplication commence elle-aussi à être visible :
Environ 1 heure plus tard, celle-ci est terminée :
Un clic sur la machine virtuelle à migrer nous affiche le schéma de réplication des données :
Si tout est OK, retournez sur le projet de migration, actualiser si nécessaire afin de pouvoir cliquer sur Migrer :
Définissez la destination cible, puis cliquez sur Continuer :
Cochez la machine virtuelle à migrer, puis cliquez sur Migrer :
Quelques secondes plus tard, la notification suivante affiche le succès de déclenchement de la migration :
Cette migration est visible sur notre projet :
Le coffre Recovery nous indique que la migration est terminée :
Le groupe de ressources Azure contient alors de nouvelles ressources créées lors de la migration :
Afin de pouvoir nous connecter à la machine virtuelle via Azure Bastion, copiez les commandes suivantes depuis la page Azure de votre machine virtuelle migrée :
# 1. Autoriser les connexions RDP
Write-Host "Activation des connexions RDP…" -ForegroundColor Cyan
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' `
-Name 'fDenyTSConnections' -Value 0
# 2. Ouvrir le Pare-feu Windows pour RDP
Write-Host "Configuration du Pare-feu pour autoriser RDP…" -ForegroundColor Cyan
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# 3. Redémarrer le service TSE/RDP
Write-Host "Redémarrage du service TermService…" -ForegroundColor Cyan
Restart-Service -Name 'TermService' -Force
Write-Host "RDP activé et Pare-feu configuré. Vous pouvez maintenant vous connecter." -ForegroundColor Green
Collez ces commandes, puis lancez celles-ci :
Ensuite, connectez-vous à votre machine virtuelle migrée via Azure Bastion :
Constatez l’ouverture de session Windows sur votre machine virtuelle migrée sur Azure :
La migration de notre machine virtuelle hébergée sur VMware vers Azure s’est déroulée avec succès.
Conclusion
En définitive, migrer vos VMs vers Azure sans droits d’infra reste une solution de « seconde main » qui dépanne en cas de contraintes fortes, mais elle ne doit pas devenir la norme.
Pour tirer pleinement parti du cloud, il sera toujours préférable de recréer vos ressources selon les principes cloud-native : refactoring des applications, adoption de services managés et optimisation des coûts.
À long terme, cette approche garantit une meilleure scalabilité, une résilience accrue et une plus grande agilité opérationnelle, tout en maîtrisant vos dépenses. Gardez donc cette méthode de contournement sous le coude, mais visez toujours la modernisation et l’optimisation complètes de votre stack dans Azure.
Les solutions de bureau à distance, telles qu’Azure Virtual Desktop et Windows 365, reposent sur des protocoles de transport pour offrir une expérience utilisateur fluide et réactive. Par défaut, UDP est souvent privilégié pour sa faible latence, mais dans certains environnements, la fiabilité et la stabilité offertes par TCP priment.
Cet article détaille les spécificités de chacun de ces protocoles, leurs avantages et inconvénients, et propose deux approches pour forcer l’usage de TCP : une modification côté serveur et une modification côté client, que ce soit directement via le registre ou en déployant une stratégie de groupe (GPO).
TCP et son rôle dans les solutions de bureau à distance :
Le Transmission Control Protocol (TCP) est un protocole orienté connexion qui assure la fiabilité des échanges. Il garantit que les paquets arrivent dans l’ordre et, en cas de perte, les retransmet automatiquement.
Avantages de TCP :
Fiabilité et intégrité des données : Chaque paquet est vérifié et retransmis en cas d’erreur ou de perte.
Contrôle d’erreur et ordonnancement : Les données arrivent dans le bon ordre, ce qui est essentiel pour des applications nécessitant une cohérence stricte.
Inconvénients de TCP :
Surcharge et latence accrue : Les mécanismes de contrôle (comme le handshake initial) ajoutent un certain délai.
Moins performant pour les applications ultra-réactives : La latence induite peut être un frein pour certaines applications en temps réel.
UDP et ses applications dans le Remote Desktop :Le User Datagram Protocol (UDP) est un protocole sans connexion qui envoie les paquets sans vérifier leur réception ni leur ordre. Cette approche permet une transmission rapide avec une latence très réduite, idéale pour des sessions interactives.
Avantages de UDP :
Faible latence : Parfait pour des sessions de Remote Desktop où la réactivité est cruciale.
Moindre surcharge : L’absence de contrôle d’erreur exhaustif accélère le transfert des données.
Inconvénients de UDP :
Fiabilité moindre : Sans retransmission automatique, la perte de paquets peut dégrader la qualité de la session.
Absence de contrôle d’erreur intégré : Dans des environnements instables, cela peut entraîner des distorsions.
Fort de cette comparaison, il apparaît que le choix du protocole doit être adapté au contexte réseau. Par exemple, dans des environnements à qualité réseau variable, forcer l’utilisation de TCP peut s’avérer judicieux pour garantir une meilleure stabilité des connexions.
Forcer le flux TCP côté serveur
Il est possible de forcer le serveur à n’accepter que des connexions TCP, ce qui est particulièrement utile dans des environnements où la stabilité prime. Pour cela, vous pouvez modifier le registre du serveur ou déployer une GPO.
Modification via Registre
Avant modification, le serveur accepte par défaut les connexions en UDP (comme indiqué par vos captures d’écran). Pour forcer TCP, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport.
Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre SelectTransport :
Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :
« Use either UDP or TCP (default) » : Si la connexion UDP est possible, la majorité du trafic RDP l’utilisera.
« Use only TCP » : Toutes les connexions RDP se feront exclusivement via TCP.
Si cette stratégie n’est pas configurée ou est désactivée, RDP sélectionnera automatiquement le protocole optimal pour offrir la meilleure expérience utilisateur.
Testons maintenant la configuration côté client.
Forcer le flux TCP côté client
Passons à présent à la configuration côté client. Avant modification, le client se connecte en UDP, comme le montrent les captures d’écran. Pour forcer l’utilisation de TCP (via WebSocket, qui repose sur TCP), il suffit d’ajouter la clé de registre fClientDisableUDP.
Avant modification, le client fonctionnait en UDP, comme vous pouvez le constater sur la capture d’écran ci‑dessous.
Pour ce faire, la modification est simple : il suffit d’ajouter la clé de registre fClientDisableUDP.
Voici la commande permettant d’ajouter automatiquement cette clé de registre Windows avec des droits administrateur :
Après modification, la connexion se fait exclusivement en TCP. Ce changement assure que le client ne tente plus d’établir une connexion via UDP :
Conclusion
Le choix entre TCP et UDP dans des environnements de bureau à distance comme Azure Virtual Desktop et Windows 365 se résume à un compromis entre rapidité et fiabilité :
UDP offre une faible latence, idéale pour des sessions interactives, mais peut souffrir de pertes de paquets dans des réseaux instables.
TCP, même via une couche WebSocket, garantit la transmission fiable des données, au prix d’un léger surcoût en latence.
Note technique : Forcer l’utilisation de TCP est particulièrement recommandé dans les environnements où la qualité du réseau est variable ou sujette à des perturbations. Dans ces situations, bien que TCP puisse introduire une latence légèrement supérieure, il offre une stabilité et une fiabilité accrues, assurant ainsi une expérience utilisateur plus homogène.
En forçant l’utilisation de TCP via une modification de registre côté serveur (ou via une GPO) et/ou côté client, vous pouvez améliorer la stabilité des connexions, particulièrement dans des environnements où la qualité de la connexion est incertaine.
Ces approches vous permettent de mieux contrôler la configuration de votre infrastructure de Remote Desktop, optimisant ainsi l’expérience pour vos utilisateurs.
Début février, Microsoft vient d’annoncer une nouvelle fonctionnalité en préversion pour migrer une machine virtuelle, de première génération vers la seconde. Cette bascule de génération est l’occasion de renforcer la sécurité (via Secure Boot et vTPM), d’améliorer les performances (temps de démarrage plus rapides) et d’offrir un support de disques de plus grande capacité. Tout cela, sans avoir besoin de reconstruire la machine virtuelle et en quelques clics.
Depuis quand la génération 2 est disponible sur Azure ?
Microsoft a annoncé la prise en charge des machines virtuelles de génération 2 depuis 2019, avec une généralisation progressive de leur déploiement par la suite.
Il y a quelques jours, Microsoft a annoncé la prévisualisation publique des machines virtuelles de génération 2 sur Azure. Les machines virtuelles de génération 2 prennent en charge un certain nombre de nouvelles technologies telles que l’augmentation de la mémoire, les Intel Software Guard Extensions (SGX) et la mémoire persistante virtuelle (vPMEM), qui ne sont pas prises en charge par les machines virtuelles de génération 1. Mais nous y reviendrons plus tard.
Les machines virtuelles Gen1 restaient toujours utiles pour la migration d’environnements legacy, ou lorsque la compatibilité avec d’anciennes images était nécessaire.
En revanche, les VM Gen 2, avec leur firmware UEFI, offrent la possibilité d’exécuter des fonctionnalités modernes comme la virtualisation imbriquée.
Qu’est-ce que le Trusted Launch ?
Azure propose le lancement fiable pour améliorer de manière fluide la sécurité des machines virtuelles (VM) de génération 2. Le lancement fiable protège contre les techniques d’attaque avancées et persistantes. Le lancement fiable se compose de plusieurs technologies d’infrastructure coordonnées qui peuvent être activées indépendamment. Chaque technologie offre une couche de défense supplémentaire contre les menaces sophistiquées.
Concrètement, Trusted Launch combine plusieurs technologies :
Secure Boot : Assure que seuls des composants logiciels signés et vérifiés sont autorisés à se charger pendant le démarrage.
vTPM (TPM virtuel) : Fournit une zone sécurisée pour stocker des clés cryptographiques et d’autres informations sensibles.
Measured Boot : Enregistre et vérifie les mesures du processus de démarrage pour détecter toute modification non autorisée.
Qu’est-ce que le Secure Boot ?
Le Secure Boot est donc une fonctionnalité de sécurité intégrée au niveau du firmware qui garantit que, lors du démarrage du système, seuls des composants logiciels authentifiés et signés numériquement (bootloader, pilotes, etc.) sont chargés.
Cela permet de prévenir l’exécution de code malveillant dès le démarrage, protégeant ainsi le système contre des attaques telles que les bootkits. En vérifiant l’intégrité et l’authenticité des éléments critiques, Secure Boot contribue à renforcer la sécurité globale de la machine.
Quelles sont les différences entre les 2 générations ?
Ce tableau permet ainsi de choisir la génération en fonction des besoins spécifiques en termes de sécurité, performance et compatibilité :
Fonctionnalité
Machines virtuelles Gen 1
Machines virtuelles Gen 2
Exemple / Explication
1. Type de firmware
BIOS
UEFI
Gen 2 utilise l’UEFI, permettant par exemple l’activation du Secure Boot.
2. Support des systèmes d’exploitation
32 bits et 64 bits
Exclusivement 64 bits
Pour un déploiement Windows Server 2019, seule la Gen 2 est compatible en 64 bits.
3. Interface de disque de démarrage
Utilise un contrôleur IDE
Utilise un contrôleur SCSI
Le démarrage sur SCSI en Gen 2 offre de meilleures performances I/O.
4. Secure Boot
Non disponible
Disponible
La sécurité est renforcée grâce au Secure Boot dans les VM Gen 2.
5. Virtualisation imbriquée
Support limité
Support amélioré
Permet d’exécuter Hyper-V dans la VM Gen 2 pour des environnements de test.
6. Temps de démarrage
Démarrage plus classique
Démarrage généralement plus rapide
Une VM Gen 2 peut démarrer plus vite grâce à l’architecture UEFI optimisée.
7. Taille maximale du disque système
Limité selon les anciens standards
Support de disques système de plus grande taille
Idéal pour des OS nécessitant un volume de boot plus important.
8. Virtualisation basée sur la sécurité
Non supportée
Supportée
Permet d’utiliser des fonctionnalités telles que Windows Defender Credential Guard.
9. Gestion de la mémoire
Standard
Optimisée pour des performances supérieures
Amélioration dans la gestion de la mémoire et la réactivité du système dans la Gen 2.
10. Support des périphériques modernes
Compatible avec du matériel plus ancien
Conçu pour exploiter les dernières technologies matérielles
Par exemple, intégration possible d’un TPM virtuel pour renforcer la sécurité.
11. Déploiement et gestion
Basé sur des modèles plus anciens
Optimisé pour une gestion moderne via Azure Resource Manager
Facilite l’intégration avec les nouvelles options de déploiement automatisé dans Azure.
12. Compatibilité des images
Compatible avec un large éventail d’images anciennes
Restreint aux images récentes optimisées pour UEFI
Gen 1 permet d’utiliser des images plus anciennes, alors que Gen 2 cible les OS modernes.
En résumé, le choix entre Gen1 et Gen2 se fera principalement en fonction des exigences de compatibilité et de sécurité :
Gen1 convient aux scénarios où l’héritage et la compatibilité avec des images plus anciennes priment.
Gen2 est privilégiée pour bénéficier d’une meilleure sécurité et de performances optimisées, notamment grâce aux fonctionnalités comme Secure Boot et le vTPM.
Puis-je utiliser des Gen1/Gen2 avec toutes les familles de machines virtuelles Azure ?
Non. Et pour vous aider, Microsoft vous met à disposition cette liste, disponible via ce lien.
Toutes les images OS sont-elles compatible avec Gen2 ?
Non. Les machines virtuelles Gen2 prennent en charge que certaines images OS :
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012
Windows 11 Professionnel, Windows 11 Entreprise
Windows 10 Professionnel, Windows 10 Entreprise
SUSE Linux Enterprise Server 15 SP3, SP2
SUSE Linux Enterprise Server 12 SP4
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS
Puis-je basculer une VM de Gen1 à Gen2, et inversement ?
Anciennement, il n’était pas possible de facilement convertir directement une VM existante de Gen1 vers Gen2, en raison des différences fondamentales au niveau du firmware et de la configuration des disques. Pour migrer vers une Gen2, il fallait alors bien souvent recréer la machine virtuelle dans la génération cible.
Qu’est-ce que MBR2GPT ?
MBR2GPT est un outil en ligne de commande de Microsoft qui permet de convertir un disque partitionné en MBR vers le format GPT sans perte de données, facilitant ainsi la transition d’un mode BIOS hérité vers un démarrage UEFI.
Depuis peu, Microsoft vient d’ajouter une fonctionnalité, encore en préversion, pour basculer de Gen1 à Gen2 en quelques clics, dont la source est disponible juste ici.
Enfin, voici d’ailleurs une vidéo de Microsoft parlant en détail de l’outil MBR2GPT :
Comme indiqué dans cette vidéo, l’outil MBR2GPT va travailler sur la conversation des partitions de l’OS :
Le processus sur Azure se fait en seulement quelques clics, et je vous propose de tester tout cela 😎💪
Pour réaliser ce test de conversation de génération (encore en préversion), il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Commençons par créer une machine virtuelle de première génération.
Etape I – Création de la machine virtuelle Gen1 :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle compatible à la fois Gen1 et Gen2 :
Renseignez les informations de l’administrateur local, 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 :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion pour continuer.
L’étape suivante consiste à lancer l’utilitaire intégré MBR2GPT afin de valider et de transformer la partition du disque OS au format GPT, et aussi d’ajouter la partition système EFI requise pour la mise à niveau en Gen2.
Etape II – Transformation du disque OS depuis MBR vers GPT :
Une fois Azure Bastion correctement déployé, saisissez les identifiants renseignés lors de la création de votre machine virtuelle :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
Confirmez le statut du mode BIOS en Legacy :
Les propriétés du disque OS nous confirme l’utilisation du style de partition MBR (Master Boot Record) :
Depuis le menu Démarrer de votre machine virtuelle, puis cliquez sur Exécutez pour ouvrir le programme cmd :
Lancez la commande MBR2GPT suivante pour exécuter la validation MBR vers GPT :
MBR2GPT /validate /allowFullOS
Assurez-vous que la validation de l’agencement du disque se termine avec succès. Ne continuez pas si la validation du disque échoue :
Lancez la commande MBR2GPT suivante pour exécuter la conversion MBR vers GPT :
MBR2GPT /convert /allowFullOS
Obtenez le résultat suivant :
Cliquez-ici pour fermer votre session Windows :
Une fois la session Windows fermée, cliquez-ici pour fermer l’onglet ouvert pour Azure Bastion :
Depuis le portail Azure, arrêtez votre machine virtuelle :
Confirmez votre choix en cliquant sur Oui :
Quelques minutes plus tard, confirmez que la machine virtuelle est en état Arrêté (désallouée).
Encore en préversion, l’activation des mesures de sécurité sur la machine virtuelle n’est pas possible depuis le portail Azure. Il faut donc utiliser Azure Cloud Shell.
Etape III – Activation du vTPM et du Secure Boot :
Mais avant d’activer le vTPM et le Secure Boot sur notre machine virtuelle Azure, il est nécessaire d’activer la fonctionnalité Gen1ToTLMigrationPreview, encore en préversion, sur notre souscription Azure.
Pour cela, cliquez sur le bouton suivant pour ouvrir la fenêtre d’Azure Cloud Shell :
Une fois Azure Cloud Shell d’ouvert en mode PowerShell, saisissez la commande suivante afin de voir si celle-ci est déjà activée :
Validez la mise à jour du profil de sécurité le dans la configuration de la VM :
# Following command output should be `TrustedLaunch
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.SecurityType
# Following command output should return `SecureBoot` and `vTPM` settings
(Get-AzVM -ResourceGroupName myResourceGroup -VMName myVm | Select-Object -Property SecurityProfile -ExpandProperty SecurityProfile).SecurityProfile.Uefisettings
Le changement de génération de notre machine virtuelle est également visible sur le portail Azure :
De même que le profil de sécurité ainsi que les options activées (une fois que vous avez activé le Trusted launch, les machines virtuelles ne peuvent plus être ramenées au type de sécurité Standard) :
Ces options sont encore modifiables depuis l’écran ci-dessous (Microsoft recommande d’activer le Secure Boot si vous n’utilisez pas de pilotes personnalisés non signés) :
Redémarrez votre machine virtuelle :
Reconnectez-vous à celle-ci via le service Azure Bastion :
Constatez la bonne ouverture de session Windows :
Confirmez le statut du mode BIOS en UEFI, de même que l’activation du Secure Boot :
Relancer la validation de l’agencement du disque sur un disque déjà configuré en GPT provoquera une erreur logique :
Les propriétés du disque OS nous confirme l’utilisation du style de partition GUID (GPT), qui est un schéma de partitionnement moderne qui utilise des identifiants uniques (GUID) pour chaque partition :
Etape IV – Activation de services annexes :
Une fois la bascule en Gen2 effectuée, il n’est plus possible d’activer la sauvegarde via Azure Backup avec une police de type standard :
D’ailleurs, l’activation de la sauvegarde après le changement de Gen1 à Gen2 n’a posé aucun souci :
Il en a été de même pour l’activation de réplication pour une machine migrée de Gen1 à Gen2 :
Dans le cadre d’un test de failover, la nouvelle machine virtuelle, créée temporairement, est bien elle aussi en génération 2 :
La connexion via Azure Bastion sur cette machine virtuelle temporaire est bien fonctionnelle :
Conclusion
En conclusion, cette procédure toute simple et réalisée en quelques clics avec MBR2GPT nous démontre que migrer vos machines virtuelles de Gen1 à Gen2 représente bien plus qu’un simple changement de firmware :
Grâce à une sécurité renforcée avec Secure Boot et vTPM, des performances accrues et une prise en charge des disques de plus grande taille.
Adopter Gen2, c’est ainsi investir dans une plateforme plus robuste, performante et alignée avec les exigences actuelles de la sécurité informatique.
Microsoft innove pour Windows Serveur 2025 et propose de payer la licence via un abonnement paiement à l’utilisation (PAYG) grâce à Azure Arc ! Avec cette option, vous déployez une VM et payez uniquement pour l’utilisation. Cette fonctionnalité est facturée directement sur votre abonnement Azure. Vous pouvez désactiver le paiement à l’utilisation à tout moment. Enfin, le tarif semble assez intéressant 😎
Une vidéo de John existe déjà sur le sujet 🙏💪 :
Dans cet article, je vous propose de tester et surtout de voir combien cela coûte💰:
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice de licence PAYG sur Windows Serveur 2025, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Afin de tester cette fonctionnalité de licensing utilisant Azure Arc, nous allons avoir besoin de lier nos VMs de test à une souscription Azure présente sur notre tenant Microsoft.
Pour cela, je vous propose donc de simuler plusieurs VMs sous Windows Serveur 2025 grâce à un environnement Hyper-V créé sous Azure.
Dans Azure, il est en effet possible 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 :
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 :
Renseignez les informations de l’administrateur local, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la machine virtuelle invitée (Windows Serveur 2025),créée plus tard dans notre machine virtuelle Hyper-V, puis cliquez 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 Hyper-V :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
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 au format NTFS :
Une fois connecté sur votre machine virtuelle Hyper-V, ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
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 :
L’environnement Hyper-V est maintenant en place. Nous allons pouvoir créer ensemble la machine virtuelle sous Windows Serveur 2025.
Etape II – Création de la machine virtuelle :
Pour cela, il est nécessaire de récupérer une image au format ISO de Windows Serveur 2025, puis de lancer l’installation.
Toujours sur la machine virtuelle Hyper-V, ouvrez le navigateur internet Microsoft Edge.
Dans mon cas, je suis passé par Visual Studio pour télécharger l’image au format ISO de Windows Serveur 2025 :
Attendez quelques minutes pour que le téléchargement se termine :
Une fois le fichier téléchargé, rouvrez votre console Hyper-V Manager, puis cliquez-ici pour créer votre machine virtuelle Windows Serveur 2025 :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM Hyper-V, puis cliquez sur Suivant :
Pensez à bien choisir Génération 2 :
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 de Windows Serveur 2025 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 créée, cochez la case suivante pour activer TPM, puis augmenter le nombre de processeurs :
Double-cliquez sur votre machine virtuelle invitée, puis cliquez-ici pour lancer son démarrage :
La machine virtuelle est maintenant prête à recevoir Windows Serveur 2025. Suivez toutes les étapes de l’installation pour le configurer.
Etape III – Installation de Windows Serveur 2025 :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Définissez la langue de votre clavier, puis cliquez sur Suivant :
Lancez l’installation de Windows Serveur 2025 :
Cliquez-ici afin de ne pas renseigner de clef de licence Windows Serveur 2025 pour utiliser par la suite une licence en PAYG :
Choisissez une version Desktop, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Lancez l’installation de Windows Serveur 2025 :
Attendez maintenant quelques minutes la fin de l’installation de Windows Serveur 2025 :
Attendez que le redémarrage se poursuivre :
Définissez un mot de passe à votre compte local, puis cliquez sur Suivant :
Déverrouillez la session Windows :
Renseignez à nouveau le mot de passe de votre compte administrateur pour ouvrir la session :
Adaptez la configuration des remontées télémétriques, puis cliquez sur Accepter :
Windows Serveur 2025 est maintenant installé sur notre machine virtuelle. Il nous faut maintenant configurer Azure Arc afin que la liaison avec Azure puisse mettre en place la licence PAYG.
Etape IV – Configuration d’Azure Arc :
Une fois la session Windows ouverte, ouvrez les paramètres systèmes depuis le menu Démarrer :
Constatez l’absence de licence Windows Serveur 2025 active, puis cliquez dessus :
L’erreur suivante concernant l’activation apparaît alors :
Ouvrez le programme de configuration d’Azure Arc déjà préinstallé :
Cliquez sur Suivant :
Attendez quelques instants afin que l’installation se finalise :
Une fois Azure ARC installé, cliquez sur Configurer :
Cliquez sur Suivant :
Cliquez-ici afin de générer un code d’activation à usage unique :
Copiez le code généré :
Rendez-vous sur la page web indiquée, puis collez le code précédemment copié :
Authentifiez-vous avec un compte Azure disposant des droits nécessaires :
Cliquez sur Suivant :
Sélectionnez Pay-as-you-go, puis cliquez sur Suivant :
Sur le dernier écran de la procédure de configuration, sélectionnez Terminer :
Constatez la bonne connexion à Azure Arc via l’icône de notification suivant :
La liaison via Azure Arc est maintenant opérationnelle, mais la licence Windows Serveur 2025 n’est pas encore appliquée sur votre machine virtuelle. Nous allons devoir terminer la configuration de celle-ci depuis le portail Azure.
Etape V – Gestion de la licence PAYG :
Retournez sur la page système d’activation de Windows afin de constater la présence d’un autre message d’erreur :
Retournez sur le portail Azure, puis cliquez sur la nouvelle ressource Azure représentant notre machine virtuelle et créée après la fin de la configuration d’Azure Arc :
Dans le menu Licences du volet gauche, cochez la case Pay-as-you-go with Azure, puis sélectionnez Confirmer :
Attendez quelques minutes afin de constater la bonne activation de celle-ci :
Cette information est également visible depuis la page principale de la ressource Arc :
Rouvrez la page système d’activation de Windows afin de constater la bonne activation de la licence Windows :
Afin de comprendre un peu mieux les mécanismes de licences PAYG via Azure Arc, j’ai créé au total 4 machines virtuelles sur mon serveur Hyper-V :
Machine virtuelle Windows Serveur Standard 4 cœurs,
Machine virtuelle Windows Serveur Standard 4 cœurs éteinte par la suite,
Machine virtuelle Windows Serveur Datacentre 4 puis 8 cœurs par la suite,
Machine virtuelle Windows Serveur Standard 12 cœurs.
J’y ai également configuré Azure Arc, et activé les licences Windows Serveur 2025 via ma souscription Azure :
Mon environnement de test est maintenant en place, il ne nous reste qu’à attendre plusieurs jours afin de comprendre les coûts facturés par Microsoft via ma souscription Azure.
Etape VI – Analyse des coûts de licence :
Afin de comprendre les coûts de facturation pour les différentes machines virtuelles fonctionnant sous Windows Serveur 2025 PAYG, je vous propose d’utiliser le Gestionnaire des coûts Azure :
Utilisez les différents filtres disponibles pour identifier les coûts qui vous intéressent :
Commençons par analyser les 7 premiers jours suivant la configuration de mon environnement de test :
Comme le montre le gestionnaire des coûts ci-dessus, ainsi que la documentation Microsoft ci-dessous, aucun frais de licence n’est facturé durant les 7 premiers jours :
En outre, vous pouvez utiliser le paiement à l’utilisation gratuitement pour les sept premiers jours après l’avoir activé en tant qu’essai.
Pour plus de clarté, j’ai également transposé ces premiers résultats dans un tableau Excel :
J’ai continué avec les 3 jours suivants, cette fois facturés par Microsoft :
Comme le montre le gestionnaire des coûts ci-dessus, ainsi que la documentation Microsoft ci-dessous, des frais journaliers en fonction du nombre de cœurs de chaque VM sont facturés :
Pour plus de clarté, j’ai également transposé ces résultats dans un tableau Excel :
Deux informations sont intéressantes dans ce tableau :
La tarification par cœur Microsoft semble identique pour des machines sous licence Standard ou Datacentre.
Il semble que le prix $33.58 indiqué par Microsoft dans la documentation ne corresponde pas à un prix unitaire relevé par cœur, mais pour 2 cœurs :
J’ai ensuite effectué par la suite 2 modifications sur 2 de mes machines virtuelles de test :
Arrêt d’une machine virtuelle
Augmentation du nombre de cœurs
Pour plus de clarté, j’ai également transposé ces résultats dans un tableau Excel :
L’arrêt de la machine virtuelle le 24 décembre montre bien une baisse des coûts de licence pour les jours suivants.
Le passage de 4 à 8 cœurs indique bien un doublement des coûts de licences pour les jours suivants.
Voici enfin le même tableau Excel dans sa totalité
Conclusion
En résumé, cette nouvelle approche pour licencier des serveurs en dehors du cloud est facile à mettre en œuvre et semble très intéressante financièrement. Les tests ont montré qu’un arrêt de machine virtuelle réduit les coûts de licence, tandis que l’augmentation du nombre de cœurs entraîne une augmentation proportionnelle des coûts.
Ces observations soulignent l’importance de gérer judicieusement les ressources et les configurations de vos machines virtuelles pour toujours optimiser au mieux les coûts de licence.
Enfin, pour la gestion des licences Azure, il est fortement recommandé de considérer Azure Hybrid Benefit pour la majorité des machines virtuelles sous Windows pour maximiser les économies.
La restriction du presse-papier Windows entre le poste local et une session Azure Virtual Desktop est déjà possible depuis la configuration du protocole RDP. Mais la personnalisation des restrictions peut être poussée encore d’un cran. Avec Intune, vous pouvez exiger que le fameux copier-coller ne fonctionne que dans un sens spécifique, ou même uniquement que pour certains types de donnée !
Comme annoncé en introduction, vous pouvez déjà configurer beaucoup de paramètres RDP pour Azure Virtual Desktop. La configuration du protocole RDP est directement disponible depuis la configuration de votre pool d’hôtes de session Azure Virtual Desktop.
Le protocole RDP (Remote Desktop Protocol) possède plusieurs propriétés que vous pouvez définir pour personnaliser le comportement d’une session à distance, par exemple pour la redirection d’appareil, les paramètres d’affichage, le comportement de session, etc.
Quelles sont les propriétés RDP prises en charges par AVD ?
Toutes les propriétés existantes au protocole RDP ne sont pas intégrées à Azure Virtual Desktop. Voici la liste de ceux compatibles avec AVD, et sont aussi disponibles sur la page officielle de Microsoft :
Propriété RDP
Description
encode redirected video capture
Active ou désactive l’encodage de la vidéo redirigée.
targetisaadjoined
Autorise les connexions aux hôtes de session joints à Microsoft Entra à l’aide d’un nom d’utilisateur et d’un mot de passe. Cette propriété s’applique uniquement aux clients non-Windows et aux appareils Windows locaux qui ne sont pas joints à Microsoft Entra. Elle est remplacée par la propriété enablerdsaadauth.
camerastoredirect
Configure les caméras à rediriger. Ce paramètre utilise une liste délimitée par des points-virgules des interfaces KSCATEGORYVIDEOCAMERA des caméras activées pour la redirection.
redirected video capture encoding quality
Contrôle la qualité de la vidéo encodée.
maximizetocurrentdisplays
Détermine l’affichage d’une session à distance utilisée pour l’écran plein écran lors de l’optimisation. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
drivestoredirect
Détermine les lecteurs fixes, amovibles et réseau sur l’appareil local qui seront redirigés et disponibles dans une session à distance.
devicestoredirect
Détermine les périphériques qui utilisent le protocole MTP (Media Transfer Protocol) ou le protocole PTP (Picture Transfer Protocol), comme une caméra numérique, sont redirigés d’un appareil Windows local vers une session à distance.
usbdevicestoredirect
Détermine les périphériques USB pris en charge sur l’ordinateur client qui sont redirigés à l’aide d’une redirection opaque de bas niveau vers une session distante.
bandwidthautodetect
Détermine s’il faut ou non utiliser la détection automatique de la bande passante réseau.
redirected clipboard
Détermine s’il faut rediriger le Presse-papiers.
smart sizing
Détermine si l’appareil local met à l’échelle le contenu de la session distante pour qu’il corresponde à la taille de la fenêtre.
autoreconnection enabled
Détermine si l’appareil local tente automatiquement de se reconnecter à l’ordinateur distant si la connexion est supprimée, par exemple en cas d’interruption de la connectivité réseau.
redirectlocation
Détermine si l’emplacement de l’appareil local est redirigé vers une session distante.
audiomode
Détermine si l’ordinateur local ou distant lit l’audio.
compression
Détermine si la compression en bloc est activée lors de la transmission de données à l’appareil local.
videoplaybackmode
Détermine si la connexion utilisera le streaming multimédia efficace par RDP pour la lecture vidéo.
networkautodetect
Détermine si la détection automatique des types de réseau est activée.
dynamic resolution
Détermine si la résolution d’une session distante est automatiquement mise à jour lorsque la fenêtre locale est redimensionnée.
use multimon
Détermine si la session distante utilise un ou plusieurs affichages à partir de l’appareil local.
enablerdsaadauth
Détermine si le client utilisera l’ID Microsoft Entra pour s’authentifier auprès du PC distant. Lorsqu’il est utilisé avec Azure Virtual Desktop, cela offre une expérience d’authentification unique. Cette propriété remplace la propriété targetisaadjoined.
enablecredsspsupport
Détermine si le client utilisera le fournisseur de support de sécurité des informations d’identification (CredSSP) pour l’authentification s’il est disponible.
redirectsmartcards
Détermine si les appareils de carte à puce sur l’appareil local sont redirigés et disponibles dans une session à distance.
keyboardhook
Détermine si les combinaisons de touches Windows (Windows, OngletAlt+) sont appliquées à une session à distance.
redirectprinters
Détermine si les imprimantes disponibles sur l’appareil local sont redirigées vers une session à distance.
redirectcomports
Détermine si les ports série ou COM sur l’appareil local sont redirigés vers une session distante.
redirectwebauthn
Détermine si les requêtes WebAuthn d’une session distante sont redirigées vers l’appareil local, ce qui permet d’utiliser des authentificateurs locaux (tels que des clés de sécurité et de Windows Hello Entreprise).
screen mode id
Détermine si une fenêtre de session distante s’affiche en plein écran lorsque vous lancez la connexion.
singlemoninwindowedmode
Détermine si une session distante à affichage multiple bascule automatiquement vers un affichage unique lors de la sortie de l’écran plein écran. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows et l’application Bureau à distance pour Windows.
audiocapturemode
Indique si la redirection d’entrée audio est activée.
desktopheight
Spécifie la hauteur de résolution (en pixels) d’une session distante.
desktopwidth
Spécifie la largeur de résolution (en pixels) d’une session distante.
desktopscalefactor
Spécifie le facteur d’échelle de la session distante pour rendre le contenu plus grand.
kdcproxyname
Spécifie le nom de domaine complet d’un proxy KDC.
selectedmonitors
Spécifie les affichages locaux à utiliser dans une session distante. Les affichages sélectionnés doivent être contigus. Nécessite use multimon la valeur 1. Disponible uniquement sur l’application Windows pour Windows, l’application Bureau à distance pour Windows et l’application de connexion Bureau à distance de boîte de réception sur Windows.
desktop size id
Spécifie les dimensions d’un bureau de session à distance à partir d’un ensemble d’options prédéfinies. Ce paramètre est remplacé si les paramètres desktopheight et desktopwidth sont spécifiés.
alternate shell
Spécifie un programme à démarrer automatiquement dans une session distante en tant que shell au lieu de l’Explorateur.
Où les modifier ?
Certaines propriétés RDP sont en effet modifiables depuis ces écrans du pool d’hôtes :
Informations de connexion :
Comportement de la session :
Redirection de périphérique :
Comme vous pouvez le voir dans la copie d’écran ci-dessous, la configuration détermine si le presse-papiers de l’ordinateur client sera redirigé et disponible ou non dans la session distante, et vice versa :
Le presse-papiers de l’ordinateur local est disponible dans la session à distance (par défaut)
Le presse-papiers de l’ordinateur local n’est pas disponible dans la session à distance
Non configuré
Paramètres d’affichage
Avancé
Peut-on configurer le comportement de redirection du Presse-papiers plus finement ?
Oui, cela est possible grâce à l’une des 3 méthodes suivantes :
Via Microsoft Intune
Via une stratégie de groupe
Via une ou des clefs de registre dans la golden image
Travis vous explique en détail la fonctionnalité via les clefs de registre Windows :
Dans cet article, je vous propose de tester la méthode via Intune :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Peu de prérequis sont nécessaires pour réaliser ce test AVD sur les restrictions du presse-papier Windows :
Un tenant Microsoft
Une souscription Azure valide
Dans ce test, nous allons déployer un environnement Azure Virtual Desktop composé de 5 machines virtuelles individuelles. Ces 5 machines nous permettront de comparer les différentes configurations Intune afin de voir les changement dans le presse-papier :
Aucune restriction
Restriction complète
Restriction depuis le poste local
Restriction depuis AVD
Restriction sur le format de donné
Etape I – Préparation Azure Virtual Desktop :
Avant tout, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création par la barre de recherche :
Nommez celui-ci, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1minute :
Une fois le réseau virtuel déployé, continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant là encore la barre de recherche du portail Azure :
Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop
Choisissez un pool d’hôtes de type personnel, puis cliquez sur Suivant :
Définissez le nombre de machines virtuelles créées ainsi que la région Azure, puis choisissez l’image OS :
Choisissez les caractéristiques techniques de vos machines virtuelles AVD, puis spécifiez le réseau virtuel adéquat :
Effectuez une joindre à Entra ID en incluant Intune ainsi que les informations d’identification du compte administrateur local, puis cliquez sur Suivant :
Définissez un nouvel 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 entièrement terminé, cliquez-ici pour continuer l’assignation des utilisateurs :
Assignez les 5 utilisateurs de test à votre groupe d’application AVD :
Assignez ces mêmes 5 utilisateurs de test AVD aux 5 machines virtuelles créés :
N’oubliez pas la configuration RDP suivante, puis Sauvegarder :
Notre environnement Azure Virtual Desktop est maintenant en place. La suite de la configuration des restriction passera par le portail Intune.
Etape II – Configuration Intune :
Rendez-vous sur le portail Intune afin de créer 4 groupes Entra ID qui serviront à tester tous les scénarios de restriction du presse-papier :
Pour chacun de ces groupes, ajoutez dans chacun d’eux une machine virtuelles AVD de test :
Consultez la liste des machines virtuelles inscrites sur Intune pour vérification :
Commencez par créer une première police de configuration Intune, par exemple la restriction maximale :
Choisissez les options suivantes, puis cliquez sur Créer :
Nommez votre profil de configuration Intune, puis cliquez sur Suivant :
Recherchez dans le catalogue les options suivantes afin de les activer, ce qui aura pour effet de bloquer dans les 2 sens le presse-papier pour tous les types de transfert, puis cliquez sur Suivant :
Cliquez sur Suivant :
Ajouter un des 4 groupes de machines virtuelles créé précédemment, puis cliquez sur Suivant :
Vérifiez les paramètres une dernière fois, puis cliquez sur Créer :
Créer les 3 autres polices en faisant varier les réglages liés au presse-papier :
Retournez sur le menu suivant afin de pousser les configurations sur les machines virtuelles AVD dès que possible :
Renseignez les champs suivants, puis cliquez sur Suivant :
Ajoutez les machines virtuelles AVD, puis cliquez sur Suivant :
Lancez la synchronisation Intune en cliquant sur Créer :
Attendez quelques minutes afin de constater l’application avec succès des différentes polices de configuration sur les machines virtuelles AVD :
Attendez quelques minutes, puis retournez sur le portail Azure afin de redémarrer les machines virtuelles AVD pour que les modifications soient prises en compte :
Constatez l’indisponibilité des machines virtuelles AVD pendant la phase de redémarrage :
Constatez la disponibilité des machines virtuelles AVD quelques minutes plus tard :
Notre environnement avec les 5 machines virtuelles AVD est prêt pour les différents tests. Dans mon cas, je vais utiliser l’application Remote Desktop afin d’exécuter en parallèle les 5 sessions de bureau à distance :
J’ai donc ouvert 5 sessions AVD pour mes 5 utilisateurs de test :
Commençons par un premier test sans aucune restriction sur le presse-papier.
Etape III – Test Presse-papier sans restriction :
Cette première machine virtuelle n’est pas présente dans groupe Entra ID et n’a donc aucune police de configuration associée :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
Aucune configuration n’est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne
Continuons avec un second test avec une restriction complète du presse-papier.
Etape IV – Test Presse-papier avec restriction complète :
Cette seconde machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
2 configurations sont présentes dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Continuons avec un troisième test avec une restriction sur le presse-papier depuis le poste local.
Etape V – Test Presse-papier avec restriction depuis le poste local :
Cette troisième machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
1 configuration est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local fonctionne
Continuons avec un quatrième test avec une restriction sur le presse-papier depuis AVD.
Etape VI – Test Presse-papier avec restriction depuis AVD :
Cette quatrième machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
1 configuration est présente dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD fonctionne
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Continuons avec un dernier test avec une restriction sur le format de donnée sur le presse-papier.
Etape VII – Test Presse-papier avec restriction sur le format de donné :
Cette dernière machine virtuelle dispose de la configuration Intune suivante :
La configuration Intune a bien été déployée sur ma machine virtuelle :
La copie d’écran de test ci-dessous nous apprend les éléments suivants :
2 configurations sont présentes dans le registre Windows
Le copier-coller d’un fichier depuis le poste local vers AVD ne fonctionne pas
Le copier-coller d’un fichier depuis AVD vers le poste local ne fonctionne pas
Le copier-coller d’un texte depuis AVD vers le poste local fonctionne
Le copier-coller d’une image depuis AVD vers le poste local fonctionne
Conclusion
La mise en place de restrictions sur le presse-papier via Intune renforcera la sécurité et son importance cruciale dans les environnements virtuels. En limitant le transfert de fichiers et certaines données sensibles, nous pouvons renforcer significativement la protection des informations.
Enfin, Intune permet de simplifier la gestion des politiques de sécurité Azure Virtual Desktop et Windows 365 via ses nombreuses règles disponibles sur étagère.
Les récentes et excellentes vidéos postées par Travis Roberts sur sa chaîne YouTube m’ont motivé de faire des tests sur différents espaces de stockages Azure. Le choix de la forme de stockage sur le Cloud est primordial, car il détermine son prix et ses performances selon vos besoins. D’ailleurs, saviez-vous qu’il existe maintenant un compte de stockage provisionné v2 de type de standard ?
Sa première vidéo, visible ci-dessous, montre les 3 modèles de facturation disponibles sur le compte de stockage Azure :
Pay-As-You-Go (PAYG)
Provisionné V1
et le tout nouveau Provisionné V2 :
Sa seconde vidéo, disponible ci-dessous, vous fournit des conseils pratiques pour assurer un fonctionnement sans souci pour FSLogix, tout en mettant en lumière les mauvaises configurations pouvant entraîner des goulots d’étranglement très frustrants au niveau des performances :
Pour rappel, plusieurs articles sur ce blog ont déjà abordé le sujet du stockage sur Azure :
Enfin, Microsoft met à disposition plusieurs pages de documentation très intéressantes sur les stockages Azure et leurs performances, dont voici quelques liens :
Dans cet article, je vous propose donc un petit exercice de test de performances de différents espaces de stockages Azure, comprenant à la fois différents types de disques managés et comptes de stockages :
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Etape 0 – Rappel des prérequis :
Peu de prérequis sont nécessaires pour réaliser les tests de performances sur des espaces de stockage Azure :
Un tenant Microsoft
Une souscription Azure valide
Dans cet article, nous allons déployer une machine virtuelle Azure, et différents types de stockage. Cela nous permettra de comparer leurs performances, avec pour socle un environnement de test commun.
Etape I – Déploiement de la machine virtuelle Azure :
Afin de tester différents types de disque, j’ai donc déployé une machine virtuelle sur Windows. J’ai choisi une machine virtuelle de type D32s v5 pour disposer de :
Une limitation haute pour le nombre maximal de disques de données
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle :
Renseignez tous les champs concernant la souscription Azure et la région adéquates :
Choisissez une image, puis taille de machine virtuelle présente dans la liste :
Renseignez les identifiants du compte administrateur local, cochez la case concernant la licence, puis cliquez sur Suivant :
Dans l’onglet dédié au stockage, ajoutez tous les disques que vous souhaitez comparer, puis cliquez sur Suivant :
Retirer l’adresse IP publique de votre machine virtuelle, puis lancez la validation Azure :
Quand la validation est réussie, lancez le déploiement de votre machine virtuelle de test :
Une fois le déploiement terminé, cliquez ici pour consulter votre machine virtuelle :
Activez les insights de votre machines virtuelles afin de récupérer quelques métriques de performance :
Configurer le stockage de ces insights sur un LOA :
Déployez également le service Azure Bastion pour vous y connecter plus facilement en RDP de façon sécurisée :
Notre machine virtuelle est maintenant déployée, nous pourrons nous y connecter quand le service Azure Bastion sera entièrement déployé.
En attendant, nous allons pouvoir continuer les déploiements des autres stockages Azure.
Etape II – Déploiement des comptes de stockages Azure :
Depuis le portail Azure, commencez par rechercher le service des comptes de stockage :
Cliquez-ici pour créer votre premier compte de stockage :
Nommez ce dernier, spécifiez le SKU voulu, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre premier compte de stockage :
Comme le montre la copie d’écran ci-dessous, j’ai créé plusieurs compte de stockage afin de comparer les éléments suivants :
Les performances IOPS bande passante
Les performances de bande passante
Les prix
J’ai donc configuré les comptes de stockage Azure selon les caractéristiques suivants :
J’ai souhaité créer autant de comptes de stockage que de partage Azure Files afin de ne pas créer d’interférences dans leurs performances :
Voici le compte de stockage avec un Azure File dont le niveau d’accès est optimisé pour les transactions :
Voici le compte de stockage avec un Azure File standard en provisionnement v2 :
Voici le compte de stockage avec un Azure File de type premium :
Voici le compte de stockage avec un Azure File dont le niveau d’accès est chaud :
Voici le compte de stockage avec un Azure File dont le niveau d’accès est froid :
Pour chacun des comptes de stockage, j’ai récupéré le script de connexion en utilisant leur clef d’accès respective afin de monter les partages en lecteurs réseaux sur ma machine virtuelle de test :
La suite se passe directement sur la machine virtuelle de test.
Etape III – Configurations des stockages :
Connectez-vous à votre machine virtuelle de test avec le compte d’un administrateur local :
Une fois connecté à votre session à distance, ouvrez le gestionnaire de disque Windows :
Le gestionnaire de disque Windows vous propose automatiquement de lancer l’initialisation des nouveaux disques de données ajoutés, cliquez sur OK :
Ajoutez un volume simple sur chacun des disques ajoutés :
Nommez au besoin les disques afin de les identifier plus rapidement :
Ouvrez Windows Terminal afin de monter les différents Azure File créés sur les comptes de stockages :
Contrôlez la présence de tous les stockages dans l’explorateur de fichier, encore une fois, renommez-les au besoin :
Etape IV – Installation de l’outil de mesure Diskspd :
DISKSPD est un outil que vous pouvez personnaliser pour créer vos propres charges de travail synthétiques. Nous utiliserons la même configuration que celle décrite ci-dessus pour exécuter des tests d’évaluation. Vous pouvez modifier les spécifications pour tester différentes charges de travail.
Microsoft recommande d’utiliser l’utilitaire DiskSpd (https://aka.ms/diskspd) pour générer une charge sur un système de disques (stockage) et … pour mesurer les performances du stockage et obtenir la vitesse maximale disponible en lecture/écriture et les IOPS du serveur spécifique.
Sur votre machine virtuelle de test, téléchargez l’exécutable via ce lien Microsoft, puis ouvrez l’archive ZIP téléchargée :
Copiez le contenu de l’archive dans un nouveau dossier créé sur le disque C :
L’exécutable se trouve dans le sous-dossier amd64 :
Les 2 étapes suivantes sont dédiées aux tests de performances des disques via l’application Diskspd. Microsoft met d’ailleurs à disposition un protocole similaire de tests juste ici :
Deux séries de tests sont conseillées pour exploiter le deux caractéristiques suivantes :
IOPS
Débit
Le changement entre ces deux séries se fera au niveau de la taille des blocs.
Etape V – Tests des IOPS des stockages Azure :
Commencez une première salve de tests pour déterminer les IOPS max pour chacun des espaces de stockage.
Ouvrez Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :
Les arguments utilisés pour diskspd.exe sont les suivants :
-d900 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b8K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
-c50G : taille du fichier 50 GB (il est préférable d’utiliser une taille de fichier importante pour qu’il ne parte pas dans le cache du contrôleur de stockage)
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-PremiumSSD.txt : fichier de sortie des résultats
Une fois tous les tests terminés, retrouvez les fichiers des résultats :
Ouvrez chacun des fichiers de résultats, puis descendez au paragraphe suivant :
Continuons avec les tests sur les débits maximums des espaces de stockage Azure.
Etape VI – Tests des débits des stockages Azure :
Continuez avec une seconde salve de tests pour mesurer les débits maximums des types de disque Azure.
Toujours sur Windows PowerShell ISE, puis lancez les commandes des test suivantes, une à une ou à la chaîne, en modifiant les paramètres si besoin :
Les arguments utilisés pour diskspd.exe sont les suivants :
-d900 : durée du test en secondes
-r : opérations de lecture/écriture aléatoires
-w100 : rapport entre les opérations d’écriture et de lecture 100%/0%
-F4 : nombre de threads max
-o128 : longueur de la file d’attente
-b64K : taille du bloc
-Sh : ne pas utiliser le cache
-L : mesure de la latence
-c50G : taille du fichier 50 GB (il est préférable d’utiliser une taille de fichier importante pour qu’il ne parte pas dans le cache du contrôleur de stockage)
E:\diskpsdtmp.dat : chemin du fichier généré pour le test
> IOPS-PremiumSSD.txt : fichier de sortie des résultats
Une fois tous les tests terminés, retrouvez les fichiers des résultats :
Ouvrez chacun des fichiers de résultats, puis descendez au paragraphe suivant :
Pour plus de clarté, j’ai synthétisé tous mes résultats de IOPS et DEBITS dans l’étape suivante.
Etape VII – Synthèse des résultats :
Voici un tableau synthétique des différentes mesures faites sur 5 essais :
v1 premier essai à la chaîne (Les IOPS, puis les DEBITS)
v2 second essai à la chaîne (Les IOPS, puis les DEBITS)
v3 troisième essai en même temps (Tous les IOPS, puis tous les DEBITS)
v4 quatrième essai en même temps (Les IOPS, puis les DEBITS)
v5 dernier essai à la chaîne (Les IOPS, puis les DEBITS)
Les performances IOPS et DÉBITS sont différentes, car les configurations des espaces de stockages sont différentes.
J’ai souhaité comparer les chiffres de Diskspd avec ceux donnés par Azure Monitor.
Pour les disques de la machine virtuelles, nous sommes sur les mêmes chiffres entre les 2 sources :
IOPS :
Débits :
Pour les comptes de stockages, c’est plus difficile à vérifier, car seuls des volumes de transactions sont disponibles en tant que métriques Azure :
Mais le compte de stockage de type v1 (premium) affiche bien les mêmes IOPS :
En revanche, pour les débits sur ce même compte de stockage de type v1 (premium), j’avais obtenu via Diskspd des chiffres correspondant à la moitié de ceux donnés par Azure Monitor :
Etape VIII – Analyse des coûts :
Tous les stockages Azure listés dans cet articles fonctionnent sur différentes grilles tarifaires. Azure Pricing Calculator nous donne malgré tout un premier point de comparaison grossier.
Le tableau ci-dessous reprend toutes les options de base des stockages Azure, sans y inclure de transactions, et en prenant que pour paramètre une taille de 1024 Go :
A titre d’information, le disque Premium SSD v2 semble meilleur marché que le disque Premium SSD quand les performances configurées sont les mêmes :
Enfin, ayant testé Diskspd de façon 100% identique sur tous les stockages testés, je trouvais intéressant de vous montrer l’impact financier via le Gestionnaire des coûts Azure.
Diskspd a donc été lancé au total 10 x 15 minutes sur les 9 espaces de stockage Azure, et cela donne les coûts suivants :
Malgré des performances très honorables, les comptes de stockages de type PAYG sont à proscrire si les opérations d’écriture et de lecture sont très fréquentes :
Coûts sur le compte de stockage froid : les opérations d’écritures représentent 99.99% du coût total !
Coûts sur le compte de stockage chaud : les opérations d’écritures représentent 99.99% du coût total !
Coûts sur le compte de stockage optimisé pour les transactions : les opérations d’écritures représentent 99.90% du coût total !
Le tarif élevé du compte de stockage standard v2 s’explique par la configuration très poussée sur ce dernier
Mais Diskspd n’aura pas été capable de les atteindre :
Quant aux disques de la machine virtuelles, leurs coûts semblent pour eux très contenus :
Et cela malgré la configuration très performante renseignée sur le disque Premium SSD v2 :
C’est à se demander si les profils FSLogix n’auraient pas leur place sur un disque Premium SSD v2, en lieu et place d’un compte de stockage Premium, mais sans oublier bien sûr d’y ajouter le prix de la machine virtuelle :
Conclusion
En conclusion, les comptes de stockage et les disques managés Azure offrent tous deux des solutions robustes et flexibles pour répondre à divers besoins de performance. Les nouvelles options de SKU permettent de personnaliser les débits et les IOPS, offrant ainsi une adaptabilité précieuse pour des exigences spécifiques. La visualisation des performances via Azure Monitor ajoute une couche de transparence et de contrôle appréciable.
Cependant, au-delà des performances, le coût reste un facteur crucial à considérer. Les frais peuvent rapidement augmenter en fonction du type de stockage et des opérations effectuées. Il est donc essentiel de garder à l’esprit les coûts associés et de toujours se référer aux caractéristiques des disques, aux options de stockage disponibles, ainsi qu’aux fonctionnalités de récupération et de réplication.
Ces éléments sont déterminants pour faire un choix éclairé et optimiser l’utilisation des ressources Azure.
Microsoft vient d’annoncer lors de l’Ignite 2024 le plan de mise à l’échelle dynamique pour Azure Virtual Desktop. Mais qu’apporte donc cette nouvelle méthode dite dynamique à cette fonctionnalité déjà existante sur Azure Virtuel Desktop? C’est ce que nous allons voir ensemble dans cet article, encore dans un état de préversion à l’heure où ces lignes sont écrites.
Mais qu’est-ce que le plan de mise à l’échelle ?
La plan de mise à l’échelle, ou autoscaling en anglais, est déjà disponible pour les environnements AVD mutualisés et individuels depuis déjà quelques temps. Deux articles parlant de ce sujet sont déjà disponibles sur ce blog :
La mise à l’échelle automatique vous permet d’effectuer un scale-up ou un scale-down de vos hôtes de session de machines virtuelles dans un pool d’hôtes pour optimiser les coûts de déploiement.
Microsoft a mis à jour sa documentation afin d’expliquer en détail les 4 grandes fonctionnalités de la mise à l’échelle dans le cadre d’un environnement AVD partagé :
Voici d’ailleurs une représentation diapo de trois d’entre elles :
Comme le montre la première animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut allumer progressivement des machines virtuelles quand une certaine limite d’utilisateurs est atteinte.
Comme le montre la seconde animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut éteindre des machines virtuelles éteintes tant celles-ci ne sont pas exploitées.
Comme le montre la troisième animation ci-dessus, la mise à l’échelle sur un environnement Azure Virtual Desktop partagé peut forcer des utilisateurs à se déconnecter que si vous avez activé ce paramètre dans la phase de descente en charge uniquement.
Grâce à ces différents mécanismes, le plan de mise à l’échelle vous permet de moduler à la hausse ou à la baisse le nombre de VMs allumées à un moment précis selon les besoins.
Mais quelles sont les 4 phases du plan de mise à l’échelle?
Vous pouvez établir un plan de mise à l’échelle basé sur :
Des créneaux horaires exprimés en heures.
Des créneaux journaliers exprimés en jours.
Tous les plannings de mise à l’échelle AVD comprennent les 4 phases suivantes :
Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session. Par exemple, si votre bureau ouvre à 9h, vous pouvez prévoir que les utilisateurs commencent à se connecter entre 8h30 et 9h.
Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Par exemple, entre 09h et 17h, la plupart des utilisateurs sont connectés et travaillent activement. De nouveaux utilisateurs peuvent se connecter, mais à un rythme plus lent que pendant la montée en charge.
Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Par exemple, entre 17h et 18h, les utilisateurs commencent à se déconnecter. Dans cette phase, vous pouvez définir un pourcentage minimum plus bas d’hôtes actifs et une taille minimale de pool d’hôtes pour réduire le nombre de VM d’hôtes de session en état de fonctionnement ou arrêtées.
Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Par exemple, après 20h, la plupart des utilisateurs sont déconnectés. De nouveaux utilisateurs peuvent se connecter pour des scénarios d’urgence, mais ces cas peuvent être rares.
Azure Virtual Desktop propose également des graphiques afin de comprendre le gain et l’efficacité du mécanisme :
Mais qu’apporte la méthode dynamique du plan de mise à l’échelle ?
Peu importe la méthode choisie, les phases et les fonctionnalités d’un plan de mise à l’échelle restent les mêmes. Mais ce qui change concerne directement les machines virtuelles AVD :
Dans la méthode dite Gestion de l’énergie : la plan de mise à l’échelle peut allumer et éteindre des machines virtuelles AVD selon les usages et la programmation mise en place.
Dans la méthode dite dynamique : la plan de mise à l’échelle peut créer ou supprimer des machines virtuelles AVD selon les usages et la programmation mise en place.
La mise à jour de l’hôte de session vous permet de mettre à jour le type de disque de la machine virtuelle (VM) sous-jacente, l’image du système d’exploitation (OS) et d’autres propriétés de configuration de tous les hôtes de session dans un pool d’hôtes avec une configuration d’hôte de session. La mise à jour de l’hôte de session désalloue ou supprime les machines virtuelles existantes et en crée de nouvelles qui sont ajoutées à votre pool d’hôtes avec la configuration mise à jour. Cette méthode de mise à jour des hôtes de session est conforme à la suggestion de gestion des mises à jour au sein de l’image source principale, plutôt que de distribuer et d’installer les mises à jour sur chaque hôte de session individuellement selon un calendrier répété continu pour les maintenir à jour.
Voici les modifications que vous pouvez apporter lors d’une mise à jour :
Cette approche de création / suppression intégrée permet donc de réduire encore plus les coûts.
Couplée avec la mise à jour de l’hôte de session, la création et la suppression de machines virtuelles AVD devient d’autant plus simple, et assure de toujours disposer de ressources Azure Virtual Desktop dans leur dernière version.
Maintenant, il nous reste plus qu’à tester tout cela 😎💪
Il est également nécessaire de renseigner un nombre maximal de sessions AVD :
Commençons par ajouter des permissions RBAC nécessaires à la gestion des VMs AVD.
Etape I – Ajout des permissions RBAC :
Le traitement de création/suppression des machines virtuelles AVD a besoin de lire la configuration gérée par le nouvelle orchestrateur en chargement de votre pool d’hôtes. Il est pour l’instant nécessaire créer un rôle Azure personnalisé afin de pouvoir récupérer ces informations.
Pour cela, rendez-vous dans le portail Azure, puis commencez sa création depuis le groupe de ressources contenant votre environnement AVD :
Nommez votre nouveau rôle personnalisé, puis cliquez sur Suivant :
Recherchez la permission suivante, puis cliquez sur lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de votre rôle Azure personnalisé :
Toujours sur votre groupe de ressources AVD, assignez à l’application Azure Virtual Desktop les 3 rôles suivant, en plus de votre nouveau rôle personnalisé :
Contributeur de mise sous et hors tension de la virtualisation du Bureau
Contributeur à la machine virtuelle de la virtualisation des postes de travail
Utilisateur de Key Vault Secrets
Une fois les droits en place, il ne reste qu’à rajouter la mise à l’échelle dynamique sur notre environnement Azure Virtual Desktop.
Etape II – Création du plan de mise à l’échelle dynamique :
Comme avant, la création d’un plan de mise à l’échelle dynamique AVD apporte les avantages / restrictions suivants :
Le plan de mise à l’échelle dynamique est utilisable pour un ou plusieurs environnement Azure Virtual Desktop, à la condition que ces derniers nécessitent une gestion horaire identique
Ne pas associer le plan de mise à l’échelle dynamique avec d’autres solutions tierces de gestion des ressources Azure
Il n’est pas possible d’associer plusieurs plans de mise à l’échelle dynamique sur un seul environnement AVD
Le plan de mise à l’échelle dynamique est dépendant d’un seul fuseau horaire
Le plan de mise à l’échelle dynamique est configurable sur plusieurs périodes distinctes
Le plan de mise à l’échelle dynamique est opérationnel dès sa configuration terminée
Avant cela, prenez le temps de vérifier la configuration de l’hôte de session AVD déjà en place :
La création du plan de mise à l’échelle dynamique se fait directement sur la page d’Azure Virtual Desktop, cliquez ici pour démarrer sa création :
Remplissez le premier onglet avec vos informations de base et indiquez que votre environnement AVD est partagé :
Choisissez l’option le plan de mise à l’échelle dynamique, puis cliquez sur Suivant :
L’onglet suivant vous permet de définir quand le plan de mise à l’échelle dynamique s’active pour suivre les besoins de montée / descente en puissance tout au long de la journée.
Cliquez comme ceci pour ajouter votre première période :
Choisissez un Nom, puis sélectionnez les Jours adéquats (les valeurs par défaut qui s’affichent lorsque vous créez une planification sont les valeurs suggérées pour les jours de la semaine, mais vous pouvez les modifier selon vos besoins) :
Les informations ci-dessous de l’onglet Général ne servent qu’à définir les valeurs reprises dans les autres onglets :
Pourcentage minimum d’hôtes actifs :exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
Par exemple, si le pourcentage minimum d’hôtes actifs (%) est fixé à 10 et que la taille minimum du pool d’hôtes est fixée à 10, le plan de mise à l’échelle dynamiqueveillera à ce qu’un hôte de session soit toujours disponible pour accepter les connexions des utilisateurs.
Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Puis cliquez sur Suivant :
Montée en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se connecter aux hôtes de session.
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.
Puis cliquez sur Suivant :
Dans mon exemple, je n’ai pas modifié les 49% indiqués sur mon environnement avec un minimum 1 et maximum de 2 machines virtuelles. Cela force AVD a :
Si le nombre d’utilisateurs AVD reste sous la limite du nombres de sessions par VM :
Conserver une seule machine virtuelle créée et allumée
Si le nombre d’utilisateurs AVD dépasse la limite du nombres de sessions par VM :
Créer et allumer la seconde machine virtuelle
Période de pointe : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de connexion stable. Il n’est possible que de modifier :
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Puis cliquez sur Suivant :
Descente en charge : C’est le moment de la journée où vous anticipez que les utilisateurs commenceront à se déconnecter et à terminer leurs sessions pour la journée de travail. Il vous est possible de modifier les champs suivant :
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Seuil de capacité : pourcentage de la capacité disponible du pool d’hôtes qui déclenchera une action de mise à l’échelle.
Forcer la déconnexion des utilisateurs : Oui / non
Pourcentage minimum d’hôtes actifs :exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée :
Limite du nombre de machines virtuelles actives : exprimée en pourcentage, cette valeur se base sur le nombre de minimal de VM AVD et détermine le nombre de machines virtuelles allumée.
Nombre min de VMs : nombre de machines virtuelles hôtes de session devant toujours faire partie du pool d’hôtes. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Nombre max de VMs : nombre de machines virtuelles hôtes de session que le plan de mise à l’échelle dynamique ne dépassera pas. Ces dernières peuvent être active ou à l’arrêt niveau OS.
Puis cliquez sur Suivant :
Hors-période : C’est le moment de la journée où vous anticipez que les utilisateurs seront en état de déconnexion stable. Il n’est possible que de modifier :
Heure de début : sélectionnez une heure dans le menu déroulant pour commencer à préparer les machines virtuelles pour les heures de pointe.
Algorithme : la préférence d’équilibrage de charge que vous sélectionnez ici remplacera celle que vous avez sélectionnée pour vos paramètres de pool d’hôtes d’origine.
Puis cliquez sur Ajouter :
Il est possible d’ajouter une second planning si besoin, mais uniquement sur les autres jours restants, sinon cliquez sur Suivant :
Sélectionnez le pool d’hôtes concerné et lancez la validation Azure :
Une fois la validation Azure réussie, lancez la Création :
Consultez le plan de mise à l’échelle dynamique :
Avant l’application du plan de mise à l’échelle dynamique, je retrouve bien 3 en nombre de machines virtuelles AVD :
Etape III – Test de suppression de VM :
Après l’application du plan de mise à l’échelle dynamique, je retrouve bien une seule machine virtuelle AVD :
Seule une machine virtuelle est bien encore présente dans mon environnement Azure :
Grâce à Azure Monitor, il est possible de consulter les actions faites par le plan de mise l’échelle dynamique :
Du côté des insights AVD, un nouvel onglet dédié au plan de mise à l’échelle a fait son apparition :
Etape IV – Test de création de VM :
Afin de vérifier la création automatique des machines virtuelles AVD, je décide de connecter un utilisateur à mon environnement afin de dépasser le seuil de capacité :
L’utilisateur est bien référencé comme connecté :
Un nouvel événement est alors visible dans la table et indiquant la création d’une seconde machine virtuelle :
Ce même événement est également visible depuis les insights AVD avec son explication textuelle :
Dans la liste des machines virtuelles de mon environnement, je retrouve bien la seconde VM en cours de création :
Azure Virtual Desktop met à jour au besoin les agents AVD sur la nouvelle machine rajoutée au pool d’hôtes :
La nouvelle machine virtuelle contient bien la dernière version disponible et son nom confirme la bonne jointure au domaine AD :
La nouvelle machine virtuelle devient alors disponible et prête à recevoir des utilisateurs AVD :
Etape V – Second test de création de VM :
Toujours dans la même phase je décide de connecter un second utilisateur AVD :
Ayant configuré un algorithme de répartition de la charge en Depth-first, le second utilisateur se retrouve sur la même machine virtuelle que le premier utilisateur :
Rien ne se passe malgré le dépassement de 50% du total car j’ai configuré un plafond de 2 machines virtuelles durant cette phase de mon plan de mise à l’échelle :
Cette analyse est confirmée ici par le 3ème événement :
Je décide néanmoins de modifier dans mon plan de mise à l’échelle dynamique les 2 valeurs suivantes :
La validation du plan de mise à l’échelle dynamique entraîne, comme attendu, la création immédiate d’une 3ème machine virtuelle AVD :
Cette analyse est confirmée par le 4ème événement :
La 3ème machine virtuelle AVD apparaît bien dans le pool d’hôtes avec un statut disponible :
Etape VI – Second test de suppression de VM :
Pour mon dernier test, je décide de déconnecter mes 2 utilisateurs de test AVD :
Les sessions Azure Virtual Desktop ouvertes disparaissent bien de la console Azure :
Et il ne reste plus aucune machine virtuelle Azure :
Cette analyse est confirmée par le 5ème événement :
A noter qu’un minimum de 0 sessions actives entraîne le message d’erreur suivant pour l’utilisateur :
Conclusion
En conclusion, nous avons découvert que ce plan permet une gestion flexible et efficace des ressources, assurant ainsi une optimisation des coûts et une disponibilité continue des services.
L’activation automatique d’une machine virtuelle supplémentaire en réponse à une demande accrue, ainsi que la réduction rapide du nombre de machines en cas de baisse d’activité, illustrent la capacité de ce service à s’ajuster en temps réel aux besoins des utilisateurs.
En somme, Azure Virtual Desktop, grâce à son plan de mise à l’échelle dynamique, propose une solution robuste pour la gestion des environnements de travail virtuels.
