Les différents méthodes de migration Utilisateurs Skype OnPremises vers Teams

blog ai3 skypetoteams-300x103 Les différents méthodes de migration Utilisateurs Skype OnPremises vers Teams

Comme vous le savez surement Teams est de plus en plus présent dans nos infrastructures.
Une des questions qui se pose concerne la migration des utilisateurs de Skype For Business 2015 OnPremise vers cette nouvelle plateforme de communication et de collaboration.

blog ai3 2019-01-09_130308-203x300 Les différents méthodes de migration Utilisateurs Skype OnPremises vers Teams

Il existe donc à ce jour plusieurs méthodes pour migrer un utilisateur de Skype vers Teams.
La première consiste à migrer les utilisateurs en deux temps:
– Migration de l’utilisateur vers Skype Online
– Bascule de l’utilisateur sur Teams

La seconde consiste quant à elle, à mettre à niveau la plateforme Skype For Business 2015 OnPremise vers une infrastructure Skype For Business 2019 OnPremise.
Cette nouvelle version à l’avantage de gérer la migration directe d’un utilisateur Skype For Business OnPremise vers Teams sans passer par l’étape Skype For Business Online.
– Migration de l’utilisateur vers Teams via la commande Move-csUser et le paramètre -MoveToTeams

Cependant, il existe une troisième méthode. Cette dernière permet de migrer vers Teams directement depuis Skype for Business 2015 OnPremise grâce au Cumulative Update 8 de Skype For Business 2015 OnPremise publié en Janvier 2019.
Cette mise à jour ajoute donc de nouvelles fonctionnalités Powershell comme le commutateur -MoveToTeams (que l’on trouve nativement dans la version 2019 du produit) mais également l’option de migration vers Teams depuis le Control Panel.

Avant Cumulative Update

blog ai3 2019-01-09_172505-300x204 Les différents méthodes de migration Utilisateurs Skype OnPremises vers Teams

Apres Cumulative Update

blog ai3 2019-01-09_172323-300x235 Les différents méthodes de migration Utilisateurs Skype OnPremises vers Teams

En conclusion, dans le but d’une migration complète des utilisateurs vers Teams et d’un abandon de la solution Skype OnPremise, la mise a jour cumulative représente le meilleur choix, laissant la possibilité de migrer un utilisateur soit en 2 temps en passant par l’étape Skype Online soit directement de Skype For Business OnPremise vers Teams.
En revanche dans le cadre d’une migration partielle des utilisateurs vers Teams et d’une conservation d’une infrastructure Skype OnPremise, on privilégiera la mise à niveau de l’infrastructure vers Skype For Business 2019.

Pour plus d’information concernant les modes de migration:
https://docs.microsoft.com/fr-fr/skypeforbusiness/hybrid/move-users-from-on-premises-to-teams

Astuces SharePoint Online avec PnP-PowerShell

Cet article recense des opérations hyper-condensées en PnP-PowerShell vous permettant de gérer vos sites SharePoint Online. Avant de vous en servir, assurez-vous d’avoir installé les modules PnP-PowerShell (disponibles ici), d’avoir lancé une fenêtre PowerShell (ISE ou non), et de vous être connecté à votre collection de sites à l’aide la commande Connect-PnPOnline.

Remarque : ces commandes n’ont pas vocation à être performantes en temps d’exécution, simplement à rendre un service en un minimum de lignes. Donc, à ne pas utiliser sur des volumes de données très importants

(suite…)

Alternative aux dépréciations de commandes PowerShell Skype et Teams

Le saviez vous?

Si dans le cadre de l’administration d’infrastructure Skype Team Online, vous utilisiez des commandes Powershell telles que Get-CsActiveUserReport, Get-CsP2PSessionReport, Get-CsUserActivitiesReport, Get-CsConferenceReport… Sachez que ces commandes (et d’autres) ont été dépréciées par Microsoft depuis le début d’année 2018.

blog ai3 depreciated_cmd-300x17 Alternative aux dépréciations de commandes PowerShell Skype et Teams

La solution de remplacement à ces commandes se trouve donc être désormais Microsoft Graph.
Microsoft Graph permet d’accéder aux données et aux renseignements dans Office 365 en utilisant l’API fournie par Microsoft dans le but de créer des applications pour les organisations et les clients afin de se connecter directement à de nombreuse ressources via un point de connexion unique, https://graph.microsoft.com, notamment pour:

– Azure Active Directory
– Les services Office 365: Sharepoint, OneDrive, Outlook/Exchange, Skype Teams…
– …

blog ai3 MSGRAPH-300x187 Alternative aux dépréciations de commandes PowerShell Skype et Teams

Microsoft Graph se connecte à toutes les ressources de ces services à l’aide de relations. Par exemple, un utilisateur peut être connecté à un groupe via une relation memberOf et à un autre utilisateur via une relation manager. L’application peut donc parcourir ces relations pour accéder à aux ressources connectées et effectuer des actions via l’API.

Vous pouvez également obtenir des informations précieuses sur les données de Microsoft Graph. Par exemple, vous pouvez récupérer les informations concernant l’usage de Skype Teams au sein de l’organisation (nombre de session Audio/Vidéo, nombre de connexion, temps de chaque session…)

Ci dessous un exemple de script permettant la récupération des informations concernant l’activité des utilisateurs Skype Online.
blog ai3 example1-1-300x103 Alternative aux dépréciations de commandes PowerShell Skype et Teams
Exemple d’un fichier d’extraction en sortie de script:
blog ai3 example2-300x118 Alternative aux dépréciations de commandes PowerShell Skype et Teams

Source: https://developer.microsoft.com/fr-fr/graph

Azure VM Scale Sets : 3 Création du scaleset à partir du vhd

Dans le dernier article de cette série nous allons :

  • Récupérer le blob du vhd modèle
  • Créer un scaleset à partir du vhd
  • Mettre à jour un scaleset à partir du vhd

Cet article s’inscrit dans une série d’articles visant à montrer comment créer un groupe de machines virtuelles identiques à partir d’une machine virtuelle modèle.

3ème étape créer ou mettre à jour le scaleset

1. Initialiser les variables

2. Récupérer le blob du vhd modèle

3. Créer le VMSS à partir du vhd

Nous allons vérifier si un groupe de machine existe déjà, sinon nous allons créer celui-ci.

Comme pour la copie de la vm nous utilisons un template ARM pour configurer la machine. Pour des informations plus détaillées sur celui-ci vous pouvez vous référer à la documentation officielle.

La partie intéressante est « virtualMachineProfile », c’est dans celle-ci que l’on indique que le scaleset se base sur le vhd de la machine modèle.

Le fichier suivant contient les paramètres du template ARM :

4. Mettre à jour le scaleset à partir du vhd

Si vous avez déjà créé le groupe de machines virtuelles il est possible de mettre à jour celui-ci à partir de votre nouvelle image modèle. Il faut ensuite déployer sur chaque instance de votre scaleset la mise à jour.

A l’issue de cette série d’articles nous avons, à l’aide de powershell et des templates ARM:

  • Créé une copie d’une vm existante
  • Généralisé celle-ci
  • Transféré le vhd d’un espace de stockage à un autre
  • Créé ou mis à jour un scale set à partir de l’image

J’espère que cette série d’article a pu vous éclairer sur ce processus !

 

Azure VM Scale Sets : 2 Création du vhd modèle

Dans ce second article sur Azure nous allons :

  • Généraliser notre VM modèle temporaire
  • Sauvegarder notre image modèle ainsi générée

Lors de la première étape nous avons créé une machine virtuelle, copie temporaire de notre modèle, sur laquelle nous avons automatiquement lancé un script de généralisation. Un fichier .vhd sera généré et sera prêt à être utilisé dans un scaleset azure à l’issue de cet article.

2ème étape généraliser la machine virtuelle temporaire

1. Récupérer et éteindre la vm modèle temporaire

2. Finaliser la généralisation de la vm temporaire

A l’étape précédente nous avons généralisé la vm à l’aide de sysprep.exe. Il faut indiquer à Azure que la machine a été généralisée.

3. Sauver la vm généralisée sous la forme d’un vhd

Maintenant que notre machine virtuelle est entièrement généralisée nous pouvons extraire l’image (vhd) que nous utiliserons pour le scaleset.

Le paramètre -Path correspond au chemin local du template arm automatiquement généré.

4. Supprimer la vm généralisée temporaire

La machine temporaire n’est plus d’aucune utilité et peut être supprimée.

 

Dans le prochain article nous verrons comment utiliser le vhd généré pour créer notre scaleset.

Si vous avez besoin de transférer le vhd d’un storage à un autre vous pouvez utiliser un outil tel que cloud berry. Ou aller voir cet article expliquant comment effectuer le transfert à l’aide de powershell.

Azure VM Scale Sets : 1 Copie de la VM modèle

Dans cette série d’article nous allons explorer les groupes de machines virtuelles identiques (scaleset) Azure à l’aide de powershell et des template ARM.

Dans ce premier article nous allons :

  • Créer une copie d’une machine virtuelle azure à l’aide de script powershell et de template arm
  • Configurer cette copie pour qu’un script de généralisation se lance automatiquement au démarrage

Rapide rappel sur les Scale Sets azure à partir de la documentation microsoft :

Les groupes identiques de machines virtuelles Azure vous permettent de créer et de gérer un groupe de machines virtuelles identiques et disposant d’une charge équilibrée. Le nombre d’instances de machine virtuelle peut augmenter ou diminuer automatiquement en fonction d’une demande ou d’un calendrier défini.

Nous allons nous baser sur un cas d’utilisation de cette technologie :

  • Le client dispose d’une vm sur azure et souhaite, à partir de celle-ci, créer une collection de machine afin de pouvoir simplement créer ou supprimer des machines de sa collection en fonction de la charge actuelle
  • Le client à deux options :
    • A partir de sa machine créer une image fixe et déployer celle-ci sur son scaleset :
      Pros : l’utilisateur aura une copie conforme de sa machine
      Cons : si l’utilisateur met à jour sa machine modèle il devra écraser chaque machine le scaleset pars sa nouvelle image
    • Créer un scaleset à partir d’une image par défaut. Lors de la création d’une image lancer un script qui installera les composants nécessaires
      Pros : les machines auront toujours la dernière version de Windows, en cas de mis à jour d’un service/application il suffit de propager uniquement cette mise à jour
      Cons : lors de la création d’une machine il est nécessaire de configurer et d’installer les composants nécessaires

Nous allons explorer la première option.

1ère  étape : créer une copie temporaire de la machine modèle

1. Installer le module azure de powershell (si nécessaire)

2. Initialiser les variables

3. Initialiser les accès

4. Récupérer la machine modèle et l’éteindre si nécessaire

5. Copier le vhd de la machine modèle

Le processus de généralisation d’une machine est définitif, une fois celle ci généralisée il n’est plus possible d’utiliser celle-ci. Nous allons donc d’abord créer une copie temporaire de notre modèle que nous utiliserons pour la généralisation, laissant ainsi notre machine modèle intacte. Pour cela nous allons d’abord copier le vhd de la machine modèle dans notre storage.

6. Créer un script de généralisation

Afin qu’une VM puisse être généralisée l’outil sysprep.exe doit être lancé. Pour éviter d’avoir à manuellement se connecter sur la VM pour lancer sysprep.exe nous allons copier le script powershell suivant dans notre storage. Ce script sera lancé automatiquement au démarrage de la VM.

7. Créer une VM temporaire

Remarquez que nous utilisons ici un template ARM json pour instancier notre nouvelle vm, vous pouvez récupérer celui ci directement depuis le portail azure, azure resource explorer, ou le créer vous même à partir de la documentation microsoft.

Deux parties sont importantes dans notre cas :

  • « storage profile » précise que la VM crée se base sur un vhd existant pointant vers l’url de notre copie temporaire
  • « CustomScriptExtension » ajoute une extension qui lancera le script de généralisation au démarrage de notre vm temporaire, notez qu’il est possible de passer des arguments à ce script pour, par exemple, s’assurer de la configuration de votre vm temporaire

Le fichier suivant contient les paramètres par défaut de votre template ARM, il doit être sur la machine lançant le script powershell :

Dans le prochain article nous verrons comment utiliser cette VM pour créer le vhd qui sera utilisé pour le scaleset.

 

Cost Management Service : Suivi et optimisation de votre consommation dans Azure

La nouvelle est passée relativement inaperçue : Microsoft a racheté Cloudyn en juin 2017. Cloudyn propose une solution de reporting sur les consommations Azure, AWS et Google Cloud, mais aussi de faire des recommandations pour optimiser les coûts en fonction de l’usage. Ce service a été intégré au portail Azure sous le terme « Cost Management ».

blog ai3 cloudyn-dashboard Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Ajouter le service Cost Management dans le portail

La création du service dans le portail se fait par la marketplace : recherchez « Cost » ou « Cost Management »:

blog ai3 cloudyn-search-service-1024x304 Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Sélectionner « Cost Management », puis cliquer sur le bouton « Créer ».

A partir d’ici, la procédure varie en fonction de votre situation :

  • le service est déjà activé sur le tenant Azure, mais votre compte n’y a pas accès.
  • le service n’est pas encore activé sur le tenant Azure.

L’écran ci-dessous se présente dans le cas où le service n’est pas encore activé :

blog ai3 cloudyn-setup-1024x717 Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Pour compléter l’enregistrement, il n’y a que quelques étapes à suivre : l’activation du service ne prend que quelques minutes. Par contre, la mise à jour des statistiques peut prendre plusieurs heures en fonction des services Azure que vous utilisez.

Exemples de tableaux de bord

Les captures d’écran ci-dessous vous donnent quelques exemples significatifs des tableaux de bord proposés par « Cost Management ».

blog ai3 cloudyn-dashboard-2 Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Evolution des coûts par service

blog ai3 cloudyn-dashboard-4 Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Répartition des coûts par entité, type d’usage et région

blog ai3 cloudyn-dashboard-1-1024x770 Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Répartition des coûts par service et par région

L’objectif de la solution étant in fine d’optimiser les coûts, Cloudyn a intégré une navigation par drilldown dans les rapports, ce qui permet de réaliser des analyses très précises sur les consommations :

blog ai3 cloudyn-drilldown Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Au delà des axes d’analyse prévus par Cloudyn (Resource types, Services, Cost Types, etc), il est possible de détailler par « tag ». Aussi, je ne peut que vous conseiller de tagger l’ensemble de vos ressources Azure.

Autres features

Des alertes

Il est possible de définir des alertes (par mail) sur certains indicateurs permettant ainsi de mettre en place rapidement d’éventuelles actions correctives.

blog ai3 cloudyn-alerts Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Conseils pour l’optimisation des coûts

En fonction de l’utilisation de vos ressources, Cost Management est en mesure de vous proposer des optimisations : le cas le plus parlant concerne la taille des VM : si une VM est sous utilisée, il vous proposera de changer sa taille.

blog ai3 cloudyn-cost-optimization Cost Management Service : Suivi et optimisation de votre consommation dans Azure

blog ai3 cloudyn-cost-optimization-2 Cost Management Service : Suivi et optimisation de votre consommation dans Azure

Unification

Comme indiqué en introduction, Cloudyn gère AWS, Azure et Google Cloud. Si vous utilisez plusieurs cloud providers, vous pouvez suivre vos consommations au sein d’un outil unique.

Editions et tarifs

Cost Manager existe en 2 éditions :

  • Standard
  • Premium

Ces 2 éditions sont gratuites pour les utilisateurs Azure, et payantes pour les utilisateurs AWS et Google Cloud.

Scanner la totalité des features d’une ferme SharePoint

Un article de Benoît Bernardin

Il y a des cas, comme lors d’une migration SharePoint, ou il est utile d’avoir une vue d’ensemble des features d’une ferme SharePoint.

Je me suis trouvé dans cette situation donc, j’ai sorti le meilleur outil pour m’aider : PowerShell. Et, j’ai écrit un script qui itère les features d’une ferme SP en couvrant la totalité des scopes (Farm, Web App, Site et Web) puis, enregistre le résultat dans des fichiers CSVs. L’avantage des CSVs est qu’on peut facilement les exploiter (par exemple: les ouvrir dans Excel et faire des tableaux croisés-dynamiques).

Dans mon cas j’ai décidé de faire plusieurs fichiers car avec plus de 50 Web Apps dans la ferme cible, la quantité de données devenait importante, mais, les fichiers ayant volontairement un schéma similaire, il est facile de les agréger si besoin.

blog ai3 scanspfeatures-300x164 Scanner la totalité des features d’une ferme SharePoint

Le script fonctionne sur SharePoint 2010 et SharePoint 2013. Je pense que c’est un outil à garder dans sa boite à malice SharePoint.

Le script est disponible en téléchargement ici

Avis aux amateurs. ?

Exchange 2016 Series – Certificat SSL

Bonjour tous le monde ! Dans ce nouvel article, je vous propose d’aborder le sujet sensible qu’est le choix des certificats SSL et des bonnes pratiques à suivre lors d’un déploiement Exchange 2016.

Exchange 2016 communique avec les clients, applications et les autres serveurs sur une variété de protocoles réseau tels que http, SMTP, IMAP et POP. La plupart de ces communications, particulièrement les clients et applications, impliquent une authentification basée sur l’identification par nom d’utilisateur et mot de passe. Lorsque les informations d’identification sont envoyées sur le réseau, elles sont envoyées « en clair », signifiant que ces informations peuvent potentiellement être interceptées et lues par une personne malintentionnée. D’autres informations transmises durant la session peuvent être également sensibles et enclin à être utilisées si l’interception est possible.

Pour sécuriser ces communications Exchange 2016 utilise les certificats SSL pour crypter le trafic réseau entre le serveur, les clients et les applications. Ceci inclus :

  • Outlook se connectant via Outlook Anywhere (RPC-over-HTTP) ou MAPI-over-HTTP
  • Les navigateurs Web se connectant à Outlook sur le Web (OWA)
  • Les appareils mobiles se connectant via ActiveSync pour accéder aux boîtes aux lettres et calendriers.
  • Les applications se connectant aux services Web Exchange (EWS) pour consulter les disponibilités et autres
  • Les clients de messagerie se connectant en POP ou IMAP
  • Le trafic SMTP cryptés en TLS entre les serveurs Exchange et les autres serveurs de messagerie

Lors de la première installation d’Exchange 2016, il génère un certificat SSL auto-signé qui est alors activé pour IIS (les services HTTPS comme OWA, EWS et ActiveSync), SMTP, POP et IMAP. Le certificat auto-signé permet au serveur d’être « sécurisé par défaut » et de commencer à crypter les communications réseau de suite après son démarrage, mais il est seulement censé être utilisé temporairement jusqu’à que vous provisionniez les certificats SSL pour votre environnement.

Lors du déploiement d’Exchange 2016 vous devez planifier de remplacer le certificat auto-signé par un certificat SSL valide pour votre scénario de déploiement. Ceci implique un investissement allant d’une centaine de dollars (ou €) à plusieurs milliers de dollars (ou €) dépendant de votre scénario d’espace de noms d’accès client, le type de certificat que vous achetez, et le type de d’autorité de certification auquel vous vous adressez.

Il fortement recommandé de ne pas conserver le certificat auto-signé ou de désactiver SSL pour les services Exchange.

Certificat SSL – Prérequis

Il y a trois prérequis basiques pour un certificat SSL dans un déploiement Exchange 2016.

  • Noms de serveur/domaine correct – le certificat SSL doit contenir les espaces de noms (aka, URLs, alias, noms de domaines) correspondant au nom auquel les clients tentent de se connecter (par exemple, les utilisateurs tapant « webmail.contoso.com » dans leur navigateur web pour pouvoir accéder à Outlook web app)
  • Période de validité du certificat – chaque certificat SSL a une période de temps fixée durant laquelle il est considéré comme valide. Lorsque le certificat SSL atteint sa date d’expiration il devra être renouvelé pour continuer à fonctionner.
  • Une autorité de certification de confiance – les clients feront uniquement confiance aux certificats qui sont issues d’une autorité de certification de confiance. C’est une des raisons pour laquelle le certificat auto-signé ne correspond généralement pour une utilisation en production, parce que vos clients ne feront pas confiance au certificat publié par votre serveur Exchange. Il existe un large panel d’autorités de certification publiques auprès desquelles vous pouvez acquérir des certificats.

Choisir une autorité de certification est assez simple, et la période de validité sera déterminé par la durée pour laquelle vous achetez le certificat (en général minimum 12 mois). Cela signifie que le point de décision pour la planification de vos certificats SSL se reposera sur le choix de vos espaces de noms.

Espace de noms pour les certificats SSL

L’approche la plus simple pour les espaces de noms Exchange 2016 Server est d’utiliser un seul espace de noms pour tous les services HTTPS.

En plus de l’espace de noms HTTPS, il est courant d’utiliser un espace de noms séparé pour chacun des services SMTP, POP et IMAP, bien qu’il ne soit pas nécessaire de le faire. Il y a également le CNAME de l’Autodiscover à considérer et le domaine racine également.

Par exemple, dans un environnement simple où le nom de domaine utilisé pour les adresses de messagerie est contoso.com, et en prenant en compte toutes les considérations citées précédemment, les espaces de noms pourraient être planifiées comme :

  • Webmail.contoso.com (pour HTTPS, SMTP, POP et IMAP)
  • Autodiscover.contoso.com (pour le CNAME de l’Autodiscover)
  • Contoso.com (pour le domaine racine des recherches autodiscover)

La pratique recommandée est d’inclure uniquement les alias en tant qu’espace de noms sur les certificats SSL et pas le FQDN des serveurs.

Note : Concernant la présence du ou des FQDNs des serveurs dans les certificat SSL, il est clair que cela est supporté mais ce n’est cependant pas une bonne pratique car dans les grands environnements il est important de réduire les coûts et les frais généraux administratifs. De plus, dans les grands environnements les services sont configurés avec des espaces de noms qui résolvent des adresses IP Virtuelles (Load Balancing) et utiliser un nom de serveur dans les URLs peut amener à vous causer des problèmes lors de future migration.

En raison des récents changements apportés aux règles d’émission de certificat, vous pouvez également vous trouver dans l’impossibilité de demander un certificat SSL pour un nom de domaine qui n’est pas routable sur Internet ou que vous ne possédez pas légitimement (par exemple, domain.local).

Quel type de certificat acquérir ?

Les autorités de certification tels que Digicert peuvent vous vendre une variété de types de certificat, et certaines autorités de certification différents noms pour ce qui est sensiblement la même chose.

  • Le certificat SSL standard contient un seul nom et est généralement le moins cher à acquérir, cependant ils ne sont pas adaptés même avec une conception d’espace de noms la plus simple.
  • Le certificat SSL Wildcard vous permet de sécuriser de multiple noms sur un domaine sans avoir à spécifier les noms exacts dans le certificat. Bien que qu’ils soient souvent une option à moindre coût, les certificats Wildcard peuvent poser des problèmes de compatibilité avec certains scénarios d’intégration avec d’autres systèmes, ainsi que de ne pas être adapté aux configurations POP et IMAP sécurisées.
  • Le certificat SAN ou UC (Unified Communications) est le type de certificat recommandé. Le certificat SAN peut contenir de multiple noms. Par exemple, un certificat UC peut inclure jusqu’à 4 noms à un prix normal, avec en option la possibilité d’ajouter jusqu’à un total de 25 noms avec un coût supplémentaire. Bien que le coût d’un certificat SAN/UC soit plus important qu’un certificat Wildcard, vous rencontrerez moins de problème de compatibilité avec le certificat SAN/UC, aussi longtemps que le certificat contienne les bons noms. Si toutefois lors de votre planification d’espace de noms vous faite une erreur ou, vous rencontrez le besoin de modifier l’espace de noms, la plupart des fournisseurs vous permettrons de republier le certificat gratuitement. Pour certain cette opération à un coût J.

La pratique recommandé est de provisionner le moins de certificat SSL possible et ce, pour simplifier l’administration ainsi que de réduire le plus possible les coûts à l’achat. Donc bien qu’il soit possible d’avoir des certificats pour chacun des services (http, SMTP, POP et IMAP), il est recommandé d’utiliser qu’un seul certificat contenant tous les noms à moins que vous ne soyez dans un scénario bien spécifique. De même qu’il est recommandé d’utiliser le même certificat pour tous les serveurs Exchange qui seront configuré avec le même espace de noms.

C’est ainsi que se termine cet article. J’espère que les informations fournies tout au long de ce post pourront vous être utiles lors de vos prochains déploiement d’Exchange 2016 !

La gestion des licences Office 365 par PowerShell

Bonjour à tous,

Dans cet article, nous allons évoquer la gestion des licences par Powershell. En effet, la première porte pour accéder aux applications Office 365 est de fournir à vos utilisateurs une licence et de configurer les options disponibles sur celle-ci. Cette partie est par conséquent très importante dans l’administration de votre tenant.

Les licences disponibles pour votre tenant sont visibles via le portail d’administration, menu Facturation puis Licences :

blog ai3 File01-1024x599 La gestion des licences Office 365 par PowerShell

 

La colonne Valide(s) nous indique le nombre total de licences disponibles et la colonne Affectée(s) le nombre de licences utilisées.

Voyons voir cette scène au ralenti et trouvons maintenant ces informations via « Coquillage Puissant » :

blog ai3 File02-300x67 La gestion des licences Office 365 par PowerShell

 

La commande Get-MsolAccountSku nous permet de visualiser nos différentes licences.

Si nous mettons cette information dans une variable ($Sku = Get-MsolAccountSku), celle-ci sera un tableau avec autant de lignes que de licences.

Nous pouvons aisément réaliser un script pour extraire de manière quotidienne le statut des licences :

blog ai3 File03-1024x272 La gestion des licences Office 365 par PowerShell

 

Maintenant que nous avons nos licences, il est temps de voir les applications liées à celles-ci.

En effet, ces licences contiennent un ensemble d’applications comme le montre la capture suivante par le GUI :

blog ai3 File04 La gestion des licences Office 365 par PowerShell

Les mêmes données en Powershell :

blog ai3 File05 La gestion des licences Office 365 par PowerShell

Cette commande nous permet de visualiser les différents éléments d’une licence ainsi que leur statut.

Le  statut « PendingActivation » sur le composant « INTUNE_O365 » indique que l’application doit être dans un premier temps activée pour cet utilisateur par un Administrateur.

Maintenant rentrons dans le vif du sujet afin d’affecter des licences en masse … (Jeanne si tu nous écoutes 😉 )

Tout d’abord, avant d’affecter une licence à un utilisateur, il est impératif de définir l’emplacement auquel il appartient. Cela se passe via la cmdlet set-msoluser :

 blog ai3 File06-1024x74 La gestion des licences Office 365 par PowerShell

blog ai3 File07-1024x86 La gestion des licences Office 365 par PowerShell

« FR » pour France, « GB » pour United Kingdom, « DE » pour Allemagne, …

Une fois l’emplacement défini, affectons maintenant une licence via la cmdlet suivante set-msoluserlicense.

Dans l’exemple ci-dessous, nous attribuons une licence complète (avec toutes ces applications) à notre utilisateur :

blog ai3 File08-1024x267 La gestion des licences Office 365 par PowerShell

Pour désactiver certaines options d’une licence, il est nécessaire de définir en amont une variable qui contiendra les éléments à ne pas inclure.

Cette variable sera ensuite utilisée en paramètre (« -LicenseOptions » ) de la cmdlet set-msoluserlicense :

blog ai3 File09-1024x313 La gestion des licences Office 365 par PowerShell

Et hop, voici le résultat :

blog ai3 File10-1024x290 La gestion des licences Office 365 par PowerShell

Ou par le GUI :

blog ai3 File11 La gestion des licences Office 365 par PowerShell

 

Cool, non ? Avec ces différentes cmdlet, nous pouvons activer en masse ou alors modifier les options des différentes licences !

Maintenant, si nous souhaitons lister et exporter tous les utilisateurs et leurs licences associées, voici une fonction et sa cmdlet que nous pouvons utiliser :

Function LicenceAll ($UPN) {Get-MsolUser -UserPrincipalName $UPN | Select Licenses | % {$_.Licenses | % {$SkuPartNumber = $_.AccountSku.SkuPartNumber;$_.ServiceStatus | Select @{N=’UPN’;E={$UPN}},@{N=’LicenseType’;E={$SkuPartNumber}},@{N=’ServicePlan’;E={$_.ServicePlan.ServiceName}}, ProvisioningStatus}}}

Get-MsolUser -All | ? {$_.IsLicensed -eq « TRUE »}| % {LicenceAll $_.UserPrincipalName} | Export-Csv c:\temp\ToutesLesLicences.csv -Encoding Unicode -NoTypeInformation -Delimiter « ; »

blog ai3 File12-1024x95 La gestion des licences Office 365 par PowerShell

 

L’extraction au format csv nous donnera sous Excel les valeurs suivantes :

blog ai3 File13 La gestion des licences Office 365 par PowerShell

En attendant un prochain article, Que la force soit avec vous 😉

James MAILLET

AI3