I am using the Exchange 2007 WMI sensors, however this does not give enough information for Exchange 2010.

For example, one of the servers in our SAN suffered some downtime a day or so ago. Unbeknownst to me, some of the mailbox stores were failed and offline. I didn't discover this until I was alerted by a user that an email had failed to be delivered to her and the error the sender got was 'mailbox unavailable'. As I started tracing the email through our system, I discovered in the Exchange Console that the above condition existed.

Paessler - Please could you add this feature to PRTG? I suspect you'll find more and more people desiring this as 2003 and 2007 disappear into the past!

Thanks

Matthew, which version of PRTG are you running? PRTG 12 has no "versioned" Exchange Sensors anymore, only one "global" WMI Exchange Server Sensor that will add sensors according to the version of Exchange you are running.

We are running the very latest version of PRTG - 12.4.5.3165.

We have a CAS/Hub Server which is reasonably well monitored by the WMI sensor options. However, we also have two mailbox servers. The WMI channels available to monitor mailbox servers are not great. A good number of them do not provide much in the way of realistic data and there's no way to monitor failover of mailbox stores between our mailbox servers, or such things as DAG copy queue length, which can also indicate a problem.

Okay, we will put those things on the wishlist!

Just migrated our mailboxes to a Exchange 2010 DAG. Is this only on the feature request list or already in development?

Every time I move a DB from a DAB member to another I need to pause or acknowledge a lot of sensors on the former active server. I'm not really happy at the Moment with the state of the sensor for one of my business critical applications. Exchange 2010 is not really a new product and the successor is RTM now…yet we still wait for a sensor that can monitor a DAG.

Regards Marcus

I'm afraid it's still on the request list.

Another key performance indicator is the messages sent/received per mailbox per day. This is defined by Microsoft as part of their best practice for evaluating hardware requirements and maintaining performance. Could this also be added to the available sensors please?

Any news on whether we might see this feature soon? Exchange 2013 will be in the same boat. At the moment I'm having to cobble a web page together to do this because the other day all our mailbox databases failed over to one server (reasons unknown) and we had very slow access for users. It was only on investigating that I discovered the cause. If anything else goes wrong on our Exchange, PRTG very nicely tells me... Would be really nice if it could have told me about this too :(

OK chaps, I've had three situations since my last post where mailboxes had failed over to another mailbox server or copy queues had been suspended. I was only aware of these because I do regular checks via the EMC.

I could really, really do with PRTG being able to monitor these things. I do appreciate you sending out the beta exe script for me to try but I have had no success with it, despite following the instructions to the letter, trying every server etc etc.

Any news? My first request about this was October of last year... I wouldn't feel justified in pushing about it if it was some very rarely used piece of software, but come on - it's Microsoft Exchange!

Dear Paessler

PRTG serves us so well in monitoring our infrastructure. Everything from VMWare, Sharepoint, Switches, Printers, you name it.

But I'm a little concerned that after initially opening this thread in March 2011, over two years have passed without the ability to properly monitor Exchange 2010, one of the most widely-used Mailservers, being added to PRTG.

On November 1 2012 it was put on the wishlist - surely there has been some progress by now? I am sure am not the only user that would really like to be able to monitor their Exchange Server health.

I really don't want to have to run a secondary monitoring system just to keep a watch over our Exchange Infrastructure, and I don't really want to! PRTG is great!

Hope to hear something soon...

Matthew,

Have you taken a look at the new PS Exchange sensors that are available with the new version of PRTG? Check the link under Mail Servers Sensors the new sensors are listed including mailbox and DB sensors.

Dear Greg,

yes I have looked at these, in fact I received one of the betas to try out some months ago. Sadly these do not monitor Database Availability Group health, e.g. which copy of a DB is active, are any of the copies failed and suspended (this is NOT the same as dismounted), etc.

This is a critical function of Exchange 2010 and 2013 and is not likely to go away. It cannot be that hard to monitor - we are preparing to make a webpage that pulls the powershell results that we can view as a stand in, we might possibly set up the http monitor sensor in PRTG to check for a particular string in the webpage and alert us. We cannot keep missing downtime, which we have had an amount of recently due to some networking issues. If it would take us an afternoon to make a webpage, surely this can be done by the server monitoring experts :)

The reason that we have not created these sensors yet is that we do not have any Database Availability Groups set up here at the office and as a result we cannot develop and test such a sensor. We are planning on building this out but are currently waiting for the time and the resources to do so. We are hoping that we will be able to do this in early 2014.

I've just updated to the most recent version of PRTG, having renewed our maintenance agreement.

I just wanted to say how grateful I am for the Exchange Powershell sensors that are now included. Being able to monitor the databases at the most basic level is still a massive improvement.

However, I note that if I manually suspend a database (a state it can end up in by itself, prior to becoming 'failed and suspended'), that PRTG does not register this as a fault. Is this because it is picking up the presence of the active copy on the other DAG Member server?

This also affects how we monitor the databases. There's no point in us monitoring the database copies on each Exchange Server and using up our sensors if the sensor monitors the 'database', rather than the 'copy'. Could you clarify for me, please?

If I dismount the database, I get the message "Error reading response: Invalid XML (missing /prtg)" as the alarm code. Any way to change this for a more meaningful message, i.e. 'Dismounted', 'Failed and Suspended' etc?

Again, my sincere thanks for the progress in this :)

Hi Matthew,

indeed the sensor is 'simply' asking the exchange server about the state of the databaseconnection disregarding if it is the only database or a db in a dag. The exchange server is answering with mounted or unmounted but not if there is a failover-state.

As Greg mentioned before, we will restructure our environment during the next weeks by removing Exchangeserver 2003 and adding Exchange 2013 to it. In the new setup there will be a DAG, too. After that upgrade we will bring some new / improved sensors for monitoring DAG.

Please bear with us.

Kind Regards

Vielen dank, Dieter :-)

that's great news about the new sensors, I'll look forward to it. If you need any info regarding Exchange 2010/2013 from a live setup, or a beta tester for the development sensors I'd be glad to oblige. We run a full test setup with DC's and Exchange 2010/2013 DAG here as well.

Kind regards

I don't know if this is of interest to you, but as a temporary fix I am using the following free Powershell script - http://exchangeserverpro.com/powershell-script-health-check-report-exchange-2010/ produced by Paul Cunningham.

The script is designed to output to screen or to produce an html report that is sent by email. I have modified the script to send the html report to the wwwroot on an IIS server, where it can be opened as a web page. I have set PRTG to monitor this page for the word 'failed'.

I'm sure someone with more ability could come up with a more comprehensive system than this, but in principle it works - wondered if it may be of interest?

I am interested in using this script on Exchange servers. Can you tell me if this script affects performance?. Thank you