Bonne nouvelle, Windows 11 est maintenant disponible en préversion depuis plusieurs semaines et on ne parle plus que de lui ! Afin de vous faire la main sur le nouvel OS proposé par Microsoft, vous pouvez dès à présent le tester sur Azure.
Dans cet article, nous allons créer ensemble une nouvelle machine virtuelle sur Windows 11 prenant le temps de parler des options possibles lors de la création, en évolution constante.
Comme à chaque fois que vous souhaitez ajouter de nouvelles ressources, vous devez préalablement disposer d’une souscription Azure. Si cela n’est pas votre cas, sachez que Microsoft propose des crédits Azure gratuits, 130 € environ, à utiliser pendant 30 jours. Cela sera largement suffisant pour créer et tester Windows 11. Vous pouvez donc profiter de cette offre en cliquant ici.
Etape I : Création de la machine virtuelle
Une fois votre souscription en place et connecté à votre portail Azure, la création de la VM peut commencer. Le bouton de création de ressource va vous aider à trouver rapidement Windows 11 :
La recherche « Windows 11 » sur la marketplace d’Azure vous indiquera différentes images disponibles pour Windows 11, selon que vous soyez en version Pro, Enterprise ou que vous construisez un environnement multisessions pour Azure Virtual Desktop :
Dans notre exemple, choisissez Windows 11 Enterprise, encore en préversion à date où cet article est écrit.
Comme pour toutes les machines virtuelles créées sur Azure, des informations de bases sont systématiquement demandées :
Onglet I : Informations de base
Souscription : rattachement de la ressource à l’arborescence Azure. La souscription correspond à une « ligne de crédit » auprès de Microsoft (CB, CSP, EA, …).
Groupe de ressources : Container logique très utile et maintenant obligatoire pour organiser les ressources Azure. De plus, une ressource ne peut pas être présente dans plusieurs groupes de ressources à la fois.
Nom de la machine virtuelle : Nom de la machine virtuelle ^^ aussi utilisé pour le nom de machine dans l’OS.
Région : Localisation physique de la machine virtuelle dans le Cloud Microsoft. Voici ici la liste de toutes les régions Azure existantes.
Option de disponibilité : permet par exemple de répartir plusieurs machines virtuelles sur différents datacenters Azure ou dans différents racks au sein d’un même datacenter. Très pratique pour créer des architectures résilientes.
Image : bibliothèque d’images préconstruites par Microsoft, ISV ou constuites par vous-mêmes via des images personnalisées.
Azure Spot instance : Apporte une réduction significative du prix en exploitant des ressources non utilisées par Azure. Ne surtout pas prendre pour des services critiques sans interruption possible !
Taille : Détermine la puissance de la machine virtuelle (CPU, mémoire vive, performances et nombre de disques) et donc le prix.
Compte administrateur : Utilisateur et mot de passe pour administrer localement la machine virtuelle.
Ports publics entrants : Restriction ou autorisation de ports ouverts sur la machine virtuelle.
Ports entrants : Propose l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP).
Licence : Case déclarative sur la juste possession de licence Windows 10, autorisant son exploitation sur plusieurs périphériques.
Onglet II : Disque(s)
Nous pouvons ici modifier la performance du disque OS, mais aussi ajouter si besoin des disques secondaires selon le besoin d’espace. Le nombre de disque dépendra aussi du SKU choisi pour cette machine virtuelle. Dans notre exemple, nous n’allons rien changer ici :
Cet onglet a son importance car il définit les interactions réseaux possibles avec la nouvelle machine virtuelle. Plusieurs options ici vont donc potentiellement créer, ou non, de nouvelles ressources Azure :
Réseau virtuel : La machine virtuelle doit obligatoirement être sur un réseau virtuel, même si ce dernier ne comporte aucune autre ressource.
Sous-réseau : Le réseau virtuel doit comporter au minimum un sous-réseau. Le sous-réseau sera utile pour segmenter et sécuriser une infrastructure. Besoin de comprendre l’adresse IP ? Cliquez-ici !
IP publique : L’IP publique n’est pas une ressource obligatoire et doit être évitée dans un grand nombre de cas pour des questions de sécurité. Dans notre exemple, cette IP publique nous sera utile pour nous connecter à cette nouvelle machine Windows 11.
Groupe de sécurité réseau : Ce composant réseau d’Azure est très pratique pour filtrer les accès entrants et sortants sur un sous-réseau. Il ne s’agit pas ici d’une solution Firewall, mais d’un filtrage par sources, ports et protocoles.
Ports publics entrants : A la différence du premier onglet, la restriction ou l’autorisation de ports ouverts définie ici concerne le groupe de sécurité réseau.
Ports entrants : Propose là encore l’ouverture des ports de management habituels (HTTP, HTTPS, SSH ou RDP)
Accélération réseau : Avec la mise en réseau accélérée, le trafic réseau arrive directement à l’interface réseau de la VM.
Equilibreur de charge : Propose d’intégrer la nouvelle machine virtuelle derrière un équilibreur de charge existant. Très pratique pour augmenter et répartir le volume de requêtes pour un site web frontal.
Onglet IV : Management
Cet onglet apporte des outils complémentaires concernant la gestion de la machine virtuelle. Cela est utile pour diagnostiquer ou résoudre les problèmes :
Diagnostiques de démarrage : Comme son nom l’indique, il est possible de conserver un journal du démarrage de la machine virtuelle, qui pourra être exploité si un jour la machine virtuelle ne démarre pas correctement.
Diagnostiques invités de l’OS : Remonte des métriques additionnelles sur de la machine virtuelle vers un compte de stockage Azure.
Identité managée : Créé et gère une identité propre à la machine virtuelle. Cette dernière pourra avoir des droits sur d’autres ressources Azure, dans le but d’éviter la création d’un mot de passe qui serait stocké sur celle-ci.
Connexion via Azure AD : Combinaison intelligente pour permettre l’authentification via Azure AD. Cela passe aussi par l’ajout de rôles sur la ressource Azure pour autoriser ou non la connexion des utilisateurs.
Arrêt automatique : Programmation d’un arrêt OS de la machine virtuelle selon un horaire, lui-même défini selon un fuseau horaire. Très pratique pour diminuer la consommation Azure et donc le coût si la machine n’est pas utilisée en 24/7. Attention, le démarrage n’est pas automatique et devra donc passer par l’ajout d’un traitement batch.
Reprise après sinistre : Même dans un Cloud, on n’est jamais à l’abri d’une panne globale d’un centre de données. La réplication d’une machine virtuelle dans une seconde région Azure est alors possible et gérée par un service dédié : Recovery Services Vault.
En plus des options de management, d’autres fonctionnalités sont encore disponibles avant la création de la machine virtuelle :
Extension : les extensions sont un moyen rapide d’apporter une couche de configuration supplémentaire. Certaines sont disponibles via la bibliothèque d’extensions, mais il est aussi possible de travailler avec des scripts personnalisées.
Données personnalisées : Propose d’ajouter des données en plus de l’image déployée. Dans le cadre d’une image Windows, ces données seront stockées dans %SYSTEMDRIVE%\AzureData\CustomData.bin.
Données utilisateurs : Les données utilisateur sont une nouvelle version des données personnalisées et offrent des avantages supplémentaires.
Hôtes dédiés : Comme indiqué sur cette page, l’hôte dédié vous donne l’assurance que seules les machines virtuelles de votre abonnement se trouvent sur l’hôte physique, donc isolées des autres. La facturation se fait alors par hôte dédié et non par machines virtuelles créées.
Groupe de placement de proximité : Regroupement logique utilisé pour s’assurer que les ressources Azure se trouvent proches les unes des autres. Les groupes de placements de proximité sont utiles pour les charges de travail où une latence faible est requise.
Génération de machine virtuelle : La génération 2 existe maintenant depuis plusieurs années. Le choix de la génération va dépendre de l’OS choisi. Ce dernier apporte des fonctionnalités comme le Secure Boot, la prise en charge d’un disque OS supérieur à 2 To…
Note :
Il est maintenant possible de créer une machine virtuelle GEN 2 bénéficiant du Trusted Launch. Pour bénéficier de cette option encore en préversion, il est nécessaire de passer par ce lien spécifique du portail Azure. Vous aurez alors accès aux options suivantes :
Attention, le Trusted lunch n’est pas accessible sur toutes les images d’OS ou en GEN1 Windows 11 PRO -> KO Windows 11 Enterprise -> OK
Pour rappel, celui fonctionne uniquement sur les machines virtuelles de seconde génération. Concrètement, ce démarrage sécurisé de la VM repose sur une version virtualisée du TPM :
Merci à Dean pour cette vidéo ????.
Onglet VI : Tags
Le tags est une information facultative mais fort pratique pour la classification des ressources Azure. Un tag est composé d’une paire nom/valeur. Il précise des informations sur les projets, les responsables, les durées de vie des ressources ou encore les utilisateurs finaux. Une ressource Azure peut contenir jusqu’à 50 tags.
Etape II : Déploiement de la machine virtuelle
Une fois toutes les options renseignées et la création déclenchée, il ne reste plus qu’à patienter quelques minutes. Il n’est pas nécessaire de rester sur la page de déploiement pendant le traitement. Une notification vous avertira du succès ou de l’échec de celui-ci.
Cette copie d’écran ci-dessus nous présente en détail les ressources créées pour cette machine virtuelle.
Un aperçu des mêmes ressources dans le groupe de ressources Azure nous indique une 6ème ressource :
Le disque OS est bien une ressource à part de la machine virtuelle. Il peut être détaché au besoin de cette dernière.
Etape III : Connexion à la machine virtuelle
Dans notre exemple, la connexion est RDP est ouverte sur notre machine virtuelle Windows 11 car nous avons autorisé l’accès RDP sur la machine, mais également sur la partie réseau d’Azure. Voici ci-dessous une vue des règles, entrantes et sortantes, ouvertes sur le groupe de sécurité, rattaché ici à la carte réseau de la VM :
L’avertissement indiqué sur la règle entrante pour le port RDP est présent pour vous alerter sur ce risque possible d’intrusion, car ouvert sur Internet.
L’accès RDP est possible directement depuis la fonction présente dans la barre d’action. Il est aussi possible d’utiliser l’adresse IP publique rattachée à la machine virtuelle :
Bastion est un autre moyen d’accès beaucoup plus sécurisé car il ne demande pas d’adresse IP publique pour chaque VM. Plus d’informations ici.
Le téléchargement et le lancement du fichier de connexion de bureau à distance vous affichera l’alerte de sécurité suivante :
Il ne vous restera alors qu’à renseigner les codes administrateurs renseignés sur le premier onglet lors de la création de la machine virtuelle :
Enfin vous y êtes ! Vous voici dans votre nouvelle machine virtuelle Azure, tourant sur Windows 11 ????
Conclusion
Pour un utilisateur déjà habitué aux machines virtuelles sur Azure, aucune différence lors de la création d’un Windows 11 sur Azure. En attendant le passage de Windows 11 en disponibilité générale, prévu pour le 05 octobre prochain, voici un article détaillé sur les nouveautés présentes dans le nouvel OS de Microsoft. Enfin voici également un test de celui-ci en vidéo :
Il ne me reste qu’à vous souhaiter une bonne lecture. N’hésitez pas à faire part de vos remarques sur Windows 11 dans les commentaires ????
La fonctionnalité d’optimisation des performances multimédia sur Azure Virtual Desktop avait été annoncée il y a déjà quelques temps. Elle est maintenant accessible pour une phase de test publique. Pour en savoir plus, voici un lien vers la documentation officielle de Microsoft.
Dans cet article, nous allons installer et tester la fonctionnalité, étape par étape, afin de mesurer l’impact sur les performances sur un environnement Azure Virtual Desktop :
Contrôle de la version de Windows Desktop Client
Création d’un nouvel environnement AVD
Assignation des utilisateurs aux machines virtuelles d’AVD
Modification des paramètres RDP
Ajout des droits RBAC sur le groupe de ressources AVD
Création d’Azure Bastion
Installation de Google Chrome
Installation de Multimedia Redirector Service
Installation des extensions sur les navigateurs Internet
Test de la solution avec et sans optimisation
Etape I : Contrôle de la version de Windows Desktop Client
Une version minimale est nécessaire pour profiter de la redirection multimédia sur votre poste local : 1.2.2222. Vous pouvez retrouver la page de téléchargement ici. Voici également le lien vers le patchlog de l’outil Windows Remote Desktop.
Comme indiqué dans la documentation Microsoft, la machine locale doit disposer de performances minimales pour effectuer la redirection multimédia dans de bonnes conditions. Microsoft met donc à disposition une liste de recommandations matérielles pour Teams.
Il est également nécessaire d’intégrer la machine locale au programme Insider. Cette action s’effectue directement depuis le Registre Windows :
Il est nécessaire de créer les entrées suivantes.
Une fois la modification du registre terminée, relancez Windows Remote Desktop pour constater qu’une nouvelle mise à jour est maintenant disponible :
Notre client Windows Remote Desktop est maintenant à jour. Retournez sur le portail Azure pour créer un nouvel environnement Azure Virtual Desktop. Passez ces étapes si vous disposez déjà d’un AVD fonctionnel sur une souscription Azure.
Etape II : Création d’un nouvel environnement AVD
Afin de faire un test de la solution sur un nouvel environnement, je vous remets ici tous les écrans de création d’AVD. Veuillez noter que nouvelles options sont apparues, nous prendrons le temps d’en parler lors de ce déploiement. Suivez si besoin ce guide étape par étape :
Utilisez la barre de recherche pour retrouver le service Azure Virtual Desktop.
La création complète de l’environnement Azure Virtual Desktop commence en cliquant ici :
Le premier onglet d’options ci-dessous défini les options de mon environnement (Pool d’hôtes) :
Le second onglet est dédié aux machine virtuelles. Notez qu’il est nécessaire de créer au préalable un réseau virtuel dans la même région Azure que votre AVD. Le processus de création ne propose pas d’en créer un :
Depuis quelques temps déjà, il est possible de se passer d’un domaine Active Directory pour AVD. Un article sur ce sujet est consultable ici.
Nouvelle option très pratique.
Le troisième onglet est consacré à l’espace de travail des utilisateurs :
Aucun changement particulier ici.
Un nouvel onglet fait son apparition pour permettre le paramétrage des options de logs et de métriques. J’en ai donc profité pour créer un espace Log Analytics Workspace, avant le déploiement de ma solution AVD :
Notez que cette nouvelle fonctionnalité ne paramètre la remontée que pour le pool d’hôtes et l’espace de travail. Il reste encore des opérations manuelles pour y intégrer les machines virtuelles.
Une fois la configuration AVD terminée, comptez environ une bonne quinzaine de minutes pour que le déploiement se fasse :
Etape III : Assignation des utilisateurs aux machines virtuelles d’AVD
Dans le cadre de mon test, j’ai souhaité assigner manuellement les deux machines virtuelles à différents utilisateurs. Je dois donc faire les deux opérations moi-même.
Avant d’assigner les utilisateurs sur les machines virtuelles AVD, il est nécessaire de rajouter ces derniers sur le groupe d’applications AVD, créé automatiquement lors de l’étape précédente :
Il est préférable de faire une assignation via un groupe.
L’assignement des utilisateurs AVD sur les machines virtuelles peut se faire sans souci juste après :
Attention : l’assignement des utilisateurs aux machines virtuelles est irrévocable !
Comme mon exemple est basé sur une intégration des machines virtuelles avec Azure AD, je suis dans l’obligation d’effectuer des étapes supplémentaires pour rendre pour AVD fonctionnel. Les étapes 4 et 5 sont donc dédiées au scénario AVD sans serveur Active Directory.
Etape IV : Modification des paramètres RDP
Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se font directement sur le pool d’hôtes d’AVD :
targetisaadjoined:i:1
La copie d’écran ci-dessus montre le paramétrages des options RDP possibles.
Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :
Etape V : Ajouts des droits RBAC sur le groupe de ressources AVD
Afin d’autoriser les utilisateurs d’Azure AD à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se font assigner directement le groupe de ressources AVD :
Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD
L’étape suivante avec Azure Bastion permet d’administrer plus facilement les machines virtuelles d’Azure Virtual Desktop. Vous pouvez déployer ce service et en profiter pour toutes les machines virtuelles présentes dans le même réseau virtuel que ce dernier. Cela marche aussi pour les VMs sur des réseau virtuels appairés.
Etape VI : Création d’Azure Bastion
Azure Bastion est un service que vous déployez et qui vous permet de vous connecter à une machine virtuelle à l’aide de votre navigateur et du portail Azure. Cette étape est facultative dans notre démonstration, mais Azure Bastion nous facilite les opérations d’installation sur les machines virtuelles d’AVD.
Schéma expliquant le principe de connexion TLS d’Azure Bastion.
La création d’Azure Bastion est très facile et se fait en seulement quelques minutes sur notre environnement de test :
Le nom du subnet d’Azure Bastion est normé et ne peut être différent de cette copie d’écran.
Quelques minutes plus tard, Azure Bastion s’est déployé sur le réseau virtuel. Rien de plus n’est nécessaire pour l’utiliser !
Azure Bastion est maintenant installé. Dans le cadre de notre test, nous allons effectuer l’opération d’optimisation sur une seule des 2 machines virtuelles AVD. Le but étant de comparer le bénéfice de la solution, avec et sans la redirection multimédia. L’étape suivante est dédiée à l’installation de Google Chrome et se fera sur les 2 VMs.
Etape VII : Installation de Google Chrome
Connectez-vous via Azure Bastion sur la première machine virtuelle :
Renseignez ici les codes admins saisis lors du déploiement d’AVD.
Voici ici le lien officiel pour installer Google Chrome.
Il faudra aussi installer Google Chrome sur la seconde machine virtuelle pour nos tests. Vous pouvez garder ouvert l’onglet d’Azure Bastion de la première machine virtuelle quand vous vous connectez à la seconde.
Etape VIII : Installation de Multimedia Redirector Service
Vous l’avez compris, l’installation du Multimedia Redirector service ne doit se faire que sur la première machine virtuelle. Vous pouvez le télécharger ici.
L’installation est assez rapide et ne comporte que quelques écrans.
Etape IX : Installation des extensions sur les navigateurs internet
Si le navigateur Google Chrome est encore ouvert sur votre première machine virtuelle, vous devriez voir le message d’alerte suivant :
L’ouverture de Microsoft Edge après l’installation de Multimedia Redirector Service doit également remonter l’alerte suivante :
Etape X : Test de la solution avec et sans optimisation
A date, la fonctionnalité de redirection multimédia sur AVD n’est pas disponible via accès Web, mais uniquement via Windows Remote Desktop. Nous voilà donc prêts à tester notre solution :
Si vous rencontrez des difficultés d’authentification lors de votre entrée dans la VM : faite un sign-out complet de Windows Remote Desktop.
La mention Insider est bien présente dans le titre de notre fenêtre de Windows Remote Desktop.
Une fois connecté dans votre session AVD avec le compte de votre premier utilisateur de test, vérifiez l’état des extensions dans les 2 navigateurs Internet :
Google Chrome et Microsoft Edge présentent aussi une case à cocher pour rendre la fonctionnalité opérationnelle sur tous les sites.
La version publique de la redirection multimédia pour Azure Virtual Desktop a limité la lecture sur YouTube. Pour tester YouTube dans le cadre du déploiement de votre organisation, vous devrez activer une extension.
Microsoft
Un tour sur YouTube permet de se rendre compte de l’impact des performances sur la machine virtuelle. Voici un lien vers une vidéo en 4K. Prenez le navigateur Internet de votre choix pour les tests :
Un petit tour dans les performances des 2 machines virtuelles pendant la lecture de cette vidéo à haute résolution montre l’impact sur les performances avec ou sans la redirection multimédia :
Sans redirection multimédia :
L’utilisation CPU est totale pour cette lecture 4K sans l’optimisation multimédia.
Avec redirection multimédia :
L’utilisation CPU est fortement diminuée pour cette lecture 4K avec l’optimisation multimédia.
Conclusion
Avant tout, l’objectif premier de la redirection multimédia n’est pas de permettre à tous les utilisateurs d’Azure Virtual Desktop de lancer des vidéos 4K YouTube en simultané. Le but ici est bien d’alléger les sollicitations en performance des machines virtuelles AVD. Imaginez l’impact sur un environnement Azure Virtual Desktop, partagé par une douzaine d’utilisateurs utilisant Microsoft Teams.
La redirection multimédia vous permet d’obtenir une lecture vidéo fluide lorsque vous regardez des vidéos dans votre navigateur Azure Virtual Desktop. La redirection multimédia déplace l’élément multimédia du navigateur vers la machine locale pour un traitement et un rendu plus rapides.
Microsoft
Merci à Freek Berson pour sa vidéo de démonstration.
Comme toujours, faites part de vos remarques sur la redirection multimédia d’Azure Virtual Desktop dans les commentaires ????
Sorti le 02 août dernier, beaucoup de personnes ont déjà eu l’occasion de tester Windows 365 en version d’essai ou via un achat de licences. A l’inverse d’Azure Virtual Desktop, ce nouveau service bureau à distance proposé par Microsoft se positionne au plus proche d’un service SaaS. De façon générale, le déploiement de Windows 365 est assez facile et rapide.
A peine sorti et déjà dans la mouise????.
Mise en place de Windows 365
La mise en place de Windows 365 a déjà été abordé dans cet article. Voici également d’autres liens très utiles :
Néanmoins, de petits blocages peuvent arriver à différentes étapes du processus de mise en place. Dans cet article, nous allons passer en revue quelques problèmes possibles et tenter d’y apporter des solutions.
Problème 1 : Impossible de commander des licences d’essai de Windows 365
Problème 2 : Windows 365 Entreprise : Erreur de check(s) sur la connexion réseau on-premise
Problème 3 : Windows 365 Entreprise : L’inscription d’Intune MDM a échoué
Problème 4 : Windows 365 Entreprise : Erreur de passerelle lors de l’ouverture de session Windows 365
Problème 1 : Impossible de commander des licences d’essai de Windows 365
Au premier jour de disponibilité de Windows 365, des licences d’essai étaient disponibles pour Windows 365. Ces licences gratuites étaient bien visibles depuis la console d’administration de Windows 365 :
3 éditions sont disponibles pour Windows 365. Plus d’informations ici.
Dans chaque des 3 éditions se trouvaient la version d’essai disponible en plusieurs tailles de Cloud PC. La durée de la licence d’essai était de 60 jours.
Chaque tenant pouvait prendre 3 tailles de Cloud PCs pour chacun des 3 éditions de Windows 365.
Présente encore il y a quelques jours, l’activation de la version d’essai affichait le message d’erreur suivant :
Gauche : message d’erreur au moment de l’achat. Droite : les licences d’essai ne sont plus visibles dans la liste.
En lieu est place de ces licences, il est malgré tout possible de découvrir Windows 365 par cette simulation. Selon les dernières informations de Microsoft :
L’achat de licences d’essai a été suspendu faute d’un immense succès.
Aucune date de réouverture n’est annoncée concernant la disponibilité des licences d’essai
Les licences d’essai déjà prises ne sont pas impactées par cette restriction
Il est recommandé de s’inscrire ici pour se tenir informer des prochaines nouveautés
Problème 2 : Windows 365 Entreprise : Erreur de check(s) sur la connexion réseau on-premise
Les licences Windows 365 Entreprise nécessitent systématiquement une connexion réseau on-premise. Mon article précédent sur Windows 365 détaille bien le processus de création de cette connexion. Vous pouvez aussi regarder la vidéo très explicative de Dean sur ce sujet :
Après la création de la connexion on-premise, Windows 365 va se charger de vérifier un certain nombre de paramètres essentiels au bon déploiement des Cloud PCs :
La première connexion est en erreur, un clic sur son status explique le détail précis de cette dernière.
Un problème d’identification sur le domaine est constaté par Windows 365. Il faut donc vérifier à nouveau les informations de domaine.
La seconde connexion a passé tous les contrôles de Windows 365. Elle peut donc être utilisée pour créer une police de provisionnement.
Note : Il existe des erreurs non bloquante, comme celle-concernant Azure AD device sync :
Comme indiqué dans cet article de Microsoft, cette erreur de synchronisation des Cloud PCs dans Azure AD peut prendre du temps. Il faut se rappeler que celui-ci s’opère avec l’agent Azure AD Connect, dont le cycle de synchronisation par défaut est de 30 minutes. Ce temps peut s’allonger si votre architecture Active Directory est repartie en différents rôles :
Si Azure AD Connect est correctement configuré avec l’option Hybrid Azure AD join, cette alerte devrait disparaître.
Problème 3 : Windows 365 Entreprise : L’inscription d’Intune MDM a échoué
Comme indiqué dans les prérequis de Windows 365 Entreprise, il est nécessaire de disposer de plusieurs licences au préalable. Windows 365 effectue une inscription MDM dans Intune.
L’erreur ci-dessous montre que la configuration MDM dans Intune est incorrect.
Les contrôles des options du tenant dans Intune indiquent clairement un problème de licence.
Problème 4 : Windows 365 Entreprise : Erreur de passerelle lors de l’ouverture de session Windows 365
L’utilisateur souhaite accéder à son Cloud PC mais rencontre une erreur lors de l’ouverture de la session Windows. Ce problème peut se produire via l’interface web ou le client Remote Desktop :
Un reprovisionnement de licence Windows 365 ou de Cloud PC n’y change rien ????.
Le Cloud PC est pourtant correctement provisionné dans Intune.
De mon expérience, le souci ici vient de l’utilisation d’un domaine managé Azure AD DS au lieu d’un domaine Active Directory. Voici un rappel des différents modèles d’identité compatibles avec les solutions de bureau à distance proposées par Microsoft :
Conclusion
Prenez le temps de lire les erreurs et de bien vérifier vos paramètres le cas échant afin de ne pas perdre trop de temps ou de motivation. Vous pouvez retrouver les documentations de gestion des erreurs ici et là. En cas de doute, il faut ne pas hésiter à reprendre la documentation initiale de déploiement disponible là. Faites part de vos remarques sur la solution Windows 365 dans les commentaires ????
Annoncé il y a plusieurs mois Windows 365, le nouveau service de bureau à distance proposé par Microsoft, est disponible depuis le 2 août dernier. Voici une courte vidéo d’introduction à la solution ainsi qu’un lien vers la documentation Microsoft :
Dans cet article, nous allons présenter Windows 365 Cloud PC en répondant à plusieurs interrogations et aussi en déployant plusieurs éditions de démonstration. Voici le lien vers la FAQ officielle de Windows 365.
Quelles sont les solutions de bureau à distance actuellement proposées par Microsoft Cloud ?
Actuellement, il existe 2 services proposant du bureau à distance via le Cloud Azure. Le choix de la solution se fait alors selon les besoins utilisateurs, du niveau de management et du mode de facturation :
Quelles sont les différences techniques entre les 2 solutions de bureau à distance ?
La principale technologie employée dernière ces 2 solutions est identique : Azure. Windows 365 se positionne comme une offre parallèle à Azure Virtual Desktop. Le tableau ci-dessous nous montre les principales différences techniques entre ces 2 services :
On peut en déduire que Windows 365 est un service managé par Microsoft qui ne requiert presque aucune compétence sur Azure.
Pourquoi proposer Windows 365 en version Business et en version Entreprise ?
Deux éditions de Windows 365 sont disponibles : Windows 365 Business et Windows 365 Entreprise.
Windows 365 Entreprise : conçu pour les grandes entreprises qui souhaitent déployer des Cloud PCs au sein de leur organisation, sans limitation de licences et via une gestion Intune
Windows 365 Business : apporte des Cloud PCs autonomes, facile à mettre en place sans exigence de management
Quelles sont les prérequis ou limites à ces 2 éditions ?
Windows 365 Entreprise : Les utilisateurs ayant un PC Windows Pro : Windows 10 Enterprise E3 + EMS E3 ou Microsoft 365 F3/E3/E5/Business Premium. Les utilisateurs n’ayant pas de PC Windows Pro : Windows VDA E3 + EMS E3 ou Microsoft 365 F3/E3/F5/Business Premium
Windows 365 Business : aucune licence préalable n’est nécessaire. Un maximum de 300 licences est possible par tenant
Quelles sont les coûts par utilisateur de Windows 365 ?
Contrairement à Azure Virtual Desktop, Windows 365 apporte un calcul et une prédiction des coûts plus simple à anticiper : cela va dépendre de la puissance allouée à l’utilisateur ????.
Voici un extrait de la liste des prix publics publiée par Microsoft.
Voici une seconde liste comparant les 3 éditions disponibles.
Existe t-il des coûts de bande passante comme pour Azure Virtual Desktop ?
Dans le cas de Windows 365 Entreprise, des coûts supplémentaires sur Azure sont à prendre en compte :
Le schéma d’architecture indiqué plus bas montre des connexions réseaux indispensables à son fonctionnement. Cette liaison est utilisée pour connecter Windows 365 à Active Directory, elle apporte aux utilisateurs l’accès à des ressources locales. La tarification Azure est donc appliquée pour l’utilisation du réseau.
Comment bien dimensionner les Cloud PCs des utilisateurs ?
Comme pour Azure Virtual Desktop, Microsoft met à disposition des recommandations de puissance selon les besoins des utilisateurs :
Si le besoin de puissance de l’utilisateur venait à changer, il est toujours possible de revoir cela :
Qu’est-ce que Windows Hybrid Benefit ?
A ne pas confondre avec Azure Hybrid Benefit, Windows Hybrid Benefit est permet de réduire le coût des licences Windows 365 Business. Les utilisateurs disposant déjà d’une licence Windows 10 Professionnel peuvent souscrire à cette licence à prix réduit. En revanche, cette option n’est pas disponible en édition Entreprise.
Que se passe t-il pour le Cloud PC si la licence Windows 365 de l’utilisateur est retirée?
Il existe une période de grâce. Elle s’étend sur 7 jours avant que l’utilisateur ne perde l’accès à son cloud PC. Re-licencier et/ou réaffecter l’utilisateur pour remettre le cloud PC dans un état Provisionné.
Comment se connecter à son Cloud PC ?
Les utilisateurs peuvent accéder à leur Cloud PC de 2 manières différentes. Il s’agit ici des mêmes moyens de connexion que ceux disponibles via Azure Virtual Desktop :
Quelles sont les régions Cloud disponibles pour les Cloud PCs Windows 365 ?
Windows 365 est un service global. Mais le déploiement de Cloud PCs n’est disponible que dans certaines régions Azure. Vous trouverez la liste ici. Aucun doute que cette liste va s’agrandir dans le temps.
Quelles sont les possibilités de backup et de reprise d’activité avec Windows 365?
A date, on manque encore d’informations de la part de Microsoft sur ces 2 services déjà disponibles sur Azure Virtual Desktop.
Quels sont les liens possibles entre une infrastructure existante et Windows 365 ?
La réponse est : cela va dépendre de la licence Windows 365 choisie. Il existe une différence importante entre les éditions Business et Entreprise. Seule la seconde permet (et exige) d’établir une liaison « réseau à réseau ».
Cela est utile dans le cadre d’infrastructure existante dans Azure ou on-premise. Cette liaison est établie avant le premier déploiement des Cloud PCs. Ce lien réseau est utilisé pour :
Joindre les Cloud PCs à un domaine Active Directory existant
Permettre un accès réseau à des ressources locales via une passerelle Azure VPN ou autre
Pour approfondir le sujet, nous allons maintenant déployer 2 environnements pour Windows 365 :
Déploiement A : Edition Windows 365 Business
Déploiement B : Edition Windows 365 Entreprise
Déploiement A : Edition Windows 365 Business
Etape I : Achat d’une licence de démonstration Windows 365 Business
L’achat d’une licence de démonstration pour Windows 365 Business est possible depuis le centre d’administration de Microsoft 365. Vous retrouvez sur cette page 2 familles de produit Business :
Windows 365 Business
Windows 365 Business (avec Windows Hybrid Benefit)
3 plans de démo sont disponibles en essai gratuit pendant 60 jours. A noter que la quantité est 25 par défaut et grisée. Vous aurez donc et dans chacun des 3 plans qu’une seule licence Windows 365 Business affectable :
2 vCPU, 4 GB, 128 GB
2 vCPU, 8 GB, 128 GB
4 vCPU, 16 GB, 128 GB
Vous pouvez rencontrer un souci lors de l’achat de licence d’essai avec le message d’erreur suivant :
Je n’ai pas encore d’information sur l’origine de cette erreur. Je pense que cela vient d’un nombre trop élevé de licences d’essai activées, dû à l’engouement pour Windows 365.
Etape II : Affectation de la licence Windows 365 Business à l’utilisateur
Une fois l’achat correctement terminé, il faut retourner sur la liste des utilisateurs du tenant pour affecter la licence d’essai Windows 365 Business à la personne de votre choix :
L’affectation de cette licence est aussi possible sur un groupe d’utilisateurs.
Et c’est bien tout ce qu’il faut faire pour la partie Windows 365 Business ????! Une fois le déploiement du Cloud PC terminé, l’utilisateur peut directement s’y connecter.
Note : Déjà dit plus haut, le management des Cloud PCs sous cette licence est limité. Pas question ici de liaison réseau à réseau, ou de management via Intune.
Etape III : Connexion de l’utilisateur à Windows 365 Business
Comme indiqué dans le jeu de questions en début d’article, plusieurs méthodes de connexion à Windows 365 existent. Dans ce premier essai, nous allons utiliser ici la page web officielle de Windows 365 :
Tableau de bord montant à utilisateurson ou ses Cloud PCs.
L’interface web apporte également l’accès à certaines ressources locales du PC.
Comme pour l’accès à Azure Virtual Desktop, une seconde authentification est demandée pour ouvrir la session Windows de l’utilisateur.
Etape IV : Contrôles du déploiement de Windows 365 Business
Le premier contrôle s’effectue directement sur le Cloud PC. Nous en apprenons un peu plus ici sur la jointure effectuée par Windows 365 :
Une fois connecté sur le Cloud PC, la commande dsregcmd /status affiche la jointure à Azure AD, mais aussi l’absence de liaison avec un domaine Active Directory.
Comme attendu, la mention AzureAdJoined à YES indique que le Cloud PC est bien enregistré dans Azure AD :
Pour finir, nous ne retrouverons pas ce Cloud PC dans la section dédiée à Windows 365 du portail Intune :
Les éditions Windows 365 Business n’ont pas cette fonctionnalité.
Déploiement B : solution Windows 365 Entreprise
La Tech Community a déjà mis à disposition une aide au déploiement pour Windows 365 Entreprise. Vous pouvez la consulter ici.
Voici un déroulé étape par étape sur mon tenant de test :
Etape 0 : Rappel des prérequis
Contrairement à l’édition Windows 365 Business, celle-ci demande plusieurs prérequis pour déployer correctement les Cloud PCs:
Licences utilisateurs : Pour les utilisateurs ayant déjà un PC en Windows Pro : Windows 10 Enterprise E3 + EMS E3 ou Microsoft 365 F3/E3/E5/Business Premium. Pour les utilisateurs n’ayant pas de PC en Windows Pro : Windows VDA E3 + EMS E3 ou Microsoft 365 F3/E3/F5/Business Premium
Licence pour l’administrateur : Licencier le ou les administrateurs des Cloud PCs via une licence Intune Service Admin
Souscription Azure : Disposer d’une souscription Azure valide avec un rôle de propriétaire pour le réseau virtuel de Windows 365
Réseau virtuel Azure : Déployer un réseau virtuel sur la souscription Azure ci-dessus. Vérifier que la configuration DNS du réseau virtuel soit faite pour utiliser un domaine Active Directory
Domaine Active Directory : Disposer d’un domaine Active Directory accessible via le réseau virtuel ci-dessus. Ce domaine peut provenir d’une architecture on-premise ou hébergé dans Azure. A date, il n’est pas encore possible de faire fonctionner Windows 365 avec Azure AD Domain Services (Etape I)
Azure AD Connect : Synchroniser les identités Active Directory avec Azure AD, mais également activer la fonction Hybrid Azure AD Join (Etape II)
Test Azure Active Directory Domain Services -> KO
J’ai voulu faire un test de jointure entre Windows 365 et Azure AD DS. Voici le domaine managé correctement déployé :
Seulement l’absence d’Hybrid Join avec Azure AD DS provoque une erreur lors du provisionnement du Cloud PC :
Etape I : Activation de la fonction Hybrid Azure AD join via Azure AD Connect
L’outil Microsoft Azure AD Connect a été conçu pour vous permettre d’atteindre et de remplir vos objectifs en matière d’identité hybride. La dernière version est téléchargeable ici.
Dans mon domaine Active Directory, j’ai déjà préparé des utilisateurs pour mon futur environnement Windows 365.
Grâce à Azure AD Connect, je retrouve bien mes utilisateurs dans Azure AD.
Un retour dans la configuration d’Azure AD Connect permet d’activer la fonction. de jointure hybride.
Une fois tous les prérequis validés, l’étape suivante consiste à prendre des licences Windows 365 Entreprise pour les utilisateurs.
Etape II : Achat d’une licence de démonstration Windows 365 Entreprise
Comme pour l’édition Business, il est possible de prendre une licence de démonstration pour Windows 365 Entreprise. Cette opération est possible depuis le centre d’administration de Microsoft 365 :
De la même façon, Les 3 mêmes plans de démo sont disponibles en essai gratuit de 60 jours :
2 vCPU, 4 GB, 128 GB
2 vCPU, 8 GB, 128 GB
4 vCPU, 16 GB, 128 GB
Comme pour l’édition Business, vous pouvez rencontrer un souci lors de l’achat de licence d’essai avec le message d’erreur suivant :
Même erreur que celle constatée lors de l’achat de licence d’essai Business.
Etape III : Affectation de la licence Windows 365 Entreprise à l’utilisateur
Une fois l’achat correctement passé, il faut retourner sur la liste des utilisateurs pour affecter la licence à la personne de votre choix :
L’affectation de cette licence est aussi possible sur un groupe d’utilisateurs.
L’affectation de la licence Windows 365 Entreprise à un utilisateur est directement visible dans la console Intune via le suivant :
L’ajout de la ligne dans cet écran est automatique et instantané.
Etape IV : Création de la connection vers le réseau on-premise
Une connexion réseau est requise pour déployer des Cloud PCs Windows 365 Entreprise. La création de cette liaison entre Windows 365 et le réseau virtuel d’Azure se fait directement depuis le portail Intune :
Le rôle de propriétaire de la souscription Azure est nécessaire pour effectuer cette liaison.
Les éléments renseignés ci-dessous sont propres à votre domaine Active Directory :
Dans mon exemple, j’ai créé une OU spécifique pour les Cloud PCs. Cette OU est prise en compte dans la synchronisation via Azure AD Connect.
Il est possible de créer plusieurs connexions réseau Windows 365 dans un même tenant.
Une fois la création réseau lancée, un check est effectué afin de vérifier que tout est en ordre.
Le processus de check peut prendre plusieurs dizaines de minutes. Voici différents résultats possibles :
Tout est bon ????.
Si la fonction Hybrid Azure AD join n’est pas activée chez vous, vous rencontrerez l’alerte ci-dessus.
Etape V : Création de la police de provisionnement
Une dernière étape de paramétrage est nécessaire dans Intune pour lier la connexion réseau avec les Cloud PCs Windows 365 Entreprise, grâce à une police de provisionnement :
Comme indiqué dans les prérequis, le compte utilisé pour créer cette police doit disposer du rôle Intune Service Admin.
La connection on-premise est obligatoire pour créer la police de Windows 365 Entreprise.
La police fait appel à des images personnalisées ou préconstruites.
L’assignation des utilisateurs à cette police doit être en cohérence avec les licences Windows 365 Entreprise précédemment affectées. Il est donc préférable dans les deux cas d’assigner via un seul et même groupe d’utilisateurs :
A ce stade, le status du Cloud PC Windows 365 Entreprise va automatiquement évoluer :
Le processus de provisionnement des Cloud PCs prend entre 20 et 30 minutes environ.
Après un laps de temps, les Cloud PCs sont provisionnés ou remontent en erreur :
Pour l’erreur sur le premier utilisateur, la fonction Hybrid Join n’a pas été correctement activée dans Azure AD Connect.
Pour le second utilisateur, tout est bon pour lui, l’étape suivante va consister à se connecter à Windows 365.
Etape VI : Connexion de l’utilisateur à Windows 365 Entreprise
Comme indiqué pour l’édition Business, plusieurs méthodes de connexion à Windows 365 sont possibles. Cette fois-ci, nous allons utiliser le client Windows Remote Desktop :
Une fois authentifié, le Cloud PC apparaît de la même manière qu’une machine d’Azure Virtual Desktop.
Comme pour Azure Virtual Desktop, une seconde authentification est demandée pour ouvrir la session Windows de l’utilisateur.
Etape VII : Contrôles du déploiement de Windows 365 Entreprise
Le premier contrôle s’effectue directement sur le Cloud PC. Nous en apprenons un peu plus ici sur la jointure effectuée par Windows 365 :
Une fois connecté sur le Cloud PC, la commande dsregcmd /status nous permet de constater la jointure à Azure AD et la liaison avec le domaine Active Directory.
Comme pour l’édition Business, la mention AzureAdJoined à YES indique que le Cloud PC est bien enregistré dans Azure AD :
Gestion des Cloud PCs via Intune.
Gestion des erreurs dans le déploiement
Microsoft met à disposition des aides concernant la résolution de souci de déploiement sur Windows 365. Vous pouvez retrouver cette documentation ici ou là. En cas de doute, il faut ne pas hésiter à reprendre la documentation initiale de déploiement disponible là.
Dean de l’Azure Academy nous propose cette vidéo très explicative sur le déploiement de l’édition Entreprise.
Conclusion
Windows 365 est une nouvelle approche de bureau à distance s’appuyant sur Azure. Nul doute que la solution va encore évoluer pour apporter encore plus de fonctionnalités et de simplicité. Faites part de vos remarques sur la solution Windows 365 dans les commentaires ????
Une nouvelle certification Azure a vu le jour en juillet 2021. Cette dernière, baptisée AZ-700, s’intéresse tout particulièrement à la gestion et la sécurisation des réseaux au sein d’Azure. A l’heure où ces lignes sont écrites, la certification est en phase BETA et pendant encore plusieurs semaines. Vous n’aurez donc pas les résultats de réussite ou d’échec après la fin de votre examen. Vous devrez attendre entre une et deux semaines après la fin de la phase BETA.
Vous pouvez consulter la page de la certification AZ-700 ici, vous pouvez télécharger le contenu détaillé de l’examen là et enfin suivre le parcours d’apprentissage Microsoft via ce lien. Sans attendre, beaucoup de guides ont déjà fleuri sur la toile. En voici donc quelques liens :
Portail Azure, créé par Microsoft et utilisé par mes petites mains ????
AZ-700 : Réactions à chaud
J’ai passé la certification AZ-700 il y a seulement quelques heures ::
J’ai eu à répondre à 59 questions, dont certaines dans deux use-cases et d’autres dans deux jeux de questions à réponses Oui/Non
Le temps règlementaire pour cet examen était 120 minutes
Voici mon ressenti sur cet examen beta :
Toutes les questions respectent bien le thème réseau.
Répartition équitable des questions sur chacune des grandes parties.
Cohérence entre le parcours d’apprentissage et les questions de la certification
Une bonne connaissance des SKUs (et de leurs différences) est nécessaire pour certaines questions. Il faut donc prendre le temps de consulter les fiches techniques.
On ne le dira jamais assez, mais il est impératif pour toute certification de niveau Associé de tester soi-même les différents services Azure / SKUs.
L’examen AZ-700 dans le détail
Voici les grandes parties de cet examen :
Design, Implement, and Manage Hybrid Networking (10% to 15%)
Design and Implement Core Networking Infrastructure (20% to 25%)
Design and Implement Routing (25% to 30%)
Secure and Monitor Networks (15% to 20%)
Design and Implement Private Access to Azure Services (10% to 15%)
Merci à Stanislas Quastana. Vue zoomée disponible ici.
Design, Implement, and Manage Hybrid Networking (10–15%)
Cette partie ne représente pas le plus gros pourcentage de cette certification. Pourtant, beaucoup de questions tournent autour du VPN d’Azure (Gateway Subnet, VPN Gateway, Local network gateway, …). Peu importe le type de connection (S2S ou P2S), la connaissance des différents protocoles (OpenVPN, SSTP ou IKEv2) et les méthodes d’authentification est requise. Prenez donc le temps de déployer différents VPNs dans Azure sur un environnement de test. Essayer aussi de combiner cela avec Azure AD, quand cela est possible.
Ayant passé beaucoup de temps dans mes révisions sur le service Azure ExpressRoute, je m’attendais à plus de question dessus ????. Il y en a bien quelques-unes. Là encore, on vous demande de maitriser les composants nécessaires, les différents SKUs et les débits possibles pour cette connexion.
Design and Implement Core Networking Infrastructure (20–25%)
Cette partie se concentre vraiment sur les réseaux virtuels. Autant vous dire qu’il s’agit d’un point majeur de cette certification. Je peux même m’avancer, sans trop me tromper, qu’absolument toutes les questions de l’AZ-700 parlent systématiquement d’un context avec un ou plusieurs réseaux virtuels. Il faut donc savoir avec précision :
Paramétrages les zones DNS privées
Paramétrages et options de peering entre les réseaux virtuels
Subnets spécifiques à certains services Azures (Bastion, Gateway, …)
Gestion et accès dans la création de points de terminaison (Privés, Services)
Caractéristiques et composants d’un Azure WAN (SKUs)
En revanche, et cela va peut-être en décevoir certains, peu de questions vraiment facile sur l’adressage même des réseaux ????
Design and Implement Routing (25–30%)
De mémoire, je ne pense pas avoir eu beaucoup de questions sur la partie routing ou NAT. A l’inverse, je peux dire que j’ai été bombardé de questions sur les services Azure suivants ????:
Je ne vous apprends rien ici, ces services sont au cœur de nombreuses architectures. Ils nécessitent d’être bien configurés selon le besoin, donc de nombreuses questions reposant principalement sur le choix du bon SKU.
Ce quim’a bien aidé dans mon cas : les exercices proposés dans le parcours d’apprentissage. Je les ai tous faits et refaits plusieurs fois et j’ai même testé des cas alternatifs par simple curiosité, et pour être sûr d’avoir bien assimilé les fonctionnalités.
Secure and Monitor Networks (15–20%)
Le monitoring est très souvent le parent pauvre dans les certifications Microsoft. Il en est même dans les tâches quotidiennes. Pourquoi s’y investir quand tout marche bien ? Car dans la vie de tous les jours, tout ne marche pas toujours bien tout le temps !
Pour le reste, les NSG sont bien présent dans cette certification. Attendez-vous donc à beaucoup de questions sur ce sujet mais aussi dans les use cases. Le WAF (Web Application Firewall) est aussi une ressource importante car elle est présente dans plusieurs services Azure. Prenez donc le temps de tester ses fonctionnalités de filtrage avec ses combinaisons conditionnelles.
Design and Implement Private Access to Azure Services (10–15%)
Il s’agit d’une des dernières parties du programme de l’AZ-700, à ne surtout pas négliger à mon avis. Les services Azure Private Endpoint et Azure Service Endpoint sont très présents dans beaucoup de questions proposant des scénarios à décortiquer. Il est donc conseillé d’avoir déployé plusieurs fois ces deux services et d’avoir pu tester leurs liaisons possibles, ou impossibles, avec les réseaux virtuels.
Enfin, la partie des App Services et Kubernetes est assez réduite dans le descriptif et n’a donc que peu de chance de se retrouver dans les questions pour votre certification.
Conclusion
Au final, il s’agit d’une certification Microsoft comme on les aime, mais aussi comme on les déteste. Le thème est très précis, mais les possibilités d’application sont immenses !
De niveau associé, cette certification n’offre aucune question sur la compréhension des grands principes des services Azure. Ici, les questions sont toutes contextualisées dans des cas d’usage demandant des connaissances approfondies avec une bonne dose de logique. Avec de l’expérience, on peut facilement isoler des réponses improbables, pour n’avoir qu’un choix final entre deux réponses.
Ne soyez pas stressé par le temps, vous en avez toujours assez ! Et aussi ne surtout pas « bâcler » pas les dernières questions ou l’ultime relecture des réponses, car vous voulez tout simplement voir le « bout du tunnel » (expérience personnelle).
Je ne m’avancerai pas sur mon résultat de cette BETA ????.
Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur cette certification ????
Attendu depuis longtemps par la communauté Azure Virtual Desktop, Azure AD Join est enfin là ! Lancé il y a seulement quelques jours en public preview, la possibilité de se passer d’un Active Directory pour environnement AVD permet d’envisager certains projets avec une architecture 100% Cloud. Dans cet article, nous allons voir ensemble cette fonctionnalité et les bénéfices apportés par cette dernière.
Point important : cette amélioration pose un souci pour l’utilisation de la gestion des profiles via FSLogix, car l’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la gestion des identités Azure AD.
Introduction
Gestion des identités sur Azure Virtual Desktop : Rappel de l’existant
Jusqu’à présent, un environnement Azure Virtual Desktop (anciennement Windows Virtual Desktop) nécessitait de joindre les machines virtuelles Azure à un domaine Active Directory. Ce domaine pouvait provenir d’un Windows Server, ayant le rôle d’Active Directory sur un machine virtuelle Azure, ou via le service de domaine managé Azure AD DS.
Merci à Dean pour cette explication claire sur la gestion des identités sous AVD.
Qu’est-ce qu’un périphérique joint à Azure AD ?
La jonction Azure AD est destinée aux organisations axées en priorité ou uniquement sur le cloud. Toute organisation peut déployer des appareils joints Azure AD, quels que soient leur taille et leur secteur d’activité. La jonction Azure AD fonctionne même dans un environnement hybride et permet l’accès aux applications et ressources locales et cloud
Attention, il est possible de joindre des machines en Windows 10 à Azure AD, à l’exception de Windows 10 Famille.
Cette jointure à Azure AD est prévu à l’origine pour des entreprises ne disposant pas d’une infrastructure Windows Server Active Directory locale.
Dans le cas contraire, il est malgré tout possible de fonctionner de manière hybride. L’avantage sera de protéger les appareils Windows 10, tout en conservant l’accès aux ressources locales qui nécessitent une authentification locale. Dans ce cas précis, nous parlerons alors des machines jointes à Azure AD hybride. Ces appareils sont joints à votre annuaire Active Directory local et à votre Azure AD.
Pourquoi se passer d’un contrôleur de domaine pour AVD ?
Le premier argument est le coût ! Beaucoup de projets Azure Virtual Desktop sont petits et concernent un petit nombre d’utilisateurs en Remote Desktop. L’ajout d’un domaine sur des VMs ou via un domaine managé augmente la facture environ plus une centaine d’euros par mois .
Enfin, la gestion des machines AVD peut également se faire via Intune (Endpoint Manager). Que vous utilisiez des machines virtuelles partagées ou individuelles pour AVD, Intune peut gérer les deux ????Un précédent article en parle et explique le processus d’intégration sur Intune pour les machines AVD partagées ici.
Vue générale des fonctionnalités d’Intune (MEM + MAM).
Déploiement d’un AVD utilisant Azure AD
On y est ! On va détailler ici, étapes par étapes, la création d’un environnement Azure Virtual Desktop en ne disposant d’aucun domaine Active Directory en place. Pour rappel, à l’heure où ces lignes sont écrites, la fonctionnalité de jointure avec Azure AD est toujours en public preview.
Etape I : Création du réseau virtuel
Habituellement, le réseau virtuel hébergeant AVD est déjà présent par le domaine existant. Dans un environnement vide, il faut donc commencer la création de celui-ci en premier :
Je prends soin de choisir la région adaptée à mon architecture AVD.
La configuration de la plage réseau et des sous-réseaux ne change pas d’un projet classique AVD. Dans mon exemple rapide, on ira au plus simple :
Une fois la création du réseau virtuel terminée, je peux passer à la création de mon environnement Azure Virtual Desktop.
Etape II : Déploiement d’Azure Virtual Desktop
Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :
Taper « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.
La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI pour réussir la jointure avec Azure AD :
Dans mon exemple, j’ai choisi un host pool composé de VMs personnelles, il est possible de le faire avec des VMs partagées.
Note : l’assignement de type automatique dans le cadre de machines virtuelles individuelles va directement affecter ces dernières aux personnes se connectant à AVD dans la mesure où ces utilisateurs y sont autorisés.
Dans l’onglet des machines virtuelles, je défini les options relatives à ces dernières. Aucune particularité concernant la jointure avec Azure AD dans la première partie :
La copie d’écran ci-dessous concernant Azure AD et connaît une évolution sur deux points :
Type de domaine à joindre : il est maintenant possible de choisir Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.
En sélectionnant Azure Active Directory, un certain nombre de champs disparaissent de la configuration de base. Plus besoin ici de renseigner un login du domaine.
La création de l’espace de travail ne change pas par rapport aux environnements AVD classiques :
Une fois tous les champs correctement renseignés, il ne reste plus qu’à lancer la création des ressources :
Une fois la création terminée, nous pouvons constater les ressources suivantes dans notre groupe de ressources :
Etape III : Affectation des utilisateurs
Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou des groupes d’utilisateurs pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par ici :
Etape IV : Ajout d’un argument RDP
Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se font directement sur le pool d’hôtes d’AVD :
targetisaadjoined:i:1
Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :
Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se font assigner directement le groupe de ressources AVD :
Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD
Etape VI : Test de la solution côté utilisateur via Remote Desktop
Une fois les étapes précédentes terminées, il ne reste plus qu’à tester le bon fonctionnent de la solution. Cela se fait en téléchargeant le client Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible là)
Application Remote Desktop
Renseigner ici un compte Azure AD présent dans le groupe d’utilisateurs AVD.
L’écran de gestion du poste arrive dans la foulée, inutile de lier votre poste local à l’identité Azure AD.
L’écran ci-dessous nous emmène sur l’environnement Azure Virtual Desktop. Ici se trouvent tous les espaces de travail affectés à l’utilisateur, dans lesquels se trouvent toutes les applications (Remote Desktop ou Remote Apps) affectées à l’utilisateurs :
Ecran du Remote Desktop PC.
Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :
Le mot de passe peut être mémorisé pour éviter la ressaisie ultérieure.
Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 10 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :
Etape VII : Test de la solution côté utilisateur via HTML 5
Il est également possible de se connecter à Azure Virtual Desktop via un navigateur internet. Pour rappel, la page d’accès est la suivante : aka.ms/wvdarmweb :
Comme pour l’application Remote Desktop, l’authentification utilise le compte Azure AD.
On se retrouve alors, de la même manière que précédemment, sur une page donnant accès aux espaces de travail et aux applications :
Une seconde demande d’authentification est demandée pour accéder à la machine virtuelle.
Etape VIII : Vérifications Azure Virtual Desktop
Vérification de la jointure sur la machine virtuelle
Afin de regarder plus en détail cette jointure, la commande dsregcmd /status sur la machine virtuelle AVD nous en dit plus :
La jointure avec Azure AD est bien là mais aucune jointure à un domaine n’est faite.
Les informations relatives au tenant d’Azure AD.
Les informations relatives à l’activation de la fonctionnalité SSO.
Vérification de l’ajout des machines virtuelles dans Azure AD
Les machines virtuelles créées par Azure Virtual Desktop sont bien retranscrites dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :
Vérification de l’ajout des machines virtuelles dans Intune
Comme j’ai coché la gestion des machines virtuelles AVD via la solution Intune, je retrouve bien mes machines virtuelles dans la console de cette dernière (lien ici)
Vérification du pool d’hôtes d’Azure Virtual Desktop
Comme cet exemple reposait sur un environnement AVD avec des machines virtuelles individuelles, je retrouve bien sur chacune un utilisateur assigné :
Etape IX : Gestion des erreurs liées à la jointure avec Azure AD
Il est possible de rencontrer des erreurs lors du déploiement de cet environnement AVD, en jointure avec Azure AD. Pour vous aider, Microsoft met à votre disposition cette page d’aide. Voici quelques exemples d’erreurs possibles :
Les machines virtuelles sont bien déployées, mais elles sont encore marquées comme indisponibles, plusieurs minutes après le déploiement d’AVD :
>> Avez-vous bien marqué à OUI la case de validation de l’environnement ?
Erreur de mot de passe de l’ouverture de la session RDP : « The logon attempt failed »
J’ai passé du temps sur cette erreur ????.
>> Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :
Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :
Cette option est également configurable via GPO. la commande rsop.msc vous permet de voir cela.
Conclusion
Comme à chaque fois, Dean de l’Azure Academy nous met à disposition une vidéo très explicative sur tout le processus de cette nouvelle fonctionnalité d’Azure Virtual Desktop :
On attend bien évidemment avec impatience la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????
La mise en place d’Azure Virtual Desktop s’accompagne de bonnes pratiques, dont une concerne tout particulièrement la gestion des profils utilisateurs. Dans cet article, nous allons détailler l’installation de la solution FSLogix sur Azure Virtual Desktop, avec différentes options possibles pouvant améliorer l’expérience utilisateur.
Les profils des utilisateurs Windows
Un profil utilisateur contient des éléments de données sur une personne, notamment des informations de configuration comme les paramètres du poste de travail, les connexions réseaux persistantes ou les paramètres d’application. Par défaut, Windows crée un profil utilisateur local qui est étroitement intégré au système d’exploitation. Dans le cadre d’un environnement multiutilisateurs, il est important de rappeler l’importance des profils utilisateurs Windows :
Profil utilisateur : Un profil utilisateur Windows est un ensemble de paramètres qui personnalisent l’environnement de l’utilisateur. Chaque compte utilisateur dispose d’un profil qui inclut un ensemble de fichiers et de dossiers qui leurs sont propres, comme le bureau, les documents, les téléchargements, la musique, les images, …
Profil itinérant : Un profil itinérant est une fonctionnalité qui permet aux utilisateurs, à partir d’un poste implémenté dans un domaine, de se connecter à n’importe quel ordinateur du même réseau du même domaine et de retrouver leur environnement « personnalisé » décrit ci-dessus. Sans la fonctionnalité de base des profils itinérants, les utilisateurs perdraient leurs paramètres et leurs documents locaux lorsqu’ils se connecteraient à différents ordinateurs du domaine.
Les produits Microsoft fonctionnent avec plusieurs technologies pour les profils utilisateurs distants, notamment :
Profil utilisateur itinérants (RUP, Roaming user profiles)
Disque de profil utilisateur (UPD, User profile disks)
Enterprise State Roaming (ESR)
UPD et RUP sont les technologies les plus fréquemment utilisées pour les profils utilisateur dans les environnements Hôte de session Bureau à distance (RDSH) et Disque dur virtuel (VHD).
La solution FSLogix
Azure Virtual Desktop recommande les conteneurs de profil FSLogix. FSLogix est société acquise par Microsoft en novembre 2018. Elle propose une solution de conteneurisation des profils utilisateurs en itinérance, utilisable dans une large gamme de scénarios sous format VHD ou VHDX. Avec FSLogix, vous allez pouvoir réaliser les actions suivantes pour vos utilisateurs :
Centralisation des profils utilisateurs Azure Virtual Desktop
Dissociation possible entre les conteneurs Office365 avec les conteneurs profils utilisateurs
Gestion des applications visibles ou non via la fonction AppMasking
Contrôle des versions JAVA
Customisation de l’installation via de nombreuses règles ou via GPO
Sans les conteneurs de profil FSLogix, OneDrive Entreprise n’est pas pris en charge dans les environnements RDSH ou VDI non persistants
Comme toute donnée devant être migrée ou installée dans le Cloud, plusieurs scénarios techniques sont possibles pour héberger ces dernières. Dans le cadre des profils FSLogix , nous pourrions envisager les solutions suivantes :
Stockage sur un compte de stockage partagé
Stockage sur un serveur de fichiers
Stockage sur un NetApp File
Intégration des profils utilisateurs d’AVD, stockés sur un Azure File share.
Peu importe la solution choisie, vous devez également décider du format du profil : VHD / VHDX.
Au travers de cette vidéo, Dean nous montre comment estimer la taille du stockage FSLogix.
OS compatibles avec FSLogix
FSLogix est compatible avec une gamme étendue de systèmes d’exploitation, en 32 ou 64 bit :
Windows 7 ou plus récent
Windows Server 2008 R2 ou plus récent
Licences FSLogix
Il n’existe pas de licence spécifique pour FSLogix mais un droit d’utilisation intégré dans un grand nombre de licence Microsoft 365. Voici la liste des licences comprenant cette éligibilité :
Lors de la connexion de l’utilisateur, un conteneur est dynamiquement attaché à l’environnement en utilisant le disque dur virtuel et le disque dur virtuel Hyper-V, pris en charge nativement. Le profil utilisateur est donc immédiatement disponible et apparaît dans le système exactement comme un profil utilisateur local.
Installation de la solution FSLogix
Comme indiqué précédemment, l’installation de la solution FSLogix est possible sur plusieurs système de stockage. Dans cet article, nous allons nous intéresser à l’installation de la solution sur un compte de stockage Azure. Avant d’aller plus loin, l’installation de la solution FSLogix va légèrement différer selon le type de domaine mis en place pour votre environnement Azure Virtual Desktop. A ce jour, la solution fonctionne avec 2 types de domaine :
Azure Active Directory Domain Services (Azure AD DS) : Azure AD DS fournit des services de domaine managé avec un sous-ensemble de fonctionnalités AD DS traditionnelles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos/NTLM.
Azure Virtual Desktop reposant sur une gestion d’identité gérée par Azure AD et synchronisé avec Azure AD DS.
Active Directory Domain Services (AD DS) : serveur LDAP (Lightweight Directory Access Protocol) qui fournit des fonctionnalités clés telles que l’identité et l’authentification, la gestion des objets, la stratégie de groupe et les approbations.
Azure Virtual Desktop reposant sur une gestion d’identité gérée par AD DS et synchronisé avec Azure AD.
Etape I : Création du compte de stockage
Peu importe l’architecture d’identité choisie, le création d’un compte de stockage est identique dans les deux cas. Plusieurs options existent lors sa création dans un objectif d’augmenter sa résilience :
Utilisation de la fonctionnalité Cloud cache via la création de 2 comptes de stockage dans des régions Azure différentes
Attention à la longueur du nom du compte de stockage ! Celui-ci doit être inférieur à 15 caractères, au risque de bloquer la jointure du compte au domaine AD DS.
La sécurité a toute sa place dans un projet Azure Virtual Desktop. Je vous conseille donc de limiter la porter de votre compte de stockage au seul réseau v-net de votre architecture.
Etape II : Ajout du compte de stockage au domaine
Une fois la création de votre compte de stockage terminée, vous allez pouvoir le paramétrer pour le joindre à votre domaine. Juste avant cette configuration, pensez également à ajouter votre adresse IP publique dans la configuration réseau du compte de stockage, afin de ne pas être bloqué par la suite :
Comme nous avons filtré la méthode de connectivité, nous devons rajouter notre adresse IP publique comme exception d’accès au compte de stockage.
En fonction du type de domaine présent dans votre projet, je vous invite à suivre la procédure de configuration correspondante à votre cas :
Scenario A : domaine managé Azure AD DS
Scenario B : domaine Active Directory Domain Services (AD DS)
Dans mon exemple, deux comptes de stockage sont créés pour vous montrer le paramétrage pour les 2 types de domaine.
Scenario A : Azure AD DS
Il s’agit de la jointure la plus facile à réaliser, puisqu’elle peut se faire directement depuis le portail Azure. Pour cela, vous n’avez qu’à rentrer dans votre compte de stockage et vous rendre sur l’option suivante :
Quelques secondes après l’activation de l’option, tout est bon ????
Une fois le compte de stockage associé au domaine managé, il ne reste qu’à ajouter les rôles RBAC Azure et les droits NTFS Windows aux utilisateurs d’AVD. Pour cela, nous allons procéder de la façon suivante :
Azure RBAC : droits d’accès via le rôle Storage File Data SMB Share Contributor via le portail Azure
Windows NTFS : droits de modification via la commande icacls
L’ajout de rôle RBAC se fait assez facilement via le portail Azure ou aussi via des commandes en PowerShell. Voici les rôles nécessaires sur le partage de fichier fslogix du compte de stockage :
L’ajout des droits NTFS demande un peu plus d’effort et doit se réaliser obligatoirement via des commandes depuis une machine jointe au domaine Azure AD DS. Pour cela, il est nécessaire de créer une machine virtuelle sur Azure et de la joindre au domaine Azure AD DS. A terme cette machine virtuelle peut être éteinte et conservée pour gérer d’autres options du domaine managé.
Une fois la machine virtuelle créée et jointe, Alexandre nous simplifie la vie avec son script ici. Pour vous aider, je vous ai préparé une découpe de ce dernier en dessous :
Rappel Important concernant le script d’ajout des droits NTFS
Avoir créé au préalable un domaine managé Azure AD DS
Avoir joint le compte de stockage au domaine managé Azure AD DS
Avoir ajouté au préalable un partage de fichier sur le compte de stockage
Disposer d’un compte ayant des droits de propriétaire sur la souscription Azure
Lancer le script depuis un compte administrateur local aussi présent dans le domaine Azure AD DS
Script PowerShell
La partie 1 du script sert à initialiser un certain nombre de variables pour la suite des prochaines commandes PowerShell. Certains éléments sont à créer manuellement avant de pouvoir les renseigner :
$SubscriptionId : ID de la souscription Azure
$ResourceGroupName : nom du groupe de ressources du compte de stockage
$StorageAccountName : nom du compte de stockage
$AzufileShareName : nom du partage de fichier créé pour FSLogix
$StorageAccountKey : clef d’accès du compte de stockage
$ADDSname : nom du domaine managé Azure AD DS
$UserGroupName : nom du groupe d’utilisateurs d’AVD
$AdminGroupName : nom du groupe d’administration d’AVD
$DirectoryID : chemin local du sous-répertoire dans le partage de fichier fslogix
$Directory : sous-répertoire dans le partage de fichier fslogix
Le partie 2 monte un lecteur réseau dans l’explorateur en utilisant une clef du compte de stockage comme identifiant. Si votre session utilisateur n’est pas administrateur, je vous conseille de lancer cette commande via une fenêtre PowerShell non-administrateur également, sous peine de ne pas voir apparaitre le lecteur réseau dans votre explorateur de fichier :
$connectTestResult = Test-NetConnection -ComputerName "$StorageAccountName.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded)
{
net use T: "\\$StorageAccountName.file.core.windows.net\$AzufileShareName" /user:Azure\$StorageAccountName $StorageAccountKey
}
else
{
Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}
La partie 3 créée le sous-dossier dédié aux profils et ajoute les droits NTFS pour que FSLogix puisse travailler correctement :
Scenario B :Active Directory Domain Services (AD DS)
Vous l’aurez compris si vous avez lu le paragraphe précédent, cette jointure nécessite un peu plus de manipulations et ne peut se faire directement depuis le portail Azure. Vous trouverez le lien vers la documentation officielle ici. Au final, les commandes d’ajout vont se faire en PowerShell. Pour aller plus vite, Alexandre nous a encore préparé un script PowerShell, disponible sur son GitHub. Ce script est téléchargeable ici, il effectue les actions suivantes :
Téléchargement et installation et lancement du module Azure
Téléchargement et installation et lancement du module Azure AD
Connection à Azure et Azure AD
Téléchargement, extraction et installation et lancement du module AzFilesHybrid
Jointure du compte de stockage au domaine AD DS
Ajout des rôles Azure RBAC sur le partage de fichier FSLogix
Ajout des droits NTFS sur le partage de fichier FSLogix
Rappel important le script ci-dessous
Avoir synchronisé au préalable votre domaine à Azure AD via l’installation d’Azure AD Connect
Disposer d’un compte ayant des droits de propriétaire sur la souscription Azure
Rajouter au prélable un partage de fichier sur le compte de stockage
Lancer ce script sur un compte de domaine AD DS et disposant des droits administrateur local
Script PowerShell
La partie 1 du script sert à initialiser les variables pour les prochaines commandes PowerShell. Certains éléments sont à créer manuellement avant de pouvoir les renseigner dans les variables :
$SubscriptionId : ID de la souscription hébergeant le compte de stockage
$ResourceGroupName : nom du groupe de ressources hébergeant le compte de stockage
$StorageAccountName : nom du compte de stockage
$AzufileShareName : nom du partage de fichier créé pour FSLogix
$StorageAccountKey : clef d’accès du compte de stockage
$domainname : nom du domaine AD DS
$OrganizationalUnitDistinguishedName : nom de l’OU du domaine AD DS
$UserGroupName : nom du groupe d’utilisateurs d’AVD
$AdminGroupName : nom du groupe d’administration d’AVD
$DirectoryID : chemin local du sous-répertoire dans le partage de fichier fslogix
$Directory : sous-répertoire dans le partage de fichier fslogix
La partie 7 utilise la clef d’accès du compte de stockage pour monter un disque réseau. Cela sert à appliquer les droits NTFS juste après.
$connectTestResult = Test-NetConnection -ComputerName "$StorageAccountName.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded)
{
net use T: "\\$StorageAccountName.file.core.windows.net\$AzufileShareName" /user:Azure\$StorageAccountName $StorageAccountKey
}
else
{
Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}
La partie 8 utilise la commande ICACLS pour modifier les droits en adéquation avec les besoins FSLogix :
Peu important le type de jointure faite durant l’étape II, l’installation de la solution FSLogix sur Windows 10 reste la même. Cette installation est généralement lancée sur une machine virtuelle servant d’image pour votre environnement Azure Virtual Desktop. Il faut donc créer, au prélable de ce script d’installation, une nouvelle machine virtuelle sur Azure avec l’OS Windows 10 multisessions.
Script PowerShell
Le script PowerShell ci-dessous installe et configure FSLogix sur votre Windows 10. Comme à chaque fois, vous pouvez lancer le script d’un seul bloc ou partie après partie. La partie 1 du script sert à initialiser les variables pour la suite des prochaines commandes PowerShell. Seule la variable ci-dessous est à renseigner :
$connectionString: Il s’agit ici du chemin complet du partage de fichier créé sur le compte de stockage. Il se découpe toujours de la façon suivante :
\\ »nom du compte de stockage ».file.core.windows.net\ »nom du partage »\ »sous-dossier »
Presque toutes les options de configurations FSLogix se font via des clefs de registre. Vous pouvez retrouver toutes les options ici. Voici un script PowerShell reprenant les plus intéressantes :
Etape IV : Préparation de l’image + création d’AVD
Je ne passerai pas plus de temps du la gestion de l’image car ce n’est pas l’objectif principal de cet article. Néanmoins, les grandes étapes pour réutiliser cette image Windows 10 dans Azure Virtual Desktop sont :
Sysprep de l’image
Désallocation de la machine virtuelle
Capture de la machine virtuelle
L’article suivant, écrit par Robin Hobo explique tous les étapes l’ensemble du processus.
Etape V : Test de la solution FSLogix
Encore une fois, le fonctionnement de la solution FSLogix est identique, que vous soyez en domaine managé Azure AD DS ou en domaine AD DS. Un test de la solution est possible une fois l’image Windows 10 utilisée dans un environnement Azure Virtual Desktop.
Environnement de départ
La copie d’écran ci-dessous montre deux AVD : un géré par AADDS et l’autre par un AD DS.
Une fois l’environnement AVD déployé sur votre souscription Azure, vous pouvez assigner un groupe d’utilisateurs pour tester FSLogix :
L’assignement d’utilisateurs ou de groupes d’utilisateurs doit se faire pour chaque pool d’hôtes AVD, au niveau du groupe d’applications.
Une fois l’assignement effectué, le lancement du client Remote Desktop fait apparaitre le ou les environnements Azure Virtual Desktop :
Scenario A : Verifications Azure AD DS
Avant le premier lancement de la session utilisateur, un tour rapide dans le partage de fichier du compte de stockage ne montre aucun profil FSLogix :
FSLogix contenant aucun profil pour l’environnement Azure AD DS, avant l’ouverture de session.
Au moment où l’utilisateur AVD s’authentifie pour la première fois sur une machine virtuelle d’AVD, le dossier se créé automatiquement sur le compte de stockage :
FSLogix contenant le profil pour l’environnement Azure AD DS après l’ouverture de session.
Scenario B : Vérification AD DS
Avant le premier lancement de la session utilisateur, un tour rapide dans le partage de fichier du compte de stockage ne montre aucun profil FSLogix :
FSLogix contenant aucun profil pour l’environnement AD DS, avant l’ouverture de session.
Au moment où l’utilisateur AVD s’authentifie pour la première fois sur une machine virtuelle d’AVD, le dossier se créé automatiquement sur le compte de stockage :
FSLogix contenant le profil pour l’environnement AD DS, après l’ouverture de session.
L’ouverture du dossier montre bien le profil de profil de l’utilisateur au format VHDX :
Conclusion
Au final, FSLogix reste une solution pratique et performante pour la gestion des profils utilisateurs pour les environnements Azure Virtual Desktop. Sa relative facilité d’installation, ses performances et ses possibilités de personnalisation font le succès de cette solution dans un grand nombre de scénarios. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????
Qui a dit que le Cloud était sans aucun danger ? Qui a dit que tout était sauvegardé nativement dans le Cloud ? De plus, on n’imagine pas non plus perdre une région entière d’Azure. Malgré tout, des contre-mesures doivent être mises en place pour prévenir le risque. Plusieurs méthodes existent déjà pour augmenter la résilience d’une infrastructure IT. Dans cet article, nous allons prendre le temps de nous intéresser à une fonctionnalité spécifique du backup d’Azure, appelée Cross Region Restore.
Comme l’indique Microsoft dans sa documentation, l’option de Restauration inter-région (Cross Region Restore) permet de restaurer des données dans la région jumelée Azure à votre site de production. Ce service est donc disponible via Azure Backup. Une coffre de sauvegarde est donc déployé dans la région de production pour gérer la passerelle des données. A l’heure où ces lignes sont écrites, cette fonctionnalité supporte les sources de données suivantes :
Bases de données SQL, hébergées sur des machines virtuelles Azure (préversion)
Bases de données SAP HANA, hébergées sur des machines virtuelles Azure (préversion)
Célèbre Viaduc de Millau en France, au-dessus des nuages.
Régions paires d’Azure
Comme indiqué par Microsoft, une région Azure comporte un ensemble d’un ou plusieurs datacenters connectés via un réseau dédié à faible latence :
Le nombre de datacenters au sein d’une région Azure est variable.
Liste des régions Azure :
Géographie
Paire régionale A
Paire régionale B
Asie-Pacifique
Asie Est (Hong Kong, R.A.S.)
Asie Sud-Est (Singapour)
Australie
Australie Est
Sud-Australie Est
Australie
Centre de l’Australie
Australie Centre 2*
Brésil
Brésil Sud
États-Unis – partie centrale méridionale
Brésil
Brésil Sud-Est*
Brésil Sud
Canada
Centre du Canada
Est du Canada
Chine
Chine du Nord
Chine orientale
Chine
Chine Nord 2
Chine orientale 2
Europe
Europe Nord (Irlande)
Europe Ouest (Pays-Bas)
France
France Centre
France Sud*
Allemagne
Allemagne Centre-Ouest
Allemagne Nord*
Inde
Inde centrale
Inde Sud
Inde
Inde Ouest
Inde Sud
Japon
Japon Est
Japon Ouest
Corée du Sud
Centre de la Corée
Corée du Sud
Amérique du Nord
USA Est
USA Ouest
Amérique du Nord
USA Est 2
USA Centre
Amérique du Nord
Centre-Nord des États-Unis
États-Unis – partie centrale méridionale
Amérique du Nord
USA Ouest 2
Centre-USA Ouest
Norvège
Norvège Est
Norvège Ouest*
Afrique du Sud
Afrique du Sud Nord
Afrique du Sud-Ouest*
Suisse
Suisse Nord
Suisse Ouest*
Royaume-Uni
Ouest du Royaume-Uni
Sud du Royaume-Uni
Émirats Arabes Unis
Émirats arabes unis Nord
Émirats arabes unis Centre*
Ministère de la défense des États-Unis
US DoD Est*
US DoD Centre*
Gouvernement américain
US Gov Arizona*
US Gov Texas*
Gouvernement américain
US Gov Iowa*
US Gov Virginie*
Gouvernement américain
US Gov Virginie*
US Gov Texas*
Note : Comme indiqué dans un précédent billet sur la région Azure Suisse Ouest, certaines régions offrent un accès restreint pour la prise en charge de scénarios client spécifiques : par exemple la récupération d’urgence. Ces régions ne sont disponibles que sur demande en créant une demande de support dans le portail Azure.
Tarification de la sauvegarde Azure et de la fonctionnalité CRR
Dans le cadre de sauvegarde de machines virtuelles Azure, Microsoft indique clairement dans sa brochure tarifaire que l’activation de la fonctionnalité CRR entraine une évolution du SKU du compte de stockage, pour permettre la sauvegarde et la lecture de vos données dans les deux régions. Pour vous aider à y voir plus clair, voici la décomposition tarifaire de la sauvegarde faite via le service Azure Backup.
Azure facture en premier lieu l’instance sauvegardée, en fonction de sa taille :
Taille de chaque instance
Tarif Sauvegarde Azure par mois
Instance inférieure ou égale à 50 Go
CHF 7,3808 + stockage utilisé
Instance supérieure à 50 Go mais inférieure ou égale à 500 Go
CHF 14,7615 + stockage utilisé
Instance supérieure à > 500 Go
CHF 14,7615 pour chaque incrément de 500 Go + stockage utilisé
L’exemple de calcul donné par Microsoft est assez clair :
Exemple : si vous avez 1,2 To de données dans une instance spécifique, le coût correspond à CHF 44,29 (+ le stockage consommé, voir plus bas). Vous êtes alors facturé CHF 14,77 pour chacun des 2 incréments de 500 Go et CHF 14,77 pour les 200 Go de données restants.
44.29 CHF = 14.76 x 3 (3 incréments de 500 Go)
Est donc également facturé le volume de données sauvegardées. On ne parle plus ici de la taille de l’instance sauvegardée, mais bien de la taille totale prise par l’ensemble des sauvegardes journalières, hebdomadaires, mensuelles et annuelles. Le volume total va alors dépendre de différents facteurs comme :
La fréquence des sauvegardes
La durée de rétention des sauvegardes
Le facteur de compression des données brutes
Selon le niveau de protection désiré, le coût du stockage au Go peut lui aussi varier :
Niveau Standard
Niveau Archive
LRS
CHF 0,0331 par Go
CHF 0,0043 par Go
ZRSPréversion
CHF 0,0414 par Go
S.O.
GRS
CHF 0,0662 par Go
CHF 0,0085 par Go
RA-GRS
CHF 0,0840 par Go
CHF 0,0085 par Go
Si vous activez l’option CRR sur votre coffre de sauvegarde, le coût au Go sera obligatoirement en RA-GRS.
Activation de Cross Region Restore
Vous êtes maintenant décidé à activer cette fonctionnalité ? Nous allons donc voir le processus d’activation de cette dernière, étape par étape, puis nous finirons par un test.
Etape I : Création d’une machine virtuelle de départ
Notre point de départ une machine virtuelle sur la région North Europe. Si vous n’avez jamais déployé de machine virtuelle dans Azure, je vous conseille de suivre le Quickstart, mis à disposition par Microsoft.
Comme indiqué dans cette copie d’écran, j’ai déployé une VM dans la région Azure « North Europe ».
Etape II : Création et configuration d’un coffre de sauvegarde Recovery Services Vault
Ce coffre de sauvegarde va nous servir pour piloter la sauvegarde de la machine virtuelle initiale. Ce coffre de sauvegarde doit être créé dans la même région Azure que la machine virtuelle, à l’inverse d’un coffre dédié à une solution de Disaster Recovery. Voici le processus de création de celui-ci étape par étape :
Utilisez la barre de recherche pour créer cette nouvelle ressource.
Renseignez les champs ci-dessous pour terminer la création de votre coffre de sauvegarde :
Pensez donc à positionner votre coffre dans la même région Azure que votre machine virtuelle.
Une fois que votre coffre de sauvegarde est créé, vous allez pouvoir activer la fonctionnalité de Cross Region Restore via le propriété de configuration de ce dernier :
Cette opération est à faire avant la mise en place de sauvegarde.
Deux options sont ici présentes dans la configuration du coffre de sauvegarde :
Type de réplication (LRS / ZRS / GRS) : nous parlons ici du nombre total de copies des sauvegardes et de leur localisation géographique sur l’infrastructure Azure
Cross Region Restore : Oui / Non
Important : ces options sont uniquement modifiables avant le démarrage de la première sauvegarde. Cela n’est plus possible de les changer après.
Etape III : Activation et démarrage de la sauvegarde
Une fois les options paramétrées, nous allons activer la sauvegarde de la machine virtuelle initiale. L’opération peut se faire depuis le coffre de sauvegarde ou directement sur la machine virtuelle :
L’écran suivant commence par détailler la police de sauvegarde à appliquer pour cette machine virtuelle. Il est question ici de définir le nombre de sauvegardes à faire et de leur rétention. Aucune police n’est créée à l’origine, vous pouvez donc la configurer directement via ce processus :
Par défaut, seule une sauvegarde journalière est définie. Elle sera conservée pendant 30 jours.
L’ajout de sauvegardes aura un impact sur le coût total de la sauvegarde. Une rétention plus longue augmente le coût.
Une fois la police créée, il est maintenant temps de sélectionner la machine virtuelle initiale pour continuer pour votre test :
Seules les machines virtuelles créées dans la région North Europe seront présentées dans cette liste de choix.
L’activation de la sauvegarde provoque la création automatique de ressources Azure :
Ce processus est rapide 🙂
Un retour dans le coffre de sauvegarde indique les objets sauvegardés et donc la bonne prise en compte de notre machine virtuelle initiale.
Note : Vous pouvez déjà apercevoir ici un filtre sur l’affichage de la première ou de la seconde région Azure.
Un clique sur la ligne « Azure Virtual Machine » affiche la machine virtuelle sauvegardée et le statut actuel de l’état de sauvegarde de cette dernière :
Un avertissement est présent car la première sauvegarde journalière n’a pas encore été faite. Cette sauvegarde sera déclenchée selon la police de sauvegarde.
Afin d’aller plus loin dans notre démonstration de la fonctionnalité CRR, nous allons devoir déclencher la première sauvegarde manuellement :
Cette sauvegarde est déclenchée manuellement, la durée de rétention est modifiable.
Le schéma ci-dessous nous montre l’étape de création du snapshot, faite au moment de la sauvegarde. Celui-ci reste à « proximité » des disques de la machine virtuelle. Les données seront transférées au coffre de sauvegarde ultérieurement.
Vous pouvez suivre l’avancement de la sauvegarde en consultant les jobs de sauvegarde. Le processus de sauvegarde initial est rapide, mais le transfert de données vers le coffre prend un peu de temps :
Une heure plus tard, la première sauvegarde de ma machine virtuelle est entièrement terminée et transférée vers le coffre de sauvegarde :
Le snapshot est fait et les données de sauvegarde ont bien été transférées au coffre de sauvegarde.
L’écran ci-dessous indique que l’avertissement précédent a disparu et que la sauvegarde faite manuellement est de type « Application consistent ».
Les sauvegardes cohérentes dans les applications capturent le contenu et les opérations d’E/S en attente de la mémoire. Les instantanés de cohérence d’application utilisent l’enregistreur VSS (ou un pré/post-script pour Linux) pour vérifier la cohérence des données d’application avant une sauvegarde.
Cohérence du système de fichiers
Les sauvegardes cohérentes de système de fichiers assurent la cohérence en prenant une capture instantanée de tous les fichiers au même moment.
Cohérence en cas d’incident
Des instantanés de cohérence des incidents sont pris généralement si une machine virtuelle Azure s’arrête au moment de la sauvegarde. Seules les données déjà présentes sur le disque au moment de la sauvegarde sont capturées et sauvegardées.
Un retour dans le coffre de sauvegarde nous montre un premier travail effectué dans la seconde région Azure :
Un clic sur l’objet donne toutes les informations relatives aux sauvegardes :
La sauvegarde étant faite ce matin, le point de sauvegarde n’est pas encore transposé sur la seconde région Azure. Il va falloir faire preuve de patience pour finir la restauration de la machine virtuelle sur la seconde région Azure :
Etape IV : Préparation à la restaurationde la machine virtuelle
L’objectif de ce Cross Region Restore est bien de créer une nouvelle machine virtuelle dans la seconde région Azure. Vous trouverez toutes les informations relatives à restauration ici. En attendant de pouvoir avancer sur la restauration, j’en profite pour créer un compte de stockage, nécessaire à la future restauration.
Afin de faciliter la lecture ultérieure au travers du portail Azure, je vous conseille de créer les prochaines ressources dans un nouveau groupe de ressources, lui-même placé dans la seconde région Azure. Ce compte de stockage doit donc être créé de la façon suivante :
Le compte stockage doit être sur la seconde région Azure, de performance Standard et en redondance LRS.
Etape V : Restauration de la machine virtuelle sur la seconde région Azure
Quelques heures plus tard, je suis enfin en mesure de continuer l’opération de restauration. Je retourne donc sur le coffre de sauvegarde pour constater que la seconde région comporte bien le premier point de restauration :
Un nouveau clique sur l’item « Azure Virtual Machine » montre le premier point de restauration transféré entre les deux régions.
L’opération de transfert entre les régions aura donc pris plusieurs heures, mais s’est fait de manière transparente.
Note : La restauration ne peut se faire que si certaines ressources sont déjà en place dans la région de destination. Nous avions déjà vu dans l’étape précédente la création d’un compte stockage, utilisé en tampon. A celui-ci, il faudra également créer un réseau virtuel, pour relier la nouvelle machine virtuelle :
Pensez donc à créer le VNet au préalable pour terminer cette restauration.
Afin de suivre l’avancement de la restauration, un tour dans les travaux du coffre de sauvegarde permet d’obtenir plus d’informations :
Les jobs de CRR ne se trouvent pas dans la page principale, mais dans la liste de travaux de la région secondaire.
Cette opération prend quelques dizaines de minutes.
Ce processus n’est pas aussi rapide qu’un failover déclenché par Azure Site Recovery. Son objectif est lui aussi différent.
Le processus de restauration aura donc pris une peu moins de 30 minutes.
Afin de constater la création des nouvelles ressources Azure, je retourne sur le nouveau groupe de ressources créé sur « West Europe ». J’y constate la présence d’une nouvelle machine virtuelle et de toutes ses ressources associées :
Toutes les ressources présentes ici sont bien positionnées sur la seconde région Azure.
La nouvelle machine virtuelle est bien opérationnelle.
Un essai de connexion RDP est possible :
Les codes d’administration sont les mêmes que ceux renseignés sur la machine virtuelle initiale.
Je retrouve bien la session d’administration ????.
Conclusion
Au final, la fonctionnalité Cross Region Restore d’Azure Backup fonctionne très bien entre région Azure. C’est une solution pour repartir en cas de désastre. A ne pas confondre avec une véritable solution de Disaster Recovery, elle permet par contre de conserver une meilleur contrôle des sauvegardes faites par Azure Backup.
Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Backup ????
Dans cet article, nous allons détailler l’outil appelé Azure Resource Mover et regarder les étapes nécessaires à la migration de ressources Azure d’une région A à une région B.
Qu’est-ce qu’Azure Resource Mover ?
Microsoft a mis à disposition un outil très pratique, appelé Azure Resource Mover. Cet outil vous sera utile si vous souhaitez déplacer des ressources d’une région Azure à une autre. Vous trouverez l’article de documentation Microsoft via ce lien.
Voici également un petit rappel sur « Qu’est-ce qu’une région Azure ?«
Région Azure : Une région Azure est un ensemble de centres de données, déployés dans un périmètre défini par la latence et reliés par un réseau régional dédié. Avec plus de régions mondiales que tout autre fournisseur de cloud, Azure offre à ses clients la flexibilité de déployer des applications là où ils en ont besoin. Une région Azure a une tarification et une disponibilité de service distinctes.
Carte des régions Azure à travers le monde. Cette carte évolue très régulièrement.
Qu’apporte Azure Resource Mover dans un processus de migration intra-région ?
Ce nouvel outil facilite grandement le processus de migration puisqu’il fournit une interface unique avec un système d’étapes et de contrôle des dépendances. Cela permet donc de :
Réduire la complexité et le temps de migration
Identifier les dépendances des ressources Azure
Déplacer les ressources de manière groupée
Nettoyer automatiquement les ressources dans la région initiale
Fonctionner en mode Test : vous pouvez encore annuler si vous ne souhaitez pas effectuer la migration
Les autres types de migration sur Azure
Il existe des besoins autres que la migration sur une autre région. Microsoft met donc à disposition deux autres types de migration :
Déplacement de ressources Azure sur un autre groupe de ressources
Déplacement de ressources Azure sur une autre souscription Azure
Ce dernier cas peut s’avérer intéressant si l’on souhaite justement abandonner le paiement PAYG (Pay-As-You-Go ou encore appelé paiement à la demande par carte bancaire) pour s’orienter vers d’autres canaux de distribution, tels que le CSP ou encore EA.
Grandes étapes
Voici la liste des grandes étapes que vous allez déclencher dans Azure Resource Mover :
Dans certains cas et également dans mon exemple plus bas, il est possible de relancer l’étape 4 à plusieurs reprises sous forme de cycle. Azure Resource Mover apporte donc une excellente visibilité sur les étapes et les cycles restants et leur ordonnancement.
Liste des ressources migrables avec Azure Resource Mover
À l’aide de Resource Mover, vous pouvez actuellement déplacer les ressources suivantes d’une région à une autre :
Machines virtuelles Azure et disques associés
Cartes réseau
Groupes à haute disponibilité
Réseaux virtuels Azure
Adresses IP publiques
Groupes de sécurité réseau
Équilibreurs de charge internes et publics
Bases de données Azure SQL et pools élastiques
Note : Vous ne pouvez pas sélectionner des disques managés comme ressources à déplacer entre des régions. Les disques sont cependant copiés lors d’un déplacement d’une machine virtuelle. Vous pourrez retrouver la liste complète avec tous les types de ressources Azure ici, accompagnés des 3 possibilités de migration.
Processus de migration via Azure Resource Mover.
Etape I : Création du projet de migration
Cette étape s’effectue directement dans le groupe contenant des ressources Azure à migrer. Il suffit alors de sélectionner les ressources et d’utiliser la fonction correspondante dans la barre d’action.
Pour simplifier les étapes, il est préférable de regrouper au préalable toutes les ressources à migrer dans un seul et même groupe de ressources.
L’écran suivant nous présente les informations de base sur les ressources sélectionnées et nous demande également de choisir la région de destination.
Il est indiqué dans les annotations que la migration des ressources sur une autre souscription peut être faite dans un second temps. Prenez donc le temps de la réflexion sur votre meilleur « itinéraire de migration ».
L’écran ci-dessous reprend la liste des ressources précédemment sélectionnées dans le groupe de ressources :
Dans mon exemple, une ressource est manquante dans cette liste, je peux cliquer sur le lien pour avoir plus d’informations.
Un encadré s’ouvre à droite et liste les ressources exclues par Azure Resource Mover. Cette information est précieuse car elle vous permet directement d’écarter ou de repenser certains projets de migration.
Pas d’inquiétude dans mon cas puisque le disque rattaché à ma machine virtuelle sera bien copié.
La confirmation sur l’écran suivant va lancer le projet et de vous proposer le démarrage de la phase suivante, déclenchée elle aussi à votre demande :
Ce bouton ne déclenche aucun traitement irréversible 🙂
Une fois ce traitement validé, l’étape II va pouvoir être déclenchée dans Azure Resource Mover.
Etape II : Configuration des ressources de destination
Cette étape est facultative. Elle permet néanmoins d’effectuer des modifications aux ressources créées. Dans mon exemple, je dispose d’une machine n’ayant pas de zone de disponibilité. Je veux migrer cette machine virtuelle en lui précisant sur quelle zone de disponibilité je la souhaite : Région « North Europe Zone 3 ».
Un clique sur la configuration de la machine virtuelle m’ouvre l’écran ci-dessous.
Je spécifie ici la zone 3 au sein de la région North Europe.
Je profite également pour faire une modification sur l’adresse IP publique rattachée à ma machine virtuelle. Souhaitant mettre en place cette VM dans une de zone de disponibilité, je dois changer le SKU de cette dernière en Standard pour que la migration se fasse sans souci :
Changement de SKU pour l’adresse IP publique en standard.
Etape III : Validation des dépendances
Comme dans beaucoup de cas, les ressources Azure sont interconnectées entre elles. L’exemple le plus évident est bien la machine virtuelle. De base, une machine virtuelle créé les ressources Azure suivantes :
Machine virtuelle
Disque OS
Carte réseau
Disque de données (facultatif)
Groupe de sécurité réseau (facultatif)
Adresse IP publique (facultative)
Le processus de validation des dépendances va donc vérifier que rien n’est oublié dans ce projet de migration.
A partir de cet écran et comme indiqué en haut à gauche, nous sommes bien dans Azure Resource Mover.
Une fois la validation des dépendances effectuée, il arrive que certaines erreurs remontent afin d’être résolues avant la migration. Un clique sur le lien vous donne toutes les informations nécessaires pour les comprendre.
Dans le cas présent, cette erreur est considérée comme « normale » puisque cette alerte concerne le disque OS. Le processus va se donc régler de lui-même cette erreur par la suite.
D’autres erreurs peuvent aussi remonter. Ici par exemple une migration vers l’Asie m’est bloquée à cause de la taille de ma machine virtuelle.
Etape IV : Migration
Comme vous le voyez dans la colonne Status sur toutes mes ressources Azure, il est indiqué que ces dernières sont en attente de la préparation au déplacement. Dans mon exemple de machine virtuelle, je dois effectuer la migration en deux cycles pour palier l’erreur du disque managé :
Cycle A : migration du groupe de ressources uniquement
Cycle B : migration des autres ressources
Cycle A – Préparation à la migration
Il s’agit de la première étape de la migration à proprement parlé.
Je commence donc mon cycle A avec uniquement mon groupe de ressources et clique sur Prépare.
Pour continuer, je clique sur Prépare.
A ce moment-là et après un court traitement de la part d’Azure, je constate que le statut de mon groupe de ressources a changé :
Le statut est passé de Prépare à Initialisation de la migration.
Cycle A –Initialisation de la migration
Je continue donc le processus de migration du groupe de ressources en le sélectionnant à nouveau et en cliquant sur Initier la migration :
L’erreur sur la machine est toujours présente mais cela ne gêne pas en soi.
Peu de choix sont possibles sur les écrans de confirmation 🙂.
Une fois l’initialisation lancée, je peux déjà constater la création d’un nouveau groupe de ressources sur ma région de destination :
La présence d’un second groupe de ressources est aussi constatée sur la région de destination.Le statut est passé d’Initialisation de la migration à Confirmation de la migration.
Cycle A –Confirmation de la migration
Cette dernière étape est nécessaire pour valider la migration des ressources sélectionnées. Je reste donc sur mon groupe de ressources et la déclenche dans la foulée :
Azure Resource Mover créé dans cette étape de nouvelles ressources. On retrouve dans le groupe de ressources de destination le disque qui sera utilisé pour la nouvelle machine virtuelle :
Le disque de la machine virtuelle est lui aussi créé dans le futur groupe de ressources.
De plus, d’autres ressources sont créées dans le second groupe vu précédemment. Ce groupe de ressources va donc servir à la transition des données de la machine virtuelle :
Est présent dans ce groupe un coffre et un compte de stockage pour le cache de transition.Le groupe de ressources a encore changé de statut. L’erreur sur la machine virtuelle a disparu.
Je vais pouvoir attaquer le cycle B avec les autres ressources à migrer. J’effectuerai la suppression de toutes les ressources sur la région initiale une fois que la migration sera entièrement terminée.
Cycle B – Préparation à la migration
Comme pour le premier cycle, nous répétons les mêmes étapes avec les autres ressources Azure que nous souhaitons migrer.
Vous ne pouvez pas vous tromper dans les étapes à suivre.
L’étape de préparation prendra plus de temps que lors du cycle A.
Cycle B – Initialisation de la migration
En seconde étape, je continue le processus de migration en sélectionnant les ressources et en cliquant sur Initier la migration :
Une fois cette étape terminée, un tour dans le nouveau groupe de ressources montre que les autres ressources sont venues se rajouter au disque. A noter que la copie d’écran ci-dessous nous montre maintenant deux disques dont un appelé réplica :
La présence de 2 disques nous rappelle le fonctionnement d’Azure Site Recovery dans le cadre d’un DR.
Cycle B – Confirmation de la migration
Nous lançons donc la dernière étape encore une fois pour valider la migration des ressources sélectionnées :
Un rapide contrôle dans la liste des machines virtuelles nous montre que la VM de la première région a bien été éteinte, tandis que celle dans la seconde région est maintenant allumée :
Point important : L’adresse IP publique de la seconde machine virtuelle dans la seconde région ne sera jamais identique à la première. Les adresses IP publiques ne se transfèrent pas entre régions. Il s’agit ici d’une nouvelle adresse IP publique.
Un second contrôle sur la machine virtuelle de la seconde région indique bien la zone 3, comme paramétré dans Azure Resource Mover.
Etape V : Suppression des ressources
La dernière étape de ce processus de migration comprend la suppression des anciennes ressources encore présentes dans la première région. Elle peut être faite via Azure Ressource Mover ou directement via le groupe de ressource en lui-même :
A ce point, toutes les ressources présentes ici se retrouve dans le même status final.
Le message d’erreur vous indique que le groupe de ressources initial ne peut être supprimé via Azure Ressources Mover :
Vous pouvez malgré tout continuer cette étape de suppression avec les autres ressources.
Les ressources sélectionnées précédemment ont donc terminé le processus d’Azure Resource Mover :
Il ne reste plus qu’à s’occuper du groupe de ressources.
Une suppression manuelle reste donc à faire dans la première région Azure :
Le groupe de ressources non supprimé contient encore la dépendance de la machine virtuelle pris en compte par Azure Resource Mover.
Une seconde suppression est également à faire pour entièrement terminer le processus. il s’agit ici du projet créé par Azure Resource Mover, mais aussi du compte de stockage et du coffre créé pour assurer la copie des données du disque de la machine virtuelle entre les deux régions.
A noter que la suppression de l’ensemble ne peut se faire qu’après le retrait des verrous posés sur les ressources :
Conclusion
Au final, Azure Resource Mover est un très bon outil de migration entre différentes régions Azure. Gardez encore en tête que certaines limitations subsistent et que les migrations très complexes à étapes sensibles seront peut-être gérées en dehors de cet outil.
Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Resource Mover ????
La mise en place d’Azure Windows Virtual Desktop s’accompagne de bonnes pratiques, dont plusieurs sont dédiées à Microsoft Teams. Dans cet article nous allons détailler l’installation de Microsoft Teams sur Azure Virtual Desktop, ainsi que la mise en pratique de quelques options pouvant améliorer l’expérience des utilisateurs.
Installation de Microsoft Teams
Une des premières bonnes pratiques concernant Azure Virtual Desktop est de travailler avec des images de l’OS. L’image de votre OS va vous permettre de maîtriser vos déploiements en les sécurisant et en les automatisant.
Il est donc conseillé d’installer Microsoft Teams sur votre image, avant de commencer le déploiement des ressources dédiées à AVD. Sachez que l’installation de Teams n’est pas comprise dans les images Windows 10 multisessions avec les applications Office 365, mises à disposition par Microsoft. Cette installation est donc systématiquement à part. Un lien vers la documentation Microsoft dédiée à ce sujet est toujours utile pour vous aider dans cette mise en place.
Etape 0 : PrérequistechniquesTeams
Comme indiqué par Microsoft, il est nécessaire d’installer sur Teams sur une machine virtuelle ayant à minima les performances suivantes :
Paramètre
Système d’exploitation de station de travail
vCPU
2 cœurs
Mémoire RAM
4 Go
Stockage
8 Go
Note : A contrario, il est également dit par Microsoft qu’Azure Virtual Desktop recommande des machines virtuelles à 4 coeurs.
Etape I : Activation de l’optimisation Teams pour AVD
Cette étape est essentielle dans l’installation de Teams dans un environnement Windows 10 multisessions. Les machines virtuelles d’AVD n’ont souvent peu de puissance graphique, ce qui signifie que l’exécution d’un chat vidéo entraînera une consommation élevée de CPU et conduira à des problèmes de performance.
Même en passant à un chat vocal, la qualité de l’appel peut encore être mauvaise et la consommation de CPU trop élevée. Les organisations déploient souvent AVD dans une capacité multi-utilisateurs. Cela signifie que plusieurs utilisateurs accèdent à une même machine virtuelle et qu’ils partagent donc un processeur. Les administrateurs informatiques peuvent aider à résoudre les problèmes liés à l’épuisement du processeur grâce à la redirection audiovisuelle (AV).
La redirection audiovisuelle utilise la puissance des appareils des utilisateurs finaux pour charger les chats vidéo et vocaux. Cela signifie que les utilisateurs s’appuieront sur le CPU et le GPU de leur appareil pour charger le chat et que la machine AVD n’aura plus une consommation CPU élevée. De plus, l’interface utilisateur sera considérablement améliorée car la qualité de l’audio-visuel sera presque la même que celle des équipes locales. Pour activer l’optimisation des médias pour Teams, ajouter la clé de registre suivante sur l’image AVD :
Exécuter cette commande PowerShell en administrateur.
Vous pouvez déployer l’application de bureau Teams pour AVD en utilisant une installation par machine. Pour installer Microsoft Teams, le script ci-dessous va vous aider en installant les 3 composants suivants :
L’installation de Teams se termine et aucun redémarrage n’est nécessaire après l’exécution de ce script. Vous devriez pouvoir vous connecter directement à Teams et cliquer sur votre image pour vérifier sa bonne installation AVD.
Ce contrôle de l’optimisation Teams pourra se faire directement via un utilisateur dans l’environnement AVD.
Comme à chaque fois, merci à Dean pour ses vidéos bien pratiques.
Etape III : Optimisations possibles sur Teams
Certaines optimisations post-installation sur Teams peuvent intéressantes selon les souhaits de configuration ou si un manque de performances est constaté par vos utilisateurs.
Désactivation de l’accélération matérielle
Dans certains cas, il a été constaté que la désactivation de l’accélération matérielle augmentait les performances vidéo de Teams. Cette fonctionnalité est désactivable directement depuis les paramétrage de l’outil client, via une clé de registre ou encore via un règle GPO :
Un redémarrage de Teams est nécessaire après avoir coché la case dans les paramètres.
Seconde méthode, la clef de registre ci-dessous va désactiver la fonction quand sa valeur est égale à 1 :
Dernière méthode, la création de GPO pour FSLogix nécessite la récupération des fichiers ADMX et ADML. Vous pouvez effectuer cette étape d’installation via ce lien.
Désactivation du « receive segment coalescing » RSC sur la partie réseau
Dans d’autres cas, il a été constaté que la désactivation de l’option de recombinaison des paquets réseaux rétablissait les performances vidéo de Teams. Cette fonctionnalité est désactivable directement via une ligne de commande PowerShell :
Get-NetAdapterRSC
# Chercher le nom de l'adaptateur réseau primaire utilisé par AVD
Disable-NetAdapterRSC -Name "Nom de l'adaptateur réseau"
Redirection du cache Teams hors du profil utilisateur FSLogix
Note : Cette fonctionnalité n’est possible que si vous avez installé FSLogix au préalable sur votre image. Suivez l’étape ci-dessous si ce n’est pas encore le cas dans votre environnement. Si FSLogix est déjà en place et fonctionnel, passez à la suite.
Le script PowerShell ci-dessous installe et configure FSLogix. Vous pouvez retrouver toutes les options de la solution FSLogix ici. La variable $connectionString doit reprendre le nom du compte de stockage et le nom du file share. Voici un exemple dans un environnement où ebgkhbywivnfzjy est le nom de mon compte de stockage et profiles le nom de mon file share :
L’accès au file share aux les utilisateurs AVD va nécessiter l’application de droits RBAC et NTFS. L’opération dépend d’un certain nombre de facteurs, je vous conseille la documentation suivante pour un domaine Azure AD DS, et cette seconde documentation pour un domaine AD DS.
Une fois que Teams a été installé conformément aux directives d’installation et que l’utilisateur a démarré Teams pour la première fois, la taille du conteneur de profil augmente considérablement en quelques minutes.
Taille du profil avant l’ouverture de Teams.
Quelques minutes après l’ouverture de Teams montre que le profil grandit beaucoup !
Taille du profil après l’ouverture de Teams.
Il est alors possible d’appliquer une optimisation sur Teams pour exclure la prise en charge du cache Teams. La mise en place de cette fonction va nécessiter plusieurs actions :
Ajout d’un fichier de configuration XML sur le compte de stockage utilisé pour FSLogix
Ajout d’une règle de registre dans la configuration FSLogix sur les machines virtuelles AVD
Le script ci-dessous est assez complet et nécessite de remplir un certain nombre de variables :
Identifiant de la souscription
Nom du groupe de ressources du compte de stockage FSLogix
Nom du compte de stockage FSLogix
Nom du file share FSLogix
Clef primaire ou secondaire du compte de stockage
# Step 1
# Variable to Modify
$SubscriptionId = ""
$ResourceGroupName = ""
# The Ressource Group of your storage Account
$StorageAccountName = ""
$AzufileShareName = ""
$StorageAccountKey = ""
# Step 2
# Module and Connection
Install-Module AZ
Import-Module AZ
Install-Module azuread
Import-Module azuread
# Connection Needed for Azure
Connect-AzAccount
Select-AzSubscription -SubscriptionId $SubscriptionId
# Connection Needed for Azure AD
Connect-AzureAD
# Step 3
# Variable to not modify"
$xmllocation= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"
# Step 4
# Run the code below to test the connection and mount the share
$connectTestResult = Test-NetConnection -ComputerName "$StorageAccountName.file.core.windows.net" -Port 445
if ($connectTestResult.TcpTestSucceeded)
{
net use T: "\\$StorageAccountName.file.core.windows.net\$AzufileShareName" /user:Azure\$StorageAccountName $StorageAccountKey
}
else
{
Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."
}
# Step 4 Directory Creation for Teams Exclusion
# Variable to not modify
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$DirectoryID= "T:\Teams"
$Directory= "Teams-Exclusion"
New-Item -Path $DirectoryID -ItemType Directory
# Step 5 Download the Xmlredirection
# Variable to not modify"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
$xmllocation= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"
$xmlurl= "https://raw.githubusercontent.com/Aldebarancloud/WVDCourse/main/redirections.xml"
$connectionString= "\\$StorageAccountName.file.core.windows.net\$AzurefileShareName\$Directory"
Invoke-WebRequest -Uri $xmlurl -OutFile $xmllocation
Un contrôle dans le compte de stockage permet de s’assurer la bonne présence du fichier de configuration XML.
Une fois le script lancé, il est nécessaire d’ajouter sur l’image AVD une règle de registre pour FSLogix appellant ce fichier XML de configuration. Il faut donc remplacer les xxx par le nom de votre compte de stockage dans cette commande PowerShell :
Une fois la configuration finie, il faut penser à supprimer le profil de l’utilisateur sur le compte de stockage FSLogix afin de repartir sur une base « propre ». L’utilisateur peut alors lancer sa session AVD et Teams. Un rapide contrôle sur le compte de stockage nous permet de vérifier l’évolution de la taille sur profil utilisateur
Ouverture de la session AVD et de la session Teams par un utilisateur de test.
La taille du profil utilisateur n’augmente plus au lancement de Teams.
Conclusion
Au final, Microsoft Teams reste un outil formidable de communication bien intégré dans la suite Office 365. Il mérite toute sa place dans Azure Virtual Desktop. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????