Product configuration

Device location and organization

Product configuration addresses two categories of device management.

Location

Know where a device is at the time of an event so that:

  • Support teams can troubleshoot issues effectively.

  • Employees receive the same level of digital experience independent of their location.

Track events by:

  • Geographical location

  • Location type, onsite or remote

Organization

Define the relationship between the device and the organizational structure.

  • Specify access and administrative rights for users with the right level of granularity, for example, by assigning IT support user rights to a region or department that they are responsible for.

  • Assign compliance responsibility and patching responsibility to the right users.

  • Track hardware renewal needs at the right level.

While the organization of a given device is rather static, its location can change frequently. The following example illustrates some of the possible locations of a device owned by a Swiss entity.

  • A device is located in the Lausanne office in Switzerland.

  • A device is located in the Boston office in the U.S.

  • An employee is working remotely from home in Lausanne.

  • An employee is working from a hotel in Boston.

Accessing product configuration

  • Select Administration from the main menu.

  • Click Product configuration in the System configuration section of the navigation panel. You must have administrative rights to see this feature. Refer to the Roles documentation for more information.

Location

Geolocation tab

Gain more dynamic insights into the digital employee experience (DEX) of remote employees with the geolocation feature. Nexthink determines the location of devices on the internet by referencing the GeoIP database and public IP addresses of the systems running Collector.

The geolocation feature is disabled by default.

Location granularity

Choose one of the following options:

  • Do not capture any location data

  • Public IP only

  • Public IP and country

  • Public IP, country and state

  • Public IP, country, state and city

When you enable the geolocation feature, the Nexthink platform records the name of the internet service provider (ISP) independently of the selected level of granularity.

Using a virtual private network (VPN) affects the public IP address reported by Collector. In order to improve the geolocation precision, it is best to avoid routing the traffic between Collector and the Nexthink instance through a VPN. The feature works with any version of Collector, and no information leaves the Nexthink platform. Nexthink has its own instance of the geolocation database and performs the geolocation lookup internally.

Location type tab

The Nexthink platform includes a rule-based assignment process that allows the system to determine if a device is located onsite or remotely. This feature is highly configurable and you can adjust it by modifying the rules.

Configure the assignment using a CSV file with a tabular structure. Each row in the table contains two patterns and a location type.

Example of a CSV file

Example of the comma-separated, assignment text file:

Field1,Pattern1,Field2,Pattern2,Location Type
primary_local_ip,10.0.0.0/8,name,NXT*,Onsite
primary_local_ip,172.16.0.0/16,,,Onsite
name,*,,,Remote

Table showing the assignment rules from the text file above:

Field1
Pattern1
Field2
Pattern2
Location Type

primary_local_ip

10.0.0.0/8

name

NXT*

Onsite

primary_local_ip

172.16.0.0/16

Onsite

name

*

Remote

The first rule tags all devices belonging to the local subnet 10.0.0.0/8 whose name starts with NXT as Onsite. The second rule tags all devices belonging to the local subnet 172.16.0.0/16 as Onsite. The last rule tags all other devices as Remote.

To satisfy a rule, a pattern must match the corresponding field. The system establishes rule precedence from the top to the bottom of the table. You can be more specific with the device assignment at the top of the table and more general at the bottom.

  • Field1: Data for the first field used for the assignment

  • Pattern1: The pattern for the first field

  • Field2: Data for the second field used for the assignment

  • Pattern2: The pattern for the second field

  • Location Type: The name of the target location type. The allowed location type values are:

    • Onsite

    • Remote

    • Unknown

Supported values for Field1 and Field2:

  • name: The hostname of the device.

  • collector_tag: The tag number assigned to Collector during its installation. Only the exact number is matched.

  • collector_string_tag: The label assigned to Collector during its installation. This value supports pattern matching.

  • dn: The distinguished name of the device, as reported by Collector. The device must be part of an Active Directory domain. The format of the distinguished name reported by Collector is the standard sequence of attribute=value elements connected by commas, from the most specific to the most general attribute. For example CN=ex01,OU=Computers,DC=example,DC=org

  • ad_site: The Active Directory site on which the device is located. The name, collector_string_tag, dn and ad_site fields support character pattern matching. To define the associated string pattern, use the following wildcards:

    • The ? character substitutes a single character.

    • The * character substitutes zero or more characters.

  • ip: The last public IP address of the device. As a pattern for the field, specify either:

    • A single IP address in dot-decimal notation, for example: 192.168.10.1

    • A subnet in CIDR notation, for example: 192.168.10.0/24

  • primary_local_ip: The last local IP of the device for the primary physical network adapter. Specify patterns in the same way you specified them for the ip field.

  • collector_local_ip: The local IP used for the traffic between the endpoint and the Nexthink instance. Specify patterns in the same way you specified them for the ip field.

Enabling geolocation is a prerequisite for building rules based on public IP addresses.

Considerations

Ensure that your CSV configuration file meets the following criteria:

  • The file size is less than 5MB.

  • The file encoding is UTF-8.

  • A comma is the field separator.

  • Field delimiters are optional and quotes " are the only allowed delimiter type.

  • The total number of rules or rows is less than 40,000.

  • A catch-all rule with Field1=name and Pattern1=* is entered for the last row of the table.

If any of these checks fail, the file selection will revert to the previously uploaded file. Only when you fix the errors, will you be able to unblock the upload.

Uploading the CSV file

Refer to the in-product documentation in the right-side panel for step-by-step instructions on uploading the CSV file.

Organization

The Nexthink platform includes a rule-based assignment process that allows the system to dynamically reassign the organization entities of devices. Additionally, you can classify the entities into higher-level organizational units, for example, global regions.

This feature is highly configurable, allowing you to adjust the assignment by modifying the rules or adding your own classifications of entities, according to the requirements of your organization.

Configure the assignment using a CSV file with a tabular structure. Each row in the table contains two patterns and an entity name. Optionally, it can also contain custom classifications of the entity.

Example of a CSV file

Example of a comma-separated, assignment text file:

Field1,Pattern1,Field2,Pattern2,Entity,region
,,,,,Global Region
name,device-d*,,,FRANCE,EUROPE
name,device-1*,,,CANADA,AMERICAS
collector_string_tag,CH*,,,SWITZERLAND,EUROPE
collector_string_tag,US*,,,UNITED STATES,AMERICAS
name,*,,,Unassigned,Unassigned

Table showing the assignment rules from the text file above:

Field1
Pattern1
Field2
Pattern2
Entity
Region

Global Region

name

device-d*

FRANCE

EUROPE

name

device-1*

CANADA

AMERICAS

collector_string_tag

CH*

SWITZERLAND

EUROPE

collector_string_tag

US*

UNITED STATES

AMERICAS

name

*

Unassigned

Unassigned

Each row in the table contains two patterns, an entity name and optional additional custom classifications. To satisfy a rule, a pattern must match the corresponding field. The system establishes rule precedence from the top to the bottom of the table. This requires you to be more specific with the device assignment at the top of the table and more general at the bottom.

Suppose you have a device with the name as device-d100 and collector_string_tag as CH10. This device would match both the first and the third rules. Since the system evaluates the device-d100 rule first, the device would be assigned to Entity FRANCE and Global Region EUROPE.

The first five columns are mandatory:

  • Field1: Data for the first field used for the assignment

  • Pattern1: The pattern for the first field

  • Field2: Data for the second field used for the assignment

  • Pattern2: The pattern for the second field

  • Entity: The name of the target entity

In addition to the mandatory columns, add up to six custom classifications.

The system uses the header row to create the NQL ID of the classification. Those values cannot contain spaces or special characters. The values in the second row correspond to the display names.

  1. #region is the NQL ID.

  2. Global Region is the display name of the NQL ID of the classification.

Supported values for Field1 and Field2:

  • name: The hostname of the device.

  • collector_tag: The tag number assigned to Collector during its installation. The system only matches the exact number.

  • collector_string_tag: The label assigned to Collector during its installation. This value supports pattern matching.

  • dn: The distinguished name of the device, as reported by Collector. The device must be part of an Active Directory domain. The format of the distinguished name reported by Collector is the standard sequence of attribute=value elements connected by commas, from the most specific to the most general attribute. For example, CN=ex01,OU=Computers,DC=example,DC=org

  • ad_site: The Active Directory site on which the device is located. The name, collector_string_tag, dn and ad_site fields support character pattern matching. To define the associated string pattern, use the following wildcards:

    • The ? character substitutes a single character.

    • The * character substitutes zero or more characters.

  • ip: The last public IP address of the device. As a pattern for the field, specify either:

    • A single IP address in dot-decimal notation, for example 192.168.10.1

    • A subnet in CIDR notation, for example 192.168.10.0/24

  • primary_local_ip: The last local IP of the device for the primary physical network adapter. Specify patterns in the same way you specified them for the ip field.

  • collector_local_ip: The local IP used for the traffic between the endpoint and the Nexthink instance. Specify patterns in the same way you specified them for the ip field.

Enabling geolocation is a prerequisite for building rules based on public IP addresses.

Considerations

Ensure that your CSV configuration file meets the following criteria:

  • The file size is less than 5MB.

  • The file encoding is UTF-8.

  • A comma is the field separator.

  • Field delimiters are optional and quotes " are the only allowed delimiter type.

  • There are no entity values and no classification values with an empty string or -.

  • The maximum length of entity values and classification values is 50 characters.

  • The total number of rules or rows is less than 40,000.

  • The total number of distinct entities across the whole file is less than 2,000.

  • The total number of custom classification columns is less than 6.

  • A catch-all rule with Field1=name and Pattern1=* is entered for the last row of the table.

  • The same entity cannot belong to multiple custom classifications. If an entity value appears on several lines, its classifications must be identical across all lines.

Example: The system will reject the following assignment rule because Entity FRANCE is incorrectly assigned to both EUROPE and AMERICAS on two different lines.

Field1
Pattern1
Field2
Pattern2
Entity
Region

Global Region

name

device-d*

FRANCE

EUROPE

name

device-e*

FRANCE

AMERICAS

If any of these checks fail, the file selection will revert to the previously uploaded file. Only when you fix the errors, will you be able to unblock the upload.

Uploading the CSV file

Refer to the in-product documentation located in the right-side panel for step-by-step instructions on how to upload the CSV file.

When you upload the ruleset for the first time, there is a delay ranging from 20 to 60 minutes for the data to be populated, depending on the size of the CSV file.

Editing custom classification

You can edit custom classifications by uploading an updated CSV file that best reflects your organizational structure. You can:

  • Delete the entire column to remove the existing custom classification.

  • Include a new column to add a new custom classification.

Once the new CSV is uploaded, the old custom classifications are removed from the data model and are no longer suggested by autocomplete.

Updating custom classifications may the affect results of existing NQL queries relying on organizational data. Ensure that you review and update these NQL queries after making changes to the custom classifications.

View domain permission relies on organization data, including custom classifications. Changing the assignment rules may affect the scope of data available to users with limited View domain permission. Be sure to revise profiles with limited View domain access after making changes to the custom classifications.

NQL examples

Location and ownership fields are available in the data model at two levels:

  • As device property: the fields return the current ownership and location of the device.

  • As event context: the context field returns the ownership and location at the time of the event.

The following table summarizes the corresponding fields.

Device property
Event context

Geolocation

device.public_ip.country device.public_ip.state device.public_ip.city

context.location.country context.location.state Note: city is not available as event context today.

Rule-based location type

device.location.type

context.location.type

Rule-based organization

device.organization.entity device.organization.#customClassification

context.organization.entity context.organization.#customClassification

The following NQL examples employ the product configuration features.

Investigate execution crashes

Investigate the number of execution crashes on all devices during the last 7 days to spot a potential geographical trend. In the Investigations module write the following query:

execution.crashes during past 7d
| summarize total_crashes=number_of_crashes.sum() by public_ip.country, public_ip.state, public_ip.city

Geographical distribution of Salesforce users

Write an NQL query to find the geographical distribution of Salesforce users.

web.events
| where application.name == "Salesforce*"
| summarize Number_of_users = user.count() by public_ip.country, public_ip.state, public_ip.city
| sort Number_of_users desc

Filter devices by organizational entity

Filter devices by entity to target them within a specific part of the organization.

devices 
| where organization.entity == "SWITZERLAND"

Compare DEX scores by custom region and location type

Break the DEX score down by #region and location.type to ensure digital experience consistency across the organization.

dex.scores during past 7d
| summarize c1 = value.avg() by device.organization.#region, context.location.type

Permissions

You must have administrative rights to access the Product configuration feature.

To enable proper permissions:

  • Select Administration from the main menu.

  • Click on Role from the navigation panel.

  • Click on the New Role button to create a new role or edit an existing one by hovering over an existing role and clicking on the edit icon to change the role configuration.

  • In the Permissions section, scroll down to the Administration section to enable appropriate permissions for the role.

Refer to the Roles documentation for a detailed description of the permission options.

Last updated

#451: 2024.8-Overview of integration DOC

Change request updated