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:
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 exampleCN=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
andPattern1=*
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:
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.
#region is the NQL ID.
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
andPattern1=*
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 |
|
|
Rule-based location type |
|
|
Rule-based organization |
|
|
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:
Geographical distribution of Salesforce users
Write an NQL query to find the geographical distribution of Salesforce users.
Filter devices by organizational entity
Filter devices by entity
to target them within a specific part of the organization.
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.
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