OneDrive & RemoteApp AVD

Azure Virtual Desktop intègre OneDrive depuis déjà quelques années, que ce soit via le bureau à distance ou les applications sous RemoteApp. Mais Microsoft améliore l’expérience utilisateur dans le cadre des applications lancées RemoteApp (publication d’applications sans bureau Windows).

En effet, il est possible de monter la ressource OneDrive liée au compte AVD automatiquement sur le poste local ! Concrètement, l’utilisateur ouvre son application RemoteApp et aura accès à OneDrive depuis son application ou son poste local.

Vous pouvez utiliser Microsoft OneDrive avec une RemoteApp dans Azure Virtual Desktop (preview), ce qui permet aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp. Lorsqu’un utilisateur se connecte à une RemoteApp, OneDrive peut être lancé automatiquement en tant que compagnon de la RemoteApp.

Microsoft Learn

Cette fonctionnalité ajoutée il y a quelques jours est disponible en préversion publique, comme le dit l’annonce faite par Microsoft sur son Tech Community.

La documentation Microsoft spécifie les quelques ressources indispensables pour utiliser la fonctionnalité, à l’heure où ces lignes sont écrites :

Pour mes tests, je n’ai eu besoin d’installer FSLogix, mais nul doute que la dernière version de celui-ci doit être installée pour que la gestion des profils en itinérance se fasse correctement avec le nouveau comportement de OneDrive.

Afin d’en savoir un peu plus, je vous propose de réaliser un petit exercice ensemble :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur OneDrive au travers Azure Virtual Desktop en mode RemoteApp, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Déploiement de l’environnement AVD :

Avant tout chose, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

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

Une fois le déploiement terminé, cliquez-ici pour y déployer le service Azure Bastion :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Sans attendre la fin du déploiement d’Azure Bastion, créez une machine virtuelle en Windows 11 sur le même réseau virtuel, sans y configurer d’options particulières :

Cette VM de test va nous servir à simuler notre poste local où nous lancerons l’application AVD en RemoteApp.

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

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

Activez l’option Validation de l’environnement AVD, puis cliquez sur Suivant :

Choisissez dans la liste des images Microsoft l’image Windows 11, version 22H2 :

Indiquez le nombre de VMs AVD, puis réutilisez le réseau virtuel Azure créé précédemment :

Joignez vos VMs AVD à Entra ID, puis cliquez sur Suivant :

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

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

Une fois le déploiement d’Azure Virtual Desktop entièrement terminé, cliquez-ici pour continuer sa configuration :

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

Créez un nouveau groupe d’applications AVD pour effectuer le test de l’application ouverte en RemoteApp :

Renseignez les informations de base, puis cliquez sur Suivant :

Ajoutez une application accessible depuis le menu Démarrer de votre VM AVD, puis cliquez sur Suivant :

Inutile de renseigner des utilisateurs à notre groupe d’applications, cliquez sur Suivant :

Associez votre nouveau groupe d’applications à votre espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du groupe d’applications AVD, puis attendez environ 1 minute :

Une fois le déploiement terminé, cliquez sur le groupe de ressources commun à tous les déploiements antérieurs :

Ajoutez-y les 2 rôles RBAC suivants à un ou plusieurs utilisateurs de test AVD :

Retournez sur la machine virtuelle de test simulant le poste local, puis ouvrez une session de bureau à distance via Azure Bastion, en utilisant les identifiants administrateurs renseignés lors de la création de celle-ci :

Depuis cette VM, téléchargez le client Remote Desktop depuis cette page officielle Microsoft, puis ouvrez l’application avec votre utilisateur de test AVD :

Lancez l’application configurée en RemoteApp :

Authentifiez-vous encore une fois avec un compte AVD de test :

Constatez l‘absence de configuration OneDrive dans l’application RemoteApp, mais aussi au niveau de la VM de test simulant le poste local :

Fermez l’application en RemoteApp.

Nous environnement de départ est en place. Nous allons pouvoir effectuer la configuration cible en commençant par l’installation de OneDrive.

Etape II – Configuration de OneDrive :

Depuis votre portail Azure, ouvrez une seconde session Bastion sur la VM AVD, en utilisant les identifiants administrateurs renseignés lors de la création celle-ci :

Sur la machine AVD, téléchargez OneDrive via la page officielle Microsoft :

Ouvrez une fenêtre PowerShell, en mode administrateur, puis exécutez-y la commande suivante dans le dossier de téléchargement de votre utilisateur :

.\OneDriveSetup.exe /allusers

Attendez que l’installation de OneDrive se termine :

Contrôler que l’installation de OneDrive est bien en mode ALLUSER par la présence de la clef de registre suivante :

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OneDrive

Retournez sur le portail Azure afin de récupérer le Tenant ID de votre tenant :

Retournez sur la fenêtre PowerShell de votre VM AVD, puis lancez le script suivant en prenant le soin de renseigner votre Tenant ID dans la variable $TenantGUID :

$HKLMregistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\OneDrive'##Path to HKLM keys
$DiskSizeregistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\OneDrive\DiskSpaceCheckThresholdMB'##Path to max disk size key
$TenantGUID = 'XXXXXXXXXXXXX'

if(!(Test-Path $HKLMregistryPath)){New-Item -Path $HKLMregistryPath -Force}
if(!(Test-Path $DiskSizeregistryPath)){New-Item -Path $DiskSizeregistryPath -Force}

New-ItemProperty -Path $HKLMregistryPath -Name 'SilentAccountConfig' -Value '1' -PropertyType DWORD -Force | Out-Null ##Enable silent account configuration
New-ItemProperty -Path $DiskSizeregistryPath -Name $TenantGUID -Value '102400' -PropertyType DWORD -Force | Out-Null ##Set max OneDrive threshold before prompting

Vérifiez la bonne exécution de celui-ci :

Sur la machine de test local, ouvrez une session de bureau à distance depuis l’application Remote Desktop AVD :

Acceptez la finalisation de la configuration SSO entre Entra ID et la VM AVD :

Vérifiez que l’authentification automatique de OneDrive fonctionne et que la synchronisation des fichiers OneDrive démarre bien :

Contrôlez également la présence des fichiers OneDrive depuis l’explorateur de fichiers Windows :

De retour sur la session administrateur de la VM AVD ouverte via Azure Bastion, lancez le script PowerShell suivant :

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name OneDrive -PropertyType String -Value '"C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background' -Force

La commande effectuée va permettre de laisser fonctionner OneDrive en tâche de fond lorsque l’application en RemoteApp est démarrée :

La configuration de OneDrive sur notre machine virtuelle AVD est terminée.

Pour que tout fonctionne correctement, la version de Windows de la VM AVD doit être supérieure ou égale à la 25905.

Pour cela, nous avons besoin de rejoindre programme Windows Insider de Windows 11.

Etape III – Installation du Programme Windows Insider :

Sur la session administrateur de votre VM AVD, retournez dans les paramétrages Windows :

Cliquez-ici pour rejoindre le programme Windows Insider :

Avant de pouvoir rejoindre le programme Windows Insider, cliquez sur l’alerte afin d’activer la remontée de données de diagnostic :

Activez l’option, puis retournez sur la page principale des paramètres Windows :

Cliquez sur Commencer afin d’activer le programme Windows Insider :

Utilisez le compte de votre utilisateur AVD pour rejoindre le programme :

Renseignez ses identifiants :

Choisissez le canal Canary, puis cliquez sur Continuer :

Considérez si besoin les particularités du canal Canary, puis cliquez sur Continuer :

Cliquez sur Continuer pour accepter les conditions du programme liées à votre poste :

Redémarrez la VM de test AVD :

Retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour, dont celles-ci :

Une fois l’installation terminée, lancez une redémarrage de la VM AVD :

Quelques minutes plus tard, vérifiez via la session ouverte sur Azure Bastion que votre VM AVD est dans la bonne version de Windows 11 :

Notre environnement est enfin prêt et fonctionnel pour tester OneDrive en version RemoteApp.

Il ne nous reste plus qu’à effectuer des tests RemoteApp grâce à notre utilisateur AVD.

Etape IV – Test de OneDrive en RemoteApp :

Retournez sur la session ouverte sur la VM de test local ouverte via Azure Bastion, puis réouvrez l’application configurée en RemoteApp :

Constatez la présence du compte OneDrive depuis l’application WordPad :

Constatez l’apparition d’un second OneDrive ouvert localement, avec la mention Remote, puis cliquez-dessus :

Constatez l’ouverture de la fenêtre OneDrive comme une seconde application RemoteApp ouverte depuis le poste local :

Fermez l’application WordPad :

Quelques secondes plus tard, l’application OneDrive ouverte automatiquement en RemoteApp se ferme également :

Conclusion

Grâce à cette évolution, OneDrive fonctionne parfaitement avec RemoteApp créée dans un environnement Azure Virtual Desktop. Cela permet à vos aux utilisateurs d’accéder à leurs fichiers et de les synchroniser lorsqu’ils utilisent une RemoteApp de 2 manières, localement ou au travers de l’application RemoteApp.

Azure Lighthouse prend le contrôle

Azure Lighthouse existe déjà depuis longtemps. Mais je souhaitais malgré tout en faire un article car il est très utile dans bien des cas car il facilite grandement la gestion de ressources réparties sur plusieurs tenants Microsoft. Cela s’adapte donc parfaitement aux prestataires ou fournisseurs de services Cloud.

Qu’est-ce qu’Azure Lighthouse ?

Azure Lighthouse permet une gestion multi-locataire avec de la scalabilité, une automatisation plus poussée et une gouvernance renforcée des ressources.

Microsoft Learn

En d’autres termes, Azure Lighthouse vous permet d’accéder à plusieurs tenants en simultané. Cela permet de visualiser un ensemble de ressources Azure réparties sur plusieurs tenants dans une seule et unique vue.

Grâce à Azure Lighthouse, vous allez pouvoir :

  • Créer une relation sécurisée entre vous et vos clients gérés.
  • Fournir une transparence et à la demande sur l’accès et les actions.
  • Permettre une gestion granulaire de l’accès à l’ensemble du parc Azure.

Vous pouvez gérer plusieurs clients dans un seul Azure Lighthouse. Vous devez simplement définir comment vos équipes accéderont aux ressources des clients :

Pourquoi utiliser Azure Lighthouse pour un client ?

  • Gardez le contrôle : Ajoutez, modifiez ou retirez les droits des intervenants externes à tout moment grâce à la relation fournisseur de services / client établie via Azure Lighthouse.
  • Conservez la sécurité : Fournissez un accès granulaires aux fournisseurs de services, à des niveaux spécifiques (souscription ou groupe de ressources), et à des groupes d’utilisateurs définis, pour un accès permanent ou temporaire.
  • Restez informé : Veillez à ce que vos données soient toujours sécurisées et ne quittent pas votre environnement, tout en ayant une visibilité sur les actions et les changements effectués par vos fournisseurs de services.

Comment Azure Lighthouse fonctionne ?

Pour qu’Azure Lighthouse puisse fonctionner, il est nécessaire de disposer de :

  • Utilisateurs, groupes ou principaux de service provenant du tenant du fournisseur.
  • Rôles RBAC à appliquer sur les ressources du client.

Ces 2 éléments (Rôles + identités) sont alors combinés dans un template généré au format JSON depuis le tenant du fournisseur, puis exécuté sur le tenant du client.

C’est aussi simple que cela !

Note : A la place de la génération d’un template JSON, il est aussi possible de passer par la publication d’une offre fournisseur sur la Marketplace Azure.

Combien cela coûte ?

L’utilisation d’Azure Lighthouse est gratuite pour les clients et pour les fournisseurs.

Azure Lighthouse, qui s’appuie sur la technologie de gestion des ressources déléguées d’Azure, est donc disponible sans frais supplémentaires :

Quelles sont les étapes pour mettre en place Azure Lighthouse ?

Azure Lighthouse est donc configurable de plusieurs manières :

Afin de faire au plus simple dans cet article, je vous propose, au travers d’un petit exercice, de tester la seconde méthode :

Etape 0 – Rappel des prérequis :

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

  • Deux tenants Microsoft (fournisseur / client)
  • Tenant fournisseur :
    • Un utilisateur avec des droits d’administrateur
  • Tenant client :
    • Une souscription Azure valide
    • Un utilisateur avec rôle de Propriétaire sur la souscription Azure

Afin d’identifier plus facilement les deux tenants Azure, je vous propose de configurer les couleurs du portail Azure comme ceci :

  • Portail Azure clair : tenant fournisseur
  • Portail Azure sombre : tenant client

Commençons par la configuration du tenant du fournisseur.

Etape I – Configuration du tenant fournisseur :

Connectez-vous au tenant du fournisseur afin de créer un nouveau groupe Entra ID dédié à Azure Lighthouse :

Ajoutez dans ce nouveau groupe les membres nécessaires pour tester par la suite le bon fonctionnement de l’accès aux ressources Azure situées sur le tenant du client :

Toujours sur le tenant du fournisseur, utilisez la barre de recherche comme ceci :

Cliquez sur Créer un modèle ARM (Azure Resource Manager) :

Nommez le nom de votre template ARM, puis cliquez-ici pour ajouter des autorisations RBAC :

Recherchez le groupe créé précédemment , ajoutez une autorisation que vous accorderez à vos utilisateurs d’Azure Lighthouse, puis définissez si les droits sont permanents ou éligibles :

Pour les droits éligibles, vous devrez configurer Lighthouse avec Azure AD PIM, qui est disponible dans la licence Entra ID Premium P2.

Cliquez sur le bouton Voir le modèle :

Cliquez sur le bouton Télécharger :

La configuration du tenant fournisseur est maintenant terminée

Ce template au format JSON est utilisable autant de fois que nécessaire, tant que les accès aux ressources Azure des clients sont identiques.

La suite se passe maintenant sur le tenant du client.

Etape II – Configuration du tenant client :

Connectez-vous au tenant du client où se trouve la souscription ou le groupe de ressources que vous souhaitez gérer.

Avant de mettre en place Azure Lighthouse, prenez le temps de vérifier sur la souscription Azure le bon enregistrement du fournisseur de ressources suivant :

Utilisez la barre de recherche comme ceci :

Cliquez ici pour voir les offres des prestataires de services :

Dans le menu Offres des prestataires de services, cliquez sur Ajouter une offre, puis sélectionnez Ajouter par le biais d’un modèle :

Téléchargez le modèle que vous avez créé précédemment :

Sélectionnez la souscription Azure, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du lien Azure Lighthouse :

Attendez environ deux minutes :

La configuration est maintenant en place. Avant de créer une nouvelle ressource Azure, nous allons contrôler le lien établi.

Etape III – Contrôle de la configuration :

Toujours sur le tenant du client, rendez-vous dans le menu suivant afin de constater l’apparition de la délégation créée précédemment :

Retournez sur le tenant du fournisseur afin de constater l’apparition du client dans le menu suivant :

Cliquez sur le bouton de paramétrage du portail Azure afin de voir dans la liste des tenants et des souscriptions provenant du tenant du client :

Toujours sur le tenant fournisseur, vérifiez la présence de la souscription client dans la liste des souscriptions Azure, puis cliquez dessus :

Contrôlez la désactivation des fonctions d’assignation car le rôle de propriétaire n’est pas disponible via Azure Lighthouse :

L’environnement client est maintenant correctement configuré.

Afin de vérifier le bon fonctionnement, je vous propose créer une nouvelle machine virtuelle sur la souscription Azure du client, depuis le tenant du fournisseur.

Etape IV – Création d’une machine virtuelle Azure :

Encore sur le tenant fournisseur, cliquez-ici pour créer une machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM en choisissant bien la souscription Azure du tenant du client, puis lancez la validation Azure :

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

Attendez environ 2 minutes que le déploiement se termine :

Retournez sur le portail Azure du tenant du client afin de vérifier la bonne apparition de la machine virtuelle créée depuis le tenant du fournisseur :

Contrôlez les droits RBAC présents sur cette machine virtuelle :

Notez l’absence de droits RBAC, directs ou hérités, des utilisateurs d’Azure Lighthouse.

La création des ressources est bien possible grâce à la mise en place d’un rôle RBAC de contributeur au travers d’Azure Lighthouse.

La suppression des ressources Azure depuis le tenant du fournisseur fonctionne elle aussi sans souci :

Etape V – Modification des ressources gérées par Azure Lighthouse :

La modification ou l’ajout des ressources gérées par Azure Lighthouse est possible depuis le tenant client, sans besoin de réutiliser le template JSON du fournisseur :

Là encore, la suppression de droits sur une souscription Azure est possible à tout moment depuis le tenant du client :

Conclusion :

En quelques clics, nous avons mis en place une délégation de ressources Azure en place. Bravo ! Bien évidemment, cette liaison d’Azure Lighthouse est aussi compatible avec Microsoft Entra Privileged Identity Management.

Enfin, voici comme toujours une vidéo de John Savill qui en parle très bien :

Updatez vos VMs vers Windows Server 2022

La date 10 octobre 2023 arrive à grand pas ! Non ce n’est pas l’anniversaire d’un de vos proche que vous auriez oublié … mais bien la Fin de support programmée pour Windows Server 2012 et 2012R2. A partir de cette date, plus aucune mise à jour de sécurité ne sera disponible sans l’achat des ESUs (Extended Security Updates), ou suite à une migration vers Azure ou Azure Stack HCI (solution de Cloud hybride proposé par Microsoft). 😥😥

0
Years
:
0
Months
:
0
J
:
0
H
:
0
M
:
0
S

Pour continuer de plomber l’ambiance, voici d’ailleurs le calendrier des échéances passées et futures :

Que peut-on faire dans ce cas ?

Comme déjà indiqué dans cet article, plusieurs solutions s’offrent déjà à vous :

  • Migrer vers une nouvelle version Windows ou SQL plus récente.
  • Acheter les Mises à jour de sécurité étendue (ESUs).
  • Migrer les serveurs vers Azure pour recevoir gratuitement les ESUs.

Un article dédié aux ESUs devrait arriver sous peu, tandis que 2 autres concernant la migration vers Azure existent déjà :

Il nous reste donc à parler de la mise à jour de l’OS lui-même. Cela tombe bien, car Dean Cefola de l’Azure Academy vient justement de publier une vidéo traitant de ce sujet :

Important : Bien évidement, les opérations décrites dans cette vidéo et dans mon article ne concernent que la seule mise à jour de l’OS. Il est certain que tous les projets comporteront éventuellement une migration vers le Cloud, mais également d’innombrable tests de compatibilité pour les applications déjà en place.

Aussi, je vous propose dans cet article de vous intéresser aux différentes méthodes de mise à jour possibles et décrites par Dean. Voici les grandes étapes de cet exercice :

Ces étapes sont également disponibles dans l’article de Microsoft Learn :

Une mise à niveau sur place vous permet de passer d’un ancien système d’exploitation à un plus récent, tout en conservant inchangés vos paramètres, vos rôles serveur et vos données. Cet article vous explique comment faire passer vos machines virtuelles Azure à une version ultérieure de Windows Server en utilisant une mise à niveau sur place.

Microsoft Learn

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la mise à jour vers Windows Server 2022, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Je vous propose de créer plusieurs machines virtuelles dans le but de réaliser 4 tests :

Etape I Création de l’environnement de test :

Pour cela, commencez par déployer une première machine virtuelle sur Azure. Rendez-vous sur le portail d’Azure, puis utilisez la barre de recherche :

Cliquez-ici pour créer votre première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM en choisissant bien une image Windows Server 2012 R2 :

Définissez un compte administrateur local, bloquer les ports entrants (nous utiliserons le service Azure Bastion), puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Créez un nouveau réseau virtuel, retirez l’adresse IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

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

Sans attendre que le déploiement soit entièrement terminé, il vous est possible, depuis le réseau virtuel Azure de déployer le service Azure Bastion :

Inutile d’attendre qu’Azure Bastion soit déployé pour continuer cet exercice :

Continuez en déployant 3 autres machines virtuelles Azure afin de pouvoir effectuer les 4 tests. Vous devriez avoir les VMs suivantes :

  • Windows Server 2012R2 x 3
  • Windows Server 2016 x 1

Notre environnement de départ est maintenant en place, nous allons pouvoir préparer nos VMs à installer la mise à jour OS Windows Server 2012.

Etape II – Sauvegarde et Préparation :

Mais avant cela, il est vivement conseillé de faire une sauvegarde. Depuis la machine virtuelle de votre choix, il est facile de faire une sauvegarde d’un disque via la fonction Snapshot.

Pour cela, recherchez le disque OS d’une VM de test, puis cliquez dessus :

Sur ce disque OS, cliquez-ici pour créer un snapshot de celui-ci :

Donnez-lui un nom et une performance, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du snapshot de la VM, puis attendez environ 30 secondes :

Le snapshot est maintenant visible comme un élément indépendant de la machine virtuelle Azure. Nous nous en servirons plus tard dans le cadre d’une restauration vers Windows Server 2012R2 :

Comme le rappelle la documentation Microsoft, la mise à niveau sur place nécessite l’ajout d’un second disque contenant les éléments d’installation.

Depuis le portail Azure, cliquez sur Azure Cloud Shell, puis configurez-le à votre guise :

Une fois Azure Cloud Shell démarré en mode PowerShell, lancez le script ci-dessous en prenant soin de modifier si besoin le groupe de ressources et la région Azure :

#
# Customer specific parameters 

# Resource group of the source VM
$resourceGroup = "vmmigrate-rg"

# Location of the source VM
$location = "WestEurope"

# Zone of the source VM, if any
$zone = "" 

# Disk name for the that will be created
$diskName = "WindowsServer2022UpgradeDisk"

# Target version for the upgrade - must be either server2022Upgrade or server2019Upgrade
$sku = "server2022Upgrade"


# Common parameters

$publisher = "MicrosoftWindowsServer"
$offer = "WindowsServerUpgrade"
$managedDiskSKU = "StandardSSD_LRS"

#
# Get the latest version of the special (hidden) VM Image from the Azure Marketplace

$versions = Get-AzVMImage -PublisherName $publisher -Location $location -Offer $offer -Skus $sku | sort-object -Descending {[version] $_.Version	}
$latestString = $versions[0].Version


# Get the special (hidden) VM Image from the Azure Marketplace by version - the image is used to create a disk to upgrade to the new version


$image = Get-AzVMImage -Location $location `
                       -PublisherName $publisher `
                       -Offer $offer `
                       -Skus $sku `
                       -Version $latestString

#
# Create Resource Group if it doesn't exist
#

if (-not (Get-AzResourceGroup -Name $resourceGroup -ErrorAction SilentlyContinue)) {
    New-AzResourceGroup -Name $resourceGroup -Location $location    
}

#
# Create Managed Disk from LUN 0
#

if ($zone){
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
                                   -CreateOption FromImage `
                                   -Zone $zone `
                                   -Location $location
} else {
    $diskConfig = New-AzDiskConfig -SkuName $managedDiskSKU `
                                   -CreateOption FromImage `
                                   -Location $location
} 

Set-AzDiskImageReference -Disk $diskConfig -Id $image.Id -Lun 0

New-AzDisk -ResourceGroupName $resourceGroup `
           -DiskName $diskName `
           -Disk $diskConfig

Note : J’ai également modifié le script de Microsoft pour créer le disque en Standard SSD et non en Standard HDD. Cela me permet d’activer la fonction de disque partagé pour pouvoir l’utiliser en simultané sur 3 VMs maximum :

Lancez le script, attendez environ 30 secondes, puis constatez le succès de déploiement de celui-ci :

Sur ce nouveau disque, activez la fonction de disque partagé afin de l’utiliser sur plusieurs VMs :

Retournez sur votre première machine virtuelle afin de l’ajouter en tant que disque de données, puis cliquez sur Appliquer :

Faites-en de même pour une seconde machine virtuelle :

Enfin, faites-en de même pour une troisième machine virtuelle :

Nos 3 premières virtuelles sous Windows Server 2012R2 sont enfin prêtes. Il ne nous reste qu’à lancez les installations de Windows Server 2022 sous différentes formes.

Etape III – Tests d’installation sur place de Windows Server 2022 :

Test A – Windows Server 2012R2 + Installation GUI :

Commençons par l’installation depuis l’interface GUI.

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Constatez la présence du disque F, correspondant au média d’installation de Windows Server 2022 :

Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable 

Attendez environ 1 minute que l’installation se mette en route :

L’installation passe en revue la configuration de votre machine virtuelle :

Attendez encore une fois une minute environ :

Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :

Attendez encore une fois une minute environ :

L’installation se poursuit en vous avertissant de redémarrages possibles :

L’utilisateur est naturellement déconnecté durant la suite du processus de mise à jour :

Cliquez sur Reconnecter et attendez environ 15 bonnes minutes que l’installation se termine :

Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre première machine virtuelle est bien mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un second cas de mise à jour lancée depuis le portail Azure.

Test B – Windows Server 2012R2 + Installation via Azure Run Command :

Sur votre seconde machine virtuelle de test, rendez-vous dans le menu suivant :

Lancez la commande suivante, puis cliquez sur Exécuter :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet

Attendez environ 15 minutes, sans vous fier au statut Complet de l’écran ci-dessous :

Suivez si besoin la charge CPU de votre VM depuis la fenêtre des métriques :

Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre seconde machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un troisième cas de mise à jour lancée depuis une extension de machine virtuelle.

Test C – Windows Server 2012R2 + Installation via Virtual Machine Extension :

Préparer localement un fichier de script PS1 avec le code suivant :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable /imageindex 4 /quiet

Sur votre troisième machine virtuelle de test, rendez-vous dans le menu suivant :

Choisissez Custom Script Extension, puis cliquez sur Suivant :

Cliquez-ici :

Choisissez le compte de stockage utilisé pour Azure Cloud Shell :

Créez un nouveau conteneur pour le stockage objet :

Nommez-le, puis cliquez sur Créer :

Téléversez votre script :

Sélectionnez votre script :

Cliquez-ici :

Attendez que le déploiement du script se termine :

Suivez si besoin son statut :

Environ 15 minutes plus tard, le statut du script est terminé :

Une fois la mise à jour entièrement terminée, ouvrez une session via Azure Bastion :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre troisième machine virtuelle est bien elle aussi mise à jour en version Windows Server 2022.

Nous allons pouvoir tester un dernier cas de mise à jour lancée depuis une machine virtuelle déjà sous Windows Server 2016.

Test D – Windows Server 2016 + Installation GUI :

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Ouvrez une fenêtre PowerShell et exécutez-y la commande suivante :

cd "F:\Windows Server 2022\"
.\setup.exe /auto upgrade /dynamicupdate disable

Choisissez l’image de Windows Server 2022 correspondante à vos besoin, puis cliquez sur Suivant :

L’installation se poursuit en vous avertissant de redémarrages possibles :

Une fois la mise à jour entièrement terminée, la session ouverte précédemment via Azure Bastion se réouvre à nouveau :

Constatez la nouvelle version de votre Windows Server depuis Server Manager :

Constatez également la nouvelle version de votre Windows Server depuis le portail Azure :

Notre machine virtuelle en 2016 est correctement mise à jour en version Windows Server 2022.

Etape IV – Retrait du disque d’installation :

Une fois l’installation terminée, il ne nous reste plus qu’à retirer le disque d’installation monté sur les machines virtuelles mises à jour :

Cliquez sur Appliquer :

Attendez quelques secondes la notification Azure :

Constatez la disparition du disque F :

Etape V – Restauration de la sauvegarde :

Dans le cas d’un bug au moment de la mise à jour ou après tout autre déconvenue, il est possible de repartir du snapshot généré avant la mise à jour.

Commencez par éteindre la machine virtuelle à restaurer :

Attendez quelques secondes la notification Azure :

Depuis le snapshot, cliquez-ici pour créer un nouveau disque OS :

Nommez-le, choisissez sa taille et sa performance, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du disque :

Retournez sur une des machines virtuelles de test, puis cliquez-ici pour intervertir les disques OS :

Choisissez le nouveau disque, puis lancez le traitement en cliquant sur OK :

Attendez quelques secondes la notification Azure :

Redémarrer la machine virtuelle restaurée :

Ouvrez une session via Azure Bastion :

Attendez la fin de chargement de session :

Constatez le retour à l’ancienne version de Windows Server depuis Server Manager :

Conclusion

Le processus de mise à jour depuis une VM déjà sur Azure vers une version plus récente de Windows Server est des plus simples. Nul doute que la mise à jour de l’OS est la partie émergée de l’iceberg. D’autres tests avant la mises à jour devront être effectués pour vérifier la bonne compatibilité des applications et des services installés.

Organisez-vous grâce au multi-tenants

Microsoft propose depuis quelques temps déjà plusieurs options pour gérer les organisations réparties sur plusieurs tenants Cloud. Par exemple, la synchronisation entre tenants a été introduite en janvier de cette année. Depuis, les choses continuent de progresser grâce à l’arrivée d’un nouveau niveau : l’organisation multi-tenants = regroupement de plusieurs tenants B2B dans un seul ensemble ayant des facultés de synchronisation.

Avant de tester la création d’une organisation multi-tenants sur mon environnement de démonstration, faisons d’abord un bref rappel de quelques notions importantes sur les tenants Microsoft.

Qu’est-ce qu’un tenant Microsoft ?

Nous pourrions traduire le mot anglais Tenant par locataire. Dans l’univers du Cloud Microsoft, le terme Tenant désigne le périmètre (le Cloud) dans laquelle vos données sont stockées. Ainsi chaque client possède sa propre sphère, son propre Tenant.

Voici d’ailleurs la définition selon Microsoft :

Un locataire est une instance d’Azure AD dans laquelle résident des informations sur une seule organisation, y compris des objets organisationnels tels que des utilisateurs, des groupes et des appareils, ainsi que des inscriptions d’applications, telles que Microsoft 365 et des applications tierces.

Microsoft Learn

Qu’est-ce que la synchronisation multi-tenants ?

La synchronisation multi-tenants d’Entra ID est un mécanisme qui facilite la création, la modification et la suppression des utilisateurs à travers plusieurs tenants via un système automatisé et géré par Microsoft :

Son objectif principal est d’assurer une collaboration transparente entre les tenants d’une même organisation, tout en rationalisant la gestion des comptes utilisateurs B2B dans un environnement multi-tenants.

Une vidéo de John en parle d’ailleurs très bien :

Concernant la gestion d’identités externes au tenant, Microsoft propose également d’autres fonctionnalités comme par exemple :

Qu’est-ce qu’une organisation multi-tenants ?

Nous sommes ici à un niveau plus élevé que le tenant unique, nous parlons ici de fédérer plusieurs tenants Microsoft.

L’image ci-dessous montre 2 tenants Microsoft distincts, contenant chacun des utilisateurs présents dans chacun d’eux (Entra ID) :

Microsoft a développé ce niveau pour répondre à plusieurs demandes :

Une organisation multilocataire est une organisation qui a plusieurs instances d’Azure AD. Voici les principales raisons pour lesquelles une organisation peut avoir plusieurs locataires :

  • Conglomérats : les organisations avec plusieurs filiales ou unités commerciales qui fonctionnent indépendamment.
  • Fusions et acquisitions : organisations qui fusionnent ou acquièrent des sociétés.
  • Activité de cession : dans le cadre d’une cession, une organisation fractionne une partie de ses activités pour former une nouvelle organisation ou la vendre à une organisation existante.
  • Plusieurs clouds : les organisations dont la conformité ou la réglementation doivent exister dans plusieurs environnements cloud.
  • Plusieurs limites géographiques : organisations qui opèrent dans plusieurs emplacements géographiques avec différentes réglementations de résidence.
  • Locataires de test ou intermédiaires : organisations qui ont besoin de plusieurs locataires à des fins de test ou de préproduction avant de procéder à un déploiement plus large sur des locataires principaux.
  • Locataires créés par un service ou un employé : organisations où des services ou des employés ont créé des locataires pour le développement, le test ou le contrôle distinct.
Microsoft Learn

Pour vous donner un exemple concret, ce scénario peut se présenter quand une entreprise en rachète d’autres. Bien souvent, celles-ci ont chacune un environnement 365 déjà en place, et l’idée d’une migration de tenant à tenant est considérée comme trop lourde.

Pour faire simple, l’organisation à multi-tenants continue elle aussi de s’appuyer sur la synchronisation entre tenants d’Entra ID : Les utilisateurs de votre tenant sont alors provisionnés dans les autres tenants de l’organisation en tant qu’utilisateurs de collaboration B2B.

Peut-on gérer une organisation multi-tenants dans Microsoft 365 ?

Au-delà les différents mécanismes possibles de collaboration sur Entra ID, Microsoft a rajouté ce niveau d’organisation multi-tenants dans la console d’administration de Microsoft 365 :

Note : L’activation antérieure de la synchronisation entre tenants d’Entra ID ne gêne en rien la mise en place d’une organisation multi-tenants. Celles-ci continueront toujours de fonctionner :

Afin de se faire une meilleure idée de l’ensemble de tenants, je vous propose de mettre en place une organisation multi-tenants à partir de 2 tenants B2B non connectés.

Voici les différentes étapes de l’exercice que je vous propose :

Commençons d’abord par détailler les prérequis et l’environnement de départ pour nos tests.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la migration Active Directory vers Azure, il vous faudra disposer de :

  • 2 tenants Microsoft avec des licences 365
  • Une souscription Azure valide pour la création des machines virtuelles de test

Dans mon exemple, mes deux tenants de test sont issus du Microsoft 365 Developer Program. Voici la vue de mes deux tenants de test :

  • JLO Tenant A // jean0loup.onmicrosoft.com
  • JLO Tenant B // tdsynnexchlab.onmicrosoft.com

Chacun de mes 2 tenants dispose d’utilisateurs avec des licences Microsoft 365 E5 Dev :

Dans chacun des tenants de test, j’ai créé également 2 groupes de 3 d’utilisateurs chacun :

Enfin pour les tests, j’ai également créé 2 machines virtuelles de test pour la démonstration côté utilisateur :

Sur ces 2 machines virtuelles hébergées sur Azure, j’y ai installé la suite office 365 + Teams :

J’ai installé Microsoft Teams par ce lien :

Avant la moindre configuration, j’ai testé le bon fonctionnement du chat EXTERNE de Teams entre 2 utilisateurs des 2 tenants :

Microsoft nous le rappelle bien : tenanta user1 fait partie d’une organisation. Il est possible qu’ils aient des politiques liées aux messages qui s’appliquent au chat.

Nous allons donc maintenant déployer une organisation multi-tenants depuis la console d’administration de Microsoft 365.

Etape I – Configuration de l’organisation multi-tenants :

La fonction d’organisation multi-tenants est encore en préversion à l’heure où ces lignes sont écrites. Il est donc nécessaire d’activer l’option de livraison ciblée sur les 2 tenants de test.

Pour cela, rendez-vous sur la page d’administration de Microsoft 365, puis dans le menu ci-dessous afin d’activer l’option suivante :

Attendez quelques minutes, puis rafraîchissez cette même page afin de voir apparaître le menu suivant :

Effectuez cette opération sur les 2 tenants.

Dans ce menu, commencez par démarrer le processus de mise en place de l’organisation multi-tenants en cliquant ici :

Sélectionnez le premier choix afin de créer l’organisation multi-tenants :

Avant d’aller plus loin, ouvrez un second navigateur internet afin de copier sur cette page l’identifiant tenant ID du second environnement :

Renseignez les champs et collez le tenant ID récupéré précédemment :

Cliquez sur Suivant :

Cochez les deux cases suivantes pour valider la synchronisation entrante, puis cliquez sur Suivant :

Cliquez sur le bouton ci-dessous pour valider et démarrer le processus de création de l’organisation multi-tenants :

Copiez le lien ci-dessous afin de terminer le processus de création dans le second tenant de test :

Dans votre second navigateur, rendez-vous sur le lien copié précédemment, puis cliquez-ici pour valider la synchronisation entrante :

Cliquez sur Terminer :

Le message suivant apparaît pour vous indiquer que le processus d’intégration du second tenant est en cours. Cliquez-ici plusieurs fois pour rafraichir le processus :

Quelques minutes plus tard, le lien de synchronisation est bien confirmé dans sur les deux tenants de notre organisation multi-tenants :

Sur les 2 tenants, cliquez ici pour partager un groupe d’utilisateurs vers l’autre tenant :

Après cela, cliquez sur les deux tenants de destinations afin de vérifier la bonne prise en compte des utilisateurs présentes dans vos 2 groupes Entra ID à synchroniser :

La configuration de l’organisation multi-tenants depuis le portail d’administration de Microsoft 365 est maintenant terminée. La synchronisation multi-tenants devrait se lancer sous peu.

Afin d’en savoir un peu plus, rendez-vous sur le portail d’Entra ID juste ici.

Etape II – Configuration de la synchronisation multi-tenants :

Grâce à la configuration de l’organisation multi-tenants, Entra ID a automatiquement préconfiguré la synchronisation multi-tenants.

Cliquez sur le menu suivant d’Entra ID pour découvrir les paramétrages effectués sur vos 2 tenants :

Cliquez sur les 2 configurations créées :

Visualisez les différentes informations disponibles, dont l’intervalle d’approvisionnement fixe :

Configurez-ici si besoin les notifications par email, puis sauvegardez :

Analysez les personnalisations possibles concernant les attributs d’Entra ID :

Quelques minutes plus tard, retournez sur les listes d’utilisateurs respectives de vos 2 tenants afin de constater l’apparition d’utilisateurs synchronisés :

Notez l’absence de synchronisation des groupes Entra ID, seuls des utilisateurs des groupes sélectionnés sont synchronisés :

Consultez et comparez sur les 2 tenants les propriétés synchronisées (ou non) d’un utilisateur concerné :

Il est également possible de lancer, sans attendre, une synchronisation manuelle.

Afin de tester cela, renseignez un titre de poste sur un autre utilisateur synchronisé :

Rendez-vous dans le menu suivant pour lancez la synchronisation à la demande :

Recherchez l’utilisateur à synchroniser, puis démarrez le traitement :

Attendez quelques secondes, puis constatez le changement de titre de poste sur le second tenant :

A noter qu’il n’est pas possible d’effectuer la synchronisation inverse depuis le tenant de destination :

Notre configuration est maintenant en place. Nous allons pouvoir effectuer différents tests entre nos deux utilisateurs de test :

  • tenanta-user1@jean0loup.onmicrosoft.com
  • tenantb-user1@tdsynnexchlab.onmicrosoft.com

Pour rappel, ces utilisateurs sont représentés de la façon suivante dans les 2 tenants de destination :

  • tenantb-user1_tdsynnexchlab.onmicrosoft.com#EXT#@jean0loup.onmicrosoft.com
  • tenanta-user1_jean0loup.onmicrosoft.com#EXT#@tdsynnexchlab.onmicrosoft.com

Etape III – Test de Microsoft Teams :

Depuis les 2 machines virtuelles, ouvrez le client Microsoft Teams. Pour une meilleure expérience utilisateur, activez le nouveau Teams :

Depuis l’écran des paramétrages de Teams, activez la prise en charge des 2 tenants :

Sur le 2 sessions Teams, recherchez les utilisateurs invités respectifs. Notez la présence d’utilisateurs externes précédemment utilisés pour communiquer :

Commencez la communication sur les utilisateurs NON EXTERNE :

Notez les points suivants :

  • La présence de 2 notifications Windows respectives
  • La présence de 2 notifications Teams respectives
  • L’incohérence dans le fil de discussion dans l’écran en tâche de fond

Un clic sur les 2 notifications Teams respectives permet de permuter sur le second tenant :

De retour sur les tenants de départ, commencez la création d’une équipe Teams :

Ajoutez dans celle-ci l’utilisateur invité du second tenant, puis cliquez sur Ajoutez :

Postez un nouveau message d’équipe en citant le second utilisateur comme ceci, afin de constater l’absence de notifications Teams :

Enfin, testez la fonctionnalité d’appel de Teams afin de constater la présence de notifications sur le second utilisateur :

Les quelques tests sur Microsoft Teams ont pu démontrer une bonne intégration des environnements multi-tenants, mais des efforts sur les notifications sont encore à faire.

Pour l’instant, je trouve que la communication via des comptes utilisateurs EXTERNES est encore plus simple.

Continuons les tests avec SharePoint Online.

Etape IV – Test de SharePoint Online :

Créez un nouveau site SharePoint online avec des droits au second utilisateur de test, puis ajoutez-y des fichiers.

Copiez / collez l’URL du site SharePoint Online dans la navigateur de la second VM, puis authentifiez-vous :

Vérifiez la bonne ouverture d’un des fichiers présents :

SharePoint Online fonctionne donc sans souci avec les utilisateurs synchronisés, continuons avec Exchange Online.

Etape V – Test d’Exchange Online :

Configurez une boite mail partagée sur un des 2 tenants, puis ajoutez-y des droits au second utilisateur de test :

Depuis Exchange Online, ouvrez sur les 2 sessions la boite mail partagée créée précédemment via la fonction Ouvrir une autre boîte aux lettres :

Saisissez le nom de la boite mail partagée, puis cliquez sur Ouvrir :

Constatez la présence d’un message d’erreur sur la seconde session :

Essayez si besoin avec le client Outlook local :

Là encore, l’expérience utilisateur ne sera pas encore fonctionnelle :

Je suppose que le point concernant Outlook repose encore sur le fait que les boîtes mails partagées n’acceptent toujours pas de comptes invités.

Conclusion :

Microsoft continue d’avancer avec sa solution d’organisation multi-tenants et cela facilite grandement la création d’utilisateurs ayant des droits SharePoint / OneDrive sur plusieurs entreprises. Mais il y a encore des difficultés dans la partie Teams, au niveau des notifications, et dans la partie Outlook dans la partie authentification.

Nul doute que d’autres améliorations encore à venir afin que les utilisateurs de tenants différents puissent encore accroitre leurs synergies.

Migrez votre AD 2012R2 vers Azure

Microsoft nous prévient déjà depuis assez longtemps : la fin du support de Windows Server 2012 R2 et SQL 2012 sont prévues pour le 10 octobre 2023 😖. Après cette date, ces produits ne recevront plus de mise à jour, sécurités incluses ! Trois s’options s’offrent alors à vous :

  • Migrer vers une nouvelle version Windows ou SQL plus récente.
  • Acheter les Mises à jour de sécurité étendue (ESU).
  • Migrer les serveurs vers Azure pour recevoir gratuitement les ESUs.

Pas de panique !

Microsoft vous aide à planifier la fin de support Windows Server 2012/2012 R2 et SQL Server 2012. Plusieurs ressources sont mises à disposition :

En plus de la documentation Microsoft, Dean Cefola de l’Azure Academy nous propose un petit exercice d’upgrade d’un Active Directory, actuellement hébergé sur un serveur Windows 2012R2 vers un Azure en version 2022 :

La vidéo est vraiment bien faite et très explicative, je souhatais donc vous proposer en détail l’explicatif étape par étape en français afin que vous puissiez le tester par vous-même :

Enfin, Microsoft met aussi à disposition un article dédié à ce sujet : Déployer AD DS dans un réseau virtuel Azure

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la migration Active Directory vers Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un environnement Active Directory on-premise (point de départ)

De mon côté, j’ai simulé mon environnement Active Directory on-premise sur Azure. Voici donc les ressources Azure déjà en place :

  • Machine virtuelle en Windows Server 2012R2
  • Azure Bastion
  • Azure VPN Site à Site

En me connectant à mon serveur AD (nous l’appellerons DC2012R2), nous y retrouvons mon domaine on-premise, ainsi que la version de l’OS : Windows Server 2012R2.

Actuellement, mon environnement de test ne comporte qu’un seul serveur en tant que contrôleur de domaine AD :

Nous allons donc maintenant déployer un nouvel environnement sur Azure afin de simuler la transition AD vers le Cloud de Microsoft.

Etape I – Déploiement des ressources Azure :

Pour cela, commencez par déployer une machine virtuelle sur Azure. Rendez-vous sur le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer votre première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

Définissez un compte administrateur local, bloquer les ports entrants (question de sécurité pour un DC), puis cliquez sur Suivant :

Comme le Microsoft le recommande, il est nécessaire de stocker les informations AD (base de données, les journaux et le dossier sysvol) séparées du disque OS.

Pour cela, rajoutez un second disque en cliquant ici :

Cliquez sur OK :

Définissez le paramètre Host Cache sur le disque de données sur None, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Créez un réseau virtuel (différent de celui utilisé pour simuler le réseau on-premise), retirez l’adresse IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour vous connecter à la VM :

Cliquez sur le bouton suivant pour déployer le service Azure Bastion :

Inutile d’attendre qu’Azure Bastion soit déployé pour continuer cet exercice.

Modifiez l’adresse IP locale de votre machine virtuelle Azure pour la rendre statique :

Avant d’aller plus loin, il est nécessaire d’établir une liaison réseau entre les deux environnements Azure <> on-premise (Normalement, notre environnement on-premise ne se trouve pas dans Azure).

Une des options est donc pour nous de construire une liaison VPN en connectant 2 passerelles VPN Azure entre elles.

Etape II Déploiement de la passerelle VPN Azure :

Pour cela, il est nécessaire de commencer par la création d’une nouvelle passerelle VPN dans notre réseau virtuel Azure.

Pour cela, utilisez la barre de recherche :

Cliquez sur le réseau virtuel créé lors de la création de la VM DC2022 d’Azure :

Ajoutez un sous-réseau dédié à la passerelle VPN comme ceci :

Pour créer une passerelle VPN, utilisez à nouveau la barre de recherche :

Cliquez ici pour créer la seconde passerelle que nous connecterons par la suite à la première (on-premise) :

Renseignez les informations de base relatives à votre Passerelle VPN, puis lancez la validation Azure :

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

Attendez environ 15-45 minutes :

Afin de connecter les deux Passerelles VPNs Azure entre eux, nous avons besoin d’avoir :

  • deux passerelles de réseau local
  • deux connexions VPNs

Dans mon cas, la ressources VPNs côté on-premise sont déjà présentes :

Il ne me reste donc qu’à déployer les 2 ressources VPNs suivantes sur mon réseau Azure :

  • Passerelle de réseau local
  • Connexion VPN

Pour créer cela, utilisez encore une fois la barre de recherche Azure :

Configurer la passerelle de réseau local dans l’environnement Azure, mais indiquez l’adresse IP publique du VPN on-premise, puis lancez la validation :

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

Continuez en créant la connection entre le VPN Azure et la passerelle de réseau local on-premise, puis cliquez sur Suivant :

Définissez une clef partagée, puis lancez la validation Azure :

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

Attendez environ 5 minutes afin de constater un changement dans le statut de la connexion VPN.

Le statut de la connexion change bien sur le passerelle VPN Azure :

Le statut de la connexion change également sur le passerelle VPN on-premise :

Afin que la nouvelle machine virtuelle DC2012 d’Azure se connecte à l’Active Directory on-premise DC2012R2, configurez le DNS de votre réseau Azure pour qu’il pointe sur l’adresse IP de votre AD on-premise, puis cliquer sur Sauvegarder :

Notre environnement Azure est maintenant prêt pour configurer l’Active Directory. Pour cela, nous devons d’abord joindre votre machine virtuelle DC2022 au domaine on-premise, puis la promouvoir en tant que contrôleur de domaine.

Etape III – Ajout du second contrôleur de domaine Azure :

Pour cela, ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM DC2022 :

Saisissez la commande suivante afin renouveler les informations DNS de votre VM DC2022 d’Azure afin qu’elle puisse rejoindre votre domaine on-premise :

ipconfig/renew

Sur la console Server Manager, utilisez le menu suivant pour créer une nouvelle partition liées aux données AD DS :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur OK:

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Créer :

Attendez que le traitement se termine :

Cliquez sur Fermer :

Toujours sur Server Manager, cliquez sur WORKGROUP afin de joindre votre domaine on-premise :

Cliquez sur le bouton ci-dessous :

Renseignez le nom de votre domaine on-premise, puis cliquez sur OK :

Renseignez les identifiants d’un compte présent sur le domaine on-premise, puis cliquez sur OK :

Attendez quelques secondes pour voir apparaître le message suivant, puis cliquez sur OK :

Cliquez sur OK :

Cliquez sur Fermer :

Cliquez-ici pour lancer un redémarrage immédiat de la VM DC2022 d’Azure :

Azure Bastion vous informe que la connexion RDP a été perdue. Cliquez sur Fermer :

Retournez sur votre DC2012R2 afin de constater la bonne apparition de notre VM DC2022 d’Azure dans la liste des ordinateurs du domaine Active Directory.

Rouvrez à nouveau une session à distance via le service Azure Bastion en utilisant un compte de domaine sur votre DC2022 :

Cliquez-ici pour installer les rôles AD DS et DNS sur votre VM DC2022 d’Azure :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cochez les deux rôles AD DS et DNS, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez quelques minutes, puis cliquez ici pour promouvoir votre VM DC2022 comme un second serveur AD DS de votre domaine on-premise :

Conservez le premier choix ainsi que le domaine précédemment joint, puis cliquez sur Suivant :

Choisissez si besoin un site différent du premier, renseignez le mot de passe DSRM, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Modifiez les chemins AD DS pour utiliser le nouveau disque, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ 5 minutes que l’installation se termine :

Comme la VM doit redémarrer au niveau OS, Azure Bastion vous informe que la connexion RDP a été perdue. Cliquez sur Fermer :

Retournez sur votre DC2012R2 afin de constater la bonne apparition de notre VM DC2022 d’Azure dans la liste des contrôleurs de domaine.

Afin que la nouvelle machine virtuelle DC2022 Azure puisse résoudre des requêtes DNS du domaine on-premise, configurez le DNS de votre réseau Azure pour qu’il pointe sur l’adresse IP de votre VM DC2022, puis cliquer sur Sauvegarder :

Effectuez la même opération sur le DNS du réseau on-premise :

Notre machine virtuelle est maintenant contrôleur de domaine, nous allons pouvoir préparer le décommissionnement du DC2012R2 sur le réseau on-premise.

Avant cela, nous devons nous occuper des rôles FSMO.

Etape IV Transfert des 5 rôles FSMO :

Nous allons déplacer les 5 roles FSMO présents sur Active Directory :

Pour cela, ouvrez une session à distance sur votre VM 2012R2 via le service Azure Bastion en utilisant un compte admin de domaine :

Lancez la commande suivante afin de vérifier sur quel contrôleur de domaine se trouve actuellement les 5 rôles FSMO :

netdom /query fsmo

Comme attendu, les 5 rôles sont actuellement gérés par le contrôleur de domaine DC2012R2 :

Depuis la console Server Manager du serveur DC2012R2, ouvrez Windows PowerShell avec le module AD :

Saisissez la commande suivante pour transférer d’un coup les 5 rôles depuis DC2012R2 vers DC2022, en prenant le soin de modifier le nom en gras par le nom de votre VM :

Move-ADDirectoryServerOperationMasterRole -Identity "azure-dc" -OperationMasterRole 0,1,2,3,4

Validez alors chacune des demandes de transfert de rôle :

Relancez la commande suivante afin de vérifier le changement de contrôleur de domaine pour les 5 rôles FSMO :

netdom /query fsmo

Si vous rencontrez le message d’erreur suivant :

Depuis la console Server Manager, ouvrez Active Directory Sites et Services :

Corriger la valeur à vide de l’attribut dNSHostName :

Puis relancez la commande suivante :

Move-ADDirectoryServerOperationMasterRole -Identity "azure-dc" -OperationMasterRole 0,1,2,3,4

Vous pouvez maintenant décommissionnnez votre serveur DC2012R2.

Etape V Décommissionnement l’Active Directory DC2012R2 :

Pour faire les choses dans l’ordre, cliquez sur la fonction de désinstallation présente dans la console Server Manager se trouvant sur votre serveur DC2012R2 :

Cliquez sur Suivant :

Cliquez sur Suivant :

Décochez les deux rôles AD DS et DNS, puis cliquez sur Suivant :

Cliquez-ici pour confirmer votre choix :

Le message d’erreur suivi est attendu, la d’installation de rôles en activité ne peut que se faire qu’après un premier décommissionnement au niveau du domaine.

Cliquez-ici pour commencer l’opération :

Cliquez sur Suivant :

Cochez la case suivante pour également procéder pour la partie DNS, puis cliquez sur Suivant :

Définissez un nouveau mot de passe pour le compte d’administrateur local Windows :

Cliquez sur Rétrograder :

Attendez quelques minutes que le traitement se termine :

Le serveur DC2012R2 a besoin d’effectuer un redémarrage OS pour terminer la rétrogradation :

Azure Bastion vous informe alors que la connexion RDP a été perdue. Cliquez sur Fermer :

Retournez sur Server Manager de votre DC2022 d’Azure pour ouvrir Active Directory Utilisateurs et Ordinateurs :

Comme attendu, il ne reste que le DC2022 hébergé sous Azure :

Configurez le DNS de votre réseau Azure pour qu’il pointe plus que sur l’adresse IP de votre DC2022, puis cliquez sur Sauvegarder :

Effectuez la même opération sur le DNS du réseau on-premise, puis cliquez sur Sauvegarder :

Nous environnement Active Directory est maintenant 100% Cloud. Nous allons pouvoir mettre à jour le niveau domaine fonctionnel vers une version plus récente.

Etape VI Mise à niveau du domaine Active Directory :

Pour cela, retournez sur la console Server Manager de votre DC2022 d’Azure, puis ouvrez Active Directory Domains and Trusts :

Commencez par élever le niveau fonctionnel du domaine sur chaque domaine de votre forêt :

Choisissez la version la plus récente possible, puis cliquez sur Elever :

Cliquez sur OK :

Cliquez sur OK :

Une fois tous les domaines modifiés, effectuez la même opération au niveau de la forêt AD :

Là encore, choisissez la version la plus récente possible, puis cliquez sur Elever :

Cliquez sur OK :

Cliquez sur OK :

Toutes les opérations de transfert ou de mise à jour sont maintenant terminées. Il ne nous reste plus qu’à tester le bon fonctionnement de notre Active Directory dans Azure.

Etape VII Test de connexion depuis le réseau on-premise :

Pour tester notre AD dans Azure, nous utiliserons une machine virtuelle Windows 11 connectée au réseau on-premise (donc transitant par le lien VPN).

Sur la page de machines virtuelles Azure, éteignez le DC2012R2 afin de ne pas fausser le test de bon fonctionnement :

Confirmez votre choix en cliquant sur Oui :

Attendez l’apparition de la notification Azure suivante :

Ouvrez une session à distance sur votre machine Windows 11 de test via le service Azure Bastion en utilisant un compte de domaine :

Attendez que la session Windows s’ouvre :

Saisissez la commande suivante afin de bien vérifier l’ouverture de session sur un compte du domaine AD :

whoami

Conclusion :

Grâce à cet exercice, nous avons pu parcourir ensemble les principales étapes présentes dans une migration vers Azure d’un Active Directory, et via une version plus récente. Nul doute que le nombre et la répartition des DCs des infrastructures on-premise peut rajouter des tâches et de la complexité.

Migrez votre Windows 365 dans une autre région Azure

Microsoft continue d’apporter toujours plus de fonctionnalités à son service Windows 365. Cette fois, vous allez pouvoir très facilement déplacer vos Cloud PCs d’une région Azure à une autre en quelques clics. Que Microsoft ouvre de nouveaux centres de données ou que vos utilisateurs se déplacent à travers le globe, Azure déménage pour vous !

Plusieurs articles ont déjà été écrits sur ce blog à propos de Windows 365 depuis sa sortie durant l’été 2021 :

Mais la question du déplacement d’un ou plusieurs Cloud PCs Windows 365 n’avait pas encore été abordée par Microsoft. Ils corrigent donc le tir pour automatiser ce processus de déplacement de ressources Cloud.

D’ailleurs, où est hébergé son Cloud PC ?

Comme tous les services Cloud de Microsoft, les Cloud PCs sont hébergés dans un de leurs nombreux centres de données répartis à travers le Cloud.

Windows 365 est donc disponible à ce jour dans la liste de centres données suivante, et celle-ci continue de s’agrandir :

  • Amériques
    • Brésil Sud (restreint)
    • USA Centre
    • USA Centre Sud
    • USA Est
    • USA Est 2
    • USA Ouest 2 (restreint)
    • USA Ouest 3
  • Asie
    • Asie Est
    • Asie Sud-Est
    • Inde Centre
    • Japon Est
    • Corée Centre
  • Océanie
    • Australie Est
  • Canada
    • Canada Centre
  • Europe
    • Europe Nord
    • Europe Ouest
    • France Centre
    • Centre Ouest de l’Allemagne
    • Norvège Est
    • Suède Centre
    • Suisse Nord
    • Sud du Royaume-Uni
  • Afrique / Moyen Orient
    • Afrique du Sud Nord
    • Émirats arabes unis Nord

Pourquoi migrer son Cloud PC ?

Tout service Cloud étant par nature accessible depuis internet, il n’est pas évident de comprendre l’intérêt de migrer son Cloud PC vers une autre région Azure. Plusieurs raisons pourraient alors l’expliquer :

  • Déplacer le Cloud PC au plus près de son utilisateur pour améliorer les performances et diminuer la latence réseau.
  • Intégrer son Cloud PC dans une infrastructure réseau existante, mais présente dans une autre région Azure.
  • Maitriser le lieu de résidence des données de son Cloud PC.

Y a-t-il un risque à déplacer son Cloud PC ?

Non, Microsoft est très clair sur le processus de migration du Cloud PC :

Tous les PC cloud du déplacement sont sauvegardés avant d’être déplacés vers la nouvelle région. Cette sauvegarde, qui peut prendre un certain temps, peut commencer lorsque l’utilisateur est connecté et actif.

Microsoft Learn

Par contre, le processus de migration peut prendre un certain temps, et donc occasionner une interruption de service pour l’utilisateur :

Le meilleur moment pour effectuer des déplacements est pendant le week-end pour s’assurer que l’impact sur les utilisateurs est réduit. Les PC cloud étant arrêtés pendant le processus de déplacement, vous devez avertir vos utilisateurs avant le déplacement afin qu’ils puissent enregistrer leur travail et se déconnecter.

Microsoft Learn

Afin de comprendre le processus de déplacement, je vous propose de tester ensemble cette fonctionnalité de Windows 365 sur deux cas de figure :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Deux licences Windows 365

Commençons par le scénario le plus simple à tester, à savoir le déplacement d’un Cloud PC uniquement joint à Entra ID.

Scénario A – Cloud PC Windows 365 joint uniquement à Entra ID :

Afin de mettre en place le premier Windows 365, il est nécessaire d’assigner une licence à un utilisateur de test :

Rendez-vous sur le portail d’Intune afin de créer une police de provisionnement :

Ici, notre jointure est simple et directe :

Environ 30 minutes plus tard, la page suivante vous affiche la bonne mise à disposition du Cloud PC pour son utilisateur :

Avant de lancer le processus de déplacement du Cloud PC, cliquez sur le lien suivant, authentifiez-vous avec votre utilisateur de test, puis lancez une session Cloud PC :

Attendez quelques secondes que la sessions Windows s’ouvre :

Ouvrez la commande suivante et l’adresse web suivante afin de constater votre configuration de jointure et votre adresse IP actuelle :

dsregcmd /status

Notre PC actuellement hébergé aux USA est maintenant prêt à être migré dans un centre de données Suisse.

Pour cela, retournez dans la liste des polices de provisionnement, puis cliquez sur celle-ci :

Cliquez sur le lien suivant pour en modifier le contenu :

Changez la Géographie Microsoft et la Région Azure selon vos souhaits, puis cliquez sur Suivant :

Qu’est-ce qu’une Géographie Microsoft ?
La réponse est juste ici.

Cliquez-ici pour mettre à jour votre première police de provisionnement :

La notification suivante apparaît alors :

Enfin, cliquez-ici pour déclencher la bascule de région Azure selon les nouvelles règles de la police de provisionnement modifiée :

Confirmez votre choix en cliquant ici :

L’ordre de bascule est maintenant pris en compte par Azure. Les Cloud PCs rattachés à cette police de provisionnement voient leur statut changer :

Quelques minutes plus tard, la connexion Windows 365 de notre utilisateur de test se termine :

Et environ 1 heure et 30 minutes plus tard, le Cloud PC retrouve son précédent statut :

Rouvrez une session de bureau à distance de votre utilisateur de test.

La réouverture d’Edge indique la possibilité de restaurer les onglets précédent ouverts :

Cette fois-ci, la page de IP2location indique bien une nouvelle adresse IP et un nouveau positionnement estimé sur la Suisse :

Pour les Clouds PC de Windows 365 joints uniquement à Entra ID, la migration vers une nouvelle région Azure a été des plus simples.

Intéressons-nous maintenant aux Clouds PC Windows 365 de joints à Entra ID et à Active Directory (jointe hybride).

Scénario B – Cloud PC Windows 365 joints à Entra ID et à Active Directory (hybride) :

Cette seconde liaison est surtout utile dans le cadre d’infrastructure existante dans Azure ou on-premise car elle permet de :

  • Joindre les Cloud PCs à un domaine Active Directory existant
  • Permettre un accès réseau à des ressources locales via une passerelle Azure VPN ou autre

Une liaison réseau doit être établie dans Azure avant le premier déploiement des Cloud PCs. Il nous est également nécessaire de disposer d’un domaine Active Directory.

Dans mon cas, j’ai déployé une machine virtuelle Azure en Windows Server, et Azure Bastion pour m’y connecter plus facilement :

N’oubliez pas de configurer également l’adresse IP locale de votre VM en tant que DNS sur votre réseau virtuelle Azure.

Azure Bastion est donc un service de jump pour accéder aux machines virtuelles sur Azure, que celles-ci soient Windows ou Linux. Un article en parle juste ici.

Renseignez les identifiants de l’administrateur local renseignés lors de la création de votre VM, puis cliquez sur Connecter :

Installer les rôles suivants pour créer votre domaine Active Directory :

  • Active Directory Domain Services
  • Serveur DNS

Créez une OU et un utilisateur dédié à vos tests Windows 365 :

Installer Azure AD Connect sur votre serveur Active Directory de test via ce lien. Un article dédié à Azure AD Connect est disponible juste ici.

Le gestionnaire des synchronisations d’Azure AD Connect affiche la bonne remontée de notre utilisateur de test dans Entra ID :

Dans Azure AD Connect, n’oubliez pas d’également configurer la jointure hybride par le menu suivant :

Cochez la case ci-dessous, puis cliquez sur Suivant :

Cochez la case ci-dessous, puis cliquez sur Suivant :

Renseignez les informations d’identifications d’Active Directory, puis cliquez sur Suivant :

Une fois la configuration terminée, retournez sur le portail des utilisateurs d’Entra ID afin de constater l’apparition de notre utilisateur AD correctement synchronisé :

Veillez à lui assigner également une licence Windows 365 :

Retournez sur le portail d’Intune pour créer une connexion réseau Azure :

Configurez celle-ci en tenant compte à la fois des informations d’Azure et d’Active Directory :

Attendez quelques minutes que le processus de vérification de Windows 365 n’affiche pas d’erreur bloquante :

Créez une seconde police de provisionnement dédiée à ce scénario B :

Configurez celle-ci pour qu’elle utilise la connexion réseau créée précédemment dans le cadre de notre jointure hybride :

Retournez sur l’onglet suivant afin de constater l’apparition d’un second Cloud PC en cours de provisionnement :

Attendez environ une heure que le provisionnement se termine :

Vérifiez sur la page des périphériques d’Entra ID que le nouveau Cloud PC y figure bien :

Vérifiez dans l’OU d’Active Directory que le nouveau Cloud PC y figure également :

Notre environnement de départ pour notre Scénario B est enfin prêt. Nous allons pouvoir commencer la migration du Cloud PC dans une autre région Azure.

Pour cela, commencez par créer un second réseau virtuel Azure :

Veillez à choisir une région et un adressage IP différents du premier réseau virtuel :

Une fois le réseau virtuel créé, cliquez-ici pour lui ajouter un appairage vers le premier réseau virtuel :

Configurez l’appairage comme ceci, puis cliquez sur Créer :

Attendez quelques secondes que le statut de l’appairage indique Connecté :

Comme pour le premier réseau virtuel, renseignez l’adresse IP locale de votre machine virtuelle ayant le rôle d’Active Directory, puis cliquez sur Sauvegarder :

Retournez sur le portail d’Intune afin d’ajouter une seconde connection réseau Azure hybride :

Choisissez le second réseau virtuel Azure :

Reproduisez les mêmes éléments d’identification de votre Active Directory, puis cliquez sur Suivant :

Lancez la création de votre connection réseau Azure hybride en cliquant ici :

Attendez quelques minutes que le processus de vérification de Windows 365 n’affiche pas d’erreur bloquante sur la nouvelle connection réseau Azure hybride :

Retourner dans la liste des polices de provisionnement, puis cliquez sur celle-ci :

Cliquez sur le lien suivant pour en modifier le contenu :

Changez la connection réseau Azure hybride, puis cliquez sur Suivant :

Cliquez-ici pour mettre à jour votre seconde police de provisionnement :

La notification suivante apparaît alors :

Enfin, cliquez-ici pour déclencher la bascule de région Azure selon les nouvelles règles de la police de provisionnement :

Confirmez votre choix en cliquant ici :

L’ordre de bascule est maintenant pris en compte par Azure. Les Cloud PCs rattachés à cette police de provisionnement voient leur statut changer :

Environ 1 heure et 30 minutes plus tard, le Cloud PC retrouve son précédent statut :

Ouvrez la session de bureau à distance de votre utilisateur de test :

Là encore, la page de IP2location indique bien une adresse IP et un positionnement estimé sur la Suisse :

Conclusion

En seulement quelques clics, Microsoft propose encore une fois d’automatiser des opérations qui pouvaient prendre plusieurs heures en opérations IT. L’ajout réguliers de fonctionnalités apporte toujours plus de souplesse au service managé Cloud PC.

Voici d’ailleurs une vidéo de Dean sur le sujet est disponible juste ici 😎:

Maîtrisez vos accès conditionnels

Cette semaine, Microsoft vient juste d’annoncer la disponibilité générale (GA) de fonctionnalités récentes liées à l’Accès Conditionnel, et très présent au cœur d’Entra ID. L’ajout de tableaux de bord sur plusieurs ressources (utilisateurs, périphériques et applications) faciliteront grandement le contrôle de la bonne couverture des polices d’accès conditionnels sur les besoins.

Voici un lien vers un article pour un bref rappel de l’accès conditionnel, déjà expliqué dans un autre article dédié à Azure Virtual Desktop.

Qu’est-ce que l’Accès Conditionnel ?

Tous les environnements informatiques sont en quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers du Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations sécuritaires à gérer.

Le périmètre de sécurité moderne s’étend au-delà du périmètre réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations utilisent désormais des signaux basés sur l’identité dans le cadre de leurs décisions de contrôle d’accès.

Microsoft Learn

Qu’est-ce qu’un Signal pour Entra ID ?

L’accès conditionnel repose sur un certain nombre de signaux ou paramètres d’entrée. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :

  • Emplacement (adresse IP)
  • Appareil (OS, version, conformité, …)
  • Utilisateur Entra ID
  • Application interrogée
  • IA (Détection des risques en temps réel géré par Entra ID Identity Protection)

Qu’est-ce qu’une Décision pour Entra ID ?

La décision est le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est possiblement question de bloquer l’accès à l’utilisateur, ou de l’autoriser selon des conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :

  • Exiger une authentification multifacteur (cas plus utilisé)
  • Exiger que l’appareil soit marqué comme conforme
  • Exiger un appareil joint en hybride à Entra ID
  • Exiger une stratégie de protection des applications

Qu’est-ce qu’une Option d’application pour Entra ID ?

Ces options apportent une supervision de session et des accès de l’utilisateur telles que :

  • Empêcher l’exfiltration des données
  • Protéger lors du téléchargement
  • Empêcher le chargement de fichiers sans label
  • Bloquer les programmes malveillants potentiels
  • Surveiller les sessions utilisateur pour la conformité
  • Bloquer l’accès

Doit-on disposer de licence pour utiliser l’accès conditionnel ?

Rappel important : Mi-juillet 2023, Microsoft a annoncé renommer son service Azure AD (Azure Active Directory). Ce changement est encore en cours et devrait être finalisé pour la fin de cette année. Cette simplification de dénomination est en cohérence avec le périmètre de la gestion identitaire élargie et gérée par le Cloud de Microsoft.

Cela a aussi pour conséquence un léger changement de nom de certaines licences :

Microsoft a mis une FAQ à disposition juste ici.

L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Microsoft Entra ID Premium P1/P2. Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :

  • Microsoft Entra ID Premium P1
  • Microsoft Entra ID Premium P2
  • Enterprise Mobility + Security E3
  • Enterprise Mobility + Security E5
  • Microsoft 365 Business Premium
  • Microsoft 365 A3
  • Microsoft 365 A5
  • Microsoft 365 F1
  • Microsoft 365 F3
  • Microsoft 365 F5 Security
  • Microsoft 365 F5 Security + Compliance

Je vous remets également le lien vers le site très utile créé par Aaron Dinnage :

Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?

Cette question me revient très souvent 😉. Il faut savoir que cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :

Certains services clients ne sont actuellement pas en mesure de limiter les avantages à des utilisateurs spécifiques. Nous vous recommandons d’acquérir des licences pour tout utilisateur dont vous avez l’intention de bénéficier et/ou d’accéder au service.

Microsoft Learn

Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.

Maintenant que la partie licence est clarifiée, nous allons pouvoir nous intéresser aux principales fonctionnalités de l’accès conditionnel.

Pour vous rendre sur les règles d’accès conditionnel, allez sur la page suivante d’Entra ID dédiée :

Voici quelques fonctionnalités de l’accès conditionnel d’Entra ID que je vous propose d’étudier :

Fonctionnalité I – Le nouveau tableau de bord :

La page d’accueil de l’accès conditionnelle a été revue pour afficher plusieurs informations essentielles aux équipes IT :

C’est vraiment ce qui manquait à ce service : la visibilité. Il est maintenant beaucoup plus simple de comprendre d’un rapide coup d’œil les éléments suivants :

  • Polices actives ou non : les polices d’accès conditionnel ont 3 statuts possibles. Le mode « Rapport seulement » est utile pour contrôler l’impact durant une phase de test sans perturber les utilisateurs.
  • Utilisateurs : Affiche le nombre d’utilisateurs ayant pu s’authentifier sans passer par aucune police d’accès conditionnel.
  • Périphériques : Affiche le nombre de poste étant non managés ou non conformes.
  • Applications : lien vers une liste des applications couvertes et non couvertes par une police d’accès conditionnel

Par exemple, un clic sur la première rubrique affiche le journal d’événements d’ouverture de session avec les filtres adéquats :

Un clic sur les applications ou sur l’onglet Couverture montre 2 différents tops applications :

  • Top des applications non couvertes par un accès conditionnel
  • Top des applications couvertes par un accès conditionnel

Là encore, un clic est possible pour basculer à nouveau sur le journal des événements d’ouverture de sessions afin d’identifier plus facilement les utilisateurs concernés par l’application ciblée :

Microsoft a même pensé au graphique afin d’améliorer la prise de vue dans son ensemble de ce que représente les accès conditionnés à ceux en étant dépourvues :

Voici une nouvelle vidéo qui résume bien ce nouvel écran :

Fonctionnalité II – Création d’une police :

Le véritable moteur de l’accès conditionnel d’Entra ID est : la police.

Depuis longtemps, il est possible de créer une police d’accès conditionnel depuis une feuille blanche. Vous devrez alors choisir parmi toutes les options disponibles dans les sections suivantes :

  • Utilisateur(s) : cible la police sur un utilisateur, un groupe d’utilisateurs ou même des utilisateurs selon leurs rôles. Il est même possible d’exclure des utilisateurs selon ces mêmes règles.
  • Destination(s) cible(s) : cible une ou plusieurs applications Cloud créées sur votre tenant. Là encore, Il est même possible d’exclure des applications si nécessaire.
  • Condition(s) : ajoute des conditions (ou signaux) présents au moment de l’authentification. Comme le risque calculé par Entra ID Identity Protection ou encore la localisation du poste.
  • Condition(s) d’accès : détermine si l’accès est bloqué et cela même si le processus d’authentification est réussi, ou conditionne l’accès selon des critères supplémentaires : MFA, poste conforme…
  • Contrôle(s) de session : renforce si besoin les conditions de persistance de la session au sein de l’application.

Fonctionnalité III – Création d’une police à partir d’un modèle :

Microsoft a proposé il y a plusieurs mois déjà de simplifier la création de police d’accès conditionnel en proposant des modèles de départ :

Ces modèles de base sont classifiées dans les 5 sections suivantes :

  • Sécurisation de base
  • Zero Trust
  • Travail à distance
  • Protection des administrateurs
  • Menaces émergentes

Par exemple, le blocage de l’authentification traditionnelle peut se faire en seulement quelques clics :

Vous pouvez à tout moment changer le statut de votre police. Cela permet de désactiver celle-ci si les résultats sécuritaires obtenus ne sont pas ceux attendus :

Fonctionnalité IV – Test d’une police avec la fonction « Et si » :

Tester une police d’accès conditionnel est possible avec un utilisateur de test ou via la fonction Et si. Cette second option est très utile si l’utilisateur n’est pas disponible ou si le scénario de test demande des conditions très particulières.

Un grand nombre de paramètres (signaux) sont disponibles pour réaliser des tests dans tous les sens :

Et le résultat ne se fait pas attendre, notre nouvelle police d’accès conditionnel créée à partir d’un modèle joue bien son rôle :

Fonctionnalité V – Déclaration de lieux nommés :

Par exemple, quand des lieux sont considérés comme des sites de l’entreprise et que la sécurité réseau est géré par le service IT, il devient utile de les renseigner ici :

Cela permet alors de créer des règles d’accès conditionnel plus précises en incluant ou excluant ces lieux :

Fonctionnalité VI – Configuration d’une MFA renforcée :

L’authentification multi-facteurs est devenue la norme pour s’authentifier sur Internet. Mais toutes les méthodes multi-facteurs ne se valent pas. Microsoft propose de laisser le choix des méthodes MFA aux administrateurs :

Par exemple, ils peuvent faire en sorte que seules les méthodes d’authentification résistantes au hameçonnage soient disponibles pour accéder à une ressource sensible. Toutefois, pour accéder à une ressource non sensible, ils peuvent autoriser des combinaisons d’authentification multifacteur (MFA) moins sécurisées, telles que mot de passe + SMS.

Microsoft Learn

Plusieurs méthodes de MFA renforcées sont déjà disponibles et il est aussi possible de créer les siennes :

Il suffit après d’appeler ces méthodes de MFA renforcées dans la configuration de la police d’accès conditionnel :

Conclusion :

L’accès conditionnel sous Entra ID a réussi s’imposer comme la référence de base dans l’autorisation d’accès aux ressources de l’entreprise. Les personnalisations possibles et la prise en compte d’exclusions apporte beaucoup de souplesse et évite la fatigue sécuritaire chez les utilisateurs. Nul doute que d’autres fonctionnalités sont encore à venir 😎.

Alertez-vous grâce à Azure Monitor

Nombreuses sont les applications critiques et, comme souvent, les équipes IT ont besoin de remontées d’alertes ou de notifications pour résoudre les interruptions de services le plus rapidement possible quand cela se produit. Mais chaque système ou application ne peuvent à eux seul être leur propre système d’alertes. C’est ici qu’intervient Azure Monitor.

Merci à Dave pour cette idée d’article 😎

Azure Monitor est une solution de monitoring complète qui permet de collecter et d’analyser des données de télémétrie en vue d’y répondre, à partir de vos environnements cloud et locaux.

Azure Monitor collecte et agrège les données de chaque couche et composant de votre système sur plusieurs abonnements et locataires Azure et non-Azure.

Microsoft Learn

Azure Monitor intègre aussi des règles d’alerte afin de prévenir les personnes concernées de données dépassants certains seuils ou lors d’évènements majeurs :

S’appuyer sur Azure Monitor pour constituer des mécanismes d’alertes, pour les environnements Cloud ou sur site, est une approche pertinente est simplifiera grandement la chaîne des actions correctives qui s’en suit.

Afin de tester les règles d’alerte d’Azure Monitor sur un cas concret, nous allons créer une machine virtuelle, dans laquelle nous configurons une petite tâche planifiée Windows.

La non-exécution périodique de la tâche planifiée Windows sera le vecteur d’alerte dans Azure Monitor :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les règles d’alerte d’Azure Monitor, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

La source de notre alerte sera directement configurée sur une machine virtuelle Azure.

Etape I – Déployez une machine virtuelle Azure :

Commencez par déployer une VM. Pour cela, rendez-vous sur le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer votre première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

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

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

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

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour vous connecter à la VM :

Cliquez sur le bouton suivant pour déployer le service Azure Bastion :

Cliquez-ici pour configurer Azure Bastion :

Cliquez sur le bouton suivant pour déployer automatiquement le service Azure Bastion :

Attendez qu’Azure Bastion soit déployé pour continuer cet exercice.

Notre machine virtuelle est maintenant déployée et est accessible. Nous allons maintenant nous y connecter afin de configurer une tâche planifiée via le planificateur de tâches Windows.

Etape II – Configurez une tâche planifiée Windows :

Cette action basique va nous montrer comment une tâche planifiée exécutée localement va remonter des informations visibles directement depuis Azure Monitor.

Ouvrez une session à distance via le service Azure Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Cliquez sur Suivant pour terminer la configuration de Windows 11 :

Modifiez si besoin les options listées, puis cliquez sur Accepter :

Ouvrez le Planificateur de tâche Windows depuis le menu Démarrer :

Créez une nouvelle Tâche planifiée :

Nommez votre Tâche planifiée, cochez les cases suivantes, puis passez sur le second onglet :

Ajoutez-y un déclencheur :

Choisissez le motif de déconnexion avec un délai de 30 minutes, ou moins si besoin, puis passez sur l’onglet suivant :

Sur l’onglet des actions, ajoutez le lancement du programme Shutdown, avec les arguments suivants :

/f /s /t 0

Validez la création de la Tâche planifiée en cliquant sur OK :

Activez l’historique des tâches planifiées afin de faire remonter l’information dans les journaux d’évènements de Windows :

Vérifiez que votre nouvelle tâche planifiée est bien présente dans la liste, et est active :

Notre environnement de départ est maintenant en place. Nous pouvons vérifier que notre tâche planifiée s’exécute correctement en :

  • Attendant quelques minutes que la session de bureau à distance ouverte via Azure Bastion déconnecte l’utilisateur pour cause d’inactivité.
  • Déconnectant directement votre utilisateur de test depuis le menu Démarrer.

Dans mon cas, j’attends que Bastion fasse le travaille à ma place :

Une fois la session déconnectée, retournez sur la liste de vos machines virtuelles Azure afin de vérifier le changement de statut de celle-ci :

Démarrez votre machine virtuelle afin de vous y reconnecter par la suite :

Confirmez votre action en cliquant sur Oui :

Environ 30 secondes plus tard, la notification Azure suivante vous indique que votre VM est correctement démarrée :

Relancez votre session Windows via Azure Bastion :

Confirmez la bonne exécution de votre tâche planifiée grâce à l’information Dernier lancement :

Ouvrez également les journaux d’évènements Windows :

Parcourez l’arborescence suivante pour constater l’historisation de votre tâche planifiée :

  • Applications and Services Logs
    • Microsoft
      • Windows
        • TaskScheduler
          • Operational

Votre environnement de test Windows est maintenant configuré.

Pour qu’Azure Monitor vous alerte sur l’exécution (ou l’absence d’exécution) de la tâche planifiée, il est nécessaire de remonter une partie des journaux d’évènements Windows dans Azure.

Etape III – Paramétrez la remontée de journaux Windows :

Pour créer notre alerte Azure, nous devons commencer par stocker les informations liées à notre tâche planifiée Windows. Il nous faut donc les stocker, quelque part dans Azure, et les alimenter par les journaux d’évènements Windows.

Nous allons avoir donc besoin d’un espace de travail Log Analytics :

Un espace de travail Log Analytics constitue un environnement unique pour les données de journaux provenant d’Azure Monitor et d’autres services Azure, comme Microsoft Sentinel et Microsoft Defender pour le cloud. Chaque espace de travail possède son propre référentiel de données et sa propre configuration, mais peut combiner des données provenant de plusieurs services.

Microsoft Learn

Le schéma ci-dessous montre de façon assez simple le fonctionnement des services Azure, piochant les données stockées dans des tables, elles-mêmes stockées dans l’espace de travail Log Analytics :

Pour cela, retournez sur le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer votre premier espace de travail Log Analytics :

Renseignez les informations de base, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la ressource, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour mettre en place la connexion avec votre VM Windows :

Dans la section des Agents, copiez le lien web pointant vers l’agent Windows en version 64 bits :

Retournez sur la session de bureau à distance de votre VM, puis collez le lien web dans Edge :

Attendez que l’agent MMA (Microsoft Monitoring Agent) se télécharge, puis cliquez-ici pour lancer son installation :

Cliquez sur Suivant :

Cliquez sur Accepter :

Cliquez sur Suivant :

Cochez la première case, puis cliquez sur Suivant :

Sur la page de votre LAW (espace de travail Log Analytics), copiez l’ID de votre espace et une des deux clefs :

Collez ces deux informations dans les champs correspondants, puis cliquez sur Suivant :

Cliquez sur Suivant :

Cliquez sur Installer :

Attendez environ une minute que l’installation se termine :

Cliquez sur Terminer pour refermer l’installation :

Attendez quelques minutes, puis rafraichissez la page suivante plusieurs fois afin de voir la bonne connection entre notre LAW et notre machine virtuelle de test :

Cliquez sur le bouton suivant afin d’ajouter le journal d’évènement relatif aux tâches planifiées Windows dans les remontées LAW :

Recherchez dans la liste le journal suivant, cochez toutes les cases, puis sauvegardez la configuration :

Microsoft-Windows-TaskScheduler/Operational

La notification Azure suivante vous indique la bonne prise en compte de ce journal :

La connexion entre notre tâche planifiée Windows et Azure est maintenant correctement établie.

Maintenant, il va nous falloir patienter plusieurs minutes afin que les prochaines remontées relatives à notre tâche planifiée de test se fassent correctement.

Etape IV – Testez votre remontée grâce à Azure KQL :

Avant de configurer l’alerte dans Azure Monitor, il est nécessaire de vérifier la présence de données dans LAW. Pour cela, nous allons utiliser le langage KQL dans notre requête sur LAW.

Le langage de requête Kusto (KQL) est un outil permettant d’explorer vos données et d’y découvrir des modèles, d’identifier des anomalies et des valeurs hors norme, de créer une modélisation statistique, etc. La requête utilise des entités de schéma organisées dans une hiérarchie similaire aux SQL : bases de données, tables et colonnes.

Microsoft Learn

Il est possible de faire des requêtes KQL directement depuis votre espace de travail Log Analytics.

Recherchez la section Logs, saisissez la requête KQL suivante afin de rechercher une trace antérieure de notre tâche planifiée Windows :

Event
| where RenderedDescription contains "Deconnexion" and RenderedDescription contains "successfully finished"

Le résultat de notre requête sera bien évidement vide, puisque la configuration de l’agent MMA a été faite après le premier test de notre tâche planifiée :

Deconnexion est le nom de ma tâche planifiée.

Attendez quelques minutes que la session de bureau à distance via Azure Bastion vous déconnecte pour cause d’inactivité :

30 minutes après la déconnexion de votre utilisateur, la machine virtuelle devrait s’éteindre au niveau OS.

Et quelques minutes plus tard, la requête KQL lancée précédemment devrait donner cette fois ci un résultat :

Afin de configurer notre alerte Azure, il est nécessaire de convertir le résultat de cette requête KQL en nombre (compteur).

En effet, dans notre exemple, notre alerte Azure doit nous informer si la machine virtuelle ne s’est pas éteinte de la journée (0).

Modifiez la requête KQL précédente comme ceci :

Event
| where RenderedDescription contains "Deconnexion" and RenderedDescription contains "successfully finished"
| count

Dans mon environnement, la tâche planifiée Deconnexion a bien été exécutée déjà 2 fois :

Tout est maintenant prêt pour configurer notre alerte Azure.

Etape V – Créez votre alerte sur Azure Monitor :

Les alertes vous permettre de détecter et de résoudre des problèmes avant que les utilisateurs ne les remarquent en vous informant de manière proactive quand les données Azure Monitor indiquent qu’il peut y avoir un problème avec votre infrastructure ou votre application.

Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor.

Microsoft Learn

Depuis votre fenêtre de requête KQL, cliquez-ici pour créer votre Alerte Azure :

La nouvelle fenêtre reprend la requête KQL précédemment affichée :

Définissez la méthode d’analyse de cette nouvelle alerte et aussi son seuil de déclenchement, puis cliquez sur Suivant :

Sous la section des Actions, cliquez-ci dessous pour créer un groupe d’actions :

Nommez-le, puis passer sur l’onglet suivant :

Dans l’onglet Notifications, définissez un type de notification Email, nommez-le également, puis renseignez une adresse email à cibler :

Cliquez sur Créer votre groupe d’actions :

De retour sur votre règle d’alerte, cliquez sur Suivant :

Nommez votre règle d’alerte Azure, puis cliquez sur Suivant :

Une fois la validation Azure réussie, lancez la création de l’alerte :

La création d’une alerte Azure entraine l’envoi immédiat d’un premier email informant la mise en place de celle-ci aux destinataires présents dans le groupe d’actions associé :

Comme notre alerte Azure est configurée par intervalle d’analyse de 24 heures, j’ai attendu quelques peu avant de recevoir le second email suivant :

Le contenu du second email nous indique bien que la tâche planifiée sur notre machine Windows n’a pas été exécutée durant la période donnée :

En effet, l’exécution de la tâche planifiée est journalisée dans Windows, lui-même connecté à notre Log Analytics workspace. La valeur à zéro de la requête KQL indique donc l’absence de lancement, et correspond surtout le seuil d’alerte configuré.

Conclusion

Ce petit exercice nous a montré le véritable potentiel des règles d’alerte d’Azure Monitor, et l’intérêt de stocker les évènements et les métriques de nos ressources Cloud ou sur site.

Afin d’aller plus loin sur ce sujet, je ne peux que vous conseiller de regarder cette autre vidéo, dédiée aux Règles de traitement des alertes :

Premiers pas dans l’IA

A la suite du Microsoft Learn Cloud Skills Challenge de 2023, Microsoft a continué les évènements liés à l’apprentissage avec le Microsoft Learn AI Skills Challenge, qui vient juste de se terminer il y a quelques jours.

L’un comme pour l’autre, leur but est de vous plonger dans l’apprentissage de produits Microsoft mais aussi de nouvelles thématiques IT innovantes.

IBM, Google, Amazon, NVIDIA, DataRobot, H2O.ai, OpenAI, Clarifai … ou encore Microsoft sont sur l’IA depuis plusieurs années, alors … pourquoi pas vous/moi ?

J’ai justement décidé de profiter de cet été pour m’y intéresser afin de me faire ma propre expérience.

Quelques termes fréquemment employés « à toutes les sauces » :

Certains termes liés à l’IA sont souvent employés à tout va. Prenons en exemple ces 3 là pour mieux les comprendre :

Source : Microsoft Learn :

  • Le Deep Learning, ou apprentissage profond, est un sous-ensemble du Machine Learning, ou apprentissage automatique, basé sur des réseaux neuronaux artificiels. Le processus d’apprentissage est qualifié de profond parce que la structure des réseaux neuronaux artificiels se compose de plusieurs couches d’entrée, de sortie et masquées.
  • Le Machine Learning est un sous-ensemble de l’intelligence artificielle utilisant des techniques (telles que le Deep Learning), qui permettent aux machines de tirer des enseignements de leur expérience pour améliorer la manière dont elles exécutent leurs tâches.
  • L’intelligence artificielle est une technique qui permet aux ordinateurs d’imiter l’intelligence humaine. Cette technique inclut donc le Machine Learning.

Sommes-nous vraiment face à une intelligence créative ou simplement générative ?

Alors pourquoi apprendre à utiliser des IAs ?

Comme le dirait très bien une IA :

Il y a plusieurs raisons pour lesquelles apprendre l’intelligence artificielle (IA) peut être bénéfique. L’IA occupe une place grandissante au sein des entreprises soucieuses d’innover et d’opérer leur transformation numériqueLes besoins en compétences relatives à cette technologie se font ainsi de plus en plus ressentir, créant de nombreuses opportunités professionnelles

Microsoft Copilot

Bref vous l’aurez compris, l’IA est même capable de s’autojustifier elle-même 🤣.

Les IAs restent une formidable boite à outils qui peuvent nous faire gagner un temps précieux dans certaines tâches.

D’ailleurs, les secteurs où les IAs œuvrent déjà ne manquent pas : marketing, santé, administratif, transport, …

Blog : doit-on encore écrire des articles « à la main » ?

Avec l’arrivée des agents conversationnels comme ChatGPT, cela devient une question légitime.

Ecrire un article sur un sujet technique est un travail long, et cela avant même le début de son écriture.

Mais la rédaction d’articles repose sur de la créativité : le sujet, les arguments, les contre-arguments, les exemples et les démonstrations.

Comment une IA générative ( et non créative) pourrait écrire et documenter quelque chose qui n’existe pas encore ou est encore insuffisamment documenté dans sa base de données ?

Bref IAs, ou pas IAs, ce sujet reste passionnant 😉

Petite vidéo intéressante sur ChatGPT :

Par où commencer ?

Le contenu d’apprentissage sur les IA est déjà vaste et conséquent. Avant de partir sur Azure, il est important de commencer avec certaines bases sur l’IA.

J’ai beaucoup apprécié les vidéos faites par IBM, disponibles ici sur YouTube et dont en voici certaines :

Microsoft a mis également à disposition plusieurs parcours d’apprentissage liés à l’IA juste ici :

Enfin et même si le Machine Learning Challenge est maintenant terminé, il est encore possible de suivre son contenu sur Microsoft Learn par ce lien :

Peut-on tester l’IA avec Azure ?

C’est justement le but de ce premier article sur le sujet, tester ensemble un premier service d’IA disponible sur Azure. Comme bien souvent, je trouve très intéressant d’utiliser les exercices Azure liés aux certifications. Microsoft les met à disposition sur sa plate-forme GitHub.

Voici donc la liste des exercices créés par Microsoft et en relation avec la première certification dédiée à l’AI : AI-900 :

Aussi je vous propose dans cet article de réaliser un premier exercice appelé Explorer la détection d’objets :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice proposé par Microsoft et basé sur une IA d’Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I Création de la ressource Azure Cognitive Services :

Nous allons utiliser ici un service central d’IA disponible sur Azure : Cognitive Services.

Mais pour la reconnaissance d’objets, nous aurions pu utiliser Custom Vision. En effet, beaucoup de services dédiés à un type d’IA sont également disponibles sous Azure.

Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :

Renseignez tous les champs suivants, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour voir votre Cognitive Services :

Le menu ci-dessous contient deux éléments importants : Clés et Point de terminaison de votre ressource Cognitive Services :

Gardez votre onglet Azure ouvert, rendez vous à la page suivante pour vous connectez au service Custom Vision, puis authentifiez avec votre compte Azure :

Acceptez les conditions d’utilisation de Custom Vision :

Cliquez-ici pour démarrer un nouveau projet Custom Vision :

Nommez projet en le configurant comme ceci, puis cliquez sur Créer :

Notre environnement IA est maintenant en place. Mais nous avons besoin de lui dire quoi faire (quoi identifier) pour que celui-ci soit à mesure de reproduire la tâche par la suite.

Etape II – Ajouts d’images étiquetées :

Pour que votre IA soit en mesure d’effectuer de la détection d’objet, elle a besoin d’être aidée lors de la phase d’identification.

En effet, l’identification IA repose avant tout sur un entrainement préalable.

Pour cela, il vous faut :

  • Télécharger des images contenant les classes que vous souhaitez que le modèle identifie.
  • Etiquetez des objets en délimitant les zones de chacun d’eux.

Une fois l’archive ZIP téléchargée, décompressez les fichiers JPG présents sur un dossier local :

Ajoutez les images d’entrainement en cliquant ici :

Validez l’envoi des 33 fichiers dans votre service Custom Vision en cliquant ici :

Attendez quelques minutes que le traitement d’envoi se termine :

Environ 2 minutes plus tard, fermez le traitement d’importation :

Cliquez sur la première image afin d’y rajoutez une ou plusieurs étiquettes Cycliste ou Piéton, selon les cas :

Sur chaque personne, choisissez le rectangle proposé par défaut ou dessinez-le avant de mettre l’étiquette appropriée (Cycliste / Piéton), puis cliquez ici pour passer sur l’image suivante :

Effectuez la même opération sur la totalité des photos téléversées (33) :

Une fois toutes les images étiquetées, retrouvez les deux classifications juste ici :

On a donné les informations de départ pour l’identification d’objets. Notre IA a maintenant besoin d’analyser les photos étiquetées pour comprendre les traits communs afin de créer la meilleure formulation possible.

Etape III – Entrainement de notre modèle d’IA :

Afin de familiariser notre IA aux photos étiquetées, Microsoft propose une fonction d’entrainement. A la différence de la phase de test qui suivra, cette étape permet de comprendre et formuler la détection et l’identification des objets.

Pour cela, cliquez sur Entrainer :

Sélectionnez l’option Formation rapide, puis cliquez sur Entrainer :

Attendez quelques minutes que le traitement se termine.

Pendant l’entrainement, il est possible de faire varier le curseur dédié au Seuil de probabilité. Comme son nom l’indique, le Seuil de probabilité correspond au minimum pour considérer la prédiction comme étant valide dans les calculs de Precision et de Recall :

A la fin du traitement, 3 indicateurs font leur apparition suite à l’entrainement :

  • Précision : Quelle est la proportion d’identifications positives réellement correctes ?
  • Recall : Quelle est la proportion de positifs réels qui a été identifiée correctement ?
  • mAP : Précision moyenne calculée comme la moyenne pondérée des précisions à chaque seuil

Notre modèle d’IA est maintenant entrainé. Un petit test s’impose avant sa publication afin d’être sûr que les systèmes fonctionnent bien.

Etape IV – Test rapide de notre modèle d’IA :

Avant de publier les API pour exploiter notre IA dans l’application, il est encore possible d’effectuer de test avec un ou plusieurs images entièrement nouvelles donc inconnues pour notre IA.

Pour cela, cliquez-ici :

Renseignez l’URL suivante, puis lancez le traitement d’analyse :

https://raw.githubusercontent.com/jlou07/ai/6071c0170056f5159aff1c6a4f612d809c8af5f5/cyclistes.jpg

L’image de test s’affiche alors et encadre en rouge les cyclistes ou piétons identifiés dans votre image. Un score de probabilité est aussi calculé pour chaque objet identifié :

Fermez la fenêtre de test rapide. Il nous est maintenant possible de publier notre modèle de détection des cyclistes et des piétons.

La publication active et autorise l’utilisation de notre modèle via le couple URL / clef.

Etape V – Publication et test réel de notre modèle d’IA :

Cliquez sur Publier pour rendre accessible notre model d’IA via son URL :

Définissez la ressource Cognitive Services créée précédemment, puis cliquez sur Publier :

Quelques secondes plus tard, notre model d’IA est enfin publié, l’URL que nous allons utiliser se trouve juste ici :

Retournez sur le portail Azure, puis ouvrez Azure Cloud Shell :

Si cela n’était pas déjà le cas, Azure Cloud Shell a besoin d’un compte de stockage Azure.

Cliquez-ici pour configurer le compte de stockage Azure pour le Cloud Shell :

Renseignez les différents champs selon vos souhaits, puis cliquez sur Créer :

Environ une minute plus tard, le message suivant apparaît. Choisissez PowerShell :

Saisissez les deux commandes suivantes pour nettoyer l’Azure Cloud Shell, et télécharger depuis GitHub les scripts utilisés pour les exercices présents dans l’AI-900 :

rm -r ai-900 -f
git clone https://github.com/MicrosoftLearning/AI-900-AIFundamentals ai-900

Lancez la commande suivante pour ouvrir le script detect-objects.ps1 dans l’éditeur Code :

cd ai-900
code detect-objects.ps1

Le script suivant apparaît alors, nous allons devoir modifier deux variables :

Pour que le script utilise bien votre model publié, identifiez champs suivants situés en haut du script :

Retournez sur la page de Custom Vision afin de copier / coller vos deux valeurs :

Cela doit donner la chose suivante :

Ensuite, lancez les deux commandes claviers suivantes :

  • CTRL + S : pour sauvegarder le script detect-objects.ps1 modifié.
  • CTRL + Q : pour quitter l’éditeur Code.

L’éditeur Code doit se fermer, gardez la fenêtre d’Azure Cloud Shell encore ouverte :

Testons l’image suivante au travers de notre modèle d’IA :

Pour cela, lancez le script suivant depuis votre fenêtre Azure Cloud Shell :

./detect-objects.ps1 1

Constatez les résultats de probabilité calculé par votre modèle :

Effectuez à nouveau l’exercice avec cette seconde image :

Pour cela, lancez ce second script depuis votre fenêtre Azure Cloud Shell :

./detect-objects.ps1 2

Constatez à nouveau les résultats de probabilité calculé par votre modèle :

Bien évidemment, votre modèle d’IA est encore imprécis et nécessitera beaucoup plus d’images pour améliorer sa précision de classification et sa probabilité de détection.

Mais c’est déjà un bon début pour comprendre comment un service d’IA, disponible sur étagère, peut faire gagner un temps précieux dans la conception d’applications.

Conclusion

Je ne peux que vous encourage qu’à tester l’IA d’Azure au travers des autres exercices disponibles sur cette liste.

A mon sens, Azure Cognitives Services et Azure Machine Learning sont de formidables outils simples d’utilisation et vous donneront une meilleure compréhension des systèmes d’IA.

Enfin, n’oubliez pas de prendre le temps de regarder des vidéos, d’assister à des trainings et de lire des articles provenant de différentes sources pour vous faire une meilleure idée de toutes les IAs passées, présentes et futures 😎.

Windows 365 Switch

Fraichement arrivé, Windows 365 Switch vous permet de pousser encore un peu plus l’intégration transparente entre votre poste local et votre Cloud PC. Pour le moment, Windows 365 Switch est uniquement accessible en préversion, Microsoft vient de l’annoncer à la communauté : Windows 365 Switch disponible en avant-première publique.

Qu’est-ce que Microsoft 365 Switch ?

Grâce à Windows 365 Switch, vous allez pouvoir basculer entre votre poste local et votre Cloud PC très facilement. Je suis presque sûr que cela préfigure l’arrivée d’un menu Démarrer unique entre vos deux ressources 😎.

Windows 365 Switch fait sens dans le cadre de scénarios BYOD (Bring-Your-Own-Device), où vous devez vous connecter depuis votre propre appareil Windows à un PC Cloud sécurisé, appartenant par exemple à l’entreprise.

Ayant besoin d’un accès constant aux ressources présentes sur les deux environnements, vous pouvez facilement passer de votre environnement personnel à votre environnement professionnel.

Windows 365 Switch permet de passer facilement d’un Cloud PC Windows 365 au bureau local en utilisant les mêmes commandes clavier familières, ainsi qu’un clic de souris ou un geste de balayage. Windows 365 Switch permet une expérience transparente à partir de Windows 11 grâce à la fonction d’affichage des tâches.

Microsoft Techcommunity

Avant de rentrer en détail sur la mise en place de cette fonctionnalité, voici une vidéo de présentation par les équipes de Microsoft :

Quels sont les prérequis pour Windows 365 Switch ?

Comme la documentation Microsoft le rappelle, utilisez Windows 365 Switch nécessite de respecter exigences suivantes :

  • Appareil physique Windows 11 Professionnel ou Entreprise.
  • Windows 365 PC Cloud licence.
  • Inscrire à la fois l’appareil physique et le PC cloud dans le canal bêta du programme Windows Insider (par défaut) ou le canal de développement.

Concernant l’obligation de l’appareil physique, je ne suis pas entièrement d’accord, et je vais vous le démontrer en utilisant une machine virtuelle AVD lors de mon test.

Dans celui-ci, vous trouverez toutes les étapes nécessaires, de la création à la connexion à la machine virtuelle, au test de la fonctionnalité Switch :

Etape 0 – Quels sont les prérequis pour tester Windows 365 Switch ?

Pour réaliser cet exercice sur Windows 365 Switch, il vous faudra disposer des ressources suivantes :

  • Une souscription Azure valide
  • Une licence Windows 365

Dans notre exercice, nous allons donc commencer par créer une machine virtuelle via Azure Virtual Desktop afin de servir de poste local de test.

Etape I – Préparation d’Azure Virtual Desktop :

Commençons par créer notre machine virtuelle AVD de test pour simuler notre poste local.

Pour cela, rendez-vous dans le portail d’Azure afin créer un réseau virtuel en utilisant la barre de recherche en haut de l’écran :

Cliquez ici pour créer votre réseau virtuel pour la VM AVD :

Renseignez les différents champs, puis lancez validation du template par Azure :

Une fois la validation réussie, lancez la création de la ressource :

Attendez environ une minute que le réseau virtuel Azure soit créé, puis continuez la création des ressources AVD en utilisant la barre de recherche Azure :

Cliquez-ici pour créer un nouvel environnement Azure Virtual Desktop :

Renseignez les champs du premier onglet, puis cliquez sur Suivant :

Inutile de modifier l’accès réseau AVD sur le second onglet, cliquez sur Suivant :

Renseignez les informations liées aux machines virtuelles AVD en prenant soin de choisir une image présente dans la liste de celles compatibles avec Windows 365 Switch :

Définissez les performances voulues pour votre VM, puis renseignez le réseau virtuel créé précédemment :

Joignez vos VMs AVD à Azure AD, renseignez un mot de passe administrateur local, puis cliquez sur Suivant :

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

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

Le traitement Azure devrait durer une dizaine de minutes environ.

Une fois terminé, cliquez sur le nom du groupe de ressources afin d’y mettre les droits pour votre utilisateur de test :

Dans la section des rôles RBAC Azure sur le groupe de ressources AVD, ajoutez les rôles suivants pour votre utilisateur AVD :

Activez la fonction suivante pour profiter du SSO dans les propriétés RDP, puis sauvegardez :

Rafraichissez plusieurs fois afin que la machine AVD soit prête et marquée comme connectable :

Notez l’apparition récente de ces 2 nouveaux indicateurs.

Quelques rafraichissements plus tard, la machine virtuelle AVD est bien indiquée comme disponible :

Votre environnement Azure Virtual Desktop est maintenant prêt. Nous allons pouvoir maintenant nous connecter à ce poste local simulé pour le mettre à jour.

Ouvrez le client Remote Desktop, ou installez-le depuis ce lien si cela n’est pas encore le cas :

Utilisez la fonction suivante pour faire apparaître la machine AVD :

Authentifiez-vous avec votre utilisateur de test AVD :

Cliquez sur l’icône de bureau à distance :

Autorisez-les connections de bureau à distance à partir de l’identité Azure AD de votre utilisateur de test AVD :

Attendez que le bureau à distance Windows 11 AVD s’ouvre :

Allez dans les paramétrages Windows :

Cliquez-ici pour rejoindre le programme Windows Insider :

Avant de pouvoir rejoindre le programme Windows Insider, cliquez sur cette alerte afin d’activer la remontée de données de diagnostic :

Activez l’option, puis retournez sur la page principale des paramètres Windows :

Cliquez sur Commencer afin d’activer le programme Windows Insider :

Utilisez le compte de votre utilisateur de test AVD pour rejoindre le programme :

Cliquez sur Continuer pour accepter les conditions du programme liées aux données privées :

Choisissez le canal Dev ou Beta, puis cliquez sur Continuer :

Considérez si besoin les particularités du canal Dev, puis cliquez sur Continuer :

Cliquez sur Continuer pour accepter les conditions du programme liées à votre poste :

Redémarrez la VM de test local :

Comme attendu, la session Windows de l’utilisateur de test se ferme en y indiquant le motif :

Environ 30 secondes plus tard, réouvrez la session Windows de votre utilisateur de test :

Retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour, dont celles-ci :

Lancez si besoin manuellement certaines mises à jour :

Attendez l’installation complète de toutes les mises à jour :

Une fois les installations terminées, lancez à nouveau un redémarrage de la VM de test local :

Attendez que le redémarrage se termine :

Afin de tester Windows 365 Switch, il est nécessaire de rejoindre également le programme Windows Insider sur la machine Windows 365.

Etape II – Préparation de Windows 365 :

Il est nécessaire de disposer des droits administrateurs pour notre utilisateur de test Windows 365.

Pour cela, rendez vous sur le portail Intune sur l’adresse suivante, puis créez une nouvelle configuration utilisateur comme ceci :

Renseignez les informations suivantes en cochant bien la case Local admin, puis cliquez sur Suivant :

Ajoutez le groupe d’utilisateurs Windows 365, puis cliquez sur Suivant :

Lancez la création de votre configuration utilisateur :

Attendez quelques minutes que la configuration utilisateur s’applique bien à votre poste Windows 365 :

Ouvrir une nouvelle session de bureau à distance, cette fois sur votre poste Windows 365 :

Comme précédemment sur la VM AVD, cliquez-ici pour rejoindre le programme Windows Insider sur votre poste Windows 365 :

Suivez les différentes étapes Insider, puis lancez le redémarrage de votre Cloud PC :

Retournez sur les paramètres Windows, puis constatez l’apparition de nouvelles mises à jour pour votre poste Windows 365 :

Attendez l’installation complète de toutes les mises à jour :

Une fois les installations terminées, lancez à nouveau un redémarrage de votre poste Windows 365 :

Attendez que le redémarrage se termine :

Vérifiez la présence de la mention suivante liée à Insider sur votre poste Windows 365, la version doit être supérieure ou égale à 22631.2129 :

Retournez sur votre machine de test AVD.

Etape III – Installation de Windows 365 :

Ouvrez le Windows Store, recherchez l’application Windows 365, puis installez-la :

Une fois l’installation terminée, ouvrez l’application Windows 365 :

Utilisez le compte approprié pour ouvrir la session Windows 365 :

Renseignez les identifiants de votre utilisateur de test disposant de la licence Windows 365 :

Passez les différentes pages d’aide :

Vérifiez la version de votre application Windows 365, celle-ci doit être supérieure ou égale à 1.3.177.0 :

Connectez-vous une première pour vérifier que tout fonctionne bien :

Utilisez le compte disposant de la licence Windows 365 :

Vérifiez l’absence de la nouvelle fonctionnalité Windows 365 Switch :

Et attendez 🤣🤣🤣.

Etape IV – Test de Windows 365 Switch :

Anecdote :

La fonctionnalité Switch n’est pas apparue immédiatement, c’est le moins que l’on puisse dire…

J’ai dû passer par plusieurs mis à jour Insider sur le poste et le Cloud PC et attendre environ 48 heures avant de pouvoir apercevoir la fonctionnalité apparaître dans le menu de l’application Windows 365.

A ce jour, je vois bien le menu Switch. Voici donc les différentes versions de mon environnement de test :

Windows 11 Azure Virtual Desktop :

Application Windows 365 :

Windows 365 Cloud PC :

Comme vous pouvez le constater, la fonctionnalité Switch apparaît donc bien dans mon environnement AVD de test :

Et l’aide y est également reportée dans les Actions rapides :

Un simple clic dans le menu suffit à activer la fonction :

Cliquez alors ici pour ouvrir la session Windows de votre Cloud PC :

La première ouverture de session affiche le premier écran de chargement suivant :

Comme indiqué, il est possible d’attendre ou de retourner sur le poste local, le temps que le chargement de la session Windows de votre Cloud PC se termine.

Attendez un peu, puis constatez le changement d’écran de chargement précédent par celui-ci :

Quelques secondes plus tard, le bureau Windows du Cloud PC s’ouvre :

Depuis le Cloud PC, retournez sur votre PC local comme ceci :

Et l’autre sens est également tout aussi simple :

Vous pouvez évidement réutiliser les raccourcis claviers habituels et les gestes pour basculer entre votre Cloud PC et votre PC local :

  • Ctrl+Win+flèche gauche : Déplacer un bureau vers la gauche.
  • Ctrl+Win+flèche droite : Déplace un bureau vers la droite.
  • Balayage à quatre doigts vers la gauche ou la droite : Passer d’un bureau à l’autre.

Conclusion

Microsoft continue encore et toujours de rendre la solution Windows 365 encore plus simple et l’enrichie très régulièrement de nouvelles fonctionnalités. Comme pour le boot direct sur le Cloud PC, Switch s’intègre dans cette approche unifiée entre le poste local et Windows 365 permet une fois de plus d’adoucir la barrière avec le Cloud.

Comme annoncée en introduction de cet article, l’intégration commune et complète des 2 barres Démarrer sera à coup sûr une amélioration majeure !