N‑central Custom Properties, If You’re Not Using Them, You Should Be

Over the years, I’ve spoken with many of our partners that use N‑central, and it always amazes me how few leverage custom properties. Often when I explain one or two uses for them, their minds are immediately racing with other potential uses as well, so today we are going to look at some of the many uses for custom properties and how they can benefit the support and service you provide to your clients.

Before we start though, maybe I should explain what a custom property is and where it can be applied in N‑central. Custom properties enable you to categorize devices and customers with unique tags. You can then create filters based on the values of the custom properties so you can apply rules for automated workflows. It’s important to note that custom properties can be applied to devices by operating system or device class and to your customers and sites in N‑central.

Custom properties at the device level

Grouping for Patch Management—This is one of the more common uses.  If you have clients where you don’t want to patch all the devices in a class at the same time, how do you sperate them out?  The simple answer here is to use a custom property. In this scenario I like to add the custom property by device using the Dropdown Type. Once you have defined the different schedules in your custom property, create filters to target the different values and create patch rules to target the different filters.

Deploying different profiles for integrated features in N‑central—Whether you’re deploying EDR, AV, backup, or DNS Filtering in N‑central they all require a profile which determines what configuration will be used. Creating profiles at the SO level that can be used across multiple customers is far more efficient and easier to manage than creating multiple similar profiles on a per customer basis, e.g. when it comes to deploying EDR, the recommended approach is to deploy it to a device first in Detect Mode for a period of at least 72 hours before switching it to Protect Mode where auto remediation is enabled. This is another scenario where you can add the custom property by Device using the Dropdown Type, you can define values like “Detect Mode”, “Protect Mode”, “Not Installed”, etc. and again create filters to target the different values and create rules to target the different filters.

Did you know that automation polices can also set the value on custom properties, so if you need to gather additional information on a device that is not picked automatically by N‑central, you could run an automation policy to gather this information and write it to a custom property, e.g. the current public IP address of the device or the Bitlocker encryption key.

Related Product

N‑central

Manage large networks or scale IT operations with RMM made for growing service providers.

Más información

Custom properties at the customer level

So far, we’ve looked at how custom properties can be utilized on a device level, so now let’s look at some uses for custom properties at a customer level.

Checking service and support levels—If you offer different tiers of service and support to your clients, you can use custom properties to easily determine what levels are provided to them, build out your service offerings (e.g. gold, silver, bronze, etc.) using service templates, scheduled task profiles and rules to determine what monitoring, automation, self-healing and features are deployed for each tier, then tag your clients into the relevant categories by creating a custom property by customers using the Dropdown Type.

Using custom properties as input values when running automation policies—I mentioned earlier that you can use automation policies to set the value of a custom property, but did you know you can also use custom properties as input values when running automation policies? This can be particularly useful when deploying software that requires a client specific license key or token across multiple clients. In this scenario, you should create a custom property by customers using the Password Type and define the client specific licence key or token for each client that requires the software.

These are just a few examples of how you can leverage custom properties to enhance how you use N‑central to manage and maintain your customers. If you haven’t been using custom properties up to this point, hopefully this blog will inspire you to do so.

If you have questions join me on the N-Central office hours at www.n-able.com/events

Paul Kelly is the Head Nerd at N‑able. You can follow him on Twitter at @HeadNerdPaul, LinkedIn or email at [email protected].