Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Custom Properties - What are you using and why?

amc435

What custom properties are you using, and why?

Find more posts tagged with

Custom Properties

Accepted answers

All comments

ScottRich

We use a lot of custom properties, mostly to mute or redirect alerts and to cause things to appear on different maps.

joepoutre

We use them for device location, device ownership including monitoring escalation information, and build state. And we build groups around them, which in turn can be used for alarms and reports.

fred8o8

We use the custom properties to help assign an asset to a user and/or a department. We also use it to put servers in groups (development vs production) for alarms and alerts as well.

d09h

alert recipient email addresses--initially because there used to be a limit of approx. 220 characters in alert utility GUI (probably in 2012). I had to update too many alerts too often so I just started using a custom property

device type/ team/ regional gateway

silverbacksays

I treat CPs in two ways:

As a funnel... start with the CPs that split your estate into sensible, logical, chunks, then work down to the specifics. Good CP use is key to getting the most out of Orion, as they are used everywhere!
For specific reporting purposes. For example, if you want to be able to report on all the ADSL circuits your company uses, create an 'interface' CP called something like 'ISP_Link', and assign it to your ATM interfaces!

It's all about stripping the onion that is your monitored estate down into the logical layers that represent your business areas, and using CPs to represent them

blsanner

As silverbacksays mentioned, they are used everywhere. There are common ones like site name, site number, contact person, alert email address, alert muting, etc. I've also used ones like volume thresholds, latitude/longitude for automated world map population, patch windows for scheduled unmanagement, etc. Those are just the ones off the top of my head that I've used in the last couple of months. I'm sure there are a ton that I am forgetting about.

It's funny, a recent client I was working with kept asking off the wall questions about ways to do different things. It seems like all of my answers involved creating a new custom property. I asked him at the end of the day if he got how powerful custom properties were and his answer was a resounding yes.

jirwin

We use custom properties in many different ways.. here are some examples:

Dynamic Alerting
- Trigger Variables
  - Our alerts are setup with default thresholds such as "90% space remaining" for a volume.. But we expand on that by creating a property "Alert_Vol" which lets us choose to alert anywhere from 80-100% based on the need. This lets us have a single alert for many different cases/system.
  - Similarly we have other fields like "Alert_Suppress" which if set to true will prevent all alerts from firing for that system. This is great because the node can continue to poll and shows its status in the console but we prevents the false positive emails, tickets and even our home pages and NOC views are setup to ignore nodes set to "true".
- Email Actions
  - We have a Primary (TO), Secondary (CC) and Ticket email address on every node. This lets us direct emails to the appropriate teams and create tickets for the right group. Again all with a single alert.

These changes let us reduce our number of alerts definitions from well over 50 down to 20. And our alert actions are greatly reduced as well.. This really helped in the management and control of our alerts.

Inventory Integration
- We pull about 20 or so fields from our inventory system into Orion via an automated powershell script.
- Some of the ways we use these fields are:
  - Alert Trigger Variables
    - Similar to Orion only properties we pull over things from our inventory that let us dynamically adjust alerts. ex. pulling "Patching Day" lets us suppress alerts during a systems patching cycle to prevent false positives.
  - Alert Email Content
    - With these fields available we are able to produce alert emails that have both our Inventory and Orion content together. This greatly assists our tech's in understanding the impact of the alert and often leads to faster resolutions..
  - Grouping
    - We have multiple dynamic groups setup to key off fields from our inventory - One of the big ways we utilized this was to create a Network map showing our Physical rack statuses based on the Rack ID's in our inventory.
  - Reporting
    - The additional information lets us produce reports that combine inventory information with Orion polled information which is invaluable to our various teams and our management.

Before we used this integration our teams were trying to manually set/update fields in multiple systems.. This streamlined things and reduced the duplication effort. It also gave me as the admin more control since far fewer people needed node management access, etc. We are planning to expand this further to include automated node setup/removal and flowing information back from Orion to our inventory..

If you are not using custom properties I highly suggest you take a look them - There is countless uses for them and they will undoubted make your Orion monitoring better!!

michael.kent

We've used them while migrating peering links from one DC to another. We would mark all the links to be migrated, along with the connection name and AS number. At a pinch we could run a report for all currently connected ports that were marked as to be migrated.

As we proceeded with the migration the number of ports on the report would keep dropping.

Our second useful custom property was for transit links, we could record what the commit level was, again for easier reporting.

Along with this much of the standard location etc, as mentioned above.

jkrenzien

Geographical location

Device owner

Service owner

Device grouping

Alert muting

Finally and probably the most painful NCM scripting. It is only painful because interface custom properties cannot be referenced within NCM which ends up being a huge drawback for me since I I would like to use the interface properties in my remediation scripts.

jkuvlesk

There will be a class on 9/21/16 over custom properties. It will be recorded and posted in the Customer Portal for later viewing. https://thwack.solarwinds.com/events/1878

lynchnigel

We tend to use an extension within the caption of all the switches and routers so for edge switches they have the switch name -'esw' so we can sort by that within the groups

We tend to use a custom field for the node room, building, campus, team-responsible.

Groups are set up for dynamic so when a node is added it goes straight into the groups using the above.

That is the main use but they are used within the alerting and reporting as well.

wluther

Here is a link to the same question from last year, and it has some pretty good examples in it. I reference this link often, and even find some new ideas every once in a while.

https://thwack.solarwinds.com/community/solarwinds-community/announcements/blog/2015/10/01/custom-properties-how-do-you-…

As mentioned numerous times in the previous posts, custom properties are basically the starting point to do the task you are needing.

You can even use custom properties to "Auto Provision" nodes... so to speak... While it can get very complicated, very quickly, it is actually quite easy to do some minor auto provisioning tasks with custom properties.

While they are not technically alerts, I have a few alerts setup to standardize several subsets of devices in our network.

For example, all of our lab devices are located in the same location, room, city, state, zip, etc...

So, whenever someone adds a new device, and sets the custom properties "Department" = "LAB" and "Testing" = "Yes/True", then the advanced alert gets triggered. The actions taken on that device simply set the values for various other custom properties. Now, every time that alert gets triggered, it saves the user from having to manually go through and set 10+ other values.

But yes, I would have to agree with the previous replies, most people end up using them for the same basic tasks, alerting, grouping, reporting, automation...

tallyrich

We are using them to make Solarwinds our "single point of truth" for our documentation. Things like property tag, device location, startup/shutdown order and such.

Jfrazier

The previous posts are very good examples of what you can do. In the end with a little thought and even some creative SQL you can do all manner of things. One of the areas that they become useful for involves complex alert conditions where you can look for various values related to a node in custom properties to determine if it is alertable.

mcam

it really does seem that even though we have a whole bunch of CPs, there will always be a reason to add more

wluther

The only things missing now, in regards to custom properties, are the ability to show/hide them based on device type/vendor/or other cp, the ability to rearrange the ordering (also based on various type/vendor/cp), and having cascading CPs... So, yeah, same here, I think everything pretty much revolves around CPs... at least for now.