Installation Abort- Error while installing Exchange 2019 at step 7-Mailbox transport role

Question

This is a new installation of Exchange 2019 on a new separate windows Server 2019. the communication between the AD-DC server and the Exchange Server is established.

The pre-requisites are installed on the exchange server successfully:

• Unified Communications Managed API 4.0 Runtime
• Visual C++ 2012 Redistibutable X64
• IIS URL Rewrite Modul 2
• .NET Framework 4.8

(see PDF file1 attached)

Also The AD PrepareSchema and PrepareAD commands executed successfully and were verified in ADSIEdit

The installing admin is a member in the SchemAdmin, EnterpriseAdmin and ServerAdmin groups on the AD.

First attempted the installation with the latest Exchange 2019 CU12. the installation went on smooth until step7 (of13) where it aborted with error and Exit. Re-Install and Uninstall were not possible! So, the the Exchange Server entries were deleted by ADSIEdit and the changes were propagated between both servers. then, The windows server was completely re-installed from scratch. Then re-tried the Exchange installation anew this time however with CU10 yet have received the same error!

In the PDF file 2 attached l have copied the error message and the code the installer displayed when it aborted. Again, Repeating the installation or uninstallation are not possible. Stuck!

Can anyone help with a fix for this please? Thanks.

File 2- Error Exchange 2019 Installation.pdfFile 1- InstlleddPre-requisites.pdf

Answer 1

Hi @KF,

Based on the setup error message, it indicates that the issue is related to a mailbox object which doesn't have a Mailbox Database attribute valid value.

1. Please first check the ExchangeSetup.log under the ExchangeSetupLogs folder to determine the system mailbox where the problem occurs.
2. In Active Directory open Active Directory Users and Computes-> Users container-> Delete system mailbox users that reported the error in the setuplog.
3. Prepare AD again to generate new objects and restart setup. It should continue the installation and install the Mailbox Role.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

It seems like a permission issue. Would you try the solutions in the following links:

Exchange Server Troubleshooting: Unable to upgrade with error code '3221684229'

update Exchange 2016 to CU 9, update Mailbox Role Access Denied Error?

Exchange Service Pack or Rollup or Cumulative Update fails with error code '3221684229' and message 'Access is denied.'

Answer 3

Thank you so much Xuyan Ding for this valuable suggestion!. I have re-checked Active Directory for residual user names that were left over from repeated attempts to install Exchange. Before your suggestion, I had deleted all the entries belonging to the failed installations and in doing so, I had followed the instructions mentioned in the Link below:

https://social.technet.microsoft.com/Forums/windows/en-US/7ad33f2c-b34c-44d0-93bb-b71b2019f932/uninstallremove-exchange-2010-from-ad?forum=exchangesvrdeploylegacy

Yet that WAS/IS NOT sufficient to completely cleanse the Active Directory from the remains of the failed installations. Active Directory creates and retains some Usernames that are not related to the Actual users in the users containers. the internally created user names usually have username extensions encoded in B64 or Hexadecimal! and can be distinguished from the standard usernames. So if anyone experiences this problem during installation of Exchange 2019 (or even with Exchange 2016) , it is not enough to delete the Exchange Containers mentioned in the ADSIEdit link above, you need to look further for any internally created residual names whose properties are Exchange-related, then delete them. the goal is to have a completely clean AD containers free from any usernames that the process internally created them during the installation process.

Thanks gain and hopefully this ticket will help someone solve their similar problem.

Reagrds