Skip navigation
1 2 3 4 Previous Next

Product Blog

57 Posts authored by: aLTeReGo Employee

Orion and the modules which run atop the platform provide a tremendous wealth of statistical information at your fingertips for spotting trends and hotspots. That data collected is also helpful for determining if what you're seeing now is anomalous, or normal consistent behavior based upon historical analysis. Unfortunately, one area where Orion hasn't been quite as strong is helping users troubleshoot active ongoing issues. Should you find yourself in the throes a major outage or performance issue, Orion does an outstanding job of ensuring you're alerted to the problem at hand. Where it falls short however, is providing tools which aid in your ability to diagnose the root cause of the issue in real-time.

 

As many of you are keenly aware, default polling intervals for statistic data collection in Orion is typically somewhere between 5-10 minutes for most Orion product modules. While this normal polling interval for statistic collection is perfectly reasonable for trend analysis, alerting, and reporting, it's less than ideal when you're actively troubleshooting an ongoing issue. Ideally, you'd want the ability to make change, like restarting a Windows service or Linux daemon, change a CBQoS policy, or allocate additional resources to a virtual machine, and then see immediately the impact those changes are having to the issue you're trying to resolve. In these situations, it's simply untenable to wait 5-10 minutes for Orion's next polling cycle to determine if what changes you made resolved the issue. Doing so significantly bottlenecks the number of things you can try, and extends the duration of the outage as you wait for Orion's next scheduled polling interval to determine if the issue is resolved.

 

Sure, there are alternatives and workarounds which many people leverage in these situations. Some choose to click the 'Poll Now' button feverishly to get updated values ahead of the normal 5-10 minute polling interval, but even this takes a minute or so before data is collected and visible within the Orion web interface. While better, this is still less than optimal for troubleshooting purposes. Others instead, use different tools like command line interfaces on switches, routers and linux, or Resource Monitor and Task Manager on WIndows for their firefighting needs. These tools though, have their own drawbacks, such as requiring you leave Orion where you were initially alerted to the problem, and console into the device exhibiting the issue. If this problem potentially spans multiple devices, such as in the case of distributed application architectures, clustered or load balanced servers, HSRP, VRRP, etc. then you'll be forced to juggle multiple console sessions with no ability to compare or correlate metrics between devices.

 

 

Enter PerfStack

 

With the release of PerfStack included in Orion Platform 2017.3, these woes are a thing of the past. No more juggling between different tools as your boss watches over your shoulder, breathing down your neck as you scramble to isolate the cause of your next critical performance issue. With our new improvements to PerfStack, we introduce you to real-time polling, which provides up to one second statistic collection granularity when activated. This can be for a single entity like a node, or even multiple disparate entities simultaneously.

 

PerfStack-Real-Time-Polling.gif

 

 

Start Real-Time Polling

To begin using PerfStack's new Real-Time Polling capabilities, start a new project and add a node by clicking 'Add Entities'. Expand the 'Node' category and click on the node you just added in the previous step to select it. This will populate the metric pallet with the list of all available metrics for that entity. Within the metric palette, expand 'CPU/Memory' or 'Response Time' and you will notice a blue rocketship icon which adorns many of the available metrics listed. This icon denotes that the metric is available for Real-Time Polling. Note that not all metrics for a given entity are pollable in real-time. A full listing of all real-time pollable metrics can be found by expanding the 'Real-Time Polling' category in the metric palette of the selected entity.

 

Rocket Ship.pngReal-Time Polling Category.png

 

Once you've identified which real-time metrics you'd like to visualize within your PerfStack project, drag and drop those metric tiles into the chart area the same as you would any other metric. You can of course include both real-time and non-real-time metrics within the same project, but only those denoted with the blue rocket ship icon will be updated within the chart at one second intervals. Other metrics included within the same project will continue to update themselves based upon their normal scheduled polling intervals.

 

Now that you've added the some real-time metrics to your PerfStack project, simply click the 'Start Real-Time Polling' icon in the top action bar. This will automatically change the timeframe of the chart to the last 10 minutes. This allows you to more easily visualize variations in the charted values at high frequency polling intervals. You may also notice the rocketships blink when real-time polling is starting. This process takes just a second or two, then the charts begin to move. To stop real-time polling, simply click the 'Stop Real-Time Polling" button in the top action bar.

 

 

Start-Real-Time-Polling.gif

 

 

Real-Time Polling Limits

While real-time polling is active, you can continue to add or remove additional real-time metrics to your project. These can be from the same, or entirely different entities. Real-Time polling will continue for those existing metrics on the chart, and any newly added metrics will begin to update in real-time. There is a limit of ten unique real-time metrics per-project which can be polled. Should you exceed this limit, you will notice a toast message appears in the top right of the window when attempting to add the eleventh metric to a chart where real-time polling is enabled. This same message will appear if your project contains more than 10 real-time pollable metrics and you attempt to enable Real-Time Polling. To resume real-time polling, reduce the number of metrics which can be polled in real-time within your PerfStack project to ten or fewer.

 

Session LimitGlobal Limit
PerfStack RealTime Exceeded.pngPerfStack Real-Time Global Limit.png

 

In addition to the per-session limit of 10 real-time metrics, there is also a notification if you exceed a global limit of thirty unique metrics across all web interface sessions on the Orion server. Real-time polling uses a shared cache across all sessions, so if you and three of your colleagues are viewing the same ten metrics in real-time within PerfStack this only counts as 10 real-time metrics, not 40. This is because PerfStack is only polling the device in real-time once, and not for each unique user session. This helps reduce overhead on the Orion server, as well as any strain on the monitored device.

 

Polling Methods

In our ever enduring commitment to remain an agentless first monitoring solution, Real-Time Polling in this release is available only for nodes managed via ICMP, SNMP, or WMI. Those nodes which are managed via the Orion Agent cannot as yet utilize Real-Time Polling. Should you select an entity within PerfStack that is managed via the Agent, you will notice the absence of any blue rocket ship icons in that entities metric tiles, denoting that Real-Time Polling is not available for that entity.

 

Metrics and Entities Supported

As stated above, Real-Time Polling is not yet available for all metrics and entity types. For this release of PerfStack, we focused on what we believe to be the most vital real-time metrics users would need at hand during a firefight. This includes 34 metrics spanning across three different entity types, nodes, interfaces, and volumes; allowing you to troubleshoot the most common network, storage, and device related performance issues in real-time from a single, centralized, web based interface. If you'd like to see additional real-time metrics supported in future releases, we'd love to know which ones you would find most valuable, and how you would plan to use them.

 

NodesInterfacesVolumes
Average CPU LoadAvailabilityAverage Disk Queue Length
Average Memory UsedReceived DiscardsAverage Disk Reads
Average Percent Memory UsedReceived ErrorsAverage Disk Transfer
Peak CPU LoadTransmit DiscardsAverage Disk Writes
Peak Memory UsedTransmit ErrorsMaximum Disk Queue Length
Minimum CPU UsedAverage Receive bpsMaximum Disk Reads
Minimum Memory UsedMinimum Receive bpsMaximum Disk Transfer
Average Response TimePeak Receive bpsMinimum Disk Queue Length
Maximum Response TimeReceive Percent UtilizationMinimum Disk Reads
Minimum Response TimeAverage Transmit bpsMinimum Disk Transfer
Minimum Transmit bpsMinimum Disk Writes
Peak Transmit bps
Transmit Percent Utilization

 

 

User Restrictions

We at SolarWinds, understand that not all Orion administrators may want every user to have access to such an amazing feature. After all, they may be completely mesmerized by the screen and not get any actual work done as a result. With that in mind, you will find a new user or group level permission which controls whether the 'Real-Time Polling' button appears within PerfStack for those users. This new setting can be found under [Settings -> All Settings -> Manage Accounts]. From there, select a group or individual user account and click 'Edit'. Expand 'Performance AnalysIs Settings' at the bottom of the page and change this setting from 'Allow' to "Disallow' for any user or group. This will disable Real-Time Polling for those users. By default, all users have permission to launch Real-Time Polling within PerfStack.

 

Real-Time Polling is only one of the latest improvements we've made to PerfStack in the Orion Platform 2017.3 release. If you're interested in what other goodies we've stuffed under the hood, hop on over to my earlier post, entitled Orion Platform 2017.3 - PerfStack New Features & Improvements for the full rundown.

 

 

Syslog

When PerfStack was initially released, a surprising few key metrics were noticeably absent. Chief among those, was the surprising lack of Syslog data. In the Network Performance Monitor 12.2 release, and all Orion product modules which include Orion Platform 2017.3, we rectified this injustice, bringing Syslog into the PerfStack fold. For any node sending Syslog data to Orion you will find a new 'Syslog' metric tile under the 'Status, Events, Alerts' category. Simply drag that tile to the chart area, and voila! Syslog data charted over time broken down by severity level.  As with all metric tiles within PerfStack this metric tile is dynamic and will only appear Nodes which have been configured to send Syslog data to the Orion server. If this tile does not appear for nodes you believe should, verify that Orion has received Syslog data from the device using the web based syslog viewer within the Orion web interface.

 

 

Hovering your mouse over the charted area will show the total number of syslog messages received at the top of the legend for the time shown below the vertical marker, as well as a breakdown of each severity type contributing to that total beneath it.

 

 

SNMP Traps

Not to be outdone, the inclusion of SNMP Trap data has also been added. Much like Syslog, SNMP Trap data is broken out by severity and is available as a dynamic metric tile for any node which is configured to send SNMP Trap data to Orion. The SNMP Trap metric tile can be found under the same 'Status, Events, Alerts' category as Syslog, when a node is selected from within the metric palette.  If this tile does not appear for nodes you have configured to send SNMP Trap data to Orion, verify that Orion is receiving those SNMP Traps from the device using the web based SNMP Trap viewer, accessible from within the Orion web interface.

 

 

 

Zoom

When hovering your mouse over the charted area you may notice your mouse cursor has learned a new trick, changing to crosshairs. Holding down your mouse button while dragging across the charted area allows you to lasso a specific time period of interest, such as a sudden spike in resource usage. The selected area is then the focal point of your project, while the rest of the chart area surrounding this time period becomes visually de-emphasized through color desaturation. while the colors remain bright and vibrant within the selected area.  This easily allows you to focus your attention on the area selected area without visual distraction from the surrounding area. This selection process occurs across all charts within the PerfStack, making it easier to visually correlate what else occurred during the same time period.

 

 

Once a time period has been selected, new options appear next to the selected area. Clicking the [+] icon highlighted above, zooms into the selected time range where you can view high fidelity detailed data collected during that time period. Similarly, clicking the [-] icon allows you to zoom further out to spot trends, or return to your previous perspective after having zoomed in. Any time after having made a selection, clicking the [X] icon will cancel the selection and return focus to the entire viewable chart area.

 

 

Data Explorer

Great! So now you know how many Syslog messages and SNMP Traps were received from any of your devices, along with their respective severity. You can even zoom into a specific time frame and cross correlate this data against other metrics from the same or different entities monitored by Orion. That's some super powerful stuff! But you know what would make this data even more powerful?

 

What if you could actually view the full details of those Syslog or SNMP-Traps from within PerfStack itself? That would assuredly accelerate the troubleshooting process and aid in reducing time-to-resolution; both of which are key tenets of PerfStack. Well that's exactly what we've done!

 

To get started, select a time period in the chart area, the same as described above to zoom in or out of the chart. Next, click the top paper & magnifying glass icon from the options displayed to the right of the selected area. This action will cause the Data Explorer tab to be shown in the left pane, where the Metric Palette normally appears. Switching between the Data Explorer and the Metric Palette is simply a matter of clicking on the appropriate tab.

 

Within the Data Explorer, all Syslog or SNMP Trap data is listed in the chronological order it was received. Each line represents a single message, beginning with its severity and ending with the date and time the message was received. In between is a brief preview of the message body. To view the full message text, simply expand the row.

 

 

If your devices are sending a lot of Syslog or SNMP Traps to Orion, it may be difficult to sift through all the noise and focus on what's truly important, even if you select the tiniest window of time. Since this just so happens to be another key tenet of PerfStack, we added filtering and search to the Data Explorer. This allows you to do things, such as show only Warning or Critical messages that were received during the selected time period, while filtering out the excessive noise generated by Informational and Debug messages.

 

And BOOM! Just like that, the problem is found. If SolarWinds was a leading US based office supply company, right now you'd probably feel compelled to blurt out 'That was easy". The magic doesn't end there either. This same functionality that's available for both Syslog and SNMP Traps can also be used to view the details of Orion Events. So if you aren't afforded the opportunity to configure devices to send Syslog or SNMP Traps to your Orion server, you can still give this new feature a whirl by adding Orion Events to your PerfStack and following the instructions outlined above.

 

 

Additional Metrics Support

In addition to Syslog & Traps, PerfStack in Orion Platform 2017.3 includes support for a variety of additional Orion product module metrics in this release. Given the feedback we have received since the initial release PerfStack, we know these will all be extremely welcomed additions.

 

Universal Device Pollers

That's right, I said Universal Device Pollers! Unquestionably the single most often requested feature request I receive for PerfStack has been adding support for Universal Device Pollers. With the release, I'm proud to announce you can now add Universal Device Pollers to your PerfStack projects no differently than any other metric. Universal Device Pollers for both Nodes and Interfaces are supported, and appear under their respective entity type. When you select an interface for example, which has Universal Device Pollers assigned, the 'Group' names as defined within the Universal Device Poller Windows application will appear within PerfStack as new metric categories. In the example below I have a Universal Device Poller Group I've defined in the Win32 application called 'Cisco Switch', which I've assigned to interface 'Fa0/1' on 'lab-transi-sw1'. Similarly, I have a Node based Universal Device Poller called 'sonic Current CPU Util' which is assigned to 'stp-nsa2400'. Please note that for Universal Device Pollers to appear in PerfStack, they must be of type 'Rate' or 'Counter' and that 'Keep Historical Data' must be enabled.

 

PerfStack Universal Device Pollers.png

Network Insight for F5 & ASA

This release of PerfStack also includes support for NPM's Network Insight for F5, and all new Network Insight for ASA. These metrics appear under their own distinct categories or node entities and are treated no differently than any other metric within PerfStack.

 

F5 ASA.png

 

Voice & Network Quality Manager

A party just isn't a party unless you invite your friends, so in this release we invited VNQM to join the fun by bring metrics for IPSLA operations into PerfStack. IPSLA Operations appear as their own separate entity type within PerfStack. If however, you find it easier to search by source router instead you can select that node entity and click the add related items button and all IPSLA operations running on that router will appear listed in the entities list. Select the IPSLA operation you'd like to see more information about and the list of all available metrics for that operation appear listed in the metric pallet. From there you know the drill; just drag and drop them onto the chart area and voila!

 

Network Configuration Manager

Also joining the party is NCM, allowing Orion users for the first time ever to visually cross correlate configuration changes to the impact they have on the network. When combined with NTA you can easily see the effect your recent CBQoS policy change is having on the flow of traffic from the moment the change was made. PerfStack also makes it easy for you to not only determine exactly when a change was made, but by whom. Similar to Syslog, Traps, and Events, selecting a time period from the charted area and clicking the Data Explorer button reveals detailed information about the configuration change that occurred, such as the username of the individual who logged into the device and their IP address.

 

 

 

 

Alert Visualization

Visualization of alerts in the premiere release of PerfStack displayed only the total aggregate of all alerts against a given entity, as well as how long all alerts had been active against that object. While useful, you were unable to determine what those alerts were which triggered, or how long each of those alerts remained active. A lot of that important detail was obscured through aggregation, making this particular area of PerfStack ripe for improvement.

 

In this release of PerfStack we preserved the same total alert aggregate that was available in the first release, but then extended the chart to show the names of the alerts which triggered along with their individual durations. No longer are you left wondering what alert was triggered against the object, or fumbling through other areas of the Orion web interface to track down that information. You'll also know at a glance when the alert triggered and for how long, in a manner which allows you to visually recognize patterns of reoccurrence and correlate specific individual alerts against other metrics collected by Orion.

 

Export

Occasionally it's necessary to share your PerfStack findings with others who may not have access to Orion, or archive those findings in a ticketing system for historical purposes beyond your defined retention period. For some, this information needs to be imported into other systems for change back, show back, billing, forensic analysis, or correlation with other non-Orion tools in the environment. Previously, your only recourse was to export data for each metric individually via the Custom Chart View, or write your own series of custom queries against the SQL database backend to obtain the raw values behind these charts.  In this PerfStack release however, those days are behind us.

 

After adding all metrics of interest to your PerfStack project, simply click the new 'Export' button located in the top menu. This will export your project's content to a Microsoft® Excel friendly comma separated value (CSV) formatted file,which is then downloaded to your local machine via your browser.

 

Double click the file to open in Excel, or upload the file to Google™ Docs to open in Sheets. Inside you will find all the raw data which made up the charts in PerfStack. Each series of the same chart is represented as its own set of columns, complete with the entity and metric name, date and time the data was collected, and its value. If your PerfStack project contained multiple charts, the values for each chart are grouped together in the CSV file the same as they were visually laid out within PerfStack itself. Simply put, the detailed raw data for the second PerfStack chart is directly beneath the end of the series for the first chart data contained within the CSV file.

 

 

The logical layout of the CSV file makes it easy to visually recreate similar charts to what was seen in PerfStack, using the native graphing tools included in Excel or Sheets. The format of the raw data is also well suited for import into 3rd party reporting solutions like Domo or eazyBI. With the data contained in logical layout and an open format, the possibilities are limitless.

 

 

 

Usability Improvements

 

Share

Not everyone who used PerfStack initially realized that whatever they created could be easily shared with others, simply by copying the URL and sending it to them. Since this is one of PerfStack's most powerful capabilities, we felt it needed to be promoted to the top menu, alongside other important functions like saving and loading a PerfStack.

 

Just click this 'Share' button and the dynamic PerfStack URL is automatically copied to your clipboard and ready to be pasted into an email, instant message, helpdesk ticket, etc. and shared with others.

 

Getting to PerfStack in previous releases meant leaving what you were looking at and starting the troubleshooting process over from the very beginning again in PerfStack if you needed to correlate symptoms with their root cause. For example, if users are complaining about the performance of SharePoint, a logical starting point might be to go to the Node Details view of the SharePoint server in Orion. But what if you then wanted information from the Hypervisor this virtual machine is running on, the storage array, or the SharePoint application being monitored by SAM? Well, you'd probably navigate to PerfStack, add the problem node, and then its relationships, before eventually plotting metrics in the chart area for correlation. This sounds tedious just explaining it and we knew we could do better.

 

Within the 'Management' or 'Details' resource located on the details view of virtually any entity type supported by PerfStack, you will find a new 'Performance Analysis' link. When pressed, you will be taken directly to PerfStack and the entity object you came into PerfStack will be pre-populated in the entity selector, along with any of its related items. In addition, the chart area will pre-populate with relevant metrics associated with the entity you came in from.

 

 

For example, if you were to click on the "Performance Analysis' link from the 'Node Details' view of your SharePoint server, you would be taken to PerfStack where the Node, it's volumes, interfaces, etc. are already listed in the entity list, and metrics such as Status, CPU/Memory utilization, response time, alerts, and events are all pre-populated for you. These metrics are dynamic based upon the entity type you enter from, ensuring they are always relevant to what you're investigating.

 

Links To PerfStack.png

We didn't stop simply at having links into PerfStack from other views in Orion. We knew that there were occasions when users viewing data in PerfStack needed additional information only found on entity details views, such as MAC addresses, serial/model numbers, etc.. WIth that in mind, we included direct links to the Details view of any entity shown within PerfStack's entity list. Simply hover your mouse over the entity name, the same as you would to add related items or to remove the entity from the list. There you will notice a new link icon, which when clicked will open a new browser tab that will take you to the details view for that entity.

 

Link to Details from PerfStack.png

 

Drag & Drop Entities

We all know you can drag and drop metrics onto PerfStack's chart area to visualize virtually any combination of metrics desirable, but what if I told you that you could drag and drop entire entities into the chart area? Would that blow your mind?  Well that's exactly what you can do now with PerfStack!

 

Utilizing the same logic derived from 'Links to PerfStack' referenced above, relevant and dynamic metrics associated with a given entity are pre-populated and charted when an entity is dragged into PerfStack's chart area. Simply click and hold your mouse on the drag handle which appears to the left of the entity name when hovering your mouse. Next, drag the entity into the chart area. This will then populate the charted area will the same metrics that would appear if you had entered PerfStack through the 'Performance Analysis' link on that entities Details view, saving you precious time in the throes of troubleshooting.

Drag and Drop Entities.png

Full Screen Mode

WIth the initial release of PerfStack we received a lot of feedback from customers wanting to add PerfStack to a wallboard in their NOC. The first issue these customers ran into was a bug where PerfStack did not respect session timeout values defined for the user account. I'm happy to announce that this issue has been resolved, allowing you to have PerfStack running and updating indefinitely if so desired, without ever timing out your session.

 

Next on their wish list was some ability to declutter the UI of extraneous elements which were unnecessary for a non-interactive display. This would allow them to maximize the viewable area for data being displayed in the charts and legend. Being the accommodating bunch that we are, a newly added button was added to the top right of PerfStack, just above the chart legend. When clicked, all UI elements except the chart and legend are removed, placing PerfStack into fullscreen mode. To exit full screen mode and return to normal mode, just click the button again or remove all metrics from the chart. Note that this button will only appear when one or more metrics are plotted in the chart area.

 

Maximize.png

 

Sharing is great when you're collaborating on a specific issue with a group of individuals, but what if you as the Orion Administrator want to create custom PerfStack dashboards to share with your users? This can be accomplished with other custom Orion views fairly easily, and PerfStack function no different.

 

To begin, first start by creating your custom PerfStack and including all metics you'd like represented in the chart. When complete, save your changes and click the 'Share' button. You should now have the URL to your saved PerfStack in your copy/paste buffer. Next, go to [Settings -> All Settings -> Customize Menu Bars] and edit the menu bar for the user/s you'd like to have access to your saved PerfStack. At the bottom of the page click the 'Add' button, give your link a name, and paste the saved PerfStack URL into the URL field of the 'Edit Custom menu Item' dialog windows that appears. From there, click 'ok' to save your changes and drag your newly created menu item from the 'Available Items' column to the 'Selected Items' column to add this to your menu bar.

 

When users which are assigned that Menu Bar login, they will now see a link to your custom saved PerfStack in their navigation. This allows Orion administrators to quickly share custom saved PerfStacks without emailing or instant messaging links to users. Similarly, you can now also use the 'User Links' resource in a similar fashion to provide your users links to custom saved PerfStack dashboards.

 

 

This represents an incredible amount of awesome jam packed into a single release, and I haven't even mentioned Real-Time polling yet! Let us know what your thoughts are these PerfStack improvements in the comments section below. We'd love to hear your feedback!

Hopefully you are already reaping the benefit from the many improvements that were made in Network Performance Monitor 12.1, Server & Application Monitor 6.4, Storage Resource Monitor 6.4, Virtualization Manager 7.1, Netflow Traffic Analyzer 4.2.2, and Network Configuration Manager 7.6. If you haven't yet had a chance to upgrade to these releases, I encourage you to do so at your earliest convenience, as there are a ton of exciting new features that you're missing out on.

 

Something a few who already upgraded may have seen, is one or more deprecation notices within the installer. These may have included reference to older Windows operating systems or Microsoft SQL versions. Note that these deprecation notices will only appear when upgrading to any of the product versions listed above, provided you are installing on any of the Windows OS or SQL versions deprecated in those releases. But what does it mean when a feature or software dependency has been deprecated? Does this mean it's no longer supported, or those versions can't be used anymore?

 

Upgrade.png

 

Many customers throughout the years have requested advance notice whenever older operating systems and SQL database versions would no longer be supported in future versions of Orion, allowing them sufficient time to properly plan for those upgrades. Deprecation does not mean that those versions can't be used, or that they are no longer supported at the time the deprecation notice is posted. Rather, those deprecated versions continue to remain fully supported, but that future Orion product releases will likely no longer support them. As such, all customers affected by these deprecation notices should take this opportunity to begin planning their migrations if they wish to stay current with the latest releases. So what exactly was deprecated with the Q1'17 Orion product releases?

 

Windows Server 2008 R2

 

Released on October 22, 2009, Microsoft ended mainstream support for Windows Server 2008 R2 SP1 six years later on January 13, 2015. For customers, this means that while new security updates continue to be made available for the aging operating system, bug fixes for critical issues will require a separate purchase of an Extended Hotfix Support contract agreement; in addition to paying for each fix requested. Since so few of our customers have such agreements with Microsoft, the only recourse, often times, is an unplanned, out-of-cycle, operating system upgrade.

 

Microsoft routinely launches new operating system versions, with major releases on average every four years, and minor version releases approximately every two. As new server operating system versions are released, customer adoption begins immediately thereafter; sometimes even earlier, during Community Technical Preview, where some organizations place production workloads on the pre-released operating system. Unfortunately, in order to leverage the technological advances these later versions of Windows provide, it occasionally requires losing backwards compatibility support for some older versions along the way. Similar challenges occur also during QA testing whenever a new operating system is released. At some point it's simply not practical to thoroughly and exhaustively test every possible permutation of OS version, language, hotfix rollup or service pack. Eventually the compatibility matrix becomes so unwieldy that a choice between quality or compatibility must be made; and really that's not a choice at all.

 

 

SQL Server 2008 / 2008 R2

 

SQL Server 2008 was released on August 6, 2008, with SQL 2008 R2 being released just four months shy of two years later, on April 21, 2010. Seven years later, there have been tremendous advances in Microsoft's SQL server; from the introduction of new redundancy options, to technologies like OLTP and columnstore indexes, which provide tremendous performance improvements. Maintaining compatibility with older versions of Microsoft SQL precludes Orion from being able to leverage these and other advances made in later releases of Microsoft SQL Server, many of which have potential to tremendously accelerate the overall performance and scalability of future releases of the Orion platform.

 

If you happen to be running SQL Server 2008 or SQL 2008 R2 on Windows Server 2008 or 2008 R2, not to worry. There's no need to forklift your existing SQL server prior to upgrading to the next Orion release. In fact, you don't even need to upgrade the operating system of your SQL server, either. Microsoft has made the in-place upgrade process from SQL 2008/R2 to SQL 2014 extremely simple and straightforward. If your SQL server is running on Windows Server 2012 or later, then we recommend upgrading directly to SQL 2016 SP1 or beyond so you can limit the potential for additional future upgrades when/if support SQL 2012 is eventually deprecated.

 

Older Orion Version Support for Windows & SQL

 

Once new Orion product module versions are eventually released which no longer support running on Windows Server 2008, 2008 R2, or SQL 2008/R2, SolarWinds will continue to provide official support for those previous supported Orion module versions running on these older operating systems and SQL server versions. These changes only affect Orion module releases running Orion Core versions later than 2017.1. If you are already running the latest version of an Orion product module on Windows Server 2008/R2 or SQL 2008/R2 and have no ability to upgrade either of those in the near future, not to worry. Those product module versions will continue to be supported on those operating system and SQL versions for quite some time to come.

 

Monitoring vs Running

 

While the next release of Orion will no longer support running on Windows or SQL 2008/R2, support for monitoring systems which are running on these older versions of Windows and SQL will absolutely remain supported. This also includes systems where the Orion Agent is deployed. What that means is if you're using the Orion agent to monitor systems running on Windows Server 2008 or Windows Server 2008 R2, rest assured that support for monitoring those older systems with the Orion Agent remains fully intact in the next Orion release. The same is also true if you're monitoring Windows or SQL 2008/R2 agentlessly via WMI, SNMP, etc. You're next upgrade will not impact your ability to monitor these older operating systems or SQL versions in any way.

 

 

32Bit vs 64Bit

 

Support for installing evaluations on 32bit operating systems will also be dropped from all future releases of Orion product modules, allowing us to begin the migration of Orion codebase to 64bit. In doing this, it should improve the stability, scalability, and performance for larger Orion deployments. Once new product versions begin to be released without support for 32bit operating systems, users wishing to evaluate Orion based products on a 32bit operating system are encouraged to contact Sales to obtain earlier product versions which support 32bit operating systems.

 

 

.NET 4.6.2

 

Current Orion product module releases, such as Network Performance Monitor 12.1 and Server & Application Monitor 6.4, require a minimum version of .NET 4.5.1. All future Orion product module releases built atop Core versions later than 2017.1 will require a minimum version of Microsoft's .NET 4.6.2, which was released on 7/20/2016. This version of .NET is also fully compatible with all current shipping and supported versions of Orion product module releases, so there's no need to wait until your next Orion module upgrade to update to this newer version of .NET. Subsequently, .NET 4.7 was released on 5/2/2017 and is equally compatible with all existing Orion product module versions in the event you would prefer to upgrade directly to .NET 4.7 and bypass .NET 4.6.2 entirely.

 

It's important to note that Microsoft's .NET 4.6.2 has a hard dependency on Windows Update KB2919355, which was released in May 2014 for Windows Server 2012 R2 and Windows 8.1. This Windows Update dependency is rather sizable, coming in between 319-690MB. It also requires a reboot before .NET 4.6.2 can be installed and function properly. As a result, if you don't already have .NET 4.6.2 installed, you may want to plan for this upgrade during your next scheduled maintenance window to ensure your next Orion upgrade goes smoothly and as quick as possible.

 

Minimum Memory Requirements

 

With many of the changes referenced above, minimum system requirements have also needed adjustment as well. Windows Server 2012 and later operating systems utilize more memory than previous versions. Similarly, .NET 4.6 can also utilizes slightly more memory than .NET 4.5.1. As we move forward however, 64bit processes inherently use more memory than the same process compiled for 32bit. To ensure users have a pleasurable experience running the next version of Orion products, we will be increasing the absolute minimum memory requirements from 4GB to 6GB of RAM for future versions of Orion product modules. The recommended minimum memory requirement however, will remain at 8GB.

 

While most readers themselves today would never consider running and using a Windows 10 laptop on a day-in-day-out basis with just 4GB of RAM, those same people also likely wouldn't imagine running an enterprise grade server based monitoring solution on a system with similar such specs either. If you do, however, find yourself in an environment running Orion on 4GB of RAM today, an 8GB memory upgrade can typically be had for less than $100.00. This can be done before the next release of Orion product modules and will even likely provide a significant and immediate improvement to the overall performance of your Orion server.

 

 

How to Prepare

 

All items listed above can be completed prior to the release of the next Orion product module versions and will ensure your next upgrade goes off without a hitch. This posting is intended to provide anyone impacted by these changes with sufficient notice to plan any of these upgrades during their regularly scheduled maintenance periods, rather than during the upgrade process itself. In-place upgrades of SQL, as stated above, are a fairly simple and effective process to get upgraded quickly with the least possible amount of effort. If you're running Orion on Windows Server 2008 or 2008 R2, in-place OS upgrades are also feasible. If either of these are not feasible or desirable for any reason, you can migrate your Orion installation to a new server or migrate your Orion database to a new SQL server by following the steps outlined in our migration guide.

 

Other Options

 

If for any reason you find yourself running Orion on Windows Server 2008, Server 2008 R2, or on SQL 2008/R2 and unable to upgrade, don't fret. The current releases of Orion product modules will continue to remain fully supported for quite some time to come. There is absolutely zero requirement to be on the latest releases to receive technical support. In almost all cases, you can also utilize newly published content from Thwack's Content Exchange with previous releases, such as Application Templates, Universal Device Pollers, Reports, and NCM Configuration Change Templates. When you're ready to upgrade, we'll be here with plenty of exciting new features, enhancements and improvements.

 

 

Planning Beyond The Next Release

 

At any given time, Orion supports running on a minimum of three major versions of the Windows Operating System and SQL database server. When a new server OS or SQL version is released by Microsoft, SolarWinds makes every effort possible to support up to four OS and SQL versions for a minimum of one Orion product module release. If at any time you find yourself four releases behind the most current OS or SQL server version, you may want to begin planning an in-place upgrade or migration to a new server during your next regularly scheduled maintenance window to ensure your next Orion product module upgrade goes flawlessly.

 

For your reference, below is a snapshot of Windows Operating Systems and SQL Server versions which will be supported for the next release of Orion product modules. This list is not finalized and is still subject to change before release. However, nothing additional will be removed from this list, though there could be additional version support added after this posting.

 

Supported Operating System VersionsSupported Microsoft SQL Server Versions
Server 2012SQL 2012
Server 2012 R2SQL 2014
Server 2016SQL 2016

We've all been there at some point or another. For some of us it's a daily ritual, for others, it's what haunts our dreams at night.

 

I'm speaking, of course, about troubleshooting complex multi-faceted IT issues which can (and often do) transcend functional silos within the overarching IT organization. Cloud, virtualization, hybrid IT, storage area networks, converged infrastructure etc., have all fundamentally transformed IT. Tasks which historically may have taken hours or even days, now take minutes, and some just seconds to complete. These historically, time consuming tasks have become so easy, in fact, that in some organizations they're fully or at least partially automated.

 

The story doesn't end at the infrastructure either. Instead of monolithic, single purpose, do everything, application servers; distributed application architectures, elasticity, and containerization have increasingly becoming the norm. While all these abstraction layers have helped address application scalability and availability, they have also made it significantly more difficult for those monitoring the health and performance of everything which contributes to the delivery of the services those applications provide.

 

The troubleshooting process itself is more entangled than ever before, often times requiring collaboration amongst many different functional silos within the organization. From the storage administrator, DBA, Virtualization admin, cloud architect, application designer, network engineer, DevOps, systems administrators, etc., the finger pointing begins right away. But where to begin? The Orion® Platform and its related product modules such as Network Performance Monitor, Server & Application Monitor, etc., can collect millions of different metrics from across the entirety of the IT environment. That's an overwhelming amount of data to parse through as the clock is ticking; the pressure mounts, and your SLA is hanging in the balance.

 

Many Orion administrators have created elaborate, purpose-built, custom summary dashboards, comprising many various chart resources to help consolidate relevant information related to specific business critical services and to aid in troubleshooting scenarios. The issues with this approach are varied. First, depending upon the complexity and elaborateness of the custom dashboard, the creation process can be both tedious and time consuming. Second, only those with Orion View Management rights have the necessary permissions required to build or modify these custom summary dashboards, placing a tremendous burden on the Orion administrator and making them the bottleneck for efficient troubleshooting. Third, there's the issue of maintaining these custom summary dashboards. Some larger organizations may have dozens or even hundreds of these for various business services, and if not properly maintained to reflect changes made throughout the organization, these dashboards become less and less useful for their intended purpose.

 

From the end-user's perspective, these dashboards help eliminate the need to navigate through a various multitude of views and dashboards in search of data needed to isolate the root cause. Provided, of course, the issue they're investigating occurred within the default time period shown within the chart resources. If it didn't, then the end-user must click on each chart resource individually to be taken to the Custom Chart View, where they can adjust the timeframe shown to the timeframe desired for that specific chart. This then defeats the entire purpose of the custom summary dashboard as a means to visually correlate data more easily for the specific time period when the issue occurred.

 

Enter PerfStack

 

With the release of Network Performance Monitor 12.1 RC1, and the impending release of Server & Application Monitor 6.4 RC1 comes a completely new method for visualizing and correlating data within the Orion web interface. We affectionately refer to this as 'PerfStack'. In part, the name represents the newfound performance analysis and correlation capabilities this feature brings to the Orion® Platform, enriched with relationship data which powers AppStack. The culmination of time series and relationship data is what sets PerfStack apart, allowing you to quickly sift through the massive amounts of data Orion products collect, eliminating noise, and allowing you to focus on what's truly relevant to the issue at hand.

 

Immediately upon upgrading to any of our latest release candidates you will notice a new option available under the 'Home' menu, entitled 'Performance Analysis', which will take you to the new PerfStack dashboard. By default, you will begin with a new analysis project, whereby you will need to start by adding at least one entity. In the throes of an active investigation into an ongoing issue,   the entity selected would typically be the one exhibiting the symptom. This could be the switch, router, virtual machine, host, (AKA: node), or something more specific like the application, LUN, array, or web transaction, to name only a few of the possibilities. Choose whatever the most logical starting point is in your investigation and note that you can add as many entities as you wish to your analysis project.

 

Performance Analysis Menu OptionAdd Entities
Performance Analysis.pngAdd Entities.png

 

Select Entities

 

 

Once you’ve added your entity/s to PerfStack, hovering your mouse over any of those entities in the list, you will notice two icons that appear to the right of the entity name. When clicked, the first icon brings in all other entities related to that object. This leverages existing AppStack relationship data, as well as additional relationship information not currently expressed within AppStack. This includes items such as Hardware Health sensors, network Interfaces, IIS™ Sites, application pools, etc. Relationship information within PerfStack allows you to dramatically accelerate the troubleshooting process and focus exclusively on what's likely related to the issue at hand. This prevents you from fumbling about, wasting time manually trying to figure out how things are related on your own.

 

Add Related EntitiesAvailable Metrics

 

Clicking on any entity name itself populates a list of all available metrics associated with that entity in the adjacent column. These metrics are categorized into collapsed groupings based on their type, any of which can be expanded to reveal individual metric tiles. These tiles can then be dragged onto the chart area on the right where the metric data is plotted.

 

 

 

Add as many metrics to the chart area as you desire. You can add multiple metrics to the same chart, as well as stack multiple charts on top of each other. PerfStack is also capable of combining data from disparate data sources into the same chart. For example, combine Storage Resource Monitor's LUN IOPS data with Network Performance Monitor's network latency and bandwidth data into the same chart to troubleshoot iSCSI performance issues. A feat never before possible within the Orion® Platform family of products.

 

Correlate Metrics Across Different Orion Product Modules
Multi-Product Chart.png

 

PerfStack also allows you to combine integer-based metrics with percentage-based metrics while maintaining the appropriate scale. This is accomplished by maintaining two separate x-axes when metrics of dissimilar types are combined within the same chart.

 

Combine Metrics of Dissimilar Units Within The Same Chart
Integer Pecent.png

 

Data for all metrics displayed within the chart area are automatically aligned across the same time period. Hovering your mouse over any chart area adds a vertical marker which tracks with your mouse movement to visually align all data points across the series. It also displays the date and time that datapoint was collected. As you move your mouse horizontally across the time period of the chart area, the values within the legend update to reflect the values aligned to the vertical marker.

 

 

The viewable time period can be adjusted globally, maintaining sync across all charts in PerfStack. Both relative and custom timeframes are available, allowing you to view things such as the last seven days of history, or focus on a particular event that occurred between 8am - 6pm last Tuesday, for example.

 

Adjust Time RangeSave your Masterpiece

 

Once you've completed your masterpiece, you can optionally save it for future reference. Charted metrics, the entities they're derived from, and the custom or relative time frame are all included as part of your saved project. Saved PerfStack projects can be loaded just as easily as they were saved with a top five most recently used PerfStack list making juggling between projects a snap. You can also save a copy of a project using Save As, or delete PerfStack projects you no longer need from within the More menu.

 

Load Saved PerfStack MRUDelete & Save As

 

Each individual Orion user can create, save, load, update, and delete their own works of art within PerfStack. Also, users aren't required to have Orion 'Admin' or 'View Management' rights to do so, either. Any Orion user can create as many PerfStack dashboards as they wish and manage them independently without assistance from the Orion Admin; something I'm sure is music to the ears of every Orion administrator.

 

Sharing is Caring

 

The most powerful PerfStack feature of all is the ability to collaborate with others within your IT organization; breaking down the silo walls and allowing teams to triage and troubleshoot problems across functional areas. Anything built in PerfStack is sharable. The only requirement is that the individual you're sharing with has the ability to login to the Orion web interface. Sharing is as simple as copying the URL in your browser and pasting it into email, IM, or even a helpdesk ticket.

 

 

When received, the URL provided allows others to instantly see exactly what you've found. They, in turn, can work from that URL, add their own metrics, and send it back without ever affecting your project. Similar behavior is also true if you wish to share a saved PerfStack. Sharing saved PerfStack projects with others allows the recipient access to view your saved PerfStack dashboard and any updates you may make to it in the future. Other users cannot modify your saved PerfStack project, but they can save their own copy, update it as needed, and share back their results.

 

Orion account limitations are fully respected by PerfStack, so there's no need to worry about users gaining access to information they shouldn't. If for any reason, a user should receive a link to a PerfStack project containing objects not permitted by their account restrictions, then any/all metrics related to those restricted objects would be automatically hidden from that user's perspective of the PerfStack project.

 

Coming Soon to a Theater (Monitor) Near You

 

PerfStack is a feature provided with all upcoming Orion product releases which are built atop Orion Platform v2017.1 or later. The list of supported modules include (but not limited to)...

 

  • Network Performance Monitor 12.1
  • Server & Application Monitor 6.4
  • NetFlow Traffic Analyzer 4.2.2
  • Virtualization Manager 7.x
  • Storage Resource Monitor 6.4
  • Web Performance Monitor 2.2.1

 

SolarWinds PerfStack Analysis Dashboard was engineered to allow Orion users to troubleshoot, isolate, and identify IT problems in ways never before possible. As our IT environments evolve, so too must the tools we use to monitor them. Cross silo collaboration is an essential ingredient to any successful IT organization, now and for the foreseeable future. PerfStack, like NetPath before it, are just tiny glimpses into what we have in store for the future of Orion, and we sincerely hope you like what you see.

Server & Application Monitor 6.2 included a boatload of great new features that are going to be difficult to top, but that isn't going to stop us from trying. Here is a sneak peek at just a few of the items the team is diligently plugging away on.

 

  • Cloud Infrastructure Monitoring
    • Amazon AWS
  • Optional Agent for Linux Applications and Servers
    • Allows for polling host and applications behind firewall NAT or proxies
    • Polling node and applications across multiple discrete networks that have overlapping IP address space
    • Allow for reliable and secure encrypted polling over a single port
    • Support low bandwidth, high latency connections
    • Full end to end encryption between the monitored host and the Orion poller
    • Store and forward capabilities allowing the agent to operate independently of the Polling engine when network connectivity is lost
  • Numerous AppStack Environment enhancements
  • Real-Time Performance Analysis
  • Native Log File Monitoring
  • Web Interface design improvements
  • Active Directory Discovery
  • Application Template Assignment to Groups (Static or Dynamic)
  • Automated Network Sonar Discovery Import
    • Automatic monitoring of newly found nodes, interfaces, volumes, and applications based on discovery profile criteria
  • Web Based SSH Client

Since the release of Server & Application Monitor (SAM) 6.2, the team has been busily plugging away on a long list of new features and general product enhancements.  Chief among them are improvements to the aesthetics and overall design of the Orion web interface. While not the primary focus of this blog post, it is near impossible to post screenshots for some of what we've been working on without divulging some sneak peeks into the very early stages of this interface design refresh. A follow-up blog post is currently in the works that will go into detail and explain our multi-phased approach for delivering a fresh, clean, and modernized interface for all products that run atop the Orion platform. Suffice it to say, it is our aim to accelerate overall Orion web interface performance, dramatically improve usability for many of the most common tasks, as well as refine and enhance the product's visual appearance as part of this endeavor. Continue watching the Product Blog for more specifics surrounding the Orion UI redesign, as well as opportunities to provide feedback to members of our user experience team regarding these improvements. Your feedback might just earn you some much deserved Thwack points that can be redeemed for some cool SolarWinds SWAG!

 

With that prologue out of the way, it's time to run through a few notable new features we've been working on that are sure to put a smile on your face. As always, your feedback on features such as these is essential; and the absolute best time to provide that feedback is during betas. So if you're anything like me and would rather try out the new features yourself rather than simply read about them, then short circuit this post entirely and click the big red button below. Otherwise strap in, adorn your reading glasses (if you need them) and soak in the geek goodness below as I walk through some of the new features planned for this release and expose a few glimpses of the web interface redesign.

 

SAM 6.3 Beta button.png

 

Active Directory Discovery

One of the many aspects we wanted to focus our attention on improving within this release is how servers are discovered in SAM. Network subnets, IP address ranges, and lists of individual IP addresses might seem like natural options for those of us who come from a network centric background. However, for those possibly unfamiliar with the networks design or IP addressing schema, Active Directory in many instances provides much or all of the information needed about the servers residing on the network.

 

Active Directory discovery can be added as an additional discovery method to any new or previously existing discovery profile and used in conjunction with the three previously available methods for complete coverage across the environment. 

 

Similar to the other three methods of discovery, multiple Active Directory domains may be used in the discovery profile. This is especially handy for large organizations that may have multiple domains running in their environment due to mergers and acquisitions, separation of internal business units, or even lab vs. production systems. Also, unlike Active Directory authentication to the Orion web console, there is no requirement for the Orion server to be in the same Active Directory domain as the domain controllers used for discovery.

Discovery 2 - Add Domain Controller.png

 

Active Directory has the distinct advantage of allowing for more precise and targeted discovery within the environment. Instead of using a very broad discovery technique such as subnets or IP address ranges, you can more surgically discover only those items you wish to monitor, such as servers and/or workstations. This is particularly useful for organizations using class B "/16" (65,534 IP address) or class A "/8" (16,277,214 ip addresses) subnets, where sequential network scanning techniques may take hours or even days to complete successfully. In environments such as these, much of that IP address space is unused, but it still must be swept to determine which IP addresses are in use and are not part of the discovery process. Active Directory however, has a complete database of all hosts on the network which are members of the domain. Leveraging that database allows for a much more rapid scan of servers and workstations running on the network that could be monitored by SAM.

 

Discovery 3 - Add Domain Controller.png

Discovery 4 - Select OUs.png

Once you've added the Active Directory domain you wish to discover and click "Next" you are shown a complete listing of all Containers and Organizational Units (OUs) in the domain hierarchy. By default all OUs and Containers are selected, including any future Organizational Units that may be created after the discovery profile creation process is complete. Selecting the root level domain object toggles between select/deselect all, and the individual checkboxes on the left allow you to select the specific OUs to include or exclude from this discovery profile. The checkbox to the right of each OU listed designates whether to include any sub-OUs that may be created under that Organizational Unit in the future. For example: you have a root level Organizational Unit named "California" because you have only one office in that region today, located in Los Angeles. Later a new office is brought online in San Francisco. As a result you may decide to create two sub-OUs under California named "LA" and "SF" to manage group policy separately for each of those offices. The "Include Future OUs" option allows for these types of changes to occur within an OU, sub-OU, or domain without the need to update SAM's discovery profiles that are used for recurring nightly scheduled rediscovery of new devices in the environment. If not applicable or desirable in your organization, this option can of course be disabled.

 

Automatic Monitoring

Another primary area we focused on for this release is reducing or outright eliminating the maintenance overhead required to keep SAM up to date as new systems are brought online. Too many of us have been in similar situations where a new critical business system is brought up in the environment, and the first time there's a reported problem or issue with the system there's immediately an exchange of finger pointing that occurs amongst the responsible parties attempting to assign blame for why the system wasn't being monitored. As a result many organizations have implemented rigid policies and processes surrounding the provisioning of new systems in an attempt to mitigate these blind spots on the network. Unfortunately even the best laid plans aren't immune from human fallacy, even those with the best of intentions.

 

With that in mind we aimed to provide a mechanism that would ensure that as new systems were brought up in the environment that they would be monitored without relying on someone in the organization to manually add them to SAM for monitoring; or dig through the nightly Network Sonar Discovery Results to select which new items should be monitored. If adding individual devices manually is more your speed, or thumbing through the Network Discovery Results is how you enjoy spending your morning "me" time, those options continue to remain intact and unchanged in this release.

Discovery 5 - Automatic Monitoring.png

 

When selecting "Automatically Monitor" from the "Monitoring Settings" step of the Network Sonar Discovery Wizard you may continue on by clicking "Next" and accept the recommended defaults (only "Up" interfaces, non-removable media volumes, etc.) or use your own preferences by clicking the "Define Monitoring Settings" button. Clicking this button takes you through a mini-wizard where you are given the ability to define what you'd like automatically monitored should they be found during the Sonar discovery process. These options include, but are not limited to, interface type (trunk, non-trunk) , state (up/down/shutdown/etc.) upon discovery, interface name (contains, does not contain), interface description (contains, does not contain), volume type (Fixed Disk, Mount Points, etc), and AppInsight Applications. Additional steps may appear within the mini-wizard depending upon which Orion modules are also installed alongside SAM.

 

The next time the Network Sonar Discovery runs, either at the completion of creating the new Discovery Profile or its next scheduled run, any items found meeting the criteria defined within the profile not already monitored in Orion, will be automatically monitored by SAM.

 

For nodes managed via the optional Agent that was included as part of the SAM 6.2 release, these automatically become managed nodes in Orion by default when they first register with the Orion server or additional polling engine using Agent Initiated mode. Monitoring of these hosts however is limited to status, response time, CPU, and memory, without taking some additional step to select the specific items you'd like monitored on those hosts. The new automatic monitoring option shown here allows you to predefine those items just for agent managed nodes, agentlessly managed nodes, or all nodes in the environment depending upon the settings defined within the discovery profile.

Discovery 6 - Automatic Monitoring - Select Volumes.png

 

There's still more in store for this release, but we are eager and anxious to get your feedback on some of the features already starting to near completion. Please note that the absolute best time to provide feedback is during the beta, as things are still very fluid and there's plenty of time to fix bugs, make adjustments, and alter the design before release. That's right, betas are intended not only as a mechanism for finding bugs, visual defects, or other things broken in the code, but also to address usability issues and design flaws as well. If you are interested in taking SAM 6.3 for a spin and kicking the tires on some of these (and other) features, simply sign-up here. The only requirement for participation in the beta is that you own an existing license of Server & Application Monitor which is currently under active maintenance.

If you frequent the various product and geek speak blogs here on Thwack, you've likely at one time or another stumbled upon some reference, and possibly sneak peek glimpses, into what has affectionately been referred to as the "AppStack". The Application Stack, or "AppStack" for short, is a term used to describe all the various moving parts that make up today's complex application delivery infrastructure. This begins at the bottom with the backend storage arrays where data is housed, through the various different virtualization layers, up to the server that hosts the application, until finally we reach the application itself. The AppStack Environment View shown below accompanies the SAM 6.2, VMAN 6.2, and SRM 6.0 beta releases.

 

SAM Button.pngVMAN Button.pngSRM Button.png

 

The image below isn't the latest incarnation of the Candy Crush sensation, but rather a visual representation of all the various infrastructure components that make up my lab environment. Historically, all of this status goodness was tucked away under each respective categories product tab. Correlation and association of these various objects was a mental exercise based on a working knowledge of the infrastructures initial deployment, or legacy information that has been passed down from systems administrator  to systems administrator before them. To make matters worse, todays infrastructure is dynamic and ever changing, so what you thought you knew about the organizational layout of your supporting infrastructure may have changed dozens, or even hundreds of times since it was initially deployed.

 

AppStack.png

 

The AppStack Environment provides a 10,000 foot overview of your entire environment. At first, this may seem a bit overwhelming as there's a lot of status information contained within a single view. To that end, our UX research team toiled tirelessly to ensure that the AppStack provides as much useful information possible, while reducing or completely eliminating any extraneous noise that could distract from identifying problems in the environment and their likely cause. Perhaps most unnerving to most when first presented with the AppStack Environment View is the lack of object names displayed. Well fret not my dear friend because our UX masterminds thought of everything!

 

In most cases, when trying to get a high level overview into the health status of the environment, you're trying to get as much information represented in as little real estate as possible. If the status is good (green) then likely it's not of any concern. For those objects that are in distress however, you may want to glean additional information into what they are before digging deeper. As with most things in Orion, mouse hovers are available extensively throughout the AppStack Environment view to expose information, such as the objects name and other important details. However, if you're trying to determine the object names for a multiple of objects in distress, a mouse hover is a fairly inefficient means for determining what those objects represent. To address this need you will find a "Show Names" link in the top left of the AppStack. Clicking on this link will expose the name of any object currently in distress. Object names for items that are up (green) remain hidden from view to reduce visual clutter, so it's easier to focus on the items currently in distress.

 

Show Names.png

 

 

The AppStack Environment functions as a status overview page that is valuable when visually attempting to identify issues occurring within the environment, such as in the case of a NOC view, or perhaps the view you keep on your monitor while you go about your usual daily routine.  Any changes in status are updated in real-time for all objects represented in the AppStack. No browser refresh necessary. What you see in the AppStack Environment view is a real-time representation of the status of your environment.

 

Leveraging application topology information gathered across various different products, from Server & Application Monitor (SAM), Virtualization Manager (VMAN), and the all new Storage Resource Monitor (SRM), Orion is now capable of automatically compiling relationships and displaying them in a meaningful fashion between all the various infrastructure components that make up the application stack. Object associations are updated and maintained in real-time, and automatically, as the environment changes. This is important in todays dynamic environments where VMs are vMotioned between hosts, and storage is so easily reprovisioned, reallocated, and presented to servers. If someone had to maintain these relationships manually, it would likely be a full time job that could drive a person insane!

 

Clicking on any object within the AppStack selects that item and displays all relevant relationships the object has to any other object represented within the AppStack Environment. In the case below, I've selected an Application that's currently in a "Critical" state. I can see in the selection bar that this is a Microsoft SQL Server; one I've been having a bit of trouble with lately, so I'm not at all surprised to see it in a critical state. From here I can see which server SQL is running on, the fact that it's obviously virtualized because I can also see the host, virtual custer, datacenter, and data store the VM resides upon as well. None of those appear to be my issue however, as their status is "green". Moving further down the AppStack I can see the volumes that the VM is using, the LUN where the Data Store this VM resides upon, and the Storage Pool itself. So far, so good. Wait a minute, what's that I see? The backend array this VM is running on appears to be having some trouble.

 

AppStack Selected.pngDouble clicking on the Array object, or selecting the array and clicking on the object name from within the selection bar (for those of you rocking a tablet or other touch enabled device) takes me to the Array Details view. There I can see the I/O on this array is exceptionally high. I should probably vMotion a few VMs off the hosts that are utilizing this array, or provision more storage to those hosts from different arrays and balance the VMs across them.

 

Selection Bar.png

 

In this example, the AppStack Environment view was able to cut through the all the various information Orion is capable of collecting across multiple products to expose a problem, provide context to that problem, and identify the root cause. This can be done across the entire environment, or custom AppStack Environment views can be created to focus on a specific areas of responsibility. Perhaps you're the Exchange Administrator, and all you care about is the Exchange environment. No problem! Creating a custom AppStack environment view is simple. You can filter the AppStack by virtually any property available in Orion, such as Application Name, or Custom Property by adding filter properties.

 

Narrow your Envionment.pngSave as New Layout.pngSave as new Layout Dialog.png

 

Once you've filtered the AppStack to your liking and saved it as new layout, you can reference it at any time from layout selector in the top right of the AppStack Environment view. These custom AppStacks can also be used in rotating NOC views for heads up displays, or added to any existing summary view.

 

In addition to this new AppStack Environment View, you will also find a contextual AppStack resource on the Details view of every object type that participates within the AppStack. This includes, but is not limited to...

 

  • Node Details (For Servers)
  • Application Details
  • Array Details
  • Group Details
  • Storage Pool Details
  • LUN Details
  • Storage Pool Details
  • Hyper-V Host Details
  • ESX Host Details
  • Cluster Details
  • Virtual Center Details
  • Datastore Details
  • Volume Details
  • vServer Details
New Layout - Microsoft Exchange.png

 

AppStack MiniStack.png

The AppStack Environment resource provides relevant contextual status information specific to the object details being viewed. The image on the right, taken from the Node Details view of the same SQL server shown in the example above, displays the relationships of all other monitored objects to this node. This context aware application mapping dramatically reduces time to resolution by consolidating all related status information to the object being viewed into a single, easily digestible resource.

 

Relationships aren't limited exclusively to the automatic physical associations understood by Orion however. These relationships can also be extended using manual dependencies to relate logical objects that are associated in other ways, such as SharePoint's dependency on the backend SQL server. This capability further extends the AppStack to represent all objects as they relate to the business service, and significantly aids in root-cause analysis of today's complex distributed application architectures.

 

Earn $100.00 & 2000 Thwack Points!

 

SAM 6.2, VMAN 6.2, and SRM 6.0 beta participants have been given a special opportunity to earn $100.00 and 2000 Thwack points simply for taking part in these betas and providing feedback. To participate you will need to sign-up to participate and install at least two beta products that integrate within the new AppStack Environment view.

 

If you already own Virtualization Manager, you can sign-up here to participate in the Virtualization Manager 6.2 beta, get it installed and integrated with SAM or SRM and you're well on your way to earning $100.00 and 2000 Thwack points. Please note though, that you MUST already own Virtualization Manager and be under active maintenance to participate in the Virtualization Manager 6.2 beta.

 

If you currently own Storage Manager, and are under active maintenance, you can sign-up here to participate in the SRM 6.0 beta. Install SRM alongside SAM or VMAN to earn yourself some quick holiday cash!

 

If you're not yet participating in the Server & Application Monitor 6.2 beta, then what are you waiting for? All SAM product owners under active maintenance are welcome and strongly encouraged to join. Simply sign-up here. If you also happen to own Virtualization Manager or Storage Manager, then now is a great time to try out these awesome combined beta releases, and earn a little cash in the process.

 

Space is limited, so please reply to this post letting us know that you're interested in participating. You'll not only fatten your wallet in the process, but you'll also be helping us to build better products! Here’s how it’s going down.

 

When:What you’ll do:What you receive:
When you receive the beta bits for 2 or more productsHave a 15 minute phone call with our UX team to review what to expect and tell us about your job and technical environmentMy eternal gratitude!
2 to 4 days after installing two or more participating beta productsSend us a 1 to 2 minute video telling us about your initial experiences with AppStack. You can make the video with whatever is easiest for you; most people use their phone.$50 Amazon gift card
7 to 10 days after installing two or more participating beta productsSend us another 1 to 2 minute video telling us about how you've used AppStack. What are your favorite things? What drives you crazy?$50 Amazon gift card
12- 14 days after installing 2 or more participating beta productsSpend one hour with us showing us how you use AppStack.  We’ll  meet using GoToMeeting so that you can share your screen and walk us through some typical use cases.2,000 thwack points

Up until this point, much of the noise surrounding the Server & Application Monitor 6.2 beta has been focused exclusively on a new optional agent that allows for (among many other things) polling servers that reside in the cloud or DMZ. More information regarding this new optional agent can be found in my three part series entitled "Because Sometimes You Feel Like A Nut" linked below.

 

 

If you can believe it, this release is positively dripping with other incredibly awesome new features and it's time now to turn the spotlight onto one that's sure to be a welcome addition to the product.

 

Since the advent of AppInsight for SQL in SAM 6.0, and AppInsight for Exchange in 6.1, you may have grown accustomed to the inclusion of a new AppInsight application with each new release. Well I'm happy to announce that this beta release of SAM 6.2 is no different, and includes the oft requested AppInsight for Microsoft's Internet Information Services (IIS).

 

 

HTML tutorial

 

DISCOVERY


As with all previous AppInsight applications, monitoring your IIS Servers with SAM is fairly straightforward. For existing nodes currently managed via WMI simply click List Resources from the Node Details view and select Microsoft IIS directly beneath AppInsight Applications. You will also see this option listed for any new IIS servers added individually to SAM and managed via WMI using the Add Node Wizard.

 

You can add AppInsight for IIS applications individually using the methods above, or en masse using the Network Sonar Discovery Wizard.  One-time Discovery and scheduled recurring discovery of IIS servers in the environment using Network Sonar are fully supported. Either method will allow you to begin monitoring all IIS servers running in the environment quickly and easily.

 

AppInsight for IIS has been designed for use with IIS v7.0 and greater running on Windows Server 2008 and later operating systems. To monitor earlier versions of IIS such as 6.0 and 6.5 running on Windows 2003 and 2003R2 respectively, you should use theInternet Information Service (IIS) 6 template available in the Content Exchange.

 

AppInsight for IIS discovery is currently limited to WMI managed nodes. For nodes managed via SNMP, ICMP, etc. you can manually assign AppInsight for IIS to the node no differently than any other application template in SAM.

List Resources.png

 

Network Sonar One Time Discovery.png

Network Sonar Discovery Results.png

 

CONFIGURATION

AppInsight for IIS Configure Server.png

AppInsight for IIS leverages PowerShell to collect much of its information about the IIS server. As such, PowerShell 2.0 must be installed on the local Orion server or Additional Poller to which the node is assigned. PowerShell 2.0 must also be installed on the IIS Server being monitored. Windows 2008 R2 and later operating systems include PowerShell 2.0 by default. Only if you are running Orion on Windows 2008 (non-R2) or are planning to monitor servers running IIS 7.0, will you need to worry about the PowerShell 2.0 requirement.

 

Beyond simply having PowerShell installed, Windows Remote Management (WinRM) must also be configured. This is true both locally on the Orion server, as well as on the remotely monitored IIS host. If you're not at all familiar with how to configure WinRM, don't worry. We've made this process as simple as clicking a button.

 

After discovering your IIS servers and choosing which of them you wish to monitor, either through the Add Node WizardList Resource, or Network Sonar Discovery, you will likely find them listed in the All Applications tree resource on the SAM Summary view in an "Unknown" state. This is because WinRM has not been configured on either the local Orion server or the remotely monitored IIS host. Clicking on any AppInsight for IIS application in an "Unknown" state from the All Applications resource launches the AppInsight for IIS configuration wizard.


When the AppInsight for IIS configuration wizard is launched you will be asked to enter credentials that will be used to configure WinRM. These credentials will also be used for the ongoing monitoring of the IIS application once configuration has successfully completed. By default the same credentials used to manage the node via WMI are selected. Under some circumstances however, the permissions associated with that account may not be sufficient for configuring WinRM. If that is the case, you can select from the list of existing credentials available from your Credential Library, or enter new credentials for use with AppInsight for IIS.

 

Once you've selected the appropriate existing, or newly defined credential for use with AppInsight for IIS, simply click "Configure Server". The configuration wizard will do the rest. It should only take a minute or two and you're up and monitoring your IIS server.

 

If configuring WinRM to remotely monitor your IIS server isn't your jam, or if perhaps you'd simply prefer not using any credentials at all to monitor your IIS servers, AppInsight for IIS can be used in conjunction with the new optional agent, also included as part of this SAM 6.2 beta. When AppInsight for IIS is used in conjunction with the agent you can monitor IIS servers running in your DMZ, remote sites, or even in the cloud, over a single encrypted port that's NAT friendly and resilient enough to monitor across high latency low bandwidth links.

 

MONITORING

 

Sites and Pools.pngAs with any AppInsight application, AppInsight for IIS is designed to provide a near complete hands off monitoring experience. All Sites and Application Pools configured on the IIS server each appear in their respective resources. As Sites or Application Pools are added or removed through the Windows IIS Manager, those Sites and Application Pools are automatically added or removed respectively from monitoring by AppInsight for IIS. This low touch approach allows you to spend more time designing and building your IT infrastructure, rather than managing and maintaining the monitoring of it.

 

Each website listed in the Sites resource displays the current status of the site, it's state (started/stopped/etc.), the current number of connections of that size, the average response time, and whether the side is configured to automatically start when the server is booted.

 

It is all too common for people to simply stop or disable the Default Web Site or other unused sites in IIS rather than delete them entirely. To reduce or eliminate false positive "Down" alert notifications in these scenarios, any sites that are in a Stopped state when AppInsight for IIS is first assgined to a node are placed into an unmanaged state automatically. These sites can of course be easily re-managed from the Site Details view at anytime should you wish to monitor them.

 

The Application Pools resource also displays a variety of useful information, such as the overall status of the Application Pool, it's current state (stopped/started/etc.), the current number of worker processes associated with the pool, as well as the total CPU, Memory and Virtual Memory consumed by those worker processes. It's the perfect at-a-glance view for helping identify runaway worker processes, or noisy neighbor conditions that can occur as a result of resource contention when multiple Application Pools are competing for the same limited share of resources.

 

As one might expect, clicking on a Site or Application Pool listed in either of these resources will direct you to the respective Site or Application Pool details view where you will find a treasure trove of valuable performance, health, and availability information.

 

SERVER EXECUTION TIME

Response Time.png

 

The release of Network Performance Monitor v11 included an entirely new method of monitoring end user application performance in relationship to network latency with the advent of Deep Packet Inspection, from which the Quality of Experience (QoE) dashboard was born. The TopXX Page Requests by Average Server Execution Time resource is powered by the very same agent as the Server Packet Analysis Sensor that was included in NPM v11. AppInsight for IIS complements the network and application response time information provided by QoE by showing you exactly what pages are taking the longest to be served up by the IIS server.

 

This resource associates user requested URLs with their respective IIS "site", and its average execution time. Expanding any object in the list displays the HTTP verb associated with that request. Also shown is the date and time of the associated web request, the total elapsed time, IP address of the client who made the request, and any URL query parameters passed as part of the request.

 

New linear gauges found in this resource now make it possible to easily understand how the value relates to the warning and critical thresholds defined. Did I just barely cross over into the "warning" threshold? Am I teetering on the brink of crossing into the "critical threshold? These are important factors that weigh heavily into the decision making process of what to do next.

 

Perhaps you've just barely crossed over into the "warning" threshold and really no corrective action is required. Or maybe you've blown so far past the "critical" threshold that you can barely even see the "good" or "critical" thresholds anymore and a full scale investigation into what's going on is in order. In these cases, understanding where you are in relation to the thresholds defined is critical to determining both the severity of the incident, as well as measuring a sufficiently adequate response.

 

Server execution time is the time spent by the server processing the users request. This includes the web server's CPU processing time, as well as backend database query time, and everything in between. The values shown in this resource are irrespective of network latency; meaning, page load times will never be better than what's shown here in this resource without backend server improvements, regardless of what network performance looks like. Those improvements could be as simple as rebuilding database indexes, defragmenting the hard drive, or adding additional RAM to the server. Either way, high server execution time means users are waiting on the web server or backend database queries to complete before the page can be fully rendered.

 

AppInsight for IIS - Management.png

REMEDIATION

 

What good is the entire wealth of information that AppInsight for IIS provides if there is no way to remediate issues when they occur?

In addition to a powerful assortment of key performance indicators, you will notice new remediation options available within the Management resource of the AppInsight for IIS "Site Details" and "Application Pool Details" views. Within each respective resource is the ability to stop, start, and even restart the selected site or application pool, as well as unmanage. Remediation actions executed through the web interface are fully audited, no differently than terminating processes through the Real-Time Process Explorer, or stopping/starting/restarting services via the Windows Service Control Manager.

IIS Alert Trigger Action.png
In conjunction with one of the many other improvements also included in the SAM 6.2 beta, it is now possible to automate these IIS remediation actions from within the all new web based Alert Manager. Not only can you say, restart a site that has failed, or stop an Application Pool that's running amuck, but you can perform those remediation actions against any IIS site or Application Pool in your environment regardless if it's the site or application pool in distress. This is important for complex distributed applications where issues with backend application servers or database servers may require a restart of the frontend IIS site or application to resolve. Now this can be completely automated through the Advanced Alert Manager, and you can get some much need shuteye.


These are just a few of the capabilities of AppInsight for IIS. If you'd like to see more, you can try it out for yourself by participating in the SAM 6.2 beta. To do so, simply sign-up here. We thrive on feedback, both positive and negative. So kick the tires on the new SAM 6.2 beta and let us know what you think in the SAM Beta Forum.

 

Please note that you must currently own Server & Application Monitor and be under active maintenance to participate in this beta. Betas must be installed on a machine separate from your production installation and used solely for testing purposes only. Also, if you're already participating in the NPM v12 beta, the SAM 6.2 beta can be run on the same server, alongside the NPM v12 beta.

As promised, the long awaited and highly anticipated Server & Application Monitor (SAM) 6.2 Beta is now available for download. The premiere feature of this SAM beta is the new optional agent, which is intended to address key environmental scenarios where conventional agentless monitoring techniques are either impractical or impossible to leverage. Some of these scenarios include, but are not limited to, monitoring Windows hosts within the DMZ over a single fixed port; monitoring servers in remote branch offices over high latency, low bandwidth connections; or monitor the servers you have hosted in cloud based services, such as Amazon EC2, Azure, or Rackspace. For even more examples you can check out Part 1 and 2 of this blog series at the links below.

 

 

If you can believe it, I still have plenty more examples of where this agent might prove beneficial in your environment. I'll be covering more of those in another follow-up later on. For this post though, I want to cover a few of the different agent deployment methods available in the beta.

 

As discussed earlier, most agent based solutions rightfully deserve the negative reputations they have received over the years. Many of the negative connotations associated with those solutions surround abysmal management of the agent software on which they are dependant. With SolarWinds heritage of simplicity and strong emphasis on ease of use in all things we do, we firmly believe we are uniquely qualified to address many of the problems that have long plagued agent based solutions of the past. The first way in which we address this is by making the agent optional.  Striving to be the absolute best agentless management and monitoring solution is in our DNA and will remain so for the foreseeable future.

 

Everyone knows that the biggest headaches suffered at the hands of typical agent-based solutions has been the initial deployment and continual upkeep of the agents themselves. Agentless solutions allow you to install software on a centralized server and you're up and monitoring in no time. As new versions are released, you simply upgrade the server where the monitoring solution is installed and you're back up and running. The only thing left to do at this point is hit the big red button you got from your local office supply chain and call it a day.

 

With this in mind, as we set out to build this agent we were determined to ensure that it was not only incredibly powerful and flexible, but that is was also simple to deploy and easy to maintain. Not just easy in comparison to previous generations of agent based solutions, but "easy" by even agentless standards. If you would like to try out this new agent included in the SAM 6.2 beta and follow along, click the button below to sign-up.

thwack-blue.png

Agent Deployment - Add Node Wizard

 

For servers within your environment, Agent deployment is as simple as adding a new node to Orion. From within the Add Node Wizard you will notice a new "Agent" option listed alongside the familiar ICMP, SNMP, WMI, and External polling methods. After entering the IP address, hostname or fully qualified domain name of the server you wish to monitor, choose Agent as the method for polling the node. Selecting this new Agent option then prompts you to provide administrative credentials. These credentials are used solely for the purpose of installing the agent on the remote host. Once the agent is fully deployed to the remote host, the Local System account will be used for all node polling functions. After the credentials have been entered click "Next". Orion will then validate the credentials entered and check to see if the Agent software is already installed on the host. If it is not, you will be prompted to install the Agent software. Clicking "Start Install" will then begin the process of remotely deploying the Agent to the host, and a progress indicator will appear denoting the progress of the installation. Remote agent deployment typically takes a minute or two to complete, but across WAN links installation may take longer. If you don't feel like waiting around for the installation to complete you can click on the "Go to Manage Agents while install continues" link in the progress window. Deployment and installation will continue in the background allowing you to work on other things while you wait. If you choose to leave the Add Node Wizard during agent deployment you will be notified via the Notification Banner at the top of the screen once the agent is installed. Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor on the node.


If you opt to continue through the Add Node Wizard process throughout the installation of the agent, you will be walked through the rest of the existing Add Node Wizard process flow that you are likely already familiar with. You will be prompted to select which resources on the host you wish to monitor (Volumes, Interfaces, Hardware Health, Asset Inventory, AppInsight applications, etc.) as well as select which application templates you'd like to assign to the node. The final step of the Add Node Wizard allows you to review the node properties, update any Custom Properties, or revise any node thresholds and polling intervals. When you're done reviewing the node properties, simply click the "Ok, Add Node" button to complete the process of adding the agent managed node to Orion.

Agent Deployment Wizard

 

If deploying agents individually isn't your speed, you can opt instead to deploy agents to multiple endpoints simultaneously from within the Orion web interface using the Agent Deployment Wizard. Located under [Settings -> Manage Agents] appears the "Add Agent" option. Clicking this button will walk you through the process of deploying the agent to any existing managed Windows node within Orion. You can also specify the IP addresses of Windows hosts within your environment that are not yet Orion managed nodes. To deploy an agent to an existing managed node in Orion, select it from the grid displaying the full list of WIndows nodes managed in your Orion environment. To deploy the agent to Windows hosts not yet managed by Orion, simply enter the IP address or hostname and click "Add to list". Once you've compiled the full list of hosts you wish to deploy the agent to, click "Next" to proceed on to the next step within the Wizard.

 

The next step is to provide credentials for deploying the agent to the selected hosts. You can select each host individually or multiple hosts in bulk and assign credentials to use for agent deployment. Credentials are validated as they are assigned to hosts, which helps eliminate potential agent deployment failures. When all hosts have valid credentials assgined you can click the "Deploy Agent" button to begin the agent deployment process.


While agents are being deployed you can continue working within the Orion web interface and will be notified via the Notification Banner at the top of the screen once the agents have been deployed. Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor for each node. At any time you can check the progress of the Agent deployment process by going to "Manage Agents" under "Settings". This is also where you will find any potential errors related to agent deployment processes or edit agent settings.


Regardless of which push deployment method used, be it the Add Node Wizard or the Agent Deployment Wizard, you will need to ensure that TCP Port 445 is open from the Orion server to the hosts you wish to deploy the agent. The agent must also be able to communicate back to the Orion server over TCP Port 17778. For more information on agent deployment requirements you can reference the NPM v11.0 QoE Agent Deployment Guide.

Mass Agent Deployment Option

Mass Agent Deployment Option.png

Agent deployment from within the Orion server itself may be the easiest way to manage one, or even dozens of hosts within your environment, but what if you need to manage hundreds or even thousands of hosts using the agent? What if the hosts you're trying to manage are outside your environment and aren't directly accessible from the Orion server via RPC, such as host in the cloud or at a branch office behind NAT?


In cases such as these, it may be beneficial to utilize a software distribution solution to deploy the agent to the hosts you wish to manage. These can be software distribution tools built natively into Windows such as Group Policy, or commercial products like System Center Configuration Manager or SolarWinds Patch Manager to name a few. If you have servers running in the cloud, such as Amazon EC2 you may want to bundle the Agent as part of the server so that any dynamic elastic instances created are also managed in Orion. If you happen to be hosting servers on Azure, you can leverage Web Deploy to distribute the Agent to those servers as well. Really any solution that allows you to distribute MSI packages can be utilized to deploy the agent software.


You will find everything you need for mass agent deployment within the Orion web interface under [Settings ->  Agent Settings -> Download Agent Software] as pictured on the left. All agent settings that will be used during deployment can be preconfigured here, such as agent communication method ("Agent Initiated" or "Server Initiated"), as well as which polling engine the agents should communicate with. In the case of Agent Initiated Communication, you can specify an alternate IP address, hostname, or Fully Qualified Domain Name the agent should communicate with in the event the Orion server itself is hidden behind a firewall using address translation.


All preferences selected within this web interface are contained inside the Microsoft Transform (MST) file, which serves as the configuration setting for the Windows Installer (MSI) Package. Both the MST and MSI files are used together in conjunction with your software distribution mechanism of choice to deploy the agent software with the preferences selected here.


As agents are deployed within the environment or new cloud instances pre-packaged with the agent software installed come online, these hosts will begin registering with the Orion server and become managed nodes within Orion automatically. Thus dramatically reducing management overhead. As agents automatically register with the Orion server and become managed nodes within Orion, admins will be apprised through the Notification Banner at the top of the Orion web interface. Automatic registration and node management can, of course, be optionally disabled under [Settings -> Agent Settings -> Define Global Agent Settings] for environments where this behavior may not be desirable. When these options are disabled, agents must be individually allowed to register using the [Add Agent -> Connect to a previously installed agent] option located under Manage Agents section of the Settings view.

Manual Agent Deployment Option

 

 

If deploying the Agent software from within the Orion web interface isn't possible, due to NAT, firewall policies, or access control lists, and group policy or other software deployment mechanisms aren't really your thing, the agent can of course be installed manually on the host you wish to monitor. The agent software can be downloaded from the Orion web interface under [Settings ->  Agent Settings -> Download Agent Software] from the host where you plan to install the Agent software. Alternatively the agent installer is a mere 16MB in size, which is small enough for most environments that it can be emailed to engineers in the field as they bring new services online.

 

During the manual installation of the the Agent you are prompted to provide information, such as the IP address of the Polling Engine the agent will communicate with and your Orion credentials so that the agent can connect and register with the Orion server. Once the installation is complete the host where the agent was installed will automatically register with the Orion server and become a managed node. You will also be notified via the Orion web interface in the Notification Banner that a new agent has registered with the Orion server and become a managed node.Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor on the node. If you would rather be notified via email, syslog, SNMP Trap, etc. you can optionally configure an alert to notify you of any new agents registered with the system.


Agent Management

Global Agent Settings.png

 

One of the biggest headaches associated with traditional agents has been maintaining them as new versions are released. Commonly, once the management server itself is upgraded you are blind to what's going on within the environment until all agents are also updated to the same version as the server. This means that a coordinated effort is required to properly upgrade the management server and all associated agents simultaneously to limit the amount of time you're without visibility into the environment. The additional overhead and orchestration required to successfully accomplish such an endeavor is commonly deemed not worth it, and upgrades are avoided unless deemed absolutely essential. Even then, the process is nightmarish at best.

 

While developing the Agent it was our intent to make it as much of a hands off experience as agentless monitoring is today. This means building an agent that is completely self maintaining. As new versions of SAM, NPM, or other products that utilize the Agent are released, the agent automatically updates itself once the Orion server is upgraded. Agents update themselves over the same communication channel the agent uses for polling, allowing agents that were deployed to hosts behind firewalls, proxies, or in the cloud to be updated simply and transparently.

 

For instances where automatic agent updates may not be desired, this feature can be disabled both globally or on an individual agent by agent basis from within the Orion web interface. In the event automatic agent updates are disabled, you still have the ability to approve agent updates manually through the Orion web interface. This affords you the ability to control exactly when agent updates occur on an individual agent by agent basis without the need to manage agent updates separately through other software distribution methods.

Delete Agent Node.png

Another common point of contention associated with agents is cleaning up after them. Accidentally deployed an agent to a server you didn't mean to monitor, but don't want to deal with the hassle of uninstalling the agent? No problem. Whenever you attempt to delete an Agent managed node in Orion you are given the option to uninstall the agent software from that host. This works for individual nodes deleted from Orion or multiple nodes selected at the same time. Unlike agent deployment however, uninstalling the Agent from the Orion web interface does not require connectivity to the agent managed host via RPC. Instead, the uninstall command occurs over the same communication channel the agent uses for polling. This means you can remotely uninstall agents that were deployed to hosts behind firewalls, proxies, or in the cloud from the comfort of the Orion web interface.


These are just a few of the ways this new agent is designed to make management and monitoring simpler than other agent based products you may have used in the past. All these great new capabilities are available now in the latest Server & Application Monitor 6.2 beta. If you currently own Server & Application Monitor and are under active maintenance we would love you to try out the new agent and give us your feedback. Simply sign-up here to download the SAM 6.2 beta and participate.

As promised in my earlier blog post entitled, "SAM 6.2 Beta - Because sometimes you feel like a nut - Part 1," here are some additional scenarios where the new agent included in the forthcoming Server & Application Monitor 6.2 beta could prove beneficial in ways you may not have even thought of yet. (As a reminder, SolarWinds remains firmly committed to our "Agentless First" approach for virtually everything we do!)

 

For those who need an agentless alternative to monitoring certain aspects of their environment, the new and optional agent is yet another powerful tool in your arsenal. Where you might wield this new weapon is entirely up to you.

 

Below are three additional examples in a continuing series where I outline some of the tangible benefits of the agent. If you'd like to kick the tires on the new agent, please feel free to participate in the SAM 6.2 beta. We'd love to get your feedback. Simply sign-up by clicking the link below:

 

 

SAM6.2Beta Button.png

Head in the Clouds

 

Monitoring applications and servers running in the cloud using traditional agentless protocols is fraught with issues. For instance, by default, the WMI protocol is not fully encrypted, nor will it traverse NAT boundaries. WMI also requires a healthy number of open ports to function properly, not to mention that it's a fairly chatty protocol that doesn't tolerate bandwidth congestion or high latency conditions very well. Problems like these are further exacerbated by the fact that many ISPs block RPC traffic on the internet due to the protocols historical association with worms and hacker exploitation.

 

Unfortunately, the SNMP protocol fares only slightly better than WMI. Currently, all versions of Windows still rely upon SNMPv2, which provides no authentication or encryption. While SNMP has been designed to work in harsh bandwidth contentious environments, as well as traverse firewalls with ease, there still remains an ever decreasing amount of useful information available that can be collected from Windows devices via SNMP. This fact alone, coupled with Microsoft's recent depreciation of SNMP in Windows 2012, suggests that no further dependency should be built on the protocol for monitoring Windows devices.

 

Passive vs Active.png

The agent included in the SAM 6.2 beta allows you to monitor servers hosted by cloud based services such as Amazon EC2, Rackspace, Microsoft Azure, or virtually any other Infrastructure as a Service (IaaS).


Agents installed on Windows servers hosted in the cloud are then monitored by Orion no differently than any other server in your environment. Each agent can be configured independently to operate in the mode that best suits your needs. For instance, you may want to use Server Initiated mode for servers hosted on Amazon EC2 because they all have publicly routable IP addresses. Conversely, you may want to use Agent Initiated mode for servers you're hosting in Azure because these servers may be hidden behind a NAT.

 

Each agent can also be configured to communicate with a specific Orion server or additional poller for load distribution.

Once deployed, the agent eliminates the issues associated with the WMI and SNMP protocols outlined earlier. All communication between the Orion server and the agent occur over a single fixed port. This communication is fully encrypted using 2048 bit TLS encryption. The agent protocol not only supports NAT traversal, but also supports passing through proxy servers that require authentication. The protocol the agent uses has been designed from the ground up to be extremely efficient and operate in low bandwidth, high latency environments. This makes it ideal for monitoring servers located in the cloud.

 

Finally, the agent is far more secure than either WMI or SNMP simply because there are no listening ports at the endpoint when using the Agent Initiated mode. This means there is zero attack footprint exposed by the Agent on the monitored endpoint that could be leveraged and exploited remotely by hackers or cyber criminals. Both SNMP and WMI expose listening ports on the host where they are running, making the agent a much more attractive option for monitoring servers running in the cloud.

 

You can't keep a good agent down

 

Agent Connecivity Failure.png

Unlike traditional agentless monitoring techniques, the Agent included in the SAM 6.2 beta is resilient to failure. In the unlikely event the Orion Server or Additional Poller were to go down for any reason, agentless monitoring of any hosts or applications monitored by that poller stops until that server is brought back online. This leaves gaps in performance charts and availability reports. This is also true for other types of failures that can occur anywhere in between the poller and what's being monitored, such as network equipment issues, WAN circuit problems, or VPN tunnel hiccups.

 

The agent, on the other hand, operates independent of the poller it's associated with and continues monitoring the server and its applications, regardless of whether or not it can communicate with the poller. Once connectivity to the poller is restored, the agent then forwards the results of its monitoring during the outage to the poller for processing, All gaps in the data will be filled with the data collected by the agent that would have ordinarily been lost if the host were being monitored without an agent.

These were just a few additional scenarios where you might find using an agent beneficial in your environment. As previously stated, the new agent is completely optional and intended to address specific needs where agentless monitoring of Windows hosts is either difficult, or simply not possible. As my final example demonstrated, there are other advantages the agent can provide to complement your agentless monitoring architecture. I will outline more examples in a follow-up posting, as well as provide a walkthrough of some of the agent deployment methods that are available in the beta.

 

The SAM 6.2 beta is not yet available, but will be very soon. If you would like to sign-up to participate in the beta, you can do so by completing a short survey. You need only be an existing SAM customer under active maintenance. Once available, you will be notified via email with a download link to the SAM 6.2 beta.

There's been quite a bit of chatter recently surrounding the hotly anticipated release of Network Performance Monitor v11, featuring the entirely new Quality of Experience (QoE) dashboard. At the center of what makes all of this amazing QoE information possible are Packet Analysis Sensors, which can be deployed either to the servers running the business critical applications themselves, or to a dedicated machine connected to a SPAN port which collects the same information completely out-of-band for multiple servers simultaneously. For all intents and purposes, these Packet Analysis Sensors could be considered specialized agents, solely dedicated to the purpose of collecting packet data from the network. But what if these "agents" could be used to monitor other aspects of the servers they were installed on, or leveraged to address many of the complicating factors and limitations associated with agentless monitoring? These were precisely the kind of questions we asked ourselves as we were developing the Packet Analysis Sensors for NPM.


What are these "complicating factors" you might ask? It depends on your environment's architecture. It's quite possible you have numerous uses for an agent today that you're not even aware of yet. Either due to network design obstacles or security requirements and concerns, there are many organizations that have had to make compromises regarding what they monitor, how, and to what extent. This has left blind spots on the network, where some servers or applications simply cannot be monitored to the full extent desired, or not at all in some cases. With the soon-to-be-released beta release of Server & Application Monitor (SAM) 6.2 we take Orion into a brave new world without compromise.


HTML tutorial

 

So what exactly are some of the challenges many of us face when attempting to monitor our server infrastructure and the applications that reside upon them? 


You can't get there from here

Agent Initiated Communication.png

This is a typical colloquialism you might hear when visiting the great state of Maine, but has been adopted by the IT community commonly to refer to situations where there's no route between two network segments. In most cases this is because one or both networks are behind a NAT device such as a firewall, and there's simply no way to get to the private address space behind the NAT without creating port forwarders, 1:1 address translations, or establishing a site-to-site VPN between the two networks.

 

With the new Agent included in SAM 6.2, these problems are a thing of the past. This new agent supports two different modes of operation. In the scenario on the left, the Agent is functioning in "Agent initiated mode", which means all communications are initiated from the server where the agent is installed. No direct route from the Orion server or additional poller to the monitored host is required. No port forwarding needs to be configured at the remote site, nor do you need a pool of public routable IP addresses at each remote site for 1:1 address translation to each device you wish to monitor behind the NAT.

 

With the agent installed on the remote Windows host, you can perform essentially all of the same node and application monitoring that you normally would for agentless hosts within your network, across what would otherwise be disconnected networks.

You want me to open what?

Agent Server Initiated.png

Such is the reaction you're likely to receive when you ask the network/firewall admin what ports you need opened to monitor the servers located in the DMZ. As I discussed in one of my early blog posts "Portocalypse - WMI Demystified" the port range WMI uses for agentless communication can be enormous. While this range can be significantly reduced, it does require either manual registry modifications or creation of a custom group policy. A reboot of each server that has its WMI port range modified is also required before the changes will take effect. As if that weren't bad enough, WMI won't cross most NAT devices. If your internal network goes through a NAT to access the DMZ, you're very likely unable to utilize WMI for monitoring any Windows hosts in your DMZ.

 

To eliminate these issues, the new agent included in this SAM 6.2 beta allows you to operate the agent in a "Server Initiated" mode. In this mode the agent operates over a single port (TCP 17790) similar to "Agent Initiated" mode. The difference in "Server Initiated" mode is that TCP port 17790 is listening on the host where the agent is installed and the Orion server polls information in a similar fashion to SNMP or RPC, instead of having it pushed to the Orion server in "Agent Initiated" mode. Zero ports need to be opened inbound to the internal network from the DMZ, and all communication is done across a single NAT friendly port.

Peekaboo - I see you!

 

Whether it's the NSA, those willing to perform corporate espionage, or the black hat hacker who hangs out at your local Starbucks, it's important to keep prying eyes from peering into your organizations packets. While SNMPv3 has existed for quite a long time, all versions up to and including Windows 2012 R2 still rely upon the older and less secure SNMPv2, a protocol which provides no encryption or authentication. While Microsoft's WMI protocol addresses the authentication aspects that are sorely lacking in SNMPv2, encryption is different matter altogether. While it's possible to force the use of encryption in the WMI protocol, this is not the default behavior and is seldom ever done. This requires modifications to WMI namespaces to force the use of encryption, a process that must be repeated on each host you wish to manage. Beyond that, your monitoring solution must also work with WMI encryption, something very few solutions on the market today support.


The Agent included in the SAM 6.2 beta has been designed from the ground up with security first and foremost on our mind. To that end, the agent utilizes FIPS compatible 2048 bit TLS encryption to ensure all communication between the Agent and the Orion Poller are fully encrypted and safe from would-be cybercriminals.

 

How slow can you go?

 

Not all protocols are created equal. WMI and RPC may be right at home on todays gigabit Ethernet networks, but that is because these protocols were designed almost two decades ago as LAN protocols. These protocols were never designed to traverse bandwidth-contentious WAN links,nor function in high latency environments or across the internet. Attempting to use either of these agentless protocols in these scenarios is very likely to result in frequent polling timeout issues. Roughly translated, this means you are completely blind to what's going on.

 

The Agent in SAM 6.2 eliminates the issues associated with these protocols by utilizing the standards based HTTPS protocol, which is both bandwidth-efficient and latency-friendly. This means the agent could be used to monitor such extreme scenarios as servers running on a cruise ship or oil platform in the middle of the south pacific from a datacenter in Illinois via a satellite internet link without issue, something that would be otherwise impossible using traditional agentless protocols such as WMI or RPC.

 

What does this mean for Agentless Monitoring in Orion?

 

There are still plenty more challenges this new Agent is aimed at addressing that I will cover in a follow-up post. In the meantime, however, you might be wondering what this means for the future of agentless monitoring capabilities that Orion was built upon.

 

Absolutely nothing! SolarWinds pioneered the industry in agentless monitoring, and remains 100% committed to our "agentless first" approach in everything that we do. SolarWinds will continue to push the boundaries of agentless technologies to the very limit of their capabilities and beyond. We will continue to lead the industry by being at the forefront of new agentless technologies as they emerge, now or at any time in the future.

 

Agent vs Agentless - The war rages on

 

The war between agent-based and agentless IT monitoring solutions has gone on as long as there have been things in the environment that needed to be monitored. Agentless monitoring solutions have always had the advantage of not requiring any additional software that needs to be deployed, managed, and maintained throughout the devices lifecycle. There is typically little concern over resource contention on the host being monitored because there is essentially zero footprint on the machine in an agentless configuration. Due to the nature of agentless monitoring solutions, they can be deployed and providing value within a couple of hours in most environments. Agent based monitoring solutions typically require rigorous testing, as well as going through a tedious internal configuration change approval process before any agent software can be deployed into production. Agent deployment is commonly a manual process that requires running the installation locally on each server before they can be monitored. Then there are the security concerns associated with having any piece of software running on a server that could potentially be exploited by a hacker as a means of entry into the system.

 

If Agentless is so great why did SolarWinds build an Agent?

 

If the agent vs agentless war has taught us anything, it is that each approach has its own unique advantages and disadvantages. There is no single method that suits all scenarios best or equally. This is why we fundamentally believe that for full coverage, any monitoring solution you choose must provide excellent agentless monitoring capabilities, as well as provide an optional agent for those scenarios where agentless monitoring simply isn't feasible or prudent.

 

We here at SolarWinds believe that, given our agentless heritage, we are uniquely qualified to understand and address many of the problems that have plagued agent-based monitoring solutions of the past. It is our intent to make agent-based monitoring as simple and painless as agentless monitoring is today.

 

Ok, so what exactly does this agent monitor anyway?

 

The agent included in SAM 6.2 will be capable of monitoring virtually everything you can monitor today on a WMI managed node in SAM. This includes, but is not limited to node status (up/down), response time, latency (all with no reliance on ICMP), CPU, Memory, Virtual Memory, Interfaces, Volumes, Hardware Health, Asset Inventory, Hyper-V virtualization, as well as application monitoring. This very same agent can also be utilized as a Packet Analysis Sensor for deep packet inspection if so desired and appropriately licensed. The agent is officially supported on the following Windows operating systems.

 

  • Windows 2008
  • Windows 2008 R2
  • Windows 2012
  • Windows 2012 R2

 

While the agent should also work on Windows 2003 and 2003 R2 hosts, these operating systems are not officially supported. Non-Windows based operating systems such as Linux/Unix are also not supported by the agent at this time. If you are at all interested in a Linux/Unix agent for SAM that provides monitoring of Linux/Unix systems and applications, you can vote for this idea here.

 

Sounds good, but how much is this going to cost me?

 

The agent software is essentially free. You remain bound by the limits of the license you own regardless of how you're polling that information, either via an agent or agentless. For example, if I own a SAM AL150 license, I can monitor 150 nodes, volumes, and components. This remains true if I'm monitoring those servers with an Agent installed or agentlessly.

 

Sign me up already

 

There's still plenty more agent stuff to talk about, including additional scenarios where the agent could be used to overcome common obstacles you might encounter with agentless monitoring. In my follow-up post I will discuss some of those as well as cover the various different agent deployment options and agent management, so stay tuned for more information.

 

If you're anything like me, you'd much rather try something out yourself then read about it. Fortunately for you this new Agent is included as part of the SAM 6.2 beta, which will be available soon. If you currently own Server & Application Monitor and it's under active maintenance, you can sign-up here. You will then be notified via email when the SAM 6.2 beta is available for download.

We've just wrapped up the Server & Application Monitor 6.1.1 Service Release, meant to address any major outstanding issues identified in SAM 6.1 since its official release. Now it's time once again to turn our attention to the future of Server & Application Monitor. With that said, below is a list of items the team is currently working on.

 

  • AppInsight for IIS
    • Sites
    • Application Pools
  • Optional Agent for Monitoring Windows Applications and Servers that addresses the following needs:
    • Allows for polling host and applications behind firewall NAT or proxies
    • Polling node and applications across multiple discrete networks that have overlapping IP address space
    • Allow for reliable and secure encrypted polling over a single port
    • Support low bandwidth, high latency connections
    • Polling nodes across domains where no domain trusts have been established
    • Full end to end encryption between the monitored host and the Orion poller
  • Application stack integration and visualization (E.g. visual mapping through the entire application stack to help identify root cause of performance and availability issues)
  • Performance & Scalability Improvements
  • Web Based Advanced Alert Manager
  • Packet-level Traffic Analysis and Classification
  • Web Based Syslog and Trap Management
  • Unmanage Behavior Improvements
  • Disk Volume Capacity Forecasting
  • Mandatory Custom Properties
  • Independant Volume Thresholds
  • Hardware Health Improvements
  • Support for SQL Server 2014

 

PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

Server & Application Monitor 6.1.1 Release Candidate is now available for all SAM customers under active maintenance through your Customer Portal. Release Candidates are fully supported and upgradable to the final release when available. If you are experiencing any of the issues outlined below, we recommend downloaded the SAM 6.1.1 Service Release and upgrade now.

 

Fixed Issues and Additions in this Release

This release of SAM includes the following fixes and additions:

Version 6.1.1

Fixed Issues:

  • An issue where certain Asset Inventory resources were displaying volumes that were not appearing in the web console has been fixed. a
  • The Exchange database file size default limit was increased in size from 50 GB to 1 TB, and can now be configured manually in the following file: SolarWinds.APM.BlackBox.Exchg.Collector.dll.config.  The 50 GB limit made it difficult to determine proper thresholds. b
  • An issue where AppInsight for Exchange incorrectly calculated the limit for any mailbox database on Exchange 2010 Standard Edition at 50GB has been resolved. c
  • An issue where a PowerShell scripts are unable to run because user accounts and the Exchange server are from different domains has been resolved. d
  • An issue where AppInsight for Exchange threw an error citing, Exchange Version Mismatch, has been resolved. e
  • A conflict between:
    • Windows Scheduled Task Manager and templates of the same name causing the former not to function properly, has been fixed. f
    • AppInsight applications and templates of the same name causing the former not to function properly, has been fixed. m
  • An issue where certain Asset Inventory resources were showing duplicate records due to external updates has been fixed. g
  • AppInsight for Exchange now has the ability to poll all mailboxes within a domain forest. Prior to this fix, AppInsight for Exchange could only poll root mailboxes.  
  • A memory leak has been fixed. This leak occurred during the attempted initialization of certain performance counters resulting in performance counters endlessly attempting to start. i
  • An issue where some physical servers being monitored were falsely reporting a child Warning status has been fixed. j 
  • AppInsight for Exchange now supports Windows 2008 (non-R2). k 
  • A timeout setting has been increased for Linux script execution which now prevents a script execution error. l
  •   A Linux script execution error has been fixed. n, p, q
  • After  upgrading to SAM 6.1, an issue where the variables, ${Threshold-Statistic-Critical} and ${Threshold-Statistic-Warning} no longer populated, has been fixed. o
  • An issue where certain Asset Inventory resources were showing duplicate records due to external updates has been fixed. g
  • AppInsight for Exchange now has the ability to poll all mailboxes within a domain forest. Prior to this fix, AppInsight for Exchange could only poll root mailboxes.
  • A memory leak has been fixed. This leak occurred during the attempted initialization of certain performance counters resulting in performance counters endlessly attempting to start. i
  • An issue where some physical servers being monitored were falsely reporting a child Warning status has been fixed. j
  • AppInsight for Exchange now supports Windows 2008 (non-R2). k
  • A timeout setting has been increased for Linux script execution which now prevents a script execution error. l

 

Table of Fixed SAM Issues

The following table provides the internal Development ID numbers and external support ID numbers for fixed SAM issues as well as new feature requests in this release. Search in the support ID number column for the number assigned to your support case.

 

SuperscriptSupport ID numberDevelopment ID number
a591714321074
b586749318056
c603164328359
d591412320755
e593737321838
f, m594985, 602168323456, 328549
g576182312166
h581448314906
i490700255402
j577567312188
k596422324735
l599218326004
n, p, q594888, 583631, 601187323753, 325219, 327131
o598659325679

We here at SolarWinds are continuously looking to improve our products in both functionality and user experience. Failover Engine (FoE) as you can imagine, doesn't get a tremendous amount of feedback from the Thwack community. This is because FoE is akin to the spare tire sitting in the trunk of your car. You hardly ever think about it until you need it. With that in mind, I've compiled a few thought provoking questions that I hope will engage those of you in the community to think about how you use FoE. This should help to give us a better understanding how and where we can improve FoE in the future,

 

What has your experience been like Installing/Upgrading FoE?

In an Failover Engine LAN Configuration How do you Maintain the Standby Host?

Are your Failover Engine member servers joined to the Domain?

How do you prefer to manage administrative tasks in Failover Engine?

What is the primary reason your Orion server is down?

How much redundancy is enough for your environment?

At first glance, Server & Application Monitor (SAM) 6.1 might sound like it's a "minor" release. However, with the mountain of new features we've managed to cram in, 6.1 is anything but minor. In previous blog posts I discussed Windows Scheduled Tasks and JSON/XML monitoring, as well as Sustained Threshold Conditions that can be used to squelch nuisance alerts. Despite more than half a dozen additional new features in this release I haven't even talked about yet, such as new SOAP Monitor, Drag & Drop resources (that's right, I said drag and drop), and a new Web-Based Report Scheduler, much of the buzz surrounding SAM 6.1 has centered around AppInsight for Exchange. This is likely due to the success of AppInsight for SQL in the SAM 6.0 release, coupled by the tease that was my previous blog posting entitled "Introducing AppInsight for Exchange - Server & Application Monitor 6.1 Beta 2 Sneak Peek". In that post I gave readers a very early glimpse into AppInsight for Exchange, that barely scraped the surface of what this new application monitoring capability provides. So today I'll attempt to satisfy some of that curiosity by showcasing some of the other functionality included in AppInsight for Exchange.

 

I first cut my teeth back in the day of Exchange 5.5. Since that time I've seen tremendous improvements in Exchange scalability, reliability, and performance. As a consequence of these improvements however, Exchange has become significantly more complex to manage, monitor, and maintain. Simply isolating a performance bottleneck in your Exchange environment can be akin to playing a bad game of "Where's Waldo".

 

AppInsight for Exchange ends the madness by centrally consolidating all information about each mailbox database and its copies across all mailbox servers in the Database Availability Group, into a single Mailbox Database Details view. It is within this Mailbox Database Details view where you will find all relevant information pertaining to that specific individual mailbox database on the server, as well as all other servers where a copy of that database resides.

 

Information including last full and incremental backup, number of mailboxes in the database, average mailbox size, and default storage quotas applied at the mailbox database are all easily at hand.

Database Details.png
Database size and disk io.png

The Database Details view also contains multi-server performance, health, and availability information that should make troubleshooting common mailbox database issues a breeze.

 

For example, in the screenshot to the left you can easily identify where the mailbox database resides on each servers file system, the size of that mailbox database, and how it relates to the amount of free space on each servers volume. You can also identify disk I/O performance issues across servers by seeing the Disk Queue Length, Latency, and total IOPS for the volumes on each server where a copy of that database resides.

 

Similar resources also appear in this view for Transaction Logs, showing additional detail such as the total number of transaction log files, as well as their cumilitive total size on disk.

 

All this information allows you to easily spot problems before they start. There's nothing worse, or more preventable than a database dismounting because the volume it's located on has run out of space. With AppInsight for Exchange, now you can be proactively alerted and take corrective action before it impacts your users.

Now let's say your mailbox database was running out of space. Where do you go, and what do you do now? You could move the mailbox database to a different volume that has more space. If you have more unallocated storage you could even extend the volume. Both of those options require heavy lifting, and likely some downtime.

 

What if you could easily identify the offending user mailboxes that are taking up a large percentage of space in the database? You could then either hunt those users down and ask them them to clean up their mailbox, or move them to another mailbox database that has more available space.

 

The "Users By Mailbox Quota Used" and "Users By Mailbox Size" resources allow you to view each and every user mailbox, its total size, amount of space all attachments in the mailbox are consuming, total number of attachments, and percentage of quota used. This information is available in each mailbox database view, as well as across the entire Exchange environment.

 

You can even spot dormant mailboxes easily within the same resource by viewing the "Last Accessed" date.

Users By Mailbox Quota Used.png

From this resource you can drill down even further into the User Mailbox Details view. Here you can see the quota limits applied to the individual users' mailbox, the Active Directory Organizational Unit where this user resides, and can even click their Primary SMTP Address to notify them that some mailbox cleanup is required.

 

Before you do that though, you might want to get a better understanding of how this user is using their mailbox. Perhaps they recently received several very large email attachments that they could move off onto the file server. Maybe this user regularly receives a large volume of incoming email. This could be normal given their job function, or indicative of ineffective SPAM filtering.

 

With AppInsight for Exchange you can easily visualize each users historical mailbox usage, identify trends such as the growth of a user's mailbox over time, and the total size of all attachments within the users mailbox over the same period. You can also gain insight into the volume of mail sent and received by the user each day, both internally and externally.


This information allows you to make informed decisions before extending users mailbox quotas or adding additional storage to the Exchange server. This information can also be included in alerts that give helpdesk staff a heads up as users approach their quota limit.

Mailbox Details.png
Total Mailox and Attachments Sizes.pngReceived Mail.png

What if the problem you're facing was the other direction? Instead of a massive influx email or attachments driving the users mailbox size, it was malicious activity the end user wasn't even aware of? The Users By Messages Sent resource helps identify mailbox abuse caused by potential trojans, botnets, or otherwise unscrupulous activity. Should your users mailbox be taken over by such mass mailing marauders, AppInsight for Exchange makes identifying this unusual traffic a trivial affair.

 

AppInsight for Exchange also allows you to report on the mobile devices being used in your environment, the operating system version running on those devices, as well as the last time any device was used to connect to Exchange via ActiveSync.

 

This information is available on any individuals Mailbox User Details view. It is also available as an out of the box report that lists all mobile devices in use in your organization and their respective owner.

 

Until now, SAM 6.1 has been available only to a select number of beta participants, but that's no longer the case. As of today, all current SAM customers under active maintenance can download and install the official SAM 6.1 Release Candidate simply by signing up here. Upgrading of your existing production Server & Application Monitor installation is also fully supported. So give AppInsight for Exchange, or any of the over a dozen other improvements in this release a go, and tell us what you think!

Users By Messages Sent.png

Synced Devices.png

 

SAM 6.1 RC button.png

Filter Blog

By date: By tag: