Recherche de site Web

Comment changer de licence Microsoft 365 pour les comptes Entra ID


Changer de licence Microsoft 365 tout en préservant l'ensemble des plans de service

Après avoir lu l'article sur la gestion des licences avec le SDK Microsoft Graph PowerShell, un lecteur a demandé quelle était la meilleure façon de changer de licence Microsoft 365 pour les comptes Entra ID tout en préservant la continuité du service (voici la question complète). Le problème ici est que chacune des licences de compte qui doivent être traitées peut avoir un ensemble différent de plans de service désactivés. Changer une ou deux licences est facile à effectuer manuellement ; changer rapidement de centaines devient un exercice très ennuyeux. C’est alors que l’automatisation via PowerShell devient un outil précieux pour les administrateurs de locataires.

L’exercice impliquait le passage des licences utilisateur d’Exchange Online Plan 2 à Microsoft 365 E3. Je prévois que cette exigence s'appliquera aux locataires disposant de licences Office 365 E3 ou Office 365 E5 qui découvrent qu'ils doivent effectuer une mise à niveau vers Microsoft 365 E3 ou Microsoft 365 E5 pour devenir éligibles à l'utilisation de Microsoft 365 Copilot. La mise à niveau de la licence doit avoir lieu avant qu'un locataire puisse acheter le minimum de 300 sièges Copilot et décider qui obtiendra les coûteuses licences Copilot à 30 $/mois.

Les licences basées sur un groupe constituent une bonne solution pour l'attribution automatisée des licences. Les administrateurs peuvent personnaliser les configurations de licence en désactivant les fonctionnalités. Ce que nous explorons ici, c'est le changement de licence par script en supprimant une ancienne licence et en la remplaçant par une nouvelle licence. Un locataire peut décider d'adopter cette approche pour avoir un contrôle total sur le flux des attributions de licences.

Tout sur les plans de service

Habituellement, il n’y a aucun problème à maintenir l’ensemble des fonctionnalités disponibles pour les utilisateurs lors de la mise à niveau des licences. Une licence de niveau supérieur offre toujours plus de fonctionnalités qu'une licence de niveau inférieur. Microsoft contrôle la disponibilité des fonctionnalités via les plans de service. Un plan de service détermine si la fonctionnalité qu'il contrôle est activée ou désactivée. Par exemple, si un locataire ne souhaite pas utiliser Viva Engage (Yammer), il doit désactiver le plan de service Viva Engage Core dans les licences attribuées aux comptes d'utilisateurs. Les locataires désactivent souvent les plans de services obsolètes que Microsoft propose encore, comme StaffHub, Sway et Kaizala. La figure 1 montre un compte avec une licence Office 365 E3 avec deux plans de service désactivés.

La tâche consiste à s'assurer que la licence mise à niveau attribuée aux comptes d'utilisateurs conserve les mêmes fonctionnalités. En d’autres termes, si un plan de service est désactivé dans l’ancienne licence, il doit l’être dans la nouvelle.

La propriété AssignedLicenses stocke les informations de licence pour les comptes d'utilisateurs. Parmi les informations conservées pour une licence figure l’ensemble des plans de services désactivés. Par exemple, cette sortie montre que quatre plans de services désactivés sont présents pour une licence Microsoft 365 E5.

$User = Get-MgUser -UserId Chris.Bishop@office365itpros.com -Property AssignedLicenses

$User.Assignedlicenses | fl

DisabledPlans        : {0d0c0d31-fae7-41f2-b909-eaf4d7f26dba, 0898bdbb-73b0-471a-81e5-20f1fe4dd66e, 8c7d2df8-86f0-4902-b2ed-a0458298f3b3, 7547a3fe-08ee-4ccb-b430-5077c5041653…}
SkuId                : 06ebc4ee-1bb5-47dd-8120-11324bc54e06

La mémorisation des GUID des plans de produits et de services n’est pas une tâche facile. Vous pouvez télécharger un fichier CSV contenant des informations sur les GUID et les noms associés aux produits et aux plans de services. Microsoft actualise périodiquement le fichier CSV et il est possible de lire les informations du CSV dans des tableaux pour rendre les données accessibles dans les scripts PowerShell.

Vous pouvez prendre l'ensemble des plans de service désactivés et l'utiliser lors de l'attribution d'une nouvelle licence de produit. Cela fonctionnera si la nouvelle licence prend en charge les mêmes plans de service que l'ancienne. Malheureusement, ce n'est pas le cas. Par exemple, il existe différentes versions de plans de service pour des applications telles que To Do, Forms et Exchange Online. Pour être sûr que l'ensemble des plans de services désactivés est répercuté sur la nouvelle licence, vous devez déterminer les équivalents des plans désactivés de l'ancienne licence et utiliser ces valeurs lors de l'attribution de la nouvelle licence.

Création d'un script pour changer de licence Microsoft 365

Pour comprendre les étapes nécessaires pour changer de licence pour les comptes d'utilisateurs, j'ai décidé d'écrire un script pour mettre à niveau les comptes d'une licence Office 365 E3 vers une licence Microsoft 365. Le code :

  • Récupère l’ensemble des abonnements (produits achetés) pour le locataire.
  • Importe les informations sur les produits et les plans de services publiées par Microsoft.
  • Construit des tables de hachage pour les produits utilisés dans le locataire et les plans de service. Ces tables de hachage sont utilisées pour une recherche rapide afin de résoudre les GUID en noms de produits et de plans de services.
  • Crée des tableaux de plans de service dans les anciennes et les nouvelles licences et utilise ces données pour déterminer les GUID du plan de service correspondant afin de garantir que les fonctionnalités désactivées sont conservées. Le résultat est un tableau dans lequel le script peut rechercher un plan de service désactivé dans l'ancienne licence afin de déterminer la valeur correcte à utiliser lors de l'attribution de la nouvelle licence. Le script apporte une nouvelle modification au tableau pour ajouter une entrée pour Kaizala car les noms des plans de services sont assez différents dans les deux licences (KAIZALA_O365_P3 et KAIZALA_STANDALONE).
  • Recherche l'ensemble des comptes d'utilisateurs avec les licences Office 365 E3.
  • Crée une liste de comptes et d'informations sur le plan de service désactivé. Une entrée dans la liste ressemble à ceci :
UserId        : 96155a51-6885-4c8f-a8b6-e1614af08675
DisplayName   : John James
SkuId         : 6fd2c87f-b296-42f0-b197-1e91e994b900
DisabledPlans : {aebd3021-9f8f-4bf8-bbe3-0ed2f4f047a1, 7547a3fe-08ee-4ccb-b430-5077c5041653}
  • Parcourt la liste. Pour chaque compte, déterminez l'ensemble des plans de service désactivés pour la nouvelle licence, puis exécutez l'applet de commande Set-MgUserLicense pour ajouter la nouvelle licence au compte. Si l'attribution de licence réussit, une commande Set-MgUserLicense distincte supprime l'ancienne licence. Malgré la prise en charge du « empilement de licences » dans des applications telles qu'Exchange Online, il est plus sûr de supprimer des licences uniquement lorsque vous êtes sûr qu'une licence de remplacement est en place. Voici le code pour ajouter la nouvelle licence et supprimer l’ancienne. Vous pouvez voir que l'ensemble des plans de services désactivés est transmis sous forme de tableau dans le paramètre DisabledPlans :
$Status = Set-MgUserLicense -UserId $User.UserId -AddLicenses @{SkuId = $NewSKU; DisabledPlans = $DisabledServicePlansToUse} `
        -RemoveLicenses @() -ErrorAction SilentlyContinue
If (!($Status)) {
    Write-Host "Error assigning license - please check availability" -ForegroundColor Red
} Else {
    Write-Host ("{0} license assigned to account {1}" -f ($TenantSkuHash[$NewSKU]), $User.DisplayName )
    # Now to remove the old license
    $Status = Set-MgUserLicense -UserId $User.UserId -AddLicenses @() -RemoveLicenses $OriginalSku -ErrorAction SilentlyContinue
    If ($Status) {
        Write-Host ("{0} license removed from account {1}" -f ($TenantSkuHash[$OriginalSKU]), $User.DisplayName )
    }
}

Vous pouvez télécharger le script depuis GitHub. Comme toujours, la mise en garde s'applique : bien que le code fonctionne, il n'est pas prêt pour la production. Des tests supplémentaires et probablement du développement sont nécessaires pour protéger le code et le rendre prêt à être utilisé dans votre locataire. Par exemple, pensez à ajouter une vérification qu'une licence est disponible avant de procéder à son attribution. Mais le code PowerShell est simple et devrait être assez facile à suivre.

Plusieurs voies vers une solution

L’avantage de l’utilisation de PowerShell pour automatiser les activités administratives dans Microsoft 365 réside dans sa flexibilité et le degré de contrôle qu’il offre. Ce n’est pas une raison pour toujours choisir PowerShell lorsqu’un logiciel prêt à l’emploi est disponible. Les licences basées sur les groupes géreront probablement de nombreux scénarios d’attribution de licences que vous rencontrerez. Mais si les licences basées sur les groupes ne peuvent pas répondre à vos besoins, il est bon de savoir qu’il existe toujours PowerShell.

Articles connexes