Meilleur auteur de réponses
Migration Exchange 2010-2016 - Échec de communication avec la base de données de boîtes aux lettres

Question
-
Bonjour,
je rencontre un problème sur une migration Exchange 2010 / 2016.
J'ai lancé hier la migration des 160 BAL via powershell. Elles étaient en file d'attente et s'exécutaient progressivement. J'ai paramétré mes jobs pour qu'ils se complètent automatiquement dimanche à 21H.
Ce matin j'ai vu que je ne pouvais plus afficher l'état des migrations ; erreur suivante :
Échec de communication avec la base de données de boîtes aux lettres.
+ CategoryInfo : ResourceUnavailable: (:) [Get-MoveRequestStatistics], StorageTransientException
+ FullyQualifiedErrorId : [Server=SRV-EXCH2016,RequestId=eeecbfe9-5dda-40d6-8c1c-0624eca1413f,TimeStamp=29/11/2019 15:14:44] [FailureCategory=Cmdlet-St
orageTransientException] 26E778AA,Microsoft.Exchange.Management.Migration.MailboxReplication.MoveRequest.GetMoveRequestStatistics
+ PSComputerName : srv-exch2016.J'ai vu que le disque où se trouve la base de données était quasiment plein. J'ai donc ajouté de l'espace et relancé le serveur ; pas mieux.
En cherchant un peu, je vois aussi dans les logs les erreurs suivantes :
The Microsoft Exchange Mailbox Replication service was unable to process jobs in a mailbox database.
Database: 2016BDD01
Error: MapiExceptionMailboxQuarantined: Unable to open message store. (hr=0x80004005, ec=2611)
Diagnostic context:
Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=145]
Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=310][latency=0]
Lid: 52176 ClientVersion: 15.1.1847.1
Lid: 50032 ServerVersion: 15.1.1847.6001
Lid: 35180
Lid: 23226 --- ROP Parse Start ---
Lid: 27962 ROP: ropLogon [254]
Lid: 17082 ROP Error: 0xA33
Lid: 26937
Lid: 21921 StoreEc: 0xA33
Lid: 27962 ROP: ropExtendedError [250]
Lid: 1494 ---- Remote Context Beg ----
Lid: 50608
Lid: 32848 dwParam: 0x14
Lid: 61416 StoreEc: 0xA33
Lid: 56872 dwParam: 0xFE
Lid: 42712 StoreEc: 0xA33
Lid: 45434 Guid: 223ba1be-49d9-440c-be84-6096e67d948a
Lid: 10786 dwParam: 0x0 Msg: 15.01.1847.001:SRV-EXCH2016:6a48c489-daf3-4599-85f6-39ce8ac25d76
Lid: 1750 ---- Remote Context End ----
Lid: 27962 ROP: ropGetPropsSpecific [7]
Lid: 26881
Lid: 21817 ROP Failure: 0xA33
Lid: 46042 StoreEc: 0xA33
Lid: 32441
Lid: 1706 StoreEc: 0xA33
Lid: 24761
Lid: 20665 StoreEc: 0xA33
Lid: 25785
Lid: 29881 StoreEc: 0xA33J'ai trouvé des informations relatives à des mises en quarantaine de BAL lié à IIS ; j'ai regardé dans la base de registre, je n'ai aucune BAL en quarantaine.
J'ai vérifié l'état de la base avec eseutil /mh ; elle ne semble pas en mauvais état :
ATABASE HEADER:
Checksum Information:
Expected Checksum: 0x50eac6e0
Actual Checksum: 0x50eac6e0
Fields:
File Type: Database
Checksum: 0x50eac6e0
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,20,0 (attached by 0)
Engine ulVersion: 0x620,60,120 (efvCurrent = 9040)
Created ulVersion: 0x620,20
DB Signature: Create time:11/26/2019 16:17:18.382 Rand:3395983520 Computer:
cbDbPage: 32768
dbtime: 138627752 (0x8434aa8)
State: Clean Shutdown
Log Required: 0-0 (0x0-0x0)
Log Committed: 0-0 (0x0-0x0)
Log Recovering: 0 (0x0)
Log Consistent: 0 (0x0)
GenMax Creation: 00/00/1900 00:00:00.000 LOC
Shadowed: Yes
Last Objid: 13273
Scrub Dbtime: 0 (0x0)
Scrub Date: 00/00/1900 00:00:00.000 LOC
Repair Count: 0
Repair Date: 00/00/1900 00:00:00.000 LOC
Old Repair Count: 0
Last Consistent: (0x57FBE,1,3AC) 11/29/2019 13:17:58.611 UTC
Last Attach: (0x57FA5,2,268) 11/29/2019 08:55:58.196 UTC
Last Detach: (0x57FBE,1,3AC) 11/29/2019 13:17:58.611 UTC
Last ReAttach: (0x57FB9,2,268) 11/29/2019 12:17:17.528 UTC
Dbid: 1
Log Signature: Create time:11/26/2019 16:17:18.288 Rand:3257954905 Computer:
OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)
Previous Full Backup:
Log Gen: 196718-196823 (0x3006e-0x300d7) - OSSnapshot
Mark: (0x300D8,1,0)
Mark: 11/28/2019 21:00:27.371 UTC
Previous Incremental Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Previous Copy Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Previous Differential Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Current Full Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000 LOC
cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0
ECC Fix Success Count: none
Old ECC Fix Success Count: none
ECC Fix Error Count: none
Old ECC Fix Error Count: none
Bad Checksum Error Count: none
Old bad Checksum Error Count: none
Last Database Maintenance Finish Date: 00/00/1900 00:00:00.000 LOC
Current Database Maintenance Start Date: 11/26/2019 16:44:51.780 UTC
Highest Continuous Database Maintenance Page: 0
Highest Database Maintenance Page: 0
Database Header Flush Signature: Create time:11/29/2019 13:17:58.611 Rand:1087412944 Computer:
Flush Map Header Flush Signature: Create time:00/00/1900 00:00:00.000 Rand:0 Computer:
Operation completed successfully in 0.94 seconds.Actuellement :
- je peux lister les demandes de déplacement avec la commande get-moverequest ; elles sont toutes sur l'état InProgess
- par contre la commande Get-moverequest | Get-MoveRequestStatistics me renvoi l'erreur d'échec de communication pour toutes les BAL.
- Je ne peux pas suspendre les demandes de déplacement (toujours l'erreur de communication avec la base)
- Je ne peux pas supprimer les demandes de déplacement (idem)
Ma migration est bloquée et je ne sais plus quoi faire. Auriez vous une idée ?
Merci.
Réponses
-
Bonsoir,
à priori mon problème s'est résolu. Je pense que c'est lié au job de backup Veeam. En effet mon premier job de backup s'est déroulé le même soir où j'avais lancé mon lot de migration (avec le problème d'espace disque).
Hier soir, un nouveau job de backup s'est exécuté.
Ce soir, je peux à nouveau consulter l'état de mes jobs ; ils sont tous à 95% en attente de finalisation, paramétrée demain soir.
Je verrais demain si tout est fonctionnel.
Bonne soirée.- Proposé comme réponse F.ABASSI lundi 2 décembre 2019 10:00
- Marqué comme réponse Biliana Mouzaphirova mercredi 25 mars 2020 08:07