Just like any other application, keeping Exchange healthy is crucial. It's not always easy to live up to this task,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and sometimes things just break. So how do you tell if -- and when -- things are broken?
One way is to wait for someone to complain about it. While this approach might be practical, it results in a poor end-user experience and could have disastrous consequences over time. Just imagine a backup that failed for five consecutive days and then experiencing a disk failure on the sixth day -- not a good situation to be in.
Monitoring Exchange deployments
This is part one in a series about how to monitor an Exchange deployment. Click here for part two, which covers how to combine active and passive monitoring and how hybrid deployments change monitoring.
This challenge isn't new; it has been around almost as long as IT systems have existed. Monitoring isn't new either, but a lot has changed in how things can and should be monitored, especially for monitoring Exchange deployments.
'What do I need to monitor?'
What to monitor is a question that pops up regularly. While the question is generic and simple, the answer might not be as straightforward. In fact, the best answer I could give you would be: "It depends."
There's is no one-size-fits-all approach to monitoring Exchange deployments. Organizations should keep an eye on some basic components, such as disk space usage, CPU or service status. But that's not really the problem here.
You need to monitor the components that directly or indirectly affect end-user experiences. While it might make perfect sense to monitor access to Outlook Web App, for example, what good is it if no one uses it and no one cares if it's temporarily broken? I'm not advocating that you shouldn't monitor components you aren't actively using. I'm just pointing out that it might not be as important to you as it is to someone else.
There are some key Exchange components that matter to everyone, including database health and Client Access components. Without a healthy database, you could potentially lose data. Without a healthy client access infrastructure, no one can get to that data. You can take that approach to monitoring in any location, and then try to make something meaningful out of the alerts and messages that get thrown at you.
This might seem like the most holistic way of doing monitoring, but it's seldom useful. The overhead of having to go through all the notifications and warnings can take up vast quantities of time. I've seen many cases in which an IT department no longer looks at the alerts thrown back by their monitoring option -- just because they've always been there or they claim to not have the time to go through all those messages.
There are essentially two ways you can go about monitoring Exchange deployments. The first approach is to passively monitor your environment. This means you -- or preferably a monitoring tool -- look at the information Exchange spills out, through application logs, for example. You're effectively letting Exchange produce the data you need to monitor.
Exchange 2013 generates heaps of data, giving you a really good view of how things are working. Unfortunately, that large amount of data could make you lose valuable time as you sift through it. Find a good tool to do this for you.
Another major problem with passive monitoring is that it doesn't allow you to be proactive, at least not without additional effort for interpreting the data. The tool you use should not just read a warning from the application log and then spill one out itself. Instead, it should look at the warning and decide whether or not it's meaningful. If it isn't, it shouldn't generate a warning, at most, it should keep track of it.
In active monitoring, you proactively go out to test components and functions of your deployment and report on them. You'll often see this type of monitoring as synthetic transactions. Synthetic transactions are actions such as scripts that the monitoring software executes, mimicking an end user's behavior. This is a better way to cover things, as it allows you to proactively check if everything is still functioning as it should. This is also the approach that Exchange's Managed Availability uses.
About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects podcast.