Scheduling Remote Actions

The Remote Actions module lets you schedule remote actions for your remediation and data collection needs, at the frequency that best suits each specific use case.

Scheduling remote actions

Select the schedule type that is most suitable for your use case.

Schedule options

Centrally scheduled

Locally scheduled

Nexthink recommends using locally scheduled remote actions after your Collector agents are all updated to 24.4 or later. Devices with Collector versions 24.4 or later are the only ones that execute locally scheduled remote actions.

If you want to adjust the scheduling of a remote action from Centrally scheduled to Locally scheduled or vice versa, ensure you delete the first existing schedule and re-create a new schedule after changing the scheduling type.

Considerations when configuration schedules

When scheduling a remote action, whether locally or centrally, you can create one or more schedules (up to 10) for the remote action, each with their own device target, scheduling and input parameter values. Use multiple schedules per remote action to:

Target different devices with a different schedule (e.g. a daily remote action that should be scheduled at different times depending on the device location, or a remote action that should be run more frequently on critical devices)
Run the remote action with different parameters on different devices

When using multiple schedule, beware that each schedules are evaluated separately. In case the same device is returned by the investigation in different schedules, several executions per device will be created.

Considerations for NQL queries used in Schedule

Use NQL queries that target only those devices where the remote action is relevant. This approach minimizes the number of pending executions and avoids unnecessary executions due to the device not meeting the criteria of the remote action’s intent.

The table below provides example conditions to include in your queries.

Example of a non-recommended query:

The query will not filter out devices based on recent device activity nor any technical dependency such as platform, hardware type, operating system, or software, and is likely to result in several executions timing out or ending in failure.

devices
| where entity == "ABC"

Example of a query following the previous recommendation:

Consider the following remote action used to remediate issues encountered by Virtual Desktop Infrastructure (VDI) users of a critical business application used exclusively by the sales team, intended to run for a frequency of 1 hour.

devices past 60min
| where hardware.type == virtual and operating_system.platform == windows
| with session.events past 60min
| where user.ad.department == "Sales"
| with package.installed_packages
| where package.name == "MyBusinessApp"

The query includes precise conditions matching those devices where the remediation is relevant, resulting in fewer executions experiencing errors or reporting no impact due to missing dependencies. The query is also limited to those virtual devices where an interactive user from the relevant department has been recently active, resulting in fewer irrelevant timeouts.

Monitoring locally scheduled remote actions

Locally scheduled remote actions report their results to the platform using the regular remote_action.executions table. Unlike Centrally scheduled and on-demand executions, the request_id is not unique per execution. The request_id is the same for all executions corresponding to the same schedule on the same device.

Use remote_action.local_schedules to monitor the status of schedule configurations for each device. This returns a detailed overview of the local schedule created on all devices, their current states and any pending actions.

See the table below for more information.

Use the following NQL query to identify the number of devices in each configuration state for a given remote action.

remote_action.local_schedules
| where remote_action.name == "<some remote action name>"
| summarize device_count = device.count() by local_schedule.name, state, pending_action
| sort state asc

Last updated 1 month ago