none
Database is mandatory on UserMailbox error during install of Hub Transport RRS feed

  • Question

  • I have one Exchange 2010 RC server up and running and able to login 2 user accounts.  I am ready to setup the 2nd Exchange server in the test lab.  This server is the same name as the one I created in Beta.  But now when I try to install this server, it fails on the hub transport with this database error.  I'm not sure what database it means as it is not specific.  Most of the posts I find refer to a specific database, which in this case it does not.  Any help would be appreciated. 

    Summary: 5 item(s). 1 succeeded, 1 failed.
    Elapsed time: 00:00:09


    Preparing Setup
    Completed

    Elapsed Time: 00:00:06


    Hub Transport Role
    Failed

    Error:
    The following error was generated when "$error.Clear(); if ( ($server -eq $null) -and ($RoleIsDatacenter -ne $true) ) { Update-RmsSharedIdentity -ServerName $RoleNetBIOSName }" was run: "Database is mandatory on UserMailbox. Property Name: Database".

    Database is mandatory on UserMailbox. Property Name: Database

    Elapsed Time: 00:00:03


    Client Access Role
    Cancelled

     


    Mailbox Role
    Cancelled

     


    Finalizing Setup
    Cancelled

     

     

    Wednesday, September 2, 2009 5:39 PM

All replies

  • Found a very strange situation with this one, but resolved it.  It appears that one user account, which I enabled the mailbox on through the EMC and assigned to the specific database on the one server I had up and running was causing the issue.  I have no idea why.  Once we removed that user, then the install of the hub transport on the 2nd server went fine.  We then readded the user and enabled his mailbox in the same again to see if it would do the same thing to the database properties.  

    So, after bringing up the 2nd server, we used ADSI Edit to look at the properties of the mailbox databases.  The homeMDBBL attribute that says CN=SystemMailbox.

    But the 1st server, after adding the user back and specifically assigning him to the 1st server's mailbox database changed this attribute to point to his CN, not the SystemMailbox, which is odd since there are 3 total users on that mailbox database now and because I used the wizard to enable his mailbox and assign him to this database, it changed the homeMDBBL attribute to his CN.  This is the way it was prior to deleting him from EMC and out of AD, so I think this is what caused the 2nd server not to install the hub transport correctly. 

    Since I don't know enough about Exchange to know if it should be this way or not, I'm just posting this finding out here in case anyone else runs into this problem.  But it sure would be nice to know why this is and why it would prevent you from installing the hub transport role on another server.  Thanks.

    Sandy
    Wednesday, September 2, 2009 8:10 PM
  • Hi Sandy same issue here ... how did you identify the user that made the problems and did you find away other then completely removing the user?

    CU Daniel
    Tuesday, September 8, 2009 10:12 PM
  • We used ADSI Edit and went to the mailbox database and looked at the object's attributes for the homeMDBBL attribute.  In that attribute it showed the CN= of the user that seemed to be our issue.  We had to remove the user completely and then we were able to continue with the install.  We put the user back after the install was completed, but it did change the attribute back, so I'm not sure that we'd be able to install another server if we needed to without removing the user again.  But since this is in our lab environment, we were able to do so.  If we were in production, we'd have a major problem with this type of solution, thus why I'm hoping Microsoft is monitoring these threads to know what they need to fix before RTM. 

    Sandy
    Wednesday, September 9, 2009 2:19 PM
  • Hi Sandy,

    I would like to share, what I did to get around the problem.

    I guess I came into this issue because I installed Exchange 2010 beta in a VM and then simply deleted the VM without uninstalling Exchange 2010 beta or cleaning my AD that sits on my lab server. When I installed the RC I got the above error message.

    What I did to resolve this:

    1) I downloaded the AD cmdlets for powershell from Quest here:
    http://www.quest.com/powershell/activeroles-server.aspx

    2) I played around with it and started to delete Exchange attributes on all accounts in my AD (I just have a couple of test user accounts in it so I didn't mind much, if something breaks). Using the AD cmdlets by Quest I used the following script to delete all Exchange attributes, that were attached to the users I had joined to the old Exchange 2010 beta. The script runs on ALL users and deletes attributes, so BEWARE.

    Here is the script:
    $userlist = Get-QADUser -IncludeAllProperties
    $userlist | ForEach { Set-QADUser $_ -ObjectAttributes @{msexchmailboxguid=''; msexchhomeservername=''; legacyexchangedn=''; mail=''; mailnickname=''; msexchmailboxsecuritydescriptor=''; msexchpoliciesincluded=''; msexchrecipientdisplaytype=''; msexchrecipienttypedetails=''; msexchumdtmfmap=''; msexchuseraccountcontrol=''; msexchversion='' } }

    msexchmailboxguid, msexchhomeservername and legacyexchangedn alone did not do the trick, so I added the rest that looked obviously like exchange and then the hub installation went through.

    Hope this helps. Maybe somebody from MSFT can comment which exact attribute caused the problem, and inform the product group to fix the issue.

    @Sandy, thx for your answer.

    CU Daniel


    • Proposed as answer by shuxclams Tuesday, December 22, 2009 10:58 PM
    Wednesday, September 9, 2009 6:59 PM
  • Thanks for your information too.  I did the same thing with VM and just wiped the server instead of cleaning up AD.  I do hope that Microsoft can comment on this issue because it will keep us from installing additional servers.  Once I added the user back and assigned them to a specific database, the issue was back on the attribute showing their CN, so I know it's not fixed by just deleting the attributes or the user. 

    Sandy
    Thursday, September 10, 2009 1:44 PM
  • it did this to me without any mailboxes. I wiped my beta config out of AD (had to use ADSI to get rid of it because I tried to migrate my mbx to a new server running the RC and it didn't like that hehe), installed Exchange 2010, realized I messed up something (forgot to delete the old Exchange 2010 beta security groups), uninstalled it, then did a reinstall and got this error the first time when i was installing the mailbox role, so i rebooted went into programs and features readded the mbx role and everything was fine. I haven't tested adding the hub transport or cas roles yet.
    Tuesday, September 22, 2009 9:28 PM
  • I think the cleanup in AD when you don't do a proper uninstall of a server is not documented very well.  I think you end up with remnants that cause these kinds of issues. 
    Wednesday, September 23, 2009 8:10 PM
  • I receive the same error "Database is mandatory on UserMailbox. Property Name: Database" when attempting to install additional Exchange 2010 RC mailbox server roles. I have one 2010 RC HUB/CAS/MAILBOX running just fine. I wanted to add more mailbox roles to setup a Database Availibility Group, kind of hard to do with one mailbox server! I'm attempting this install into an existing Exchange 2007 org with all servers running Exchange SP2. I was able to set this up in a completely new environment just to see if Exchange 2010 wasn't "broken" but in reality I need it to co-exist with 2007 & 2003 for migration purposes. I would think maybe something in AD is messed up but I'm not sure what. Any ideas & advise would be appreciated. Thanks!
    Tuesday, October 27, 2009 3:36 PM
  • I ran into the exact same issue under similar circumstances with Exchange 2010 RC.   I was using a VM to host Exchange 2010 and lost access to the Exchange Management Console.  Once you lose access you can't move mailboxes.  If you can't move mailboxes you can't do a clean uninstall of Exchange 2010.  If you delete the VM and Exchange 2010 Active Directory becomes a mess and won't allow any instance of Exchange 2010 to be installed.

    Does anyone have a definitive answer as to how to fix this?
    Monday, November 2, 2009 8:55 PM
  • Not sure if this is a 100% fix but I had exchange 2007 install, uninstalled and then installed 2010 on one server it would never mount a database, so I uninstalled it and created another server and it failed on the Hub Transport. I did the install over leaving ou the hub transport and everything worked once I got mailbox's setup I was able to reinstall the Hub Transport
    Tuesday, November 10, 2009 8:34 PM
  • The Quest scripts worked perfectly.
    Tuesday, December 22, 2009 10:57 PM
  • Lets bring this one back to the top.  Could really use some more info on how to handle this.
    Sunday, February 21, 2010 10:13 PM
  • Found this:

    http://www.paulbrown.us/2009/12/adding-a-mailbox-server-role-to-exchange-2010-database-is-mandatory-on-usermailbox/
    Monday, February 22, 2010 12:13 AM
  • Take a look at this article I had a very similar problem and this fixed it quickly

     

    http://support.microsoft.com/kb/978776


    Mitch Roberson |MCITP:Enterprise Server Admin, Messaging |MCTS:OCS with Voice Achievement |MCT |MCSE 2000\2003 |MCSE Messaging 2000\2003
    Monday, February 22, 2010 6:09 PM
  • Wrong post, sorry :(
    Friday, March 12, 2010 1:24 AM
  • I was able to get the Hub Transport installed with the same error by just installing all the other components first then going back and installing the Hub. I did follow http://support.microsoft.com/kb/978776 but it did not seem to resolve the issue but may have helped.
    • Proposed as answer by Zymotik Tuesday, September 27, 2011 10:42 AM
    Saturday, June 26, 2010 10:08 PM
  • I had the same error installing Exchange Server 2010 on Server 2008 R2.

    The article http://support.microsoft.com/kb/978776 did not do anything for me.  In fact if Exchange doesn't install you cannot add the mailbox back that it tells you to delete.  As it turns out, although it's not mentioned anywhere, you have to use the Exchange Console which doesn't get installed if Exchange is not installed.

    The process to install Exchange 2010 is rediculous.  I can't belive how many problems there are with the installation process.

    Now I'm left with a failed installation and an additional problem of the missing required Federated mailbox.

    Thanks a lot!

    Friday, July 23, 2010 3:56 AM
  • I had this issue:

     

    Error:

    The following error was generated when "$error.Clear(); if ( ($server -eq $null) -and ($RoleIsDatacenter -ne $true) ) { Update-RmsSharedIdentity -ServerName $RoleNetBIOSName }" was run: "Database is mandatory on UserMailbox. Property Name: Database".

    Database is mandatory on UserMailbox. Property Name: Database

    I also followed this article: http://support.microsoft.com/kb/978776

    when I ran "get-mailbox -arbitration" it showed me the two offending mailboxes, eg:

     

    SystemMailbox{1f05a927... SystemMailbox{1f0... <server name>          unlimited

    WARNING: The object <domain>/Users/SystemMailbox{1f05a927-f066-4323-953b-aae6bdc4460d} has been corrupted, and it's in an inconsistent state. The following validation errors happened:
    WARNING: Database is mandatory on UserMailbox.

    the solution was to delete both system mailboxes via ADSIedit, and when I ran setup again, it complained the mailbox didnt exist, so unlike in the article, I recreated it before running setup again, with the following command:

    New-Mailbox -Arbitration -Name FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 -UserPrincipalName FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042@<Default_Accepted_Domain>

    the setup then ran fine.

    the original problem was we couldn't mount any databases on the original Exchange 2010 server, so installed a second server, restored all data to it and then removed the first server and then readded it. the above error occured when trying to reinstalling Exchange on it.

    all sorted now. (also sorted out small problems with MSFTE.msi versioning (full text indexing / search engine) caused by Update 4 rollup)

    not very chuffed with Exchange 2010 installation steps failing left right and center. setup routines are very fragile it seems, especially with RTM / Update rollup changes.

     

     

    Monday, August 9, 2010 2:53 AM
  • @ Daniel Thanks for the Script, would have taken me hours to get it working. Had to remove all my exchange attributes after a cataclysmic failure of my server. Your script did the trick, got it up and running in no time! Thanks!
    Tuesday, January 18, 2011 4:03 PM
  • AWESOME!!!!!  i spent 20 hours trying to get this to work.  I ran the script from Daniel and it worked.  

    Thanks again!

    Tuesday, March 22, 2011 3:55 AM
  • I Just had my new install of 2010 exchange server crashed  restored it with a backup and I continue to receive this errors just on Mailbox role install. please help !!

     

     Summary: 3 item(s). 1 succeeded, 1 failed.

    Elapsed time: 00:00:04

     

     

    Preparing Setup

    Completed

     

    Elapsed Time: 00:00:00

     

     

    Mailbox Role

    Failed

     

    Error:

    The following error was generated when "$error.Clear(); 

              if (!$RoleIsDatacenter)

              {

                $arbUsers = @(get-user -Filter {lastname -eq "MSExchApproval 1f05a927-3be2-4fb9-aa03-b59fe3b56f4c"} -IgnoreDefaultScope -ResultSize 1);

                if ($arbUsers.Length -ne 0)

                {

                  $mbxname = $arbUsers[0].name;

                  $mbxs = @( get-mailbox -arbitration -Filter {name -eq $mbxname} -IgnoreDefaultScope -resultSize 1 );

                  if ( $mbxs.length -eq 0)

                  {

                    $dbs = @(get-MailboxDatabase -Server:$RoleFqdnOrName -DomainController $RoleDomainController);

                    if ($dbs.Length -ne 0)

                    {

                      enable-mailbox -Arbitration -identity $arbUsers[0] -database $dbs[0].Identity;

                    }

                  }

                }

              }

            " was run: "The user's Active Directory account must be logon-disabled for linked, shared, or resource mailbox.".

     

    The user's Active Directory account must be logon-disabled for linked, shared, or resource mailbox.

    Click here for help... http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.267.0&e=ms.exch.err.Ex88D115&l=0&cl=cp

     

    Elapsed Time: 00:00:03

     

     

    Finalizing Setup

    Cancelled

     

     

     

    Tuesday, April 5, 2011 12:35 PM
  •  Power shell commands do not work 
    Tuesday, April 5, 2011 12:37 PM
  • Hi Sandy,

    I would like to share, what I did to get around the problem.

    I guess I came into this issue because I installed Exchange 2010 beta in a VM and then simply deleted the VM without uninstalling Exchange 2010 beta or cleaning my AD that sits on my lab server. When I installed the RC I got the above error message.

    What I did to resolve this:

    1) I downloaded the AD cmdlets for powershell from Quest here:
    http://www.quest.com/powershell/activeroles-server.aspx

    2) I played around with it and started to delete Exchange attributes on all accounts in my AD (I just have a couple of test user accounts in it so I didn't mind much, if something breaks). Using the AD cmdlets by Quest I used the following script to delete all Exchange attributes, that were attached to the users I had joined to the old Exchange 2010 beta. The script runs on ALL users and deletes attributes, so BEWARE.

    Here is the script:
    $userlist = Get-QADUser -IncludeAllProperties
    $userlist | ForEach { Set-QADUser $_ -ObjectAttributes @{msexchmailboxguid=''; msexchhomeservername=''; legacyexchangedn=''; mail=''; mailnickname=''; msexchmailboxsecuritydescriptor=''; msexchpoliciesincluded=''; msexchrecipientdisplaytype=''; msexchrecipienttypedetails=''; msexchumdtmfmap=''; msexchuseraccountcontrol=''; msexchversion='' } }

    msexchmailboxguid, msexchhomeservername and legacyexchangedn alone did not do the trick, so I added the rest that looked obviously like exchange and then the hub installation went through.

    Hope this helps. Maybe somebody from MSFT can comment which exact attribute caused the problem, and inform the product group to fix the issue.

    @Sandy, thx for your answer.

    CU Daniel



    Hi Daniel

    As far as I can see - YOU are the best :-)

    Got the same issue while I was trying to upgrade to SP1 - on One server with All roles - thats great fun (NOT), when it fails...

    I have tryed alot before this -
    But the solution you came up with saved my day (and night), it got the job done - if your not an MVP allready - you should be by now...

    This is an (AUS) Allmost Unsearchable Solution - AND you make it quite simple - THANKS....

    In great respect, Morten

     


    • Proposed as answer by rahmat23 Wednesday, June 20, 2012 9:24 AM
    Monday, April 18, 2011 11:22 PM
  • follow the technet http://support.microsoft.com/kb/978776

    , you can recreate federated mailbox by running preparead running on DC as well

    Wednesday, June 8, 2011 2:56 PM
  • Hi Sandy,

    I would like to share, what I did to get around the problem.

    I guess I came into this issue because I installed Exchange 2010 beta in a VM and then simply deleted the VM without uninstalling Exchange 2010 beta or cleaning my AD that sits on my lab server. When I installed the RC I got the above error message.

    What I did to resolve this:

    1) I downloaded the AD cmdlets for powershell from Quest here:
    http://www.quest.com/powershell/activeroles-server.aspx

    2) I played around with it and started to delete Exchange attributes on all accounts in my AD (I just have a couple of test user accounts in it so I didn't mind much, if something breaks). Using the AD cmdlets by Quest I used the following script to delete all Exchange attributes, that were attached to the users I had joined to the old Exchange 2010 beta. The script runs on ALL users and deletes attributes, so BEWARE.

    Here is the script:
    $userlist = Get-QADUser -IncludeAllProperties
    $userlist | ForEach { Set-QADUser $_ -ObjectAttributes @{msexchmailboxguid=''; msexchhomeservername=''; legacyexchangedn=''; mail=''; mailnickname=''; msexchmailboxsecuritydescriptor=''; msexchpoliciesincluded=''; msexchrecipientdisplaytype=''; msexchrecipienttypedetails=''; msexchumdtmfmap=''; msexchuseraccountcontrol=''; msexchversion='' } }

    msexchmailboxguid, msexchhomeservername and legacyexchangedn alone did not do the trick, so I added the rest that looked obviously like exchange and then the hub installation went through.

    Hope this helps. Maybe somebody from MSFT can comment which exact attribute caused the problem, and inform the product group to fix the issue.

    @Sandy, thx for your answer.

    CU Daniel



    Daniel,

    I had the same problem and tried to run your script (after installing the quest commandlets on my DC).
    It also worked for me. So thanks for being such a great help.

    Cheers,
    Jan


    • Edited by Jan Schouls Sunday, September 11, 2011 7:08 PM
    Sunday, September 11, 2011 11:44 AM
  • Worked for me! Thanks
    Tuesday, September 27, 2011 10:42 AM
  • Hi Guys,

     

    This worked for me! BIG thanks! The only thing is to mention that the Federatedemail... account is created in SBS in the Mybusiness\Users\SBSUsers OU.

     

    KR,

     

    Tamas

    Tuesday, November 8, 2011 3:48 PM
  • Thank-you so much for this.

    My next fix was to throw the server in the creek and resign from the whole job!

    Wednesday, January 18, 2012 1:21 PM
  • Hi Daniel,

    Thanks a lot....

    Friday, May 11, 2012 12:22 PM
  • I have a fully installed Exchange 2003 server with about 100 users.  Will this script kill the users?
    Thursday, June 7, 2012 8:34 PM
  • very useful article, thank you for sharing

    Mights Make Rights

    Saturday, June 9, 2012 6:31 AM
  • LOOK FOR ALIAS EMAIL ADDRESSES ON THE USER ACCOUNTS.

    This script worked perfect.  I found that by removing and reattaching the mailboxes using this script does the trick because it removed all alias email addresses on the mailbox.  Before using this script try to locate all aliases on on the users' account and remove them first.   Then rerun the exchange installer.  Once complete re-add the alias email addresses. 

    If all else fails run this script then reattach the mailboxes.  Add the alias when your users start complaining about rejected emails. 

    Monday, June 3, 2013 6:37 PM
  • Hello Daniel,

    Thanks for the Script I had the same error installing a Exchange 2013 server as part of an upgrade from 2010.

    Downloaded the tools and run the script. Restarted the install and all worked fine

    Thanks again


    ------------------------------------------------------------ Ronald Bok - Network Engineer

    Saturday, June 8, 2013 7:57 PM
  • Hi,

    After removing FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 -UserPrincipalName FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042@<Default_Accepted_Domain>  using ADSIedit run setup /prepareAD. This will recreate this mailbox.

    Emil

    Tuesday, September 17, 2013 9:08 AM
  • Just wanted to say that I encountered the same "Database is mandatory" error. My problem was that I already had system mailboxes in my Users OU in Active Directory. I just went into Active Directory Users and Computers and deleted the accounts. I ran the setup wizard again and I didn't encounter the error. The system mailbox accounts looked like they were automatically generated by Exchange. I'm guessing they wound up there from a previous failed installation that I had to back out of, but for whatever reason Exchange Setup didn't remove the system accounts during the uninstall.
    Monday, June 16, 2014 4:49 PM
  • Just in case someone will need this in the future (hope not, but you never know!) 

    https://myrefspot.wordpress.com/2013/01/10/exchange-2010-server-recovery-failed-on-hub-transport-role/

    (basically there are two keys to remove form the registry -ALWAYS BACKUP YOUR REG KEYS BEFORE TAMPERING!-)

    Plus running ./setup /preparead from elevated PS session on exchange server. 

    That solved the problem with the hub transport.

    Hope that helps,

    Cheers

    Alessio 


    Monday, February 15, 2016 3:32 AM
  • Hi Sandy,

    I would like to share, what I did to get around the problem.

    I guess I came into this issue because I installed Exchange 2010 beta in a VM and then simply deleted the VM without uninstalling Exchange 2010 beta or cleaning my AD that sits on my lab server. When I installed the RC I got the above error message.

    What I did to resolve this:

    1) I downloaded the AD cmdlets for powershell from Quest here:
    http://www.quest.com/powershell/activeroles-server.aspx

    2) I played around with it and started to delete Exchange attributes on all accounts in my AD (I just have a couple of test user accounts in it so I didn't mind much, if something breaks). Using the AD cmdlets by Quest I used the following script to delete all Exchange attributes, that were attached to the users I had joined to the old Exchange 2010 beta. The script runs on ALL users and deletes attributes, so BEWARE.

    Here is the script:
    $userlist = Get-QADUser -IncludeAllProperties
    $userlist | ForEach { Set-QADUser $_ -ObjectAttributes @{msexchmailboxguid=''; msexchhomeservername=''; legacyexchangedn=''; mail=''; mailnickname=''; msexchmailboxsecuritydescriptor=''; msexchpoliciesincluded=''; msexchrecipientdisplaytype=''; msexchrecipienttypedetails=''; msexchumdtmfmap=''; msexchuseraccountcontrol=''; msexchversion='' } }

    msexchmailboxguid, msexchhomeservername and legacyexchangedn alone did not do the trick, so I added the rest that looked obviously like exchange and then the hub installation went through.

    Hope this helps. Maybe somebody from MSFT can comment which exact attribute caused the problem, and inform the product group to fix the issue.

    @Sandy, thx for your answer.

    CU Daniel


    Worked like a Charm. Thx Daniel.

    And here is updated script version, which uses default AD PS cmdlets.

    $userlist = Get-ADUser -Filter *
    $userlist | ForEach { 
    Write-Host $_
    Set-ADUser -identity $_ -Clear "msexchmailboxguid","msexchhomeservername","legacyexchangedn","mail","mailnickname","msexchmailboxsecuritydescriptor","msexchpoliciesincluded","msexchrecipientdisplaytype","msexchrecipienttypedetails","msexchumdtmfmap","msexchuseraccountcontrol","msexchversion"
    }

    Wednesday, April 18, 2018 10:07 AM