Device Templates

General Information

(For a short video about this topic, click here.)

An OmniCenter “device template” is a collection of preconfigured device administration settings that can be used to configure groups of your managed devices automatically and simultaneously. Device templates make managing the configuration of devices on a network much easier (especially for larger networks), and ensure that the correct settings for different devices are applied consistently across the network.

The following (OmniCenter) device administration settings can be automatically configured using device templates:

  • Authentication Details
  • Host Alert Contacts
  • Service Checks
  • Threshold Checks
  • Logging Rules
  • Device Configuration Rules

Any given device template may include or omit (at the administrator’s discretion) any or all of the above device administration settings. Templates that include any of the above settings, and are then applied to a device, will override the respective settings in the device administration pages for that device.

Up to six separate device templates can be applied to each managed device using OmniCenter’s device template system. If multiple templates are applied to a device, the templates are applied in a strict linear order—with settings from templates later in the order overriding any conflicting settings from templates earlier in the order. The order in which device templates are applied to devices is dictated by OmniCenter’s device template hierarchy levels, which cannot be changed (see table below). However, any device template can be assigned to any of the hierarchy levels. Additionally, the individual settings included in a device template are applied to a devices in a cascading manner. This means that if a given template includes a setting—but other templates applied later in the order omit that setting—the setting from the earlier template will cascade across the later templates and still be applied to the target device. In this way, different device templates can each apply specific individual settings to devices simultaneously without interfering with each other. However, if in the same scenario above, some templates include the setting and some templates omit it, the setting from the last template to include it will be the one that gets applied. Settings will only cascade across other device templates until another template also includes that setting. The only device administration setting this doesn’t apply to is host alert contacts. Host alert contacts configured in the device administration pages or included in any device templates will all be added cumulatively to the device. They do not override each other.

If all of the templates applied to a device omit a particular setting, then that setting as configured in the device administration page of the respective device will be used (since there are no templates configured to override it). However, those settings can still be overridden by future device templates that include them. The only way to prevent device templates from overriding device administration settings is to either omit the setting from any device templates that may be applied to that device or to turn off device template usage completely for that device (recommended only in unusual circumstances).

To prevent configuration errors, device templates are designed in such a way that any setting included in a template, that is incompatible (or not applicable) with a device the template is applied to, will simply be ignored by that device. This provides a great deal of flexibility for administrators when designing a device template strategy, as settings for entirely different kinds of devices may be included in the same template.

The OmniCenter device template hierarchy is arranged in the following order, from first applied to last applied. It is important to note that any device template can be assigned to any of the hierarchy levels, except global—which comes with its own unique device template.)


If OmniCenter can automatically determine the type of a device when it’s discovered, the device template assigned to that “device type” (if one is assigned) will apply its settings to that device immediately. If it can’t, you will have to manually set the device type (and any desired subtypes) and repoll the device for the template settings to be applied. Likewise, if OmniCenter can automatically determine the site and/or category of a device, it will automatically apply the settings from those assigned templates immediately. Otherwise, you will have to manually assign a site and/or category and repoll the device for the template settings to be applied.


Even though only one template may be assigned to each kind of device subtype, multiple subtypes can be applied to a device—with each subtype having the potential to apply their own device template.


There is no limit to the number of subtype templates that can be created and applied to a device. When creating new device templates of this type, be aware that when multiple subtypes apply their templates to a device, they are applied in alphabetical order by subtype name. (That’s subtype name, not device template name.)

Example of Device Template Usage

It’s important to understand where in the hierarchy a particular configuration setting from a device template is applied—and whether it will override another template’s setting, or itself be overridden. To see how all of this works, let’s look at the example below.

This image shows the device template hierarchy levels (left) in action. The templates being applied at each level are shown in the middle. The device is at the bottom (blue). The left arrows show successive templates overriding a configuration setting for the same threshold check added by each. The right arrow shows a configuration setting from a threshold check added by one template, but omitted by the others, cascading across the later templates and being applied to the device.

Imagine a wide area network composed of a San Francisco location (with a large number routers) and a remote Beijing location (with a handful of remote routers in different parts of the city and a single higher-performing core router, “Beijing-Core-01,” at the headquarters location). We want to monitor latency for all of the routers on the network. Now, since we’ll be monitoring the network from the San Francisco location, we know that latency for the majority of our routers will be low, as most of them are colocated with our monitoring center. The remaining routers, in our Beijing location, will have significantly higher latency—except for one, the Beijing-Core-01 device, which consistently performs significantly better than the other routers in the region, which justifies it getting its own settings. Manually adding latency threshold checks to all of these devices individually would be quite tedious, not to mention difficult to manage and scale. This is where templates come in. To greatly reduce the work involved, we’re going to specify the differences between these devices, and what we want from them, using just three device templates. All of the routers on this network will then automatically inherit the correct configuration settings from the templates with no further effort from us.

To start, we’ll edit the latency threshold check configuration of the existing “Default” device template (applied to all managed devices) to have a setting of 200ms. This will handle the bulk of our routers. Next, we’ll create a new device template named “Beijing-Devices” and include a latency threshold check configured with a setting of 800ms. We’ll assign this template to the “Beijing” site (to which our Beijing routers should already be assigned). Finally, we’ll create a another new device template named “Remote-Core Routers” and include a latency threshold check configured with a setting of 400ms. This last template we’ll assign directly to the one core router in our Beijing headquarters location. That’s all there is to it. Every router will now automatically inherit the correct settings from the templates.

To be more specific: All managed devices on the network now have a latency threshold check applied globally from the “Default” template. Since the template hierarchy applies site-level device templates after the “Global Default” level, all of the devices assigned to the Beijing site have that setting overridden with the 400ms configuration setting from the “Beijing-Devices” template (which is applied to all of the devices in that site). Now, even though the “Beijing-Core-01” router is also in the Beijing site, we applied the “Remote-Core Routers” template directly to that device. Since device-level templates are always the last to be applied in the hierarchy, the “Remote-Core Routers” template setting is used for the “Beijing-Core-01” device.

Additionally, as an example of how the device template settings cascade, if a device template named “Cisco Routers” is assigned to the “Cisco Router” device type, and had a CPU Utilization threshold check with a setting of 90% included, but the aforementioned “Default”, “Beijing-Devices”, and “Remote-Core Routers” templates did not, that setting would cascade across the later templates, without interference, and be applied to the “Beijing-Core-01” device (because it is, in fact, a Cisco router). Remember, because this template was assigned to a device type, this check would also be added to every other managed device of this type on the network.

Beginning in OmniCenter 10, all managed devices default to having their device administration controlled by these templates.

Device Templates Included in OmniCenter by Default

Two device templates are included in OmniCenter by default to provide basic configuration settings for all of the managed devices in your network. These are the “Default” and “Windows Default” device templates (both explained below). They provide starting points for implementing your overall device template strategy.

The “Default” Template

The “Default” device template is unique and is always created by OmniCenter. There is only ever one Default template and it is always only assigned to the Global Default hierarchy level. Meaning that this device template is always applied globally to all managed devices on the network (unless device template usage is turned off for a given device). This template may be edited to suit your environment. It cannot, however, be renamed or deleted. Be aware that, even if you choose not to modify it, it is always applied. Any device administration settings that you manually apply to a specific device—that conflict with this template—will be overridden (as long as the USE TEMPLATES setting for that device is set to ON). This template is the very first template applied in the template hierarchy. (As a side note: Since the Default template is always assigned, you should not attempt to assign it to any of the other hierarchy levels.)

The “Windows Default” Template

The “Windows Default” device template is the other template created by OmniCenter. Although its name uses the word “default,” this template is simply a normal device template automatically assigned to the “Windows Server WMI” device type (meaning it is automatically applied to all managed devices of that type). It is intended for your convenience, and provides the starting point to a device template strategy for Microsoft Windows-based devices. Unlike the actual Default template, this template can be deleted. However, if this is done accidentally, it can always be downloaded again from the Netreo cloud libraries (OmniCenter version 10 and higher only).

Updated on April 11, 2019

Was this article helpful?

Need Support?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Contact Support

Leave a Reply