# Update Configuration

## Pausing updates <a href="#collectormanagement-pausingupdates" id="collectormanagement-pausingupdates"></a>

* Activate the **Pause automatic updates** feature to pause the Collector updates on all the devices.
* Select the date from the **Updates will resume** drop-down menu to indicate when to resume the updates.

You can inspect the property `device.collector.target_update_date` to know when the devices will be updated once the pause expires. If the pause functionality is turned off before its expiration, the update dates will be recomputed from that moment.

<figure><img src="https://268444917-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxJSUDk9NTtCHYPG5EWs3%2Fuploads%2Fgit-blob-6bf572af3568126cc2a0dcb7f1dc5ba9eb8b9575%2Fcolm-1684746711.png?alt=media" alt="Pause updates" width="544"><figcaption></figcaption></figure>

## Fast-track updates for maintenance releases <a href="#collectormanagement-fast-trackupdatesformaintenancereleasesmaintenance" id="collectormanagement-fast-trackupdatesformaintenancereleasesmaintenance"></a>

Maintenance releases apply to the currently installed versions of Collector and include small fixes for specific security issues or address critical bugs. By default, maintenance releases are rolled out without a delay to all the devices with the same installed version of Collector, to ensure running the most stable Collector release at all times.

Deactivate this setting to let maintenance releases follow the same rollout strategy as new versions of Collector, taking the pilot and main group delays into account. This choice offers more control but delays the adoption of bug fixes.

## Update groups <a href="#collectormanagement-updategroups" id="collectormanagement-updategroups"></a>

Define a pilot group of devices the system automatically updates with a new version of Collector before the others. If you do not define the pilot group with NQL, the system randomly chooses 10% of the Collector instances installed on the employee devices.

**Example**

<figure><img src="https://268444917-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxJSUDk9NTtCHYPG5EWs3%2Fuploads%2Fgit-blob-7957d8d7fd96b622d106b4616487285409b76ea9%2Fcolm-1684747241.png?alt=media" alt="Update pilot group" width="544"><figcaption></figcaption></figure>

```sql
devices | where device.name == '*pilot*'
```

### Defining the pilot query <a href="#collectormanagement-definingthepilotquery" id="collectormanagement-definingthepilotquery"></a>

The query must target the `devices` collection and can use conditions on any of its fields.

#### **NQL examples**

Targeting specific devices by name:

```sql
devices | where name in ['abc', 'def']
```

Targeting specific devices using a pattern:

```sql
devices | where device.name contains 'NX'
```

Targeting devices with a specific property:

```sql
devices | where ad_site = 'my site'
```

The system does not support the `summarize` , `list`, `with`, `limit` , `during past`, `from .. to ..` statements. It recomputes the pilot query every 6 hours and upon any configuration change, such as an updated query or release of a new Collector version.

### Rolling out updates <a href="#collectormanagement-rollingoutupdates" id="collectormanagement-rollingoutupdates"></a>

The system schedules all devices in the pilot group for an update two days after a new compatible Collector version is available, and all other devices for an update two weeks later or 16 days after a new compatible Collector version is available. Refer to the [Fast-track updates for maintenance releases](#collectormanagement-fast-trackupdatesformaintenancereleasesmaintenance) section for more information about the maintenance releases and how to configure their rollout strategy.

The rollout is paced with the goal of updating all the Collector instances of the pilot group within a week and all other devices within two weeks from the start of the rollout. There is also an upper rate limit to prevent Collector from sending update requests in excess of 100 requests per minute per instance to avoid overloading the network.

### Retry policy <a href="#collectormanagement-retrypolicy" id="collectormanagement-retrypolicy"></a>

If an update fails, the Collector updater tries the update again after one hour.

### Excluding non-persistent VDI devices

Select the **Do not update shared and pooled VDI devices** option to avoid Collector updates on non-persistent VDI devices, such as pooled and shared virtual desktops. This exclusion prevents such desktops from constantly switching between different Collector versions.

{% hint style="info" %}
You must configure the applicable [inbound connector](https://docs.nexthink.com/platform/configuring_nexthink/bringing-data-into-your-nexthink-instance/integrating-nexthink-with-third-party-tools/inbound-connectors) for your virtual environment to use this feature.
{% endhint %}