Skip to content
Call To Action
juin 5 2024

Quel est l’impact de la dépréciation des modules AzureAD et MsOnline sur l’optimisation des processus de migration chez Kaizzen ?

Admin
Blog Details

Quel est l'impact de la dépréciation des modules AzureAD et MsOnline sur l'optimisation des processus de migration chez Kaizzen ?

Lors de mon précédent article nous avons vu la fin des modules PowerShell AzureAD et MsOnline. Pour rappel lors d’une migration d’un Tenant Microsoft 365 vers un Tenant Microsoft 365, nous exécutons une succession de scripts PowerShell afin de réaliser différentes étapes nécessaires à la migration comme :

Design sans titre - 2024-05-16T163617.376

–          Auditer un Tenant source

Design sans titre - 2024-05-16T163623.340

Récupérer la liste de tous les objets présents sur le tenant source

Design sans titre - 2024-05-16T163638.336

Création des objets à migrer sur le tenant cible

Design sans titre - 2024-05-16T164034.182

Actions de pré-migration

Design sans titre - 2024-05-16T164044.343

Action de bascule finale

Toutes les étapes sont lancées de manières indépendantes via des scripts unitaires et non communicant, ce qui implique des phases, comme la connexion répétitives.

L’arrêt des modules AzureAD et MSOnline, qui était omniprésent dans nos scripts, nous a obligé de recoder nos scripts avec l’utilisation du module MsGraph.

Ma réflexion a donc été la suivante, comment optimiser et automatiser un maximum nos processus de migration ?

L’application Interactive PowerShell

Avant de me lancer dans le développement de l’application j’ai commencé par réfléchir quels interactions l’utilisateur aurait, quel menu allait être appelé et quelle fonctions serait disponible dans le menu. Voici donc le schéma que j’ai imaginé pour l’application et celui sur lequel je me suis appuyé pour la développer. L’application est basée sur des menus qui font appels à d’autres menus et à des fonctions contenus dans des modules afin de faciliter le développement de l’application.

Modules PowerShell Kesako ?

Un module PowerShell est une unité réutilisable et autonome qui peut contenir des applets de commandes. Un module PowerShell permet de fournir des fonctions qui seront appelées dans d’autres scripts. Les modules sont des fichiers de type « psm1 »

J’ai donc décidé de couper tous nos scripts unitaire en modules ainsi que les différents menus de l’application en module, pour un total de 56 modules

Une fois que les modules ont été créés et fonctionnels. Il a fallu créer la base de l’application, c’est-à-dire le lancement de celle-ci. C’est donc un script PowerShell permettant d’importer les modules créés et de se connecter à tous les modules Microsoft nécessaire au fonctionnement de l’application, enfin il lance le menu principal de l’application.

Une fois l’application lancée et arrivé sur le menu principal, l’utilisateur peut choisir si le tenant sur lequel il est connecté est le Tenant Microsoft Source ou Cible.

De ce choix va découler une succession de menus qui auront des choix et actions possibles comme des exports en Excel, des Audit en HTML, la création d’objets sur un Tenant Microsoft ou encore la modification d’objet pour l’ajout d’Alias… Tout dépendra de la phase de migration dans laquelle nous sommes.

Conclusion

La dépréciation des modules AzureAD & MsOnline nous ont donc permis de prendre de la hauteur sur nos processus de migration et de les revoir afin de les industrialiser un maximum pour augmenter le confort lors d’une migration. Cette réflexion et cette prise de hauteur, qui a permis d’industrialiser un processus simple de migration, m’a permis de me poser des questions sur les autres processus chez Kaizzen comme la mise en place d’un Intune qui est standardisé en interne et qui pourrait être industrialiser aussi sous forme d’application interactive PowerShell.

Gianni Lattanzio, Consultant Cloud Microsoft chez Kaizzen

Blog comments

Recent Post