Skip navigation

Product Blog

4 Posts authored by: jmeredith Employee

Companies are moving their email to cloud in droves.

Let's face it, administering Microsoft Exchange is one of those jobs that when everything goes right, no one knows you exist.  And when things go wrong, everyone knows you exist. The good news is that many companies are offloading their Exchange to Microsoft through the use of Microsoft Office 365.  If you doubt that Office 365 is big, consider that in July of this year Office 365 online workplace tools brought in more revenue than the traditional version of Office that’s installed on people’s computers. When you think about it, e-mail server replacement is the perfect SaaS application.  It's well defined without huge deviation from one organization to the next, scales well across multiple servers, needs to be accessible from anywhere and often needs permanent retention of records.  All things that the cloud is good at.


Moving to the cloud means I'll never have to worry about email again, right?

It's important to remember that while moving to the cloud alleviates your responsibility for the servers that run e-mail, you still are responsible for monitoring the e-mail itself and your company's connectivity to the cloud.  Monitoring cloud-based applications is different than monitoring on-premises applications.  Where you may have been concerned with memory and disk capacity on your servers, or server-to-server communication in the past.  Those are not concerns with SaaS.  But some potential issues still exist.    Here are just a few of the metrics you may need to be concerned with in an Office 365 environment:


  • Portal Access - Rather than server availability, it's important to know portal availability. This includes the user portal, the administration portal and the billing portal.  These may each be used by different users in your company but are all important.
  • Forwarded Exchange Users -  Are these mailboxes really necessary?  Are they violating company or government policies? What if a healthcare worker is forwarding messages containing patient information to a personal account, for example? 
  • Inactive Exchange Users - While sometimes you may keep a user's mailbox for a period of time after they are gone, sometimes you just forget to delete them and are paying for unneeded accounts.
  • Groups Accepting External Email - Do you really want external entities to be able to bulk mail these groups?
  • Top Senders - This is a handy metric for telling if your accounts have been hacked and are being used by spammers.
  • Administrative Roles - Did the number of administrators change unexpectedly? 
  • License Usage - Get a handle on how quickly your license usage grows.  How many licenses are being used?  What percentage of my total?  You still need capacity planning for SaaS, just a different type of capacity.
  • Last Password Change - Number of users with a password that is 90 days old or more.  How many users have a password that never expires?
  • User Mailbox Security - How many users have access to a large number of mailboxes?  Should they? 


Earlier this year, in collaboration with Loop1 Systems, we developed a set of templates for Microsoft Office 365 to monitor these and much more.  The templates have been very popular with customers, but there are a few things you can do to improve their implementation and function. Since these templates monitor Software as a Service, they aren't exactly like other templates that we typically provide.


Microsoft Office 365 is Software as a Service and it doesn't run on any of your servers.  What node should you apply the template to?

Since these templates are PowerShell scripts that run against a Microsoft URL, the best solution is to create an external node and apply the templates to it.  You can use "" as the node.   This is the URL for the mail API requests.  Technically for the Portal, Subscription, Security Statistics and License Statistics templates the scripts use "", but splitting the Office 365 templates between two nodes can be confusing and forces the SAM user to understand which components of the service reside on each node.


You can also use an ICMP node rather than an external node

External nodes don't report status.  By using an ICMP node, you will get a rudimentary status indication on the node icon based on a ping of the URL.  External nodes give no status and always display a purple "arrow" icon without status.  However the URL "" doesn't seem to respond to ping requests so it will always appear to be down if you point an ICMP node there.  Here is the external icon vs. the ICMP node icon.

Get a real picture of Office 365 availability with NetPath

Another way to determine the responsiveness of the Office 365 application is to set up a NetPath service for "".  If you have NetPath, you can use it to get a detailed view of the bottlenecks between your site and the application portal.


Improving responsiveness to queries by polling less frequently

Depending on the number of mailboxes in your environment and the number of templates implemented, you can experience throttling of your API requests from the Office 365 API.  If you are throttled, the choices are to either run less component monitors or reduce your polling frequency on some templates.  Most users can actually reduce the polling frequency substantially on most or all Office 365 templates since the majority of the metrics don't change frequently.  One thing to keep in mind is that if you want to ensure enough data points to avoid gaps in history, you might want to use less than an hour for your polling frequency, so try setting the frequency to 1200 (20 minutes) rather than the default of 300 (5 minutes). If you want to know more about Microsoft API throttling, see Avoid getting throttled or blocked in SharePoint Online | Microsoft Docs for a description.  The article is about Sharepoint but the concept is the same for Office 365.


I don't like the output of the detailed data from the templates.  Can I make it more readable?

The data comes back from the API in a comma-delimited format which is great for programming but not so readable.  To make the data more readable, you can modify your own copies of the scripts as follows:


[string]::Join( ", ", $users) 


[string]::Join( "< br/>", $users)

NOTE: You should be aware that this modification is injecting HTML directly into the output from the PowerShell script.  When viewed on the SAM console it will display correctly.  However, this change could create unexpected results in other areas of SAM that are not displayed on a web server, such as reports.


Comparing Exchange 2013/2016 templates with the Office 365 template.  They are both Exchange, why are they so different?

Since Office 365 is SaaS, many of the metrics in our previous Exchange templates is either not available or not meaningful.  Metrics like disk I/O and disk latency aren't available for a cloud service where the hardware is abstracted away from the user.  Similarly attempting to monitor processes and services on the hosts is not possible.  Primarily with Office 365 we monitor application data, which is available through the Office 365 API.


There was a MAPI round trip template available for Exchange.  Can I run this template against Office 365?

The MAPI round trip template was intended to check connectivity between multiple Exchange servers.  Since Office 365 is SaaS, you don't control the physical servers that are used for your accounts.  With cloud-based applications, you should check connectivity between your network and the Office 365 website.  You can get a sense of this connectivity by using the portal templates and the ICMP option discussed above.  Also as mentioned above, you can use NetPath to show the actual path your connections take to Microsoft.  Another option is to use Web Performance Monitor to record a typical mail transaction and get perspective on each part of the session.


A comprehensive approach to monitoring Microsoft Office 365

Hopefully, this post has given you some ideas about why and how to monitor Office 365. SolarWinds offers many tools to help you from SAM templates to network tools to user simulation.

If you're one of the many customers that tried the beta or release candidate, you've already seen many of the exciting new features in SAM 6.5. For the rest of you, here are more details about what's new:


Azure Cloud Infrastructure Monitoring

Just as SAM 6.4 directly accessed the world's largest cloud, SAM 6.5 expands your ability to leverage multi-cloud further by adding support for Microsoft Azure accounts in addition to Amazon AWS.  While Amazon Web Services remains the largest cloud infrastructure provider, Microsoft is growing in this market at an incredible rate.  And many customers have a footprint in both.  Now you can see Azure or AWS accounts, or a mixture of both in the same view.

Cloud-related enhancements include:

  • Add or edit your AWS/Azure Account using new UI

  • Choose Instances/VMs for AWS/Azure Accounts
  • Poll Azure VMs for performance metrics
  • A single Cloud Summary page displays data for instances/VMs for multi-cloud environments

  • Monitor Azure VMs as Orion nodes to leverage the extended features of the Orion Platform and SAM for application and OS monitoring, including expanded metrics

PerfStack 2.0 — New Features and Improvements

  • Navigate directly from Application Detail pages to predefined sets of application monitor metrics

  • Use pre-defined links from these pages or create your own custom PerfStack charts from a broad range of metrics such as these from the Azure cloud:

  • Zoom into PerfStack charts to view more details for a selected time period
  • 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
  • Share PerfStack functionality to make it more discoverable with new Share button
  • For more on PerfStack improvments, see Orion Platform 2017.3 - PerfStack New Features & Improvements

New Orion Installer

  • Install and upgrade one or more Orion Platform products simultaneously
  • Modern interface with a simplified design and intuitive workflow
  • Download and install only what is needed
  • Reduces download size and accelerates installation
  • For more on the Installer improvements, see New Installer Upgrade Experience

Other Improvements

  • New SAM templates for Microsoft Office 365 are included out of the box.  Microsoft is the leader in Software as a Service, and Microsoft Office 365 is gaining adoption with companies of all sizes.
  • Linux Agent for ARM-based devices such as Raspberry Pi to help you manage your Internet of Things (IOT)
  • Updated SAM templates for many Microsoft products
  • Search function integrated into global navigation
  • Improved dashboard view customization and Manage Nodes page
  • Support for High Availability (HA) 2.0 including multi-subnet deployments (WAN/DR)


What Else?

Don't see what you are looking for here? Check out the What We're Working On Beyond SAM 6.5 post for what our dedicated team of database nerds and code jockeys are already looking at.  If you don't see everything you've been wishing for there, add it to the Server & Application Monitor Feature Requests



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.

Don't have time to read this article and just want to try out the example template?  You can download it here Docker Basics for Linux



As I discuss cloud utilization with customers, one subject that often comes up is Docker.  Many customers are using cloud servers as Docker farms, or to supplement their on-premise docker footprint.  OH!  There's that hybrid IT thing again.


Since some of our readers may be devops people without experience in SAM, I'm going to explain every step in detail.


We watch applications in SAM with templates.  An application template is simply a collection of one or more component monitors. Today we are going to create a simple Docker template as an example of what you can do to monitor docker.


To monitor Docker we are going to:

1.  Build a Docker Server

2. Use the Component Monitor Wizard to create component monitors for critical Docker processes and generate the base template.

3. Create a script Component Monitor to query Docker for critical metrics and insert that Component Monitor into the template from step 2.


Build a Docker Server (step 1 of 3)

First we need to load Docker on a target server.  I won't bore you with instructions about that.  If you need help installing, refer to the documentation from Docker themselves at Docker Documentation | Docker Documentation .


The next step is to manage the node where we installed Docker with SAM (if it wasn't already managed).  If you're using Linux, I'd recommend installing the Linux agent when you set up the node.  Again, this is well documented in the SolarWinds documentation starting here Agent deployment .


Now that we've got a Linux node with the Solarwinds agent and Docker installed, we are ready to build a template to monitor it.


Start with a Process Monitor type component monitor (step 2 of 3)

In order to monitor an application we have to decide what to look at on the target node.  I'm talking about basic availability monitoring by ensuring that the service/process is up.  We accomplish this with either a service or process component monitor.  Using a Service or Process monitor is a best practice when creating a new template.


SAM offers Windows Service monitors along with Windows or Linux Process monitors.  In this example I'm targeting an Ubuntu server running Docker, so I'll use a Linux Process Monitor.


The easiest way to create a component monitor is using the Component Monitor Wizard.  Sometimes new users miss this option because it's located at Settings->All Settings->SAM Settings->Getting Started with SAM. 



In the wizard, I will choose Linux Process Monitor and click "Next"


Now we get to the reason it was so important to have an application node set up and defined in SAM before we started.  The next screen allows us to enter the IP address of the Linux server I set up earlier.  In this case, it's a 64-bit operating system. Be sure to change the 32-bit setting to 64-bit.  Once again, click "Next"


This is where the power of the wizard becomes evident.  You will see a list of the processes on the target server with empty checkboxes next to them.  Just check the processes associated with Docker (in this case dockerd and docker-containerd), then click "Next".

(For more about why Docker split the docker engine into two pieces, take a look at Docker containerd integration - Docker Blog .)


Now our component monitors have been created.  You can optionally check the boxes to the left and test them now.  Since the wizard actually had found the processes previously on the test node, the test should pass.  Just click "Next" again.

You can either create a new application template with these component monitors or add them to an existing one.  In this case we are going to create a new template called "Docker Basics for Linux".  It's a good idea to include the OS type in the name since we might run Docker on Windows in our environment later and we will want to know that this particular template is for Linux.  Also I included the term "Basics" since I get ambitious and write a more complex template later.


Click "Next" to continue to a screen where we can assign the template to SAM nodes.  The node we used for developing the template should be checked by default.  Just click "Next" again if that's the only node we are monitoring for now.


The final step is to confirm the creation of the component monitors.  Click "OK, Create" and you're done.

If you go to the SAM Summary page, you'll see your template has been applied.  Don't worry if it shows an "unknown" state at first.  It can take a few minutes to do its initial polling.  It should turn green once discovered.

That's it.  You're now monitoring Docker availability.


If you wanted to monitor Docker on Windows, you could have used a Windows Process Monitor or a Windows Service Monitor, which both work similarly.  This would provide the most basic information at whether Docker is even running on a target system.


Monitor Docker from the inside with a Script Component Monitor (Step 3 of 3)

For the next step, let's add some visibility into Docker itself.

Go to Settings->All Settings->SAM Settings->Manage Templates

You should see a list of all templates on your SAM system.  In the search box at the upper right corner, type "docker" and click "Search".  This should filter the list to only include the Docker template we created above.

Check the checkbox to the left of our template and click "Edit"


You should see the details of the template with the 2 component monitors we created earlier.

At this point, you can add a description and tags, or change the polling settings.  You can also change component monitors in the template.

Let's add a component monitor to show basic stats about Docker.  The easiest way to get those stats is to run the "docker info" command on the Linux server.

Wow!  That's a lot of information.  But how to do we get it into SAM?

Not to worry, SAM lets us run scripts and can collect up to 10 statistic/message pairs from the script.

Just select "Add Component Monitor" on the screen above and click "Submit".


Then select "Linux/Unix Script Monitor" (you may have to advance to the 2nd page of results) and click "Add".

Now you should see a new component monitor on the list that is opened for editing.

Enter a description and choose the authentication method and credentials. In this case I chose to inherit credentials from the node.  The script is basically run using ssh so port 22 must be open in any firewall configuration.


I entered a working directory of "/tmp" for any disk I/O required by SAM.


I also will rename the component monitor to something more meaningful.


The "command line" field will be set up for a perl script by default.  We are using a shell script so we will delete the "perl" part and replace it with "bash".

Next, click "Edit Script" to enter the actual script commands.


Insert a statistic into SAM with a bash script

In order to use a script with SAM, we are going to need to format the data in a very specific way.  SAM expects the only output from a script to consist of key/value pairs, separated by a ":", that either are a statistic or a message.  The key for statistics consists of the keyword "statistic" then a variable name, then ":"

For example if we were trying to capture number of containers, we would use Statistic.container:1 and for a description we would use Message.container:Containers This would allow SAM to display a value of 1 with a heading of "Containers".  The variable "container" would tie the two together.  That's a brief explanation of getting statistics into SAM.  I could write an entire article on Script Component Monitors alone.  Oh, look!  Someone already did... SAM Script Component Monitors - Everything you need to know


This would be pretty simple if we only wanted the single "Containers" line from the "docker info" command.  We could just pipe the output of the "docker info"  through "grep" to find the line that contains "Containers" and then pipe that line through "sed" to substitute our special identifying text for the heading "Containers: "  To see how this works type this on the Linux command line:



docker info | grep "Containers: "| sed s/"Containers: "/"Message.container:Containers \nStatistic.container:"/



Which would output:





Show more than one statistic

However if we want to grab more than one line from "docker info", it gets a bit more complicated.

First, to avoid having to grab multiple lines, I decided to just have docker send the output in JSON format.  This can be done by using the format option:


docker info --format '{{json .}}'


which returned:


Now we have the output in a single, JSON-formatted line. 


Now to create a poor-man's JSON parser.  I simply used awk to grab the data I was interested in.  I didn't use a JSON parser like "jq" because I didn't want the burden of ensuring that this code was installed on the target system. 


Here is the script that I used:


#! /bin/bash
JSON="$(/usr/bin/docker info --format '{{json .}}')"
echo $JSON| awk -F ','  '{print $3}' | awk -F ':'  '{print "Message.running:"$1,"\nStatistic.running: "$2}'
echo $JSON| awk -F ','  '{print $4}' | awk -F ':'  '{print "Message.paused:"$1,"\nStatistic.paused: "$2}'
echo $JSON| awk -F ','  '{print $5}' | awk -F ':'  '{print "Message.stopped:"$1,"\nStatistic.stopped: "$2}'
echo $JSON| awk -F ','  '{print $6}' | awk -F ':'  '{print "Message.images:"$1,"\nStatistic.images: "$2}'

This grabs the 3rd, 4th, 5th and 6th objects in the JSON and plugs them into SAM as message and statistic respectively.  At this point I have to admit that there is some risk that Docker could change the output of this file and break my positional parsing, while not affecting someone using a real JSON parser to search for the proper key/value pair.  You can test the script from the Linux command line to be sure that it works.


Now that we've got a working script on the Linux server, we can insert it into the SAM Linux script component monitor.

Here's a screen shot of the script being put into SAM


A couple of things to notice on this screenshot.

  • I couldn't run the "docker info" command as a normal user.  I had to use "sudo" to run it as super-user.  This required me to modify my "sudoers" file to add the "NOPASSWD:ALL" option for the user whose credentials I'm using.  This change allowed SAM to run a privelidged command without being prompted again for the password.  More on that here How To Monitor Linux With SSH And Sudo
  • I used a fully qualified path for the docker executable.  This is to ensure that I don't have issues due to the user's PATH statement.


Here are some screenshots of the monitor as I spun up some images and containers on the target system.


That's it!  You're monitoring Docker.


For those of you running Docker on Windows.  Most of the Docker Info commands are similar, if not the same and a script component monitor could be written in PowerShell.

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.