(For more resources related to this topic, see here.)

Creating and removing mailbox databases

To complete the following steps, you will need to launch the Exchange Management Shell or the Exchange Admin Center. For this example, the Mailbox Server where the new databases are created is configured with an additional disk (E:) that will be used to store the database and its logfiles. Despite earlier examples using multiple disks, we're sticking to a single disk in order to keep things simple. However, if you have stored your logfiles and database files on separate volumes, the same principles apply.

How to do it...

Creating a new mailbox database

To create a new mailbox database called MDB01 on server EX01, execute the following command:

New-MailboxDatabase –Name "MDB01" –Server "EX01.exblog.be" –LogFolderPath "E:MDB01Logs" –EdbFilePath "E:MDB01MDB01.edb"

Unlike the EAC, which offers you to choose whether or not to immediately mount the database, you will need to manually mount the new database after it is created. Have a look later in this article for more information on how to mount/dismount databases.

Exchange 2013 no longer dynamically adjusts the amount of memory that is assigned for each database's cache. How much memory is assigned per database depends on the amount of active and passive databases on the servers and is calculated when the Exchange Information Store service starts. That is also why you will see the following message whenever you add or remove a database or database copy to a server:

To restart the Exchange Information Store Service, run the following command from an elevated command prompt or PowerShell instance:

Restart-Service MSExchangeIS

Restarting the Exchange Information Store service will cause all databases on that server to be dismounted. If that server is not a member of a DAG or it is the sole server that contains a given database copy, that will result in downtime for the user while the service restarts.

Alternatively, the same action can be performed through the Exchange Admin Center:

1. Navigate to Servers | databases .
2. Click on the plus-sign ( + ) to launch the new database wizard. Enter a name for the database.
3. Click on browse... and select the Mailbox Server where you want to create the database.
4. Specify the EDB and logfile location.

   

5. Click on Save .

Removing a mailbox database

Before you can remove a mailbox database, it must not contain active mailboxes anymore. However, it is possible it still contains disconnected or deleted mailboxes that haven't been purged from the database yet. So before you can remove a database, you need to make sure that all mailboxes have been moved to another database. If you don't, you will get an error as shown in the following screenshot:

Before you can remove a mailbox database that has multiple database copies in a Database Availability Group, you need to remove the passive copies first. Only when the active database is the only copy that remains and it's empty, you will be able to permanently remove the database.

The following commands will move all mailboxes from database MDB01 to database MDB02, including any system mailboxes that might be hosted in MDB01:

Get-Mailbox –Database "MDB01" | New-MoveRequest –TargetDatabase "MDB02"


Get-Mailbox –Database "MDB01" -Arbitration | New-MoveRequest –TargetDatabase "MDB02"

Once you made sure that the database is empty, you can go ahead and remove the database using the following command:

Get-MailboxDatabase MDB01 | Remove-MailboxDatabase

Executing the command will remove the database from Exchange, but it will not remove the database files. You will have to manually delete the remaining files from the disk.

To remove a mailbox database through the EAC, execute the following steps:

1. Navigate to Servers | databases .
2. Select the database you want to remove and click on the garbage bin icon as shown in the following screenshot:

   

3. Click on Yes to confirm.

How it works...

Creating a mailbox database is in fact a pretty straightforward process. It suffices to provide a name, database - and log file path locations and let Exchange take care of the rest for you. When creating a new database, Exchange will first create an object in Active Directory and then create the EDB file along with the log stream and search catalog files in the locations that you specified earlier.

During the installation of Exchange 2013, several so-called arbitration mailboxes are created automatically. These mailboxes are used for system-related actions, such as distribution group moderation, federated delegation and system notification.

The following arbitration mailboxes are created by default and stored in the first (default) mailbox database:

• SystemMailbox {GUID}
• Migration.8f3e7716-2011-43e4-96b1-aba62d229136
• FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042

Make absolutely sure that you include these arbitration mailboxes when you are emptying a database before removal. If these mailboxes become unavailable or corrupt, one or more of Exchange's features might stop working. Luckily, Exchange helps you remembering and it won't let you remove a database unless it's considered empty and it's safe to remove it.

There's more...

When trying to physically remove the files immediately after having removed the mailbox database from Exchange, chances are that you will run into the error shown in the following screenshot:

Noderunner.exe is a child process of the Microsoft Exchange Search Host Controller service. In order to release the files from the noderunner.exe process, you can do any of the following:

1. Restart the Mailbox Server. Unless your server is part of a Database Availability Group and other servers have copies of the databases on this server, you will have to plan for a little downtime while the server is rebooting.
2. Restart HostControllerService on the Mailbox Server by executing following command from an elevated PowerShell console:

   
   Restart-Service HostControllerService
   

Mounting and dismounting mailbox databases

Although as an Exchange administrator, there shouldn't be many occasions on which you have to manually mount or dismount a database, sometimes you might be required to intervene because of an issue. The most common case is probably when a disk on which a database or logfiles are stored runs out of disk space. To protect the database, Exchange will automatically dismount the database. To recover from this situation, the administrator must free-up some space and manually re-mount the database. Therefore it's not only important to know how to perform these actions, but also to understand what's happening when they are executed.

Getting ready

In order to execute the following steps, you will need to log in to the Exchange Management Shell.

How to do it...

We will learn mounting and dismounting of database in this section.

Mounting a database

The following command will issue a mount-request for database MDB01:

Mount-Database "MDB01"

Dismounting a database:

Executing the following command will dismount the database MDB01:

Dismount-Database "MDB01"

How it works...

Before Exchange 2013, every database ran within the same process (store.exe) on the Mailbox Server. The introduction of the new Managed Store in Exchange 2013 changed things quite drastically, but for the better: every database is now running within its own process. This approach has some great advantages, such as whenever a database causes its worker process to hang, only a single database is affected whereas before all databases on the server would have suffered from the hanging process.

When taking a closer look at the new Managed Store, we can distinguish three important services:

• Store Service process
• Store Worker process
• Exchange Replication Service

The Exchange Replication Service could be seen as a sort of traffic control manager that provides a management interface for Exchange databases as it is responsible for issuing mount and dismount requests to the Store Service. Next to that, the Replication Service also keeps an eye on the state of a mailbox database and will, for instance, initiate a database failover when an issue with a database is reported.

For each mount request that is issued, the Exchange Store Service will create a new store worker process for the database being mounted.

Amongst other tasks, the store worker process itself is responsible for providing effective access to the database. When a database is mounted successfully, Event 3156 will be posted to the Application event log.

Subsequently, the store service will terminate the worker process for a database when a dismount request has been issued. During the dismount process, Exchange will set a flag in the database headers telling that it was cleanly dismounted (also referred to as a "clean shutdown"). If this flag isn't present, the database cannot be re-mounted without being repaired first. When a database is dismounted successfully, an Event 3161 will be posted to the Application event log.

There's more...

To know if and on what server a database is mounted, execute the following steps. Notice the use of the –Status parameter in the following command:

Get-MailboxDatabase –Status | Ft Name,*mount*

It is also possible to get a quick overview of the databases' status through the EAC. You can do so by navigating to Servers | databases .

Moving database files to another location

If you adequately sized your environment, including taking into account additional disk space for future growth, chances are that you'll never have to physically move a database to another location. However, sometimes lack of disk space, change of underlying storage subsystem or simply a change in the design of your environment might require you to move database file to another physical location.

Getting ready

To execute the following steps, launch the Exchange Management Shell. For more information on how to dismount a database have a look at Mounting/dismounting mailbox databases earlier in this article.

How to do it...

The following command will move the database files of a database called MDB01 to another location:

Move-DatabasePath –Identity "MDB01" –EdbFilePath "E:NewPathMDB01MDB01.edb" –LogFolderPath "E:NewPathMDB01Logs"

If you run the command while the database is mounted, the Exchange Management Shell will automatically throw a warning and ask for confirmation to dismount the database:

Dismounting a database will cause a temporary outage until the move has completed.

After the move has completed, Exchange will automatically re-mount the database.

There's more...

In some cases, you might prefer Exchange not to automatically move the physical files to their new location. This could be the case when you are using Mount Points in Windows Server. Mount Points can easily be reassigned to another location, without having to actually copy the data, therefore saving quite some time; especially when you are working with large databases.

Luckily, you can run the same command as before, only this time adding the –ConfigurationOnly parameter. The command will only update the database object's properties in Active Directory without physically moving the files' location:

Move-DatabasePath –Identity "MDB01" –EdbFilePath "E:NewPathMDB01MDB01.edb" –LogFolderPath "E:NewPathMDB01Logs" –ConfigurationOnly

If you use the –ConfigurationOnly parameter, make sure that you manually move/relocate the database files before attempting to mount it again. If you are working with Mount Points, now is the time you would change the mount point location.

Configuring circular logging

Circular logging is the process of truncating logfiles as soon as they have been committed into the database. Normally, logfiles are only truncated after a full back. This allows you to restore a database from an earlier time and replay the transactions up to the latest available one.

Normally there's no need to enable circular logging but it can come in handy to quickly free up some disk space; although we would prefer extending disk space for a full log drive over enabling circular logging. Another point of attention is that using circular logging comes at a cost, if you need to restore a database from an earlier point in time you won't be able to recover to the time when the database failed, inevitably leading to data loss.

That is also one of the reasons why Microsoft recommends only enabling circular logging when you have at least three additional database copies.

Getting ready

In order to execute the following steps, launch the Exchange Management Shell.

How to do it...

To enable circular logging for database MDB01, run the following command:

Set-MailboxDatabase "MDB01" –CircularLoggingEnabled $true

Similarly, the following command will turn off circular logging:

Set-MailboxDatabase "MDB01" –CircularLoggingEnabled $false

If you enable or disable circular logging for a single database copy, you will have to remount (dismount/mount) the mailbox database for the change to become effective. Databases that are part of a Database Availability Group and have multiple copies don't have to be remounted.

How it works...

Every action that a user performs, generates one (or more) database transactions. These transactions aren't immediately written to the database. Instead, as a safety-measure, these transactions get written into a logfile first. Only when transactions are safely written to a logfile, they are recorded in the database. Each logfile is 1MB in size. When a logfile fills up, a new one is automatically generated.

Transaction logs play an important role at maintaining the consistency of a database. For example, when the store worker process of one of the databases crashes, that database is not dismounted properly and thus it won't have the clean shutdown flag set. As a result, you won't be able to mount the database until it is brought back into a clean shutdown state.

Without going into too much detail, the process involved to bring a database back into a consistent state involves replaying logfiles and recording the (partial) transactions from those logfiles into the database. The transactions in the logfiles could be pretty much anything from a new e-mail that was received to a message's read status that has changed. If a logfile that needs to be replayed against the database isn't available, it essentially means that one or more (partial) transactions cannot be recorded and therefore results in data loss.

In large environments, each database can generate hundreds even thousands of logfiles each day and could end up using quite some disk space. Although it's not a recommendation, you can enable circular logging which will flush transaction logs as soon as the transactions have been recorded in the database. If you are running a DAG and your database has multiple copies, transaction logs will be flushed as soon as all database copies have recorded the transactions in the database. In case you have a lagged database copy, the logfile will be flushed from the active and passive database copies as soon as each has recorded the transactions into the database and the logfile has been inspected by the lagged copy.

Circular logging allows you to save on disk space that would otherwise be used to store the transaction logs. However, when a disaster strikes and you need to restore a database from backup, you will not be able to recover the latest transactions therefore losing data up to the latest backup. So, if you enable circular logging, make sure that you have multiple database copies running in a Database Availability Group; preferably at least three. The idea behind this is that the risk of losing three copies at once is relatively small. Just keep in mind that it's not impossible.

Creating and removing mailboxes

Creating mailboxes might be one of the simplest tasks within an Exchange environment. Even though the EAC wizard is relatively self-explanatory, there are some caveats to look out for. Especially the distinction between removing and disabling mailboxes might be confusing at first.

Getting ready

To execute the following steps, log in to the Exchange Admin Center or launch the Exchange Management Shell.

How to do it...

In this section we will learn how to create and remove mailboxes.

Creating a new user with mailbox

The following command will create a new user named Mark Sheffield and create a mailbox for that user:

New-Mailbox –UserPrincipalName Mark.Sheffield@exblog.be –Alias MSheffield –Database "MDB01" –Name "Mark Sheffield" –OrganizationalUnit "Users" –Password (Converto-Securestring –Asplaintext "P@ssw0rd" –Force) –Firstname "Mark" –LastName "Sheffield" –DisplayName "Mark Sheffield" –ResetPasswordOnNextLogon $true

In the example we just saw, some parameters are required, others aren't. If you aren't sure, you can have a look at the PowerShell help or you could just run New-Mailbox. If you haven't specified all required parameters, PowerShell will automatically query you for them.

Creating a new mailbox through the EAC is equally easy, just follow these steps:

1. Navigate to Recipients | Mailboxes .
2. Click on the plus-sign ( + ) to start the new mailbox wizard.
3. Click on New User and fill in the other fields, such as First Name , Last Name , and Display name .
4. Click on more options... to configure advanced options like:
   • In what database the mailbox should be created
   • Whether or not an archive should be created
   • What address book policy should be used
5. Click on Save to create the user.

Enabling a mailbox for an existing user

The following command will create a mailbox for an existing user named Kirk Jones:

Enable-Mailbox –Identity "Exblogkjones" –Database "MDB01"

To enable a mailbox for an existing user through the EAC refer the following steps:

1. Navigate to Recipients | Mailboxes .
2. Click on the plus-sign ( + ) to start the new mailbox wizard.
3. Click on Existing user and click on browse... to select the user.
4. Fill in the other fields.
5. Click on more options... to configure advanced options such as:
   • In what database the mailbox should be created
   • Whether or not an archive should be created
   • The address book policy
6. Click on Save to create the user.

Removing a mailbox

This command will effectively remove the mailbox and the user account of user kjones:

Remove-Mailbox –Identity kjones

To effectively remove the mailbox and the user account through the EAC refer to the following steps:

1. Navigate to Recipients | Mailboxes .
2. Select the user from the list of users.
3. Click the garbage bin icon and select delete .
4. Click Yes to confirm.

It's a common error to use Remove-Mailbox to remove a mailbox for a user. Remember that Remove-Mailbox will also remove the user account of that user. If you only want to remove the mailbox (that is, only remove the Exchange-attributes for the user account), run Disable-Mailbox.

Disabling a mailbox

The following command will disable the mailbox for user kjones, marking the user's mailbox for deletion in the database but without touching the user account itself:

Disable-Mailbox –Identity kjones

To disable the mailbox for user through the EAC follow these steps:

1. Navigate to Recipients | Mailboxes .
2. Select the user from the list of users.
3. Click the garbage bin icon and select disable .
4. Click Yes to confirm.

How it works...

Creating and removing mailboxes is a pretty straightforward action. However, the notion of removing and disabling mailboxes can sometimes be confusing.

When removing a mailbox, you are not only removing the user's mailbox but also the user account in AD. Disabling a user on the other hand will only mark the user's mailbox for deletion in the database, leaving the user account without a mailbox.

Depending on how your databases are configured, the mailbox will remain in the database in a disconnected state until it's past the database's retention time.

For example, to raise the deleted mailbox retention period to 60 days, run the following command:

Set-MailboxDatabase MDB01 –MailboxRetention 60.00:00:00

There's more...

When a mailbox is disabled, it is removed from the list of mailboxes in the EAC and you won't see it anymore when running the Get-Mailbox cmdlet. However, this doesn't necessarily mean the mailbox isn't there anymore.

As long as the mailbox is still within the deleted mailbox retention period of your mailbox database, you can re-enable it for the same user or connect it to another user's account, as long as that user doesn't already have a mailbox associated with it.

Working with disabled mailboxes

Run the following command to see a list of disabled mailboxes for a given database:

Get-MailboxStatistics –Database "MDB01" | ? {$_.DisconnectReason –eq "Disabled"}

To reconnect the disabled mailbox of Ashley Noel in database DBMBX01 to the user account of Ashley Noel, you can run the following command:

Connect-Mailbox "Ashley Noel" –Database "DBMBX01"

To connect the disabled mailbox of Ashley Noel to another user, Kirk Jones, run the following command:

Connect-Mailbox "Ashley Noel" –Database "DBMBX01" –User "exblogkjones"