リモートアクションをスケジュールする

リモートアクションモジュールでは、各ユースケースに最適な頻度で、修復およびデータ収集のニーズに応じてリモートアクションをスケジュールできます。

オンデマンド（手動、ワークフロー、または API 経由）でリモートアクションを実行すると、システムはスケジュールされたリモートアクションよりもそれを優先します。 これにより、同時に実行されるスケジュール済みリモートアクションによって、オンデマンドのリモートアクション実行が遅延することはありません。

リモートアクションのスケジュールタイプ

ユースケースに最も適したスケジュールタイプを選択します。

スケジュールオプション	中央スケジュール	ローカルスケジュール
対応頻度	毎時、毎日、毎週。	分単位（最短 10 分ごと、最長 45 分ごと）。 リモートアクションを 45 分ごとに実行するようスケジュールした場合、実行時刻は毎時 00 分と 45 分に固定されます。 たとえば、アクションは 00:00、00:45、01:00、01:45 などに実行されます。
スケジュールの上限	最大 100 個のリモートアクションをスケジュールできます。	頻度が 1 時間未満のリモートアクションを最大 10 個スケジュールできます。
トリガーとの互換性	他のトリガーと互換性があります。	手動または API トリガーとは互換性がありません。
対応プラットフォーム	Windows および macOS	Windows
実行時間	トリガー時刻から次回の反復までの実行時間: デバイスがスケジュール時刻より後にアクティブになった場合でも、有効期間内であればシステムはリモートアクションを実行します。	ローカル時刻に基づく正確なタイミング: 実行中にデバイスの電源がオフの場合、システムは実行をスキップします。
ターゲティングとスケジュールの変更	リモートアクションの評価ごとに、調査で返されたすべてのデバイスをシステムが直ちに実行します。	デバイスは、リモートアクションの作成時または更新時にスケジュールを受信します。 調査は 1 時間ごとに実行されます。 デバイス上のスケジュールの削除が有効になるまで、最大 90 分かかる場合があります。
モニタリング	進行中 および デバイス待機中 の情報を含む実行の詳細は、remote_action.executions で確認できます。 これには、リモートアクションダッシュボードでの可視性も含まれます。	完了した実行、成功、および失敗は、remote_action.executions で確認できます。 これには、リモートアクションダッシュボードでの可視性も含まれます。 スケジュール状態の実行は、remote_action.local_schedules で確認できます。 詳細については、ローカルスケジュールされたリモートアクションのモニタリングセクションを参照してください。
エラー報告	実行の失敗は常に報告されます。	特定のデバイスで 10 回連続して実行が失敗した場合、実行の失敗は 12 時間報告されなくなり、この状態に達したことを示す特別なステータスメッセージが表示されます。 デバイスは引き続きスクリプトを実行し、遅延時間が終了したとき、実行が成功したと記録されたとき、Collector が再起動されたとき、またはリモートアクションの設定が変更されたときに、報告を再開します。 注: これは Collector バージョン 24.8.2 以降に適用されます。
対話型ユーザーコンテキストのスクリプト	対話型ユーザーコンテキストのスクリプトは、対話型ユーザーセッションがない場合、実行を失敗状態として報告します。	対話型ユーザーコンテキストのスクリプトは、対話型ユーザーセッションがない場合、実行もエラー報告も行いません。 （Collector バージョン 24.8.2 以降に適用）

すべての Collector エージェントを 24.4 以降に更新した後は、ローカルスケジュールされたリモートアクションを使用することを Nexthink は推奨します。 ローカルスケジュールされたリモートアクションを実行できるのは、Collector バージョン 24.4 以降のデバイスのみです。

リモートアクションのスケジュールを 中央スケジュール から ローカルスケジュール に、またはその逆に変更する場合は、最初に既存のスケジュールを削除し、スケジュールタイプを変更した後に新しいスケジュールを作成してください。

スケジュール設定時の考慮事項

リモートアクションをローカルまたは中央でスケジュールする際に、デバイスターゲット、スケジュール、および入力パラメーター値がそれぞれ異なる、最大10件のスケジュールを作成できます。 リモートアクションごとに複数のスケジュールを使用して、次のことができます：

• 異なるスケジュールで異なるデバイスをターゲットにする（例: デバイスの場所に応じて異なる時刻にスケジュールする必要がある毎日のリモートアクションや、重要なデバイスではより頻繁に実行する必要があるリモートアクション）
• 異なるデバイスで異なるパラメーターを使用してリモートアクションを実行する

複数のスケジュールを使用する場合、各スケジュールが個別に評価されることに注意してください。 異なるスケジュールの調査で同じデバイスが返された場合、デバイスごとに複数の実行が作成されます。

スケジュールで使用する NQL クエリに関する考慮事項

リモートアクションが関連するデバイスのみをターゲットにする NQL クエリを使用してください。 この方法により、保留中の実行数を最小限に抑え、デバイスがリモートアクションの目的に関する条件を満たさないことによる不要な実行を回避できます。

以下の表に、クエリに含める条件の例を示します。

条件の種類	説明	例
プラットフォームとオペレーティングシステム	リモートアクションが特定のプラットフォーム（Windows または macOS）、あるいは特定のバージョンのオペレーティングシステムにのみ適用されるかどうかを検討してください。 ローカルスケジュールされたリモートアクションでは、現在 Windows エンドポイントのみをサポートしているため、必ずプラットフォームの条件を指定してください。	Windows スクリプト：
デバイスタイプ	リモートアクションの対象が仮想、物理、またはラップトップデバイスのどれであるかを検討してください。	物理デバイス：
オンラインデバイスとアクティブなユーザーセッション	最近オンラインになったデバイスのみが考慮される条件を必ず含めてください。 これは、毎日またはそれより低い頻度でスケジュールされるリモートアクションで特に重要です。 ユーザーコンテキストで実行されるリモートアクションでは、最近ユーザーセッションのアクティビティがあったデバイスのみを考慮してください。	毎時スケジュールされたリモートアクションは、過去 60 分間にアクティビティを報告したデバイスに限定してください。
インストール済みソフトウェアパッケージ	リモートアクションに、デバイスへの特定のソフトウェアパッケージのインストールが必要かどうかを検討してください。	Microsoft Teams の問題を修復するリモートアクションは、Microsoft Teams がインストールされているデバイスに限定してください。

推奨されないクエリの例:

このクエリでは、最近のデバイスアクティビティや、プラットフォーム、ハードウェアタイプ、オペレーティングシステム、ソフトウェアなどの技術的な依存関係に基づいてデバイスを除外しないため、複数の実行がタイムアウトしたり失敗に終わったりする可能性があります。

devices
| where entity == "ABC"

前述の推奨事項に従ったクエリの例:

営業チーム専用の重要な業務アプリケーションを使用する Virtual Desktop Infrastructure（VDI）ユーザーで発生した問題を修復するための、1 時間ごとに実行することを目的とした次のリモートアクションについて考えます。

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"

このクエリには、修復が関連するデバイスに一致する正確な条件が含まれているため、依存関係の欠落によりエラーが発生したり、影響なしと報告されたりする実行が少なくなります。 また、このクエリは、該当する部門の対話型ユーザーが最近アクティブだった仮想デバイスに限定されるため、関連性のないタイムアウトが少なくなります。

ローカルスケジュールされたリモートアクションのモニタリング

ローカルスケジュールされたリモートアクションは、通常の remote_action.executions テーブルを使用して結果をプラットフォームに報告します。 中央スケジュールおよびオンデマンドの実行とは異なり、request_id は実行ごとに一意ではありません。 request_id は、同じデバイス上の同じスケジュールに対応するすべての実行で同じです。

各デバイスのスケジュール設定のステータスをモニタリングするには、remote_action.local_schedules を使用します。 これにより、すべてのデバイスに作成されたローカルスケジュール、その現在の状態、および保留中のアクションの詳細な概要が返されます。

詳細については、以下の表を参照してください。

スケジュールのステータス	説明	可能な保留中のアクション
デバイス待機中	スケジュール設定は、デバイスがオンラインになるのを待機しています。	設定 - システムはデバイス設定が成功するのを待機しています。
設定中	スケジュール設定がデバイスに送信され、デバイスからの応答を待機しています。	設定 - システムはデバイス設定が成功するのを待機しています。
アクティブ	スケジュール設定は成功しました。 ローカルスケジュールされたリモートアクションが現在デバイス上で実行されています。	なし: 保留中の変更はありません。 設定: 再設定が保留中です。 スケジュールを削除: スケジュールは無効になっており、システムはデバイスを削除します。
削除されました	スケジュール設定は正常に削除され、現在のスケジュールではデバイス上でローカルスケジュールされたリモートアクションは実行されません。	なし: 保留中の変更はありません。
失敗しました	デバイス上のスケジュール設定は、技術的な理由により失敗しました。 失敗の例: Collector のバージョンがローカルスケジュールされたリモートアクションをサポートしていません。 macOS などのデバイスプラットフォームでは、ローカルスケジュールされたリモートアクションはサポートされていません。 スケジュール作成時のその他の技術的な失敗。	設定: システムはデバイスの再設定を試行する場合があります。

以下の NQL クエリを使用して、特定のリモートアクションについて各設定状態にあるデバイス数を特定します。

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