PI Services

Le blog des collaborateurs de PI Services

Gestion de licence Office 365 en PowerShell

 

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.

image

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

Skype for Business / Lync Server – Hybridation avec Office 365 – Partie 1/2

Contexte

Dans cet article la mise en place du mode hybride entre Skype for Business (SfB) OnPremise et Skype Online sera expliquée. La partie hybride Cloud PBX ne sera pas évoquée.

La mise en place du mode hybride étant légèrement différente entre Skype for Business et Lync Server, cet article sera découpé en deux parties. La première partie sur portera sur Skype for Business 2015 / Skype Online. La seconde partie portera sur Lync Server 2010-2013 / Skype Online.

Mode hybride Skype for Business / Skype Online

Prérequis

Pour pouvoir mettre en place le mode hybride entre SfB OnPremise et Skype Online, certains prérequis doivent être respectés :

  • Une architecture Skype for Business 2015 (avec les dernières mises à jour) contenant au minimum un serveur Edge
  • Un tenant Office 365
  • La synchronisation des comptes utilisateurs entre l’Active Directory et Office 365 (DirSync, Azure AD Connect,...)
  • L’ADFS doit être configurée
  • Des licences utilisateurs Office 365
  • Un compte utilisateur ayant les droits CSAdministrator
  • Un compte utilisateur ayant les droits d’administration Skype Entreprise dans Office 365
  • La liste des domaines fédérées dans Skype Online doit être identique à celle de Skype for Business OnPremise

Note : L’ensemble des entrées DNS doivent pointer sur les serveurs Skype for Business OnPremise. Aucun changement n’est à prévoir.

Mise en place

Depuis un serveur Front-End, lancez la commande suivante depuis le Management Shell (en tant qu'administrateur) pour vérifier que les paramètres AllowFederatedUsers et AllowOutsideUsers sont à True et que le paramètre RoutingMethod corresponde à UseDnsSrvRouting :

Get-CsAccessEdgeConfiguration

GetCsAccessEdgeConf

Si ce n’est pas le cas, exécutez la commande suivante :

Set-CSAccessEdgeConfiguration -AllowOutsideUsers $True -AllowFederatedUsers $True -UseDnsSrvRouting

Exécutez la commande Get-CsHostingProvider pour identifier le provider Skype for Business (ou Lync Online).

image

Supprimez le provider Skype for Business existant via la commande Remove-CsHostingProvider.

image

Exécutez la commande suivante pour recréer le provider avec les bons paramètres :

New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn "sipfed.online.lync.com" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

image

Une fois la partie OnPremise configurée, il faut configurer la partie Online. Pour cela vous devez vous connecter à Skype Online en PowerShell (via le module Skype for Business Online https://www.microsoft.com/en-us/download/details.aspx?id=39366).

Exécutez les commandes suivantes :

Import-Module SkypeOnlineConnector

$cred = Get-Credential <Compte administrateur Skype Online>

$CSSession = New-CsOnlineSession –Credential $cred

Import-PSSession $CSSession –AllowClobber

6

Ensuite vérifiez dans la configuration du tenant si le paramètre SharedSipAddressSpace est à True.

Si ce n’est pas le cas, utilisez la commande suivante pour le passer à True :

Set-CsTenantFederationConfiguration –SharedSipAddressSpace $true

7

Allez sur le portail d'administration Skype Online, vérifiez que le paramètre External Access soit à On except for blocked domains ou à On only for allowed domains.

Capture d’écran 2016-06-28 à 23.28.22

Maintenant que ces commandes sont passées, connectez-vous sur la console d’administration de SfB OnPremise, cliquez sur Sign in to Office 365 et indiquez le compte administrateur de Skype Online.

Des que vous êtes connectés, cliquez sur Set up hybrid with Skype for Business Online.

image

Cliquez sur Next.

image

Si au moment de la validation du mode hybride les erreurs suivantes apparaissent, patientez quelques instants que la réplication des paramètres modifiés précédemment soient prise en compte sur l’ensemble des serveurs.

image

Une fois tous les paramètres synchronisés, la fenêtre suivante s’affiche et le mode hybride est actif.

image

Bascule d’utilisateurs

Une fois que le mode hybride est actif, il est possible de migrer un utilisateur de SfB OnPremise vers Skype Online (et inversement).

Attention : La migration d'un utilisateur peut lui faire perdre l'ensemble de ses contacts Skype.

Pour migrer un utilisateur, vérifiez qu'il possède une licence comprenant la fonctionnalité Skype Online.

2016-06-28_154728

Depuis la console d’administration SfB OnPremise, recherchez l’utilisateur, sélectionnez-le, cliquez sur Action et enfin sur Move selected users to Skype for Business Online…

2016-06-28_155024

Validez les différentes étapes en cliquant sur Next.

2016-06-28_1551382016-06-28_155208

2016-06-28_155444

L’utilisateur est alors dans Skype for Business Online.

2016-06-28_155552

La migration d’un utilisateur Online vers OnPremise se fait par le même procédé en sélectionnant Move selected users from Skype for Business Online…

2016-06-28_155620

Skype for Business / Lync Server – Hybridation avec Office 365 – Partie 2/2

Contexte

Ce billet est la seconde partie de l’article sur la mise en place du mode hybride avec Skype Online. Dans cet article la mise en place de l’hybridation entre Lync Server 2010 (ou 2013) sera traitée.

La grande différence entre l’hybridation SfB / Skype Online et Lync 2010-2013 / Skype Online est la gestion des comptes utilisateurs. En effet dans le cas du mode hybride avec Lync Server 2010/2013 toutes les migrations d’utilisateurs (OnPremise <-> Online) se fait uniquement par PowerShell.

Mode Hybride Lync Server 2010-2013 / Skype Online

Prérequis

Pour pouvoir mettre en place le mode hybride entre Lync Server 2010-2013 et Skype Online, certains prérequis doivent être respectés :

  • Une architecture Lync Server 2010 ou 2013 (avec les dernières mises à jour) contenant au minimum un serveur Edge
  • Pour une architecture Lync Server 2010, un serveur supplémentaire avec les outils d’administration Lync Server 2013 est obligatoire
  • Un tenant Office 365
  • La synchronisation des comptes utilisateurs entre l’Active Directory et Office 365 (DirSync, Azure AD Connect,...)
  • L’ADFS doit être configurée
  • Des licences utilisateurs Office 365
  • Un compte utilisateur ayant les droits CSAdministrator
  • Un compte utilisateur ayant les droits d’administration Skype Entreprise dans Office 365
  • La liste des domaines fédérées dans Skype Online doit être identique à celle de Lync Server

Note : L’ensemble des entrées DNS doivent pointer sur les serveurs Skype for Business OnPremise. Aucun changement n’est à prévoir.

Mise en place

Comme décrit précédemment, les outils d’administration Lync Server 2013 sont obligatoires, donc si vous avez une architecture Lync Server 2010, installez-les sur un serveur d'administration depuis l’iso de Lync Server 2013.

Remarque : Les outils d'administration Lync Server 2013 ne peuvent pas être installés sur un serveur ayant des services Lync Server 2010.

Lync2013Admin

Depuis un serveur Front-End (ou le serveur d’administration), lancez la commande suivante depuis le Management Shell (en tant qu'administrateur) pour vérifier que les paramètres AllowFederatedUsers et AllowOutsideUsers sont à True et que le paramètre RoutingMethod est à UseDnsSrvRouting :

Get-CsAccessEdgeConfiguration

1

Si ce n’est pas le cas, exécutez la commande suivante :

Set-CSAccessEdgeConfiguration -AllowOutsideUsers $True -AllowFederatedUsers $True -UseDnsSrvRouting

Exécutez la commande Get-CsHostingProvider pour identifier le provider Skype for Business (ou Lync Online). 

2

Supprimez le provider existant via la commande Remove-CsHostingProvider.

3

Exécutez la commande suivante pour recréer le provider avec les bons paramètres :

New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn "sipfed.online.lync.com" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

4

5

Une fois la partie OnPremise configurée, il faut configurer la partie Online. Pour cela vous devez vous connecter à Skype Online en PowerShell (via le module Skype for Business Online https://www.microsoft.com/en-us/download/details.aspx?id=39366).

Exécutez les commandes suivantes :

Import-Module SkypeOnlineConnector

$cred = Get-Credential <Compte administrateur Skype Online>

$CSSession = New-CsOnlineSession –Credential $cred

Import-PSSession $CSSession –AllowClobber

6

Ensuite vérifiez dans la configuration du tenant si le paramètre SharedSipAddressSpace est à True.

Si ce n’est pas le cas, utilisez la commande suivante pour le passer à True :

Set-CsTenantFederationConfiguration –SharedSipAddressSpace $true

7

Allez sur le portail d'administration Skype Online, vérifiez que le paramètre External Access soit à On except for blocked domains ou à On only for allowed domains.

Capture d’écran 2016-06-28 à 23.28.22

Le mode hyrbide est désormais en place.

Bascule d’utilisateurs

Attention : La migration d'un utilisateur peut lui faire perdre l'ensemble de ses contacts Lync.

Dans un premier temps, connectez-vous au portail d’administration de Skype Online et récupérez le début de l’URL, dans le cas ci-dessous https://admin1e.online.lync.com/

image

Pour migrer des utilisateurs vous devrez utiliser le début de l’URL complétée par HostedMigration/hostedmigrationservice.svc.

Ici, l’URL finale sera https://admin1e.online.lync.com/HostedMigration/hostedmigrationservice.svc

Maintenant pour migrer un utilisateur OnPremise vers Online, exécutez la commande depuis le Management Shell Lync Server 2013 (depuis le serveur d’administration si vous avez une architecture Lync 2010).

$cred = Get-Credentials <Compte administrateur Skype Online>

Move-CsUser –Identity <UPN> -Target sipfed.online.lync.com -Credential $cred –HostedMigrationOverrideUrl <URL>

8

Pour migrer un utilisateur Online vers OnPremise, exécutez la commande depuis le Management Shell Lync Server 2013 (depuis le serveur d’administration si vous avez une architecture Lync 2010).

$cred = Get-Credentials <Compte administrateur Skype Online>

Move-CsUser –Identity <UPN> –Target <FQDN Front-End>-Credential $cred –HostedMigrationOverrideUrl <URL>

9

Azure AD Connect : Retour d'expérience

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.

Install 02

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.

Install 03

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.

Install 04

Le programme installe ensuite les prérequis.

Install 05

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

Install 06

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

Install 07

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.

Install 08

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

Install 10

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.

Menu 01

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

Task 01

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

Configure 01

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.

Configure 02

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

Configure 03

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

Configure 04

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

Configure 05

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.

Configure 06

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.

Post Install 01

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 :

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.

Configure 07

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. 

Configure 08

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

Configure 09

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.

Configure 10

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.

Configure 12

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.

Configure 11

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.

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

ADFS / Yammer : Renouvellement des certificats

Introduction

Cet article est un retour d'expérience sur un incident rencontré dans le cadre d'une infrastructure ADFS possédant une fédération avec Yammer. Ce dernier s'est produit lors du renouvellement de certains certificats de l'environnement ADFS. L'authentification unique n'était plus fonctionnelle. En effet, une mise à jour doit être réalisée du côté de Yammer lorsque l'un des certificats ADFS est renouvelé. Pour rappel, contrairement à d'autres services qui peuvent être fédérés (comme Office 365), il n'est pas possible de configurer automatiquement le SSO. Cette opération doit être réalisée via une demande au support Office 365.

 

Dans un premier temps, il sera question de faire quelques rappels sur les certificats ADFS puis d'étudier leurs renouvellements. Enfin, nous verrons comment mettre à jour Yammer pour que le l'authentification ne soit pas indisponible lorsque les certificats sont renouvelés. Ce dernier nous permettra de voir comment gérer les certificats avec des services fédérés qui ne peuvent pas récupérer les métadatas automatiquement.

 

Cette manipulation a été réalisée sur une infrastructure sous Windows 2012 R2 (ADFS 3.0).

 

ADFS

Dans une infrastructure ADFS, 3 certificats sont nécessaires au bon fonctionnement de celle-ci :

  • Un certificat public portant le nom DNS du service de fédération. Il s'agit d'un certificat web permettant de sécuriser les communications via SSL.

  • Un certificat auto-généré de type X.509 permettant de signé les tokens d'authentification (Token-Signing). Celui-ci permet de certifier que le token provient bien de la ferme ADFS.

  • Un certificat auto-généré de type X.509 permettant de décrypter des tokens (Token-Decrypting) provenant d'un autre fournisseur de revendications.

Renouvellement du certificat Service-Communications

Le renouvellement pour le certificat public de type Service-Communications se fait manuellement. Lorsque vous posséder votre nouveau certificat, il est nécessaire de l'importer dans le magasin personnel de l'ordinateur des serveurs ADFS (comme lors de la configuration d'ADFS) et des serveurs Web Application Proxy (si vous en posséder) .

 

Sur les serveurs ADFS, lorsque le certificat est importé, il faut ajouté les permissions de lecture sur la clé privée. Pour réaliser cette opération, il faut effectuer un clic droit sur le certificat (lorsque l'on se trouve dans le magasin personnel de l'ordinateur) puis choisir “All Tasks” puis “Manage Private Keys”.

 

03

 

Dans l'onglet sécurité, il suffit d'ajouter les comptes “NT Service\ADFSSRV” et “NT Service\DRS” (pour la fonctionnalité Workplace Join) puis d'attribuer le droit “Read”. Attention, cette opération est à réaliser sur l'ensemble des serveurs de la ferme ADFS.

 

02

 

Les commande Powershell ci-dessous nous permettent ensuite de mettre à jour la configuration des serveurs ADFS.

 

Sur les serveurs ADFS :

 

On récupère, le certificat en utilisant la commande suivante :

 

Cette dernière permet d'interroger le magasin personnel de l'ordinateur (pensez à remplacer NOM_DNS_FERME_ADFS par le nom de votre ferme de serveurs ADFS). Il est nécessaire de récupérer la valeur de l'attribut thumbprint (Pour rappel, ce champ est unique pour chaque certificat).

 

Ensuite, on modifie la configuration du service ADFS pour utiliser notre nouveau certificat en spécifiant la valeur de l'attribut thumbprint.

 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Sur chacun des serveurs ADFS d'une ferme, il faut exécuter la commande ci-dessous pour mettre en place le bindings HTTPS avec le nouveau certificat :

 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Enfin, il est nécessaire de redémarrer le service ADFS sur chacun des serveurs de la ferme.

 

On peut ensuite vérifier les valeurs grâce aux commandes suivantes :

 
 

La seconde cmdlet doit être exécuté sur chacun des serveurs de la ferme ADFS pour effectuer une vérification complète.

 

Les serveurs Web Applications Proxy se mettent à jour via les commandes suivantes :

 
 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Tout d'abord on change le certificat. Dans un second temps, on redémarre le service ADFS pour que le changement de configuration soit pris en compte. Ces deux commandes sont à exécuter sur chacun des serveurs Web Applications Proxy que vous possédez.

 

Renouvellement des certificats Token-Signing et Token-Decrypting

Au sujet, des autres certificats, il existe deux possibilités :

  • Renouvellement manuel

  • Renouvellement automatique

Le renouvellement automatique est la configuration par défaut d'ADFS. 20 jours avant l'expiration d'un certificat, ADFS en génère un nouveau. Celui-ci possède le statut de certificat secondaire. Au bout de 5 jours (soit 15 jours avant l'expiration du certificat), il est promu comme certificat primaire.

 

Les paramètres d'auto renouvèlement se consultent/configurent via Powershell. Pour cela, il faut utiliser la commande “Get-ADFSProperties”. C'est l'attribut AutoCertificateRollover qui permet de déterminer si l'auto renouvèlement des certificats de type Token-Signing et Token-Decrypting est activé.

 

Voici les paramètres ADFS qui peuvent être modifiés par la commande Set-ADFSProperties et qui concernent le mécanisme évoqué précédemment :

  • CertificateDuration : Durée de validité d'un certificat auto généré (par défaut : 365 jours)

  • CertificateGenerationThreshold : Nombre de jours avant la génération d'un nouveau certificat Token Signing or Token Decrypting (par défaut 20).

  • CertficatePromotionThreshold : Nombre de jours avant la promotion du nouveau certificat (passage du status Secondary au status Primary, valeur par défaut : 5 jours).

  • CertificateRolloverInterval : Interval de temps (en minutes) entre chaque vérification de la validité d'un certificat (par défaut 720 minutes).

  • CertificateCriticalThreshold : Nombre de jours avant qu'un certificat expire et qu'un renouvèlement critique ne soit déclenché (ce paramètre intervient lors d'un problème avec le système d'auto renouvellement).

Point d'attention :

Lors du renouvèlement d'un certificat, les métadatas changent. Aussi, si l'un des relying party trust n'est pas capable de récupérer par lui même les métadatas alors l'authentification ne sera plus fonctionnelle.

 

Yammer

La configuration de l'authentification unique via Yammer se fait manuellement. Il est nécessaire d'ouvrir un ticket auprès du support. Celle-ci ne nécessite pas d'envoyer les certificats mais simplement les métadatas. Néanmoins lorsque les certificats ADFS se renouvèlent, il est nécessaire de les transmettre au support Yammer via une demande de service sur le portail d'administration Office 365. Pour se faire, il suffit de créer une archive contenant les nouveaux certificats et de les joindre…

 

Cependant, il peut arriver que le délais soit trop court pour que le ticket soit traité à temps par le support si l'on se trouve presque à la fin de la période de 5 jours après le renouvellement des certificats (voir paragraphe précédent) ou pire, si le nouveau certificat a déjà été défini comme certificat primaire. Ce dernier cas aura pour effet de couper totalement l'authentification unique auprès de Yammer et ainsi causé une coupure de service pour les utilisateurs. En effet, Yammer n'est pas capable de récupérer les nouvelles métadatas contenant les nouvelles informations des certificats.

 

Dans ce cas, on obtient l'erreur ci-dessous lorsque l'on essaie de s'authentifier :

 

01

 

De plus dans l'observateur d'évènements, on remarque des events avec l'id 364 avec pour message :

Lorsque ce problème est rencontré, il faut transmettre le nouveau certificat au support Office 365, ce qui peut peut demander un temps de traitement long. Cependant, si l'ancien certificat est encore valide (c'est à dire qu'il est passé en statut secondaire), il existe une méthode pour rétablir le service temporairement pendant la durée de validité dudit certificat. Pour ce faire, il faut repasser le certificat en statut primaire. Cette opération peut être réalisée via la console graphique.

 

Dans la console ADFS Management, il faut se rendre dans la section “Service” puis “Certificate” puis effectuer un clic droit sur le certificat concerné et choisir l'option “Set as Primary”. Celle-ci peut être grisée. Cela survient lorsque le renouvellement automatique est activé. Il faut donc le désactiver temporairement via la commande suivante :

 

Lorsque le certificat sera de nouveau en statut primaire, le service sera rétabli. Attention, n'oubliez pas de changer le certificat primaire lorsque le support Office 365 vous aura informé de la prise en compte du nouveau certificat.

Retour d'expérience : Migration de tenant Office 365 Partie 2

Introduction

Cet article divisé en deux parties est un retour d'expérience sur une migration entre tenant Office 365. Il ne traitera pas de tous les services disponibles sur Office 365 mais seulement de ceux rencontrés lors de la migration (voir Contexte). La première partie traitait de la migration des licences, du SSO (ADFS) et de Dirsync (http://blog.piservices.fr/post/Retour-dexperience-Migration-de28099un-tenant-Office-365-Partie-1.aspx). Cette seconde partie sera consacré aux autres services d'Office 365 (Yammer, Exchange Online, Sharepoint Online).

Contexte

Pour rappel, la société possédait deux tenant et souhaitait migrer les services de l'un des deux (nommé ici myenterprise1) vers le second (nommé ici myenterprise2). Pour chaque service, un listing des étapes à réaliser sera détaillé.

Exchange Online

Il n'existe pas de réel procédure pour la migration de boîtes aux lettres entre tenant. Le processus ci-dessous est manuel. Globalement, il consiste à exporter les boîtes aux lettres au format PST, à migrer le domaine SMTP puis à recréer les boîtes aux lettres sur le nouveau tenant. Cette procédure est entièrement manuelle. Voici un listing chronologique des étapes à appliquer :

  • Configuration du domaine SMTP sur le nouveau tenant (myenterprise2). Il ne faut bien évidemment pas faire la vérification mais simplement créé les enregistrements et valider qu'ils sont bien visibles avant de passer à l'étape suivante. Cela permet de réduire la coupure de service à quelques minutes. Si les enregistrements DNS ne sont pas créés en amont, le service peut être coupé le temps de la création de ceux-ci et de la propagation dans les DNS (cela peut durer 24H).
  • Création des utilisateurs sur le nouveau tenant (positionnement d'un suffixe UPN en *.onmicrosoft.com). Cela permet de gagner encore un peu de temps sur la coupure de service.
  • Sauvegarde des boîtes aux lettres sur l'ancien tenant (myenterprise1) au format PST (via Outlook par exemple).
  • Changement de domaine des utilisateurs sur l'ancien tenant (myenterprise1). Il suffit de définir leurs suffixes UPN sur le domaine *.onmicrosoft.com afin qu'il n'interfère pas avec la migration du domaine SMTP.
  • Suppression du domaine SMTP de l'ancien tenant (myenterprise1) Office 365.
  • Vérification du domaine sur le nouveau tenant et attribution de l'intention de domaine de type Exchange Online.
  • Changement du domaine d'appartenance des utilisateurs sur le nouveau tenant (mise en place du nouveau domaine SMTP).
  • Activation des boîtes aux lettres pour les utilisateurs sur le nouveau tenant (myenterprise2).
  • Import du PST d'export réalisé précédemment pour chaque boîte aux lettres sur le nouveau tenant (myenterprise2).
  • Reconfigurer les clients Outlook. Il est nécessaire de supprimer le profil et de le recréer pour que la boîtes aux lettres soit accessible.

Toutes les étapes de changements d'UPN sont automatisables via Powershell avec la commande Set-MsolUserPrincipalName (voir script de la section Modification des utilisateurs de la partie 1).

Cette procédure est donc valable pour un faible nombre de boîtes aux lettres. Si le volume de boîte aux lettres est trop important, il reste deux solutions possibles mais plus lourdes et/ou plus onéreuses :

  • Migrer vers une infrastructure On Premise Exchange (scénario prévu par Microsoft) puis rebasculer sur le nouveau tenant Exchange Online.
  • Utiliser des outils de migrations payants.

Sharepoint Online

Comme pour d’autres services Office 365, la migration d’un site Sharepoint Online est manuelle. La migration se déroule en cinq étapes :

  1. Récupération du contenu
  2. Génération d’un modèle
  3. Import du modèle
  4. Intégration du contenu
  5. Paramétrage du nouveau site : il s’agit de reconfigurer les paramètres comme les autorisations utilisateurs.

Nous allons nous intéresser à la migration du contenu, à la génération du modèle de site et à l’import de ce dernier.

Migration du contenu

Afin de migrer le contenu d’un site Sharepoint Online, il faut utiliser OneDrive. Il est nécessaire de se connecter au site web à migrer est de copier tout le contenu du site. Néanmoins si votre site possède moins de 50Mo de contenu, il suffira de l’inclure dans le modèle. En effet, ce dernier peut inclure du contenu si celui-ci ne dépasse pas cette limite de taille.

NB : Il existe aussi des outils de migrations payant.

Génération du modèle de site

La génération du modèle de site se fait via la console d’administration du site (Paramètre du site).

image Dans la section Action du site, il faut choisir “Enregistrer le site en tant que modèle”.

image

Un assistant vous proposera ensuite de donner un nom au modèle et éventuellement d’inclure le contenu du site (cette opération n’est fonctionnelle que si votre contenu pèse moins de 50Mo).

image

Vous pourrez ensuite accéder à la galerie des solutions et télécharger le modèle au format .wsp.

NB : L’option “Enregistrer le site en tant que modèle” n’est parfois pas disponible. Pour l’activer, il faut utiliser Sharepoint Designer 2013. Il est nécessaire d’ouvrir le site depuis ce logiciel en spécifiant son url et de choisir “Options de site” dans le ruban.

image

Enfin, il faut changer la valeur du paramètre “SaveSiteAsTemplateEnabled” à “True” et appliquer le changement. Ainsi, l’option d’enregistrement du site en tant que modèle sera disponible dans les paramètres du site Sharepoint.

image 

Import du modèle de site

Pour importer un modèle de site, il suffit de créer un nouveau site en spécifiant un modèle personnalisé (le modèle devra être fourni ultérieurement).

image

Enfin, il faut ouvrir le nouveau site web et choisir “Galerie Solution” dans lors du choix du modèle. Ce lien vous mènera à une fenêtre permettant de charger le fichier .wsp précédemment créé via le bouton “Télécharger la solution”.

image 

Yammer

Yammer étant un service encore peut intégré avec Office 365, il est plus facile à migrer entre deux tenants. Tout d'abord, il est nécessaire de supprimer le domaine qui correspond au nom du réseau Yammer sur l'ancien tenant(myenterprise1). Il s'agit ensuite de l'ajouter sur le nouveau tenant (myenterprise2).

Si le domaine n'est pas fédéré, il faut que ce dernier soit défini comme domaine par défaut de Yammer. Dans le cas contraire, une erreur est remontée au moment de l'activation du service Yammer. Pour réaliser cette opération, il suffit de se rendre dans le listing des domaines, de sélectionner le bon domaine est de cliquer sur l'option “Définir par défaut”.

Yammer Domain

Nous pouvons ensuite activer Yammer sur le nouveau tenant (myenterprise2). Dans le panneau d'administration d'Office 365, il faut cliquer sur “Tableau de bord” puis choisir “Service Inclus”. Un nouveau panel apparaît sur la droite permettant d'activer Yammer.

Yammer

On peut ensuite confirmer l'activation du service.

Yammer Enable Yammer Enable 2

Le réseau Yammer est rattaché au nouveau tenant dès que le service est activé. Il existe deux types d'administrateurs sur Yammer :

  • des administrateurs déclarés directement dans Yammer
  • des administrateurs héritant de ces droits car ils possèdent le rôle administrateur général du tenant

Les premiers ne subissent aucune perte de droits pendant la migration. Cependant pour la seconde catégorie, il est nécessaire que les utilisateurs aient un compte avec le rôle administrateur général sur le nouveau tenant sinon ils perdront les droits d'administration de Yammer en plus des droits d'administration du tenant (on peut aussi les déclarés directement dans Yammer si on ne souhaitent plus qu'ils soient administrateurs du tenant).

Concernant Yammer Dirsync, comme ce dernier n'interagit pas avec Office 365 (il s'agit d'un second produit de synchronisation différent d'Office 365 Dirsync), il n'y a aucune manipulation à réaliser. Il en est de même pour la configuration du SSO via ADFS.

OneDrive

Concernant OneDrive, il faut, pour chaque utilisateur :

  • Arrêter la synchronisation du dossier
  • Désactiver l'utilisateur sur l'ancien tenant (myenterprise1)
  • Créer son compte sur le nouveau tenant (provisionning manuel ou via Dirsync)
  • Synchroniser le nouveau dossier personnel dans lequel on copiera le contenu qui aura été conservé en local sur la machine.
    OneDrive

Il existe des outils payant si vous souhaitez automatiser le transfert des données entre les deux tenants. Néanmoins, il restera à reconfigurer le client OneDrive.

Conclusion

Contrairement à la migration du SSO et de la synchronisation Dirsync qui est plus structurée (bien qu'il n'existe pas non plus de procédure officielle), la migration de services Office 365 entre tenant est actuellement totalement manuelle et relève plus d'astuces que de réels procédures.

Office 365 – Retour d’expérience d’une migration IMAP

Introduction

L'offre Office 365 inclut un outil de migration. Cet outil permet la migration des boites mails depuis Exchange (2003 / 2007 / 2010 /2013) vers Office 365 ou depuis un autre serveur de messagerie utilisant l'IMAP vers Office 365.
Ce billet portera sur mon retour d'expérience d'une migration IMAP vers Office 365.

Retour d'expérience

Les prérequis


1) Chaque compte migré doit avoir un utilisateur unique associé avec une licence active. Le compte peut être uniquement dans le cloud ou synchronisé avec Active Directory (via DirSync par exemple).
Dans le cadre d'une architecture hybride (c'était le cas dans ce projet), d'autres prérequis utilisateurs sont nécessaires. L'utilisateur doit être "connu" par les serveurs Exchange OnPremise. Pour cela la commande PowerShell suivante est à passer sur les serveurs Exchange OnPremise :

Enable-RemoteMailbox –Identity Utilisateur –RemoteRoutingAddress utilisateur@tenant.mail.onmicosoft.com –PrimarySMTPAddress utilisateur@domaine.fr
Remarque : Attention, si l'utilisateur possède d'autres adresses SMTP que la principale il est nécessaire de les indiquer dans la commande à l'aide du paramètre EmailAddresses
Remarque 2 : Il est également recommandé d'avoir l'UPN (UserPrincipalName) de l'utilisateur qui soit égal à l'adresse email afin de faciliter la connexion aux services Office 365.

2) Un Migration Endpoint avec les éléments suivants :

  • L'URL du serveur IMAP
  • Le type d'authentification (Basic ou NTLM)
  • Le chiffrement (Aucun, SSL, TLS)
  • Le port utilisé pour se connecter en IMAP au serveur
  • Le nombre maximum de migrations simultanées
  • Le nombre maximum de synchronisation incrémentales simultanées

image
3) Un fichier CSV contenant l'adresse email cible, le nom d'utilisateur et le mot de passe du compte IMAP (ou d'un compte administrateur). Le fichier CSV sera construit ainsi :

Les éléments migrés


La migration IMAP n'inclut que la partie mail. En effet les éléments de type contacts, calendrier, tâches… ne sont pas pris en compte.
La migration IMAP prend en compte les mails qui se trouvent dans les différents dossiers (et sous dossiers) personnels ainsi que les dossiers de base (Boite de réception, éléments envoyés, éléments supprimés…).

La migration


La migration se déroule par lot. Chaque lot peut comporter jusqu'à 5000 utilisateurs.
Pour une meilleure gestion des erreurs et de la volumétrie, des lots de 1200 utilisateurs environ ont été fait.
A titre d'exemple, le temps de migration pour un lot de 1200 utilisateurs ayant une volumétrie d'environ 30 Go au total (soit une moyenne de 25Mo/BAL) a mis un peu plus de deux heures.
Cette estimation est bien évidement propre à l'architecture et peut être différente en fonction de la bande passante et des performances du serveur source.

La gestion des erreurs


Il est courant qu'un lot de migration comporte des erreurs. Pour les identifier il est possible d'utiliser la commande PowerShell suivante sur le tenant Office 365 :
Get-MigrationUser -ResultSize Unlimited | ?{$_.Status -ne "Synced"}

image

Les utilisateurs en échec peuvent être sorti du lot de migration et relancés dans un lot séparé.
Remarque : Un utilisateur ne peut pas être inclus dans un nouveau lot s'il appartient déjà à un lot. Microsoft met également à disposition des rapports (au format CSV) sur la plateforme d'administration d'Office 365 – Exchange.

Conclusion

Dans le cadre de cette migration, le pourcentage d'erreur a été de 0.2% (moins d'une vingtaine de boites en erreur sur plus de 6000 boites migrées).
Le seul point négatif est la limite des éléments migrés. Les calendriers, carnets d'adresses… ne sont pas pris en compte et doivent être fait manuellement par l'utilisateur ou via un autre outil de migration.


Pour conclure l'outil de migration fonctionne parfaitement. Même s'il possède peu de fonctionnalités contrairement à d'autres outils de migration (Refresh IT, Quest…) il permet une migration simple à un moindre coût.

DirSync – Changement de l’adresse e-mail recevant les alertes

Contexte

Lors de la mise en place de DirSync dans une architecture, ce dernier envoie automatiquement des mails lors des problèmes de synchronisation.

Problème

L’adresse e-mail utilisée par DirSync n’est plus consultée et nous ne recevons plus d’alertes.

Solution

DirSync utilise l’adresse e-mail principale du tenant Office 365 (l’adresse enregistrée à la création du tenant). Il faut donc modifier cette adresse pour recevoir les alertes DirSync.

Une fois connecté au portail d’administration d’Office 365, il faut cliquer sur le nom de la société en haut à droite de la page. Puis il est possible de modifier les informations du compte principal, notamment l’adresse e-mail.

image

image

DirSync – Erreur à l’installation de DirSync sur un serveur Windows Server 2012 R2

La problématique

Lors de l’installation de Windows Azure Active Directory Synchronization (aka “DirSync”) sous Windows Server 2012 R2, l’erreur suivante peut apparaitre :

The minimum version of Windows Powershell required is 2,0.
Please install the minimum version required (or higher) and try again.

image

Cela peut sembler étrange d’autant plus que Windows Server 2012 R2 intègre nativement la version 4.0 de PowerShell.

Explication

Il semble que ce problème soit dû à la localisation du système d’exploitation. En effet sur un système d’exploitation installé en langue française, le caractère séparateur entre les entiers et les décimales est la virgule et non le point.

Or on peut remarque que le message d’erreur indique un problème pour détecter la version PowerShell 2,0 et non 2.0.

Solution

La solution consiste tout simplement à modifier les formats de date, d’heure et de nombre et à les passer sur le format anglais.

image

Il suffit ensuite de fermer, puis de relancer l’installeur de DirSync pour que la modification soit prise en compte et que PowerShell soit bien détecté.

image

N.B. : Ne pas oublier de lancer dirsync.exe avec des droits administrateur (clic droit, puis Run As Administrator), sinon une exception .net apparaît