What are your favorite Custom Properties?

Yes, I've worked with many orgs that do this in many different ways. I like to try and standardise so that when it comes to the time that they want to integrate with a CMDB we can easily point the custom properties to the CI's in the CMDB.

Some just use simple descriptions, some use codes, some use secure names provided by their security team, some even go so far in a very organised fashion to extend their naming convention to groups, maps, NOC views and custom property description fields.

Sometimes i've resorted to a visual method instead of using custom properties, especially when i'm doing architecture work for other teams. I create a visio diagram of the infrastructure and then recreate it in Orion Maps. I then include all sorts of information on the map like location, description, useful info, photos, a whole plethora of useful stuff. Eventually SolarWinds becomes not just an observability platform but the central source of information / wiki too.

Would love to hear more about your customizationsacmtix 

I think its critical to manage the expectations of the team owners of the views as they usually tell you what they want and you have to steer their focus so that you give them the most useful views possible. Custom properties are great but occasionally i've seen environments with hundreds of properties and that just gets silly. If you create and keep updating an Orion Map it can be a really useful induction tool for new starters and it can provide engineers and architects with invaluable visual representation of the application they want to focus on.

Going back to the original question now that i've had time to think... I reckon the most important custom property is SVC_NAME as this a custom property that I use to define all nodes that make up part of a service and this is really useful to then tailor alerts per team based upon this service name. When combined with a service wrapper document (architecture diagram) and a team who want to make the monitoring solution a reality you can end up with a nicely polished solution that is truly useful. 

I've been using Applications, and ApplicationsRole, and AssignmentGroup in my custom property scripts for a long time and it falls into the same train of thought you are talking about. 

Servers don't just exist for no reason, they are all supposed to be running some kind of application and there ideally would be someone in the company who is responsible for making sure that whatever that server is supposed to be doing is happening.

If I'm tracking what you mean by the 'purpose of the equipment' I will often see something along the lines of a device type, although sometimes that gets a little tricky when vendors release new hardware that crosses multiple niches, but we eventually figure out how we want to categorize those devices.  

When it comes to properties the way I generally train people is that if they can ever think of a way they would need to break things up then there needs to be a custom property for it.  So if you need to know physical locations then a property for the Site, or if the device needs its tickets to go toward a different specialist team, or whatever logical groupings you ever come up with a need for.  It's kind of a never ending process because people will always be coming asking for a dashboard or report to show just their particular area of interest.

I have custom properties for

email_on_critical, email_on_warning.  These send an email if the node or SAM monitor is in those states. It's a comma separated list of email addresses, so you can set it to anyone... muhahahaha.

OnCall_Group and OnCall_Hours.  The group is forwarded to our ticketing software so they know what group to assign it to.  The hours is used to limit when SolarWinds will create the tickets.  These are the only custom properties that are "required".  They also exist on SAM monitors, but not required as they will default to match the node, if they are null.  I wish the hours were more flexible so I could set it to actual times like "8:00am-5:00pm M-F" but that was too hard, so I just have 3 values "24 hours", "business hours", and "do not call".  This was setup many many moons ago... today I would probably handle this part inside the ticketing software... maybe.

I use some of the built in ones like city, state, zip.  They are auto-populated from other sources of information.

Priority (no longer used) was used to show what order it would come up in a disaster recovery situation.

Static_Poller: This one is mostly for my internal use, I know some systems use IP restrictions to a single specific IP of the polling engine.  Though this is becoming less used.  Everything without this set I can move willy-nilly to balance things out.

Documentation.  a link to the documentation for that node.  We never started using this one, but the custom property is still out there, and there is even still a widget that shows this link on the node summery.  It's been there for over a decade... still unused, maybe I should delete it.

Sometimes you can think of blank custom properties as a to do list.  Not sure your role in that organization, but if there is a gap in documentation its potentially a good project to plug those holes, but we all know documentation is like that last thing most companies actually allocate time to actually get done.

Here are a few we use in our org for Nodes:

• Cust_VIP - Denotes if the "customer" or users are considered VIPs. This establishes priority for alerting, outage response, etc. If Cust_VIP = True then Device_Priority = 1.
• Device_Category - Usually denotes the overall category of a device such as Network or Server
• Device_Function - The specific function of the device. For example, "Exchange"
• Device_Model - Hardware model of the device
• Device_OSType - OS type (Windows, Linux, Cisco IOS, etc.)
• Device_Priority - This is a scale of 1-4. Priority 4 does not receive alerts. Priority 1-3 receive alerts, but have varying degrees of response (immediate, next day, next business day)
• Device_Vendor - Vendor of the equipment
• Loc_Site - Site name where the equipment resides
• Loc_Bldg - Bldg number or name
• Loc_Floor - Floor of the building in which the device lives
• Loc_Room - Room of the building in which the device lives
• Resp_Org - Organization/work center that is responsible for troubleshooting the device
• Resp_Phone - Phone number/contact info for the responsible organization

I'd love to build out CPs for e-mailing in the To: and CC: lines of e-mails, but this would be a huge architectural shift in how we currently handle alerting so I haven't been able to implement these just yet, but it would help us cut down on our hundreds of configured alerts and streamline these tremendously.

We also have an organizationally-defined node naming convention, which helps a lot. It makes it easy to identify where things are, what purpose they serve on the network, and if redundancy exists. 

Ours are very similar. 

The two fields that have always had a lot of importance are the Severity of the alerts as well as the Group field which is the Assignment Group within our ticketing system for that device. Have used three different ticketing systems and these are always parameters needed to passed on to the ticketing system.

Additionally we do send emails from the alerts as well so each device also has a team distribution list for the team that owns that type of device. 

I use one Company name _Location.  We use this custom property with account limitations to limit access to nodes at certain locations so they only see their locations nodes to reduce scope in the dashboards with in SW.