Cependant, si vous essayez de monter une base de données démontée, il peut y avoir deux scénarios : la base de données sera montée avec succès ou échouera avec une erreur, telle que :<\/p>
Le montage d’une base de données Exchange peut échouer pour plusieurs raisons, comme indiqué ci-dessous :<\/p> Si les journaux sont manquants ou supprimés avant que les modifications du journal ne soient validées dans la base de données, celle-ci peut devenir incohérente (Dirty Shutdown<\/strong>) et être démontée. Une telle base de données ne peut pas être montée à moins que les journaux soient validés dans la base de données ou que la base de données soit dans un état d’arrêt propre<\/strong>. Si vous essayez de forcer le montage, vous risquez d’échouer et d’obtenir un message d’erreur.<\/p> Pour corriger l’erreur Unable to Mount Database (hr=0x80004005, ec=1108) dans Exchange Server, vous pouvez suivre les solutions suivantes dans l’ordre indiqué.<\/p> Créez une copie de sauvegarde de la base de données avec les journaux des transactions. Cette étape est essentielle pour éviter une perte de données permanente tout en réparant les causes de l’erreur Unable to Mount Database (hr=0x80004005, ec=1108).<\/p> Vérifiez le support de stockage où sont stockés la base de données et les journaux de transactions. Le disque doit disposer d’au moins 25 % de stockage libre pour stocker davantage de journaux et de modifications de la base de données. Toutefois, si le stockage est faible, vous pouvez effectuer l’une des actions suivantes pour résoudre le problème “Impossible de monter la base de données” (hr=0x80004005, ec=1108) et monter la base de données.<\/p> Une fois que vous avez suffisamment d’espace libre, essayez de monter la base de données en utilisant la cmdlet Mount-Database <\/strong>dans Exchange Management Shell.<\/p> Si cela échoue, vous pouvez utiliser le paramètre -AcceptDataLoss pour monter la base de données en supprimant les éléments ou les changements non engagés de la base de données. Cela peut entraîner la disparition d’éléments ou de boîtes aux lettres. N’utilisez ce paramètre que lorsque vous avez créé une sauvegarde de la base de données et à vos risques et périls.<\/p> Vérifiez ensuite l’état, en utilisant la commande suivante<\/p> Si la base de données n’a pas été montée, suivez ces étapes pour démarrer ou redémarrer les services Microsoft Exchange requis.<\/p> OK<\/strong>.<\/p> Une fois ces services démarrés\/redémarrés, essayez de monter la base de données à l’aide du cmdlet Mount-Database. Vous pouvez également utiliser Exchange Admin Center pour monter la base de données.<\/p> Toutefois, si l’erreur “Impossible de monter la base de données (hr=0x80004005, ec=1108)” persiste, vous devrez peut-être vérifier la santé de la base de données et la réparer ou la restaurer, comme indiqué dans les étapes suivantes.<\/p> Pour vérifier l’état de la base de données, vous pouvez utiliser EseUtil – un outil de ligne de commande intégré pour vérifier, récupérer et défragmenter la base de données Exchange. Vous pouvez utiliser la commande EseUtil suivante dans la fenêtre d’invite de commande élevée ou dans EMS pour vérifier l’état de la base de données.<\/p> Par exemple,<\/p> Si la sortie indique que l’état de la base de données est Dirty Shutdown, cela signifie que la base de données est soit incohérente en raison de journaux non validés, soit corrompue. Dans ce cas, vous devez récupérer ou réparer la base de données pour la ramener à un état d’arrêt propre<\/strong>.<\/p> Pour récupérer ou réparer une base de données corrompue, endommagée ou incohérente et la monter sans rencontrer l’erreur Unable to Mount Database (hr=0x80004005, ec=1108), vous pouvez utiliser l’EseUtil pour effectuer une récupération douce ou une récupération dure.<\/p> Dans le cas d’une restauration douce, les journaux des transactions non validées sont rejoués sur la base de données pour la ramener à un état cohérent (état d’arrêt propre). La récupération matérielle est nécessaire lorsque les journaux sont manquants\/supprimés.<\/p> Cependant, la récupération dure est un processus invasif qui récupère la base de données en supprimant les boîtes aux lettres ou les éléments irrécupérables. Au lieu de la récupération matérielle, nous vous recommandons d’utiliser le logiciel de récupération Exchange pour restaurer les boîtes aux lettres des utilisateurs de la base de données corrompue vers une base de données saine sur votre serveur Exchange.<\/p> Nous les avons examinés en détail ci-dessous.<\/p> Tout d’abord, vous devez exécuter la commande ci-dessous pour vérifier les journaux nécessaires à la récupération souple.<\/p> Une fois que vous avez vérifié les journaux et qu’aucun journal endommagé n’est trouvé, vous pouvez effectuer une récupération douce (EseUtil \/r<\/strong>) en exécutant la commande suivante. Le journal commence généralement par E00, E01, ou E02, etc.<\/p> Cela lancera le processus de récupération. Selon la taille et les dommages subis par la base de données, le processus prendra un certain temps. Une fois qu’il est terminé, vous devez relancer la commande Eseutil \/mhmhCommande pour vérifier l’état de la base de données. Si la récupération a réussi, l’état de la base de données devrait être Clean Shutdown<\/strong>.<\/p> Une fois que la base de données est dans un état d’arrêt propre, elle peut être facilement montée sur le serveur Exchange en utilisant la cmdlet Mount-Database dans EMS ou Exchange Admin Center.<\/p> Cependant, si l’état Dirty Shutdown persiste, vous avez deux options :<\/p> Encore une fois, si vous effectuez une récupération dure, vous devez accepter la perte de données car le processus purge les données endommagées, quelle que soit leur quantité. En revanche, après avoir effectué ce processus, Microsoft ne vous aidera pas. En effet, lorsqu’une base de données est récupérée à l’aide de la récupération dure, certaines informations sont codées en dur. Lorsque Microsoft s’en aperçoit, il refuse de fournir une assistance.<\/p> Pour effectuer la récupération dure, exécutez la commande ci-dessous :<\/p> Une fois exécuté, vous serez averti de la perte de données et devrez l’accepter avant de<\/p> poursuivre. Cette récupération doit être utilisée en dernier recours.<\/p> Une fois fait, vous obtiendrez un écran comme celui ci-dessous.<\/p> Vous devrez exécuter la commande EseUtil \/MH <\/strong>pour voir si l’état de la base de données est sain (Clean Shutdown). Si la base de données est saine, vous devriez être en mesure de monter la base de données et de corriger l’erreur ‘Unable to Mount Database (hr=0x80004005, ec=1108)’.<\/p> La solution manuelle ci-dessus prendra un temps considérable sans savoir si elle résoudra le problème avec succès. Il est également déconseillé d’effectuer une récupération dure, car cela entraînerait une perte de données irréversible et un codage dur de la base de données, ce qui vous priverait de toute assistance de la part de Microsoft. Heureusement, il existe une solution facile. Vous pouvez utiliser l’un des meilleurs logiciels de récupération Exchange<\/a><\/strong> – Stellar Repair for Exchange, pour restaurer les boîtes aux lettres des utilisateurs.<\/p> Tout ce que vous avez à faire est de créer une nouvelle base de données sur votre serveur Exchange. Ensuite, réparez la base de données endommagée et exportez les boîtes aux lettres vers la nouvelle base de données sur votre serveur directement à l’aide de Stellar Repair for Exchange avec une intégrité complète. Cette solution vous permet de restaurer le service à temps, sans processus de récupération complexe. En outre, vous pouvez également enregistrer ces boîtes aux lettres sous forme de fichiers PST individuels ou les exporter vers le locataire Office 365.<\/p>\n","protected":false},"excerpt":{"rendered":"Impossible de monter la base de données que vous avez spécifiée. Base de données spécifiée : MBX-DB-2016 ; Code d'erreur : Une opération Active Manager a échoué. Erreur : L'action de la base de données a échoué. Erreur : L'opération a échoué avec le message : MapiExceptionDatabaseError : Impossible de monter la base de données. (hr=0x80004005, ec=1108) Contexte de diagnostic : Lid : 65256 Lid : 10722 StoreEc : 0x454 Lid : 1494 -- Contexte distant Beg -- Lid : 45120 dwParam : 0x569817 Lid : 57728 dwParam : 0x56995F Lid : 46144 dwParam : 0x569A97 Lid : 34880 dwParam : 0x569A97 Lid : 34760 StoreEc : 0xFFFFFE0B Lid : 46144 dwParam : 0x56A13F Lid : 34880 dwParam : 0x56A13F Lid : 54472 StoreEc : 0x1388 Lid : 42184 StoreEc : 0x454 Lid : 1750 -- Remote Context End -- Lid : 1047 StoreEc : 0x454 [Database : MBX-DB- 2016, Server : mail.abc.com]<\/code><\/p>![\"Impossible](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/09\/Couldnt-mount-the-database-that-you-specified.png\")
<\/figure>\n<\/div><\/a>Raisons de l’erreur Impossible de monter la base de données (hr=0x80004005, ec=1108)<\/h2>
\n
\n
\n
\n
<\/a>Étapes à suivre pour corriger l’erreur Impossible de monter la base de données (hr=0x80004005, ec=1108)<\/h2>
<\/a>Étape 1 : Sauvegarde de la base de données<\/h3>
<\/a>Étape 2 : Vérifiez le stockage<\/h3>
\n
Mount-Database –Identity<\/code><\/p>Mount-Database -Identity < DatabaseName> -AcceptDataLoss<\/code><\/p>Get-MailboxDatabase -status | ft name,server,mounted<\/code><\/p>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/mount-database-acceptdataloss-parameter.bmp\")
<\/figure>\n<\/div><\/a>Étape 3 : Redémarrer les services Exchange<\/h3>
\n
\n
![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/restart-exchnage-services-to-mount-database.jpg\")
<\/figure>\n<\/div>\n
<\/a>Étape 4 : Vérifier l’état de la base de données<\/h3>
EseUtil \/mh <DatabasePath\/Databasename.edb><\/code><\/pre>Eseutil \/mh 'C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Mailbox\\MBXDB02\\MBXDB02.edb'.<\/code><\/p>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/check-the-database-state-using-eseutil-mh-command-768x427.jpg\")
<\/figure>\n<\/div><\/a>Étape 5 : Réparer la base de données Exchange<\/h3>
Étapes à suivre pour EseUtil Soft Recovery<\/h4>
eseutil \/ml <Log path location><\/code><\/p>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/check-the-log-files-health-status.bmp\")
<\/figure>\n<\/div>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/perfrom-soft-recovery-on-exchange-database-using0eseutil.bmp\")
<\/figure>\n<\/div>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/check-the-database-state-clean-shutdown-768x415.jpg\")
<\/figure>\n<\/div>\n
Eseutil \/P <Database file location full path><\/code><\/p>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/eseutil-hard-recovery-data-loss-warning.png\")
<\/figure>\n<\/div>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2022\/06\/performing-hard-recovery-on-exchange-database.png\")
<\/figure>\n<\/div>![\"\"](\"https:\/\/www.stellarinfo.com\/blog\/wp-content\/uploads\/2021\/12\/Download-French-windows.png\")
<\/a><\/figure>\n<\/div><\/a>En conclusion<\/h2>