The Microsoft Exchange package consists of a set of LogicModules that provides comprehensive out-of-the-box monitoring for the Microsoft Exchange mail and calendaring server.

Note: LogicMonitor also offers monitoring for online Exchange via its Microsoft Office 365 integration package. See Microsoft Office 365 Monitoring for more information.


As of the v.125 release of the LogicMonitor platform (September 2019), the Microsoft Exchange package is compatible with versions 2007 through 2019. As Microsoft releases newer versions of Exchange, LogicMonitor will test and extend coverage as necessary.

For the majority of DataSources that make up this package, there are two versions of each DataSource: one version that is compatible with Exchange versions 2007, 2010, and 2013; and one version that is compatible with Exchange versions 2016 and 2019. These versions are necessary to account for deprecations and other changes that Microsoft made to its performance counters in Exchange 2016.

The DataSource names in this package are appended with Exchange version information to delineate which set of versions a particular DataSource applies to:

  • 2007+ – DataSource names appended with “2007+” apply to Exchange versions 2007, 2010 and 2013 (e.g. Microsoft_Exchange_Replication_2007+)
  • 2016+ – DataSource names appended with “2016+” apply to Exchange versions 2016 and 2019 (e.g. Microsoft_Exchange_Replication_2016+)

Note: There are two DataSources that require no compatibility versioning: “WinExchange Processes” and “WinExchangeServices”.

Considerations: Migration from WinExchange* DataSources

In September of 2019, LogicMonitor released a new set of Microsoft Exchange DataSources. If you are currently monitoring Microsoft Exchange using the legacy WinExchange* DataSources, you will not experience any data loss upon importing the newer DataSources in this package. This is because DataSource names have been changed to eliminate module overwriting.

However, you will collect duplicate data and receive duplicate alerts for as long as both sets of DataSources are active. For this reason, we recommend that you disable the legacy WinExchange* DataSources. When a DataSource is disabled, it stops querying the host and generating alerts, but maintains all historical data. At some point in time, you may want to delete the legacy DataSources altogether, but consider this move carefully as all historical data will be lost upon deletion. For more information on disabling DataSources, see Disabling Monitoring for a DataSource or Instance.

Important: There are two legacy WinExchange DataSources that have been allowed to remain with the new set of DataSources (i.e. they have not been replaced): “WinExchange Processes” and “WinExchangeServices”. These should NOT be disabled. Both are universal across all Exchange versions and will continue working seamlessly.

Setup Requirements

The DataSources in this package rely on WMI or Perfmon to collect data from your Microsoft Exchange system:

  • WMI – Used by DataSources compatible with Exchange versions 2016 and 2019
  • Perfmon – Used by DataSources compatible with versions 2007, 2010 and 2013

Ensure that the appropriate access method (WMI or Perfmon) is enabled on the host.


Common steps for troubleshooting issues with Microsoft Exchange monitoring include:

  • Ensure WMI (or Perfmon for Exchange versions 2013 or earlier) is correctly configured on the host.
  • Ensure that the system.categories property for the host (as stored in LogicMonitor) is assigned the appropriate system category tag (i.e. MicrosoftExchange2007, MicrosoftExchange2010, MicrosoftExchange2013, MicrosoftExchange2016 or MicrosoftExchange2019).
    • If the system.categories property is not set correctly, check that the addCategory_MicrosoftExchange PropertySource is imported.
  • Open the addCategory_MicrosoftExchange PropertySource and run the Test AppliesTo and Test Script functions to check for execution errors.


Q: Why did LogicMonitor perform such an extensive overhaul of the now-legacy Microsoft Exchange (i.e. WinExchange*) DataSources?

A: The original Microsoft Exchange DataSources were developed and released many years ago. Maturity in the Exchange product (and LogicMonitor platform) have since given us many compelling reasons to restructure our Microsoft Exchange package. These reasons include:

  • Less reliance on AppliesTo scripting. Legacy DataSources rely heavily on the AppliesTo function of “isWindows()”. While once sufficient, the broadness of this function now creates incompatibility issues.
  • Better version compatibility. Beginning with Exchange 2016, Microsoft made deprecations and other changes to its performance counters. New DataSources were needed to account for these changes so that accurate data collection is maintained.
  • Improved Performance. The new DataSources take advantage of WMI for data collection for Exchange 2016 and 2019. This brings a big performance improvement over Perfmon queries, which were blanketly used previously and could result in high CPU usage, long execution times, and even timeouts. Additionally, all DataSources now leverage BatchScript which greatly improves execution time and resource usage.
  • Future Proofing. The new DataSources are more modularized and version aware. This provides more control over compatibility and eliminates the need for backward compatibility across all Exchange versions (current and future).

LogicModules in Microsoft Exchange Package

LogicMonitor’s out-of-the-box monitoring package for Microsoft Exchange contains the following LogicModules. Please ensure that all of these LogicModules are imported into your LogicMonitor platform.

Display Name



addCategory_MicrosoftExchange_PowerShell PropertySource Uses either remote PowerShell or a CIM session to identify if the Microsoft Windows host is running Exchange and sets the system.categories property to one of the following: MicrosoftExchange2007, MicrosoftExchange2010, MicrosoftExchange2013, MicrosoftExchange2016 or MicrosoftExchange2019.
addCategory_MicrosoftExchange PropertySource For Microsoft Windows hosts monitored by Linux-based Collectors only (hosts monitored by Windows-based Collectors will use the addCategory_MicrosoftExchange_PowerShell PropertySource instead), identifies if the host is running Exchange and sets the system.categories property to one of the following: MicrosoftExchange2007, MicrosoftExchange2010, MicrosoftExchange2013, MicrosoftExchange2016 or MicrosoftExchange2019.
Microsoft Exchange Info PropertySource Captures build and version metadata.
Exchange Processes DataSource Monitors resource usage metrics of Exchange processes.
Exchange Services DataSource Monitors the various Exchange services running on the host.
Exchange Active Directory Domain Controllers DataSource Monitors performance metrics across Exchange Active Directory Access Domain Controllers.
Exchange Calendar Attendant DataSource Monitors calendar attendant performance metrics.
Exchange Client Access Server DataSource Monitors Exchange Client Access Server (CAS) role stats.
Exchange Edge Transport Databases DataSource Monitors individual Exchange Transport Database metrics.
Exchange Edge Transport Database Instances DataSource Monitors Exchange Transport Database instance metrics.
Exchange Mailbox Database Instances DataSource Monitors individual Exchange mailbox database instance performance metrics.
Exchange Mailbox Databases DataSource Monitors individual Exchange Mailbox Database metrics.
Exchange Mailbox Overview DataSource Monitors the Exchange mailbox overall performance metrics.
Exchange Replication DataSource Monitors Exchange replication metrics.
Exchange RPC Client Access DataSource Monitors Exchange remote procedure call (RPC) metrics.
Exchange Transport Queue Overview DataSource Monitors aggregate transport queue metrics across all priorities.
Exchange Unified Messaging DataSource Monitors the performance metrics for Exchange Unified Messaging.

When setting static datapoint thresholds on the various metrics tracked by this integration package, LogicMonitor follows the technology owner’s best practice KPI recommendations. If necessary, we encourage you to adjust these predefined thresholds to meet the unique needs of your environment. For more information on tuning datapoint thresholds, see Tuning Static Thresholds for Datapoints.

In this Article: