Restaurez-vous dans une seconde région grâce au Cross Region Restore

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 :

  • Machines virtuelles Azure (disponibilité générale)
  • 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éographiePaire régionale APaire régionale B
Asie-PacifiqueAsie Est (Hong Kong, R.A.S.)Asie Sud-Est (Singapour)
AustralieAustralie EstSud-Australie Est
AustralieCentre de l’AustralieAustralie Centre 2*
BrésilBrésil SudÉtats-Unis – partie centrale méridionale
BrésilBrésil Sud-Est*Brésil Sud
CanadaCentre du CanadaEst du Canada
ChineChine du NordChine orientale
ChineChine Nord 2Chine orientale 2
EuropeEurope Nord (Irlande)Europe Ouest (Pays-Bas)
FranceFrance CentreFrance Sud*
AllemagneAllemagne Centre-OuestAllemagne Nord*
IndeInde centraleInde Sud
IndeInde OuestInde Sud
JaponJapon EstJapon Ouest
Corée du SudCentre de la CoréeCorée du Sud
Amérique du NordUSA EstUSA Ouest
Amérique du NordUSA Est 2USA Centre
Amérique du NordCentre-Nord des États-UnisÉtats-Unis – partie centrale méridionale
Amérique du NordUSA Ouest 2Centre-USA Ouest
NorvègeNorvège EstNorvège Ouest*
Afrique du SudAfrique du Sud NordAfrique du Sud-Ouest*
SuisseSuisse NordSuisse Ouest*
Royaume-UniOuest du Royaume-UniSud du Royaume-Uni
Émirats Arabes UnisÉmirats arabes unis NordÉmirats arabes unis Centre*
Ministère de la défense des États-UnisUS DoD Est*US DoD Centre*
Gouvernement américainUS Gov Arizona*US Gov Texas*
Gouvernement américainUS Gov Iowa*US Gov Virginie*
Gouvernement américainUS 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 instanceTarif Sauvegarde Azure par mois
Instance inférieure ou égale à 50 GoCHF 7,3808 + stockage utilisé
Instance supérieure à 50 Go mais inférieure ou égale à 500 GoCHF 14,7615 + stockage utilisé
Instance supérieure à > 500 GoCHF 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 StandardNiveau Archive
LRSCHF 0,0331 par GoCHF 0,0043 par Go
ZRSPréversionCHF 0,0414 par GoS.O.
GRSCHF 0,0662 par GoCHF 0,0085 par Go
RA-GRSCHF 0,0840 par GoCHF 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 ».

Au passage, voici un rappel des différents types de cohérence de sauvegarde :

InstantanéDétails
Cohérence des applicationsLes 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 fichiersLes 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’incidentDes 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 restauration de 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 ????

Vous déménagez de région ? Utilisez Azure Resource Mover

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.

Source Microsoft
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 :

  1. Création du projet de migration
  2. Configuration des ressources de destination
  3. Validation des dépendances
  4. Migration (Préparation / Initiation / Confirmation)
  5. Suppression des ressources initiales

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 ????

AVD + Teams = Bonnes pratiques

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.

Microsoft Teams Conference Call Bingo : MicrosoftTeams

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érequis techniques Teams

Comme indiqué par Microsoft, il est nécessaire d’installer sur Teams sur une machine virtuelle ayant à minima les performances suivantes :

ParamètreSystème d’exploitation de station de travail
vCPU2 cœurs
Mémoire RAM4 Go
Stockage8 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.
reg add "HKLM\SOFTWARE\Microsoft\Teams" /v IsWVDEnvironment /t REG_DWORD /d 1 /f

Etape II : Installation de Teams

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 :

  • Installation de la composante C++ Runtime
  • Installation du service WebRTC
  • Installation de Microsoft Teams
#Variables
$CSource = "https://aka.ms/vs/16/release/vc_redist.x64.exe"
$RDWRedirectorSource = "https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4AQBt"
$TeamsSource = "https://statics.teams.cdn.office.net/production-windows-x64/1.4.00.8872/Teams_windows_x64.msi"
$Clocation = "C:\temp\vc_redist.x64.exe"
$RDWRedirectionLocation = "C:\temp\MsRdcWebRTCSvc_HostSetup_1.0.2006.11001_x64.msi"
$TeamsLocation = "C:\temp\Teams_windows_x64.msi"

#log store
[string]$temPAth = 'C:\temp\'

#Folder Creation
if (!(Test-Path -Path $temPAth))
{
    $paramNewItem = @{
        Path      = $temPAth
        ItemType  = 'Directory'
        Force     = $true
    }

    New-Item @paramNewItem
}

#Download C++ Runtime
invoke-WebRequest -Uri $Csource -OutFile $Clocation
Start-Sleep -s 5
#Download RDCWEBRTCSvc
invoke-WebRequest -Uri $RDWRedirectorSource -OutFile $RDWRedirectionLocation
Start-Sleep -s 5
#Download Teams 
invoke-WebRequest -Uri $TeamsSource -OutFile $TeamsLocation
Start-Sleep -s 5

#Install C++ runtime
Start-Process -FilePath $Clocation -ArgumentList '/q', '/norestart'
Start-Sleep -s 10
#Install MSRDCWEBTRCSVC
msiexec /i $RDWRedirectionLocation /q /n
Start-Sleep -s 10
# Install Teams
msiexec /i $TeamsLocation /l*v teamsinstall.txt ALLUSER=1 ALLUSERS=1 /q
Start-Sleep -s 10
Merci à Alexandre pour ce script ????.

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.

Fix WVD Teams Optimization Stopped Working After Windows 10 In-place  Upgrade Windows Virtual Desktop HTMD Blog
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 :

HKEY_CURRENT_USER\Software\Microsoft\Office\nn.0\Common\Graphics
DWORD: DisableHardwareAcceleration
Value: 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.

Image

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 :

\\ebgkhbywivnfzjy.file.core.windows.net\profiles

######################
#    AVD Variables   #
######################

$LocalWVDpath = "c:\temp\wvd\"
$FSLogixURI  = "https://aka.ms/fslogix_download"
$FSInstaller = "FSLogixAppsSetup.zip"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$connectionString = "<your-share-path-here>" 

####################################
#    Test/Create Temp Directory    #
####################################

if((Test-Path c:\temp) -eq $false) {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "Create C:\temp Directory"
    Write-Host `
        -ForegroundColor Cyan `
        -BackgroundColor Black `
        "creating temp directory"
    New-Item -Path c:\temp -ItemType Directory
}
else {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "C:\temp Already Exists"
    Write-Host `
        -ForegroundColor Yellow `
        -BackgroundColor Black `
        "temp directory already exists"
}
if((Test-Path $LocalWVDpath) -eq $false) {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "Create C:\temp\WVD Directory"
    Write-Host `
        -ForegroundColor Cyan `
        -BackgroundColor Black `
        "creating c:\temp\wvd directory"
    New-Item -Path $LocalWVDpath -ItemType Directory
}
else {
    Add-Content -LiteralPath C:\New-WVDSessionHost.log "C:\temp\WVD Already Exists"
    Write-Host `
        -ForegroundColor Yellow `
        -BackgroundColor Black `
        "c:\temp\wvd directory already exists"
}
New-Item -Path c:\ -Name New-WVDSessionHost.log -ItemType File
Add-Content `
-LiteralPath C:\New-WVDSessionHost.log `
"
ProfilePath       = $connectionString
"
#################################
#    Download AVD Componants    #
#################################

Add-Content -LiteralPath C:\New-WVDSessionHost.log "Downloading FSLogix"
    Invoke-WebRequest -Uri $FSLogixURI -OutFile "$LocalWVDpath$FSInstaller"

##############################
#    Prep for AVD Install    #
##############################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Unzip FSLogix"
Expand-Archive `
    -LiteralPath "C:\temp\wvd\$FSInstaller" `
    -DestinationPath "$LocalWVDpath\FSLogix" `
    -Force `
    -Verbose
cd $LocalWVDpath 
Add-Content -LiteralPath C:\New-WVDSessionHost.log "UnZip FXLogix Complete"

#########################
#    FSLogix Install    #
#########################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Installing FSLogix"
$fslogix_deploy_status = Start-Process `
    -FilePath "$LocalWVDpath\FSLogix\x64\Release\FSLogixAppsSetup.exe" `
    -ArgumentList "/install /quiet" `
    -Wait `
    -Passthru


#######################################
#    FSLogix User Profile Settings    #
#######################################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Configure FSLogix Profile Settings"
Push-Location 
Set-Location HKLM:\SOFTWARE\
New-Item `
    -Path HKLM:\SOFTWARE\FSLogix `
    -Name Profiles `
    -Value "" `
    -Force
New-Item `
    -Path HKLM:\Software\FSLogix\Profiles\ `
    -Name Apps `
    -Force
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "Enabled" `
    -Type "Dword" `
    -Value "1"
New-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "VHDLocations" `
    -Value $connectionString `
    -PropertyType MultiString `
    -Force
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SizeInMBs" `
    -Type "Dword" `
    -Value "30720"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "IsDynamic" `
    -Type "Dword" `
    -Value "1"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "VolumeType" `
    -Type String `
    -Value "vhdx"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "ConcurrentUserSessions" `
    -Type "Dword" `
    -Value "1"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "FlipFlopProfileDirectoryName" `
    -Type "Dword" `
    -Value "1" 
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SIDDirNamePattern" `
    -Type String `
    -Value "%username%%sid%"
Set-ItemProperty `
    -Path HKLM:\Software\FSLogix\Profiles `
    -Name "SIDDirNameMatch" `
    -Type String `
    -Value "%username%%sid%" 
New-ItemProperty `
    -Path HKLM:\SOFTWARE\FSLogix\Profiles `
    -Name "DeleteLocalProfileWhenVHDShouldApply" `
    -PropertyType "DWord" `
    -Value 1
Pop-Location

##########################
#    Restart Computer    #
##########################
Add-Content -LiteralPath C:\New-WVDSessionHost.log "Process Complete - REBOOT"
Restart-Computer -Force 

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 :

Set-ItemProperty `
-Path HKLM:\Software\FSLogix\Profiles `
-Name "RedirXMLSourceFolder" `
-Type String `
-Value "\\xxx.file.core.windows.net\profiles\Teams-Exclusion"

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 ????

Quickstart pour Azure Virtual Desktop

Première nouvelle, Windows Virtual Desktop change de nom ! De manière assez logique et cohérente, vous pourrez le retrouver sous AVD. Microsoft rebaptise donc son service « Windows Virtual Desktop » (WVD) en « Azure Virtual Desktop ».

Dans la foulée, Microsoft a annoncé la mise en place d’un Quickstart dans le but de faciliter le déploiement d’AVD sur des nouveaux environnements Azure, vierges ou ayant déjà éléments d’architecture.

Nous allons détailler ensemble dans cet article toutes les fonctionnalités de ce Quickstart, encore en preview à l’heure où ces lignes sont écrites.

Résumé du Quickstart d’AVD :

Voici dans ce lien les informations de départ concernant ce nouveau Quickstart. Dans ce billet de Stefan Georgiev, nous pouvons y apprendre quelques points importants :

  • Cette fonctionnalité est toujours en preview
  • Ce Quickstart apporte une création rapide d’un environnement AVD en seulement quelques clics
  • Il facilite grandement le déploiement d’un environnement AVD en prenant en charge les éléments de base suivants :
    • Création d’un domaine si inexistant
    • Création des composantes d’AVD
    • Création d’un compte de stockage pour les profils via FSLogix
    • Installation de FSLogix sur les machines virtuelles d’AVD
    • Création de groupes d’utilisateurs
    • Application des droits NTFS / RBAC pour le compte de stockage FSLogix

Evidement et vous l’avez compris, la simplicité de ce type de déploiement entraine la mise à l’écart de fonctionnalités spécifiques à votre déploiement. Je ne suis pas inquiet pour la suite, car ce Quickstart est encore en preview et va s’améliorer au fil des remontées des testeurs.

Il est donc possible de faire des remontées directes à Microsoft par ce lien.

Windows Virtual Desktop pour les entreprises - Azure Example Scenarios |  Microsoft Docs
Si seulement le Quickstart d’AVD pouvait faire tout ça d’un coup 😉

Etape 0 : Rappel des prérequis

Comme indiqué dans le billet de Stefan, certains prérequis sont nécessaires au déploiement de votre Quickstart. Il faut disposer au préalable de :

  • Souscription Azure active
  • Tenant Azure AD
  • Un compte avec le profil d’administrateur global sur Azure AD
  • Un compte disposant des droits de propriétaire sur la souscription active
  • Active directory déjà en place ? Avoir également un compte d’administration du domaine

Le Quickstart en détail

Avant tout, la fonctionnalité de Quickstart dans AVD n’est pas encore disponible dans le portail Azure de base, mais par le lien donné ici.

Une fois sur le bon portail Azure, vous pouvez chercher AVD dans la barre principale.
Le Quickstart est alors disponible sur le menu de gauche.

La création du Quickstart va demander à passer en revue plusieurs champs avant de pouvoir exécuter les différents scripts automatisés :

Premier onglet définissant les principales caractéristiques du déploiement d’AVD.
  • Souscription : Choisissez ici la souscription Azure devant héberger l’ensemble des ressources Azure, créées par le Quickstart.
  • Configuration de la souscription : Deux choix sont possibles et cela dépend de votre situation actuelle. Possédez-vous déjà un domaine Active Directory ? Il peut s’agir soit d’un domaine managé par Azure (Azure AD Domain Services) ou soit d’un domaine géré sur une machines virtuelle.
  • Préfixe des groupes de ressources : Plusieurs groupes de ressources seront créés selon les différents scénarios, cela permet d’identifier facilement le contenu de chacun d’eux.
  • Localisation : On choisit ici la région Azure utilisée pour la création des ressources. Ce qui est dommage actuellement, c’est que cette liste est pour l’instant incomplète car elle semble ne reprendre que la liste des régions disponibles pour les métadatas d’AVD. Nul doute que Microsoft va rajouter par la suite plus de régions Azure, ou bien rajouter un second champ de localisation pour choisir où héberger les machines virtuelles et le domaine managé.
  • Compte Azure : Compte exécutant les scripts de création du Quickstart. Il doit donc être administrateur global du tenant et propriétaire de la souscription indiquée plus haut. Pour éviter un blocage durant le déploiement du Quickstart, ce dernier doit être exempté de MFA le temps de l’opération.
  • Compte administrateur du domaine : Ce compte est utilisé pour joindre les machines virtuelles d’AVD au domaine Active Directory créé ou existant. Point important : si le domaine n’est pas créé sur votre environnement, ce compte ne doit pas exister ! A l’inverse, si un domaine Active Directory, managé ou non, est déjà présent : ce compte devra exister avant le lancement du Quickstart.
  • Identité : En fonction de la configuration de la souscription indiquée plus haut, vous avez un ou plusieurs choix disponibles. Le but ici est de savoir si le déploiement doit se faire sur un domaine managé (Azure AD Domain Services), existant ou non, ou sur un domaine Active Directory sur une machine virtuelle existante.

Remarques : Afin de vous éviter des erreurs dans le déploiement du Quickstart, je souhaite vous faire une remarque sur deux prérequis importants si vous choisissez de partir sur un domaine Active Directory existant sur machines virtuelles :

  • Le contrôleur de domaine VM ne doit pas déjà avoir d’extensions DSC de type Microsoft.Powershell.DSC.
  • Le contrôleur de domaine VM doit avoir Azure AD Connect d’installé et de configuré.

Machines virtuelles

Comme pour un déploiement AVD en dehors du Quickstart, les machines virtuelles AVD sont déployables dans la même façon.
  • Machines virtuelles partagées : cette option reprend la question posée dans un déploiement AVD classique. S’agit-il d’un environnement AVD partagé entre utilisateurs ou personnel (une machine virtuelle par utilisateur) ?
  • Image source + image : On retrouve ici la possibilité de bénéficier d’images gérées par Microsoft, ou propres et personnalisées par vos soins.
  • Taille des machines virtuelles : comme toujours, cela dépend du budget alloué et des ressources nécessaires aux utilisateurs. Voici un lien détaillant les bonnes pratiques préconisées par Microsoft.
  • Nombre de machines virtuelles : Faites-vous plaisir 🙂

Assignations aux utilisateurs

En fonction du scénario de configuration de la souscription, le nombre d’options de cet écran peut varier.
  • Création d’utilisateur de validation : Le Quickstart d’AVD se propose de créer automatiquement un utilisateur de test pour vérifier le bon fonctionnement de la solution.
  • Assignation d’utilisateurs existants : Cette option est disponible si un domaine Active Directory est déjà présent. Il permet d’assigner un groupe d’utilisateurs au groupe d’application d’AVD pendant le déploiement du Quickstart.

Afin de vous aider au mieux sur les différents scénarios possibles du Quickstart, nous allons détailler les 3 grands cas possibles.

Cas I : Souscription vide

Il s’agit du cas le plus simple, on va donc partir ici de … rien !

Le but est donc bien de créer un domaine Azure AD Domain Services. Ce service est directement managé par Microsoft. Pour rappel, ce vidéo explique bien de quoi il en retourne :

Voici un tableau détaillant les principales différences entre un domaine managé et non managé.

Voici donc les éléments renseignées lors de ma création :

Finalement, la seule erreur possible serait d’indiquer un compte de domaine existant 😉

En parlant d’erreur lors du déploiement via le Quickstart d’AVD, voici ce qui se passe si vous réutilisez un compte existant pour l’administration du domaine managé Azure AD DS :

L’erreur est, disons-le, très peu explicite.

{    "status": "Failed",    "error": {        "code": "DeploymentFailed",        "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.",        "details": [            {                "code": "Conflict",                "message": "{\r\n  \"status\": \"Failed\",\r\n  \"error\": {\r\n    \"code\": \"ResourceDeploymentFailure\",\r\n    \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\"\r\n  }\r\n}"            }        ]    }}

Pourquoi cette erreur ? Pour ceux ayant déjà déployé par le passé un service Azure AD DS, il est connu que la synchronisation des mots de passe entre Azure AD et Azure AD DS ne se fait que lors des méthodes suivantes :

  • Réinitialisation du mot de passe des utilisateurs existants avant la création d’Azure AD DS
  • Création de nouveaux utilisateurs après la mise en service d’Azure AD DS

Les écrans suivants ne présentent peu d’intérêt :

La création du cas I du Quickstart AVD avec un nouvel Azure AD DS prend du temps :
1 heure et 38 minutes pour moi !

Une fois le déploiement terminé avec succès, vous pouvez retourner dans votre liste des groupes de ressources sur le portail Azure :

3 Groupes de ressources sont créées durant le processus de déploiement du Cas I d’AVD.
Le groupe de ressources « x-deployment » contient les runbooks servant au déploiement de la solution.
Le groupe de ressources « x-prerequisite » contient ici les ressources liées au domaine managé Azure AD DS.

Dans ce groupe de ressource, on remarque que le SKU employé par défaut pour Azure AD DS est la version « Enterprise ». Une option serait intéressante pour définir le SKU adapté au moment de la création du Quickstart.

La modification du SKU du service Azure AD DS est toujours possible après le déploiement.
Le script de déploiement Quickstart a aussi pensé à la modification des enregistrements DNS sur réseau virtuel, malin !
Le groupe de ressources « x-wvd » contient toutes les ressources nécessaires à l’exploitation d’AVD.

On retrouve donc dans ce groupe les ressources Azure suivantes :

  • Host Pool AVD
  • Application group AVD
  • Workspace AVD
  • X Machines virtuelles AVD
  • X Disques managés pour les machines virtuelles
  • X interfaces réseaux pour les machines virtuelles
  • Compte de stockage pour la gestion des profils utilisateurs FSLogix
  • Identité managée pour la mise en place des droits NTFS sur le file share

Ces ressources sont assez classiques dans un déploiement AVD. Les points vraiment intéressants sont les actions faites directement sur le compte de stockage :

  • Association du compte de stockage au domaine managé Azure AD DS
  • Création du file-share « profiles »
  • Ajout des droits RBAC « Storage File Data SMB Share Contributor » pour le groupe d’utilisateurs AVD
  • Ajout des droits NTFS « Modify » pour le groupe d’utilisateurs AVD

C’est bien sur ce dernier point que l’identité managée a été nécessaire. Elle a permis d’accéder au file share du compte de stockage via la clé du compte pour y rajouter les droits NTFS.

Au final, l’utilisateur de test peut donc ouvrir l’application Remote Desktop d’AVD afin de vérifier le bon fonctionnement du Quickstart :

PS : Pensez à faire un clic droit sur l’icône pour retirer l’option « tous les écrans », paramétrée par défaut.
L’ouverture de la session par l’utilisateur de test sur AVD créé bien le dossier du profil utilisateur sur le compte de stockage paramétré pour FSLogix.

Conclusion du cas I : Très facile à déployer malgré le temps long. On retrouve bien les avantages d’un Quickstart pour monter et démontrer la solution en quelques clics.

Cas II : Souscription disposant déjà d’un domaine managé Azure AD Domain Services

Peruvian Desert Oasis | The beautiful desert oasis of Huacac… | Flickr

Le second cas décrit dans cette section s’adapte pour un environnement ayant déjà déployé le service Azure AD DS. Quelques options sont donc à renseigner sur le premier onglet du Quickstart d’AVD :

Dans le cas II, le compte d’administration du domaine managé doit déjà exister, à l’inverse du compte dans le cas I.

Le cas II demande également de renseigner les éléments réseaux afin de permettre la jointure des machines virtuelles d’AVD au domaine Azure AD DS existant.

Dans mon exemple de cas II, j’ai réutilisé le domaine managé Azure AD DS créé via mon cas I.
J’ai également réutilisé le groupe d’utilisateurs d’AVD créé dans le cas I pour également l’assigner au groupe d’applications AVD créé par mon cas II.
La création du cas II du Quickstart d’AVD avec un Azure AD DS existant a été bien plus rapide que le cas I :
environ 20 minutes.

Une fois le déploiement terminé avec succès, vous pouvez retourner dans votre liste des groupes de ressources Azure :

3 Groupes de ressources sont créés durant le processus de déploiement du Cas II d’AVD.
Le groupe de ressources « x-AD-deployment » contient moins de runbooks que celui du cas I servant au déploiement de la solution.
Le groupe de ressources « x-ex-deployment » ne contient plus ici les ressources liées au domaine managé Azure AD DS, mais seulement les runbooks servant à s’associer avec ce dernier.
Le groupe de ressources « exi-wvd » contient toutes les ressources nécessaires à l’exploitation d’AVD.

Le même utilisateur de test dispose donc du second environnement AVD dans son application Remote Desktop.

Conclusion du cas II : Comme le cas I, celui-ci est aussi très facile à déployer. Malgré le fait que l’environnement de domaine est existant, le Quickstart recréé bien un second compte de stockage et y applique tous les éléments liés aux paramétrages FSLogix.

Cas III : Souscription disposant déjà d’un domaine Active Directory sur une machine virtuelle

DUBAI: PROJECTED INTO THE FUTURE [DAY 2 and 3] – FEDERICA DI NARDO

Remarques : Déjà indiqué plus haut dans cet article, deux prérequis sont importants si vous choisissez de partir sur un domaine Active Directory existant sur une machine virtuelle :

  • Le contrôleur de domaine VM ne doit pas avoir d’extensions DSC de type Microsoft.Powershell.DSC.
  • Le contrôleur de domaine VM doit avoir Azure AD Connect d’installé et de configuré.

En reprenant le parcours de configuration du cas III, seule la dernière option se retrouve modifiée par rapport au cas II :

De nouveaux champs apparaissent également sur la seconde page, dédiée aux machines virtuelles d’AVD :

  • Groupe de ressources du contrôleur de domaine
  • Machine virtuelle avec le rôle de contrôleur de domaine

Les points rappelés plus haut vous éviterons les erreurs de déploiements suivantes :

Erreur lors de l’exécution du Quickstart d’AVD car le contrôleur de domaine avait déjà une extension DSC d’installée.  » ‘Microsoft.Powershell.DSC’ with handler ‘Microsoft.Powershell.DSC’ already added »
Erreur lors de l’exécution du Quickstart d’AVD car le contrôleur de domaine n’avait pas AD Connect d’installé et de configuré. « The specified module ‘ADSync’ was not loaded because no valid »
La création du Quickstart d’AVD via le cas III a été un peu plus longue que sur le cas II :
27 minutes environ.
Le groupe de ressources « x-deployment » contient uniquement les runbooks servant au déploiement de la solution.
Le groupe de ressources « x-wvd » contient toutes les ressources nécessaires à l’exploitation d’AVD.

Conclusion du cas III : Comme le cas II, ce Quickstart s’adapte bien aux scénarios hybride avec un environnement de domaine non managé existant. Comme pour tous les Quickstarts, il recréé dans le cas III un nouveau compte de stockage et y applique tous les éléments liés au paramétrages FSLogix.

La jointure du domaine non managé se fait sans aucune difficulté dans le cas III.

Conclusion

Au final, cette première preview publique du Quickstart d’AVD fonctionne très bien et démontre un réel intérêt pour les déploiements rapides avec un paramétrage de base. Le gros du travail reste toujours sur la customisations de l’image servant aux machines virtuelles d’Azure Virtual Desktop.

Enfin et comme indiqué en début de cet article, n’hésitez pas à tester la solution et faites par de vos remarques ici 🙂

Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????

Microsoft Cloud : tout savoir sur les certifications

Microsoft Learn | Microsoft Docs

La certification est une démarche personnelle et doit avant tout servir son propre intérêt. De mon point de vue, les bénéfices des certifications informatiques vont bien au-delà du fait de posséder une plaquette de badges sur le torse, ils sont multiples :

  • Montrer les compétences acquises dans un domaine technique précis
  • Gagner crédibilité auprès de son employeur
  • Augmenter sa confiance personnelle et son estime de soi
  • Valoriser son parcours professionnel
  • Et bien plus encore !
Why Certification is Important for IT Professionals? - Whizlabs Blog

Dans cet article, nous allons parler des caractéristiques propres aux différentes certifications Microsoft, mais surtout des facilités mises en place pour passer les certifications de type Fondamental.

Les familles de certifications Microsoft

Pour faire simple, il existe plusieurs classifications pour les certifications Microsoft Cloud :

  • Classification par thème (Azure, Microsoft 365, Dynamics 365, Power Platform)
  • Classification par niveau (Fondamental, Associé, Expert)
  • Classification par nature (Général, Rôle, Spécialité)
Poster des certifications Microsoft.
Cliquez sur l’image pour consulter la dernière version.

Comme vous pouvez le voir dans le poster ci-dessus, le choix est assez large sur les certifications possibles. Vous devez donc tenir compte d’un certain nombre de paramètres pour choisir la bonne certification adaptée à votre objectif. Prenez également en compte que certaines certifications sont liées à d’autres, tandis que certaines « imposent » des certifications préalables pour valider le titre associé.

Que signifient les niveaux de certification Microsoft ?

Microsoft a introduit les niveaux de certification durant l’année 2019 et les a répartis en trois niveaux. Cela a été mis en œuvre pour de nombreuses raisons, qui bénéficient à la fois au participant et à l’employeur de plusieurs façons :

  • Rendre les cours Microsoft plus accessibles aux débutants comme aux habitués de l’informatique
  • Encourager les personnes de tous niveaux à obtenir une certification
  • Faciliter le recrutement pour les employeurs en sélectionnant des professionnels en fonction des connaissances dont ils ont besoin
  • Clarifier le niveau de compétence de la certification

Les Certifications Microsoft de niveau « Fondamental »

Afin de démarrer le cloud dans les meilleurs conditions, Microsoft a mis en place des certifications de niveau « Fondamental ». Ces certifications sont conçues pour valider un niveau de connaissances de base des services du cloud. Elle aide également les candidats non techniques à comprendre les services tels que la vente, l’achat et le marketing. Par principe, elles n’exigent pas de prérequis antérieurs.

Les Certifications Microsoft de niveau « Associé »

De niveau intermédiaire, les certifications de niveau Associé vérifieront vos connaissances de manières approfondies. Plus question ici de valider si vous maîtrisez les grands principes du domaine concerné. Il est nécessaire ici de mettre en pratique vos connaissances dans des contextes techniques précis. A l’inverse des certifications de niveau Fondamental, où seul un apprentissage théorique serait suffisant, la validation d’une certification de niveau Associé devra s’appuyer sur une expérience professionnelle réelle.

Les Certifications Microsoft de niveau « Expert »

Comme son nom l’indique, les examens du niveau Expert sont beaucoup plus difficiles que celles de niveau Associé. Dans certains cas, il faut passer plusieurs examens de niveau Expert pour obtenir une certification. Il arrive aussi que, pour être validées, elles nécessitent des certifications de niveau inférieur.

Comment se préparer à passer une certification ?

Quels sont les avantages des formations en digital learning ? - Digiformag

Peu importe le niveau de certification désiré, le rituel de préparation reste globalement identique :

Microsoft Learn : Conçu pour aider quiconque à apprendre les concepts informatiques de base à son propre rythme, Microsoft Learn est une immense bibliothèque offrant un accès gratuit à des supports de formation, des échantillons de code et même la possibilité de tester certains logiciels Microsoft.

Formation dispensée par un instructeur : Le choix d’une formation dirigée par un instructeur est également une excellente option, car il vous permet d’interagir avec un professionnel expérimenté, vous donnant l’occasion de poser des questions et de travailler sur vos faiblesses, ainsi que de développer vos points forts.

Découverte de la solution : Microsoft propose de tester ses solutions de plusieurs manières. Il est possible de souscrire à des périodes d’évaluation sans frais ou de profiter de crédits gratuits pendant une certaine durée. Par exemple, il est donc possible de tester Office 365 ou Azure sans devoir payer pour ces services.

Parcours d’apprentissage : Chaque certification Microsoft s’accompagne d’un parcours d’apprentissage, en relation avec les sujets abordés pendant l’examen. Il vous permet d’aborder à votre rythme toutes les connaissances requises et vous évalue par de petits questionnaires.

YouTube : Le célèbre site de vidéos en ligne regorge de passionnés du cloud Microsoft qui vous transmettrons leurs connaissances techniques au travers d’explications claires et visuelles. Pourquoi s’en priver ?

GitHub : Microsoft Learning dispose de son propre GitHub. C’est l’occasion ici de travailler vos connaissances techniques grâce à des exercices ou des labs orientés sur la certification choisie.

Microsoft Virtual Training Days : Webinaires Microsoft gratuits et animés par des experts qui vous apporteront toutes les bases en rapport avec la certifications. Ces évènements sont orientés pour les certifications de niveau Fondamental ou pour certains thèmes spécifiques. Dans tous les cas, ils nécessitent une inscription préalable.

Microsoft Virtual Training Days

Que vous fassiez vos premiers pas dans le Cloud Microsoft ou que vous souhaitiez valider vos connaissances, Microsoft Virtual Training Days est fait pour vous.

Microsoft Virtual Training Days regroupe les principaux thèmes du Cloud Microsoft et vous propose plusieurs sessions dédiées :

Peu importe le Training Day choisi, le webinaire vous montre tous les chapitres de la certification et les aborde de manière claire et progressive. Vous pouvez donc les suivre sans avoir la crainte de pas comprendre les concepts et les idées présentés.

Enfin et ce n’est pas des moindres, Microsoft récompense les participants à ces webinaires en offrant gratuitement un bon d’examen. Vous avez bien lu, l’examen facturé initialement 99 euros hors taxes ne vous coûtera pas un centime si vous assistez au webinaire, lui-même gratuit !

Bien évidemment, passer l’examen en ne suivant que ce webinar s’avère fortement risqué. Je vous recommande donc de compléter vos connaissances par les autres sources listées dans la section précédente.

Une fois la certification réussie

Tout d’abord, félicitations !!! C’est une petite victoire personnelle sur ses propres capacités. Cela montre que ce challenge était à votre portée et qu’il récompense les efforts fournis. Il ne faut pas rougir de son succès, et le partager sur les réseaux est mérité. Cela peut aussi encourager d’autres connaissances à choisir cette voie ou provoquer un déclic sur leur orientation professionnelle.

Bouteille de champagne 75cl - Le Moulin de Ducey

Conclusion

Comme à chaque fois, pensez à partager dans les commentaires vos propres expériences sur les certifications, Microsoft ou autres ????

Pooled Azure Virtual Desktop VMs managées avec Intune

Enroll Windows Virtual Desktop to Intune – Mr T-Bone´s Blog

Attendu depuis plusieurs mois, il est maintenant possible de mettre en place un MDM via l’outil Intune pour des machines virtuelles partagées Azure Virtual Desktop. Il s’agit toujours d’une nouvelle feature en Preview, mais qui va à terme simplifier le maintien opérationnel de ce service de Remote Desktop proposé par Azure.

Pour vous re-situer dans le sujet, voici deux vidéos sélectionnées par mes soins sur qu’est ce qu’Intune et les différences et les synergies possibles avec Configuration Manager :

Points clefs d’Intune.
Merci à Jean-Sébastien 🙂

L’objectif de cet article est donc de vous parcourir avec vous toutes les étapes nécessaires à la mise en place de cette association.

Rappel :

Comme indiqué dans son article sur les machines virtuelles partagées, Microsoft nous explique que la prise en charge actuelle d’Intune est uniquement orientée sur la configuration des VMs. De ce fait et pour que l’application se fasse correctement, il sera donc nécessaire de cibler les polices sur des groupes de machines et non des groupes d’utilisateurs.

Etape 0 : Prérequis

Certaines conditions sont donc obligatoires pour profiter d’Intune sur un environnement Azure Virtual Desktop :

  • Windows 10 multisessions, version 1903 ou ultérieure
  • Azure Virtual Desktop host pool configuré en version partagé
  • Version de l’agent Azure Virtual Desktop égale ou supérieure à 2944.1400

L’une des exigences pour gérer votre environnement Windows 10 AVD avec Endpoint Manager est l’utilisation de la jointure hybride avec Azure AD. Lorsque vous configurez vos périphériques pour qu’ils rejoignent Azure AD, ces périphériques seront visibles et gérables à la fois dans votre AD sur site et dans Azure AD.

Etape I : Mise en place d’un serveur Active Directory sur une machine virtuelle

Comme rappelé plus haut, il est donc nécessaire de disposer d’un serveur Active Directory, géré sur une machine virtuelle et non pas via le service managé par Azure Active Directory Domain Services (AADDS). Vous devrez donc créer une machine virtuelle sous Windows Server et y installer le rôle Active Directory.

Vous pouvez mettre en place très facilement cet ensemble VM + DC via le template proposé par Microsoft juste ici.

Champs à renseigner pour déployer le custom template de domain (Microsoft)
Le déploiement complet de la machine virtuelle et du domain prend environ 20 minutes.
Le template modifie même le serveur DNS du réseau virtuel sur lequel il est déployé, la vie est belle !

Pensez également à créer dans votre AD un ou plusieurs utilisateurs de test pour la solution Azure Virtual Desktop.

Création d’une première OU pour les machines virtuelles AVD et d’une seconde OU pour les utilisateurs AVD.

Etape II : Installation d’AD Connect

Une fois déployé, nous allons mettre en place la liaison entre le serveur Active Directory et Azure AD. Pour cela, nous allons utiliser l’outil Azure AD Connect, téléchargeable directement ici. Idéalement installé sur une machine dédiée et jointe au domaine, vous pouvez l’installer directement sur votre contrôleur de domaine pour environnement de test.

Si vous souhaitez en savoir plus sur cet utilitaire et son installation, voici une vidéo proposée par l’Azure Academy :

Merci à Dean Cefola ????
Synchronisation des 2 OUs précédemment créés sur le serveur Active Directory.
L’installation est terminée et la synchronisation se lance à l’issue de cette dernière. J’en ai profité pour activer le SSO, fonctionnel au sein de AVD.

Une fois déployé, vous devriez retrouver votre groupe et vos utilisateurs AVD créés sur l’AD directement sur Azure AD :

La mention DIRECTORY SYNCED vous indique que ces utilisateurs ne sont pas à l’origine créé par Azure AD.

Etape III : Mise en place de l’Hybrid Join via Azure AD Connect

Cet étape demande à retourner sur la configuration d’Azure AD Connect. En effet, il faut activer cette option dans un second temps :

  • Lancez Azure AD Connect et cliquez sur le bouton Configurer
  • Cliquez sur Configurer les options du dispositif dans la liste des tâches supplémentaires
  • Passez en revue la page et cliquez sur Suivant
  • Saisissez les informations d’identification d’un compte d’administrateur global Azure AD, puis cliquez sur Suivant
  • Sélectionnez Configure Hybrid Azure AD join et cliquez sur Next
  • Sélectionnez la configuration du système d’exploitation de l’appareil (Windows 10 actuel ou systèmes d’exploitation plus anciens de « niveau inférieur ») qui sera prise en charge et cliquez sur Suivant
  • Cliquez sur le bouton Modifier et saisissez vos informations d’identification d’administrateur d’entreprise, puis cliquez sur Suivant
  • Cliquez sur Configurer pour commencer le processus
  • Lorsque le message Configuration terminée s’affiche, vous pouvez quitter l’assistant

Etape IV : Activation de l’enrôlement automatique vers Intune

Pour que l’inscription soit automatique sur Intune et qu’ils soient managés par ce dernier, il est nécessaire de faire quelques vérifications de configuration sur Azure AD. Rendez-vous donc sur la page d’Azure AD :

Certains tenants peuvent avoir à la fois Microsoft Intune et Microsoft Intune Enrollment. Assurez-vous que vos paramètres d’inscription automatique sont configurés sous Microsoft Intune (et non Microsoft Intune Enrollment).
Vérifier l’URL de découverte MDM pour l’inscription automatique et assurez-vous que l’inscription automatique est activée pour les utilisateurs désirés.

Etape V : Création d’une GPO d’auto-enrôlement

À partir de Windows 10, version 1607, une fois que l’entreprise a enregistré un appareil Windows à son Active Directory local, cet appareil sera automatiquement enregistré dans Azure AD.

Une fois la stratégie de groupe créée et activée sur l’Active Directory local, une tâche est créée en arrière-plan pour lancer l’inscription à l’aide de la configuration existante du service MDM à partir des informations Azure AD de l’utilisateur, et sans son interaction. Effectuez les étapes ci-dessous pour configurer une stratégie de groupe afin d’inscrire un groupe d’appareils dans Intune :

Naviguer vers le dossier C:\Program Files (x86)\Microsoft Group Policy\Windows 10 May 2020 Update (2004) et copiez le dossier PolicyDefinitions dans F:\SYSVOL\domain\Policies.

Redémarrez le contrôleur de domaine pour rendre la police disponible.

Créez un objet de stratégie de groupe (GPO) et activez la stratégie de groupe Configuration de l’ordinateur > Stratégies > Modèles d’administration > Composants Windows > MDM > Activer l’inscription automatique au MDM en utilisant les informations d’identification Azure AD par device.
Dans le cadre d’un environnement AVD partagé, il est nécessaire de sélectionner « Device Credential ».

Important

Sur tous les Windows 10, versions 2004, 20H2 et 21H1, il y a actuellement un problème qui fait que les actions à distance dans Microsoft Endpoint Manager, comme la synchronisation à distance, ne fonctionnent pas correctement. En conséquence, l’application de toute politique en attente affectée à des périphériques peut prendre jusqu’à 8 heures. Pour résoudre ce problème, veuillez effectuer les étapes suivantes sur vos machines virtuelles avant de les inscrire dans Microsoft Endpoint Manager en utilisant dans votre GPO la clé de registre suivante :

  • Chemin : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server
  • Nom de la valeur : ClientExperienceEnabled
  • Type de valeur : REG_DWORD
  • Données de la valeur : 1
Vous pouvez faire l’opération dans la même GPO.
Une fois la GPO terminée, il ne vous reste qu’à rattacher celle-ci au groupe de machines virtuelles AVD.

Etape VI : Création de l’environnement Azure Virtual Desktop

Dans tous les cas, la création d’une environnement Azure Virtual Desktop nécessite une jointure à un domaine existant. Il peut être géré sur une machine virtuelle Windows Server, ou managé par Microsoft via le service AADDS. L’étape de création de AVD va s’occuper de générer les ressources Azure suivantes :

  • Host Pool AVD
  • Session hosts (machine virtuelles AVD)
  • Workspace
  • Application groupe

J’ai donc procédé à la création suivante pour Azure Virtual Desktop :

La première étape consiste à créer le host pool et à définir si ce dernier est partagé avec la règle de load balancing désirée.
Le second onglet se concentre sur les machines virtuelles créées et rattachées au Host Pool AVD.
La partie basse de l’onglet des machines virtuelles est dédiée à la jointure avec le domain existant et les comptes d’administration.
Une fois la création du workspace et les tags renseignés, comptez une dizaine de minutes pour retrouver l’environnement AVD entièrement déployé.

Une fois le déploiement AVD terminé, il vous faut retourner sur le service pour assigner à l’application group créé un groupe d’utilisateurs AVD :

Affecter ici le groupe d’utilisateurs créé dans Active Directory et synchronisé sur Azure AD via Azure AD Connect.

Etape VII : Affecter les VMs AVD au groupe de machines AD et forcer les GPO

Les machines virtuelles créées par le service Azure Virtual Desktop se trouvent dans la bonne OU mais doivent être encore affectées au groupe de machines AVD pour recevoir la GPO créée précédemment.

Un redémarrage des machines virtuelles AVD actualisera sur ces dernières les groupes et les GPO à appliquer. Vous pouvez vérifier que tout s’est bien passé avec un compte administrateur :

La commande GPRESULT /R /SCOPE COMPUTER vous permettra de vous assurer que la machine virtuelle applique ce qu’il faut.
La commande RSoP.msc vous permettra de vous assurer que la machine virtuelle applique ce qu’il faut.
Un tour dans le registre Windows vous montre également que la clef de registre a bien été correctement déployée grâce à la GPO.

Etape VIII : Synchronisation AD > Azure AD grâce à AD Connect

Azure AD Connect est configuré par défaut pour synchroniser les objets toutes les 30 minutes. Un tour dans le programme Synchronization Service Manager nous permet de voir la prochaine synchronisation :

Il est possible de forcer une synchronisation plus tôt, si cela est nécessaire.

Une fois la synchronisation effectuée vers Azure AD, vous devriez retrouver les machines virtuelles AVD dans la section Device votre Azure AD :

Il est possible que la colonne REGISTERED indique encore Pending pendant un certain temps.
15 minutes plus tard et sans rien faire, elles retrouvent bien un statut REGISTERED.

Dans certains cas, le statut peut perdurer en Pending. Voici un bon article qui explique comment s’en sortir. Quelques minutes plus tard, les choses comment aussi à bouger pour la colonne MDM :

Cette copie d’écran démontre que la machine virtuelle vm-2 est routée vers System Center Configuration Manager, ce qui n’est évidemment pas le cas.

Note :

Il sera possible que les choses changent quand un utilisateur se connecte aux machines virtuelles AVD. La copie d’écran ci-dessous montre que le tir est rectifié, comme vous pouvez le voir dans la colonne MDM : Intune.

OUF ????
La seconde arrive !
All good.

Si cela ne se passe pas comment attendu dans votre environnement, vous pouvez consulter les messages d’erreur directement dans les logs d’Event Viewer ou consulter cette page de troubleshoot.

Pour vérifier cette erreur, recherchez l’ID d’événement 76 (message d’événement : Inscription automatique À la gestion des données de la gestion des données : Échec (code d’erreur Win32 inconnu : 0x8018002b)). Cet événement indique un échec d’inscription automatique.

Etape IX : Configuration des VMs AVD sur Intune :

Pour rappel, Intune est l’ancien nom pour Microsoft Endpoint Manager, vous pouvez vous connecter à l’admin center par ce lien. Si toutes les étapes précédentes se sont bien passées, vous devriez retrouver les machines virtuelles AVD dans la section Windows Devices :

Vous allez pouvoir configurer différents types de police. Vous devez créer une nouvelle stratégie de conformité et la cibler sur le groupe de périphériques contenant vos VM multisessions. Les configurations de conformité ciblées sur l’utilisateur ne sont pas prises en charge.

Polices de conformité et accès conditionnel

Vous pouvez sécuriser vos VM multisessions Windows 10 Enterprise en configurant des politiques de conformité et des politiques d’accès conditionnel dans le centre d’administration Endpoint Manager. Les politiques de conformité suivantes sont prises en charge sur les VM multisessions de Windows 10 Enterprise :

  • Version minimale du système d’exploitation
  • Version maximale du système d’exploitation
  • Constructions de système d’exploitation valides
  • Mots de passe simples
  • Type de mot de passe
  • Longueur minimale du mot de passe
  • Complexité du mot de passe
  • Expiration du mot de passe (jours)
  • Nombre de mots de passe précédents pour empêcher la réutilisation
  • Microsoft Defender Antimalware
  • Intelligence de sécurité Microsoft Defender Antimalware à jour
  • Pare-feu
  • Antivirus
  • Antispyware
  • Protection en temps réel
  • Version minimale de Microsoft Defender Antimalware
  • Score de risque Defender ATP
  • Toutes les autres politiques sont signalées comme non applicables.

Les politiques d’accès conditionnel prennent en charge les configurations basées sur les utilisateurs et les périphériques pour Windows 10 Enterprise multisession.

Déploiement d’applications

Toutes les applications Windows 10 peuvent être déployées sur Windows 10 Enterprise multisessions avec les restrictions suivantes :

  • Toutes les applications doivent être configurées pour s’installer dans le contexte système/appareil et être ciblées sur les appareils. Les applications Web sont toujours appliquées dans le contexte utilisateur par défaut, elles ne s’appliqueront donc pas aux VM multisessions
  • Toutes les applications doivent être configurées avec l’intention d’affectation Required ou Uninstall app. L’intention de déploiement Available apps n’est pas prise en charge sur les VM multisession
  • Si une application Win32 configurée pour être installée dans le contexte du système a des dépendances ou des relations de substitution avec toute application configurée pour être installée dans le contexte de l’utilisateur, l’application ne sera pas installée. Pour s’appliquer à une VM multisession Windows 10 Enterprise, créez une instance distincte de l’application du contexte système ou assurez-vous que toutes les dépendances de l’application sont configurées pour être installées dans le contexte système
  • Azure Virtual Desktop RemoteApp et l’attachement d’applications MSIX ne sont pas actuellement pris en charge par Microsoft Endpoint Manager

Déploiement de scripts

Les scripts configurés pour s’exécuter dans le contexte système sont pris en charge sur Windows 10 Enterprise multisessions. Cela peut être configuré sous Paramètres de script en définissant Exécuter ce script en utilisant les informations d’identification connectées sur Non

Mise à jour de Windows pour les entreprises

Les politiques de Windows Update for Business ne sont pas actuellement prises en charge pour Windows 10 Enterprise multisessions.

Actions à distance

Les actions à distance suivantes des périphériques de bureau Windows 10 ne sont pas prises en charge et seront grisées dans l’interface utilisateur et désactivées dans Graphique pour les VM multisessions Windows 10 Enterprise :

  • Réinitialisation du pilote automatique
  • Rotation des clés BitLocker
  • Nouveau départ
  • Verrouillage à distance
  • Réinitialisation du mot de passe
  • Effacer

Fin de vie

La suppression des VM d’Azure laissera des enregistrements de périphériques orphelins dans Microsoft Endpoint Manager. Ils seront automatiquement nettoyés selon les règles de nettoyage configurées pour le locataire.

Configurations supplémentaires qui ne sont pas prises en charge sur les VM multisessions de Windows 10 Enterprise.

L’inscription à Out of Box Experience (OOBE) n’est pas prise en charge pour Windows 10 Enterprise multisessions. Cette restriction signifie que :

  • Windows Autopilot et Commercial OOBE ne sont pas pris en charge.
  • La page d’état des inscriptions n’est pas prise en charge.

Conclusion

C’était un plaisir de tester cette nouvelle feature pour Azure Virtual Desktop. J’attends avec impatience que plus de polices soient disponibles pour les machines virtuelles en Windows 10 multisessions. Pensez à partager dans les commentaires vos autres sources d’apprentissage ! ????

Changer la taille du disque OS sur une machine virtuelle via [smalldisk] / Resize

Azure VM | Microsoft Power Automate

Des machines virtuelles sont créées en permanence sur Azure, et très régulièrement sur Windows Serveur. Sans se poser de question, le choix de l’image présélectionne sans votre avis la taille du disque OS, sans aucun pouvoir de modification.

Mais comment faire si l’on souhaite autre chose que la taille par défaut de 128GB pour notre lecteur C ?

Nous allons voir ensemble dans cet article les différentes possibilités, avant et après la création d’une machine virtuelle, pour changer très facilement la taille du disque OS.

Cas classique : Image Windows Server

Commençons par le cas standard, la création d’une machine virtuelle avec Windows Serveur entraîne la création d’un disque OS.

Sélectionnons ici par exemple une image source Windows Server 2019.

Dans le second onglet de création de la machine virtuelle, je n’ai pas de choix concernant la taille de mon disque OS :

Cet onglet me propose de choisir les performances du disque OS, mais pas sa taille. La taille est par contre bien un choix disponible sur les disques de données ajoutés.

Rappel : les performances du disque vont influer sur la SLA de la machine virtuelle, que vous pouvez retrouver en pourcentages ici.

Une fois la machine virtuelle créée, je ne peux que constater la taille de mon disque OS, assez facilement depuis la section des disques :

Un clique sur le disque OS vous amène sur sa page dédiée.

Redimensionnement du disque OS sur une machine virtuelle existante

Une alerte est mentionnée en haut de page : la taille d’un disque ne peut se faire que si ce dernier est détaché de la machine virtuelle ou que si cette dernière est éteinte :

Cas A : Redimensionnement à la baisse

Une fois la machine virtuelle arrêtée, un redimensionnement à la baisse va obligatoirement échouer, dans le but de prévenir la perte de données :

Erreur remontée par Azure au moment du redimensionnement à la baisse.

Cas B : Redimensionnement à la hausse

Cela ne sera pas le cas dans le cas d’un redimensionnement à la hausse, comme vous pouvez le voir en dessous :

La taille du disque OS a bien été augmentée. Notez que le nombre max d’IOPS a aussi fait un bon.

Dernière chose à faire, agrandir la partition du lecteur C directement depuis la machine virtuelle :

Comment faire donc pour effectuer pour disposer d’un lecteur C plus petite taille ? Sachant que l’OS est loin de remplir le lecteur C, plusieurs options s’offrent à nous :

  • Création d’une machine virtuelle avec une image portant la mention [smalldisk]
  • Redimensionnement du disque OS, après déploiement de la machine virtuelle

Remarque importante : Prenez garde avec la taille des disques, un disque trop réduit vous apportera peu d’IOPS et donc des performances disques insuffisantes :

Néanmoins, cette démarche peut être utile dans certains cas et donc générer une économie de coûts.

1er cas : Image Windows Server 2019 [smalldisk]

Si, avant la création de la machine virtuelle, vous savez déjà que votre disque C peut être plus réduit, vous pouvez alors partir sur des images spécifiques. Voici par exemple la liste des [smalldisk] disponibles pour Windows Serveur :

Si vous avez des difficultés de visualisation du nom complet des images, un passage du curseur sur un choix vous donnera son nom complet.

Une fois la machine provisionnée sur votre souscription Azure, vous constaterez que la taille du disque OS est de 30GB. Cette taille est donc plus réduite que la précédente. Vous pourrez toujours changer celle-ci à la hausse simplement en éteignant votre machine virtuelle.

Notez qu’une taille custom du disque entraine toujours une facturation égale à la taille supérieure : ici 32GB.

2ème cas : Redimensionnement du lecteur C puis du disque OS

Il arrive dans certains cas que la machine virtuelle existe déjà. Il va donc falloir commencer le processus par redimensionner le lecteur C. Je suis donc tombé sur cet excellent article (en anglais) et écrit par Jack Rudlin. Les étapes nécessaires pour y parvenir sont :

  • Réduction de la partition de l’OS dans Windows
  • Redimensionnement du disque OS dans Azure
  • Lancement du script sous PowerShell
  • Extension de la partition du système d’exploitation

Je recréé donc une nouvelle machine virtuelle, afin de faire avec vous cette opération de réduction « à chaud » :

Comme indiqué ici, la taille custom de mon disque OS est de 127GB.

Important : comme indiqué dans l’article de Jack et dans la source Microsoft, il est fortement recommandé de faire un snapshot du disque avant toute opération pour sauvegarder les données.

Dans un premier temps, nous nous connectons en RDP sur la machine virtuelle. Cet accès nous permet de changer la taille du lecteur C via un une première requête PowerShell, disposants des droits d’administration :

Get-Partition -DiskNumber 0

Cette requête nous donne le numéro de partition, utilisé après pour le redimensionnement.
La requête ci-dessus prend en compte le numéro du disque pour nous présenter les partitions associées.

Get-Partition -DiskNumber 0 -PartitionNumber 2 | Resize-Partition -Size 31GB

Cette simple commande redimensionne la partition du lecteur C.
L’effet de la requête est immédiatement visible 🙂
Existing Volumes
Comme indiqué sur le blog de Jack, vous pouvez rencontrer une erreur si la taille visée est trop petite.

La suite va se faire en dehors de la machine virtuelle. Il faut commencer par éteindre la machine virtuelle pour effectuer la copie des données :

Machine virtuelle arrêtée et dont les ressources ne sont plus allouées. Rappel : une désallocation des ressources entraînent un forte disque de perte des données disque D : temporaire.

Il donc falloir ici utiliser le module AZ sur votre poste via PowerShell pour continuer la suite des opérations. Voici une vidéo qui explique bien comment y arriver facilement :

Merci à David Lamb 🙂

La suite se fait avec le lancement du script donné par Jack, disponible depuis son GitHub via ce lien.

Aussi je vous conseille de passer par PowerShell ISE pour modifier facilement le script, car plusieurs variables vont devoir être modifiées :

  • Ressource ID du disque OS à modifier, que vous pouvez retrouver dans les propriétés du disque OS
  • Nom de la VM, que vous pouvez retrouver sur la page de la machine virtuelle
  • Nom de la souscription Azure, que vous pouvez retrouver sur la page de la machine virtuelle
Ressource ID du disque OS que vous pouvez retrouver dans les propriétés du disque OS.
Nom de la VM que vous pouvez retrouver sur la page de la machine virtuelle.
Nom de la souscription Azure que vous pouvez retrouver sur la page de la machine virtuelle.

Avant de lancer le script :

  • Celui-ci demande de posséder un certains nombres de droits pour effectuer toutes les tâches
  • Dans mon exemple (généralement non recommandé), j’ai utilisé un utilisateur avec le profil d’administrateur global du tenant Azure
  • A minima, vous devez disposer au moins des rôles de contributeur VM et de contributeur de compte de stockage dans Azure

Dans le détail, le script de Jack effectue les actions suivantes :

  • Création d’un compte de stockage temporaire
  • Création d’un container temporaire dans le nouveau compte de stockage
  • Copie du disque OS dans le compte de stockage temporaire sous forme de page blob
  • Modification la taille du page blob pour que le disque d’OS soit réduit
  • Reconversion du disque non managé en disque managé
  • Remplacement du disque OS actuel de la VM par le nouveau disque OS plus petit
  • Redémarrage de la machine virtuelle
  • Nettoyage du compte de stockage temporaire et de l’ancien disque managé

Le processus peut également être suivi depuis le portail Azure en constatant l’évolution du compte de stockage créé par le script de Jack :

Compte de stockage temporaire créé par le script.
Copie du disque OS en disque non managé (page blob).
Copie du disque non managé sur un second avec une taille réduite.
Suppression du page blob ayant la taille originale.
Un nouveau disque managé est créé à partir du dernier page blob et porte la mention « -new ».
Suppression du dernier page blob une fois la transformation faite en disque managé.
Comme on le constate sur la machine virtuelle utilisée dans mon exemple, le script détache l’ancien disque OS et rattache aussi le disque OS à taille réduite.
La machine virtuelle est redémarrée automatiquement par le script.
Suppression du compte de stockage temporaire en fin de script.

Il faut compter une bonne quinzaine de minutes pour que le script arrive à sa fin. Une connexion en RDP à cette dernière permet de réaliser la dernière étape du processus.

Compte tenu des volumes renseignés dans notre exemple, un reliquat d’espace est disponible sur le disque OS (522MB) :

Ce surplus peut être réintégré sur le lecteur C, comme indiqué sur cette image.
Fin de l’opération 🙂

Il faut donc compter au total une bonne vingtaine de minutes pour effectuer ce processus.

Conclusion

Il est donc bien possible de redimensionner un disque OS à plusieurs moments. Pensez toujours à faire des sauvegardes avant ce type d’opération ! Pensez à partager dans les commentaires vos autres sources d’apprentissage ????

Microsoft Security Operations Analyst (SC-200)

On continue notre apprentissage sur la sécurité Azure avec cette nouvelle certification Azure SC-200, sortie il y a peu. Pour rappel, cette dernière fait partie d’un ensemble de 4 certifications dédiées à la sécurité au sein du Cloud Microsoft. J’ai déjà détaillé plusieurs d’entre-elles sur ce blog :

Nul doute que Microsoft n’a pas encore fini de nous en apprendre sur la sécurité en 2021, et je m’attends comme d’autres à de nouvelles certifications dans ce domaine. Mais focalisations-nous maintenant sur cet examen, passé ce jour par votre serviteur 🙂

Comme toujours, voici les liens fort utiles pour toutes les informations associées :

Contenu de l’examen

Plus sérieusement, le contenu de l’examen est assez clair puisque 3 grandes thématiques sont listées ci-dessous, à savoir :

  • Microsoft 365 Defender (25-30%)
  • Azure Defender (25-30%)
  • Azure Sentinel (40-45%)

Comme on le comprend assez vite à l’aide des différents pourcentages associés à chaque rubrique, Azure Sentinel prend une place de premier ordre dans le nombre des questions que vous aurez à répondre pendant cet examen. Autant donc commencer par lui.

Azure Sentinel

Qu’est-ce qu’Azure Sentinel ?

Microsoft Azure Sentinel est une solution native cloud et scalable de type SIEM (Security Information and Event Management) et SOAR (Security Orchestrated Automated Response) . Azure Sentinel assure une analyse de sécurité intelligente et fournit des informations sur les menaces dans l’ensemble de l’entreprise. Elle constitue une solution unique pour la détection des alertes, la visibilité des menaces, la chasse proactive et la réponse face aux menaces.

La réponse complète de Microsoft ici
What's the difference between Azure Security Center, Azure Defender and  Azure Sentinel? - Microsoft Tech Community

Autrement dit, cette solution s’intègre parfaitement avec les différents outils du Cloud Microsoft dédiés à la sécurité. Il ne faut surtout pas donc voir Azure Sentinel comme un énième et redondant outil de sécurité, mais bien comme un véritable système avec des moyens concrets pour les membres de l’équipe SOC.

Ce slide met en évidence les rôles et les attentes entre Azure Security center et Azure Sentinel. D’un côté il va être question de collecter et de prévenir le risque, tandis que de l’autre il sera question de détecter, d’investiguer et de répondre aux menaces.

Si on doit résumer Azure Sentinel en quelques mots pour vous faire une idée, voici ce qu’Azure Sentinel est capable d’apporter pour votre sécurité :

  • Compilation de données via de nombreux connecteurs (plus d’une centaine à date)
  • Détection des menaces
  • Outils d’investigation des menaces
  • Moyens de réponses rapides

Quels seraient alors les bénéfices que vous pouvez retirer d’Azure Sentinel ?

  • Mise en place de tableaux de bord intuitifs
  • Possibilités infinies de requêtage
  • Mise en place d’automatisation des réponses face aux menaces
  • Exploitation de Microsoft Machine Learning pour accroitre les capacités de détection
  • Intégration complète de Microsoft Intelligent Security Graph
  • Installation « facile » selon les besoins de sécurité
Comme à chaque fois, merci à John pour ses vidéos plus que claires

Pour vous aider à « maîtriser » Azure Sentinel, Microsoft a découpé son parcours d’apprentissage en 5 parties :

Comme à chaque fois, j’ai pris le temps de suivre le parcours d’apprentissage afin de me faire une idée précise sur le contenu abordé et sur la qualité.

Comme pour la SC-300, je suis assez content du résultat, même si je trouve que les exercices donnés à travers les différentes parties se ressemblent énormément et ne vont pas assez loin dans les manipulations utilisateurs. J’aurais aimé avoir plus de cas variés à réaliser dans Azure Sentinel pour donner plus de sens à certaines fonctionnalités.

Principaux connecteurs du monde Azure avec leur périmètre.

A quoi s’attendre dans cet examen ?

Malheureusement pas de mystère, une maîtrise de la solution est attendue afin de voir que vous avez bien passé du temps dans la solution ! Il faut donc comprendre ses mécanismes, son utilisation au quotidien dans la gestion des rules / alertes / incidents / workbooks.

Categorizing Microsoft alerts across data sources in Azure Sentinel -  Microsoft Tech Community
On ne vous demandera pas de sortir la liste de tous les connecteurs ! Mais certains propres à l’environnement du Cloud Microsoft sont bien évidement à connaître.

Il faut donc s’attendre à coup sûr à :

  • Des questions sur Kusto Query Language (KQL). Prenez donc le temps pour le tester et vous familiariser au maximum avec les opérateurs
  • Des questions sur les principaux connecteurs de données (Azure et éventuellement AWS). Mettez en place un certain nombre de connecteurs afin comprendre leur intérêt et les données remontées
  • Des questions sur les relations entre rules / alertes / incidents / workbooks
  • Des questions sur la gestion automatisée d’une alerte avec les automations / playbooks
  • Des questions sur les rôles propres à Azure Sentinel
  • Des questions sur l’architecture d’Azure Sentinel ( X logs Analytics Workspaces + Azure Sentinel)

Bref pas mal de sujets à connaître, et il en reste encore d’autres qui peuvent aussi tomber :

  • Notebooks
  • Hunting
  • Workbooks
  • Entities

Cela peut représenter beaucoup, mais ne vous découragez pas ! 🙂

Azure Defender

Qu’est-ce qu’Azure Security Center ?

Azure Security Center est un système de gestion de la sécurité de l’infrastructure unifié qui renforce la posture de sécurité de vos centres de données et fournit une protection avancée contre les menaces pour vos charges de travail hybrides dans le cloud (dans Azure ou non), ainsi qu’en local.

Source Microsoft
Si Azure Security Center est quelque chose de nouveau pour vous, je vous conseille cette vidéo d’Adam.

Qu’est-ce qu’Azure Defender ?

Azure Defender offre une détection et une réponse étendues pour les charges de travail exécutées dans Azure, localement et dans d’autres clouds. Intégré à Azure Security Center, Azure Defender protège vos données hybrides, vos services cloud natifs ainsi que vos serveurs contre les menaces.

Les fonctionnalités d’Azure Security Center couvrent les deux piliers de la sécurité cloud :

Combien d’outils composent Azure Security Center ?

Voici donc comment cela s’articule entre ces deux outils qui au final n’en sont qu’un seul.

CSPM (gestion de la posture de sécurité cloud) – Security Center est disponible gratuitement pour tous les utilisateurs Azure. L’expérience gratuite comprend des fonctionnalités CSPM telles que le degré de sécurisation, la détection des erreurs de configuration de sécurité dans vos machines Azure, l’inventaire des ressources et bien plus encore. Utilisez ces fonctionnalités CSPM pour renforcer la posture de votre cloud hybride et suivre la conformité avec les stratégies intégrées.

Protection de charge de travail cloud (CWP) – La plateforme de protection de charge de travail cloud (CWPP), Azure Defender, garantit une protection avancée et intelligente de vos ressources et charges de travail Azure et hybrides. L’activation d’Azure Defender offre un large éventail de fonctionnalités de sécurité supplémentaires, tel que décrit sur cette page. Outre les stratégies intégrées, lorsqu’un plan Azure Defender est activé, vous pouvez ajouter des stratégies et des initiatives personnalisées. Vous pouvez ajouter des normes réglementaires, telles que NIST et Azure CIS, ainsi que le Benchmark de sécurité Azure pour un aperçu véritablement personnalisé de votre conformité.

Source Microsoft
Une fois Azure Defender activé, on retrouve un tableau de bord des ressourcées protégées ou non par type.
Seconde vidéo dédiée à Azure Defender.

Un seul chapitre est uniquement présent pour Azure Defender, il va falloir chercher plus loin et passer du temps dans la solution :

A quoi s’attendre dans cet examen ?

Je ne vais pas le répéter, mais toujours une connaissance précise de la solution 😉

Voici quelques pistes à explorer pour se sentir à l’aise dans l’examen :

  • Des questions sur les résultats des polices compliances
  • Des questions sur la gestion des alertes / recommandations ouvertes par Azure Defender
  • Des questions sur le traitement des vulnérabilités découvertes par Azure Defender
  • Des questions sur l’activation de contre-mesures sur les ressources surveillées par Azure Defender (Machines virtuelles, Key Vaults, Comptes de stockage, Bases SQL, …)
  • Des questions sur les rôles nécessaires pour les opérateurs d’Azure Defender
  • Des questions sur les processus d’on-boarding et les contrôles associés

Cela peut représenter beaucoup, mais ne vous redécouragez pas ! 🙂

Microsoft 365 Defender

Qu’est-ce que Microsoft 365 Defender ?

Microsoft 365 Defender unifie votre processus de réponse aux incidents en intégrant des fonctionnalités clés dans Microsoft Defender pour le point de terminaison, Microsoft Defender pour Office 365, Microsoft Cloud App Security et Microsoft Defender pour l’identité. Cette expérience unifiée ajoute des fonctionnalités puissantes auxquelles vous pouvez accéder dans le Centre de sécurité Microsoft 365.

Source Microsoft
Microsoft Defender pour point de terminaison, Microsoft 365
On parle donc ici d’une solution unifiée au travers d’un nouveau portail.
  • Points de terminaison avec Microsoft Defender pour Endpoints– Microsoft Defender pour Endpoints est une plateforme de point de terminaison unifiée pour la protection préventive, la détection post-violation, l’examen automatisé et la réponse.
  • E-mail et collaboration avec Microsoft Defender pour Office 365 – Defender pour Office 365 protège votre organisation contre les menaces malveillantes posées par les messages électroniques, les liens (URL) et les outils de collaboration. Identités avec
  • Microsoft Defender pour l’identité et Azure AD Identity Protection – Microsoft Defender pour l’identité utilise les signaux Active Directory pour identifier, détecter et examiner les menaces avancées, les identités compromises et les actions internes malveillantes dirigées contre votre organisation.
  • Applications avec sécurité Microsoft Cloud App : la sécurité de Microsoft Cloud App est une solution SaaS complète qui apporte une visibilité approfondie, des contrôles de données forts et une protection renforcée contre les menaces à vos applications cloud.

Attention à ne pas vous perdre avec certaines anciennes dénominations :

  • Microsoft 365 Defender (précédemment Microsoft Threat Protection)
  • Microsoft Defender for Endpoint (précédemment Microsoft Defender Advanced Threat Protection)
  • Microsoft Defender for Office 365 (précédemment Office 365 Advanced Threat Protection)
  • Microsoft Defender for Identity (précédemment Azure Advanced Threat Protection)
Encore une fois, il ne s’agit pas de solutions qui ne se chevauchent, mais bien complémentaires.
Merci Jean-Sébastien 😉

Deux chapitres sont présents pour Microsoft 365 Defender. Encore une fois il va falloir chercher plus loin et passer du temps dans la solution pour avoir une idée de tous ces outils :

A quoi s’attendre dans cet examen ?

  • Des questions sur Cloud App Security et des polices mises en place
  • Des questions sur le shadow IT, mettant en évidence les applications découvertes via Cloud App Security
  • Des questions sur Azure Information Protection dans le cadre de la politique d’Office365
  • Des questions sur les périphériques surveillés par la partie Defender for Endpoints et les risques détectés
  • Des questions sur le risques liés aux identités et donc gérés par Defender for Identity

Conclusion

Cette certification comble un espace non occupé jusqu’à présent, car elle apporte de vraies réponses techniques à un grand nombre de défis de sécurité qui touchent les entreprises. La sécurité est bien une affaire multicouche et multidirectionnelle. Comme toujours, pensez à partager dans les commentaires vos autres sources d’apprentissage, ou votre feedback sur l’examen ????

AVD – Démarrage des VMs à la demande

Annoncé fin mars 2021 pour les environnements personnels Azure Virtual Desktop, Azure Preview propose maintenant cette même fonction pour les environnements AVD mutualisés (Pooled).

Voici un petit rappel de la solution par Dean d’Azure Academy.

La vidéo de Dean met en oeuvre la solution sur un environnement AVD personnel, qui fonctionne aussi pour les environnements mutualisés, et applique les point suivants :

  • Activation de l’option « Start VM On Connect » sur le Host Pool
  • Création d’un rôle custom pour donner le droit à AVD de démarrer les VMs
  • Affectation du rôle custom à la souscription ou au groupe de ressources
  • Déconnexion des sessions inactives via GPO
  • Activation de l’arrêt automatique des machines virtuelles à une heure fixe

Mise en place : La mise en place de cette solution est bien expliquée dans la vidéo de Dean, vous pouvez aussi suivre la documentation de Microsoft juste ici.

Rappel : La fonction est encore en public preview pour les environnements AVD mutualisés, il faut donc utiliser le portail adéquat.

Testez vous-même

De mon côté, j’ai souhaité tester la solution sur différents cas de figure :

  • Test sur un AVD en mode personnalisé : OK
  • Test sur un AVD en mode mutualisé (Windows 10 multisession) : OK
  • Test sur un AVD en mode mutualisé (Windows Server 2019) : OK

J’ai aussi fait un test plus poussé dans le cadre d’un environnement AVD mutualisé comprenant plusieurs machines virtuelles :

  • Nombre de machines virtuelles : 2
  • Algorithme d’équilibrage de charge : Breadth-first
  • Nombre maximal de sessions : 5

Voici ce qui s’est passé au niveau des machines virtuelles :

Environnement de départ, toutes les VMs sont OFF.
Connexion du premier utilisateur, une seule VM s’allume.
Connexion du second utilisateur, la seconde VM ne s’allume pas car l’utilisateur se retrouve connecté à la première VM.

J’ai donc refait un autre test en modifiant le nombre maximal de sessions :

  • Nombre de machines virtuelles : 2
  • Algorithme d’équilibrage de charge : Breadth-first
  • Nombre maximal de sessions : 1

Les premières étapes n’ont pas changé, mais j’ai bien eu autre chose lorsque le second utilisateur a tenté de se connecter :

Le second utilisateur doit bien attendre le démarrage de la seconde VM pour s’y connecter.
Les deux VMs sont bien allumées dans ce cas.

Conclusion

Au final, la fonctionnalité est bien opérationnelle et s’adapte bien à différents cas d’architecture Azure Virtual Desktop. Seul petit bémol concernant la fonction Breadth-first qui demande encore quelques ajustements pour bien allumer les autres VMs afin de répartir les utilisateurs ????

Certification Microsoft Identity and Access Administrator (SC-300)

Preparing for the SC-300: Microsoft Identity and Access Administrator exam  (May 2021) – intunedin.net

Voici un nouvel article sur les dernières certifications de sécurité sur le Cloud Azure de Microsoft. Pour rappel, vous pouvez retrouver mon article sur la certification fondamentale SC-900 ici, ainsi que sa page officielle Microsoft juste .

Que dire sur ce nouvel examen SC-300 ?

Là encore, vous pouvez retrouver tous les détails de cette dernière sur sa page officielle Microsoft.

J’ai passé cette certification de niveau Associate cette semaine. Pendant et juste après cet examen, j’ai trouvé la certification assez difficile, car elle exigeait beaucoup de mises en situation, requérant des connaissances assez précises sur les sujets que je vais essayer vous détailler tout au long de cet article.

Finalement aucun doute, la SC-300 est bien une certification de niveau Associate. Pour un peu moins la moitié des questions environ, j’avais encore un petit doute entre 2 réponses sur 4.

Dans cet examen, attendez-vous donc à :

  • Beaucoup de questions contextualisées avec 4 choix possibles
  • Des questions groupées avec OUI / NON
  • Peu de questions sur la restitution des grands principes (points faciles à ne pas négliger)
  • Un ou deux use-cases portant sur des architectures hybrides
  • Et toujours pas de labs

Que retrouve-t-on dans le Parcours d’apprentissage de la SC-300?

Le parcours d’apprentissage reprend de manière méthodique les principaux chapitres rattachés à cette certification. Une fois n’est pas coutume, j’ai suivi tous les modules de formations proposés par Microsoft.

Pourquoi cela ? Car le contenu trouvé sur internet est encore assez variable à date ou incomplet.

Au final, j’ai trouvé le parcours très bien construit autour de cette certification. Beaucoup de schémas explicatifs, de copies d’écran d’Azure et de vidéos d’introduction. De plus, les exercices pratiques avaient toujours du sens sur le thème abordé.

En revanche, ne vous faites pas avoir en ne vous basant que sur celui-ci ! Pour avoir être sûr d’avoir plus de points que les 700 nécessaires, il vous faudra avoir :

  • Les connaissances acquises par l’expérience dans Azure AD
  • A défaut de tout connaitre dans les moindre détails, une bonne dose déduction pour ne garder que les « réponses possibles »

Voici un rappel des modules du parcours avec leurs liens :

Voici également quelques blogs qui pourront vous aider dans votre apprentissage de cette SC-300 :

Rien à voir ici, mais je suis en train de manger une pizza maison 😉

Implémenter une solution de gestion des identités

Mettre en œuvre la configuration initiale d’Azure Active Directory

On arrive ici dans le cœur du sujet de cette certification :

L’identité est au centre d’Azure Active Directory et vous devez la comprendre et la maîtriser sous tous ses aspects

Plus question ici de restituer la « simple » compréhension du service ou de ses fonctionnalités. Il faut savoir l’utiliser selon différents cas de figure. Attendez-vous donc à avoir des questions sur les identités dans un contexte très précis. Peu de pièges, mais on attend des connaissances.

Par exemple, la question pourrait porter sur un type d’identité particulier avec un scénario de droits spécifiques de manière combinée. Rien de tel alors que de se refaire un passage sur les identités Azure :

Merci à John Savill 🙂

L’autre exemple serait de devoir choisir le rôle ayant le moins de privilège pour faire telles ou telles actions dans Azure AD. Ce point-ci est assez difficile car la connaissance globale des rôles sera nécessaire pour être vraiment sûr de la bonne réponse. Voici liste complète et quelques rôles pris au hasard :

La gestion des domaines personnalisés revient souvent dans beaucoup de certifications sur Azure. C’est l’occasion de marquer des points facilement en connaissant bien le processus d’ajout de domaines personnalisés :

  • Ajout du domaine personnalisé dans Azure AD
  • Modification des enregistrements DNS
  • Vérification du domain dans Azure AD
  • Utiliser le nom de domaine pour les utilisateurs, adresses mails ou autres besoins

Même si la gestion des appareils est plutôt une tache dédiée à Endpoint admin center, certaines actions et donc certaines questions peuvent vous être posées ici.

Who are you ?

Il faut avant tout bien maîtriser les concepts de jointures des devices dans Azure, comme par exemple l’hybrid join :

Appareils joints Azure AD hybrides.
Dans Windows Virtual Desktop, l’hybrid join va permettre le SSO pour une meilleure expérience utilisateur.

Les unités administratives dans Azure AD est un concept intéressant, car elles limitent les autorisations d’un rôle en fonction du service auquel il appartient au sein de l’organisation :

Azure Administrative Units and MyStaff for delegated management | Marius  Sandbu
Principe de délégation des rôles selon des unités organisationnelles dans Azure AD.
Sécurité par défaut d’Azure AD

Azure AD propose un mode de gestion de sécurité par défaut. Sa mise en place est des plus simple, mais il n’autorise aucune personnalisation.

Les paramètres de sécurité par défaut facilitent la protection de votre organisation contre ces attaques avec des paramètres de sécurité préconfigurés :

  • Exige que tous les utilisateurs s’inscrivent à Azure AD Multi-Factor Authentication
  • Exige des administrateurs qu’ils effectuent l’authentification multifacteur
  • Restreint les anciens protocoles d’authentification
  • Exige des utilisateurs qu’ils effectuent l’authentification multifacteur
  • Restreint des activités, telles que l’accès au Portail Azure

Gestion des utilisateurs, des groupes et des licences

Quoi de mieux comme question que celle ci-dessous :

Des licences sont attribuées à un groupe d’utilisateurs et celui-ci contient des utilisateurs et d’autres groupes. Combien de licences seront attribuées ?

Un début de réponse dans cette article !

De manière générale et hormis des questions de ce type, il s’agit de points faciles.

Mettre en œuvre et gérer les identités externes

Les identités externes font parties de beaucoup de scénarios d’Azure AD, il faut donc maîtriser leur intégration et les options de sécurités les concernant :

Je ne vous dis pas d’aller pas jusqu’à connaitre les en-têtes du fichier CSV d’import bulk 😉

  • Email address to invite
  • Redirection url
  • Send invitation message
  • Customized invitation message

Mettre en œuvre et gérer l’identité hybride

On cherche donc à savoir si les différentes méthodes de synchronisation entre un environnement on-premise et le Cloud n’ont plus de secrets pour vous. Ce module comporte donc les grands sujets ci-dessous :

Pas de mystère ici, le mieux étant d’avoir pu installer soi-même AD Connect sur un environnement on-premise (Active Directory), et d’avoir testé plusieurs scénarios afin d’en mesurer les impacts (avantages – inconvénients) :

Tour d’horizon d’Azure AD Connect par l’Azure Academy

C’est typiquement lors des use-cases que vous devrez maîtriser ces concepts pour proposer la solution la plus attendue :

Mettre en œuvre une solution d’authentification et de gestion des accès

Planifier et mettre en œuvre l’authentification multifactorielle Azure (MFA)

L’authentification multifacteur est un processus dans lequel l’utilisateur est invité pendant le processus de connexion à suivre une forme d’identification supplémentaire, consistant par exemple à entrer un code sur son téléphone portable ou à scanner son empreinte digitale.

Illustration conceptuelle des éléments de MFA

Les 3 piliers de la MFA 🙂

  • Quelque chose que vous connaissez – Il pourrait s’agir d’un mot de passe ou de la réponse à une question de sécurité
  • Quelque chose que vous possédez – Il pourrait s’agir d’une application mobile qui reçoit une notification ou un d’appareil de génération de jetons
  • Quelque chose que vous êtes – En général, il s’agit d’une propriété biométrique, comme la détection du visage ou des empreintes digitales utilisée sur de nombreux appareils mobiles
Cette vidéo explique étape par étape le processus de mise en place de la MFA

Quelles seraient les questions possibles dans cette certification ? Il faut voir la MFA comme un point combiné avec d’autres facteurs, comme par exemple son impact dans un accès conditionnel, ou alors son rôle dans Azure AD Identity Protection.

Close the gap. Azure AD Identity Protection & Conditional Access. -  JanBakker.tech
Deux facteurs sont représentés ici : sign-in risk et user risk.
la MFA va jouer un rôle de sécurité important.

Gérer l’authentification des utilisateurs

Dans Azure Active Directory, l’authentification implique plus que la simple vérification d’un nom d’utilisateur et d’un mot de passe. Pour améliorer la sécurité et réduire le recours à l’assistance du support technique, l’authentification Azure AD comprend les composants suivants :

Tableau des avantages et des méthodes d’authentification préférées dans Azure AD
Les méthodes d’authentification sans mot de passe telles que Windows Hello, les clés de sécurité FIDO2 et l’application Microsoft Authenticator permettent les événements de connexion les plus sécurisés.

Attendez-vous donc à des question sur les méthodes possibles pour les utilisateurs lors d’un processus de réinitialisation de mot de passe libre-service :

  • Notification sur l’application mobile
  • Code de l’application mobile
  • E-mail
  • Téléphone mobile
  • Téléphone de bureau
  • Questions de sécurité

Ou sur les différentes méthodes possibles pour enregistrer une MFA :

Comment les composants de protection par mot de passe Azure AD fonctionnent ensemble
Password Protection : j‘avais fait une blague sur ce schéma pour la SC-900.
Ici c’est bien un concept à connaitre, et idéalement de l’avoir essayé pour différencier les rôles et les agents à installer
.

Planifier, mettre en œuvre et administrer l’accès conditionnel

Vous pouvez utiliser des stratégies d’accès conditionnel pour appliquer des contrôles d’accès tels que l’authentification multifacteur (MFA). Vous aurez à coup sûr des questions impliquant la MFA. le cas classique est d’identifier quel facteur modifier pour activer une MFA, selon les exigences données par le contexte.

Conditional Access overview
Les stratégies d’accès conditionnel vous permettent d’inviter des utilisateurs à l’authentification multifacteur lorsque cela est nécessaire pour la sécurité et à ne pas le leur demander lorsque cela n’est pas nécessaire.

L’accès conditionnel est un premier outil que l’on met en place pour augmenter la sécurité sur Azure. Par exemple, la gestion des localisation peut être un point très important pour améliorer l’expérience utilisateur :

  • En évitant « d’harceler » les utilisateurs avec un contrôle MFA lorsque l’on se trouve au bureau
  • En imposant la MFA si l’utilisateur se connecte depuis un appareil non compliant

L’infrastructure d’accès conditionnel vous offre une grande flexibilité de configuration. Toutefois, une grande flexibilité implique également que vous examiniez soigneusement chaque stratégie de configuration avant de la mettre en œuvre, afin d’éviter des résultats indésirables.

Image de l’écran affichant un accès aux ressources bloqué en raison d’une stratégie d’accès conditionnel activée
Message issu de l’accès conditionnel, bloquant pour l’utilisateur

Gérer Azure AD Identity Protection

Identity Protection est un outil qui permet aux organisations d’accomplir trois tâches principales :

  • Automatiser la détection et la correction des risques liés à l’identité
  • Examiner les risques à l’aide des données disponibles sur le portail
  • Exporter les données de détection des risques vers des utilitaires tiers pour une analyse plus approfondie

Ici encore, des questions seront possible pour savoir ce qui se passera si l’utilisateur déclenche une alerte :

  • Réinitialisation du mot de passe ?
  • Demande de vérification MFA ?
Azure AD utilise l’apprentissage automatique pour détecter les anomalies et les activités suspectes, en utilisant à la fois des signaux détectés en temps réel pendant les ouvertures de session et des signaux en temps différé liés aux utilisateurs et à leurs activités d’ouverture de session.

Implement Access Management for Apps

Il s’agit ici du chapitre de la certification le plus faiblement noté. Il s’agissait aussi de celui que je maîtrisais le moins :D. Je n’ai pas eu beaucoup de questions, mais c’est toujours bon d’éviter de perdre des points dessus.

Planifier, mettre en œuvre et surveiller l’intégration des applications d’entreprise pour l’authentification unique (SSO)

Je ne vais pas trop m’étendre sur cette section.

Autre sujet de sécurité œuvrant sur les applications d’entreprise : Cloud App Security

Cloud App Security intègre la visibilité à votre cloud pour mapper et identifier votre environnement cloud et les applications cloud utilisées par votre organisation en utilisant des connecteurs faciles à déployer :

Schéma de l’architecture Cloud App Security.

Mettre en œuvre les enregistrements d’applications

Je n’ai rien de trouvé de plus explicatif que cette très bonne vidéo de John Savill :

A regarder en entier ! 🙂

Planifier et implémenter une stratégie de gouvernance des identités

On arrive au dernier chapitre … Aussi je vous conseille de ne pas négliger cette section car le pourcentage est assez important pour cette dernière sur cet examen.

De plus, je me rappelle avoir eu plusieurs questions dessus. Rien de vraiment compliqué ici, mais une bonne connaissances des outils devrait faire l’affaire.

Planifier et mettre en œuvre la gestion des droits

Il s’agit ici d’un sujet que je n’avais jamais abordé avant cette certification. J’ai pu donc découvrir et tester ce principe par le biais de la révision, et j’ai eu plusieurs questions portant sur la stratégie d’attribution des droits.

All about CIAM
Finalement le concept est assez simple car il apporte plus de clarté dans l’approvisionnement des services pour les employées et le déprovisionnement pour ces derniers quand leur mission est terminée.

La gestion des droits d’utilisation introduit sur Azure AD le concept de package d’accès. Un package d’accès regroupe toutes les ressources avec l’accès dont un utilisateur a besoin pour travailler sur un projet ou accomplir sa tâche. Les packages d’accès permettent de régir l’accès de vos employés et utilisateurs internes en dehors de votre organisation. Vous pouvez gérer l’accès des utilisateurs aux ressources suivantes avec la gestion des droits d’utilisation.

What is entitlement management? - Azure AD | Microsoft Docs
Le diagramme suivant montre un exemple des différents éléments en matière de gestion des droits d’utilisation.

Une connaissances des termes et de leurs rapports entre eux est donc fort utile :

TermeDescription
package d’accèsBundle de ressources dont une équipe ou un projet a besoin et qui est régi par des stratégies. Un package d’accès est toujours contenu dans un catalogue. Vous créez un package d’accès pour un scénario dans lequel les utilisateurs doivent demander l’accès.
demande d’accèsDemande d’accès aux ressources dans un package d’accès. Cette demande transite généralement par un flux d’approbation. Si elle est approuvée, l’utilisateur demandeur reçoit une affectation de package d’accès.
affectationL’affectation d’un package d’accès à un utilisateur garantit que l’utilisateur dispose de tous les rôles de ressources de ce package d’accès. Les affectations de package d’accès ont généralement une durée limite avant leur expiration.
catalogueConteneur de ressources connexes et de packages d’accès. Les catalogues sont utilisés pour la délégation, si bien que les non-administrateurs peuvent créer leurs propres packages d’accès. Les propriétaires de catalogue peuvent ajouter les ressources qu’ils possèdent à un catalogue.
créateur de catalogueRegroupement d’utilisateurs autorisés à créer des catalogues. Lorsqu’un utilisateur non-administrateur, autorisé à être créateur de catalogue, crée un catalogue, il devient automatiquement le propriétaire de ce catalogue.
organisation connectéeDomaine ou annuaire Azure AD externe avec lequel vous avez une relation. Les utilisateurs provenant d’une organisation connectée peuvent être spécifiés dans une stratégie comme étant autorisés à demander l’accès.
policeEnsemble de règles définissant le cycle de vie d’un accès, telles que le mode d’accès des utilisateurs, les approbateurs et la durée d’accès par le biais d’une affectation. Une stratégie est liée à un package d’accès. Par exemple, un package d’accès peut avoir deux stratégies de demande d’accès : l’une pour les employés, l’autre pour les utilisateurs externes.
ressourceRessource (un groupe Office, un groupe de sécurité, une application ou un site SharePoint Online, par exemple) dotée d’un rôle pour lequel un utilisateur peut obtenir des autorisations.
répertoire de ressourcesRépertoire comprenant une ou plusieurs ressources à partager.
rôle de ressourceCollection d’autorisations associées à une ressource et définies par elle. Un groupe a deux rôles : membre et propriétaire. Les sites SharePoint ont généralement trois rôles, mais peuvent avoir des rôles personnalisés supplémentaires. Les applications peuvent avoir plusieurs rôles personnalisés.

Planifier, implémenter et gérer la révision d’accès

Les révisions d’accès Azure Active Directory permettent aux organisations de gérer efficacement les appartenances à des groupes, les accès aux applications d’entreprise et les attributions de rôles. Je vous confirme avoir eu des questions sur la revue d’accès. Le processus n’est pas très compliqué. Quelques petits rappels :

  • Aucun résultat n’est appliqué avant la fin de la période de revue ou si le créateur stoppe et applique les résultats lui-même
  • Un accès pour un utilisateur (révoqué ou conservé) peut être changé plusieurs fois pendant la période de revue d’accès. Seul le dernier statut sera conservé et appliqué
L’accès des utilisateurs peut être passé en revue régulièrement pour vérifier que seules les personnes appropriées continuent de bénéficier d’un accès.
Plan an Azure Active Directory Access Reviews deployment | Microsoft Docs
Process de revue d’accès en 3 étapes : tout commence par la création de la revue, puis la validation et enfin l’application des résultats.

Planifier et mettre en œuvre l’accès privilégié

Privileged Identity Management est un service dans Azure Active Directory (Azure AD) qui vous permet de gérer, de contrôler et de superviser l’accès aux ressources importantes de votre organisation :

Je me souviens avoir eu une question sur un rôle devant passer sous attribution via Privileged Identity Management. Connaître les différentes étapes est donc important pour mettre en œuvre le processus et son utilisations par les demandeurs de droits.

Comment PIM fonctionne ?

Surveiller et gérer les Azure Active Directory

Les journaux d’audit et de diagnostic d’Azure Active Directory fournissent une vue détaillée de la façon dont les utilisateurs accèdent à votre solution Azure. Découvrez comment surveiller, dépanner et analyser les données de connexion.

L’architecture de création de rapports dans Azure AD comprend les composants suivants :

  • Activité
    • Connexions : Il s’agit d’informations sur l’utilisation des applications managées et les activités de connexion des utilisateurs.
    • Journaux d’audit : Fournissent des informations sur les activités du système liées aux utilisateurs et à la gestion des groupes, les applications gérées et les activités de répertoire.
    • Les journaux de provisionnement : permettent aux clients de superviser l’activité effectuée par le service de provisionnement, telle que la création d’un groupe dans ServiceNow ou l’importation d’un utilisateur à partir de Workday.
  • Sécurité
    • Connexions risquées : une connexion risquée correspond à un indicateur de tentative de connexion d’un utilisateur autre que le propriétaire légitime d’un compte d’utilisateur.
    • Utilisateurs avec indicateur de risque : il s’agit d’un compte d’utilisateur susceptible d’être compromis.

Des questions sur la rétention peuvent tomber, gardez donc en tête ces durées de rétention :

Rapports d’activité
RapportAzure AD GratuitAzure AD Premium P1Azure AD Premium P2
Journaux d’audit7 jours30 jours30 jours
Connexions7 jours30 jours30 jours
Utilisation d’Azure AD MFA30 jours30 jours30 jours

Signaux de sécurité

RapportAzure AD GratuitAzure AD Premium P1Azure AD Premium P2
Les utilisateurs à risque7 jours30 jours90 jours
Connexions risquées7 jours30 jours90 jours

Conclusion

Cette certification apporte donc un véritable tour d’horizon sur la sécurité dans Azure Active Directory. Je peux dire avec certitude qu’il y n’y pas beaucoup de notions croisées avec les certifications AZ-500 et MS-500. Elle permettra donc de valider vos connaissances sur la gestion des identités dans le Cloud.

Mes derniers conseils

  • Prenez surtout le temps de bien tester chaque module dans un environnement de test pour en connaître le fonctionnement et en mesurer les impacts
  • Etant souvent dans des environnements de tests, on néglige assez régulièrement les rôles préconstruit dans Azure Active Directory. La sécurité passe par une gestion mesurée des droits des administrations. Lisez donc leurs droits et testez-les !

Aujourd’hui, nous sommes le 1er mai, il faut donc lâcher un peu ses révisions et se vider l’esprit 😀

Pensez à partager dans les commentaires vos autres sources d’apprentissage, ou votre feedback sur l’examen. ????