Mailboxes are the normal delivery location for messages delivered within an organization. They contain messages, attachments, and other types of information that the user might have placed in the mailbox. Mailboxes, in turn, are stored in mailbox databases.

When you install a Mailbox server, Setup creates a default mailbox database. The default mailbox database is meant to be a starting point, and most Exchange organizations can benefit from having additional mailbox databases, especially as the number of users in the organization grows. Additional mailbox databases are created for many reasons, but the following reasons are the most common:

When you create a mailbox database, you can specify the following information:

Each mailbox database has a default offline address book (OAB). Microsoft Outlook 2007 and later clients access the default OAB and default public folder hierarchy on your organization’s Client Access servers. Exchange 2013 uses the mailbox provisioning load balancer to automatically select a database to use when you create or move a mailbox and do not explicitly specify the mailbox database to use. As the name implies, the purpose of the load balancer is to try to balance the workload across mailbox databases in the organization.

Although the load balancer uses multiple criteria to try to determine where a mailbox should be created or moved, the selection criteria does not take into account the proximity of the Mailbox server on which a database is stored to the computer or computers used by the user. Instead, the load balancer uses the Active Directory site where the mailbox task is being performed to determine which mailbox databases should be selected and only includes databases that are in the local site.

You can control the way automatic distribution works in several ways. You can temporarily or permanently exclude databases from the distribution process by using the -IsSuspendedFromProvisioning and -IsExcludedFromProvisioning parameters of the Set-MailboxDatabase cmdlet respectively. When either of these parameters is set to $True, Exchange excludes the related database from the automatic distribution process.

When selecting a database to use, the mailbox provisioning load balancer also checks the database management scopes of the administrator creating a mailbox. Database management scopes are part of the role-based access control (RBAC) permissions model and are a way to limit the databases administrators can view and manage.

If you create custom scopes, Exchange uses these scopes to select databases. Specifically, the load balancer only selects mailbox databases included in a scope applied to the administrator creating a mailbox. Therefore, if a database isn’t included in a scope applied to an administrator, the database won’t be selected for automatic distribution.

Automatic reseed, new for Exchange 2013, allows you to quickly restore database redundancy after a disk failure, database corruption event, or other event that requires a reseed of a database to recover operations. For automatic reseed to work, however, you must pre-provision one or more spare disks. These spare disks are then used during the automatic reseed to recover the database copy. Here’s how automatic reseed works:

To prepare spare volumes on a server, you must complete the following steps:

Consider the following scenario to see how this would work in practice:

You can identify the failure and automatic reseed tasks by reviewing the event logs. Related events are logged in the event logs under Applications and Services Logs > Microsoft > Exchange > High Availability and under Applications and Services Logs > Microsoft > Exchange >MailboxDatabaseFailureItems.

You can create mailbox databases by using the New Mailbox Database Wizard. The default database file path and default log folder path are set automatically to be the same as those used for other Exchange data.

Any new mailbox databases you create using the Exchange Admin Center are configured to use the mailbox provisioning load balancer by default. When you create mailbox databases using the Exchange Management Shell, you can set the –IsExcludedFromProvisioning parameter to $True to specify that the database should not be considered by the mailbox provisioning load balancer. Excluding a database from provisioning means new mailboxes are not automatically added to this database. Rather than excluding a database from provisioning, you can set the –IsSuspendedFromProvisioning parameter to $True to specify that a database temporarily not be considered by the mailbox provisioning load balancer. Keep in mind that whether you exclude or suspend a database from provisioning is semantics as in either case the database won’t be used for provisioning.

To create a mailbox database, complete the following steps:

Exchange Server 2013 Standard edition supports up to five databases. Exchange Server 2013 Enterprise edition supports up to 100 databases. However, if you install Exchange Server 2013 Enterprise edition but forget to enter the product key, the server runs in Trial mode and only supports up to five databases as well.

If you try to create more databases than are supported by your edition of Exchange, you’ll see an error stating that Exchange couldn’t mount the database. In the error details, you’ll also see a message stating MapiExceptionTooManyMountedDatabases: Unable To Mount Database (see Figure 3-3). You can resolve this problem on a server running Enterprise edition by reducing the number of databases on the server or simply creating the database on a different server. To resolve this problem on a server running a standard or trial edition of Exchange Server 2013, you can upgrade the server to Enterprise edition by completing these steps:

Figure 3-3. An error showing that Exchange Admin Center was unable to mount the new database.

In the Exchange Management Shell, you can create mailbox databases by using the New-MailboxDatabase cmdlet. New-MailboxDatabase cmdlet syntax and usage provides the syntax and usage.

Syntax
New-MailboxDatabase -Name DatabaseName -Server ServerName
[-EdbFilePath DbFilePath] [-LogFolderPath FolderPath] {AddtlParams}
{AddtlParams}
[-DomainController FullyQualifiedName][-IsExcludedFromProvisioning <$true
| $false}] [-IsSuspendedFromProvisioning <$true | $false>]
[-OfflineAddressBook OfflineAddressBook]
New-MailboxDatabase -Recovery <$true | $false> -Server ServerName
[-DomainController FullyQualifiedName] [-EdbFilePath DbFilePath]
[-LogFolderPath FolderPath]

Usage
New-MailboxDatabase –Server "CorpServer88" –Name "Accounting Database"
-EdbFilePath "C:DatabasesAccountingAccountingMail.edb"
-LogFolderPath "D:DatabaseLogsAccounting"

Mailbox databases can have different types of information associated with them, including a default OAB. You set related options for mailbox databases by using the Client Settings page of the related Properties dialog box. To view this dialog box and update the messaging options, follow these steps:

In the Exchange Management Shell, you can set the default OAB for mailbox databases by using the Set-MailboxDatabase cmdlet. Using the Set-MailboxDatabase cmdlet to set the default OAB provides the syntax and usage.

Syntax
Set-MailboxDatabase –Identity MailboxDatabase
[-OfflineAddressBook OABIdentity

Usage
Set-MailboxDatabase –Identity "Accounting Mail"
-OfflineAddressBook "US Corporate"

Mailbox database limits are designed to control the amount of information that users can store in their mailboxes. Users who exceed the designated limits might receive warning messages and might be subject to certain restrictions, such as the inability to send messages. Deleted item retention is designed to ensure that messages and mailboxes that might be needed in the future aren’t deleted inadvertently. If retention is turned on, you can retain deleted messages and mailboxes for a specified period before they are permanently deleted and are nonrecoverable.

An average retention period for messages is about 14 days. The minimum retention period for mailboxes should be about 7 days. In most cases, you’ll want deleted messages to be maintained for a minimum of 5 to 7 days and deleted mailboxes to be maintained for a minimum of three to four weeks. An interval of 5 to 7 days is used for messages because users usually realize within a few days that they shouldn’t have deleted a message. A three-week to four-week interval is used for mailboxes because several weeks can (and often do) pass before users realize that they need a deleted mailbox or messages within a deleted mailbox. To understand why, consider the following scenario.

Sally leaves the company. A coworker is given permission to delete Sally’s user account and mailbox. Three weeks later, Sally’s boss realizes that she was the only person who received and archived the monthly reports sent through email from corporate headquarters. The only way to get reports for previous years is to recover Sally’s mailbox, and you can do this if you’ve set a sufficiently long retention period.

To view or set limits and deletion retention for a mailbox database, follow these steps:

In the Exchange Management Shell, you can set limits for mailbox databases by using the Set-MailboxDatabase cmdlet. Using the Set-MailboxDatabase cmdlet to set limits provides the syntax and usage. When you set a limit, you can specify the value with KB (for kilobytes), MB (for megabytes), or GB (for gigabytes). The default value type is bytes. Additionally, it’s important to point out that the -MaintenanceSchedule and -QuotaNotificationSchedule parameters are not used with Exchange 2013.

Syntax
Set-MailboxDatabase [-Identity MailboxDatabase]
[-AllowFileRestore <$true | $false>] [-BackgroundDatabaseMaintenence <$true
| $false>] [-CircularLoggingEnabled <$true | $false>]
[-DataMoveReplicationConstraint <None | SecondyCopy | SecondDatacenter |
AllDatacenters | AllCopies>] [-DeletedItemRetention NumberDays]
[-DomainController DCName] [-EventHistoryRetentionPeriod NumberDays]
[-IndexEnabled <$true | $false>] [-IsExcludedFromProvisioning <$true |
$false>] [-IssueWarningQuota Limit] [-JournalRecipient RecipientId]
[-MailboxRetention NumberDays] [-MountAtStartup <$true | $false>]
[-Name Name] [-OfflineAddressBook OABId] [-ProhibitSendQuota Limit]
[-ProhibitSendReceiveQuota Limit] [-RecoverableItemsQuota Limit]
[-RecoverableItemsWarningQuota Limit]
[-RetainDeletedItemsUntilBackup <$true | $false>]

Usage
Set-MailboxDatabase –Identity "Accounting Mail"
 -IssueWarningQuota 1.9GB
 -DeletedItemRetention 14
 -MailboxRetention 30
 -ProhibitSendQuota 2GB
 -ProhibitSendReceiveQuota 2.4GB
 -RetainDeletedItemsUntilBackup $true

When you delete a mailbox from a user account, the mailbox is retained as a disconnected mailbox according to the mailbox retention setting. You can reconnect the mailbox to the original user account or another user account if necessary. Similarly, when you delete a user account and the related mailbox, the mailbox is retained as a disconnected mailbox according to the mailbox retention setting. You can connect the mailbox to an existing user account if necessary.

When you move mailboxes between databases, mailboxes in the original (source) database are soft deleted. This means they are disconnected, marked as soft deleted, but retained in the original database until the deleted mailbox retention period expires. In Exchange Management Shell, you can use a DisconnectReason of “SoftDeleted” to find soft-deleted mailboxes.

To recover a deleted mailbox, complete the following steps:

You can use the Connect-Mailbox cmdlet to perform the same task following the syntax shown in Connect-Mailbox cmdlet syntax and usage.

Syntax
Connect-Mailbox -Identity OrigMailboxIdentity
-Database DatabaseIdentity
-User NewUserIdentity
[-ActiveSyncMailboxPolicy PolicyId] [-Alias Alias]
[-DomainController DCName] [-ManagedFolderMailboxPolicy PolicyId]
[-ManagedFolderMailboxPolicyAllowed <$true | $false>]
[-Archive <$true | $false>] [-Equipment <$true | $false>]
[-Room <$true | $false>] [-Shared <$true | $false>]
[-ValidateOnly <$true | $false>]
[-LinkedCredential Credential] [-LinkedDomainController DCName]
[-LinkedMasterAccount UserId]

Usage
Connect-Mailbox -Identity "Per Reitzel"
-Database "Accounting Mail" -User "CPANDLperr" -Alias "perr"
Connect-Mailbox -Identity "Per Reitzel"
-Database "Accounting Mail" –LinkedDomainController CorpServer72
-LinkedMasterAccount "CPANDLperr"

You can recover deleted items from mailbox databases as long as you’ve either set a deleted item retention period for the database from which the items were deleted and the retention period hasn’t expired, or you have specified that Exchange should not permanently delete items from mailboxes until the database has been backed up and Exchange hasn’t been backed up yet. If either of these conditions are met, you can recover deleted items from mailbox databases.

To use Outlook 2010 or Outlook 2013 for recovery, complete the following steps:

To use Outlook Web App (OWA) for recovery, complete these steps:

After you create a database availability group and add Mailbox servers to the group, you can create copies of mailbox databases to initiate replication. Within the group, replication occurs between the active mailbox database on a source Mailbox server and other Mailbox servers that host copies of the database. You cannot replicate a database outside of a database availability group, nor can you replicate an Exchange 2013 mailbox database to a server running an earlier version of Exchange.

Each database availability group can have up to 16 member servers, and you can create up to 16 instances of a database, including one active instance and 15 passive instances. You can create mailbox database copies only on Mailbox servers that do not host the active copy of a mailbox database, and you cannot create two copies of the same database on the same server.

Because all copies of a database use the same path on each server containing a copy, the database and log file paths for a database copy on each Mailbox server must not conflict with any other database paths. You need to ensure the database and log file paths for the database copy can be created in the same location as all other copies and that the paths do not conflict with any other database paths on the target server.

With respect to Active Directory, the member servers in an availability group must all be in the same Active Directory domain. You can create database copies on Mailbox servers in the same or different Active Directory Sites, and on the same or different network subnets. However, database copies are not supported between Mailbox servers with roundtrip network latency greater than 250 milliseconds (by default). Database copies are automatically assigned an identity in the format DatabaseNameHostMailboxServerName, such as Engineering Primary DatabaseMailServer36.

To create a copy of a mailbox database, complete the following steps:

In the Exchange Management Shell, you can create mailbox database copies by using the Add-MailboxDatabaseCopy cmdlet. Add-MailboxDatabaseCopy cmdlet syntax and usage provides the syntax and usage. Use the –ReplayLagTime parameter to specify how long the Exchange Replication Service should wait before replaying log files. Use the –TruncationLagTime parameter to specify how long the Exchange Replication Service should wait before truncating logs that have been replayed.

Syntax
Add-MailboxDatabaseCopy -Identity SourceDatabase
-MailboxServer TargetServer [-ActivationPreference PrefValue]
[-ReplayLagTime Days.Hours:Minutes:Seconds]
[-SeedingPostponed <$true | $false>]
[-TruncationLagTime Days.Hours:Minutes:Seconds]
[-DomainController FullyQualifiedName]

Usage
Add-MailboxDatabaseCopy -Identity "Engineering Primary Database"
-MailboxServer "MailServer36" -ReplayLagTime 00:03:00
-TruncationLagTime 00:10:00 -ActivationPreference 2

Replay and truncation values are designed to let you fine-tune the way replication works for each database copy. Replay lag time is the amount of time to delay log replay. Truncation lag time is the amount of time that you want to delay log truncation after a log has been successfully replayed. You can also set a relative preference value for database copies. The preference value sets the order of activation preference after a failure or outage affecting the active database, with a value of 1 indicating the highest preference, a value of 2 the next highest preference, and so on. You cannot set a database copy to a value higher than the number of database copies. Active Manager uses the preference value in the case of a tie during the best-copy selection process.

To set preference values for a database copy, complete the following steps:

In the Exchange Management Shell, you can set replay, truncation, and preference values for mailbox database copies by using the Set-MailboxDatabaseCopy cmdlet. Set-MailboxDatabaseCopy cmdlet syntax and usage provides the syntax and usage.

Syntax
Set-MailboxDatabaseCopy -Identity DatabaseServer
[-ActivationPreference PrefValue]
[-ReplayLagTime Days.Hours:Minutes:Seconds]
[-TruncationLagTime Days.Hours:Minutes:Seconds]
[-DomainController FullyQualifiedName]

Usage
Set-MailboxDatabaseCopy -Identity "Tech Mail DatabaseMailServer36"
-ReplayLagTime 00:02:00 -TruncationLagTime 00:05:00
-ActivationPreference 6

In Exchange 2013, lagged copies automatically play down log files as necessary to accommodate adverse conditions, such as the following:

However, you must enable these options specifically. You enable lagged copy replay for all lagged copies in a particular database availability group by using the following command:

Set-DatabaseAvailabilityGroup DAGName -ReplayLagManagerEnabled $true

DAGName is the name of the database availability group to configure.

You specify the low diskspace threshold as a percentage of free disk space before log replay occurs by using the registry value:

For example, if you want Exchange to automatically play down lagged copies when the free disk space on the volume used by the active database reaches 10 percent, you’d edit the ReplayLagPlayDownPercentDiskFreeSpace value in the registry and set it to 10.

You specify the number of available healthy copies that triggers replay by using the following registry value:

By default, this value is set to 3, meaning replay is triggered whenever there are fewer than 3 copies of a database available for a 24-hour period. Although this value may work well in large deployments of Exchange, this value is not ideal for small deployments. Specifically, in deployments in which you have three or fewer Mailbox servers in a DAG, setting this value to 3 will cause lagged logs to play down every 24 hours whether you want them to or not.

As part of planned maintenance or for other reasons, it might be necessary to temporarily suspend replication activity for a database copy. In addition, prior to performing some administrative tasks, you need to suspend replication activity before you can complete the task—for example, before performing seeding. You can suspend and resume database copy activity by completing the following steps:

To resume replication later, tap or click Resume. If a suspend comment was provided, you can read the comment. Then tap or click Yes to resume continuous replication.

In the Exchange Management Shell, you can suspend and resume replication by using Suspend-MailboxDatabaseCopy and Resume-MailboxDatabaseCopy, respectively. Suspend-MailboxDatabaseCopy cmdlet syntax and usage and Resume-MailboxDatabaseCopy cmdlet syntax and usage provide the syntax and usage. If you only suspend activation by using the –ActivationOnly parameter, the database cannot be activated until you resume replication without specifying the –ReplicationOnly parameter. The –ReplicationOnly parameter resumes replication without affecting the activation setting. For example, if the –ActivationSuspended parameter was set to $True, the parameter remains set to $True.

Syntax
Suspend-MailboxDatabaseCopy -Identity DatabaseServer
[-ActivationOnly <$true | $false>] [-EnableReplayLag <$true | $false>]
[-DomainController FullyQualifiedName]
[-SuspendComment Comment]

Usage
Suspend-MailboxDatabaseCopy -Identity "Tech Mail DatabaseMailServer36"
-ActivationOnly

Syntax
Resume-MailboxDatabaseCopy -Identity DatabaseServer
[-DisableReplayLag <$true | $false>] [-DisableReplayLagReason "Comment"]
[-ReplicationOnly <$true | $false>] [-DomainController FullyQualifiedName]

Usage
Resume-MailboxDatabaseCopy -Identity "Tech Mail DatabaseMailServer36"

Lagged database copies have a replay lag time great than 0. You can activate a lagged copy by recovering the database copy from SafetyNet, by replaying all uncommitted log files, or by performing a point in time activation.

Before you activate a lagged copy, you may want to preserve the original files for the lagged copy. If so, you need to create a snapshot of the volumes containing the database copy and its log files by suspending replication of the lagged copy you want to activate, and then creating a shadow copy of these volumes as detailed in the steps that follow:

To recover a lagged copy from SafetyNet, complete the following steps:

To activate a lagged copy by replaying all uncommitted log files, complete the following steps:

To activate a lagged copy to a point in time, complete the following steps:

Seeding is the process of initially replicating an active or passive database into a database copy. This creates a baseline passive copy of a database. Normally, seeding occurs automatically, and the length of time required to completely seed a database depends on the size of the source database, the available bandwidth on the network, and the level of activity on the servers involved. However, automatic seeding can fail, and in this case, you then need to manually initiate seeding.

You can reseed a mailbox database copy anytime you suspect divergence has occurred. However, divergence isn’t necessarily a problem because incremental reseed (incremental resync) takes care of resolving the divergence. You would not need to do a full reseed except in circumstances in which resync isn’t possible—for example, when there is no overlap in log files between diverged copies, or when you’ve done something you shouldn’t have, like an offline defragmentation of a copy that causes uncorrectable divergence.

When you reseed a database, Exchange empties the database copy and replicates a new passive database copy. Typically, you won’t need to reseed database copies after the initial seeding has occurred; however, in some situations you might need to reseed a database copy. One state you can check for is the FailedAnd Suspended state. In this state, Exchange has detected a failure and suspended replication replay because resolution of the failure explicitly requires administrator intervention. For example, if Exchange detects an unrecoverable divergence between the active mailbox database and a database copy, Exchange marks the database copy as FailedAndSuspended. If an incremental resync doesn’t eventually resolve the problem, you need to resolve the underlying cause of the failure before the database copy can be transitioned to a healthy state, which includes reseeding the database.

Before you can seed or reseed a database, you must suspend replication. For very large databases—that is, those that are multiple terabytes (TB) in size—the preferred technique for seeding the initial passive copy of the database, if service level agreements allow or such an outage is acceptable, is to dismount the active copy of the database and copy the database file to the same location on the target Mailbox server in the same database availability group. Rather than copying the database over the network, which could take several days for a multiterabyte database, you should consider the following:

With this approach, the database will be unavailable until seeding is completed and you can mount the database. Alternatively, you can leave the active database online and use the Exchange Management tools to initiate the seeding process. After you’ve created at least one baseline passive copy of a database, you can seed new passive copies from the baseline passive copy at any time by using an online or offline approach.

The size of the database, the available network bandwidth, network latency, and the activity levels on the source and target servers determine how long an over-the-network transfer or update takes. After the seeding process has started, don’t close the Exchange Admin Center or Exchange Management Shell until the process has completed. If you do, the seeding operation will be terminated and will need to be restarted.

Keep the following in mind when you are considering updating database copies:

You can seed a database manually by completing the following steps:

To seed a database copy in the Exchange Management Shell, you use the Update-MailboxDatabaseCopy cmdlet. Update-MailboxDatabaseCopy cmdlet syntax and usage provides the syntax and usage. Use the –Force parameter when seeding programmatically, and you will not be prompted for administrative input.

Syntax
Update-MailboxDatabaseCopy -Identity DatabaseServer
-SourceServer ServerName [-CancelSeed <$true | $false>]
[-BeginSeed <$true | $false>] [-CatalogOnly <$true | $false>]
[-DatabaseOnly <$true | $false>] [-DeleteExistingFiles <$true | $false>]
[-DomainController FullyQualifiedName] [-Force <$true | $false>]
[-ManualResume <$true | $false>] [-MaximumSeedsInParallel MaxNumSeeds]
[-NetworkCompressionOverride {"UseDAGDefault"|"Off"|"On"}]
[-NetworkEncryptionOverride {"UseDAGDefault"|"Off"|"On"}]
[-Network NetworkID] [-SafeDeleteExistingFiles <$true | $false>]

Usage
Update-MailboxDatabaseCopy -Identity "CS MailMailServer25"
-CatalogOnly -Force
Update-MailboxDatabaseCopy -Identity "CS MailMailServer25"
-DatabaseOnly
Update-MailboxDatabaseCopy -Identity "CS MailMailServer25"
-Network "EastCampusDAG1Primary DAG Network"
-NetworkCompressionOverride "On" -NetworkEncryptionOverride "Off"

As an Exchange administrator, you need to monitor the health and status of database copies to ensure that they are available when needed. You can view key health and status information for a database copy by completing the following steps:

In the Exchange Management Shell, you can check the health and status of replication by using the Get-MailboxDatabaseCopyStatus cmdlet. Get-MailboxDatabaseCopyStatus cmdlet syntax and usage provides the syntax and usage.

Syntax
Get-MailboxDatabaseCopyStatus -Server ServerName {AddtlParams}
Get-MailboxDatabaseCopyStatus [-Identity LocalDatabaseName]
[-Active <$true | $false>] [-Local <$true | $false>]] {AddtlParams}
{AddtlParams}
[-ConnectionStatus <$true | $false>] [-DomainController FullyQualifiedName]
[-ExtendedErrorInfo <$true | $false>] [-UseServerCache <$true | $false>]

Usage
Get-MailboxDatabaseCopyStatus –Server "MailServer35"
-ConnectionStatus –ExtendedErrorInfo
Get-MailboxDatabaseCopyStatus
Get-MailboxDatabaseCopyStatus –Identity "Accounting Mail"

You can remove a passive database copy at any time by using the Exchange Management tools. After removing a database copy, you need to manually delete any database and transaction log files from the server.

To remove a database copy, complete the following steps:

In the Exchange Management Shell, you can remove a database copy by using the Remove-MailboxDatabaseCopy cmdlet. Remove-MailboxDatabaseCopy cmdlet syntax and usage provides the syntax and usage.

Syntax
Remove-MailboxDatabaseCopy -Identity DatabaseNameServerName]
[-DomainController FullyQualifiedName]

Usage
Remove-MailboxDatabaseCopy –Identity "CS Mail DatabaseMailServer24"

Before you remove a database using the shell, you may need to identify available copies of the database. To do this, enter the following command:

Get-MailboxDatabase DatabaseName | fl DatabaseCopies

Where DatabaseName is the name of the database you want to work with, such as:

Get-MailboxDatabase Development | fl databasecopies

As shown in this example, the output lists where copies of the database are available:

DatabaseCopies : {DevelopmentMAILSERVER42, DevelopmentMAILSERVER21}

You can only access databases that are mounted. If a database isn’t mounted, the database isn’t available for use. If a database isn’t mounted it means that an administrator has probably dismounted the database or that the drive on which the database is located isn’t online. It could also mean that the Exchange Information Store service is not running or that the drive, log drive, or both are online but out of disk space.

The Active Directory indicates that the database file
D:ExchsrvrmdbdataMarketing.edb exists for the Microsoft Exchange
Database; however, no such files exist on the disk.

Error 0xfffffb4d starting database Marketing on the Microsoft
Exchange Information Store.

Syntax
Get-MailboxDatabase [-Identity MailboxDatabase | -Server Server]
[-DomainController DCName] [-DumpsterStatistics <$true | $false>]
[-IncludePreExchange2013 <$true | $false>]
[-Status <$true | $false>] | format-table Name, Mounted, BackupInProgress,
BackgroundDatabaseMaintenance

Usage for specific database
Get-MailboxDatabase –Identity "Eng DB" –Status | format-table Name,
Mounted, BackupInProgress, BackgroundDatabaseMaintenance

Usage for all databases on a server
Get-MailboxDatabase –Server "CORPSVR127" –Status | format-table
Name, Mounted, BackupInProgress, BackgroundDatabaseMaintenance

 Usage for all databases
Get-MailboxDatabase –Status | format-table Name,
Mounted, BackupInProgress, BackgroundDatabaseMaintenance

Syntax
Dismount-Database –Identity DatabaseIdentity
[-DomainController FullyQualifiedName]
Mount-Database –Identity DatabaseIdentity
[-AcceptDataLoss <$true | $false>] [-DomainController FullyQualifiedName]
[-Force <$true | $false>]

Usage for dismounting a database
Dismount-Database –Identity "Eng DB"

Usage for mounting a database
Mount-Database –Identity "Eng DB"

Syntax
Set-MailboxDatabase –Identity DatabaseIdentity
 –MountAtStartup <$true | $false>

Usage
Set-MailboxDatabase –Identity "Eng DB"
 –MountAtStartup $false

You should run maintenance routines against databases on a daily basis. The maintenance routines organize the databases, clear out extra space, and perform other essential housekeeping tasks. By default, the automatic background maintenance does some of this work, and Exchange Server runs extended, foreground maintenance tasks daily from 1:00 A.M. to 5:00 A.M. If this conflicts with other scheduled administrative tasks or activities on the Exchange server, you can change the maintenance settings by following these steps:

In the Exchange Management Shell, you can configure the maintenance schedule for a database by using Set-MailboxDatabase. Setting the maintenance schedule provides the syntax and usage. In the example, replication is configured to occur between Friday at 9:00 P.M. and Monday at 1:00 A.M.

Syntax
Set-MailboxDatabase –Identity DatabaseIdentity
[–MaintenanceSchedule Schedule]
[-BackgroundDatabaseMaintenance <$true | $false>]

Usage
Set-MailboxDatabase –Identity "Eng DB"
 –MaintenanceSchedule "Fri.9:00 PM-Mon.1:00 AM"

As discussed earlier, each database has a database file associated with it, and the location of this file has an important role in managing Exchange Server performance. You can view the current file and folder paths the database is using by entering:

Get-MailboxDatabase DatabaseName | fl *path

DatabaseName is the name of the database to check, such as:

Get-MailboxDatabase "Engineering" | fl *path

In the command output, the database file path is listed as EdbFilePath, the log folder path is listed as LogFolderPath and any associated temporary data folder is listed under TemporaryDataFolderPath, as shown in this example:

EdbFilePath             : G:DatabasesEngineeringEngineering.edb
LogFolderPath           : H:LogsEngineering
TemporaryDataFolderPath :

In the Exchange Management Shell, you can move databases by using the Move-DatabasePath cmdlet. Move-DatabasePath cmdlet syntax and usage provides the syntax and usage. If the specified database is mounted, the database is automatically dismounted and then remounted, and it is unavailable to users while it’s dismounted. Additionally, you can perform a database move only while logged on to the affected Mailbox server, with one exception. If you are performing a configuration-only move, you can perform the configuration-only move from your management computer.

Syntax
Move-DatabasePath -Identity DatabaseIdentity
[-ConfigurationOnly <$true | $false>] [-EdbFilePath EdbFilePath]
[-DomainController DCName] [-Force <$true | $false>]
[-LogFolderPath FolderPath]

Usage
Move-DatabasePath -Identity "Engineering"
-EdbFilePath "K:DatabasesEngineeringEngineering.edb"
-LogFolderPath "L:LogsEngineering"

You cannot move a database that is being backed up or a replicated mailbox database. To move a replicated mailbox database, you must disable circular logging if enabled, remove all replicated copies, and then perform the move operation. After the move is complete, you can add copies of the mailbox database and re-enable circular logging. You’ll also want to rebuild the content indexes for each copy of the database. To perform these and other related tasks, complete the following steps:

After you’ve completed all these tasks, you should confirm that replication is working as expected by using the Get-MailboxDatabaseCopyStatus cmdlet. You also should use the Test-ReplicationHealth cmdlet to verify the health and status of the database availability group.

To rename a database, follow these steps:

In the Exchange Management Shell, you can rename databases by using the –Name parameter of the Set-MailboxDatabase. Renaming a database provides the syntax and usage.

Syntax
Set-MailboxDatabase –Identity DatabaseIdentity
 –Name NewName

Usage
Set-MailboxDatabase –Identity "Eng DB"
–Name "Engineering Mail Database"

Before deleting a mailbox database, you must delete or move the mailboxes it contains. After you’ve moved items that you might need and deleted items you don’t need, you can delete the database by completing the following steps:

In the Exchange Management Shell, you can delete databases by using the Remove-MailboxDatabase. Removing databases provides the syntax and usage.

Syntax
Remove-MailboxDatabase –Identity DatabaseIdentity
[-DomainController FullyQualifiedName]

Usage
Remove-MailboxDatabase –Identity "Eng DB"

Content indexing enables fast searches and lookups through server-stored mailboxes. Exchange Server 2013 uses the content indexing engine from the Microsoft Search Foundation. The Exchange Server storage engine automatically implements and manages Exchange Search. Exchange Search is used with searches for common key fields, such as message subjects. Users take advantage of Exchange Search every time they use the Find feature in Microsoft Office Outlook. With server-based mail folders, Exchange Search is used to quickly search To, From, Cc, and Subject fields. With public folders, Exchange Search is used to quickly search From and Subject fields.

As you probably know, users can perform advanced searches in Office Outlook as well. For example, in Outlook 2010, all users need to do is tap or click in the Search box or press Ctrl+E to access the Search tools, tap or click Search Options, and then tap or click Advanced Find. In the Advanced Find dialog box, users can enter their search parameters and then tap or click Find Now.

When Exchange Server receives an advanced query for personal folders, it searches through every message in every folder. This means that as Exchange mailboxes grow, so does the time it takes to complete an advanced search. With standard searching, Exchange Server is unable to search through message attachments.

With server-based folders, Exchange Server builds an index of all searchable text in a particular mailbox database before users try to search. The index can then be updated or rebuilt at a predefined interval. Then, when users perform advanced searches, they can quickly find any text within a document or attachment.

A drawback of content indexing is that it can be resource-intensive. As with any database, creating and maintaining indexes requires CPU time and system memory, which can affect Exchange performance. Full-text indexes also use disk space. A newly created index uses approximately 10 to 20 percent of the total size of the Exchange database (and is directly related to what’s in the database’s mailboxes). This means that a 1-TB database would have an index of about 100 to 200 GB.

Each time you update an index, the file space that the index uses increases. Don’t worry—only changes in the database are stored in the index updates. This means that the additional disk space usage is incremental. For example, if the original 1-TB database grew by 1 GB, the index could use up to 201 GB of disk space (up to 200 GB for the original index and 1 GB for the update).

Exchange Server 2013 doesn’t allow administrators to configure how indexing works. Full-text indexes are stored as part of the Exchange data files. Because of this, whatever folder location you use for Exchange data files will have an indexing subfolder, which contains all the Exchange Search data for the related database and all its related databases. By default, you’ll find full-text index files for a database in the %SystemDrive%Program FilesMicrosoftExchange ServerV15MailboxDatabaseNameGUID folder where GUID is the database’s globally unique identifier.

Each database has an index. If you make a database copy, you are also making an index copy. There’s often no need to rebuild an index. That said, as part of the recovery process for a mailbox database, you might want to rebuild the related full-text index catalog to ensure it’s current. You might also want to rebuild the full-text index after you’ve made substantial changes to a database or if you suspect the full-text index is corrupted.

You can rebuild an index manually at any time. Exchange Server rebuilds an index by recreating it. This means that Exchange Server takes a new snapshot of the database and uses this snapshot to build the index from scratch. To manually rebuild an index, enter the following commands to stop and then start the Exchange Search service:

Stop-Service MSExchangeFastSearch
Start-Service MSExchangeFastSearch

Exchange Discovery relies on Exchange Search for databases and mailboxes within databases. You can enable or disable indexing for individual databases by setting the -IndexEnabled parameter of the Set-MailboxDatabase cmdlet to $true or $false, respectively. The following example disables indexing of the Engineering database:

Set-MailboxDatabase "Engineering Database" -IndexEnabled $false

When you disable indexing of a database, you also prevent the Exchange 2013 Discovery feature from returning messages from the database or server.

You can disable indexing for all databases on a server by stopping and disabling the Microsoft Exchange Search service. Here’s an example using the Exchange Management Shell in which you stop and disable the Exchange Search service on a remote server named Server18:

Stop-Service MSExchangeFastSearch -ComputerName Server22
Set-Service MSExchangeFastSearch -StartupType Disabled -ComputerName Server22

You can enable indexing for all databases on a server by enabling the Microsoft Exchange Search service for automatic startup and starting the service. An example using the Exchange Management Shell follows:

Set-Service MSExchangeFastSearch -StartupType Automatic -ComputerName Server18
Start-Service MSExchangeFastSearch -ComputerName MailServer11

When you disable indexing on a server, you also prevent Exchange Discovery for all databases on the server.

You can quickly determine which databases have indexing enabled by using the following command:

Get-MailboxDatabase | ft Name,IndexEnabled

You can determine whether content indexing has a healthy status by using the following command:

Get-MailboxDatabaseCopyStatus | ft Identity, ActiveDatabaseCopy,
ContentIndexState -Auto

If you find that the context index for a passive database copy is outdated, you can rebuild or reseed the index. To reseed the index, enter the following command:

Update-MailboxDatabaseCopy -Identity DatabaseServer -CatalogOnly

Database is the name of the database and Server is the name of the server hosting the database, such as:

Update-MailboxDatabaseCopy -Identity EngineeringMailServer12 -CatalogOnly

If you need to troubleshoot Exchange Search issues, you can use Test-Exchange Search. When you use the -Server parameter to specify the name of a server to check, the cmdlet tests all mailbox databases on the server simultaneously. If the server is a member of a DAG and has a passive copy of a database, the test is automatically performed against the server that has the active database copy.