Monitoring Exchange 2013 with SCOM 2012 (Part 3)

Working with the management pack and configuring overrides in Exchange Managed Availability.

Additional Configuration to the Management Pack

Like previously said, one of the main characteristics of this MP is its simplicity. I don’t know (and I don’t risk a prediction) if Microsoft will introduce some complexity to future versions, but for now, there’s not much to configure with this management pack. Even if you have a complex and large Exchange organization, you should be fine just importing this MP into your existing environment.
There are no special components to install on Management Servers (correlation service is gone), you do not need to worry about the impact to the Management Group in terms of database size, instance space, Management Server workload etc., as the management pack was designed to scale.
However, if you should require some adjustments to the Management Pack, like fine tuning some of the monitor or probes, or disabling some unnecessary alerts, that is still possible. Let’s look how it can be done in the next chapters.

Operations Manager Overrides

Exchange Server 2013 management pack is designed to be simple to deploy and use. However, if you see alerts that are not valuable to you, you can configure overrides to turn these specific alerts off. Use these overrides only if you are experiencing specific problems.
If you want to disable some alerts, you can just create an override in Operations Manager as usual. For example, in my environment I was getting an alert regarding the available disk space on my Exchange Servers. The threshold for available disk space is 100GB, which I don’t have. I can modify the threshold in Managed availability (we’ll see how on the next chapter), or I can just disable this alert with a SCOM override.
To disable this alert in the SCOM console:

1. Right click on the alert, and then select Overrides > Disable the Monitor > For the object: E2K13-MBX2 – MailboxSpace (Figure 1).

Figure 1: Disable Monitor with Override

2. In the Override Properties window, clear the checkbox for the Parameter Name Enabled (Figure 2).

Figure 2: Override Properties

3. Select a destination management pack to store the override, and click OK.

If you want to change a threshold for some monitor, this is done in the Exchange Managed Availability engine via PowerShell cmdlets. This does not involve Operations Manager at all and we’ll see how to do it in the next chapter.

Managed Availability Overrides

As we saw previously, Managed Availability performs a variety of health assessments within each server. When issues are detected, multi-step corrective actions are taken to bring the server back into a functioning state. In the event that the server is not returned to a healthy state, Managed Availability can alert operators that attention is needed.
With any environment, defaults may not always be the optimum condition, or conditions may exist that require an emergency action. Managed Availability includes the ability to enable overrides for the entire environment or on an individual server. Each override can be set for a specified duration or to apply to a specific version of the server. The *-ServerMonitoringOverride and *-GlobalMonitoringOverride cmdlets enable administrators to set, remove, or view overrides.
Managed Availability components (probes, monitors and responders) can be customized by creating an override.
There are two types of override: local override and global override. As their names imply, a local override is available only on the server where it is created, and a global override is used to deploy an override across multiple servers.
Either of the above mentioned overrides can be created for a specific duration or for a specific version of Exchange servers. The override created with Duration parameter will be effective only for the period mentioned. Maximum duration that can be specified is 60 days. For example, an override created with Duration 45.00:00:00 will be effective for 45 days since the time of creation.
The Version specific override will be effective as long as the Exchange server version matches the value specified. For example, an override created for Exchange 2013 CU1, with version “15.0.620.29” will be effective until the Exchange server version changes. The override will be ineffective if the Exchange server is upgraded to different version of Cumulative Update or Service Pack.
Hence, if you need an override in effect for longer a period, create the override using ApplyVersion parameter.

Managed Availability Local Overrides

In this example we are going to create a local override for the StorageLogicalDriveSpaceMonitor monitor, since we are getting an unhealthy condition returned by the MailboxSpace health set (Figure 3). By default this monitor has a threshold of 100GB of free disk space, we want to modify it to 50GB.

Figure 3: Event 4, ManagedAvailability
In part 1 of this series of articles we already saw how to generate health reports using the PowerShell cmdlets Get-HealthReport and Get-ServerHealth. To narrow a little bit the results, let’s try something different:

Get-HealthReport -Identity E2K13-MBX1 | where { $_.alertvalue -eq "Unhealthy" }

This produces the output similar to the following:

Figure 4: Get-HealthReport
First we need to get the list of monitors associated with this healthset that are responsible for reporting the available storage space. We can determine the collection of monitors (and associated probes and responders) in a given health set by using the Get-MonitoringItemIdentity cmdlet.

Get-MonitoringItemIdentity -Identity MailboxSpace -Server E2K13-MBX1 | ft name,itemtype –AutoSize

Figure 5: Get-MonitoringItemIdentity
Now that we have the list of monitors, let’s find out which one is reporting an unhealthy state, by running the following cmdlet:

Get-ServerHealth E2K13-MBX1.contoso.com | ?{$_.HealthSetName -eq "MailboxSpace"}

Figure 6: Get-ServerHealth
To figure out why the monitor is failing, let’s list the configuration details of StorageLogicalDriveSpaceMonitor monitor.

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/MonitorDefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like "StorageLogicalDriveSpaceMonitor"}

Figure 7: StorageLogicalDriveSpaceMonitor details
You can also use Event Viewer to get the details of monitor definition. The configuration details of most of the Monitors are stored in the MonitorDefinition channel:

1. Open Event Viewer, and then expand Applications and Services Logs > Microsoft > Exchange > ActiveMonitoring > MonitorDefinition.
2. Click on Find, and then enter StorageLogicalDriveSpaceMonitor.
3. The General tab does not show much detail, so click on the Details tab, it has the configuration details specific to this monitor. Alternatively, you can copy the event details and text and paste it into Notepad to see the details.

Figure 8: MonitorDefinition
From the last 2 steps we discovered that there is a field called MonitoringThreshold with a value of “1”. I’d say that’s a good candidate to tweak in order to modify the health result returned by the monitor.
Use the following command to create a local override, and change the MonitoringThreshold value to 50GB:

Add-ServerMonitoringOverride -Server E2K13-MBX1.contoso.com -Identity MailboxSpace\StorageLogicalDriveSpaceMonitor\C: -ItemType Monitor -PropertyName MonitoringThreshold -PropertyValue ’50000’ -Duration 60.00:00:00

Local overrides are stored under following registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Overrides\Monitor
The Microsoft Exchange Health Management service reads this registry path every 10 minutes and loads configuration changes. Alternatively, you can restart the service to make the change effective immediately.

Figure 9: Windows Registry
Finally, to remove the local override that was created for the StorageLogicalDriveSpaceMonitor probe, run the following cmdlet:

Remove-ServerMonitoringOverride -Server E2K13-MBX1 -Identity MailboxSpace\StorageLogicalDriveSpaceMonitor\C: -ItemType Monitor -PropertyName MonitoringThreshold

Managed Availability Global Overrides

Configuring global overrides is not much different than configuring local overrides. The main difference is that a global override is used to deploy an override across multiple servers.
For this example we’ll use a recent problem that affected some Exchange systems throughout the world. As you are probably aware, the release of Exchange 2013 RTM CU2 and CU2 v2 caused some BSOD on DAG member servers when Exchange is deployed in multi-domain Active Directory forests.
The workaround for this problem, while the new version of the CU2 was not released, was to disable the responder “ActiveDirectoryConnectivityConfigDCRestart” to prevent forced reboots of Exchange server. Since the problem only occurred on a specific version of Exchange, we’ll want to specify that the override only applies to build number 15.0.712.24.
We can use the following command to get version information for Exchange 2013 RTM CU2 servers:

Get-ExchangeServer | ft name,admindisplayversion

Figure 10: Get-ExchangeServer version
Use following command to create a new global override:

Add-GlobalMonitoringOverride -Identity Exchange\ActiveDirectoryConnectivityConfigDCServerReboot -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.712.24"

Use following command to make sure the responder is disabled:

(Get-WinEvent -LogName Microsoft-Exchange-ActiveMonitoring/responderdefinition | % {[XML]$_.toXml()}).event.userData.eventXml | ?{$_.Name -like “ActiveDirectoryConnectivityConfigDCServerReboot"} | ft name,enabled

If the responder is disabled, Enabled should have a value of “0”, as depicted in the following picture:

Figure 11: Get-WinEvent
Global overrides are stored in the following container in Active Directory:
CN=Overrides, CN=Monitoring Settings, CN=<Exchange Organization>, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=Contoso, DC=com

Figure 12: ADSIEdit

Summary

The Exchange 2013 Management Pack is much simpler and straightforward to configure than its predecessors. Nevertheless, if some tweaking is necessary regarding the monitors and alerts, overrides can be configured in Operations Manager and also in Exchange Managed Availability.

Monitoring Exchange 2013 with SCOM 2012 (Part 2)

In this article we'll look at adding the Exchange servers as agent-managed computers, importing the Exchange 2010 Management Pack and installation.

Solution Topology

For the purpose of writing this article, I installed the following environment on my test lab:

Figure 1: Solution topology used in this article

Server Name	Role	Software
SC2K12-SCOM	Root Management Server	Windows Server 2012 SQL Server 2012 SP1 System Center 2012 Operations Manager SP1 + UR4
E2K13-MBX1	Domain Controller Mailbox Server CAS Server	Windows Server 2012 Exchange Server 2013 + CU2
E2K13-MBX2	Mailbox Server CAS Server	Windows Server 2012 Exchange Server 2013 + CU2

Table 1: List of servers

Exchange 2013 Management Pack Pre-requisites and Considerations

Before importing the Exchange 2013 MP into System Center Operations Manager, there are some pre-requisites that have to be met:

• You have one of the following versions of System Center Operations Manager deployed in your organization:
• System Center Operations Manager 2012 RTM or later
• System Center Operations Manager 2007 R2 or later
• You have already deployed SCOM agents to your Exchange Servers.
• The SCOM agents on your Exchange Servers are running under the local system account.
• The SCOM agents on your Exchange Servers are configured to act as a proxy and discover managed objects on other computers.
• If you are monitoring Exchange Server 2013 Database Availability Groups (DAGs), ensure that all DAG members are monitored by Operations Manager.

Before downloading and installing the Exchange Server 2013 MP, you might want to import some recommended additional management packs, such as (these are the ones I used):

• Active Directory Domain Services Management Pack for System Center
• System Center Management Pack for Windows Server Operating System
• System Center 2012 Monitoring Pack for Microsoft Windows Server 2012 Internet Information Service 8
• System Center Management Pack for Windows Server DNS

Add the Exchange servers as agent managed computers

Adding the Exchange servers to monitor as agent managed computers is the first required step.

1. Click the Administration tab and then click Configure computers and devices to manage on the Actions pane. This will start the Computer and Device Management Wizard (Figure 2). Click Next, choose Advanced Discovery (Figure 3) and select Servers Only from the Computers and Device Classes drop-down box.

Figure 2: Computer and Device Management Wizard

Figure 3: Advanced discovery

2. On the next window, browse for the computers you are adding (Figure 4) and click Next. Select Use selected Management Server Action Account (Figure 5), click Discover and wait for the discovery results (Figure 6). Figure 7 shows a brief summary that is displayed at the end of the wizard. It is mandatory that all systems running Exchange Server 2013 that are managed by Operations Manager use Local System as the Agent Action Account. Click Finish.

Figure 4: Discovery Method

Figure 5: Administrator Account

Figure 6: Select Objects to Manage

Figure 7: Summary

3. If the agent installation was successful, on each Exchange server you’ll be able to see the System Center 2012 - Operations Manager Agent listed on the Programs and Features on Windows 2012 (Figure 8). A new service is also created, the System Center Management Service, as depicted in Figure 9.

Figure 8: Programs and Features (Add/Remove Programs)

Figure 9: System Center Management Service Properties

4. To enable Agent Proxy configuration on all managed Exchange servers, in the Administration pane, under Administration, Device Management, Agent Managed, right-click on each Exchange server (Figure 10), select Properties, then the Security tab (Figure 11), and check the box Allow this agent to act as a proxy and discover managed objects on other computers. This step will also make exchange cluster instances to appear in the Agentless Managed section (ensure that all physical nodes of the cluster are monitored). Repeat the process for every managed Exchange 2013 server in the list

Figure 10: Agent Managed Properties

Figure 11: Enabling Agent Proxy

Create a new management pack for customizations

The customizations and overrides of sealed management packs, such as the Exchange 2013 MP, are usually saved in the default management pack. As a best practice you should create and use an unsealed management pack for each sealed management pack that you want to override, as shown in Figure 12.

Figure 12: Unsealed management packs
Creating a new management pack for storing overrides has the following advantages:

• It simplifies the process of exporting customizations that were created in your test and pre-production environments to your production environment.
• It allows you to delete the original management pack without first needing to delete the default management pack.
• It is easier to track and update customizations to individual management packs.

1. In the Operations Console, click the Administration button. In the Administration pane, right-click Management Packs and then click Create Management Pack. The Create a Management Pack wizard displays.
2. In the General Properties page (Figure 13), type a name for the management pack in Name, the correct version number in Version, and a short description in Description. Click Next and then Create.

Figure 13: Creating a Custom MP for customizations

Install the Exchange Server 2013 MP

With the recommended additional management packs already imported, download and install the latest Microsoft Exchange Server 2013 Management Pack (at the time of the writing of this article it was version 15.00.0620.018). You can find the latest Management Packs at the Microsoft System Center Marketplace.
Let’s look at the installation steps of the Exchange 2013 Management Pack:

1. Download the management pack file and launch the Microsoft Installer (MSI) package on the selected SCOM server. Accept the license agreement, and click Next (Figure 14).

Figure 14: License Agreement

2. Accept the default installation folder or select a new one. Click Next (Figure 15). The extraction process begins.

Figure 15: Select Extraction Folder

3. When the extraction ends, click Close (Figure 16). When the installation is complete, the management pack files are copied to the System Center Management Packs folder.

Figure 16: Extraction Complete

4. To import the Exchange 2013 MP, open the SCOM 2012 Operations Console. Click the Administration tab, right-click the Management Packs node and then click Import Management Packs (Figure 17).
5. Click Add, Add from disk and then click No on the Online Catalog Connection window. Select all the files from the Exchange MP directory, by default C:\Program Files\System Center Management Packs (Figure 18), click Open and then click the Install button (Figure 19).

Figure 17: Import Management Packs

Figure 18: Select Management Packs to import

Figure 19: Import Management Packs

6. The Import Management Packs page appears and shows the progress for each management pack. After the import process is complete and the dialog box displays an icon next to each Management Pack that indicates success of the importation (Figure 20), click the Close button. Click View and then Refresh, or press F5, to see the Microsoft Exchange Server 2013 management pack in the list of Management Packs.

Figure 20: Import Succeeded
After importing the Exchange 2013 MP, it will start immediately discovering Exchange machines. So, if you browse to the Discovered Inventory pane on the Operations Console (Figure 21), all the Exchange 2013 servers should be listed. Notice that the Database Availability Group (DAG) is also listed, although its state is Not monitored. This is a normal behavior, since the physical nodes of the DAG are already being monitored.

Figure 21: Discovered Inventory
The Exchange 2013 MP adds 3 views to the Monitoring pane (Figure 22):

• Active Alerts
• Organization Health
• Server Health

Figure 22: Organization Health
Expand Microsoft Exchange Server 2013, and then click Server Health. Right click on one of the Exchange servers listed and click Open, Health Explorer. By default, the view is scoped to unhealthy child monitors (Figure 23). Click on Filter Monitors to clear the filter (Figure 24). Expand Entity Health to view the 4 health groups for Exchange Server 2013:

• 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 23: Server Health (filtered)

Figure 24: Server Health (unfiltered)

Summary

With the Exchange 2013 Management Pack imported, SCOM is now prepared to receive the escalated alerts from Managed Availability that require human attention.
In the next part we’ll take a deeper look into Managed Availability, specifically how to interact with it and perform some configuration tasks that used to be part of the process of installing and configuring the MP.

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.