分（最低10分毎、最大45分毎）。
リモートアクションを45分ごとに実行するようにスケジュールした場合、実行時間は毎時0分と45分に固定されます。
例えば、アクションは00:00、00:45、01:00、01:45、などの時間で実行されます。
| | スケジューリング制限 | 最大100個のリモートアクションをスケジュール可能。 | 1時間未満の頻度で、最大10個のリモートアクションをスケジュール可能。 | | トリガーと互換性あり | 他のトリガーと互換性あり。 | 手動トリガーまたはAPIトリガーとは互換性なし。 | | 対応プラットフォーム | WindowsおよびmacOS | Windows | | 実行時間 | トリガー時間と次のイテレーションとの間の実行時間：デバイスがスケジュールされた時間後にアクティブ化された場合、システムはリモートアクションがまだ有効である限り実行します。 | ローカル時間に基づいた正確なタイミング：デバイスが実行中にオフになっている場合、システムは実行をスキップします。 | | ターゲティングとスケジューリングの変更 | リモートアクションの評価ごとに、システムは調査によって返されたすべてのデバイスを即座に実行します。 |デバイスはリモートアクションを作成または更新する際にスケジュールを受け取ります。 調査は1時間ごとに行われます。
デバイス上のスケジュールを削除するには、最大90分かかる場合があります。
完了した実行、成功および失敗はremote\_action.executionsで利用可能です。 これにはリモートアクションダッシュボードでの可視性が含まれます。
スケジューリング状態の実行はremote\_action.local\_schedulesで利用可能です。
詳細については、ローカルスケジュールされたリモートアクションのモニタリングセクションを参照してください。
特定のデバイスで10回連続して実行に失敗した場合、12時間は実行の失敗が報告されず、この状態に達したことを示す特別なステータスメッセージが表示されます。
デバイスは、遅延が終了し、スクリプトの正常な実行が記録されるか、コレクタが再起動されるか、リモートアクション設定が変更されると、スクリプトの実行を継続し、報告を再開します。
注意: これはコレクタバージョン24.8.2以降に適用されます。
| | インタラクティブユーザーコンテキストでのスクリプト | インタラクティブユーザーコンテキストでのスクリプトは、インタラクティブユーザーセッションがない場合、実行が失敗状態で報告されます。 | インタラクティブユーザーセッションがない場合、インタラクティブユーザーコンテキストでのスクリプトは実行もエラー報告もしません。 (Collectorバージョン24.8.2以降に適用) | {% hint style="info" %} Nexthinkは、すべてのCollectorエージェントが24.4以降に更新された後にローカルにスケジュールされたRemote Actionsを推奨しています。 Collectorバージョン24.4以降のデバイスのみがローカルでスケジュールされたリモートアクションを実行します。 {% endhint %} リモートアクションのスケジューリングを**中央集約スケジュール**から**ローカルスケジュール**またはその逆に変更したい場合は、最初の既存のスケジュールを削除し、スケジュールタイプを変更した後に新しいスケジュールを再作成してください。 ### スケジュール設定時の考慮事項 リモートアクションをスケジュールする際、ローカルまたは中央集約のどちらかで、リモートアクションに対して最大10のスケジュールを作成でき、各スケジュールには個別のデバイスターゲット、スケジュール設定、および入力パラメーター値を持たせることができます。 リモートアクションごとに複数のスケジュールを使用して、 * 異なるデバイスを異なるスケジュールでターゲットする（たとえば、デバイスの場所に応じて異なる時間にスケジュールされるべき日次のリモートアクションや、重要なデバイスでより頻繁に実行されるべきリモートアクション） * 異なるデバイスで異なるパラメータでリモートアクションを実行する 複数のスケジュールを使用する場合、各スケジュールは個別に評価されることに注意してください。 異なるスケジュールでの調査が同じデバイスを返す場合、そのデバイスごとにいくつかの実行が作成されます。 #### スケジュールで使用するNQLクエリに関する考慮点 リモートアクションが関連のあるデバイスのみをターゲットにするNQLクエリを使用してください。 このアプローチにより、保留中の実行の数を最小限に抑え、デバイスがリモートアクションの意図の基準を満たさないために不必要な実行を避けることができます。 クエリに含めるための条件例を下の表で提供しています。 | **条件の種類** | **説明** | **例** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | プラットフォームとオペレーティングシステム |リモートアクションが特定のプラットフォーム、WindowsまたはmacOS、あるいは特定のバージョンのオペレーティングシステムにのみ適用されるかどうかを考慮してください。
ローカルでスケジュールされたリモートアクションの場合、現在はWindowsエンドポイントのみをサポートするため、必ずプラットフォームに関する条件を指定してください。
| Windowsスクリプト： | | デバイスタイプ | リモートアクションが仮想、物理、またはラップトップデバイスをターゲットにするかどうかを考慮してください。 | 物理デバイス： | | オンラインデバイスとアクティブユーザーセッション |最近オンラインのデバイスのみを考慮する条件を常に含めてください。 これは、毎日の頻度でスケジュールされたリモートアクションや、少ない頻度でスケジュールされたリモートアクションの場合に特に重要です。
ユーザーコンテキストで実行されるリモートアクションのために、最近のユーザーセッション活動のあるデバイスのみを考慮してください。
| 過去60分以内にアクティビティを報告したデバイスで、毎時実行されるリモートアクションを制限します。 | | インストール済みのソフトウェアパッケージ | リモートアクションがデバイスに特定のソフトウェアパッケージのインストールを必要とするかどうかを考慮してください。 | Microsoft Teamsの問題の修正のためのリモートアクションを、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`を使用します。 これにより、すべてのデバイス上で作成されたローカルスケジュールの詳細な概要、その現在の状態、および保留中のアクションが戻されます。 詳細については、以下の表を参照してください。 | スケジュール状態 | 説明 | 保留中の可能性のあるアクション | | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | デバイス待ち | スケジュール設定はデバイスがオンラインになるのを待っています。 | 構成 - システムはデバイスの設定が成功するのを待っています。 | | 設定中 | スケジュール設定はデバイスに送信され、デバイスの応答を待っています。 | 設定 - システムはデバイス構成が成功するのを待っています。 | | 有効 | スケジュール設定は成功しました。 ローカルでスケジュールされたリモートアクションは現在デバイス上で実行中です。 |なし: 保留中の変更なし。
設定: 再設定が保留中。
スケジュールを削除: スケジュールはもはや有効ではなく、システムはデバイスを削除します。
| | 削除済み | スケジュール設定は正常に削除され、現在のスケジュールはデバイスでローカルでスケジュールされたリモートアクションを実行しません。 | なし: 保留中の変更なし。 | | 失敗 |技術的な理由でデバイスでのスケジュール設定が失敗しました。
失敗の例: