Exchange 2010 / Exchange 2013: Attempting to mount a new database results invalidOperationException

In Exchange 2010 and Exchange 2013 the process of mounting a database has changed since Exchange 2007.  In versions prior to Exchange 2010 the Information Store process on a server was solely responsible for tracking the creation of mailbox databases and performing mount and dismount operations.

 

In Exchange 2010 and newer the Active Manager process is now responsible for tracking the creation of mailbox databases and performing mount / dismount operations.  The Active Manager process works with the Information Store process to complete these requests.  Every server, both standalone and members of Database Availability Groups, have an Active Manager process.  This process runs within the Exchange Replication Service.

 

When administrators create a new mailbox database an entry is created in the database configuration container within Active Directory.  This will subsequently replicate to all other domain controllers.  Some administrators have noted that if you attempt to create a new database and immediately mount it – it fails with the following error:

 

[PS] C:\>Mount-Database test
Failed to mount database "test". Error: An Active Manager operation failed. Error: Couldn't find the specified mailbox
database with GUID '1a5e5284-a2d3-4241-a31a-fa0023fdc0e4'. [Database: Test, Server: MBX-3.domain.com]
+ CategoryInfo : InvalidOperation: (Test:ADObjectId) [Mount-Database], InvalidOperationException
+ FullyQualifiedErrorId : [Server=MBX-1,RequestId=8bcb44ca-f7cf-4594-81b9-1adb70b5cb95,TimeStamp=2/1/2015 3:47:30
PM] [FailureCategory=Cmdlet-InvalidOperationException] 19FDD999,Microsoft.Exchange.Management.SystemConfigurationT
asks.MountDatabase
+ PSComputerName : mbx-1.domain.com

 

This error may occur more often when creating a database and checking the mount this database option (checked by default).

 

 

 

When a mount command is issued the command is referred to the Active Manager process on the server.  In the case of a Database Availability Group the command is referred to the Primary Active Manager and then passed to the Replication Service of the node owning the active mailbox database copy.  The Replication Service then send a notification to the Information Store process to perform the mount.  In this instance the Replication Service is aware of the presence of the database, but the Information Store process is not.  This ultimately returns an error to the Replication Service which is subsequently returned to the administrative endpoint where the mount was issued (PowerShell / ECP).

 

After waiting a few minutes the database can be successfully mounted.  The wait time may be longer depending on the amount of time it takes domain controllers to successfully replicate the database object.

 

[PS] C:\>Mount-Database Test

[PS] C:\>Get-MailboxDatabase Test -Status | fl name,*mounted*

Name : Test
MountedOnServer : MBX-1.domain.com
Mounted : True

 

The same results may be observed when using the ECP.

 

*New database created but dismounted:

 

 

*Issue mount command on new database:

 

 

*Database verified as mounted.

 

 

In this time the Information Store process was made aware of the newly created database allowing for the mount request from the Replication Service to be processed successfully.

Comments

• Anonymous
  January 01, 2003
  @TubroMCP...
  
  As do most...
  
  TIMMCMIC
• Anonymous
  January 01, 2003
  @hotshot....
  
  Glad you found it helpful.
  
  TIMMCMIC
• Anonymous
  February 02, 2015
  Thanks
  saw that million times, ignored it and waited:)
• Anonymous
  March 27, 2015
  Nice, Thanks for sharing.
• Anonymous
  October 27, 2015
  Thanks ,it really helpful, it stuck me for few day.
• Anonymous
  February 15, 2016
  @Ricky:
  
  I'm glad that you found the information helpful. I removed your comment as it referenced a wholly unsupported method to recover a database. I would not want anyone to accidentally get confused by a comment and believe that this method of recovery was supported or that the data extracted using those tools were supported.
  
  TIMMCMIC
• Anonymous
  March 05, 2016
  @Christa...
  
  Thank you for reading. Your comment was removed as it contained a link to unsupported database recovery methods.
  
  TIMMCMIC