C’est en 2019 que Microsoft annonce la fin et la mise hors service de certains modules Powershell permettant l’interaction avec un tenant Office365. Ces modules sont connus et beaucoup utilisés, à savoir :
-AzureAD
-Azure AD Preview
-MS Online
Dans cet article nous verrons en quoi ces modules étaient et sont encore utilisés, par quoi ils sont et seront remplacés, ce que ça implique dans l’usage quotidien du Powershell chez Kaizzen et comment nous allons procéder pour ajuster nos processus actuels basés sur ces modules.
Les changements dans le monde PowerShell.
C’est le 15 juin 2023 que sur le site TechCommunity de Microsoft qu’on peut lire un article sur les mises au point sur les changements dans le monde PowerShell et les interactions avec un tenant Azure. Microsoft souhaite donner plus de clarté sur les changements et à quoi on doit s’attendre à l’avenir. Microsoft ne développe plus et n’investi plus de temps sur les modules Azure AD et MS Online et met en garde les utilisateurs à prioriser l’utilisation de la plateforme Microsoft Graph API via le SDK PowerShell.
Qu’est-ce que la plateforme Microsoft Graph API ?
Les Microsoft Graph API sont des interfaces de programmation fournies par Microsoft, permettant d’accéder et d’interagir avec quasiment toutes les fonctionnalités proposées par Microsoft que ce soit Office365, EndPoint Manager ou Azure. Via les API Graph, Microsoft permet d’avoir une seule porte d’entrée sur un environnement via une application Azure pour y d’interconnecter d’autres services permettant d’interagir.
Cependant Microsoft tient à rassurer les clients en expliquant qu’ils s’engagent à continuer le support le temps de la migration vers la plateforme Microsoft Graph API afin de minimiser les impacts de production qu’un tel changement peut impliquer.
Microsoft annonce que la date du 30 Juin 2023 marque la fin d’une période de préavis de 3 ans pour la dépréciation du service AzureAD Graph, et c’est à partir de cette date qu’un cycle est de retrait des cmdlets du service Azure AD Graph est initié, ce qui signifie la fin du SLA (Service Level Agreement) du module et des mises à jour de sécurité. La première étape est le blocage des nouvelles application créées à partir du service AzureAD Graph avec un préavis de 3 mois. Les autres étapes sont annoncées au fur et à mesure par Microsoft.
Microsoft tient tout de même à assurer aux clients qu’à partir du 30 Juin 2023, les applications utilisant le service Azure AD Graph continuerons de fonctionner mais qu’il ne sera pas possible d’en créer de nouvelles.
La date du 30 Septembre 2023 marque la fin des cmdlets PowerShell d’attribution de licences, à savoir :
– Set-AzureADUserLicense,
– Set-MsolUserLicense,
– L’attribut -LicenseAssignment ou -LicenseOptions de New-MsolUser
Cependant Microsoft reconnait que certains modules PowerShell sont encore nécessaires dans certains scénarios car ils n’ont pas encore d’équivalents en Graph API, c’est pourquoi la date de dépréciation des modules MS Online, Azure AD et Azure AD Preview est repoussée au 30 Mars 2024.
Microsoft affirme qu’après le 30 mars 2024, les scripts PowerShell utilisant les modules Azure AD, Azure AD Preview et MS Online ne seront plus maintenu et que seulement un support pour une migration vers la plateforme Microsoft Graph API et le SDK PowerShell sera proposé de leur part. Une période de préavis de 6 mois sera effectif pour migrer avant le retrait dès l’annonce de leur dépréciation.
Quels changements pour Kaizzen ?
Aujourd’hui les scripts PowerShell font partis du quotidien de notre travail au sein de Kaizzen. Essentiellement lors de projets de migration. Les scripts PowerShell sont beaucoup utilisés que ce soit dans l’export de la donnée, tout comme dans l’import de données.
Lors de l’export de la données, nous avons besoin de récupérer les informations des utilisateurs, que ce soit, l’UserPrincipalName, l’adresse mail, la licence…
Dans la partie import de la données, c’est-à-dire création des utilisateurs sur un tenant Office 365 cible, il en est de même pour les informations à créer et surtout la licence à attribuer à l’utilisateur.
Le module dépréciation du module Azure AD impact aussi la manière d’interagir avec le tenant Azure pour récupérer ou paramétrer des informations comme les commandes AzureADDevice pour interagir avec les appareils connectés à un Azure.
Pour palier à la dépréciation des modules, un travail est fait en interne pour revoir tous les processus de migrations et d’interactions utilisés pour les refaire en Microsoft Graph API, ce qui inclus de la formation sur l’utilisation des Graph API, le développement et le test.
L’amélioration continue de l’utilisation des Graph API chez Kaizzen ?
Personnellement lors de mon auto-formation aux Graph API, je me suis posé la question « Comment fonctionnent les outils que j’utilise pour les migrations ? »
C’est à ce moment que je me suis rendu compte que la plupart des outils type Quest On Demand, ShareGate, BitTitan… utilisent pour la plupart des Graph API via des appels POST, GET, PUT… A partir de là je me suis donc intéressé au fonctionnement des Graph API.
Lorsqu’on s’intéresse au fonctionnement des appels API REST du Graph, celui-ci est composé d’une « simple » URL https://graph.microsoft.com/{version}/{resource}?{query-parameters} la réponse et est du format JSON. A première vue l’utilisation est plutôt simple, facilement testable, grâce au site Explorer Graph de Microsoft https://developer.microsoft.com/en-us/graph/graph-explorer, et l’accès à toutes les ressources est facile. C’est à ce moment que je me suis dit « Et pourquoi ne pas faire comme les autres ? »
Ma réflexion a été que l’URL utilisé est, d’après Microsoft, toujours la même, que les requêtes sont toujours et les mêmes et les attributs retournés par les résultats toujours les mêmes donc très peu de chance d’avoir de grands changements dans l’avenir et donc pourquoi ne pas automatiser et de manière graphique nos processus actuels de migration ? Pourquoi ne pas développer une application qui serait capable, via des requêtes HTTP Graph d’aller se connecter à un Tenant Office 365, lancer des requêtes pour extraire la données, la restituer sur une base de données, et à partir de cette base aller créer la données toujours en requetes Graph HTTP sur un tenant cible ?
Ce que aujourd’hui nous faisons via une succession de scripts PowerShell, pourrait demain se faire en cliquant sur des boutons et en utilisant des appels API qui évoluent très peu au fil des années.
Julie Mathey, Consultante cloud Microsoft chez Kaizzen
