It’s been a long and exciting Beta and Release Candidate process, and the First thoughts of SAM 5.0 RC2 from our SAM testers along the way has been Oh, APM (now SAM!) How You Have Changed My Life.... They each helped ensure that SAM 5.0 is a rock solid release. With that in mind, I’m pleased to announce today that SolarWinds Server & Application Monitor 5.0 has now been officially released! I encourage all customers who installed any of the release candidates (RC1 – RC3) to upgrade to the GA build, now available in your customer portal. There you will also find permanent commercial license keys for SAM 5.0 that will need to be applied to your installation.

 

In my last Application Performance Monitor 5.0 Beta – Sign up now blog posts I’ve covered some of the major new features included in the newly renamed Server & Application Monitor 5.0 (SAM), such as the Real-Time Process Explorer (RTPE), multi-vendor server hardware health monitoring, and WMI node management with improved credentials handling. Today I’m going to touch on some of the lesser known features also included in this release.

 

SAM Admin Role and More     
    
Commonly I hear from SolarWinds Network Engineers who’ve been using our Network Performance Monitor (NPM) that they want to share some of that SolarWinds goodness with their Systems Administrator colleagues. The promise of a unified and integrated, single pane of glass view into the entire organizations infrastructure has obvious advantages. For example, they can eliminate the finger pointing between teams when issues arise in the environment, as well as reducing the time to resolution for problems when they occur.  However, one issue that has historically plagued earlier versions of Application Performance Monitor (APM) is a lack of a dedicated APM/SAM role that would allow Systems Administrators to manage applications independent of the Orion Admin role, which permits adding, removing and modifying Orion user accounts.

 

The IT field has become increasingly security conscious in recent years and there’s an ever increasing desire to limit users permissions down to the minimum required.  The same is true even for those who work in the IT department itself. Long gone are the days of everyone having root/Administrator level privileges to every system, or worse yet a single shared admin account used by all members of IT.

 

With that in mind in SAM 5.0 we have added a dedicated SAM Admin role that functions independently of the Orion Admin Role. This new SAM Admin role, when granted to a user, will allow them to assign application templates to nodes, modify application templates, manage and maintain the SAM Credentials Library, as well as unmanage applications from within the web console. In fact these SAM Admins can perform all the administrative tasks accessible from the “SAM Settings” page.

 

 image

 

You will find this new SAM Admin role under your users permission settings located under [Settings - Manage Accounts]. Select the user account you want to modify and then click the “Edit” button. Towards the bottom of the page you will find the Server & Application Monitor Settings. Here is where you can define user specific settings for SAM features.

 

image

 

In addition to the SAM User Role, we’ve also included an option that allows users the ability to launch the Real-Time Process Explorer, independent of the SAM Admin Role. You’ll also notice we’ve included an account level Temperature Unit setting for toggling between Celsius and Fahrenheit. This allows global organizations to share a common interface in which individual users in different parts of the world can view data in measurable units they’re familiar with. This setting controls the display of all temperature information throughout the product on an individual user basis.

 

image image

 

PowerShell Impersonation and 64Bit Polling

 

One of the great features that was added in APM 4.0.1 was the addition of the PowerShell script monitor that allows users to leverage PowerShell scripts and snap-ins to monitor applications that might not otherwise be monitorable, similar to the Windows, Linux/Unix and Nagios Script Component Monitors.  Occasionally users of the PowerShell Component Monitor encountered  PowerShell/PowerCLI Monitor Problem getting their PowerShell scripts to execute properly under APM. These same scripts would execute fine when run from a PowerShell command prompt, leaving users scratching their head wondering what was wrong with APM. The problem was that these scripts were being executed through the Job Engine, which runs as a service under the local system account. Because these scripts were executed under the context of the local system account, these scripts would sometimes not run due to inadequate access permissions. It was also impossible to utilize PowerShell snap-ins that required remote privileges on another host for scripts that executed locally due to these scripts executing under the local system account.

 

In SAM 5.0 we addressed this issue by allowing for local impersonation of a specified user account. This feature allows users to select which user account the script will be executed under, whether it be the local Windows administrator or an account with domain privileges. Select which account will be used for Impersonation mode from the Credential for Monitoring pull down. Local impersonation alleviates the permissions issues associated with running PowerShell scripts under the context of the local system account and allows users to leverage PowerShell snap-ins no differently than they would when executing them from the PowerShell command prompt. 

 

image

 

Users of the PowerShell Script Monitor faced another PowerShell x64 Launcher (with Parameters and Debugging) when trying to utilize this component monitor type. PowerShell comes in both 64 and 32bit varieties and as such, so do the PowerShell snap-ins that many users, including ourselves, wanted to leverage. In APM all PowerShell scripts were executed in 32bit mode with no real ability to execute 64bit PowerShell scripts locally to use 64bit snap-ins.

 

We remedied this situation in SAM 5.0 by allowing users the ability to specify which platform to run the job under. This option, located under the Advanced section of the application template, controls whether 64bit or 32bit PowerShell will be used when executing the script, allowing users the flexibility to leverage both 32 and 64bit snap-ins with SAM 5.0.

 

image. .

 

The usefulness of this Platform option isn’t limited just to PowerShell scripts though. When this option is selected for an application template that contains WMI monitors, it allows users the ability to poll 64bit WMI counters as well, for situations where the returned statistic is too large for 32bit counters. The most obvious example of where this option is useful is when monitoring processes or services via WMI on 64bit Windows servers where the memory used by any of these processes could exceed 4GB of RAM. In previous versions of APM for instance, when monitoring Microsoft SQL running on a 64Bit operating system the SQL Server (MSSQLSERVER) service itself may be consuming 16GB of memory, but APM would report a maximum of 4GB memory consumed by this process. This was because 4GB is the highest possible value that can be represented in 32bits for these WMI counters. The solution implemented in SAM 5.0 pictured above allows you to poll these WMI counters via 64bit, ensuring the information collected from these monitored 64bit Windows hosts is accurate.