Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles Ă  la une

Powershell & Office 365 : Provisionning de licences

Introduction

Dans Office 365, il existe plusieurs méthodes pour ajouter des licences à un utilisateur :

  • Via l’interface d’administration manuellement sur chaque utilisateur.
  • Via l’interface d’administration manuellement sur plusieurs utilisateurs.
  • Avec les cmdlets Powershell Office 365.

Dans cet article, nous allons nous intĂ©resser Ă  l’ajout/suppression de licences via Powershell. Le but est d’automatiser cette opĂ©ration. On peut facilement imaginer des scĂ©narios conjoints avec Dirsync. Ce dernier provisionne un compte, puis, une tâche ajoute automatiquement les licences nĂ©cessaires Ă  l’utilisateur.

D’autre part, il est possible d’ajouter pour chaque utilisateur :

  • Une licence complète incluant tout les services de l’abonnement souscrit.
  • Certains services d’une licence afin de limiter les accès aux utilisateurs (par exemple : ne donner qu’une licence Exchange sans donner les accès Ă  la suite Office).

    Nous nous attarderons sur ces diffĂ©rentes possibilitĂ©s dans l’un des paragraphes suivants.

    Nous ferons un rappel sur les prĂ©requis nĂ©cessaires Ă  l’utilisation des cmdlets Powershell avant d’apprĂ©hender leur attribution. Nous verrons enfin un script permettant d’automatiser le processus d’ajout/suppression de services via l’utilisation des groupes de sĂ©curitĂ© Office 365.

Pré requis

L’administration des utilisateurs Office 365 via Powershell a besoin de l’installation d’un module spĂ©cifique. Ce dernier nĂ©cessite un prĂ©requis : Microsoft Online Services Sign-In Assistant. Ci dessous, vous trouverez le lien de tĂ©lĂ©chargement de ce dernier :

http://www.microsoft.com/en-us/download/details.aspx?id=41950

Voici maintenant les liens pour récupérer le module Powershell :

http://go.microsoft.com/fwlink/p/?linkid=236298

A titre informatif, la version 32 bits de ces composants n’est plus pris en charge et ne sera plus mis Ă  jour par Microsoft.

 

Connexion Ă  Office 365 et permission

Pour se connecter Ă  Office 365, il est nĂ©cessaire d’exĂ©cuter la commande suivante :

Les informations d’authentification fourni doivent correspondre Ă  un utilisateur possĂ©dant Ă  minima le rĂ´le de gestion des utilisateurs. Cette attribution permettra d’affecter les licences.

 

Licences et abonnements

Tout d’abord, nous allons commencer par rĂ©cupĂ©rer les diffĂ©rents abonnements disponibles sur un tenant Office 365. Il s’agit de la commande :

Le résultat obtenu permet aussi de voir les licences disponibles (ActiveUnits) et utilisées. (ConsumedUnits)

Get-MsolAccountSku

Pour chacun des abonnements, il est possible d’accĂ©der aux services disponibles. Exemple avec le premier abonnement de la liste :

ServiceStatus

Chaque service Office 365 possède donc un identifiant qui est utilise lors de l’affectation de licences Ă  certains utilisateurs. Les services Ă©tant diffĂ©rents d’un plan Ă  un autre, voici un tableau rĂ©capitulant les identifiants et les services auxquels ils donnent accès pour un abonnement de type E3 :

EXCHANGE_S_STANDARD Exchange Online (Plan 2)
MCOSTANDARD Lync Online (Plan 2)
SHAREPOINTENTERPRISE SharePoint Online (Plan 2)
SHAREPOINTWAC Office Online
OFFICESUBSCRIPTION Office ProPlus
RMS_S_ENTERPRISE Azure Active Directory Rights Management
INTUNE_O365 Intune
YAMMER_ENTERPRISE Yammer
 

Pour les autres abonnements, les services ont des noms identiques ou similaires (exemple : SHAREPOINT_S_DEVELOPER au lieu de SHAREPOINTENTERPRISE pour un abonnement développeur).

NB : J’ai notĂ© deux spĂ©cificitĂ©s sur certains services. Premièrement, la licence Office Online doit ĂŞtre attribuĂ© conjointement Ă  une licence Sharepoint (on peut facilement s’en rendre compte via le portail d’administration Office 365). Enfin, les licences Yammer n’ont pas besoin d’ĂŞtre attribuĂ©s. Cela est sans doute dĂ» au fait que l’intĂ©gration du service dans l’offre Office 365 n’est pas terminĂ©e. Il se peut aussi que cela soit pensĂ© pour simplifier le système. NĂ©anmoins, il apparaĂ®t que le nombre d’utilisateurs peut dĂ©passer le nombre de licences sans avoir de rĂ©duction de services (Il faut donc faire un suivi rĂ©gulier du nombre de licences afin d’ĂŞtre en règle).

 

Gestion des licences utilisateurs

Attribution d’une licence complète

L’attribution d’une licence utilisateur se fait via la commande Powershell "Set-MSOLUserLicence". Il est possible d’utiliser cette commande pour un ou plusieurs utilisateurs. Le paramètre AddLicenses permet d’ajouter une licence correspondant Ă  un plan Office 365.

Exemple d’attribution d’une licence :

NB : Il est nĂ©cessaire de fournir l’attribut AccountSkuId de l’objet obtenu avec la commande Get-MsolAccountSku.

NB2 : Si vous attribuez des licences Ă  plusieurs utilisateurs et que le nombre restants est insuffisant, alors la cmdlet affectera quand mĂŞme des licences jusqu’Ă  Ă©puisement de celles-ci.

Attention, avant d’attribuer une licence, il est nĂ©cessaire d’ajouter une localisation Ă  l’utilisateur. Cette opĂ©ration est automatisable avec la commande suviante :

La location est Ă  remplacer par la valeur voulue (ici : FR).

 

Attribution d’une licence partielle

Pour l’instant nous avons vu, l’attribution d’une licence donnant accès Ă  tous les services offert par l’abonnement Office 365. Dans certains cas, il peut ĂŞtre voulu de n’autoriser un utilisateur qu’Ă  un certain nombre de services. Pour se faire, il faut crĂ©er un objet du type MsolLicenceOption. Celui-ci est une licence Ă  laquelle on a dĂ©sactivĂ© certains services.

Exemple :

Cette cmdlet crée une licence avec un pack de service désactivant Azure Right Management Services et Lync Online.

La commande crĂ©e les options de licencing Ă  partir d’un abonnement (AccountSkuId) et une liste de services sous forme de tableau. Les noms des services Ă  fournir sont ceux dĂ©finis dans le tableau du paragraphe "Licences et abonnements". On peut ensuite attribuer ces options de licencing via la mĂŞme commande que prĂ©cĂ©demment mais en changeant de paramètre :

Script

Présentation

Le but du script ci-dessous est d’effectuer un provisioning automatique des licences Office 365 pour les utilisateurs synchronisĂ©s avec Dirsync. Celui-ci est basĂ© sur l’utilisation des groupes de sĂ©curitĂ© Office 365 (ce dernier peut ĂŞtre synchronisĂ© via Dirsync). Chaque groupe correspond Ă  l’attribution d’un ou plusieurs accès Ă  des services Office 365.Ce script peut aussi bien gĂ©rer l’ajout que la suppression d’accès. Afin de ne pas perturber les accès dĂ©jĂ  affectĂ©s Ă  un utilisateur sont rĂ©attribuĂ©s (tant qu’ils ne sont pas concernĂ© par le script). Afin de mieux comprendre le comportement du script, voici un scĂ©nario d’exemple :

  • USER1 appartient au groupe GRP-SharepointOnline
  • GRP-SharepointOnline attribue les accès SHAREPOINTENTERPRISE et SHAREPOINTWAC
  • USER1 possède dĂ©jĂ  un accès Ă  Lync (via MCOSTANDARD)
  • Le script s’exĂ©cute et donne les accès Ă  SHAREPOINT Online et Office Online Ă  USER1
  • USER1 conserve Ă©galement son accès Ă  Lync Online.

Pour obtenir ce rĂ©sultat, l’algorithme recalcule les accès de chaque utilisateur. Cette opĂ©ration est rĂ©alisĂ© en rĂ©cupĂ©rant l’attribut DisabledServices de la licence utilisateur (avec Get-MsolUserLicense).

Il permet aussi de ne pas gĂ©rer certains services. Cela peut ĂŞtre notamment utile pour Yammer dont l’attribution de licence n’est pas Ă  administrer.

Celui-ci a Ă©tĂ© utilisĂ© au travers d’un runbook dans System Center Orchestrator mais il peut aussi ĂŞtre utilisĂ© dans une tâche planifiĂ©. Il est possible d’imaginer des variantes de ce script. Par exemple, les licences Ă  attribuer pourraient ĂŞtre stockĂ©e dans un attribut du groupe. On peut aussi supprimer l’exigence d’ĂŞtre un utilisateur synchronisĂ© par Dirsync (dans ce cas le groupe devra ĂŞtre alimentĂ© via la console Office 365 et non dans Active Directory).

 

Script

Office 365 – Résoudre l’erreur de migration “Cannot find a recipient that has mailbox GUID”

Contexte

Dans un environnement Exchange 2013 en mode hybride, vous obtenez l’erreur suivante lors de la migration d’une boite aux lettres Exchange Online vers Exchange OnPremise :

Error: MigrationPermanentException: Cannot find a recipient that as mailbox GUID <GUID>.

2015-09-08_181420

Cette erreur est due à l’absence du GUID sur la RemoteMailbox de l’utilisateur côté Exchange OnPremise.

Si vous lancez la commande suivante sur l’Exchange Management Shell, vous obtiendrez un GUID nul :

Get-RemoteMailbox <SamAccountName> | fl *ExchangeGUID*

2015-09-08_181240

Résolution

Afin de résoudre l’erreur et pouvoir procéder à la migration de la boite, vous devez modifier le GUID de la RemoteMailbox pour le faire correspondre à celui de la boite côté Exchange Online.

Vous pouvez récupérer le GUID de la boite depuis le message d’erreur ou depuis une console PowerShell connectée à ExchangeOnline avec la commande

Get-Mailbox <SamAccountName> | fl *ExchangeGUID*

2015-09-08_181501

Ensuite depuis l’Exchange Management Shell, lancez la commande suivante :

Set-Mailbox <SamAccountName> –ExchangeGUID <GUID>

2015-09-08_181532

Relancez votre migration.

2015-09-09_100059

Skype for Business 2015 – Publier les services web via WAP

Contexte

Lors de l’installation de Skype for Business 2015, un certain nombre de flux web doivent être publiés vers l’extérieur. Avec l’arrêt de TMG, il est recommandé (voir nécessaire) d’utiliser un autre Reverse Proxy pour publier ces flux.

Depuis Windows Server 2012 R2, Microsoft a intégré un nouveau rôle, le WAP pour Web Application Proxy. Ce rôle permet la publication de flux web. Il peut donc être utilisé dans une architecture Skype for Business 2015. Pour en savoir plus sur l’installation du rôle WAP, vous pouvez suivre le lien suivant : https://technet.microsoft.com/fr-fr/library/Dn280944.aspx.

Mise en œuvre

Prérequis

La publication des services web via WAP ne nécessite pas de prérequis particulier à l’exception du certificat public contenant l’ensemble des URLs.

 

 

Services Web

Skype for Business 2015 intègre plusieurs services web :

  • Meet
  • Dial-In
  • Scheduler
  • Autodiscover
  • Services Web
  • Office Web Apps

Publication

      Depuis la console

Remote Access Management Console

      , cliquez sur

Publish.

2015-09-09_141606

Passez la première étape, puis sélectionnez Pass-through dans la méthode de pré-authentification.

2015-09-09_141728

Indiquez le nom du service web, l’URL de publication dans External URL, sélectionnez le certificat public correspondant et indiquez l’URL interne dans Backend server URL.

2015-09-09_141913

La page suivante récapitule la publication. Cliquez sur Publish pour terminer la publication.

2015-09-09_141957

Recommencez l’opération pour toutes les URLs.