Skip to content

Device Segments

Device segments group endpoints in your estate by criteria such as operating system, hostname pattern, or custom tag, and allow you to apply settings on a per-segment basis. Segments are the primary mechanism for controlling which features are enabled on which devices.

💡 Where segments are used: Segments control Active Response access, malware scanning behaviour, memory protection settings, and other endpoint-side feature toggles. They are referenced from the Active Response and Local Configuration articles.

ℹ Note: Segments are now managed from the Device Configuration page. The standalone Settings > Device Segments listing has been retired, and the segment inventory, creation, and editing all live alongside the settings on Settings > Device Configuration. Existing bookmarks to the old page are redirected to Device Configuration automatically.

Accessing Device Segments

Navigate to Settings > Device Configuration. This view requires the Manager or Admin role.

The page lists all segments configured for your organisation, with the device count, criteria summary, and applied feature settings for each.

The Device Configuration page listing device segments and their settings

How Segmentation Works

Each device in your estate is automatically evaluated against the criteria for every segment. A device can be a member of multiple segments. When two segments apply conflicting settings to the same device, segment priority determines which setting wins (higher-priority segments override lower-priority ones).

Segment membership is re-evaluated whenever:

  • A new device enrolls
  • A device's hostname, OS, or other criteria field changes
  • A segment's criteria are edited

Creating a Segment

  1. Go to Settings > Device Configuration.
  2. Click Create a new Segment.
  3. Give the segment a name and optional description.
  4. Define the criteria that identify which devices belong to this segment. Criteria can include:
  5. Operating system (Windows, Linux, macOS)
  6. Hostname (exact match or wildcard pattern)
  7. IP address range
  8. Custom tag value
  9. Universal Sensor agent version
  10. Configure the settings that should apply to devices in this segment (see the next section).
  11. Set the segment priority (a number, higher wins).
  12. Click Save.

For the operators each criterion accepts, the wildcard syntax, and how several rules combine, see How Criteria Are Matched.

The segment becomes active immediately and devices matching the criteria will pick up the new settings the next time they check in.

How Criteria Are Matched

Each rule in a segment is a single statement of the form property, operator, value. For example, hostname matches LON-SRV-*. The properties available to you, and the operators each one accepts, are served by the platform rather than fixed in the interface, so the exact list can differ between tenants and can change as new properties are added.

Operators

A property only offers the operators that make sense for it. Where a property accepts a single operator, the rule builder displays that operator as fixed text. Where it accepts more than one, you choose from a dropdown.

Operator Meaning
Equals The property matches the value exactly.
Matches (wildcard pattern) The property matches a pattern containing wildcard characters. Available on hostname and fully qualified domain name (FQDN).
Matches (path) The property matches a full path or a path leaf. Used for the Active Directory organisational unit.
In The property is a member of the set of values you supply. Used for Active Directory groups.

Wildcard pattern syntax

When a rule uses the wildcard pattern operator, two wildcard characters are available in the value:

Character Matches
* Zero or more characters
? Exactly one character

For example, given hostnames LON-SRV-01, LON-SRV-02 and MAN-WKS-01:

  • LON-SRV-* matches LON-SRV-01 and LON-SRV-02
  • LON-SRV-0? matches LON-SRV-01 and LON-SRV-02
  • *-SRV-* matches both London servers but not the Manchester workstation
  • LON-SRV-01 used with the wildcard operator and no wildcard character behaves as an exact match

The rule builder shows a How to use wildcards hint whenever a segment contains at least one wildcard pattern rule.

💡 Wildcards apply to the hostname and FQDN properties. Properties that offer a fixed set of values, such as operating system type, are chosen from a dropdown instead and do not accept patterns.

Active Directory organisational unit format

Rules on the Active Directory organisational unit (OU) property take a path, not a distinguished name. A value such as OU=Hardware,DC=example,DC=local will not match any device.

The Universal Sensor reads each Windows device's distinguished name from Active Directory and reports its OU as a path, written from the top-level OU down to the OU that holds the computer object:

  • each OU= component becomes one path segment, separated by /, with a leading /
  • the order is reversed, so the outermost OU comes first
  • the computer's own name (CN=) and the domain components (DC=) are dropped

For example, for a computer with the distinguished name:

CN=LON-WKS-042,OU=Deploy Test,OU=London,OU=Hardware,DC=example,DC=local

the reported OU path is:

/Hardware/London/Deploy Test

The Matches (path) operator accepts either the full path or the leaf of the path:

Rule value Matches the device above? Why
/Hardware/London/Deploy Test Yes Full path, from the top-level OU down
Deploy Test Yes The leaf, the OU that directly holds the computer
OU=Deploy Test,OU=London,OU=Hardware,DC=example,DC=local No Distinguished name format is not accepted
/Deploy Test/London/Hardware No Path written in distinguished name order, innermost OU first

Some points to be aware of:

  • Spaces are kept. OU names containing spaces, such as Deploy Test, are written as they appear in Active Directory, without quotes.
  • The domain is not part of the path. Two domains with the same OU structure produce the same path. To target one domain only, combine the OU rule with a hostname or FQDN rule and set the segment to all.
  • Leaf matches can be broad. A leaf such as Laptops matches every device whose OU ends in Laptops, wherever it sits in the tree. Use the full path when the same OU name is reused in several places.
  • Special characters are left escaped. Where an OU name contains a character that Active Directory escapes in a distinguished name, such as a comma, the escaping backslash is kept in the path. An OU named Sales, EMEA is reported as Sales\, EMEA.
  • Only domain-joined Windows devices report an OU. Devices that are not joined to Active Directory, and macOS and Linux devices, have no OU value and never match an OU rule.

If you are not sure what path a device reports, check it against Devices matching the current conditions before saving (see Checking a rule before you save it). A rule that returns no devices usually means the value is in distinguished name format or the path is written in the wrong order.

Combining more than one rule

A segment holds a flat list of rules joined by a single any or all choice that applies to the whole segment:

  • any means a device joins the segment if it matches at least one rule, equivalent to a boolean OR.
  • all means a device joins the segment only if it matches every rule, equivalent to a boolean AND.

The any / all toggle appears in the rule builder once a segment has two or more rules, in the sentence that reads Select devices which match any of the following rules. With a single rule there is nothing to combine, so no toggle is shown.

Rules cannot be nested, and you cannot mix any and all within one segment. A condition such as Windows devices, and either of two hostname patterns therefore cannot be expressed as a single segment. Where you need that, either widen the rules and accept the larger match, or split the logic across two segments and let priority decide which settings apply.

Excluding a device is not supported

There is no negative operator. Every operator asserts that a property does match a value, and there is no is not, does not match, or not in form. You cannot write a rule that removes a device, or a group of devices, from a segment it would otherwise match.

Two approaches work instead:

  • Describe the devices you do want. Narrow the rules so the devices you wanted to exclude never match in the first place. Where a naming convention allows it, a more specific pattern is usually enough.
  • Layer a higher-priority segment over the top. A device can belong to several segments at once, and where two segments set the same setting differently, the higher-priority segment wins. To carve out an exception, leave the broad segment matching everything, then create a narrower, higher-priority segment that matches only the exceptions and sets the values those devices should get. This does not remove those devices from the broad segment, but it does decide the settings they receive.

Checking a rule before you save it

The segment editor lists the devices matching the rules as they currently stand, under Devices matching the current conditions, together with a count. Use this to confirm a pattern selects what you expect before saving. You can choose which device properties the preview displays.

Two further behaviours are worth knowing:

  • A rule with no value is incomplete and is not saved. Give every rule a value, or delete it, before saving the segment.
  • If a rule refers to a property that is no longer available to your tenant, the rule builder flags it and the rule is evaluated as non-matching. It does not match every device, and it does not stop the rest of the segment working. Remove the flagged rule when you see it.

Per-Segment Settings

The following settings can be configured per segment:

Setting Effect
Active Response enabled Allows users with Active Response access to start sessions and run actions on devices in this segment. See Active Response.
Malware scanning Controls whether the endpoint agent performs on-access and on-demand malware scanning.
Memory protection Enables additional memory-level threat protection. May affect performance on resource-constrained hosts.
Media Control Controls removable mass storage devices such as USB drives, including the action taken for devices that no rule covers. To restrict USB devices with Group Policy instead, see USB Controls.
End-user notifications Controls whether the endpoint displays toast notifications to the user. See End User Notifications.
Local configuration overrides Permits or blocks local configuration changes on the endpoint. See Local Configuration.

ℹ Availability: Malware scanning and Memory protection are part of Endpoint Protection, a licensed module that SenseOn enables for your organisation. Until then those settings appear locked. Media Control settings appear only where SenseOn has enabled Media Control.

Editing a Segment

  1. Go to Settings > Device Configuration.
  2. Select the segment you want to edit.
  3. Make your changes to criteria, settings, or priority.
  4. Click Save.

Changes propagate to devices on their next check-in.

Compatibility Checks

When you change a setting on a segment, SenseOn checks each affected device against the minimum Universal Sensor agent version that supports that setting. If any device has an out-of-date agent, you will see a warning listing the affected hosts. The setting still applies, but devices below the minimum version will ignore it until they are upgraded.

To see which devices are affected by a compatibility warning:

  1. Open the segment.
  2. Click the Compatibility tab.
  3. The list shows each device, its current agent version, and whether each configured setting is supported.

Deleting a Segment

  1. Go to Settings > Device Configuration.
  2. Select the segment.
  3. Click Delete Segment.
  4. Confirm the action.

Devices that were only in the deleted segment fall back to the Default segment.

The Default Segment

Every organisation has a Default segment that applies to any device not matched by a more specific segment. You cannot delete the Default segment, but you can edit its settings. Use the Default segment to set safe baseline behaviour for the whole estate, then layer more specific segments on top for exceptions.

Auditing Segment Changes

All segment creation, edit, and delete events are recorded in the Audit Log with the action category segment.