Submit a ticketCall us

whitepaperYour VM Perplexities Called, and They Need You to Read This.

Virtualization can give you enormous flexibility with future workloads and can be a key enabler for other areas, like cloud computing and disaster recovery. So, how can you get a handle on the performance challenges in your virtual environment and manage deployments without erasing the potential upside? Learn the four key areas you need to be focusing on to help deliver a healthy and well-performing data center.

Get your free white paper.

Home > Success Center > Network Performance Monitor (NPM) > Network Performance Monitor (NPM) Training > Free SolarWinds Training Videos - NPM > Preparing for an NPM Installation - Video

Preparing for an NPM Installation - Video

Updated September 14, 2018


This video (17:47) will help you to prepare your production Orion installation. It will discuss best practices for setting up your environment for three different sizes of installation from small to enterprise sized, for both the application server and database server. This video will also walk through some prep steps that you can take ahead of time to ensure a smooth installation.





NPM 11.5 and later

Related Resources

Legacy Installation Guide

Video Transcript

Hi, my name is Kenny Newbry, and in this video, I'm going to help you to prepare your production Orion Installation.

We'll discuss best practices for setting up your environment for three different sizes of installation from small to enterprise sized, for both the application server and database server.

We'll also walk through some 'prep steps' that you can take ahead of time to ensure a smooth installation.

As always, make sure you read and fully understand the System Requirements thoroughly before planning your installation - this video is intended as a guide, but does not replace these requirements.

Let's first take a look at what we mean by small, medium and large environments.

As every environment is different, we gauge the environment size by the number of elements you are monitoring. This is the number of objects you plan to monitor.

For NPM, this would be nodes, interfaces and volumes.
A small installation generally tends to be an SL100, SL250 or SL500 license, with less then a thousand monitored elements.
A medium installation is an SL500, or SL2000 license with less than six thousand monitored elements.
A large, or scaled, installation is an SLX license, with one or more additional polling engines, monitoring more than six thousand elements.

Before we go into the system requirements for each different sized installation, let's first discuss the requirements that are common between all of them.


Your Orion server will need a gigabit ethernet NIC. If you're installing Orion on a virtual server, you'll need to dedicate a gigabit ethernet NIC to your Orion server - it should not be shared with other Virtual Machines on that host. There's a simple reason for this, being that, SNMP tends to get lower priority than other network traffic, so you may see performance issues or drops if the Orion server is competing with other servers for the same busy NIC. If you plan on installing Orion on a virtual server, take extra care to read the Virtual server system requirements.


The Orion Application server should also have two 146GB 15k RPM hard drives 

configured as RAID 1, mirroring.

You'll also need Microsoft Windows 2012 or 2008 64 bit, with the Microsoft .NET frameworks 3.5 and 4.0 installed on it. You'll also need to install Microsoft IIS running in 32-bit mode on your server. We'll walk through how to enable IIS on your server during our prep steps later.


Let's first take a look at a small environment. This will be interesting to you if you have and SL100, SL250 or SL500.


By the way - if you plan to install Netflow Traffic Analyzer, even on a smaller license, your environment is not considered 'small' anymore, as Netflow has higher server and database requirements - check the NTA Admin guide for more details.


While it might not always be possible, my recommendation will always be to place your SQL database and Orion installation on separate servers.


While placing Orion and SQL on the same server will work for a time for very small environments, you're forcing Orion and SQL to compete for the same limited hardware resources, and this will lead to performance issues in the long run.

Another point to note - make sure your Orion server and SQL server are placed locally to each other - they should never be communicating over a WAN.

  • For a small installation, aim for a 2.5Ghz quad core CPU, and 4 to 8 GB RAM depending on the size of your environment and how often you need to poll.
  • For a medium environment, you'll still need a 2.5GHz CPU, but you'll want more RAM to handle the extra load - aim for 8 to 16 GB of RAM.
  • For a large environment, you'll need a 3GHZ quad-core CPU, and you'll want a lot of RAM. Between 16 and 32 GB of it, to keep up with the large amount of polling.

Let's take a look now at a scaled environment. This is an environment where you plan to poll over 10,000 elements. It's known as a scaled environment, because in order to poll this many elements, you'll need to have a * Main Poller, and at least one ** Additional Polling Engine.

A polling engine can handle a maximum of around 10,000 elements each, and you'll need to treat each of these Additional polling engines as if they were their own SLX environment - the specs for an Additional polling engine are the same as those for an SLX.

Your main polling engine communicates with, and manages polling across all additional polling engines. It's also responsible for serving the Web Console to all users. If you're planning on an extremely large installation with a lot of additional polling engines - for example, 8 or more - consider using an Additional Web Console *** to break out the Web Console load onto its own server - particularly if you feel you'll have a lot of concurrent web users. The Additional POlling engines themselves do not provide new web consoles - they're designed to provide additional polling power.

The key to ensuring your scaled environment performs well is to ensure that your polling is balanced across all polling engines. 

There's a few other points for a scaled environment that you'll need to be aware of.

  • All of your polling engines need to be at the same site.
  • A standard additional polling engine is not designed to be placed at remote sites - they and the main polling engine must have low latency, stable access to the SQL server at all times.
  • If you need to place a poller at a remote site, you'll need to use the Remote Polling Engine - this is a different version of the Additional Polling Engine, which has been designed to cope with connectivity loss to the database. It has the capability to buffer polling data to a certain extent if minor outages occur.
  • Finally, the main polling engine and additional polling engines are in constant communication. They'll communicate over port 17777 and 17778 - so you'll need to ensure that these ports are not blocked between your servers. They'll also need to communicate with your database server on port 1433.


Let's now take a moment to discuss the best practices for your SQL environment, starting with practices that will benefit all SQL environments, regardless of size.

Orion requirements ask that the SQL server recovery model for the Orion database be set to Simple recovery. This is to control the size of the transaction log file - Orion produces a very high level of I/O to its database, so the transaction log file can quickly grow out of control when set to other recovery models. using Simple recovery mode improves performance, and reduces the transaction log file size.

You should also make sure that the SQL server you plan to use supports mixed mode authentication, or SQL authentication, as Orion will need to use a SQL user in order to read and write to its database.


As for common hardware requirements - there aren't many, and we will discuss the differences in hardware specs for each environment over the next few minutes. The main common hardware requirements will be that your SQL server will need a Dual (yes, dual), 3GHZ quad core CPU. For very large environments, you many need to increase the number of cores if you're seeing a lot of CPU usage.

You'll also certainly want a Gigabit Ethernet port on your server for large environments. You can get away with a lower bandwidth port for small environments, but for bigger medium environments, and large environments, don't let your NIC become the bottleneck.

Your SQL server storage and RAM configurations are crucial for a high-performing SQL server. So crucial, that we're going to break them down and talk about each, for all three environment sizes.


When it comes to deciding on your Storage configuration for your SQL server, there's a few golden rules to follow. Get a server with a Hardware RAID controller with a battery-backed-up write back cache - this provides significantly improved write performance, and the battery backup will help protect data integrity in case of an outage. This remains true no matter what your environment size, and it's worth the investment. 


As for your RAID setup - the golden rule is to use RAID 1 for any Operating system related storage (the OS, or pagefile), and use RAID 10, also known as RAID 1 plus 0, for any SQL related storage (your database files and transaction log files). Don't be tempted by RAID 5 or 6 for anything on your SQL server - it's a cheaper option, but it's not designed to handle high IO and your performance will suffer if you use it.

For both small and medium environments, your storage arrays can be set up in the same way. Use mirrored drives otherwise known as RAID 1 for the Operating System, and a separate array of 6 disks configured in RAID 10, also called RAID 1 plus 0, for your database files - that can store both your database file and transaction log files for SQL for environments of this size.


Again, for both environments, make sure you're using a Hardware RAID controller with a BBU write-back cache.

For large environments, you'll also need to put more planning into your Disk Subsystems. In fact - you'll need four disk subsystem arrays.

Two of these disk subsystem arrays should be configured as RAID 1 ** - Use one for the operating system itself, and one for the pagefile and any extra storage you may need on the server. Use 15K RPM disks for both arrays, and set up the mirroring array with 146GB disks.


The third disk array will be for the SQL data file. This is the MDF file, and its filegroups if any. Use 6 15K RPM disks for this RAID 10 array, and use either 146GB or 300GB disks. If you're planning to store a lot of syslogs and traps, or have multiple polling engines, or plan to poll at shorter polling intervals, you'll need to consider the higher sized disks.

The fourth and last disk array will be for the SQL Transaction log file.

Again, your SQL server recovery mode should be set to SIMPLE only, so this transaction log file should be relatively small in comparison to your SQL database file sizes. However, its an extremely busy file - every write or update transaction taken by SQL is stored in the Transaction log file, to protect data integrity should there be a sudden power failure. As each update is written to disk, the transaction in the transaction log file can be overwritten again when using SIMPLE recovery - keeping the file size small. Because of the way the Transaction log works, SQL will be reading and writing to both the SQL data files, and the transaction log file concurrently - by splitting the transaction log file to its own array, you will see a large increase in IO performance. Give your transaction log file a RAID 10 array across four 15K RPM disks.

The size of your Orion database files will vary, and will heavily depend on how often you want to poll, how long you need to store the information for, and how detailed you need that stored information. It will also depend on how many devices are sending syslogs and traps to the Orion system - and whether they've been configured to send only pertinent information, or whether they're spamming debug messages.


Let's now take a look at RAM requirements for your SQL server.

When it comes to RAM, even in a small environment, you'll want your SQL server to have around 8GB.

If you can afford to add more, do. This is definitely one of those areas where more really is more. The more RAM you can provide your SQL server, the less continuous paging your SQL server will need to do, and the better it will perform. Where possible, SQL will try to serve database read requests from memory. The more of your database that fits in RAM, the faster the performance you'll notice from your Web Console, reports, graphs and so on.

For a medium environment, you'll want between 8 and 16 GB of RAM.

For a large environment, you'll need much more RAM - between 32 and 64GB  expandable - and again, if you can afford to add in more, do, to allow more of your database be served directly from RAM

Finally, and this last point is a critical one for all environment sizes..

Always, always reserve some RAM for your Operating System on your SQL server.

SQL will continue to consume RAM, to the point where it will affect OS responsiveness. By reserving a minimum of 1GB RAM for the Server OS, your Operating system is always guaranteed to be able to access it. If you have other applications on the server, increase the reserved RAM size to ensure there is adequate RAM for all applications and the OS. This is so vitally important to the health of your SQL environment, that we're going to show you exactly where this is configured in the following short Demo.

The way this reservation works is, you need to define the maximum 'allowed' memory that SQL server can use. So, for example, if you have a server with 16GB of RAM, you can define this memory setting to allow SQL to consume up to a maximum of 14.5GB. 

This can be done by your Database Administrator, or can be configured on your SQL server using Microsoft's SQL Management Studio tool. Set the 'Maximum Server Memory' option to limit the amount of RAM that will be available to your SQL server installation.

So, now that we've spoken about best practices and our system requirements, lets take a quick look at some 'prep steps' that you can take to
ensure a clean installation.

First, examine and prepare your Infrastructure. On the server or servers where you plan to install Orion, check if you have any Anti-virus
software installed. If you do, you'll find a full list of exclusions to add to your AV software in the Administrators guide. Getting this done in
advance of your installation will ensure that the AV software won't cause any hiccoughs during your install.

Check the system requirements and confirm what you have available is sufficient. Also - this one is for smaller business with limited available
servers - never install Orion on a Domain Controller, or a RIM BlackBerry server

For your Orion server, there's a little bit of configuration you can do in advance to speed up the installation process. You'll need to use the
Local Administrator account to take these steps - actually, you'll also want to use that Local Admin account for the actual installation itself
aswell. Pro tip - the Local Admin account is not the same as a Domain account with local admin rights. Make sure you're using a local account with
admin rights, as a domain account is subject to your Domain group policies. They might not cause you grief - but then again, they might, so don't
take the chance.


First, install the .NET frameworks - you'll need both .NET 3.5.1 and 4.0.3. These can be downloaded from Microsoft if they're not already a part
of your server image. Check 'Programs and Features' under the Control Panel to see if you've already got them installed.

You'll also need to enable the "Web Server" Role on your server in advance. This will install IIS on your server, and prepare it for handling the
Orion Web Console.

To do this, click on Start -> Administrative Tools -> Server Manager. Click on Roles -> Add Roles. On the 'Before you begin' page, click Next.
Select "Web Server (IIS)" on the Server Roles page. Click Next. On the Confirmation page, confirm your changes, click next, and proceed through
While you're still in the Server Manager tool, open Features, and click Add Features. You'll want to add the Microsoft Messaging feature here -otherwise known as MSMQ.

For your SQL server, if this is run by a separate DBA team, you'll need to contact them in advance, and request the 'sa' username and password. This may scare them so lets briefly discuss what Orion needs this for, so that you can provide them with this information in advance.

This will be required by the initial first run of the Orion configuration wizard to create your new Orion database, and also to create a new SQL user for Orion to use in its database communications.

The Orion user will be created only with access to the Orion database itself, and it will not have sa rights. The sa username and password will not be used again after the database has been created and this user account set up - any other times you run the wizard, you can enter in the new SQL user account and password.

So that wraps up our discussion on the system requirements and best practices for preparing your Orion installation. As a reminder, your main prep steps for a successful installation include configuring the anti-virus exclusions on your Application server, installing using the Local Admin account and getting the software pre-requisites installed before you begin. You'll also need to check in with your DBA team to get the SQL server sa username and password before you start, as it will be needed during your Orion installation for the setup process.  The next video in this series will walk you through how to complete an Orion installation, and will guide you through the options outlined in the Orion Configuration Wizard.









Last modified