Managing Mailbox Databases settings using PowerShell

Introduction

I wrote an article series here at MSExchange.org going over the process to configure corporate profiles to enforce features/restrictions to users based on pre-defined profiles, and the focus of that series was towards the mailbox management process.

The goal of that series was to save time from the Service Desk team configuring basic stuff to the end-users. In this article, we are going to use the same concept to save time for our server administrators when configuring Mailbox Databases in our production environment.

If you have a server with a couple of databases that do not change often, then this script may not be for you, but you can still use the logic and deploy it in different areas of Exchange using PowerShell.

On the other hand, if you have an organization with several sites and exchange servers, you can use this article to keep the consistency of your Mailbox Databases.

If you are interested in automation and consistency, I recommend you look into RBAC here at MSExchange.org where using those concepts to restrict administration access to a server for a group of administrators and this article will work well together.

Naming convention for the Mailbox Database…

We will continue using the precious metals that we used in our article series about corporate profiles for the databases, which are Gold, Silver and Bronze. We will make sure that Mailbox Databases will have one of the profiles as part of their name.

In the current article, we are using <CountryCode><SiteCode>-<DBIncrementalNumber>-<Profile> and an example would be CATOR-DB01-Gold which allows the administrator in a single glance to identify that this is the first database containing Gold profile mailboxes located in Toronto, Canada.

Getting the necessary information to create the source file…

There is no secret in this script since we are going to deal only with the Mailbox Database object, we can go to the Exchange Management Shell and run the following cmdlet and the results are shown in the Figure 01.

Get-MailboxDatabase <Database-Name> | FL

Figure 01

Time to define which parameters will be defined as part of the corporate policy. You can start simple with just a few parameters. In this article, we are going to use these following parameters:

• ProhibitSendReceiveQuota
• IssueWarningQuota
• ProhibitSendQuota
• DeletedItemRetention
• IsExcludedFromProvisioning

Our next step is to create our CSV file that will have four columns (DBItem,GoldValue,SilverValue,BronzeValue) and for each line, we will have one of the parameters that we want to configure and then the settings for each one of the profiles, as shown in Figure 02.

This file should be secure and only corporate administrators should be able to change it. A good location if you have a secure Active Directory is the NETLOGON folder, which is replicated among all Domain Controllers. The file name that is being used for Tutorial is EXDatabases.info.

Figure 02

Building the script…

Before we start creating the script, we need to define some definitions for this script usage. Since this is a simple script, we can start with simple definitions, as follows:

• All mailbox databases will be loaded based on the local server name
• To improve reporting for each database process by the script, the current values and the ones after the changes will be displayed in the output to support documentation on your environment
• If the database name does not have a profile on its name, then it will be skipped

The first thing to build our script is to create a validation for the baseline file which is called EXDatabase.info. In order to save time during the construction of the script we will keep the location of the file in the $OfficialPath variable and then we will test it, if the file does not exist, then the script will end.

The second block of commands will store the local server name in the $vServer variable and a list of all Mailbox Databases in the $vLocalDBs.

Now that we have gathered all the information required (the baseline file with all corporate settings and the list of the mailbox databases of the current server), our next step is to perform a loop on the Mailbox Database list. We will do that using the ForEach ($vDB in $vLocalDBs) statement.

We will use the Switch –wildcard ($vDB) to search for our pre-defined profiles (Gold, Silver and Bronze) on the Database Name, and if they match we will store just the DBItem and the ProfileValue columns in the variable $tFile.

For any given database, we are concerned about the parameters (DBItem column) and the column that matches the profile of the database. To save time we will move the DBItem column and the correspondent profile column to the variable $tFile, and there the column will be called tColumn which will help us out on the script where we don’t need to validate the profile for that mailbox database.

At this point in the script we have a variable $tFile with only two columns (parameters that we need to apply on the current mailbox database, and tColumn which has all the values for the profile). Our first test is to make sure that the variable $tValid is $True and it will only be true if the current database matches one of the pre-defined profiles.
Note: If the $tValid is $False, then the script will skip that mailbox database and an error will be provided in the output.

If the Mailbox Database has a valid profile on its name, then we will start adding all the parameters in two variables $tString and $tCheck and we will perform a full reading of the EXDatabase.info file and for each line of the DBItem column we will be adding to those two variables. The idea behind this is to build the Get-MailboxDatabase and Set-MailboxDatabase with all parameters listed on the baseline file.

After completing the reading of the entire baseline file, we can run both variables using Invoke-Expression() statement. We added a couple of Write-Host before and after to control the output of the script.

One thing that we do is to run the $tCheck (cmdlet that will list the Mailbox database properties) variable before and after running the $tString (cmdlet that will change the Mailbox Database)

Now with the script complete, we can run it by using .\DBGlobalSettings.ps1, and the output will be similar to Figure 03.

The output will have a first line for each new Mailbox Database informing the Mailbox Database name and its profile. Then, we will list the cmdlet that was used for that specific database based on the values of our baseline file. Finally, we provide the values before and after the change for comparison purposes.

Figure 3

We have been working on pieces of codes in this article, so here is the final script with all pieces of code put together.

Conclusion

In this article, we went over the process to create a simple script to keep consistency of Mailbox Databases based on their profile defined by the name convention.

By having a naming convention in place we can save time from the server administration and avoid human errors when defining Mailbox Databases using a simple script.