How to manage Mailbox role?

The Mailbox server role manages all the mailbox databases but also Recovery Databases, Public Folder databases, or any other types of databases that can be used for different purposes (archiving for example).
Hence, this role controls the availability of the information that sits in the databases, and that is why GSX controls and reports its availability through multiple ways: MAPI, Mailbox Database availability and of course critical Windows Services.

For more information about Mailbox Database Management please read this section

GSX Monitor & Analyzer main features

Monitoring the MAPI performance connectivity to the mailbox

Checking the health of every mailbox database on the mailbox server

Ensure the replication across mailbox server's role

Capacity reporting at the mailbox server role level

GSX checks the service delivered by the Mailbox server role through multiple PowerShell tests. It tests the connectivity and the availability of the content (Databases) and collects statistics to identify bottlenecks, measure the usage by the user and prevent capacity issues. If one of the following conditions fails, the server is considered as down.

Monitoring the MAPI performance connectivity to the mailbox

Because GSX focus on end user experience and because the performance is as valuable as the pure availability, GSX Monitor & Analyzer encapsulates multiple scenarios tests that are constantly played to give you a real time view and alert on the end user experience.
GSX uses built-in PowerShell commands to make Synthetic transactions that simulate end user tests. It constantly tests the MAPI connectivity to the Mailbox and measures its performance from an end user perspective.
GSX connects on the mailbox you want (or to the system mailbox if you don’t want to specify a specific target) and extracts the list of the element of the mailbox.
Doing that it tests the two most critical protocols used during any connection between a client and a mailbox server: the MAPI and the LDAP protocol. During the authentication, GSX checks also that the MAPI server, the Mailbox Database and the Directory Service Access are working correctly.
These test checks the service that the Mailbox service should deliver as well as the Health of the Mailbox Database that is specify. Of course, an error on this scenario will lead to Mailbox server Role Down and an alert!
Hence GSX tests and report constantly for you on performance and availability of the connection of a user to its Mailbox using the needed protocol to do so. And everything just in a click, without any code on your exchange server.

24 wiz exc mailboxrole 1069

Checking is good, measuring is better! GSX gives you in real time the latency of this global test for you to instantly see the peak of latency during the day or over the past day and to help you troubleshooting any problem.
You can correlate the statistics with server load, CPU, RAM, CAS connections, protocol latency, etc.

SS2 MAPILatency

 

Checking the health of every mailbox database on the mailbox server

GSX Monitor proceeds to regular automatic PowerShell tests that measures the availability of each Mailboxes databases, collects the statistics and allow the trending and the forecasting at the Mailbox Database level, at the Mailbox role and at the DAG level.
Because the service that delivers the Mailbox server role is mostly based on Database availability, GSX Monitor checks the status of all the copy of the Database on each server. If a copy of a mailbox database is in error (Dismounted or unhealthy) an alert is sent and the mailbox role server is reported down.

 

 14 mailbox stat

This leads to two consequences. If your server isn’t in a DAG, and your Mailbox Databases are not replicated, the availability of the service for your users is directly linked to the availability of the Mailbox Server. Hence the availability of the server will reflect the one of the service you deliver.
If your server is in a DAG, the availability of the server does not reflect the one of the service because what matters is the availability of the Mailbox Database inside your DAG (with its replica). In this case if you want to measure the availability of the service, you will focus on Mailbox Database availability. GSX Analyzer will calculate that automatically for you.
Hence, the availability of the Mailbox role server becomes just information you will use in GSX Analyzer Environmental Health view, to compare your mailbox role servers, identify bottleneck and troubleshoot your environment.

Ensure the replication across mailbox servers' role

GSX constantly checks scans repeatedly to see if all of the services needed for replication are up and running at the server level.

It includes:

SS6 Replication

For all of these tests, GSX remotely accesses each server, makes the tests in real time and displays the results in the real-time statistics view– alerting the administrator on any down and warning status.
The Mailbox role is down if it is completely impossible to make any of these test. If some are possible and other in warning, GSX Monitor sends a Warning alert on replication errors but the server won’t be consider as down if the connection through MAPI works and if the Mailbox Database are available.

Prevent capacity issue and identify bottlenecks in your infrastructure

Because GSX is able to test and report on the service provided by every Mailbox role server, it becomes very simple to compare the performance of each of them across statistics that will help you in identifying issue in your environment.

GSX Analyzer Environment Health view allows you to see instantly in your Mailbox server infrastructure which server experiences the highest number of outages, problems, downtime, etc.

Compare system statistics (CPU, RAM), with general availability, compare the load of the server (Number of DB, number of mailbox per server), compare storage capacity across your infrastructure and instantly discover what should be your next action.

Moreover, GSX Analyzer gives you a one click forecasting features that makes your capacity planning simple. When will you have to increase the storage? To add a new Mailbox server? To take care about the number of Mailbox per server? Etc…

Possibilities are endless.

SS5 EHVMailbox


Capacity reporting at the mailbox server role level

Here is a small list of a few reports, directly available out of the box in GSX Analyzer

  • Number of mailboxes and number of Mailbox Databases per server: The purpose of this ratio is to equilibrate the number of mailboxes between the DB stores and the servers. Some servers can have a small number of users, a lot of storage and some others have too many users for historical reasons. It allows the administrator to have the most accurate view and take actions.
  • Average mailbox size per server: Same idea that the average DB size per server. Is the reality matching with the original sizing? Is there any storage problem to anticipate on this server regarding the evolution of this statistic?
  • Total Disk Space usage for all Mailbox Databases (per server): Critical to make capacity planning. This statistic has to be correlated with the information GSX gives on the disk space used by the DB to detect further storage problems. GSX Analyzer Environment Health and the Forecasting features are key points to fully exploit these statistics.