Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant. La première partie traitera de l’architecture et des pré-requis à la migration. La seconde partie traitera du plan d’action et de la migration. Enfin la troisième partie traitera des problèmes rencontrés lors de celle-ci.

Architecture

L’architecture de cette migration est assez simple. Deux environnements similaires contenant chacun Active Directory, Azure AD Connect, ADFS et O365. Le but de la migration est de migrer l’ensemble des données du tenant A vers le tenant B. Les comptes Active Directory ne sont pas migrés et l’ADFS A sera toujours utilisé par les utilisateurs de l’Active Directory A. La synchronisation vers le tenant utilisera bien évidemment le serveur AD Connect B. Enfin les adresses emails garderont le même nom de domaine de la source vers la destination.

Figure 1 – Schéma source de l’architecture

Figure 2 – Schéma cible de l’architecture

Pré-requis

Le premier pré-requis est d’avoir une relation d’approbation inter-forêt entre les deux forêts AD.

La migration tenant-to-tenant nécessite également un outil tiers afin de migrer l’ensemble du contenu des boites aux lettres (emails, contacts, calendrier…).

Un nombre de licences suffisant dans le tenant B est également indispensable pour accueillir les comptes du tenant A.

Enfin il est important d'avoir un compte administrateur global utilisant le domaine par défaut de microsoft (@domaine.onmicrosoft.com).

Voilà qui conclut la première partie de mon retour d'expérience. Stay tuned!

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la seconde partie qui traitera du plan d’action et de la migration.

Plan d’action

Lors de la migration les noms de domaine des adresses emails étant conservés, une coupure de service est obligatoire. Il est donc primordial de bien préparer la migration et d’effectuer en avance de phase toutes les tâches pouvant être traitées pré-migration.

Le plan d’action sera le suivant :

1. Avoir un export de l’ensemble des données du tenant A. Pour chaque compte connaître son adresse de messagerie, ses alias, ses droits… Idem pour l’ensemble des objets Exchange (boites partagées, listes de distribution, contacts...)
2. Créer des utilisateurs cloud uniquement dans le tenant B correspondant aux utilisateurs du tenant A. Exemple : john.doe@domainea.com aura un compte john.doe@domaineb.onmicrosoft.com
3. Assigner des licences aux utilisateurs dans le tenant B
4. Créer le reste des objets Exchange (attention certains objets peuvent-être synchronisés avec l’AD et d’autre uniquement dans le cloud) du tenant A dans le tenant B
5. Commencer les migrations via l’outil de migration. Exemple : l’ensemble des mails plus vieux que les 30 derniers jours
6. Arrêter la synchronisation de l’ensemble des objets de l’Active Directory A vers le tenant A (supprimer la synchronisation des OU dans Azure AD Connect A). L’ensemble des comptes dans le tenant A sont à présent en Soft-Deleted
7. Utiliser la commande suivante pour restaurer l’ensemble des comptes en tant que comptes cloud uniquement :

   Get-MsolUser –ReturnDeletedUsers –All | Restore-MsolUser

8. Supprimer l’ensemble des références aux noms de domaine présent sur le tenant A (alias, adresses SIP,…). Tous les objets doivent avoir uniquement des adresses avec l’adresse par défaut de Microsoft
9. Supprimer les noms de domaine du tenant A
10. Ajouter les noms de domaine sur le tenant B
11. Modifier l’UPN des comptes cloud du tenant B pour qu’ils soient égaux aux UPN des comptes de l’Active Directory A.
12. Créer un nouveau connecteur sur l’AD Connect B pour synchroniser les comptes de l’Active Directory A. Une fois la synchronisation terminée, les comptes cloud du tenant B ont fusionné avec les comptes de l'Active Directory A.
13. Finaliser la migration via l’outil (attention, les adresses sources et destinations ont changé, il est peut-être nécessaire de les mettre à jour dans l’outil utilisé pour la migration)
14. Mettre à jour l’ADFS A via les commandes suivantes :

    Set-MsolDomainFederationSettings –domainname "domainea.com" –ActiveLogOnUri "https://<url ADFS A>/adfs/services/trust/2005/usernamemixed" –issuerUri "http://<domainea.com>/adfs/services/trust/" –logoffuri "https://<url ADFS A>/adfs/ls/" –metadataexchangeuri "https://<url ADFS A>/adfs/services/trust/mex" –PassiveLogOnUri "https://<url ADFS A>/adfs/ls/"
    Update-MsolFederatedDomain –DomainName "domainea.com" –SupportMultipleDomain

Migration

La planification

La planification de la migration est importante. En effet lorsque l’on se réfère au plan d’action on remarque que beaucoup d’actions sont à faire pendant l’interruption de service (de l’étape 6 à l’étape 12). Il est donc important de bien planifier la migration sur un weekend et de vérifier qu’aucune autre action est prévue à cette date là (paye, bilan comptable…).

Il est également très important de communiquer avec les utilisateurs tout au long du projet. Expliquer pourquoi une telle migration (intégration de la messagerie dans la messagerie groupe par exemple), bien indiquer les dates de la migration, prévenir de l’interruption de service et informer des éléments qui ne sont pas pris en compte par cette migration (signature…).

Y penser !

Une fois la migration terminée, le support utilisateur peut être amener à avoir une surcharge de travail. Avoir une équipe renforcée lors des premiers jours post-migration aidera grandement à la résolution des problèmes et à la gestion du stress des équipes.

Les actions post-migrations

Une fois la migration terminée, certaines actions sont nécessaires côté utilisateur (création d’un nouveau profil sur Outlook par exemple) mais aussi côté administrateur (donner de nouveaux droits d’administration aux équipes sur le tenant B par exemple).

Mettre en place un fichier de suivi pour les problèmes rencontrés est fortement conseillé. Cela permet de centraliser et donc de faciliter la résolution des problèmes et de ne pas oublier certains points (notamment si c’est un problème mineur).

Voilà qui conclut la seconde partie de mon retour d'expérience. Stay tuned!

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la dernière partie qui traitera des problèmes rencontrés lors de la migration.

Problèmes rencontrés et solutions

Eléments de calendrier non-migrés

Un point important pour que la migration des calendrier se fasse, la time-zone de la boite aux lettres de destination doit être renseignée. La commande PowerShell suivante permet de mettre à jour cet attribut

Set-MailboxRegionalConfiguration –Identity "<UserPrincipalName>" –TimeZone "GMT Standard Time"

Les valeurs possibles de la time-zone sont indiqués ici : https://support.microsoft.com/en-us/help/973627/microsoft-time-zone-index-values.

Migration OneDrive

Tout comme la migration des éléments de calendrier, la partie OneDrive nécessite une initialisation des comptes cibles pour que la migration s’effectue.

Lors de cette migration j’ai utilisé le script présent à l’adresse suivante pour initialiser l’ensemble des comptes.

https://support.office.com/fr-fr/article/Comment-configurer-des-sites-utilisateur-dans-OneDrive-entreprise-ceef6623-f54f-404d-8ee3-3ce1e338db07

Mauvaise synchronisation des comptes Active Directory

Au moment de la synchronisation de l’Active Directory A vers le tenant B, il est possible que certains comptes ne fusionnent pas avec leur compte cloud correspondant et que des doublons soient présent.

Il peut y avoir diverses raisons à cela :

• Une erreur dans l’UPN du compte cloud
• Un contact déjà présent dans le tenant B avec l’adresse email du compte A
• Un compte invité dans le tenant B avec l’adresse email du compte A

Dans ce cas, il faut tout d’abord supprimer l’objet (le contact ou le compte invité) du tenant B (en le supprimant également de la corbeille O365). Ensuite il faut désynchroniser le compte AD (en déplaçant le compte dans un OU non-synchronisée). Une fois le compte désynchronisé il faut supprimer ce compte de la corbeille O365. Lancer une nouvelle synchronisation pour que la métaverse de l’AD Connect prenne en compte la modification. Enfin resynchroniser le compte AD. Il doit alors fusionner correctement.

Si ce n’est pas le cas, il est possible que le compte cloud ne récupère par l'attribut ImmutableID. Cet attribut est le "lien" entre le compte dans l'Active Directory (et donc celui de la métaverse AD Connect) et le compte cloud O365.

Pour modifier l'attribut il faut de nouveau désynchroniser le compte AD et le supprimer de la corbeille O365 puis il faut utiliser les commandes PowerShell suivantes.

Sur l’Active Directory A :

$adUser = Get-ADUser "<SamAccountName>" –Properties *

$id= $adUser.ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($adUser.ObjectGUID)).tobytearray())}

Sur le tenant B :

Set-MsolUser –UserPrincipalName "<UserPrincipalName>" –ImmutableID $id

Resynchroniser le compte AD.

Conclusion

Ce billet termine mon retour d'expérience sur cette migration tenant-to-tenant. J'espère qu'il vous a été utile.

Contexte

Dans une architecture Exchange 2013 Hybride où les publications web sont faites par des boitiers KEMP vous ne pouvez pas faire de migration.

En effet vous obtenez l’erreur suivante The connection to the server ‘Exchange Server’ could not be completed.

Explications et solution

La première chose à valider est l’activation du proxy MRS sur les serveurs Exchange.

Pour cela depuis le centre d’administration Exchange, allez dans Serveurs puis Répertoires virtuels et vérifiez que sur l’ensemble des répertoires EWS l’option Activer le point de terminaison du proxy MRS est cochée.

Si c’est bien le cas, le problème peut venir de la configuration de la publication des services web d’Exchange sur le KEMP.

Depuis l’interface d’administration KEMP, allez dans System Configuration > Miscellaneous Options > L7 Configuration.

Modifiez la valeur du paramètre 100-Continue Handling pour RFC-7231 Compliant.

La modification de cette valeur va permettre au boitier KEMP de ne pas rejeter la demande de l’assistant de migration.

En essayant à nouveau de faire une migration, l’assistant passera à l’étape suivante.

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

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 :

EmailAddress,UserName,Password alexis.bernard@piservices.fr,alexis.bernard,password john.doe@piservices.fr,john.doe,password bill.gates@piservices.fr,bill.gates,password

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"}

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.

Symptôme

Suite à la migration d’une boîte aux lettres Exchange Server 2003 SP2 vers un DAG Exchange 2010 SP1 RU6 (en environnement intra-organisationnel),  l’utilisateur ne peut plus synchroniser ses emails via ActiveSync et l’erreur suivante se produit régulièrement dans le journal Application du serveur CAS :

Voici le détail de l’erreur rencontrée :

De plus l’utilisateur ne peut pas voir son téléphone lorsqu’il accède à l’interface ECP (Exchange Control Panel) dans le menu Phone, puis Mobile Phone.

Explication

Avec Exchange Server 2003 les partenariats ActiveSync sont stockés dans un dossier caché au sein de la boîte aux lettres de l’utilisateur.

Ce dossier se nomme Microsoft-Server-ActiveSync et est visualisable à l’aide d’un outil tel que MFCMAPI (http://mfcmapi.codeplex.com/).

Avec Exchange Server 2010 les partenariats ActiveSync sont stockés directement dans l’annuaire Active Directory sous la forme d’un objet de type msexchangeActiveSyncDevice.

Lors de la migration de la boîte aux lettres vers Exchange Server 2010 le serveur Exchange possédant le rôle CAS doit donc créer un conteneur nommé CN=ExchangeActiveSyncDevices dans le compte utilisateur. Le serveur CAS créé ensuite un objet de type msexchangeActiveSyncDevice dans ce conteneur pour chaque partenariat ActiveSync établit.

Voici un exemple d’objet msexchangeActiveSyncDevice généré dans un environnement Exchange Server 2010 :

Dans notre exemple l’héritage des autorisations étaient désactivé sur le compte utilisateur. Cela a empêché la descente des ACL nécessaires au bon fonctionnement d’Exchange et donc a provoqué le message d’erreur 1053 Access is Denied sur le serveur CAS.

Cette désactivation était engendrée dans notre cas à cause de l’appartenance du compte utilisateur au groupe “Server Operators” qui est l’un des groupes protégé par le mécanisme AdminSDHolder.

Pour mémoire ce mécanisme a pour but de contrôler les ACL appliquées sur les objets (comptes utilisateurs, comptes ordinateurs…) membres des groupes protégés.

La liste des groupes protégés par le mécanisme AdminSDHolder dans les différentes versions de Windows (de Windows 2000 Server à Windows Server 2008 R2) est disponible sur le site de Microsoft à l’adresse suivante :

http://technet.microsoft.com/en-us/query/ee361593

Remarque : Dans notre cas le téléphone touché était un Sony Ericsson sous Symbian avec l’application RoadSync. Cependant ce problème étant dû à une configuration au niveau du compte Active Directory tout autre téléphone pourrait en être victime.

Résolution

Pour résoudre ce problème il faut se connecter à l’ADUC (Console “Utilisateurs et ordinateurs Active Directory”), puis dans les propriétés de l’utilisateur concerné choisir “Security”, “Advanced” puis cocher la case “Include inheritable permissions from this object’s parent”.

Suite à cette manipulation la synchronisation “initiale” (comprendre celle engendrant la génération des objets dans l’annuaire Active Directory) du téléphone fonctionnera ainsi que toutes les synchronisations ultérieures.

Une fois la première synchronisation effectuée l’utilisateur pourra visualiser et gérer ses partenariats ActiveSync dans l’interface ECP (la capture d’écran ci-dessous est un exemple).

Remarque : Il est intéressant de noter que le mécanisme AdminSDHolder remodifiera automatiquement les ACL (et donc re-désactivera l’héritage des autorisations) dans un délai d’une heure maximum (en effet le processus s’exécute toutes les 60 minutes par défaut).

La préparation de l’annuaire Active Directory pour le déploiement du service pack 2 d’Exchange Server 2010 est tout à fait classique.

Mise à jour du schéma Active Directory

Dans un premier il faut déployer les extensions de schéma Echange Server 2010 SP2 à l’aide de la commande setup.com /PrepareSchema.

Remarque : Cette opération effectue des modifications sur la partition de schéma de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Schema Admins”.

Les extensions de schéma du service pack 2 intègrent de nouvelles classes et de nouveaux attributs. Parmi ces nouveaux attributs il y a notamment 5 nouveaux attributs nommés extensionCustomAttribute1 à extensionCustomAttribute5. Ces attributs supplémentaires peuvent être utilisés pour stocker des propriétés supplémentaires sur les objets destinataires (boîtes aux lettres, groupes, contacts…). Ils sont utilisables avec les commandes PowerShell suivantes :

- Set-DistributionGroup
- Set-DynamicDistributionGroup
- Set-Mailbox
- Set-MailContact
- Set-MailPublicFolder
- Set-RemoteMailbox

Pour aller plus loin au sujet de ces nouveaux attributs vous pouvez consulter l’article suivant sur le blog de l’équipe Exchange :

http://blogs.technet.com/b/exchange/archive/2012/01/17/custom-aka-extension-attributes-in-exchange-2010-sp2-and-their-use.aspx

Ainsi que le document de référence sur les extensions de schéma Exchange Server (document mis à jour suite à la sortie du SP2) :

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5401

Pour vérifier que le schéma a bien été mis à jour il suffit de vérifier la valeur de l’attribut rangeUpper sur la classe ms-Exch-Schema-Version-Pt à l’aide d’un outil comme ADSIEdit (ou via une requête de type dsquery par exemple).

Suite à la mise à jour du schéma, la valeur de l’attribut rangeUpper passe de 14728 (version Exchange 2010 SP1) à 14732 (version Exchange 2010 avec SP2).

Mise à jour de l’organisation Exchange

L’étape suivante consiste à mettre à jour l’organisation Exchange 2010 à l’aide de la commande setup.com /PrepareAd (dans cet exemple l’organisation se nomme PIServices).

Remarque : Cette opération effectue des modifications sur la partition de configuration de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Enterprise Admins”.

Pour valider la propagation des modifications apportées à la partition de configuration sur les différents contrôleurs de domaine le plus simple consiste à affichez les propriétés de l’organisation Exchange via ADSIEdit.

L’attribut objectVersion de l’organisation passe de 13214 (Exchange 2010 SP1) à 14247 (Exchange 2010 SP2).

Mise à jour des domaines

Il faut enfin mettre à jour chaque domaine de la forêt Active Directory à l’aide de la commande setup.com /PrepareDomain.

Remarque : Cette opération effectue des modifications sur la partition de domaine du domaine concerné et par conséquent nécessite l’utilisation d’un compte membre du groupe “Domain Admins” dans le domaine concerné.

Suite à l’application du service pack 2 d’Exchange 2010 la valeur de l’attribut objectVersion sur l’objet CN=Microsoft Exchange System Objects présent à la racine du domaine passe à 13040 (cette valeur est identique à celle du SP1 d’Exchange 2010).

Déploiement du service pack 2 sur l’ensemble des serveurs

Une fois l’annuaire préparé et les modifications propagées sur l’ensemble des contrôleurs de domaine il est conseillé de mettre à jour les serveurs Exchange 2010 dans l’ordre suivant :

• Serveurs CAS
• Serveurs HUB
• Serveurs Mailbox
• Serveurs UM

Remarque : les serveurs Edge étant situés en workgroup ils peuvent être patchés en parallèle.

Si la haute disponibilité est déployée sur l’environnement il faudra bien sur déployer le package successivement sur chaque nœud en pensant bien à isoler le nœud en train d’être patché (mode “drain” sur les serveurs CAS et/ou HUB en load balancing matériel ou NLB, mode maintenance sur un nœud appartenant à un DAG).

Le déploiement du patch sur un serveur nécessite que les outils d’administration Exchange 2010 (console MMC et Powershell) soient fermés. De plus les services tiers accédant aux services Exchange (agent de sauvegarde, agent antivirus dédié à Exchange…) doivent également être arrêtés.

Si certains services ou outils bloquent le déploiement du Service Pack alors une fenêtre équivalent à celle-ci s’affichera à l’issue de test des prérequis.

Attention, pas retour d’expérience, le service pack 2 peut mettre jusqu’à 1h, voir 1h30 pour se déployer sur certaines configurations.

Après une migration de boites aux lettres depuis une organisation Exchange 2003 vers une organisation Exchange 2007, il peut arriver que l’attribut “Recipient Type Details” ne soit pas défini en tant que “User Mailbox”

Voici différent cas rencontrés :

Legacy Mailbox

Ceci est typiquement le type de boite aux lettres créé avec les outils Exchange 2003. Ce type de boite aux lettres fonctionne sous Exchange 2007 mais afin d’éviter la perte de certaines fonctionnalités d'Exchange 2007, il est préférable de la convertir.

Pour cela, une simple commande Powershell suffit :

Linked Mailbox

Ceci indique que la boite aux lettre disposait d’un compte externe associé (autre que le compte SELF) avant la migration.

Pour résoudre le problème, il faut modifier les attributs de l’utilisateur en question (avec ADSIEdit) et modifier la valeur de l’attribut msExchRecipientTypeDetails de la valeur 2 à la valeur 1.

http://technet.microsoft.com/en-us/library/cc164371.aspx

Shared Mailbox

Ceci indique que le compte SELF est configuré en tant que compte externe associé sur la boite aux lettres.

Après la migration de la boite aux lettres, supprimer l’association du compte SELF en tant que compte externe associé. Ceci modifiera l’attribut msExchMasterAccountSid et lui donnera la valeur <Not Set>. Ensuite, lancer la commande Powershell suivante :

http://technet.microsoft.com/en-us/library/bb201749.aspx