Many companies have good reasons to keep their messaging infrastructure on-premises. Exchange 2016 is currently the second latest version of Exchange Server for on-premises deployments. Common reasons to upgrade Exchange include adding new functionality, such as high availability, moving from an unreliable or insecure system, and moving to a version that Microsoft still supports.
Exchange Server has two core components. First, there is the mailbox component, with all the required client access protocols and well-known mailbox functions. The second major component is the message flow, with receiving, processing, and sending email messages.
Disk space is vital to the health of an Exchange Server. Without disk you don’t have email, thus Exchange monitoring - disk space is vital. Exchange is dependent on having disk because every time an email is sent it’s written to disk, without it you’re S.O.L.
When exchange databases run out of disk space the databases will dismount. Dismounted databases are usually not a good thing because that means email is down for the users in that database. Systems with low disk space can also impact overall performance of the server. Any of these events happening to an exchange server is not good. We all know that when email is slightest bit slow or down, the users will react like the zombies are attacking and the sky is falling.
If you are using tools such as ENow Exchange Monitoring, System Center Operations Manager, or Spotlight, monitoring Exchange disk space can be pretty easy. If your budget does not allow for third party software, however, you are left to monitor their servers manually. Manual Exchange monitoring can be a pain and not practicable for some shops due to the size of their environment. This is especially true if you’re running an environment with multiple Exchange 2010 DAG nodes, with replicating databases across many mount point paths.
Some HealthSets, such as the FEP HealthSet are local .xml files. Because FEP is the Forefront Endpoint Protection service, some of you may want to disable this HealthSet on the servers, because there is no use for it.
Browse to %ExchangeInstallationPath%\Microsoft\Exchange\V15\Bin\Monitoring\Config, search for FEPActiveMonitoringContext.xml and open the file with an editor, such as Notepad. Change line 12 by replacing Enabled = True to Enabled = False. Restart the Microsoft Exchange Health Management service on the server where you modified the .xml file.
With overrides, you can change the Managed Availability exchange monitoring thresholds and define you own settings when Managed Availability in case of errors should take action.
There are two kinds of overrides:
Local overrides: are used to customize a component on a specific server or on components which aren’t globally available. For example, if you are running multiple datacenters and would like to change only server components on a specific location for individual monitoring. Local overrides are managed with the *-SetMonitoringOverride set of cmdlets. They are stored in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ActiveMonitoring\Overrides\ and are automatically updated every 10 minutes. The Microsoft Exchange Health Management service reads the changes in the registry path above.
Global overrides: are used to customize a component for a whole Exchange organization. They are managed with the *-GlobalMonitoringOverride set of cmdlets. Global overrides are stored in Active Directory:
Now that you’ve finished Part I of my three part Managed Availability blog series, I will now go a bit deeper and provide some examples about the functionality and operability of Managed Availability. My virtual test lab contains a two-member DAG based on Windows Server 2012 and Exchange 2013 CU6.
Microsoft introduced a new built-in exchange monitoring system called Managed Availability in Exchange 2013, which automatically takes recovery actions for unhealthy services within the Exchange organization.
Microsoft has been operating a cloud version of Exchange since 2007 and have put all their knowledge into Managed Availability monitoring. Managed Availability is a cloud trained system based on an end user’s experience with recovery oriented computing.
Managed Availability doesn’t mean you don’t have to monitor your on-premises or hybrid Exchange environment in fact, it’s just the opposite. The long and complex exchange monitoring PowerShell cmdlet’s (which we will look at in more detail later) are not the best and most effective method to do so.
Before we talk about Exchange Server's Managed Availability features, let's first remember the architecture of Exchange Server.
By the end of 2020, a couple of interesting things regarding Exchange server are going on. The...
When you are in an Exchange hybrid configuration and you have migrated the last Mailbox to Office 365, you might wonder what to do with the last (couple of) Exchange server that is still running on-premises. Can you decommission your last Exchange server because all your Mailboxes are in the cloud? From a supportability point of view the answer is still “No, you can’t decommission the last Exchange server because you need it for management purposes” and most customers think this is disappointing. Let me explain why we still need this last Exchange server.
Securing Exchange servers is hard. I mean it can be a giant pain sometimes. There are what, hundreds of millions or maybe billions of lines of code running on your Exchange servers, right? It doesn’t take much for a typo to get through and open a vulnerability that can then be exploited opening the most important and valuable data within your organization to all kinds of bad actors.