Configuration Rules and Labels

OVERVIEW

Configuration Rules and Labels are the dynamic configuration feature in UniconOS Management (Scout Board). They add to the standard model, in which device configuration and application definitions flow down from the Base through each OU to the device. Default settings live in the OU configuration and are inherited by every OU below it. Rules and labels are used only to override those defaults for specific groups of devices, changing just the settings that need to differ.

Note: The goal is to not break OU inheritance. Every OU should keep “Use parent device configuration” turned on, so a change made once at the top reaches every device. Any difference a group of devices needs is made with a rule and label instead of an independent OU configuration.

This guide explains what rules and labels do, shows an example to override inherited defaults, lists the different ways to target a rule (OS name, OU name, IP subnet, firmware and more), and covers the practices we recommend for designing, implementing, and maintaining them.

RULES AND LABELS AT A GLANCE

CONFIGURATION PRIORITY

UniconOS Management merges configuration from several sources. When two sources set the same parameter, the higher priority wins. Settings that do not overlap are combined.

Note: Rules override every other source, including OU and device labels and independent device configurations. Within a rule, the order of its labels sets their priority. When more than one rule matches a device, the higher-priority rule wins for any setting both rules configure.

DEFAULTS AND OVERRIDES

Default settings are defined once in the device configuration of the top OU (Lab) and inherited by every OU below it. This is the lowest-priority layer. Rules sit at the top of the priority order, so each rule and its label override only the configuration sections the label contains. Everything else still comes from the inherited defaults.

Because overrides come from rules rather than from separate OU configurations, inheritance typically does not need to be broken, and a change to the Lab defaults still reaches every device.

Figure 1 – Rules Overview: drag the handles to set priority. Every rule overrides the inherited Lab defaults.

Figure 2 – Labels Overview: each label lists the sections it overrides. Firmware Update Testing is colored Warm Amber to mark it as a test item.

GROUPING LABELS BY COLOR

Labels can be given a color in Scout Board. Use color to group like items so administrators can see at a glance what kind of override a label is. Scout Board offers several label colors.

WAYS TO TARGET A RULE

Rule parameters can be applied by several different items, such as OS name, OU name and IP subnet, as well as firmware version, hostname, serial number and hardware model. Pick the item that matches why the devices need different settings, so the rule stays correct as devices move or are replaced.

APPLYING FIRMWARE WITH RULES

Firmware is one of the most useful places for rules, because a Firmware-only label can stage an update to a small group without touching anything else. There are three complementary approaches:

RECOMMENDED OU STRUCTURE

A shallow OU tree in which standards are defined once at the top and inherited by every OU below it. Changes for a specific group are made with Configuration Rules and Labels so inheritance stays intact. In the lab, every OU (including Kiosk) inherits from Lab, and the differences come from the rules shown above.

Figure 3 – OU structure in Scout Board.

BEST PRACTICES

DESIGN

• Keep inheritance intact. Keep “Use parent device configuration” on for every OU. Put defaults in the top OU and use rules and labels for every difference.
• Use rules and labels only for overrides. The defaults belong in the OU configuration, not in a rule. Each rule should override only what a group of devices needs to be different.

LABELS

• Override labels should set only the sections they change.
• Keep override labels small. The full baseline lives in the Lab OU configuration. Override labels should usually cover one to three sections.
• Use label colors to group like items. For example, Warm Amber for testing and temporary labels, Deep Ocean for standard overrides, Cool Teal for staging.
• Fill in the description field with the purpose, the owner, and the change ticket or date.

RULES

• Order deliberately. Put the rules that must always win (such as _Staging) at the top.
• Keep peer exception rules mutually exclusive when they configure the same section (for example Lab_Apps, Lab_Desktop and Lab_Kiosk). When one group is a subset of another, as with Windows 11_FIDO inside Desktops, place the narrower rule above the broader one.
• Start narrow, then widen. Test a new rule against one or two serial numbers before switching it to a subnet or hostname prefix.
• Use the Active toggle to pause a rule during troubleshooting instead of deleting it.

IMPLEMENTING RULES AND LABELS

Perform these steps in Scout Board with an administrator account that has rights to device configuration.

1. Set the default settings in the device configuration of the top OU (for example Lab), and confirm every OU below it has “Use parent device configuration” turned on.
2. For each override:
   1. Create a label that includes only the sections that differ, and give it a color that matches its group.
   2. Create a rule with a narrow expression. Start with one or two pilot devices.
   3. Assign the label and, if the rule has several labels, order them so the one that should win is highest.
   4. Drag the rule above any other rule it must override.
3. After changing an OU device configuration, click Save and check independent configurations so the change reaches OUs and devices with independent configurations.
4. Restart a pilot device (or wait for it to reconnect) so the rules are evaluated. The Evaluated time under Applied Rules & Labels shows when this last happened.

Note: Rules are evaluated when the device connects to UniconOS Management. Changes may not appear on a device until it restarts or reconnects.

POST-IMPLEMENTATION VERIFICATION

The rules applied to a device are shown in Scout Board under OU structure. Select the OU, then select the device. The device panel on the right lists Applied Rules & Labels: every rule that matched the device, the time it was evaluated, and the labels it applied.

Note: Applied Rules & Labels is listed in rule priority order, highest first, matching the order in the Rules Overview. When two applied rules set the same section, the rule nearer the top wins. Use this list to confirm which override a device is actually getting.

Figure 4 – Applied Rules & Labels for a device in the _Staging OU. It matched _Staging and Firmware – 2609 Testing, shown in priority order (_Staging is highest).

1. In the Rules Overview, confirm the rule is Active, in the right position, and shows the expected label.
2. In the Labels Overview, confirm Used Sections lists only the sections you intended to override.
3. Select a pilot device under OU structure and check Applied Rules & Labels. Confirm the expected rules are listed with a current Evaluated time. Then review the effective configuration and confirm the override settings were applied and the other sections still come from the Lab defaults.
4. Confirm devices that should not match, including devices in other OUs such as Kiosk and _Staging, did not pick up the change. The rule should not appear in their Applied Rules & Labels.
5. Widen the rule to the full target group and repeat steps 3 and 4 on a sample of devices.
6. Record the change (name, purpose, owner, date) in your change log.

ONGOING MAINTENANCE

• Review quarterly. Remove firmware testing rules after rollout, rules for retired hardware, and labels with no entry under Used in Rules.
• Limit who can edit rules. Use Scout Board administrator rights so only experienced administrators can create or reorder rules.