Skip navigation

Product Blog

September 2017 Previous month Next month

In continuance of the great Q3 release from SolarWinds (NPM, NTA, NCM, UDT, IPAM, DPA, & SRM), I am excited to announce the Generally Availability of Virtualization Manager (VMAN) 8.0.  Over time, Virtualization Manager has incrementally evolved from a stand-alone virtual appliance to providing advanced integration to the SolarWind's monitoring stack. VMAN Orion allows for a single pane of glass for troubleshooting (AppStack ), root cause analysis (PerfStack), and VMAN features found only on Orion (predictive recommendations).  In VMAN 8.0 we have taken this a step further by providing native VMAN functionality in Orion while removing the virtual appliance requirement.  Our goal with the release was to improve ease of use while strengthening VMANs ability to find and resolve problems in the virtual infrastructure.  The VMAN 8.0 download can be found in the SolarWinds customer portal.

 

Native VMAN Polling on Orion

It is now possible to download and install VMAN much like you would for SAM & NPM without upgrading and maintaining the VMAN appliance.  If you are currently integrated, it is extremely simple to migrate your VMAN polling to Orion by going to Virtualization Settings VMware Settings (or Hyper-V Settings).  Just select the vCenter or Hyper-V host to switch polling over and choose VMAN Orion Polling from the Polling Method drop-down menu.  In VMAN 8.0 there are 3 different polling methods that you will notice.

  • Basic - This is the general polling performed by SAM & NPM and does not require a VMAN license but it will require a SAM or NPM node license. ***Note - you can still use the basic polling method if you only have VMAN polling since the VMAN license is allocated node licenses equal to the socket count in your VMAN license, (e.g. 64 socket license = 64 node licenses).
  • VMAN Appliance - This is the traditional VMAN polling which occurs from the virtual appliance and requires that the appliance is integrated with Orion to get full VMAN functionality in Orion.
  • VMAN Orion - Full VMAN polling that occurs from Orion and does not require the VMAN appliance but does require a VMAN license

 

 

In addition to the new polling method in VMAN 8.0 we have added the ability to scale out your VMAN polling using the Additional Polling Engine (APE) framework for free.  No additional polling engine license is required to run with VMAN infrastructure monitoring.

 

Batch Execution of Recommendation Actions

The time it takes to optimize your environment has been drastically reduced with the ability to quickly select and batch multiple recommendations to execute immediately or schedule for a later time through just a few clicks.

 

VMAN will automatically configure the correct order of operations in which to perform the actions based on your selections.

 

 

Management action based recommendation policies

 

New policies in Virtualization Manager allow for greater control and precision over the recommendations which optimize your environment.  Create granular policy exclusions based on recommended actions for CPU, Memory, VM & Storage Migrations.

The new policy becomes available by selecting the Disallow Actions for Recommendations and then selecting the scope (vm, host, cluster, or datastore) to apply the policy against.  Then select the actions to exclude from recommendations for the scope chosen above.

  • Move VM - Actions based on VM movement/placement to a different host or datastore.
    • Move VM to a different host
    • Move VM to a different Datastore
  • Configuration - Modification of the VM memory or vCPU configuration
    • Change CPU Resources
    • Change Memory resources

 

 

PerfStack 2.0 - New Features & Improvements

With VMAN 8.0 we also get a new and improved version of Perfstack that continues to build on the tenants of SolarWinds to help dig into problems faster and identify true root cause across different IT disciplines.

    • Links from VM & Host Details that populate the PerfStack palette
    • Zoom into PerfStack charts to view more detail for the selected time period
    • Data ExplorerAlert visualization improvements
      • Export PerfStack data to Excel
    • Alert visualization improvements
      • Each individual alert start/end time is now visualized separately in PerfStack
      • Existing aggregate alert visualization against an object is retained
    • Export PerfStack data to Excel
    • Easier to share PerfStack dashboards with the new ‘Share’ button.
    • PerfStack 2.0 - Real-Time Polling

You can get to PerfStack from within the VM details page in three different spots (we wanted to make sure you didn't miss it.)

  • Virtualization Manager Tools
  • Virtual Machine Details
  • Resource Utilization

 

 

View of the PerfStack palette pre-populated with metrics of the VM.

 

 

WEB INTERFACE IMPROVEMENTS

 

 

NEW INSTALLER UPGRADE EXPERIENCE

    • Install and upgrade one or more Orion Platform products simultaneously
    • Modern interface with a simplified design and intuitive workflow
    • Downloads and installs only what is needed
      • Reduces download size & accelerates installation

 

 

Windows Authentication & SSL Encryption for Orion Microsoft SQL Database connectivity

 

 

Documentation

Virtualization Manager (VMAN) - SolarWinds Worldwide, LLC. Help and Support

 

VMAN 8.0 Release Notes - SolarWinds Worldwide, LLC. Help and Support

NPM 12.2 was made available in the Customer Portal on September 13th!  The release notes are a great place to get a broad overview of everything in the release.  Here, I'd like to go into greater depth on  Network Insight for ASA including why we built it and how it works.  Knowing that should help you get the most out of the new tech!

 

Network Insight

We live in amazing times.  Every day new technologies are invented that change how we interact, how we build things, how we learn, how we live.  Many (most?) of these technologies are only possible because of the relatively new ability for endpoints to talk to each other over a network.  Networking is a key enabling technology today like electricity was in the 1800s and 1900s, paving the way for whole wave of new technologies to be built.  The better we build the networks, the more we enabling this technological evolution.  That's why I believe in building great networks.

 

A great network does exactly one thing well: connects endpoints.  The definition of "well" has evolved through the years, but essentially it means enabling two endpoints to talk in a way that is high performance, reliable, and secure.  Turns out this is not an easy thing to do, particularly at scale.  When I first started maintaining, and later building networks, I discovered that monitoring was one the most effective tools I could use to build better networks.  Monitoring tells you how the network is performing so you can improve it.  Monitoring tells you when things are heading south so you can get ahead of the problem.  Monitoring tells you if there is an outage so you can fix it, sometimes even before users notice.  Monitoring reassures you when there is not an outage so you can sleep at night.

 

Over the past two decades, I believe as a company and as an industry we have done a good job of building monitoring to cover routers, switches, and wireless gear.  That's great, but virtually every network today includes a sprinkling of firewalls, load balancers, and maybe some web proxies or WAN optimizers.  These devices are few in number, but absolutely critical.  They're not simple devices either.  Monitoring tools have not done a great job with these other devices.  The problem is that we mostly treat them like just another router or switch.  Sure, there are often a few token extra metrics like connection counts, but that doesn't really represent the device properly, does it?  The data that you need to understand the health and performance of a firewall or a load balancer is just not the same as the data you need for a switch.  This is a huge visibility gap.

 

Network Insight is designed to fill that gap by finally treating these other devices as first class citizens; acquiring and displaying exactly the right data set to understand the health and performance of these critical devices.

 

Network Insight for Cisco ASA

Network Insight for Cisco ASA is our second installment in the Network Insight story, following Network Insight for F5.  As you saw with F5, Network Insight for ASA takes a clean slate approach.  We asked ourselves (and many of you) questions like:

 

  • What role does this device play in connecting endpoints?
  • How can you measure the quality with which the device is performing that role?
  • What is the right way to visualize that data to make it easiest to understand?
  • What are the most common and severe problems that occur with this device?
  • Can we detect those problems?  Can we predict them?

 

With these learnings in hand, we built the best monitoring we could from the ground up.  Let's take a look at what we came up with.

 

Access Lists

 

ACLs define what traffic is allowed or blocked.  This is the most essential task of the firewall and monitoring tools generally don't provide any visibility.

 

The first thing we found here is there's no good way to get all of this data via SNMP.  We have to pull the config and analyze it.  For that reason, we handed this piece off to the NCM team to work on.  You'll see a post here in the product blog shortly covering this!

 

 

Site to Site VPN

 

Site to site VPN tunnels are the next most important service that ASAs provide.  They are often used to connect offices to data centers, data centers to cloud providers, or one organization to a partner.

 

Yesterday, you could monitor these tunnels by testing connectivity to the other side of the tunnel, for example an ICMP monitor to a node that can only be reached through the tunnel.  Today, we poll the ASA itself via SNMP and API to show a complete picture including:

  • What tunnels are configured?
  • Are my tunnels up or down?
  • If a tunnel is up:
    • How long has the tunnel been up?
    • How much bandwidth is being used by the tunnel?
    • What protocols are securing the traffic transiting the tunnel?
  • If a tunnel is down:
    • How long has the tunnel been down?
    • What phase did the tunnel negotiation fail at?

 

 

 

This means we automatically detect and add VPN tunnels as they're configured or removed and constantly keep an eye on these very important logical connections.  I'll highlight a couple interesting things.

 

Favorites

 

We're introducing a simple new concept called favorites.  Marking a tunnel as a favorite by clicking the star on the right does two things.  First, you can filter and sort based on this attribute.  The page by default shows favorite tunnels first, so you will always see your favorites first until you change the sorting method.  Second, it promotes that tunnel's status to the summary screen.  We found for most ASAs there were a couple of VPN tunnels that were wildly more important than all of the other tunnels.  Here at SolarWinds HQ for example, it's the tunnel to the primary data center.  At the primary data center, it's the tunnel to the secondary data center.  Favorties provide a super easy way to add extra focus to the tunnels that are so important that a big part of the story of the health and performance of the ASA is the health of the tunnels themselves.

 

 

Tunnel Status

What is the status of the tunnel?

 

Turns out this is a harder question to answer than it looks.  Tunnels are established on-demand.  If you just configured a tunnel, but have not sent any interesting traffic so the tunnel is not up, should we show it as down (red)?  That doesn't seem right.  What if the tunnel was up for 3 months, but interesting traffic stopped coming so the tunnel timed out and went back down, but is prepared to come back up as soon as interesting traffic is seen?  The tunnel is definitely "down", but should it be red?  Probably not!  We spent a lot of time thinking about this and talking to you guys to determine the logic that decides if an administrator considers a tunnel down, up, or something in between.  All of that logic is built into the statuses you see presented on this page.

 

Phases

For years, my first troubleshooting step on a tunnel that was down was to review logs and find out what phase negotiation failed at.  This tells you what set of variables you need to review for matching against your peer.  I'm very pleased that this first data point is now right in the monitoring tool that identified the tunnel as down to start with.  I hope it helps you guys get your tunnels back up faster.

 

 

Remote Access VPN

 

When users connect to the office using a software VPN client on their laptop, Cisco calls that Remote Access VPN.  As with Network Insight for F5, we are careful here to use the same terms as the manufacturer so it's easy to understand what we're talking about.

 

Again, we have to use both SNMP and API to get all the data we need to answer the following questions:

  • Who's connected?
  • Who tried to connect in the past, and what was the result?
  • How long have they been connected?
  • How much data have they uploaded and downloaded?
  • What is their session history?

 

 

Again, I'll highlight a few things.

 

List View

One of the challenges is the sheer number of remote access connections there are.  We know we do not do good enough job at dealing with very large lists today and our UI Framework team has been working on solving that.  This page is one of the first implementations of the new List View that they created.  This list view gives you the tools to easily deal with very large lists.  The left side of the screen lets you filter on anything shown on the right.  The filters available are considerate of the data and values seen on the right, so we don't have useless filters.  You can stack several filters and remove them individually.  Finally, after filtering your list you can still sort and search through those filtered results to further hone your list.

 

 

You'll see this list view a lot more as time passes.

 

Interfaces

 

Whereas interfaces are the main story on a switch or router, they're an important secondary story on an ASA.  We rebuilt the interfaces view from the ground up based on the List View.  Along the way, we made sure we were building it for a firewall.

 

 

NAMEIF

As my fellow ASA Administrators know, nameif is not a typo.  Nameif is the command you use to specify the name of an interface on an ASA.  A nameif must be configured for an interface to function, and from the moment you specify the nameif onward, every other element in the interface references the nameif.  ACLs, NAT, you name it.  In other words, the identity of an interface on an ASA is its nameif (like CPLANE or OUTSIDE), not it's physical name (like GigabitEthernet0/2).  Accordingly, that is the primary name shown here, with the physical interface name shown only if the interface isn't in use and doesn't have a nameif.

 

Access Lists

If you have NCM to pull access lists from configs, we will identify which access list is applied to each interface and provide a link to review the access list.  This is super convenient in practice.

 

Security Level

Security levels have some control over what traffic the ASA allows.  It also provides a quick indicator of how much the administrator trusts the network connected to a specific interface.  Kind of important things for a firewall.

 

Favorites

Again, we're using the simple favorites concept.  I expect a lot of ASAs to have the interface connected to the Internet favorited!

 

 

Platform

 

All of the things described above are technology services that are built on a platform.  The platform must be healthy for the services to have any chance of being healthy.  The platform sub-view helps you understand the health of the platform.

 

 

High Availability

While high availability is a feature of many platforms, it seems to be particularly popular on ASAs.  Additionally, it seems Administrators have to fiddle with it a lot.  Administrators have to failover to perform software upgrades, some choose to failover to change circuits, failover to upgrade hardware, failover for all sorts of reasons.  While I'm concerned we are all using failover so often, it is clear that NPM has to provide great coverage for H/A.

 

In speaking with lots of ASA administrators we found several different behaviors.  Some administrators were unaware of whether their ASAs were really ready for failover or not.  Some check manually every once in a while, but have had an active ASA go down only to discover failover could not occur.  Some expert administrators were checking failover status, but were also checking the quality of failover that would occur by verifying configuration synchronization and state synchronization.

 

Our H/A resources takes the best practices we found were being manually used by expert administrators, automates the monitoring of them, and presents simple conclusions in the UI.  If everything is green, you get simple checks and a phrase explaining what is healthy.  If something goes wrong, you get a red X more verbose explanation.  For example, if the standby is ready but the config is not in sync, failover can occur but the behavior of the firewall may change.  Maybe your last ACL change was not copied to the standby, so it doesn't apply if there is a failover.  If standby is ready but connection state information is not synced, failover can occur but all of your users will have to restablish their connections.  Not good!

 

Of course you can alert on all of these things.

 

Connection Counts

Firewalls store information about each connection that is actively flowing through them at a given moment.  Because of that, there is a limit to how many concurrent connections they can handle, and this is one of the primary values used to determine what size firewall you need to buy.  It's obvious then that it should also be a crucial part of how we understand the load of the device in addition to RAM and CPU, so we've included it here.

 

Aggregating connection failure rates is an interesting way to get an indicator that something is amiss.  Perhaps your firewall is blocking a DDOS or maybe a firewall rule change went awry.  Watching this one value can be a leading indicator of all sorts of specific problems.

 

Summary: Putting it all Together

If we've done our job, we're providing comprehensive coverage of the health and performance of an ASA on all of the sub-views.  Now, we pull all the information together and summarize it on the Summary page.

 

 

Details Widget

One of the things that really weighed down the Node Details page for most nodes was the Details resource.  This resource has historically been a catch all for lots of little bits of largely static data users have asked us to show on this page.  The problem is that it kept growing and eventually took up nearly half the page with data that actually wasn't that commonly needed.  Here we have rebuilt the resource to focus on the most important data, but with the additional data available within the "other details" drop down.  This also allowed us to move away from the archaic pattern of Name:value pairs in our UI.  Instead, we describe the device as your peer would.  You can see how the resource reads more like "this is <hostname>, the <context name> context on a <hardware model> running <software version>".

 

Also, did you know that what we called "resources" in the previous UI framework are called "widgets" in the new UI Framework?  There's your daily dose of useless trivia!

 

PerfStack Widget

Did you notice it?  The Load Summary and Bandwidth widgets on this page are powered by PerfStack charting.  Try clicking around on them.  It's oh so pleasant.  More to come on this later.

 

Favorites

The Bandwidth and Favorite Site-to-Site VPN widgets display information about the components you identified as your favorites on the other pages.  I think it's about time we recognized that all VPN tunnels and all interfaces are not equally important.  Some are so critical that their status alone is a big part of the answer to the question: how is the firewall running?  Favorites makes it easy to give them the attention they deserve.

 

Setup Network Insight for ASA

 

To get this visibility in your environment, jump on over to the customer portal to download the new version.  After upgrading your NPM instance, the new ASA monitoring should "just work," but here's the specifics just in case.

 

Already monitoring ASAs?

The new monitoring will start up automatically.  Give the new version a couple minutes to poll and jump over to Node Details for one of your ASAs.  You'll get a bunch of new information out of the box.  For complete coverage as seen in the screenshots above, you'll be prompted to edit the node, check the "Advanced ASA" monitoring check box, and enter CLI credentials.  Make sure to look at the sub-views (mouse over to the left)!

 

There is one caveat.  If you've assigned a custom view to your ASAs, we will not overwrite that!  Instead, you will have to choose to manually change the view for your ASAs over to our new view.

 

Adding a new ASA?

 

Simply "Add Node" and select the "Advanced ASA" monitoring check box on the last step to enter CLI credentials.  That's it.  Give it a few minutes and check out the Node Details page for that ASA.

 

Conclusion

 

That does it for now.  You can click through the functionality yourself in our online demo.  I'd love to hear your feedback once you have it running in your environment!


 

 

No need for liederhosen or giant mugs of beer to have a good time.  Just sign up for the SAM 6.5 beta.

 

Of course if you want an idea of what's in the beta, just refer to WHAT WE'RE WORKING ON BEYOND SAM 6.4

 

The beta is now open, so turn on some oompah music get started here.

For those of you familiar with the Enterprise Operations Console, you may be familiar bshopp previously written, similarly titled article , which explains the function and purpose of EOC.  That article was a big hit among users so I have decided to write up something similar for our latest release of EOC 2.0 which is now available.

 

When discussing the Orion Suite of products with customers, we often get the question, “how does Orion scale?”  Customers these days may have very different reasons for asking this question or different ideas of what scale means to them.

 

The answer is that SolarWinds provides multiple methods available for customers to choose from:

  1. Scaling horizontally or scaling up - If customers are scaling the number of elements within a single instance of Orion, SolarWinds provides the use of Additional Polling Engines to quickly expand the overall capacity.
  2. Scaling out - Whether it is the way in which the client runs their business such as a MSP, a customer has acquired additional instances of SolarWinds due to mergers or acquisitions, or any other number of reasons, customers may have what we refer to as a distributed model of deployment.  This means the clients environments consist of multiple separate Orion Instances running throughout their infrastructure.  The Enterprise Operations Console is the perfect tool to roll up data from each distributed instance.

In this post, we are going to discuss the Enterprise Operations Console 2.0 or EOC for short.  Take the below first graphic, you have a worldwide network with teams responsible for managing their respective region, so an Orion installation resides in each; North America, EMEA and APAC. EOC’s main functionality is to aggregate data from multiple Orion server installations and display that data in a similar fashion as the Orion Web Console. As an example, the global NOC/ Management Team may require a comprehensive view of all entities into a single dashboard for a representation of status, current alerts, and need the ability to run reports across the worldwide environment.  The Enterprise Operations Console provides this visibility for you. Administrators even have the ability to create customized accounts and restrict what data each Orion EOC user is permitted to see. These restrictions can be set on an individual basis by customizing user settings and on a group basis by defining roles.Now, the EOC 2.0 web console has changed slightly from the prior version as you can see in the screenshots below.  The previous version of EOC is on the left, and the latest version of EOC is depicted below on the right.

EOC.jpg

Below is a quick touch on some of the new features and improvements.  Stay tuned for more posts with additional details around these features.

  • Improved Data Collection: Live on-demand polling and immediate display of data from distributed Orion Instances. (Discussed more below)
  • Improved & Updated UI:  EOC 2.0 is now built on the same framework as other members of the Orion product suite.  This provides:
    • An improved UI, with familiar navigation, icons, and controls.
    • Access to Orion features such as High Availability including multi-subnet deployments (WAN/DR), and the ability to implement Additional Web Servers with EOC.
  • New Status Rollup: View status of any Orion entity from distributed Orion sites with the unique Enterprise Summary Tiles.
  • Improved Search Functions: Utilize Search integrated into the Navigation or utilize the Asset Explorer for pre-filtered searches within Enterprise Summary Tiles.
  • New Alert Options: Input notes and acknowledge alerts from EOC.
  • Global Reporting: Create and customize global reports with easy selection of desired sites.
  • New Map Options: Import Maps from Orion Instances to display status in EOC NOC view.  Use the WorldMap resource to display consolidated view across the distributed environment.
  • PerfStack™ in EOC: Perform advanced analysis of issues by pulling entity data from multiple sites into a single PerfStack™! 

Note:  There is no upgrade path from EOC 1.6.x to EOC 2.0.  You may run both these versions in tandem if desired, however EOC 2.0 will require a fresh install on a new server and a new database.These changes were done based on feedback from you, our users, who were looking for an update to the UI, more flexibility with the tool, and something up to the standards the rest of the Orion Platform has executed upon with recent enhancements. One of the common misconceptions about EOC is that it pulls all the data from each of your Orion servers into the EOC database.  In actuality, EOC pulls high-level information such as current status, alerts, events, and more.  Investigating further or drilling into elements within the EOC web console would then seamlessly redirect users behind the scenes to the local Orion instance that entity is actually being monitored from. Let's walk through an example.  Below you can see that I have a number of issues in my lab environment, and I will select a node entity that is in warning.  This will populate the asset explorer with a pre-filtered list, and drilling into the device will actually take me to the device details page on the local instance where that node is being monitored from:I can now continue further investigation or go right back to my EOC global view.Now that we have gone through a high-level of what EOC is, let's dig deeper into how it works.  In versions of the Enterprise Operations Console prior to 2.0, EOC contacted remote Orion instances at regular polling intervals in which it collected all current statistics based on the most recent polls.  So by default, every 5 minutes, large subsets of data were retrieved from the remote sites and stored into the EOC database.  The overview of the previous version can be reviewed here:  What is the Enterprise Operations Console (EOC) & how does it work?The problem was that even with decreasing the polling intervals, we were never able to achieve real-time polling or real-time display of that data within EOC.  Very often, the data presented was well behind what was actually being detected at the local instance/site.Delays in status and alert notification presented a serious problem for EOC users, therefore resolving this issue was extremely critical.  EOC 2.0 now leverages a function called SWIS federation which executes only the queries necessary determined by the content of the page being viewed.  In essence, Federated SWIS allows us to pull only the data we need, when we need it. Depicted below is a more technical breakout of this first image.  Each instance may contain different products, may be different sizes, and may be geographically dispersed. With EOC 2.0, remote Orion SWIS services register themselves with EOC's federated SWIS service, thereby exposing their data through a single SWIS interface.  When a user/client accesses the website and performs a function, a SWQL query is sent to SWIS on EOC.  Here it is analyzed to determine what servers can satisfy the query.  SWIS will then exclude any servers that are not necessary, forward the query to the appropriate Orion SWIS instances, combine the results from each, and send the aggregated results back to the client. This process is completely transparent to the user and is able to run much more efficiently over constantly pulling copies of data, from each instance, into a database, and then running additional queries to provide the results.  Federated SWIS performs all the heavy lifting, aggregating the data, and allows us to display that data exponentially faster than we were able to before. EOC 2.0 will be able to highlight Alerts, Events, and Status from any of the following entities:

  • Applications
  • Components
  • Groups
  • Interfaces
  • IP SLA Operations
  • LUNs
  • NAS Volumes
  • Nodes
  • WPM Player locations
  • Pools
  • Ports
  • Providers
  • Storage Arrays
  • Transactions
  • Virtual Clusters
  • Virtual Datacenters
  • Virtual Hosts
  • Virtual Machines
  • VCenter Servers
  • Volumes
  • And more...

 

Stay tuned for more posts highlighting the new feature/ functionality and enhancements made to EOC in the Enterprise Operations Console  forum. 

We’re happy to announce the release of SolarWinds® Exchange Monitor, a standalone free tool that provides a view of your Microsoft® Exchange Server performance.

Exchange Monitor gives your team insight into metrics, services and Database Availability Group (DAG) status. This tool supports Exchange Server 2013 and 2016.

 

Metrics monitored by Exchange Monitor:

  • Total Service IOPS (count)
  • Host Used CPU (%)
  • Host Used Disk (%)
  • Host Used Memory (%)
  • I/O Log Writes Average Latency (ms)
  • I/O Log Reads Average Latency (ms)
  • I/O Database Writes Average Latency (ms)
  • I/O Database Reads Average Latency (ms)
  • Outstanding RPC Requests (count)
  • RPC Requests Failed (%)

Services monitored by Exchange Monitor:

  • Active Directory Topology
  • DAG Management
  • Exchange Replication
  • Information Store
  • Mailbox Assistants
  • Mailbox Replication
  • Mailbox Transport Delivery
  • Mailbox Transport Submission
  • Search
  • Service Host
  • Transport
  • Unified Messaging

DAG info:

  • Databases (count)
  • Current Size (GB)
  • Total DB Copies (count)
  • Disk Free Space (GB)
  • List of servers belonging to the DAG and their health status

 

 

Exchange Monitor gives you the ability to add as many Exchange Servers as you wish. Simply click the “Add Server” button and fill IP address/domain name and credentials. The only limitation when adding a new server is, that you cannot add 2 servers from the same DAG. Monitoring multiple servers from the same DAG can be achieved only with Server & Application Monitor (SAM).

Once you add a server to Exchange Monitor, it will load polling interval, metrics with thresholds and services to monitor from global settings. You can edit these settings locally – per server. When looking at server details page, click the COMMANDS button in the top – right corner and select “Manage Metrics”.

 

You can then fine-tune your thresholds for this server only. Here you can also turn off metric, if you do not wish to monitor it. When you do not monitor a metric, you will not get any notifications about this metric.

 

If an Exchange Server belongs to DAG, you’ll see Database Availability Group (DAG) resource on the server details screen. Bottom part of this resource contains information about all servers belonging to this DAG and their health status. You can inspect status of these servers by clicking on “Show All” button.

 

Hovering over these servers will give you additional information about Content Index State and Copy status of the databases assigned to this server.

 

 

 

What else does Exchange Monitor do?

  • Allows you to add as many Exchange servers as you wish (with limitation to monitor only 1 server per DAG)
  • Creates notification every time, when metric goes over threshold, service goes into non-running state or DAG is not healthy

       

 

  • Can write all notifications into Event Log.
  • Allows you to set your polling interval (how frequently you want to receive data from Exchange Server) per server
  • Allows you to set thresholds, metrics to monitor and services to monitor per server

    

 

 

For more detailed information about Exchange Monitor, please see the SolarWinds Exchange Monitor Quick Reference guide here on THWACK®: https://thwack.solarwinds.com/docs/DOC-191309

Download SolarWinds Exchange Monitor: http://www.solarwinds.com/exchange-monitor

Filter Blog

By date: By tag: