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.