リモートアクションのスケジューリング

リモートアクションモジュールでは、各特定の使用ケースに最適な頻度で、リモートアクションをスケジュールして修復やデータ収集のニーズを満たすことができます。

リモートアクションのスケジューリング

使用ケースに最も適したスケジュールタイプを選択してください。

スケジュールオプション	中央でスケジュール	ローカルでスケジュール
対応している頻度	毎時、毎日、毎週。	分（最低10分ごとから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以降に適用)

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

リモートアクションのスケジューリングを「中央でスケジュール」から「ローカルでスケジュール」に、またはその反対に調整したい場合、最初に既存のスケジュールを削除し、スケジュールタイプを変更した後に新しいスケジュールを再作成することを確認してください。

構成スケジュールの考慮点

リモートアクションをスケジュールする際、ローカルでも中央でも、1つ以上のスケジュール（最大10個）をそのリモートアクション用に作成でき、それぞれのデバイスターゲット、スケジューリング、および入力パラメーター値を持たせることができます。 リモートアクションごとに複数のスケジュールを使用して、

• 異なるデバイスを異なるスケジュールでターゲットする（たとえば、デバイスの場所に応じて異なる時間にスケジュールされるべき日次のリモートアクションや、重要なデバイスでより頻繁に実行されるべきリモートアクション）

• 異なるデバイスで異なるパラメータでリモートアクションを実行する

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

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

リモートアクションが関連のあるデバイスのみをターゲットにするNQLクエリを使用してください。 このアプローチにより、保留中の実行の数を最小限に抑え、デバイスがリモートアクションの意図の基準を満たさないために不必要な実行を避けることができます。

クエリに含めるための条件例を下の表で提供しています。

条件の種類	説明	例
プラットフォームとオペレーティングシステム	リモートアクションが特定のプラットフォーム、WindowsまたはmacOS、あるいは特定のバージョンのオペレーティングシステムにのみ適用されるかどうかを考慮してください。 ローカルでスケジュールされたリモートアクションの場合、現在はWindowsエンドポイントのみをサポートするため、必ずプラットフォームに関する条件を指定してください。	Windowsスクリプト:	where operating_system.platform == windows Windows 11スクリプト:	where operating_system.platform == windows and operating_system.name == "Windows 11*"
デバイスタイプ	リモートアクションが仮想、物理、またはラップトップデバイスをターゲットにするかどうかを考慮してください。	物理デバイス:	where hardware.type != virtual ラップトップデバイス:	where hardware.type == laptop
オンラインデバイスとアクティブユーザーセッション	最近オンラインのデバイスのみを考慮する条件を常に含めてください。 これは、毎日の頻度でスケジュールされたリモートアクションや、少ない頻度でスケジュールされたリモートアクションの場合に特に重要です。 ユーザーコンテキストで実行されるリモートアクションのために、最近のユーザーセッション活動のあるデバイスのみを考慮してください。	毎時スケジュールされたリモートアクションを、過去60分以内に活動を報告しているデバイスに限定します。	with execution.events past 60min 現在ログインしているユーザーのための毎時スケジュールされたリモートアクションを、過去60分内にアクティブなユーザーがいるデバイスに限定します。	with session.events past 60min
インストール済みのソフトウェアパッケージ	リモートアクションがデバイスに特定のソフトウェアパッケージのインストールを必要とするかどうかを考慮してください。	Microsoft Teamsの問題の修正のためのリモートアクションを、Microsoft Teamsがインストールされているデバイスに限定します。	with package.installed_packages	where package.name == "Microsoft Teams*"

非推奨のクエリの例:

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

devices
| where entity == "ABC"

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

次のリモートアクションを考慮してください。営業チーム専用の重要なビジネスアプリケーションを使用する仮想デスクトップインフラストラクチャ（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