(7 vote(s), 
Loading...Dans le cadre d'une migration de Microsoft Exchange 2010/2013 vers Exchange 2016 vous allez créer des lots de migration pour déplacer vos BAL des anciennes banques vers les nouvelles.
C'est Exchange 2016 qui s'occupe du déplacement des BAL vers ses banques, mais il arrive qu'un lot de migration reste bloqué en état "synchronisation".
Plusieurs causes possibles avec pour chaque cause sa solution que je vous détaille dans ce guide anti prise de tête ! J'ai en effet passé des heures pour comprendre comment la boite noire qu'est Exchange fonctionnait.
Disclaimer
Avant de vous lancer dans des opérations de migration assurez-vous d'avoir des sauvegardes intègres et récentes.
Quoi qu'il en soit je ne suis pas responsable de vos actions, je partage ici mon expérience et il ne s'agit en rien d'une référence. Chaque infrastructure a ses spécificités et réagit différemment.
La seule référence officiel est le technet Microsoft.
Pensez à désactiver tous les quotas sur vos banques de destination ainsi que les quotas en dur sur chaque mailbox, car le process de migration n'appréciera pas de se faire couper la chique par une restriction de quota. Vous remettrez les quotas en place une fois toutes les BAL migrées.
Ce guide concerne Exchange 2016, il a été validé uniquement sur cette version. Il est possible que cela fonctionne de façon similaire avec Exchange 2013, je n'ai pas essayé.
Historiquement sous Microsoft Exchange 2010 cette opération s'effectuait sous le nom de "demande de déplacement locale".
Lexique Exchange
- onpremise = hébergé chez vous sur votre infrastructure (locale)
- online = hébergé chez microsoft (office 365)
- banque de données = base de données = database
- BAL = boite aux lettres = boite email = mailbox
Avant tout, soyez patient
Ces opérations de lot de migration prennent du temps, même avec une BAL vide de test. Soyez patient et attendez au moins 30 à 60 minutes quand vous lancez un lot pour statuer sur le fait qu'il soit planté ou non (suivant la taille des BAL et des ressources de vos serveurs).
Les approximation de traduction de Microsoft ajoutent de la confusion, c'est pourquoi je vous détaille ici toutes les étapes.
Mais, quelle est la cause d'un tel blocage ? Il en existe au moins 2.
Cause 1
Vous avez une demande déplacement d'une banque Exchange 2010 vers une autre banque Exchange 2010 qui n'a pas été effacée. Exchange 2016 contrôle ceci une fois le lot lancé, mais pas avant. C'est un peu bête, mais c'est fait comme ça.
Cause 2
Vos banques de données et/ou leurs copies ne sont pas dans un état de santé "healthy".
J'ai rencontré ce problème et mes lots se comportaient de façon totalement aléatoire sans que je ne comprenne pourquoi... en regardant de près toutes les opérations passaient en file d'attente tant que les copies de bases n'étaient pas dans un état "health".
Là encore, Exchange ne prévient pas c'est donc à vous de vérifier que les bases sont bien montées et en état :
Get-MailboxDatabase -Status | Format-List name,server,mounted
Get-Queue | Select Identity,Status,MessageCount | fl
Et sur chacun de vos serveurs :
Get-MailboxDatabaseCopyStatus -Server SRV2016-1 | fl contentindex*,databasename
En cas de problème de santé cette commande affichera "FailedAndSuspended" et/ou "The content index is corrupted".
Une fois que vous avez vérifié que tout fonctionne bien, passons à la suite. Vous avez 2 possibilités gérer un lot de migration : le terminer manuellement ou automatiquement. Voyons le comportemen pour chaque mode.
Cas d'un lot terminé automatiquement
Le lot sera bloqué en "synchronisation" et dans "afficher les détails" l'utilisateur est en "échec".
Les autres utilisateurs du lot passent en état "synchronisation" :
Puis en état "terminé" :
Voici la solution :
- Dans les détails du lot > supprimer la BAL en échec (icone corbeille) qui passe en "suppression" avant de disparaître
- effacer la demander déplacement dans la console Exchange 2010 :
A ce moment là quand toutes les autres BAL sont terminées le statut du lot "synchronisation" n'a pas de sens car il n'y a plus rien à migrer. C'est juste un bug de l'interface web ECP qui n'arrive pas connaître le statut réel du lot, car même quand vous supprimez toutes les identités du lot il reste en état "synchronisation" !
Pour vérifier que les BAL ont changé de banque allez dans destinataires > boîtes aux lettres et regarder si les BAL sont bien dans la nouvelle banque.
Il ne vous donc plus qu'à :
- stopper le lot (bouton stop)
- Attendre que l'état passe de "interruption" à "interrompu"
- supprimer le lot (icone corbeille)
- Créer un nouveau lot avec la BAL qui posait problème (en mode "terminer automatiquement") :
Cas d'un lot terminé manuellement
Le lot sera bloqué en "synchronisation" et dans "afficher les détails" l'utilisateur est en "échec" avec l'erreur UserAlreadyBeingMigratedException.
Les autres utilisateurs du lot restent en état de "synchronisation", en réalité ils sont en attente à cause de la BAL en échec.
Solution :
- stopper le lot (bouton stop)
- Attendre que l'état passe de "interruption" à "interrompu"
- effacer la demande de déplacement de la BAL en échec depuis Exchange 2010 :
- relancer le lot (bouton play)
Toutes les BAL du lot repassent par les états "démarrage", "synchronisation", "terminé" puis synchronisé (y compris la BAL en échec) :
Note : il est tout à fait normal que la BAL en échec reste plus longtemps par l'étape de synchronisation car elle a un peu de retard sur les autres.
Si ce n'est pas le cas et que l'état reste bloqué en "synchronisation" vous reprendre la migration de la BAL bloquée :
Get-MoveRequest k0 | Resume-MoveRequest
Ou terminer la migration mais uniquement pour la BAL "k0" :
$Date = Get-Date
Get-MoveRequest "k0@bm.ad" | Set-MoveRequest -CompleteAfter $Date
L'état du lot devient "synchronisé", exemple : "boîtes aux lettres synchronisés : 3/3".
Il ne reste plus qu'à cliquer sur "terminer le lot de migration" à droite.
L'état du lot passe en "fin" (mal traduit, comprendre "en cours de finalisation") puis "terminé".
Exemple : "Boîtes aux lettres finalisées : 3/3".
Savoir si une BAL a migrée
Il vous suffit d'aller dans destinataires > boites aux lettres et ajouter la colonne "base de données". Pour cela cliquer sur les "..." > ajouter/supprimer des colonnes.
Si vos BAL indiquent des banques hébergées sur la nouvelle infra c'est terminé.
Comment avoir plus de logs
Pour avoir un peu plus de détails sur l'état :
Sur l'état de la migration d'une BAL :
Get-MoveRequest K0@bm.ad
Avec plus de logs :
Get-MoveRequest K0@bm.ad | Get-MoveRequestStatistics -includereport |fl
En exportant vers un CSV, plus pratique à lire :
Get-MoveRequest K0@bm.ad |Get-MoveRequestStatistics -includereport | Export-csv -Encoding UTF8 c:\temp\K0.txt
Sur l'état de la migration d'un lot (batch) :
Get-MigrationBatch -Identity "nom du lot" -IncludeReport
Limitation avec Exchange 2010
Si vous essayez d'effacer une demande de déplacement de 2010 vers 2016 depuis Exchange 2010 vous aurez ce message d'erreur :
"MapiExceptionNoAccess : Unable to open message store..."
Il protège le transfert, car c'est le serveur 2016 qui en est à l'origine et il ne faudrait pas que 2010 puisse interrompre l'opération.
Commandes et liens utiles
En complément quelques commandes qui peuvent servir :
Supprimer tous les lots terminés :
Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest
Terminer un lot de migration préparé :
Get-MigrationBatch "nom du lot" | Complete-MigrationBatch
Terminer une demande de déplacement pour une BAL donnée :
Get-MoveRequest "toto@bm.ad" | Resume-MoveRequest
Voir l'historique de déplacement pour une banque de données (même après suppression) :
Get-MoveRequestStatistics -MoveRequestQueue "Banque-2016-2"
Déplacer une BAL de banque :
get-mailbox "toto@bm.ad" | New-MoveRequest -TargetDatabase "Banque-2016-1"
ou :
New-MoveRequest -Identity "toto@bm.ad" -TargetDatabase "Banque-2016-1"
Effacer toutes les demandes de déplacement terminées:
Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest
Afficher la date et heure des étapes :
Get-MoveRequest "toto@bm.ad" | Get-MoveRequestStatistics | Select *TimeStamp
Liens utiles (technet et divers) :
- Gérer les déplacements de boîtes aux lettres locales dans Exchange 2016
- Gestion des lots de migration dans Exchange Online (la procédure de migration onpremise est très proche de la version online)
- Préparer un lot depuis un fichier CSV
- Différer la bascule
- Utiliser PreventCompletion, CompleteAfter, SuspendWhenReadyToComplete
- Reprendre individuellement une demande de déplacement
Conclusion
C'est un peu laborieux et j'espère que ces informations vous seront utiles. Comme d'habitude faites vos essais sur une plateforme labo avant de tester sur la production, on n'est jamais trop prudent.
Important : n'utilisez jamais l'argument -force sur pour supprimer un lot de migration, j'ai fait le test en labo et j'ai scratché complètement la BAL et le compte AD associé. Je suppose que cela a interrompu le process de migration en plein milieu, et c'est à proscrire !
Le premier commentaire c'est pour vous 👇