Showing results for 
Search instead for 
Did you mean: 
Create Post


Level 14

This is one of the common questions IT pros face in their job every day. Whether yours is a large organization with different teams for network and application management, or a small IT department with one IT guy trying to figure out where the problem is, the challenge of identifying the root cause is the same. Though the network and servers are part of the same IT infrastructure, they are two very different entities when it comes to monitoring and management.

Take the example of end-users complaining of slow Web connectivity and performance. Where do you think the problem is?

  • Is there a problem on the in-house network?
  • Is it a fault on the ISP’s side?
  • What about the IIS server?
  • Is it the virtual environment hosting IIS?

There could be many more possibilities to investigate. Making a list of questions and manually checking each part of the infrastructure is definitely what you don’t want to do. Visibility into the network and the application side of the house is key. Integrated visibility of network and application performance is the best thing an IT admin could ask for in this scenario.

As you probably know, Network Performance Monitor (NPM) v12 is out with NetPath™ technology. The power of NPM can be enhanced when integrated with Server & Application Monitor (SAM). In the image below, I’m making a modest attempt to explain the value of end-to-end visibility that you get across the service delivery path, from inside your network to outside your network, from on-premises LAN across the WAN and cloud networks.


Users in both the main and branch offices are reporting slow performance of intranet sites. What is causing the problem and why? Is it the network, or the systems infrastructure that needs troubleshooting, or both?



  • Using hop-by-hop critical path analysis available with NetPath in NPM to isolate problem in the ISP network.
  • Using application and server monitoring in SAM to pinpoint performance issue in the Web server environment.
  • The Quality of Experience (QoE) dashboard available in and common to both NPM and SAM analyzes network packets to provide insight into network and application response times for specific application traffic. This helps confirm the symptoms of the problem at both sides—network and the application.


  • One unified Web interface and NOC for monitoring and troubleshooting networks and applications infrastructure.
  • Eliminate finger-pointing between network and system teams. Find out exactly where the root cause is for faster troubleshooting.
  • NPM and SAM are built on the Orion® Platform, sharing common services such as centralized alerting, reporting, and management.
  • Easy to install, set up, and use. Automatically discover your environment and start monitoring.

If you already are a user of NPM and SAM, please comment below on how you benefitted from using them together?


We have been using NPM for years.  We are currently installing / configuring SAM.  However, we went back and forth several times on the best implementation path.  Our Networking team that controls NPM has some reservations about adding another product into their database.  In discussing with Solarwinds sales tech support, they lead us to the conclusion that we can still achieve the same results by splitting it out, of course having to look at two different consoles.  Once everything is stood up, I hope our implementation is as successful as this use case.  Time will tell.

Sounds an awful lot like a case of "get off my lawn!" to me, mprobus​! The way the Orion database is designed provides that that unless you have serious constraints on database space or storage performance (or you have a GIANT estate), NPM & SAM work just fine together. Splitting them means double the admin, double the downtime when upgrades are due and double the backups!

All your Networking team would need to do is add a node custom property for '_team' and give it lookup values of 'networking' or 'applications' (or something similar), assign this and the appropriate value to each node and  then define this CP in a new limitation, and BOOM! You have one instance that serves both teams, with both teams oblivious of the other's content (assuming network guys get the 'networking' restriction and vice versa).

Just my two UK pence worth


I went without SAM or APM for a long time... I was missing out on a lot.  Now with appstack it's even more important!  With NPM & SAM you can cover 85% of the app stack.  If it's a web app WPM fills in the detail and SRM will help to see if it's all the storage causing your problems.

In the old days, it WAS the network.  Now that I've fixed that (replaced faulty Nortel hardware and OS with Cisco and new IOS to the tune of about $8M), 9 times out of 10 it's the App or one of the resources it relies on (spinning disk/SAN/databases, etc.).

But silos prevent SAM from being adopted.  Silly!

Level 11

Working with an ISP that's trying to expand into IPTV, I can honestly say that the biggest clue is Occam' razor. How complex (and tested) is the application that's having trouble vs the complexity (and historical stability) of the network supporting the application? Oh, after merging in last week's code it's really slow? No, it's not the network. Alternately; oh, the new code is working to every site but this one? Yeah, that's probably the network.

That said, NPM is an amazing troubleshooting tool, and makes it so much easier now to either point to a node and say "yeah, there is something wrong with that device" or, "no, the network is fine, revert your latest code push." So much less headache and so much time saved all the way around. Honestly, the first time this tool circumvented the need to have an hour plus meeting with the admins and devs it paid for itself.


Some days the answer is YES, because it is the network AND the application.

We've been using NPM and SAM for several years now.  The finger pointing still happens at time because the info is not available to either SAM nor NPM.

Hopefully with NetPath, some of that will be resolved.

Level 12

It's always the network... until it's not!

Level 14

We been using NPM for quite a while.  We have approval SAM, finally.  Can't wait.

Level 16


you just can't get that from NPM or any other central NMS...

try look at them

BRIDGE Technologies / products

I am currently wrestling with a EUE project for monitoring the multiple steps in our DSS reports that includes Citrix, Spreadsheet Server and MDX. I have learned that NPM/SAM is not there yet with monitoring the Citrix experience. We are implementing A LOT of PS tog et us over the hump. In our situation we know absolutely sure that it is the app.

Level 11

We use NPM with is extremely useful for troubleshooting, but we are not using it with SAM yet.


Yeah same here. We have a network team and that's only responsible for the network. So we don't have SAM. It's always painful having to prove that the network is AOK.

Level 12

Use NPM and SAM.   Both are useful on a day to day basis.  Really looking forward to NPM 12 with NetPath, to add one more layer of visibility, particularly for removing the network from the list of potential culprits.

Level 10

Same here!

NPM has made proving that the problem is NOT the network much easier.  Unfortunately, we have many long-timers who recall our old Nortel network, which WAS the problem many times.  So they have a poor trust factor, and a long memory.

Level 21

We have been using both NPM and SAM for years and absolutely love the product.  The single pane of glass has helped us identity problems on countless occasions, I can't imagine what our lives would be like now without this combination. 

On one recent occasion we had a client indicate they had a problem on a few of their VM's.  Within only a few minutes looking in Orion we were able to tell which VM's were having the issue, and see that all of those VM's were on the same host.  It turns out all of the VM's on that host were having a problem so immediately we knew that the host was the issue.  We were able to quickly rule out a network issue because the upstream network device showed no signs of trouble and the other hosts in the cluster were also attached to that network device and they were not experiencing trouble.  Ultimately we restarted a few processes on the host and the issue was resolved.

About the Author
After CIS/MIS contracted for DISA in mid 90’s Worked with Toyota for 3 years Worked for GE for 4 years (Here was where I first found SW products) Did a bunch of various network engineering projects Contracted for GE for 4 more years Currently working with General Dynamics Mission Systems   William Eckler IT Business Operations Services .ılılı..ılılı. GENERAL DYNAMICS Mission Systems