Orion APM 3.1 shipped last week and offers a brand new frequently-requested component monitor—the Windows Event Log Monitor. The event log monitor regularly scans the event logs on a Windows server and counts the number of events that match a rule specified by a user. The number of matching event logs is the performance statistic that APM reports. It’s a simple monitor, but it can be very powerful because it’s very flexible and the event logs contain a lot of data.


To create a Windows Event Log Monitor, you create a new template and add Windows Event Log Monitor. It can be found under the All Components folder when you add a new template.


clip_image002 clip_image004




You will need to provide credentials for the target server. But your first real choice is to select an event log to monitor. We provide a dropdown of the most common built-in logs. We also provide Custom which allows you to specify the name any event logs created by specific apps. Orion itself creates a custom log, for instance.




Once you know which log, the next thing is to know what you want to look for in the logs. The monitor will scan the contents of each log it finds looking for a match. You define what constitutes a match. You can specify one or more of the following:


· Log Sources – Source tells you which app generated the event. For instance, WMI, Outlook, and Winlogon are some of the sources I see in the event log for my laptop. If you specify these sources in the match definition, then APM will only count logs from those sources




· Event ID – Each event has an ID. You can use a search engine to find the meaning of various IDs or which IDs indicate particular events. For instance, 644 is the ID of the event log that’s generated when an account is locked out. If you listed 644 in the match definition for an event log monitor, APM would count the number of times it saw 644. You can list one or more IDs to the match definition. If you leave it blank, then all event IDs will be considered as a match




· Event Type – Each event has a type such as Error or Information. You might create a simple event log monitor that counts the number of logs of type Error and then create an alert if that monitor goes above 1.




· User – Event logs include a user field, although it isn’t always filled in. But if you’re interested in tracking a particular user account’s activities on a particular server, this field would be useful.




· Key Words – Every event log has a description field that elaborates on what happened that caused the log to be generated in the first place. The Include Events and Exclude Events fields allow you to scan for key words. Here you can specify strings (including regular expressions) that must be included or excluded to create a match. So you might want to count events that include the (unlikely) text Radiohead but exclude them if they also include Creep.




You can include one or more or all of the parameters above. A match will be found only when all of these parameters match. Thus, if you look for events from source X, with ID Y, and text Z, then APM will return the number of event logs where X, Y, and Z are all true.


One other aspect of the monitor to appreciate is the “polling period”, which may be confusing. When you apply the monitor to a server, you will set the polling period. Let’s say you set it as 5 min. APM will look at the event logs every 5 minutes. Let’s say are looking for Event ID = 644. On the first poll, you find two event logs with the ID 644. APM will count that as 2. In 5 minutes, it will poll again. Do you want it to scan those same events? Or do you want it to only scan event in the last 5 minutes? If you set the polling interval at 1, it will look only at those events from the last 5 minutes—i.e., new events. If you set it at 1.5, it will look at the last 7.5 minutes, so it will rescan part of the previous scan. If you’re looking for more of a “rolling” event count, you might want to increase this number and rescan some of the previous intervals.




In practice, we expect each user to create several windows event log monitors. Each monitor would be scanning for a different set of conditions. One monitor might be counting the number of Errors (like Errors in Application Event Log that we ship with 3.1) while another is counting the number of login failures on a sensitive server.


The Windows Event Log monitor is a flexible monitor for Windows systems, and we’d love to hear how you’re using it. If you create monitors that you find useful and interesting, please publish your templates to the thwack community.



Our doc team has dedicated an entire chapter in the Orion NCM Admin Guide called "Modifying Device Command Templates", so I won't spend the time to rewrite this into a blog post ;-)  However, given the number of thwack posts around modifying device templates, I thought it would be useful to go through some fundamentals to ensure you've got a solid footing before you try to extend NCM device support yourself.

1. What are device templates?

All NCM device support is based on device command templates or device templates for short.   Device templates define the series of native device commands NCM will use to execute config management actions for a particular device type (e.g., download configs, upload configs, reboot device).  For example, the native device command to show the running config on a Cisco IOS device is "show running".   So, in the device template, we map that value to the DownloadConfig command.   In some cases a single device template can be defined for an entire class of devices (e.g. Cisco IOS based), while in other cases a template specific to one type of device must be created (e.g. Cisco PIX Firewall).

NCM provides out of the box support for over 15 different vendors and 100s of different device models. For devices not supported out of the box, NCM includes the ability to extend the default device support by creating or modifying device templates. 

2. Where are device templates stored?

All device templates are located in the \Solarwinds\Configuration Management\DeviceTypes folder on the NCM server.

3. How does NCM determine which device template to use for a specific device?

NCM uses the system OID of the device retrieved during discovery to automatically identify which device template maps to which device(s).  NCM matches using a best case algorithm by choosing the template that matches the most digits of the device's system OID.   This allows you to have a generic Cisco IOS device template that is used if no more specific device template exists.   For example, if you have a Cisco ASA device with system OID, NCM would normally use the default Cisco IOS device template based on a match of the   However, because there is a specific Cisco ASA device template that matches exactly, NCM would use that one instead.

NOTE: You can override automatic mapping by editing the device in the NCM client application and changing Device Command Template from "Auto Determine" to a specific template.

4. What does a device template look like?

Here's the device template used for standard Cisco IOS devices:

<!--SolarWinds Network Management Tools-->
<!--Copyright 2005 SolarWinds.Net All rights reserved-->
<Configuration-Management Device="Cisco Devices" SystemOID="">
        <Command Name="RESET" Value="terminal width 0${CRLF}terminal length 0"/>
        <Command Name="Reboot" Value="reload${CRLF}y${CRLF}y"/>
        <Command Name="EnterConfigMode" Value="config terminal"/>
        <Command Name="ExitConfigMode" Value="end"/>
        <Command Name="Startup" Value="startup"/>
        <Command Name="Running" Value="running"/>
        <Command Name="DownloadConfig" Value="Show ${ConfigType}"/>
        <Command Name="UploadConfig" Value="${EnterConfigMode}${CRLF}${ConfigText}${CRLF}${ExitConfigMode}"/>
        <Command Name="DownloadConfigIndirect" Value="copy ${ConfigType} ${TransferProtocol}://${StorageAddress}/${StorageFilename}${CRLF}${CRLF}${CRLF}"/>
        <Command Name="UploadConfigIndirect" Value="copy ${TransferProtocol}://${StorageAddress}/${StorageFilename}  ${ConfigType}${CRLF}${CRLF}"/>
        <Command Name="EraseConfig" Value="write erase${CRLF}Y"/>
        <Command Name="SaveConfig" Value="write memory"/>
        <Command Name="Version" Value="show version"/>

Just as an example, if you had a device that required a different command to show the running configuration (e.g. more system:running-config), you could easily copy this device command template, change the name and system OID as appropriate, and change the value of the DownloadConfig command to be "more system:running-config".  Voila, new device command template!

5. After modifying a template, how do I troubleshoot it?

When troubleshooting existing or custom device templates, you should always enable NCM session tracing.   To enable session tracing in NCM, go to File > Settings > Session Tracing.   Attempt to verify login and download a config from the problematic device.   Then, you can find the session trace for your device in \SolarWinds\Configuration Management\Session-Trace.  

The session trace will show you the command interaction between NCM and the device and where there are issues (e.g., non-standard login prompts, non-standard enable prompts, requirement for precommand to go into CLI mode, etc.) that you can then easily correct with simple modifications to the device template.    See Orion NCM Admin Guide (Command Template Commands) for list of commands that can be used to modify interaction between NCM and your device.

To save yourself some time, don't forget to check out the Content Exchange to see if there's a community-created device template already available for your device.

Orion IPAM 1.6 GA'd this week, which includes some highly requested features that should make your lives easier in terms of managing IPs and subnets.  First, let's look at the multi-edit functionality.

Notice the highlighted check boxes in the above screenshot.  Using these you can now multi-edit a group of IPs simultaneously.  This is nice if you have a group of IPs you want to edit on a single page in IPAM.  What if you want to multi-edit a group of IPs that span multiple pages in IPAM?  We've got that covered too!

As you can see in the above screenshot, we've also added the ability to specify a range of IPs you want to multi-edit. 

Bulk subnet importing was another highly requested feature we were able to implement in IPAM 1.6. 

In this screenshot you'll see that we simply ask you for the subnet and the CIDR, then we parse it for you and show you the results.  Even better, you can import multiple subnets at the same time.

The last feature I'd like to show is the subnet import lockdown.  This will help when managing duplicate subnets.

You'll see highlighted in the above screenshot a checkbox.  When this box is checked, it will only update the subnet you're currently editing.  In other words, if you are managing duplicate subnets, and you only want to make changes to one, you'd check this box and any changes made will be restricted to that subnet.

If you're an existing IPAM customer, 1.6 is waiting for you in your SolarWinds Customer Portal.  If you're interested in IPAM, but haven't purchased it yet, try it for free for 30 days; you can download it here.


Wishing everyone a happy Holiday!


APM includes several ways to monitor files.  For many users, there are business critical files that must be present and unchanged.  If the file is changed or deleted, a critical incident has occurred. 


How do you know if a file is still there?  The File Existence Monitor is a straightforward monitor that will periodically check for the presence of a specific file.  If the file is present, the monitor is up.  If the file is absent, the monitor is down.   You can also use the File Existence Monitor to ensure that a file is not present.  You might use this on a system where an application error will generate a log file.  You can set the File Existence Monitor to show up if there is no log file, but down if the log file has been generated.  This monitor doesn’t report any statistic, just up, down, and response time. 




There are actually two ways to monitor for file changes:  The File Change Monitor and the File Age Monitor 


The more obvious is the File Change Monitor.  With this monitor, you identify a file by specifying the path.  Next, browse to the target file and take a snapshot of the file by clicking “update checksum”.  The checksum is stored in the Orion database and provides a baseline, and each time APM runs the File Change Monitor, it will take a snapshot of the current state of the file and compare it with the checksum in the database.  If the checksum matches, the monitor is up.  If the checksum doesn’t match the monitor is down.  The checksum will fail to match if any change at all has been made.  If the file content or security is modified, the monitor will go down.  As a statistic, the file change monitor will report the number of hours since the file was changed.  So if the file has not been changed, the hours will continue to grow.  What happens if the file has been changed intentionally?  In that case, you’ll need to update the checksum and restart the clock.




In contrast, the File Age Monitor is much simpler.  Like the File Change Monitor, you specify a file.  But there is no checksum.  This monitor checks the Last Modified date of the file and compares the current date and calculates the age of the file in hours.  The file age is reported as a statistic. 




Why do you need both File Change and File Age?  The File Change Monitor would be most useful if you have a file that needs to be in a particular state.  Any change from that state is a problem.  File Age is a simple check on whether the file has been changed.  You could alert on a change, but you might also alert on a lack of change.  Imagine that you have a file that should be updated every 5 minutes.  You could trigger an alert if the age of the file is greater than 5 minutes.


APM also includes monitors that will check the size of a file, the number of files in a directory, and the size of a directory.  How do you monitor files?  Are there any common file monitoring scenarios that we’re missing?


Unpluggable Port Mode

Posted by bshopp Employee Dec 16, 2009

One cool new feature we added in 9.5 that you may not know about yet was directly influenced by you, the community. Customers requested that they wanted to monitor specific ports, such as user ports, but when those users shut down at the end of the day and went home, they did not want to receive alerts that the node is now offline and down.


With NPM 9.5 you can now set a property on an interface in which if that port goes down, within Orion we will show it as unplugged and you will not receive alerts or a down icon in the UI.


1. In the Orion web console go to Admin -> Manage Nodes and select one of more interfaces and select “Edit Properties”




2. Check the first dialog “Display interface as unplugged rather than down” and submit


3. When an interface is down, it will now show as Unplugged within the UI and not trigger alerts and alarms




So when everyone goes home in the evening, do those VoIP phones need to be powered on?  Is anyone really using Wireless?  That is money just being tossed out the window and who isn’t fighting with budgets for more money these days.  So Cisco released earlier this year a new technology initiative focused around this problem of reducing power consumption and lowering your carbon footprint, you can read more about it here - http://www.cisco.com/en/US/products/ps10195/index.html


We worked with Cisco with the launch of this new initiative and in our Orion NPM 9.5 and NCM 5.5 releases, introduced some functionality specifically around this.  I will focus here on NPM and not steal Chris, the NCM Product Managers, thunder of what he did in NCM for EnergyWise.  For NPM, we have introduced an EnergyWise-specific view into the product, which his not enabled by default.  To add this, go to the Admin page in the web console and select Customize Menu Bars, select the appropriate menu bar you want to edit and click edit.   You will need to drag over the EnergyWise view to your Select Items as seen in the second screenshot below and click submit.






OK, so I have added it now what do I do with it?  So we have a report which we ship with called an EnergyWise readiness report which looks at your nodes in NPM and tells you which hardware supports EnergyWise and if the OS version supports it or not.  This is a good starting point to help you plan for moving to EnergyWise.


So you have devices that support EnergyWise and you have upgraded them to the appropriate OS, now what?  So now we will begin polling EnergyWise statistics and showing them to you at a global, node and interface level view of Energy use.






If you drill down to the node details view, you can view power usage at the node level and look at each port and what its current power level is and the node level EnergyWise settings.  See above.


If you drill down to a specific port, you can see a weekly EnergyWise Recurrence Policy calendar amongst other things which shows you when the device connected to that port will change power levels based on the defined policies.



'Tis the season, but not the one you're thinking of.  Yes, it's definitely the holiday season, but we at SolarWinds have also found ourselves in what could be called a 'Release Candidate' season.  We've already received a great deal of participation and feedback for the APM release candidate (or RC as we like to call it around here), a handful of customers have been using the IPAM RC for about a week now, and we just finished the RC for IP SLA Manager.  Now for the big question: why should you care?

First, I'd like to address what an RC is, as this term is most likely a new one to many of you.  An RC is a fully tested, production-ready, fully supported build of the product.  It is NOT a beta.  Let me say that again.  An RC is NOT a beta.  There are several key differences between an RC and a beta build.  First, beta builds are not supported; RCs are.  This means if you install the RC in your production environment and you are on maintenance, you have full access to the SolarWinds support staff for any issues you may encounter during the upgrade process.  This leads to another important difference: we want you to install the RC in your production environment, and this is NEVER something we'd recommend with a beta build.  Third, the level of testing is significantly different between a beta and an RC.  RCs have undergone full functional and regression testing, as well as performance and load testing.  Functional testing ensures we've fixed all of the major bugs found related to new features, and regression testing ensures we haven't broken any existing functionality.

Next, it's important to understand why we are promoting RCs and encouraging you to participate.  First and foremost, your feedback is extremely important to us, and the earlier we can get it, the better.  RCs are, for the most part, the very first time we're putting a finished version of the product in customers' hands.  If you think we got something wrong, we want to hear about it as soon as possible.  In addition, we know from our years of experience in software development that it's impossible to anticipate every possible issue you might encounter during a production upgrade.  This becomes even more challenging when you start to consider that each of your environments are unique.  If you encounter an issue during the upgrade process, we want to know about that immediately too.

Because we understand that it's impossible to anticipate every possible issue you may encounter during an upgrade, we are providing an added level of support for customers willing to upgrade to the RC in their production environments.  This leads us to the benefits you get as a customer by taking the RC and upgrading in your production environment.  Customers installing the RC in production will have closer access to Product Management and Development for any issues they may encounter.  We have set up new Release Candidate forums for customers to post any issues they encounter, and these forums are actively monitored by Product Management and Development.  Not only are we going to engage with you on thwack, we may ask you to do a GoTo meeting with us to better understand what's going on in your specific environment.  This is all in addition to the normal SolarWinds support channel available to you (remember, an RC is a fully supported build).  Another benefit to taking the RC is that you get a first look at the new features in the release, quite possibly features that you've been asking us to implement.  Lastly, we'll throw in a t-shirt.  We will send a t-shirt to any customer on maintenance who takes the RC, upgrades their production environment, and describes their upgrade experiences on thwack.  For what it's worth, the t-shirts are pretty cool too!

We understand that a number of customers encountered issues during their upgrade to Orion 9.5, and we find this unacceptable.  This is not something we ever want to repeat.  We are committed to quality releases for all SolarWinds products, and promoting RCs is a direct reflection of that commitment.

If you're an Orion IP SLA Manager customer on maintenance, you should have an email in your inbox with instructions on how to sign up for the 3.1 RC.  Sign up, install the RC in production, describe your upgrade experience on thwack, and we'll send you a cool t-shirt.  If you're not an Orion IP SLA Manager customer, look for the NTA RC in the coming weeks.  As I said, 'tis the season!

I continue to see a lot of posts requesting database integration between Orion NPM and Orion NCM where the primary use-case is the ability to add nodes and custom properties once in NPM and have them automatically synched to NCM.   We’re actively exploring centralized node/attribute management, but in the meantime, you can leverage the “Import from Orion database” job in NCM to keep your nodes and your properties in sync.


Here’s how to do it:


1. In NCM desktop application, click Schedule > Create New Job and select Import Devices from Orion Database




2. Follow the steps in the wizard to setup your sync schedule and then click on Import tab to connect to your Orion NPM database


3. Now you can map each NPM database column to an NCM field name.   This is done by clicking on the column header and selecting an NCM field from the list.   You can select <ignore> to bypass the column.   For example, if you had a custom property in Orion NPM called Asset Tag, you would create a custom property in NCM called Asset Tag and map them using this interface.


NOTE:  If you need more granular control over which nodes get added, there is a special EnableOrionImport field in NCM.   If it is mapped to a custom true/false property in Orion NPM, you can control which nodes get imported from NPM using that node property.




4. Finally, you can setup node addition, merging options, and filters.   I’d recommend you leave the default node import settings, which will add all new nodes and merge data about existing nodes.




That’s it.   It’s a good idea to do a test run to ensure it has the expected results.   You can do this by right-clicking on your newly created job and selecting Test Job.
















We’d love to hear how this job is working for you (good, bad, and ugly), so please don’t be shy about posting any feedback you have to the Orion NCM forum!






So I was on the phone with a customer of ours recently who has a mandate that all their devices must be managed via SNMPv3 by a specific date.  For most devices, this is not a problem.  However, for Windows, they currently do not support SNMPv3 for monitoring natively out of the box.  So what to do?


Well there is an open source application called net-snmp which you can install on your Windows boxes to allow you to monitor them via SNMPv3.


1. Download and install the latest version of net-snmp from here to your Windows boxes, currently happens to be v5.5


2. During the install, select “With Windows Extension dll Support”   

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.