Automatic mailbox provisioning fails in Exchange 2013


Where has the time gone? Hard to believe it has been so long since my last post. I definitely need to change that pattern.

I wanted to share a recent experience I had that left me stumped for quite some time and which I just recently figured out the cause.

I was working on troubleshooting a problem with a Site Mailbox not being created (Site Mailboxes are that cool feature that combines email storage on Exchange and document library on SharePoint), and so I was trying to get some additional tracing from my lab, and noticed that Site mailboxes weren't getting created in my lab either. Funny, since I've had this lab running for the better part of 2 years, and it has always worked. After fixing a minor issue with the Site Mailbox provisioning which was due to a configuration issue with the autodiscover domain I had previously set up, I got to the point where the mailbox should have been provisioned, but it wasn't. Instead, I was presented with an error page indicating the following

The next thing I noticed was that I also couldn't create a mailbox using the Exchange tools (specifically, I was using the Exchange Management Shell). One never likes to see red come back from a Powershell command, and there it was. The same error as displayed by the attempt to create the Site Mailbox.

A value can't be provided automatically for the "Database" mandatory parameter. Specify an explicit value for the
parameter and try again, or add the Verbose parameter to obtain more information about the failure.
    + CategoryInfo          : NotSpecified: (:) [New-Mailbox], RecipientTaskException
    + FullyQualifiedErrorId : [Server=MYSERVER,RequestId=b37c727e-3473-4223-b9c3-32483c927aa3,TimeStamp=DateTime
  ] [FailureCategory=Cmdlet-RecipientTaskException] 50FA30F,Microsoft.Exchange.Management.RecipientTasks.NewMail
  box
    + PSComputerName        : myserver.mylab.com

My first thought was – oh great, maybe I'm running out of space, and the databases have the flag set to exclude from provisioning. That would totally make sense, right? See, starting with Exchange 2010, you didn't have to specify a mailbox database when you create a mailbox. Exchange would automatically select one for you. For mailboxes created with the Exchange management tools (EMC or EMS for 2010, EAC or EMS for 2013), you still have the option to specify a database if you wish, but for Site Mailboxes, this functionality is required because you have no way to specify a database when the mailbox is requested to be created from the SharePoint Site. Instead, it relies on the automatic mailbox provisioning.

Well, I checked every database on my servers, and found that none of them had the excluded from provisioning flags set.

Get-MailboxDatabase | fl name, *provision*

Here was the output from one database. The others matched. You can see from this that none of the provisioning flags to exclude the database from automatic provisioning of mailboxes were set to True.

Name                                        : e15db1
IsExcludedFromProvisioning                  : False
IsExcludedFromInitialProvisioning           : False
IsSuspendedFromProvisioning                 : False
IsExcludedFromProvisioningBySpaceMonitoring : False

Bummer! What else could cause this? Maybe the database weren't mounted? That could also cause this. I checked to make sure all the databases were mounted, and they were.

Get-MailboxDatabase -Status | fl name, *mount*

Name                  : e15db1
MountedOnServer       : Myserver
MountAtStartup        : True
Mounted               : True
AutoDatabaseMountDial : GoodAvailability

Again – each database was indeed mounted. Scratch that possibility. Hmm. Where to look next?

At Microsoft, in Support, we have access to some internal tools that are quite helpful. One of these is the Exchange Troubleshooting Assistant (ExTRA). This was first introduced as part of the Best Practices Analyzer family (ExBPA) with Exchange 2007, and although it no longer ships with Exchange 2013, it is still available to install if a Support Engineer needs to collect the diagnostic tracing that it offers. Although ExTRA can be installed and traces captured, the traces are stored in an ETL format, and in order to convert those traces to human readable output, an internal tool must be used.

Sooo…I captured a trace with what I thought would be relevant tags, converted it and reviewed the results. Needless to say, it wasn't very helpful in this case.

I next reviewed some of our source code relating to the particular error message. This was the proverbial needle in the haystack that I needed that led me to the solution.

What was the problem, you ask?

The "Mailbox Resources Management Agent" Cmdlet Extension Agent was disabled. I have no idea how it was disabled, but it was.

Take a look here for an explanation of what Cmdlet Extension Agents do.

http://technet.microsoft.com/en-us/library/dd335054(v=exchg.150).aspx

Specifically,

"in Exchange 2013, the New-Mailbox cmdlet invokes the Mailbox Resources Management agent when the cmdlet runs. If the Database parameter isn't specified, the Mailbox Resources Management agent automatically determines a suitable mailbox database on which to create the new mailbox and inserts that value into the Database parameter."

Aha! That perfectly explains why this wasn't working.

I enabled that cmdlet extension agent, and VOILA! Automatic mailbox provisioning began to work again, and creating the Site Mailbox also worked.


Comments (0)

Skip to main content