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
Supported frequencies	Hourly, Daily and Weekly.	Minutes (minimum every 10 minutes up to 45 minutes).
Scheduling limits	Schedule up to 100 remote actions.	Schedule up to 10 remote actions with a frequency of less than 1 hour.
Compatible with triggers	Compatible with other triggers.	Not compatible with manual or API triggers.
Supported platforms	Windows and macOS	Windows
Execution time	Execution time between the triggering time and the next iteration: If a device is activated after the scheduled time, the system executes the remote action provided it is still valid.	Precise timing based on the local time: If the device is off during the execution, the system will skip the execution.
Change of targeting and scheduling	For each evaluation of the remote action, the system immediately executes all devices returned by the investigation.	Devices receive schedules when creating or updating the remote action. The investigation occurs every 1 hour. Deleting schedules on devices may require up to 90 minutes to become effective.
Monitoring	Execution details, including in progress and waiting for device information, available in remote_action.executions . This includes visibility in remote action dashboards.	Completed executions, success and failure, available in remote_action.executions. This includes visibility in remote action dashboards. Scheduling state execution available in remote_action.local_schedules. Refer to the Monitoring locally scheduled remote actions section for more information.
Error reporting	Execution failures reported systematically.	If 10 executions in a row fail on a given device, execution failures will not be reported for 12 hours, and a special status message will indicate that this condition has been reached. The device will continue executing the script and resume reporting when the delay expires, a successful execution is recorded, the collector is restarted, or the remote action configuration is modified. Note: This applies to collector versions 24.8.2 and later.
Scripts with interactive user context	Scripts with interactive user context report execution in state failure in case there are no interactive user sessions.	Scripts with interactive user context do not execute nor report error when there are no interactive user sessions. (Applicable to collector versions 24.8.2 and later)

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.

Type of conditions	Description	Example
Platform and operating system	Consider if the remote action applies only to a given platform, Windows or macOS, or a specific version(s) of an operating system. For Locally scheduled remote actions, always specify a condition on the platform, as they currently support only Windows endpoints.	Windows script: | where operating_system.platform == windows Windows 11 script: | where operating_system.platform == windows and operating_system.name == "Windows 11*"
Device type	Consider whether the remote action targets virtual, physical or laptop devices.	Physical device: | where hardware.type != virtual Laptop devices: | where hardware.type == laptop
Online devices and active user session	Always include a condition that only recently online devices are considered. This is especially pertinent to remote actions scheduled at daily frequencies or those scheduled less frequently. Only consider devices with recent user session activity for remote actions running in the user context.	Limit hourly-scheduled remote actions to devices reporting an activity in the past 60 minutes. | with execution.events past 60min Limit hourly scheduled remote actions for the currently logged-in user to those devices with an active user in the past 60 minutes. | with session.events past 60min
Installed software package	Consider whether the remote action requires the installation of a specific software package on the device.	Limit a remote action for remediation of Microsoft Teams issues to devices with Microsoft Teams installed. | with package.installed_packages | where package.name == "Microsoft Teams*"

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.

Schedule status	Description	Possible pending action
Waiting for device	The schedule configuration is waiting for the device to be online.	Configure - The system is waiting for the device configuration to be successful.
Configuring	The schedule configuration was sent to the device and wait for the device response.	Configure - The system is waiting for the device configuration to be successful.
Active	The schedule configuration was successful. The Locally scheduled remote action is currently being executed on the device.	None: No pending changes. Configure: A reconfiguration is pending. Delete schedule: The schedule is not valid anymore, and the system will remove the device.
Deleted	The schedule configuration was successfully deleted and the current schedule will not execute the Locally scheduled remote action on the device.	None: No pending changes.
Failed	The schedule configuration on the devices has failed for technical reasons. Examples of failures include: The Collector version does not support Locally scheduled remote actions. Locally scheduled remote actions are not supported on device platforms such as MacOS. Other technical failures when creating the schedule.	Configure: The system may try to reconfigure the device.

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