Contexte

Dans Office 365 lorsque vous activez une fonctionnalité qui déclenche un mail automatique (exemple : activation de l’UM, activation du PSTN calling…) le mail est rédigé dans la langue du tenant et non dans celle de l’utilisateur.

Explications et solution

Par défaut l’ensemble des mails envoyés automatiquement utilise la langue sélectionnée lors de la création du tenant. Donc si votre tenant a été créé en Français l’ensemble des mails sont envoyé en Français.

Pour changer la langue, en anglais par exemple, il faut que l’utilisateur possède l’attribut PreferredLanguage de renseigné sur son compte Active Directory. Pour l’anglais il est possible de mettre “EN-US” ou “EN-GB”.

La liste des code possibles est disponible au lien suivant https://technet.microsoft.com/en-us/library/ee825488.aspx.

Une fois la valeur modifiée (et après avoir effectué une synchronisation AzureADConnect) le mail envoyé est en anglais !

Script de modification de l’attribut PreferredLanguage dans l’AD

Si vous souhaitez modifier en masse l'ensemble des utilisateurs vous pouvez utiliser le script PowerShell ci-dessous.

$users = Get-ADUser -Filter * -SearchBase "DC=MONDOMAINE,DC=COM" -SearchScope Subtree
$actual=1
$total = $users.count
foreach($user in $users)
{ 
   $sam = $user.SamAccountName
   Write-Progress -Id 1 -Activity ("Working...Please wait") -PercentComplete ($actual / $total * 100) -Status ("Working on {0} - {1} / {2}" -f $sam, $actual, $total)
   Set-ADUser $sam -add @{PreferredLanguage="EN-GB"}
   $actual++
}

Description

Le pack de contenu Office 365 Adoption dans Power BI permet d’obtenir des informations sur la façon dont votre organisation a adopté les différents services au sein de Office 365 pour communiquer et collaborer. Vous pouvez visualiser et analyser les données d’utilisation Office 365, créer des rapports personnalisés et les partager au sein de votre organisation.

Configuration

Pour profiter de cette nouvelle fonctionnalité il faut utiliser votre compte d’administration Office 365 et se rendre à l’adresse suivante : https://app.powerbi.com

Une fois dessus créer un compte en rentrant votre compte :

Une fois sur votre espace de travail cliquez sur « obtenir des données » depuis le volet de navigation

Cliquez sur « Obtenir » au niveau de la tuile Services

Vous pouvez maintenant choisir et installer l’application dont vous avez besoin. Par exemple vous pouvez installer l’application « Azure Active Directory Activity Logs » qui vas vous permettre d’avoir plusieurs statistiques sur votre infrastructure :

Le prérequis pour cette application est de rentrer le nom de domaine suivi de la procédure d’authentification.

Voici un autre exemple avec l’application « Office 365 Adoption Preview » :

Le prérequis pour cette application est de rentrer le nom de tenant suivi de la procédure d’authentification.

Information

Pour plus d’information concernant la configuration, je vous invite à consulter les liens suivants :

• Pack contenu adoption Office 365
• Enable the Power BI Adoption content pack for Office 365 

1. Se rendre sur l'interface d'administration de SharePoint Online

Sélectionner : Nouveau > Collection de sites privée

2. Renseigner les champs suivants

1. titre
2. addresse du site web
3. la langue
4. le modèle (choisir personalisé)
5. le fuseau horaire
6. l'administrateur du site
7. le quota

3. Patienter pendant la création du site

4. Application du template de site

Se rendre sur le site qui a été créé et cliquer sur "Galerie solutions" pour charger le template personalisé.

Sélectionner "Télécharger la solution"

Sélectionner le fichier template à injecter puis valider par OK

Activer le module et patienter pendant le chargement du template. 

FIN.

Problème:

Impossible de requêter les membres d'un groupe dynamique Exchange ayant un paramètre de filtrage sur le champ "CountryOrRegion".

L'erreur spécifiée est générique et indique que le filtre OPATH ou LDAP est invalide:

"La chaîne de filtre de prévisualisation du destinataire $VotreFiltre n'est ni un filtre OPath valide ni un filtre LDAP valide. Utilisez le paramètre -RecipientPreviewFilter avec une chaîne de filtre OPath valide ou une chaîne de filtre LDAP valide."

Cause:

Une des raisons possible à ce message d'erreur est que la valeur du champ CountryOrRegion ait été déclarée depuis une console Powershell en français (ou toute langue autre que l'anglais). En effet la console powershell interprète et traduit directement la valeur spécifiée pour l'attribut CountryOrRegion.

Par exemple, si vous spécifiez la valeur "CountryOrRegion -eq Germany" ou "CountryOrRegion -eq DE" et que votre console powershell est en français, la valeur retenue et transmise dans le filtre OPATH sera "CountryOrRegion -eq Allemagne".

Ceci est problématique car les serveurs Exchange installés en anglais seront incapables de traduire cette valeur et vous ne pourrez pas interagir avec cette liste de distribution dynamique pour la partie modification et récupération des membres, la liste en elle-même devrait normalement être fonctionnelle. 

Autre raison possible, la valeur n'est pas renseignée correctement.

Les valeurs doivent correspondre à la norme ISO 3166-1 de l'appellation des pays.

https://fr.wikipedia.org/wiki/ISO_3166-1

Solution:

Actuellement, ce problème est considéré comme un fonctionnement standard du produit, pour corriger les listes de distributions dynamiques en erreur, il vous faudra les recréer depuis une console en anglais.

Dans un environnement hybride, avec des utilisateurs synchronisés depuis l'Active Directory vers O365, il n'est actuellement pas possible de changer l'UPN directement par le portail d'administration O365.

Cependant avec les commandes Powershell suivante, il est possible de modifier l'UPN directement dans O365:

Il faut passer par l'adresse technique pour changer l'UPN de l'utilisateur d'un domaine à un autre, il faut cependant que l'UPN final soit égal à la valeur présente dans l'Active Directory Onpremise.

Introduction

Cette fonctionnalité disponible aussi dans Azure appelé authentification forte ou double authentification permet de renforcer la sécurité d’accès aux ressources web.

L’activation est accessible par le centre d’administration office sur l’onglet utilisateurs actifs, le lien « gérer l’authentification multi-facteur » se trouve en bas de page après sélection de l’utilisateur.

Mise en place

Dans la liste des utilisateurs sélectionner un ou plusieurs utilisateurs et cliquer sur le bouton activer.

De la même façon sélectionner désactiver pour un utilisateur ayant déjà la fonctionnalité activée.

Le lien “gérer les paramètres” concerne la gestion au niveau de la méthode de contact, des mots de passe d’application ou pour réinitialiser la MFA sur les mobiles reliés.

Une fois activé, lors de la première connexion au portail Office l’utilisateur entre son identifiant et mot de passe habituel (1ère authentification). Un message avertit de la mise en place d’une procédure supplémentaire de sécurité.

La configuration commence et il faut choisir entre 3 méthodes de contact. Nous allons les tester les 3 et garder notre préférée. 

Méthode de contact 1 : L’appel.

L’appel téléphonique (Microsoft US) vers un mobile ou bureau: un message audio vous demande d’utiliser la touche # pour confirmer la demande d’accès.

La configuration est terminée (étape 3). Vous recevez un code précieux valable sur vos applications client lourd comme Outlook MailOs Skype etc. à utiliser en lieu et place du mot de passe habituel.

Je vais donc l’utiliser pour configurer Outlook. Et pour Skype, il suffit de se déconnecter et se reconnecter avec le nouveau mot de passe de 16 caractères.

Vous pouvez changer d’avis et vouloir utiliser la méthode par SMS ou application mobile !

Il faudra passer par une réinitialisation de la méthode de contact ou ponctuellement utiliser le lien autre option de contact.

Méthode de contact 2 : Validation par SMS

Tout ce passe à l’étape 1.

Un code numérique à 6 caractères vous parvient et doit-être reporté dans le champs de vérification pour validation.

Notez aussi la possibilité d’espacer la 2ème vérification tous les 30 jours.

Méthode de contact 3: Validation par application mobile.

A l’étape 1, vous choisissez application mobile puis cliquez sur le bouton configurer.

Vous aurez besoin de l’application Azure Authenticator et de l’application Barcode Scanner pour lire le QR Code.

Soit vous ajouter manuellement un compte dans l’application mobile Authenticator en saisissant le code de 9 caractères puis l’URL complet, ou en sélectionnant analyser le QR Code.

L’application mobile génère un code numérique à 6 caractères qui doit-être reporté dans le champs de vérification avant la fin du temps imparti pour valider l’accès.

L’application mobile peut aussi générer un message pop-up “Approuver” ou “Refuser”.

C’est la méthode que je préfère, pas de code à reporter juste un clic sur Approuver !

Attention !

Le signalement provoque l’inaccessibilité au compte dans l’immédiat et peut-être le “bannissement” du mobile utilisé (à confirmer).

Car pour le moment impossible de configurer à nouveau la MFA sur le mobile pour cet utilisateur. Même après une réinitialisation des paramètres ou la désactivation-réactivation de la fonctionnalité, cet utilisateur devra se passer de MFA pour de nouveau avoir accès au ressources! Ou changer de mobile?! ou de numéro de téléphone.

Bonjour, nous allons voir les bases pour gérer ses licences O365 en powerShell

Connexion au tenant O365

Nous allons enregistrer les informations de connexion

$cred = Get-Credential

Puis nous allons nous connecter au tenant lié au informations de connexion enregistré précédemment.

Connect-MsolService -Credential $cred

Récupération des offres

Si vous n’avez pas d’erreur vous êtes connecté a votre tenant.

Nous allons récupérer les infos sur nos offres

Get-MsolAccountSku | Format-Table AccountSkuId

Nous allons ensuite listé les produits disponible dans l’offre que nous allons assigner.

$ServicePlans = Get-MsolAccountSku | Where {$_.SkuPartNumber -eq “ENTERPRISEPREMIUM_NOPSTNCONF”}
$ServicePlans.ServiceStatus

Voici les correspondances produits des valeurs de servicePlan pour un abonnement E5.

Création d’une offre personnalisée

En nous basant sur les valeurs servicesPlan, nous allons créer notre option de licence.

$MyO365Sku = New-MsolLicenseOptions -AccountSkuId piservices:ENTERPRISEPREMIUM_NOPSTNCONF -DisabledPlans LOCKBOX_ENTERPRISE,EXCHANGE_ANALYTICS,ATP_ENTERPRISE,MCOEV,INTUNE_O365,MCOSTANDARD,EXCHANGE_S_ENTERPRISE

Le paramètre –DisabledPlans permet des choisir les éléments que l’on souhaite désactiver dans l’offre.

Attribution de la licence

Pour des raison légal il faut spécifier le pays où a licence sera utilisé.

Set-MsolUser -UserPrincipalName adrien.gougeon@piservices.fr -UsageLocation FR

Enfin nous n’avons plus qu’a associer notre licence avec nos options.
Set-MsolUserLicense -UserPrincipalName adrien.gougeon@piservices.fr -AddLicenses piservices:ENTERPRISEPREMIUM_NOPSTNCONF -LicenseOptions $MyO365Sku

version script

Voici en bonus les commandes dans un script simple et fonctionnel.

$cred = Get-Credential
Connect-MsolService -Credential $cred

$MyO365Sku = New-MsolLicenseOptions -AccountSkuId piservices:ENTERPRISEPREMIUM_NOPSTNCONF -DisabledPlans LOCKBOX_ENTERPRISE,EXCHANGE_ANALYTICS,ATP_ENTERPRISE,MCOEV,INTUNE_O365,MCOSTANDARD,EXCHANGE_S_ENTERPRISE

$users=Get-MsolUser -Synchronized -UnlicensedUsersOnly | where {$_.UserPrincipalName -notlike 'adm_*' -and $_.UserPrincipalName -like '*@piservices.fr'} | select -Property UserPrincipalName

Foreach ($user in $users) {

    Set-MsolUser -UserPrincipalName $user.UserPrincipalName -UsageLocation FR

    Set-MsolUserLicense -UserPrincipalName $user.UserPrincipalName -AddLicenses piservices:ENTERPRISEPREMIUM_NOPSTNCONF -LicenseOptions $MyO365Sku

}

Nous avons la commande :

Get-MsolUser -Synchronized -UnlicensedUsersOnly | where {$_.UserPrincipalName -notlike 'adm_*' -and $_.UserPrincipalName -like '*@piservices.fr'} | select -Property UserPrincipalName

Cette commande permet d’obtenir les utilisateurs qui sont synchronisés et sans licence. le résultat est ensuite filtré pour enlever les comptes admins et cibler le domaine que nous voulons manipuler et enfin nous ne prenons que le champ UserPrincipalName car c’est le seul qui nous sert pour le script.

Bonus

Voici en bonus des commandes utiles pour améliorer vos scripts.

Pour sélectionner toutes les entrée d’une OU sans les sous-OU et mettre une valeur dans extensionAttribute15.

Get-ADUser -Filter * -SearchBase "VOTRE OU" -SearchScope 1 -Properties extensionAttribute15 | Set-ADUser –Add @{extensionAttribute15="AzureAdSync"}

Cette commande peut vous être utile si vous faites de la synchro d’AD on-premise avec azure AD connect

Introduction

Azure AD Connect est devenu, depuis quelques mois, le nouvel outil de synchronisation d'identité entre une infrastrcture Active Directory On-Premise et Azure Active Directory. Ce dernier doit remplacé les outils existants (Dirsync et Azure AD Sync) en consolidant les fonctionnalités de chacun de ceux-ci. Aussi, il apporte de nombreuses fonctionnalités comme la synchronisation des attributs étendus, la synchronisation Azure AD vers Active Directory On premise des groupes ou encore une interface de monitoring Azure AD Connect Health. Malheureusement, toutes ces nouvelles fonctionnalités nécessitent de souscrire à la version basic voir premium d’Azure Active Directory.

Du point de vue de l'installation, Microsoft à simplifié les choses pour les personnes disposant déjà d'un des outils précédemment cités. Le but de cet article est de partager un retour d'expérience sur la mise à jour de Dirsync vers Azure AD Connect au travers d'un guide pas à pas puis de détailler les changements entre les deux outils.

Azure AD Connect peut être téléchargé via le lien suivant :

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Mise à jour

Lors du lancement du programme d'installation, il est d'abord demandé d'accepter la licence utilisateur.

Il s'en suit une analyse du serveur existant afin de valider que la configuration Dirsync est compatible avec le processus de migration Azure AD Connect. Si celle-ci n'est pas compatible, il faudra alors réaliser une installation complète du produit. Cela implique de reconfigurer intégralement l'outil (comptes, base de données, règles de filtrage, ….). Plusieurs causes peuvent être responsables de la non prise en charge de la migration :

• Un trop grand nombre d'objets à synchroniser (+ de 50000)

• L'utilisation d'une DLL d'extension personnalisée. Ces dernières permettent d'étendre les fonctionnalités de synchronisation en réalisant du filtrage plus poussé ou une transformation sur certains attributs. Il s'agit d'un concept hérité de Forefront Identity Manager (FIM). En effet Azure AD Connect, comme ses prédécesseurs est toujours basé sur cet outil.

• La suppression d'attributs dans les règles de synchronisation.

Lorsque l'analyse est terminée, il faut indiquer le chemin d'installation ainsi que les informations d'accès à la base de données et éventuellement un compte de service. Comme pour Dirsync, ce dernier doit posséder les droits "Replicate Directory Changes" au niveau du domaine.

Le programme installe ensuite les prérequis.

Les informations (login/mot de passe) du compte utilisé par Dirsync pour accéder à Azure Active Directory doivent être renseignées.

Puis, il est nécessaire d'indiquer un compte Active Directory ayant les droits administrateur de l'entreprise.

La dernière étape consiste à choisir si l'on a activé le mode hybride et s'il faut démarrer la synchronisation dès la fin de l'installation. Ne pas cocher la case permet néanmoins de valider que la configuration a été correctement reportée depuis Dirsync.

Enfin, l'installation s'exécute (une dizaine de minutes).

Revue post installation

Une fois l'installation terminée, DirSync est désinstallé et est remplacé par Azure AD Connect. De nouvelles icônes apparaissent :

• Azure AD Connect : Permet de voir et configurer les paramètres principaux de l'outil

• Synchronization Rules Editor : Cet utilitaire sert à la configuration des règles de filtrages et de transferts d'attributs et ne se trouvent plus dans la console de gestion de FIM.

• Synchronization Service : Cet icône mène à la console de FIM contenant les connecteurs de gestion des identités qui a été renommé pour l'occasion. Comme pour Dirsync, il y a deux connecteurs :

  • Active Directory on premise / Azure AD Connect : import uniquement (sauf en cas d'utilisation du writeback avec Azure AD Premium)

  • Azure AD Connect / Azure Active Directory

• Synchronisation Service Key Management Utility : Utilitaire de gestion de la clé encryptant les données dans Azure AD Connect

NB : Elles sont identiques à celles présentes dans Azure Active Directory Sync.

De plus, comme pour Dirsync, une tâche planifiée nommée Azure AD Sync Scheduler est créée. Elle s'exécute toutes les trois heures (mais il est bien sûr possible de changer ce comportement).

Revue de la configuration

Azure AD Connect :

L'utilitaire Azure AD Connect permet plusieurs options :

• Revue de la configuration actuel

• Configuration des options de synchronisation

• Mise à jour du connecteur

• Gestion du mode staging

La première option permet simplement une revue de la synchronisation mise en place avec une visualisation des annuaires synchronisés et des options activées (synchronisation du mot de passe, des attributs étendues, mapping de l'attribut servant d'UPN dans Office 365). En effet depuis Windows Azure Active Directory Sync, il est possible d'implémenter une synchronisation multi-forêt. Aussi, une synchronisation vers des annuaires différents d'Active Directory est prévue par Microsoft mais cette fonctionnalité n'est pas encore implémentée.

NB : L'option de filtrage par groupe n'est disponible que pour une nouvelle installation et n'est conseillé par Microsoft que dans le cadre d'un déploiement progressif.

Les trois autres options nécessitent d'indiquer un compte administrateur Azure Active Directory  afin de modifier certaines options de configuration.

Le second onglet offre la possibilité d'ajouter d'autres annuaires Active Directory pour la synchronisation.

Il permet aussi d'activer ou désactiver certaines options comme la gestion du mode hybride d'Exchange ou l'écriture inversée (Azure AD vers Active Directory On premise).

L'actualisation du connecteur peut être utilisée après une mise à jour de votre schéma Active Directory. Ainsi, Azure AD Connect pourra mettre à jour ses connecteurs en cas de changement.

Enfin, la dernière option concerne l'activation du mode staging. Lorsqu'il est activé, aucun changement n'est synchronisé/exporté vers Active Directory (si le Writeback est activé) ou vers Office 365. Cela permet de valider sa configuration avant d'appliquer un changement.

Synchronization Service :

Il s'agit de la console Synchronisation Service de Forefront Identity Management. Cependant pour chaque connecteur (appelé Management Agent), les options de configuration sont bien plus légères que dans Dirsync. Il n'est possible de configurer que les paramètres de connexion à l'annuaire, les attributs accessibles et le filtrage par unité d'organisation (via le bouton Container de l'onglet Configure Directory Partitions). En effet, la configuration des filtres par attribut et des règles de jointure d'attribut s'effectue via l'outil présenté dans le chapitre suivant. Cette nouveauté était apparue avec Azure Active Directory Sync.

Synchronization Rules Editor :

Cet outil  change la manière dont sont gérées les règles de synchronisation. Cette gestion ne s'effectue plus au sein de la console de synchronisation héritée de Forefront Identity Manager. Néanmoins, cette nouveauté permet d'utiliser la syntaxe déclarative de FIM qui n'était utilisable qu'au travers de FIM portal (et qui nécessite des CAL pour chaque utilisateur géré par ce système). Ce langage donne la possibilité d'effectuer des opérations simples sans passer par du développement en C# ou VB.Net. Les deux liens ci-dessous expliquent la syntaxe et la détaille :

• https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-understanding-declarative-provisioning-expressions/

• https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-functions-reference/

L'utilitaire offre une vision globale des règles entrantes (import depuis Active Directory On premise ou Azure AD) et sortantes (export vers Active Directory On premise ou Azure AD). Toutes ces règles ont une priorité (la plus faible étant prioritaire sur les autres). Si ces dernières ont un poids supérieur à 100 alors elles correspondent aux règles par défaut de l’outil.

Nous remarquons sur l'image précédente qu'il y a une règle avec une priorité de 99. Il s'agit d'une règle personnalisée reprise lors de la migration de Dirsync. Celle-ci filtre les utilisateurs via un attribut Active Directory. On peut définir le type d'objet source (ici l'annuaire Active Directory On premise) et le type d'objet dans la Metaverse, c’est-à-dire dans la base de données d'Azure AD Connect. Enfin, on peut redéfinir la priorité de la règle. 

L'onglet suivant permet de définir le ou les attributs utilisé(s) pour filtrer les objets (ici des utilisateurs mais cela peut aussi s'appliquer à des groupes par exemple). La définition du filtrage se fait de la même façon que sur Dirsync (les objets satisfaisants la règle étant exclus de la synchronisation).

Ensuite, il est possible de définir une règle de jointure entre un objet provenant de la source (annuaire Active Directory ou Azure Active Directory) et la metaverse. Cette jointure s'effectue sur un attribut. Dans le cas de notre règle de filtrage, il n'existe pas de règle de jointure. Cependant il n'est pas nécessaire d'en ajouter.

En effet, si l'on ouvre la règle avec la priorité 100 (In From AD - User Join), on remarque qu'une règle de jointure existe déjà pour les objets de types utilisateurs.

Enfin, on définit les valeurs transmises depuis la source vers la metaverse. Elles peuvent être de trois types :

• une valeur constante

• un attribut source

• un attribut source transformé via la syntaxe déclarative

Dans le cadre d'un filtrage par attribut pour la synchronisation, les objets non synchronisés doivent posséder l'attribut cloudFiltered avec la valeur True dans la metaverse.

Conclusion

L'installation est donc très similaire à celle de Dirsync et demande les mêmes informations (compte administrateur de l'entreprise, serveur SQL, ...). De plus, le processus de mise à jour est simplifiée au maximum. Néanmoins, pour les personnes n'ayant pas utilisées Azure Active Directory Sync, l'administration et notamment la configuration les règles de synchronisation est différente.

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)

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

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 :

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

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>.

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*

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*

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

Set-Mailbox <SamAccountName> –ExchangeGUID <GUID>

Relancez votre migration.