Exchange includes a mailbox resources provisioning management agent whose purpose is to assign new mailboxes to available databases. This agent is one of the standard set of cmdlet extension agents. Its purpose is to look for new mailbox creation requests that do not specify a database in which the new mailbox should be created. When it detects such a request, the agent scans for all healthy databases within the same Active Directory site as the server or workstation on which EAC or EMS is running, omitting any databases that are explicitly marked to be excluded from provisioning on a permanent or temporary basis. A healthy database is one that is online and operational. The agent exhibits no great intelligence and selects a database for the new mailbox on a random basis from the set of available databases. If you want to create a mailbox for an account that belongs to a remote site, you should connect to a server on the site that you want to own the mailbox before you create it; else, the mailbox will be created in a database on the local site.
The mailbox resources provisioning management agent does not take the current number of mailboxes in a database into account when it selects a target database. If you allow Exchange to allocate mailboxes to available databases, expect to rebalance load from time to time by moving mailboxes around. You can find out just how many mailboxes are assigned to the different databases with a simple EMS command, albeit one that takes some time to complete in a large organization due to the need to contact every database to count the mailboxes:
Get-Mailbox | Group-Object database | Sort Count -Descending | Format-Table Count, Name –AutoSize
Equipped with this information, you can redistribute some mailboxes to the databases that are not heavily populated or suspend some databases from automatic provisioning so that they don’t accept new mailboxes. The easiest way to redistribute mailboxes is to create a migration batch of the mailboxes you want to move from one database to another and run the batch over the weekend so that the moves occur at a time of low system load.
When you use EAC to create a new mailbox and elect to enable Exchange to select the database to host the new mailbox (Figure 1), the only indication that a remote server is involved might be a slight delay when the new mailbox is created over what you’d expect when a mailbox is created locally.
Figure 1. Specifying a database for a new mailbox
Three flags are available to help you control the databases that are available for automatic provisioning. These are as follows:
- IsExcludedFromInitialProvisioning means that a database should be disregarded for provisioning on a very temporary basis. Setting this flag does not prevent Exchange from using the database to hold new mailboxes. It is strictly advisory. This property is new in Exchange 2013.
- IsSuspendedFromProvisioning also marks a database that is excluded from provisioning temporarily. However, if you set this property to $True, Exchange ignores the database when it creates new mailboxes.
- IsExcludedFromProvisioning means that a database is disregarded for provisioning on a more permanent basis. The intention is for you to use IsSuspendedFromProvisioning if you just want to stop new mailboxes from being created in a database for a reasonably small amount of time, say, up to half a day. Use IsExcludedFromProvisioning for longer periods. The difference between the two properties enables administrators to configure some granularity in the provisioning status of a database.
Exchange sets a similar property, called IsExcludedFromProvisioningBySpaceMonitoring, if the Managed Availability system detects that space is running out on the disk used to hold a database. You cannot set this property.
If either the IsExcludedFromProvisioning or IsSuspendedFromProvisioning flag is set to $True, the database is excluded from provisioning and remains in that state until both flags are reset to $False. Both flags have the same practical effect of stopping Exchange from using a database for provisioning. The difference between them is how long the provisioning block exists. Excluded means “never use this database for provisioning”; suspended means “don’t use this database for provisioning until I tell you it’s okay to do so.” The following explores how these circumstances might arise.
You might want to exclude a database from mailbox provisioning permanently if it is reserved for a particular purpose. For example, you might want to assign a database that has elevated quotas to a certain class of user or to users who belong to a particular department. You might also decide that automatic mailbox provisioning is a bad idea and that you’d prefer to assign new mailboxes to specific databases manually. In either case, you can use a command such as this to exclude the database from provisioning:
Set-MailboxDatabase –Identity 'VIP Mailboxes' –IsExcludedFromProvisioning $True
A temporary exclusion might be invoked when you know that a database should not be assigned new mailboxes for a period. For example, the database might be due to be moved to a new disk that allows it to grow, and you don’t want to add any more mailboxes until the new storage is available. In this case, you can block provisioning temporarily with a command like this:
Set-MailboxDatabase –Identity 'DB1' –IsSuspendedFromProvisioning $True
When you are ready to allow the database to be assigned new mailboxes on an automatic basis, you set the flag back to $False.
Set-MailboxDatabase –Identity 'DB1' –IsSuspendedFromProvisioning $False
Unlike many other properties that are stored in Active Directory, a change to a flag to suspend or include a database in automatic provisioning is immediately respected by the mailbox provisioning agent.
By default, new mailbox databases are added to automatic mailbox provisioning after they are created. Databases that are made available for automatic provisioning also become candidates for selection as targets for mailbox moves and personal archives if the locations for these operations are not specified by administrators. In other words, if you don’t specify a target database when you move a mailbox or create a personal archive for a mailbox, the mailbox provisioning agent will select a target from a list of available databases. My tests show that Exchange usually selects the same database as the primary mailbox to hold an archive, even if you don’t select a specific target database. I also found that if you issue a move request for a mailbox that has an archive, Mailbox Replication Service (MRS) will move the primary and archive mailboxes together to a target database that it automatically selects.
Troubleshooting A valid mailbox wasn’t found and mailbox creation failed
If you create new databases from EMS, you can specify that the database is excluded on a permanent or temporary basis by setting the flags previously described when you run the New-MailboxDatabase cmdlet. You can go too far and exclude all available databases from automatic provisioning. In this situation, you see the error shown in Figure 2 when the mailbox provisioning agent scans for databases and discovers that none are available.
Figure 2. No databases available for load balancing
The fix is simple. Either reset the flag on a database to make it available or go back and select a different database. An explicit selection of a database tells the mailbox provisioning agent that it doesn’t have to make a selection, so the error will be avoided.
The problem with using automatic assignment of mailboxes to databases rather than asking administrators to think about which database should host a new mailbox is that it ignores any consideration of with whom the owner of the new mailbox is likely to correspond. For years, it has been best practice to keep the mailboxes for people who share a common workgroup together in the same database to minimize the use of system resources to transport messages among members of the workgroup. Advances in technology have reduced the importance of this principle. The current Exchange database schema eliminated single-instance storage within databases, and Exchange 2007 began forcing all messages to move through the transport system, even when they are addressed to a recipient in the same database. Even so, it’s still good to consider mailbox placement from a wider perspective than a simple distribution across available mailboxes and retain some administrator involvement in the process instead of leaving everything for a computer to decide.