Monitoring Exchange 2013 with SCOM 2012 (Part 1)

When I’m discussing what the mission critical systems are of any given organization, email often comes up as one of the most crucial and important service to maintain. It’s not a surprise since, although it’s not categorized as line-of-business or core application, people rely on email at some level to perform their regular job tasks. And with this in mind, proactively maintaining a healthy messaging infrastructure should be on the top of the list for every Systems Administrators throughout the world (and I’m sure it is, as I remember a survey from a couple of years ago where for over a third of CIOs and IT managers, a week without e-mail is more traumatic than events such as a minor car accident, moving to a new home, or getting married or divorced).

In case you’re running Microsoft Exchange Server, System Center 2012 Operations Manager (SCOM 2012) can provide the necessary monitoring and alerting to help maintain those messaging servers to ensure they run smoothly without any problems. The latest Microsoft Exchange Server 2013 Management Pack (MP) includes a complete health model and a full complement of diagnostics-based alerts. This MP is also much simpler than its predecessors and more user focused, with a simplified dashboard that makes it easier to quickly determine what users are experiencing.
Like the previous versions of the Exchange MP, Microsoft invested all its internal experience running Exchange servers into the development of this software piece. And this time, the Exchange team is also sharing all the knowledge acquired through the management of Office 365 and Exchange Online environment, with its extreme demands on availability and performance.

Exchange Server 2013 introduced a new feature called Managed Availability, which comes with monitoring built in. This latest management pack leverages the capability of Exchange to detect and automatically recover from performance and availability issues, thus reducing alert noise and administrative overhead.

In terms of interoperability, this Management Pack does not upgrade the Exchange 2010 Management Pack, this is a completely new MP. It is possible to run these Management Packs side-by-side as you upgrade your Exchange environment from 2010 to 2013.

What’s New

One thing you’ll notice with the Microsoft Exchange 2013 Management Pack is its simplicity (some might say too simple). It contains 3 views, less than 20 classes and about 75 monitors that cover Exchange component health (such as Hub Transport health), customer touch point health (such as “is OWA working”), clustered scenarios, as well as dependencies monitoring (“is Active Directory healthy”). Monitoring covers primarily availability and performance scenarios.
This simplicity in the management pack also means a lower impact to the Operations Manager environment and a better scalability.
The following are some of the new features in the Exchange 2013 Management Pack:

• Simplified dashboard: the dashboard of the Exchange 2013 Management Pack has been simplified and refined into the following three categories
  • Active Alerts - Provides a list of all outstanding alerts in your organization.
  • Organization Health - Provides an overview of the overall service health in your organization.
  • Server Health - Provides an overview of the health of individual servers in your organization.
• User focused monitoring: Exchange 2013 introduces a monitoring and recovery infrastructure called Managed Availability that focuses on the user experience. All Exchange 2013 components have built-in monitors that detect problems and attempt to recover the service availability. Any issues that can't be recovered automatically are escalated to the Exchange 2013 Management Pack as an alert.
• There are no performance counters collected by this Management Pack: the monitoring does cover any performance issue that might arise, leveraging Exchange Managed Availability.
• There are no reports in this Management Pack: you can still use some of the built-in Operations Manager reports (such as the Health and Availability reports) to track organization availability, or define SLAs against the Organization.
• The Correlation Engine, introduced with the Exchange 2010 MP, is no longer used: Although it seemed a good idea with the Exchange 2010 MP, with the introduction of the Exchange 2013 Managed Availability, it no longer makes sense. The correlation logic, as well as self-healing capabilities moved to the Exchange servers. Each monitored Exchange server is responsible for monitoring its own health, and simply reports this via the Operations Manager agent. There is a little bit of roll-up going on, from Exchange server to Organization health

Using Health Explorer (Figure 1) you can dive into the monitoring capabilities of the Exchange Management Pack, exposing all the available monitors. As depicted in Figure 2 and Figure 3, each monitor has a link to online knowledge.

Figure 1: Exchange 2013 Health Explorer

Figure 2: Heath Explorer for Exchange 2013

Figure 3: Online knowledge article
If instead of using Health Explorer you open the management pack using MP Viewer (Figure 4), you’ll have a hard time trying to find the 75 monitors included. That’s because most of them are just not there, the MP leverages the information provided by Exchange 2013 Managed Availability.
It might be fun to also open the Exchange 2010 MP (Figure 5) and compare both of them. This will give you a clear image of all the simplicity within the latest Exchange management pack.

Figure 4: MP Viewer with Exchange 2013 MP

Figure 5: MP Viewer with Exchange 2010 MP

Exchange Server 2013 Managed Availability

Managed availability is defined as a set of internal processes made up of probes, monitors, and responders that incorporate monitoring across all server roles and all protocols. With managed availability, internal monitoring and recovery-oriented features are tightly integrated to help prevent failures, proactively restore services, and initiate server failovers automatically or alert administrators to take action. Managed availability moves away from monitoring individual separate slices of the system to monitoring the end-to-end user experience, and protecting the end user’s experience through recovery-oriented computing
Managed availability includes three main asynchronous components that are constantly doing work: probes, monitors and responders.

• Probes: These are sets of data collectors that measure various components. There are three distinct types of probes:
  • Synthetic transactions that measure synthetic end-to-end user operations and checks that measure actual traffic.
  • Checks that measure actual customer traffic.
  • Notifications that allow Exchange to take immediate action. A good example of this is the notification that is triggered when a certificate expires.
• Monitors: The data collected by probes are passed on to monitors that analyze the data for specific conditions and depending on those conditions determine if the particular component is healthy or unhealthy.
  The monitoring is done at different layers to deal with dependencies. Because there is no correlation engine in Exchange 2013, the dependencies are differentiated with unique error codes that correspond to different probes and with probes that don’t include touching dependencies.
• Responders: If a monitor determines that a component is unhealthy, it will trigger a responder. If the problem is recoverable, the responder attempts to recover the component using the built-in logic. There are several responders available for each component, but the one responder that’s relevant for the Exchange 2013 Management Pack is the Escalate Responder. When the Escalate Responder is triggered, it generates an event that the Exchange 2013 Management Pack recognizes and feeds the appropriate information into that alert that provides administrators with the information necessary to address the problem. These are the types of responders available:
  • Restart Responder: Terminates and restarts service
  • Reset AppPool Responder: Cycles IIS application pool
  • Failover Responder: Takes an Exchange 2013 Mailbox server out of service
  • Bugcheck Responder: Initiates a bugcheck of the server
  • Offline Responder: Takes a protocol on a machine out of service
  • Escalate Responder: Escalates an issue

The specific set of probes, monitors and responders within Exchange 2013 Managed Availability are referred to as health sets. Health sets are further grouped into functional units called Health Groups. There are four Health Groups and they are used for reporting within the SCOM Management Portal (Figure 1):

• Customer Touch Points – components with direct real-time, customer interactions (e.g., OWA).
• Service Components – components without direct, real-time, customer interaction (e.g., OAB generation).
• Server Components – physical resources of a server (e.g., disk, memory).
• Key Dependencies – server’s ability to call out to dependencies (e.g., Active Directory).

Figure 6: Exchange 2013 Managed Availability
Managed availability runs on every Exchange 2013 server and it is implemented in the form of two processes:

• Exchange Health Manager Service (MSExchangeHMHost.exe) - A controller process that is used to manage worker processes. It is used to build, execute, and start and stop the worker process, as needed. It is also used to recover the worker process in case that process crashes, to prevent the worker process from being a single point of failure.
• Exchange Health Manager Worker process (MSExchangeHMWorker.exe) - A worker process that is responsible for performing the runtime tasks.

Systems Center Operations Manager is used as a portal to see health information related to the Exchange environment. The alerts within the System Center Operations Manager (SCOM) portal indicate unhealthy states as reported by the Managed Availability components in Exchange 2013.
Each server executes its own probes, monitors itself, and takes action to self-recover, and escalates to SCOM via the Operations Manager agent when needed. This is a different approach from previous versions of Exchange and the corresponding management pack, where all events were escalated to a central SCOM server that would have to decide, based on the correlation engine, to raise an event or not. Pushing everything to one central place didn’t work, that’s why now each individual Exchange server acts as an island.
Notification and alerting to Operations Manager is handled via events, so the Management Pack has a set of simple event monitors that trigger based on these events. Events are logged to the Microsoft > Exchange > ManagedAvailability > Monitoring event log via the Escalate Responder.

Figure 7: Exchange 2013 Managed Availability Event Log
To view health, you use the Get-ServerHealth and Get-HealthReport cmdlets. Get-ServerHealth is used to retrieve the raw health data, while Get-HealthReport operates on the raw health data and provides a current snapshot of the health.

Get-HealthReport -Identity E2K13-MBX1

Figure 8: Get-HealthReport

Get-ServerHealth -Identity E2K13-MBX1

Figure 9: Get-ServerHealth

Summary

And so we conclude part 1 of this 5-part article about configuring the Exchange 2013 Management Pack for System Center 2012 Operations Manager. We covered the new features of the MP, and also the native monitoring functionality of Exchange Server – Managed Availability – which decentralizes monitoring and healing actions.

Exchange Server 2013 Backup and Restore 101 (Part 9)

In the last couple of articles of this series, we covered the process to backup and restore data using the most basic tool available to an Exchange administrator that is the Windows Server Backup. We also covered how an administrator is able to create a backup of a running mailbox database using the eseutil utility.

There is nothing wrong with that process, and it will work just fine. However, let’s picture a scenario where the customer has a single Exchange Server and a large mailbox database and all the protected data is on tapes which are moved to an offsite facility on a daily basis.

Then, we have a catastrophic failure on Exchange Server, and we performed the disaster recover procedures on the server (using the same step by step guide that we described in the sixth article of this series). To make matters worse, the business/customer says that time is of the essence and they must have access to some sort of e-mail to keep the business going as soon as possible. At this point, we have two options:

Option A: You can say to the customer: Sorry pal, but your design does not allow such RPO (Recovery Point Objective). If you can get his agreement that it is not doable, then we can restore the data as we have done in the previous articles, however we will have to wait for the Backup team to find the data and make them available.

Option B: Perform a dial tone recovery, where we will create a new temporary mailbox database and move all existent users to that new place, and after that they will be able to send and receive new e-mails just fine.

After having the original database ready from the backup team, we can use a feature called RDB (Recovery Database) to mount the original mailbox database and make sure that the database or at least its data can be restored/merged in production.

Restoring the service using dial tone recovery….

In order to demonstrate the dial tone recovery, we are going to use the following scenario: we have a couple of users hosted on TOREX01server, and they work in a special department that is responsible for sending and receiving information from the customers.
The data to be restored is going to take at least a day to be available to the messaging team, and for that reason we decided to perform the dial tone recovery to get the users working on the new messages and then afterwards we are going to merge that information.
Our test user is called Number6, and we can see its mailbox content before the crash, as shown in Figure 01.

Figure 01
After the restore of the server (we can check the entire process on the sixth article of this series), we will have all databases dismounted and the next logical step would be the restore of the databases, but in this scenario we are aware that they are not coming anytime soon.
At this point, new messages coming from Internet are being queued up (Figure 02, Queue Viewer), all Outlook clients are showing as disconnected (Figure 02, Outlook) and Outlook Web App is giving an error message (Figure 02, OWA). Long story short, nothing works!

Figure 02
The first step is to create a temporary mailbox database (TDB01) using either Exchange Admin Center (EAC) or Exchange Management Shell on the recovered server. Using EAC (Exchange Admin Center), click on Servers, and then Databases, click on Add (represented by the + icon) and on the new page define a name for the new Mailbox Database, for this article we will be naming it as TDB01, finally define the location for logs and edb file, and click on save, as shown in Figure 03.
We left uncheck the Mount this database, because as soon as we finish creating it, we will be restarting the Microsoft Exchange Information Store, and then mounting the mailbox database using these cmdlets:
Restart-Service MSExchangeIS
Mount-Database TDB01

Figure 03
The mailbox databases are shown in Figure 04, where we have the DB01 dismounted, which is waiting for the original log files from the last backup, and a brand new temporary database called TDB01.

Figure 04
Our next logical step is to start pointing the mailboxes to the new temporary mailbox database. In the cmdlet below (Figure 05), we list the mailbox first and then we move it by adding set-mailbox cmdlet at the end of the pipe. After running either of the cmdlets below, a confirmation will be required to complete the process.
Get-Mailbox number6 | Set-Mailbox –Database TDB01
We can use also in a single cmdlet, as follows:
Set-Mailbox <name> -Database <New-Database>

Figure 05
The important lesson from the cmdlet above is that we have not moved any data (It makes sense, since the original mailbox database with all data is dismounted and the backup is coming). We just need to change the mailbox configuration to the new location, what is going to change mainly is the homeMDB attribute of the user, as shown in Figure 06.
Note:We are just showing the attribute, we don’t need to change it manually, just perform the cmdlet above and we are good to go.

Figure 06
Now the user that we have just moved can go to the Outlook Web App (OWA), the result will be a brand new mailbox, and only new messages that were in the queue will be delivered to the mailbox, as shown in Figure 07.

Figure 07
If the same user opens an existent Outlook profile that was configured in the past, then the following message (Figure 08) will be displayed. In order to access the information on the temporary database, the user needs to click on Use Temporary Mailbox and only the new information will be accessible. On the other hand, if the user wants to access the information before the outage of the system, then the option Use Old Data can be selected, and the information that was previously synchronized with the user local OST file will be available.

Figure 08
In Figure 09, we can see Outlook with the new received messages after the user clicked on Use Temporary Mailbox option.

Figure 09

Conclusion

In this article, we went over the process of using the dial tone recovery process to bring the end-users back online with an empty mailbox where they will be able to send and receive new messages. In the next article of this series, we will be restoring the original database content and merging the new information with the old data to restore the service completely.

Exchange Server 2013 Backup and Restore 101 (Part 8)

In the previous article of this series, we went over the process to backup Exchange Mailbox Databases using Windows Server Backup and after protecting the databases we have several ways to restore the data. It is all about planning how we want to restore that data to the end-users.

In a scenario where the Exchange Server is beyond repair and a recovery process has to be started, then we can use Windows Server Backup to restore the entire volume to the original location and that will restore all Mailbox Databases inside of that volume, and that is what we are going to go over in the first section of this article.

However, in some cases, we may have only one mailbox database that requires restore, and if we restore the entire volume we will overwrite information from a healthy mailbox database, and that is where we should consider restoring just one Mailbox Database and we will cover that in the second section of this article.

Restoring all Mailbox Databases from the same volume using Windows Server Backup…

In this scenario, we are going to restore the Mailbox Databases to their original location. This type of recovery is often used when the only server that you have crashed, and you restored the Exchange Server using the /RecoverServer switch (we cover this process on the sixth article of this series) and now it is time to restore the Mailbox data that was being protected previously with Windows Server Backup.
Let’s say that we have the administrator mailbox with two items on its Inbox, as shown in Figure 01, and then all of a sudden the Exchange Server crashed. Well, the first action is to perform the recovery of the server (covered on the article number 6 of this series), and then we need to restore the Exchange Mailbox Databases.

Figure 01
As soon as the server restarts from the recovery process, we will notice that all mailbox databases are dismounted (Figure 02), and at this point we should have all drive letters but without any mailbox database files on them. We can always check the properties of the mailbox databases to make sure that the path defined on the Mailbox Database object exists on the server.

Figure 02
Since we have been protecting our Exchange Server using Windows Server Backup (as shown in the seventh article of this series), we can open Windows Server Backup and then click on Recover… (Figure 03) and follow these steps.
Note:Since this server was just recovered, the Windows Server Backup may not have been installed, and if that is the case, we need to install the feature before continuing.

Figure 03
In the Getting Started page. Here we can select an existent backup location, by selecting A backup store on another location, then click Next.
In the Specify Location Type page. Click on Local Drives and click Next.
In the Select Backup Location page. Select the drive that was used to store the backup information, and click Next.
In the Select Server page. In case one or more servers exist on the location, they will be displayed on the list, select the Exchange server name from the list and click Next.
In the Select Backup Date page. Here is the key area for the restore, we have a calendar where every day that we had a backup is in bold letters, and after selecting the day, we can select the Time (in situations where we have more than one backup a day).
After selecting the day and hour of the previous backup to be restored, we can click on the link on the Recoverable Items folder and a new window with the volume (in our case M:) and two items will be listed. That weird number of the first two items is the GUID of the Mailbox Database that we can retrieve using the following cmdlet. The Windows Server Backup and the Exchange Management Shell used to retrieve the guid are shown in Figure 04.
Get-MailboxDatabase –Server <ServerName> | ft Name,EdbFilePath,LogFolderPath,Guid -AutoSize

Figure 04
In the Select Recovery Type page. Select Applications and click next. (Figure 05)

Figure 05
In the Select Application page. We will have Exchange listed under applications, just click on Next.
In the Specify Recovery Options page. Select Recover to original location (Figure 06) and the reason is that we do not have any data on the disks right now and we need to restore the Mailbox Database, click Next.

Figure 06
In the Confirmation page. A summary with all the items that will be recovered will be displayed, click on Recover (Figure 07). To start the process and that may take a while depending on the size of the Mailbox Databases that are being restored (I’m sorry, we are talking of Windows Server Backup, so in fact we are restoring the entire volume, thus all mailbox databases that we have in it).

Figure 07
The final page will be similar to figure 08, where we will see each item restore status, and how much information was transferred.

Figure 08
If we look back to the databases in Exchange Admin Center (EAC), we will notice that they are mounted (Figure 09) and the users have access to their information and all the information available is from the backup that we choose during the recover process.

Figure 09

Restoring a Single mailbox Database…

Now, we have a different situation we have our server with two Mailbox Databases residing on the same volume (M: drive) however just one database is corrupted and since we do not want to touch the databas that is healthy we cannot use the previous procedure to restore the information.
We can check the databases information using Exchange Admin Center (EAC) where we can see that only DB01 is Dismounted however, DB02 is healthy (Figure 10).

Figure 10
In the Getting Started page. Select This Server (<ServerName>), click Next.
In the Select Backup Date page. Select a day, and then the time that you want to restore, and click Next.
In the Select Recovery Type page. Select Applications and click next.
In the Select Application page. We will have Exchange listed under applications, just click on Next.
In the Specify Recovery Options page. Select Recover to another location (Figure 11) and we are going to create a folder on the temporary drive (X: drive), and the name for that folder will be Restore, after defining the location click Next.

Figure 11
In the Confirmation page. Just click on Recover to start the process, which may take a couple of minutes/hours to finish depending on the size of the volume. In the final page of the wizard just click on Close.
In the folder that we defined as destination for the restored files we will have a subfolder for each mailbox database (the name of the folder will be based on the guid attribute of the database, which makes it easy to identify what we want to restore). Inside each main folder, we will have the volume and the directory structure where the mailbox database was protected.
We must look for the Exx.chk file (where XX is the Log Prefix of the Mailbox Database that we are trying to restore) and the DB01.edb is the mailbox database file (Figure 12), and we will use that information in a few moments.
Note:If the logs and database files are not in the same volume, we must restore them as a pair. Just restoring the database volume will not help, in this current situation the database and logs are on the same volume which makes things much easier.

Figure 12
In order to check if the database is in a healthy state we can use the command below, but first we need to be on the same location of the EDB file using either Exchange Management Shell or command (we should use cd FolderName to go deeper in the structure of directories).
Eseutil /mh <file.edb>
In Figure 13, we can see that the database is in Dirty Shutdown state and in this state, we cannot mount it.

Figure 13
We need to use the eseutil utility in recovery mode (/r) to bring the database to a clean shutdown state and we can do that by using the following syntax, the results of that command line is shown in Figure 14.
Eseutil /r <LogPrefix> /l <Path-Log-Files> /d <Path-Database-File>

Figure 14
Now, we can run the same eseutil /mh <database.edb> and the state will be clean shutdown, as shown in Figure 15.

Figure 15
In order to restore the database we can just place the EDB file in the original location on the Exchange Server (Figure 16). If there are files from the previous database, we can move them to a temporary location to be safe, but the goal is to keep just the brand new restored EDB file on that folder.
Note:If a folder does not allow removal, then we can stop the service Microsoft Exchange Search Host Controller and then try to remove that folder (related to the Search Service)

Figure 16
After cleaning up the folder and making sure that the EDB is in clean shutdown state, we can use Exchange Admin Center (EAC) to mount the database (Figure 17), a confirmation will be required. After that, the users will have access to their content, which was restored from the restore process that we have just completed.

Figure 17

Conclusion

In this article, we went over the process to restore all mailbox databases contained in a volume using Windows Server Backup, and how to restore a single mailbox database using the eseutil utility.

Exchange Server 2013 Backup and Restore 101 (Part 7)

At the beginning of this article series, we defined the goal to show the administrators how to protect and restore information from Exchange Server 2013 using built-in tools. There are several tools in the market to protect Exchange data, and the vast majority uses an agent installed on the Exchange Server, and each tool has its own documented process to backup and restore exchange data.

Although many organizations are moving away from the traditional backup using Exchange native tools, there are still a lot of organizations requiring traditional backups, and there is the scenario where an Exchange Server resides on a remote/distant office and a regular backup is the only way to protect that data.

There are also customers running Office365 and they are getting used to the idea that there is no traditional backup/restore process available other than the recovery deleted items process (as seen in the beginning of this series) and the Single Item Recovery in conjunction with the high availability of the Mailbox Databases to keep the exchange data.

In this article, we are going to show how to protect using a built-in tool which is Windows Server Backup, and after that, we will be restoring the databases in several different ways which we'll see in the next article of this series.

Using Windows Server backup…

Before starting with Windows Server Backup to protect an Exchange Server database, the administrator must be aware of a few key points to make sure that Windows Server Backup will work properly with your Exchange Server environment, as follows:

• Only full backups for Exchange Server are supported, no incremental or differential backups
• Protection is done at the volume level, we are not going to see the database items during the creation of the protection job
• The tool will run only locally, there is no remote administration
• We can restore Exchange Database afterwards, but that won’t save us from protecting and restoring the entire volume first
• Exchange logs will be purged after a successful backup
• The destination of the backup can be local or a remote network share
• There is no integration between Windows Server Backup and Recovery Database feature of Exchange Server 2013 (this process is manual, and we will cover it in this series)
• The restore process is brutal, it will restore the entire content of the volume, which means that a lot of space is required to perform a restore process, so plan well how you are going to keep the information.

Now that we are on the same page with the limitations we can go ahead and install Windows Server Backup We can add a new feature using Server Manager, and being at the Features page we need to select Windows Server Backup from the list (Figure 01) and use default values to complete the installation. After the installation, the tool is ready to use and there is no requirement for a restart.

Figure 01
If you prefer the PowerShell to install your windows features, then just run the cmdlet Add-WindowsFeature Windows-Server-Backup as shown in Figure 02.

Figure 02
In this article, we will have a single Exchange Server with a few Mailbox Databases created after the installation and all of them are on the C: drive. We are going to organize the existent environment to support better integration with Windows Server Backup, by moving all existent databases to a volume that will be used only for Exchange data, and getting rid of any additional mailbox database.
The first step is to make sure that we have a volume for our Mailbox Databases. We can use the cmdlet below (Figure 03) to list all the mailbox databases of any given server and the Mailbox Database file path and its log files.
Get-MailboxDatabase –Server <ServerName> | fl Name,EdbFilePath,LogFolderPath
As we can see, we have three Mailbox Databases on this server and all of them are on the C: drive and that is not the ideal scenario when using Windows Backup. To be honest this setup is not good in any production environment for several reasons: first, we do not want the same disk being shared between Operating System and Exchange Databases; second, if the disk is running out of space then it will bring down the server and consequently the mail system. Finally, using a single volume will affect Windows Server Backup where we do not have a place to store the backup, and the only option would be a network share.

Figure 03

Preparing the Exchange Server 2013 environment…

For this article, we added 2 additional disks (M: drive for the Exchange Databases and X: drive allocated for the backup files and restores), we know based on the previous figure (Figure 04) that we have three databases and they are still on the C: drive.
In order to move our production mailbox databases (DB01 and DB02) to the new drive we can use the cmdlet below, and we need to repeat the process for each mailbox database.
Move-DatabasePath <DatabaseName> -EDBFilePath M:\EXDatabases\DB01\DB01.edb –LogFolderPath M:\EXDatabases\DB01
Note:The directory structure defined in the cmdlet will be created automatically, after entering the cmdlet above we need to confirm the move for the database and log files.

Figure 04
At this point both production databases (DB01 and DB02) are in the new location, however we still have the default mailbox database on the same server (by default they start with Mailbox Database and a long number). Since we are adjusting the Exchange Server to support the Windows Backup, we should remove all Mailbox Databases from the C: drive.
The first step is to list all the Mailbox Databases for that default mailbox database and using the following cmdlet, we can accomplish such task.
Get-Mailbox –Database “Mailbox Database <number>”
After that we can use the same cmdlet and add | New-MoveRequest –TargetDatabase <DBName> to move all existent mailboxes to the new location. The entire process is shown in Figure 05.
Note:We should wait for the completion of all move requests, and we can use the Get-MoveRequest to track the status of the process.

Figure 05
Since we are planning to remove the first Mailbox Database, it is most likely that Mailbox Database has arbitration mailboxes, and we can find that out using the following cmdlet.
Get-Mailbox –Database “Mailbox Database <number>” –Arbitration
If there is arbitration mailboxes on that mailbox database, then we need to list all arbitration mailboxes followed by the | New-MoveRequest –TargetDatabase <DBName>, as shown in Figure 06.

Figure 06
After having all mailboxes and arbitration mailboxes moved, we should make sure that we remove all the requests using Remove-MoveRequest cmdlet. The next step is to remove the last mailbox database that still resides on the C: drive and we can use the following cmdlet (Figure 07):
Remove-MailboxDatabase “<DBName>”

Figure 07
After all changes, we can check the result in Figure 08 where we have only two Mailbox Databases on the server and now we are ready to start protecting them using Windows Server Backup.

Figure 08
The Mailbox Databases were never protected, and we can validate that by checking the Mailbox Database properties using EAC (Figure 09). We will see that there is no information about the last full or incremental backup, and we will be checking this information again after running the backup using Windows Server Backup.

Figure 09

Protecting Exchange Databases…

In the Figure 10, we show the main page of the Windows Server Backup, and in order to protect Mailbox Databases we are going to set it up for a daily backup, the first step is to click on Backup Schedule...

Figure 10
In the Getting Started page. A welcome page for the backup schedule wizard will show up, just click on Next.
In the Select Backup Configuration page. We are going to select Custom and then click Next.
In the Select Items for Backup page. We need to click on Add Items and select all volumes that contain Exchange Mailbox Databases (in our case M: volume), as shown in Figure 11. After selecting all volumes that contain Exchange Mailbox Databases and log files, click on Advanced settings, and select VSS Full Backup option under VSS Settings, as shown in Figure 12.

Figure 11

Figure 12
In the Specify Backup Time page. We are going to select once a day and we will be using 11PM as the time to run the protection, please change according to your environment and click Next.
In the Specify Destination Type page (Figure 13). Here we can define where the protection files will be placed. There are several options: we can use a dedicated hard disk (recommended), an existent volume or a shared folder on the network. In our case, we are going to use the option Back up to a volume and click Next.
Note:
The first option is recommended because all the disk activity will be in a separate disk, and that disk is going to be used only for the Windows Server Backup. Using this option the disk will be formatted and it will not be visible on Windows Explorer.

Figure 13
In the Select Destination Volume page. Click on Add and select the volume desired, and click Next.
Finally, in the last page a summary of all settings that we defined so far is going to be listed, click on Finish.
The results of this new backup job that we have just scheduled is a new Task in Task Scheduler being listed under Microsoft\Windows\Backup item, as shown in Figure 14.

Figure 14
Now it is time to wait for the scheduled task to run, and after that, we can see the results on the main page of Windows Server Backup, Figure 15 The same initial page will provide details about schedule jobs, last activities, future jobs and status of the volume/disk being used to store the backup files.

 
Figure 15
After having the first backup complete, we can go back to the mailbox database properties using Exchange Admin Center (EAC), and if everything went fine, we will have information on the Last Full Backup field, as shown in Figure 16. As part of the same process, all the logs that were committed to the mailbox database were purged as part of the backup of the database.

Figure 16

Conclusion

In this tutorial, we went over the basic steps to configure an Exchange Server 2013 to work with the built-in Windows Server Backup. In our next article of this series, we will be able to restore the database information to restore a mailbox server, and after that we will work with dial tone restore, mailbox portability and Recovery Mailbox Database, so we have tons of cool stuff to check in this series.