MSPsが複数のクライアント環境を管理する場合、各エンドポイントに適切にパッチを適用し続けることは難しい場合があります。パッチ適用ポリシーは、パッチ管理を拡張し、定期的な設定を自動化するのに役立ちますが、ディスク容量不足、サービス停止、デバイスのオフライン化などの障害によって、プロセスが複雑になることがあります。
自動化スクリプトを使えば、MSPsは設定の失敗につながる前に、こうした状態の多くを検出して対処できます。自動化スクリプトを使うことで、MSPsはエンドポイントの準備、結果の検証、失敗時の修復、必要に応じた問題のエスカレーションを行い、パッチの設定をより簡単に管理できます。これによりパッチポリシーを補完し、パッチ管理プロセスを改善して、更新プログラムが適切に展開されるよう支援します。
それを踏まえて、automation scripts がパッチ管理をどのように改善し、設定前・設定中・設定後のどの場面で最も価値を発揮するのかを見ていきましょう。
パッチ設定において自動化スクリプトはどのような役割を果たしますか？
自動化スクリプトは、承認、スケジュール、再起動ルールなどの日常的なアクティビティを管理するパッチ自動化ポリシーとは異なります。自動化スクリプトは、通常のパッチポリシーの範囲外となる可能性がある、エンドポイント固有のチェック、検証、修復、例外対応など、より複雑な問題に対応します。
スクリプトでは、次のような複数のタスクを管理できます。
エンドポイントがパッチのインストール準備完了かどうかを確認します。
パッチを設定する前のデバイス準備。
アップデートが正常にインストールされたことを確認しています。
パッチの失敗を引き起こす一般的な問題を修正します。
定義された制限内で失敗したアクションを再試行しています。
診断情報を収集中です。
未解決の問題を技術者にエスカレーションすること。
ターゲットを絞った準備状況チェック、検証、例外処理にスクリプトを使用すると、パッチポリシーを定常的な設定に集中させやすくなります。
MSPsはパッチ設定前にスクリプトをどのように活用できるのでしょうか？
ここまでを踏まえて、MSPsがスクリプトを活用してパッチ管理と設定をどのように改善できるかを見ていきましょう。設定前スクリプトは、MSPsがパッチの設定に影響する可能性のある条件を特定し、それらに対処するのに役立ちます。たとえば、次のようなものがあります。
1. 利用可能なディスク容量を確認
パッチを設定できない原因が、空き容量の不足だけという場合もあります。スクリプトは、パッチ設定前に利用可能なストレージを定義済みのしきい値と比較し、パッチに十分なディスク容量があることを確認できます。利用可能な空き容量がしきい値を下回った場合、そのエンドポイントを設定対象から除外したり、承認済みのクリーンアップワークフローに回したり、技術者による確認が必要であることを示したりできます。
スクリプトで容量を確保するために、ファイルを無差別に削除しないよう注意してください。適切な監視と承認がなければ、重要なものを削除してしまうリスクが常にあります。
2. 保留中の再起動を検出
エンドポイントは、アップデート、アプリケーションのインストール、またはシステム変更の後に、再起動待ちの状態のままになることがあります。スクリプトは、アップデートのインストール後やシステム変更後に再起動が必要なエンドポイントを特定するのに役立ちます。
MSPs は、承認されたメンテナンス時間内に再起動アクションをスケジュールしたり、定義された条件のもとで再起動を開始するスクリプトを実行したりできます。これにより、通常のワークフローを中断することなく、更新プログラムを適切にインストールできます。
3. 必要なサービスを確認
スクリプトは、OS更新サービスやその他の必要なツールが正常に実行されていることを確認するのにも役立ちます。たとえば、サービスが停止している場合やエラーメッセージを返す場合、スクリプトでサービスの再起動を試みたり、問題を技術者にエスカレーションしたりできるため、更新が展開される前に問題へ対処できます。
4. パッチの前提条件を確認する
パッチのインストール前に満たす必要がある前提条件がある場合があります。たとえば、特定のOSバージョン、依存フレームワーク、必要なプロセス、承認された更新元への接続などです。スクリプトでこれらの前提条件を確認し、明確な結果を返せるため、前提条件を満たしていないエンドポイントは対応したり除外したりできます。
5. 競合するアプリケーションを閉じるか停止する
場合によっては、開いているアプリケーションや実行中のプロセスが、更新プログラムの開始や完了を妨げることがあります。このような場合、スクリプトでこうした問題を検出し、ユーザーに通知したり、メンテナンス期間中に停止したりすることで、更新プログラムを完了できます。
まずユーザーが作業内容を保存できるようにしないまま、アプリケーションを閉じるべきではないことを忘れないでください。予期しない再起動によって何時間分もの作業が失われることほど、ストレスのたまることはそう多くありません。
MSPsはクライアントのエンドポイントグループ全体でどのようにスクリプトを実行できるのでしょうか？
MSPsがさまざまなクライアントのエンドポイントでスクリプトを実行したい場合、各エンドポイントに手動で接続しなくてもスクリプトを実行できる、一元管理された制御機能が必要です。再利用可能なスクリプトは、変数、しきい値、スケジュール、除外設定などを含め、個別のニーズに合わせてカスタマイズしながら、クライアント全体で標準化できます。
スクリプトは、次のようなさまざまなグループやニーズを対象にできます。
クライアント
サイトまたは拠点
オペレーティングシステム
デバイスの役割
部門
メンテナンスウィンドウ
実際、すべてのクライアントとデバイスが必要なサポートを受けられるようにするには、カスタマイズされたターゲット型スクリプトを実行できることが不可欠です。標準的な従業員用ノートPCでスクリプトが動作しても、サーバー、キオスク、その他の業務上重要なデバイスでも同じように動作するとは限らないため、適切なスクリプトのターゲティングが重要です。
スクリプトはパッチが正常にインストールされたことをどのように確認できるのでしょうか？
パッチ管理で重要でありながら見落とされがちな点の1つが、インストールの確認です。自動設定コマンドでインストールを開始することはできますが、エンドポイントが意図したパッチ適用状態に達したことまでは確認できません。インストールの適切な証明がなければ、パッチの適用失敗が気づかれないままになることがよくあります。
自動化スクリプトを使うと、次のようないくつかの方法でパッチのインストールを確認できます。
1. オペレーティングシステムのパッチステータスを確認
スクリプトを使うと、インストールされたアップデート識別子、アップデート履歴、オペレーティングシステムのビルド番号、最後に正常にインストールされた日付、再起動のステータスなどの重要な詳細を確認できます。これは、パッチが正しくインストールされている場合にあるべき状態とエンドポイントの現在の状態を比較するシンプルなチェックで、インストールの確認を簡単に行えます。
2. アプリケーションのバージョンを確認
スクリプトでは、アプリケーション更新後にインストール済みソフトウェアを確認して、最新バージョンで実行されていることを確かめることもできます。これにより、MSPsは正常に完了したと報告されていても想定したバージョンに更新されていないインストールを特定し、確認して更新を完了できます。
3. 構造化された結果を返す
スクリプトはパッチのステータスを確認し、「成功」「再起動が必要」「手動確認が必要」や、理由を添えた失敗などの標準化された出力を提供できます。これはパッチを確認するための迅速で明確な方法です。デバイス、タイムスタンプ、簡潔なエラーメッセージが含まれるため、問題に迅速に対処できます。
4. 再起動後に再確認
多くのパッチは、エンドポイントが再起動するまで完全には検証できません。このような場合、エンドポイントの再起動後に、MSPsは検証スクリプトを実行またはスケジュールして、最終的なオペレーティングシステムのビルドやアプリケーションのバージョンを確認し、残っているエラーを報告できます。
スクリプトで一般的なパッチ障害をどのように修復できますか？
パッチが失敗した場合、スクリプトを使用して対処し、パッチを正しく再インストールすることもできます。これは予測可能でリスクの低い状況で最も効果を発揮しますが、スクリプトは異常な障害や影響の大きい障害を技術者に送信することもできるため、必要に応じて手動で調査できます。
1. 失敗した更新サービスを再起動する
更新を完了するためにサービスの再起動が必要な場合は、自動化スクリプトで対応できます。スクリプトは、更新に関連するサービスのステータスを確認し、安全に実行できるタイミングで再起動するよう設定できます。これにより、停止したサービスが失敗の原因である場合でも、インストールを続行できます。サービス障害が繰り返し発生する場合は、それらをログに記録してエスカレーションする必要があります。そのため、スクリプトにはエスカレーション前の再起動回数の上限も含める必要があります。
2. 一時的な更新状態を修復
自動化スクリプトには、アップデートが失敗した場合に備えて、停止したアップデートコンポーネントのリセット、一時的なアップデートデータの削除、既知の前提条件の修復など、承認済みの修復アクションを含めることができます。これにより、アップデートのトラブルシューティングと再試行を自動化できます。修復スクリプトは、対象を限定し、テストと承認を行い、既知の条件にのみ限定する必要があります。破壊的なアクションは、技術者による確認を必須にする必要があります。
3. 失敗したパッチインストールを再試行
インストールが失敗した場合は、問題が解決された後に再試行するようスクリプトを設定できます。これにより、予測可能な失敗への対応を自動化し、技術者の介入が必要なエンドポイントの数を減らせます。ただし、再試行は最大試行回数を設定し、試行間に遅延を設け、各失敗の理由を記録するよう設定する必要があります。これにより、必要に応じて技術者にエスカレーションできます。
4. 必要な再起動を実行
更新プログラムを完全にインストールする前に再起動が必要な場合、スクリプトはクライアントのポリシーに従って再起動をスケジュールし、開始できます。これにより、計画されたメンテナンス時間帯に再起動をスケジュールし、さらに再起動によって重要な作業が失われないようにするためのわかりやすいユーザー通知をあわせて行うことで、日常業務を中断することなく更新プログラムが適切にインストールされるようにできます。
5. 技術者による確認のためにログを収集する
スクリプトは、ログ、更新履歴、システム情報、失敗コードなどの情報を収集するためにも使用できます。その後、更新対応を技術者にエスカレーションする必要がある場合も、必要な情報はすぐに利用できます。これにより、技術者が基本的な診断情報の収集に費やす時間を削減し、必要な情報を1か所で提供することで効率を向上できます。
パッチ自動化はどのような場合に停止し、技術者にエスカレーションすべきですか？
パッチの自動化は、エンドポイントを最新の状態に保ち、安全性を確保するための有用なツールですが、技術者が介入する必要がある場面もあります。特に、問題の解決に技術者の専門知識や調査が必要な場合は、自動化に任せず技術者が対応すべき状況が数多くあります。
こうした状況には、次のようなものがあります。
許可された再試行回数を超えても同じパッチが失敗する
必要なサービスを復元できない
エンドポイントが繰り返し一貫性のない結果を返す
業務上重要なアプリケーションに影響が出ている
サーバーまたは特殊なデバイスで確認が必要
パッチによって、予期しないアプリケーションまたはシステムの動作が発生する
スクリプトで不明なエラーが発生する
このエンドポイントは承認済みの設定構成の対象外です
修復には破壊的または高リスクな変更が必要になる
こうしたいずれの場合でも、ITチームに通知して対応できるようにする必要があります。技術者が効率的に問題を診断して解決できるように、アラートにはクライアント、エンドポイント、スクリプトのバージョン、パッチ、試行したアクション、結果、および推奨される次のステップを含めるようにしてください。
覚えておきたいのは、自動化の目的は反復作業を減らすことであり、未解決の問題をうやむやにすることではないという点です。スクリプトで解決できない問題が発生した場合は、ITチームが対応できるよう準備しておく必要があります。
MSPsはパッチ自動化スクリプトをどのように安全に標準化すべきですか？
パッチ自動化スクリプトは、パッチの設定とトラブルシューティングの両方に使える、強力で柔軟なツールです。ただし、適切に設計する必要があります。パッチ自動化スクリプトを作成する際に押さえておきたい重要な手順は、次のとおりです。
スクリプトごとに目的を1つに絞る: 1つのスクリプトですべてに対応する理由はありません。実施可能かつ実用的である限り、準備状況のチェック、修復、検証、レポート作成などのタスクはそれぞれ分けるべきです。
管理された環境でテストする: スクリプトをデバイス全体に展開する前に、テストして意図したとおりに動作していることを確認することが重要です。本番環境のエンドポイント全体で使用する前に、代表的なデバイスグループでスクリプトを必ず検証してください。
パイロットエンドポイントグループを使用: スクリプトを展開する際は、すべてのデバイスに一度に設定したくはありません。クライアント環境全体に広げる前に、まずは限定された設定グループから始めることで、予期しない問題を早期に発見して対処できます。
バージョン管理を維持する: スクリプトと、それに加えられた変更をしっかり管理することが重要です。各スクリプトについて、変更内容、オーナー、承認日、ロールバック用のバージョンを必ず記録してください。
明確な入力と変数を使用する: スクリプトは、わかりやすく、特定のクライアント向けに簡単に修正できるようにする必要があります。クライアント固有の設定、しきい値、メンテナンスウィンドウはメインのスクリプトロジックと分けておくことで、必要に応じて調整できるようになります。
資格情報と機密データを保護: スクリプト内を含め、あらゆる場所で機密データを安全に保つことが重要です。プレーンテキストのパスワード、アクセストークン、または機密性の高いクライアント情報をスクリプトに埋め込んではいけません。データ漏えいのリスクがあります。
タイムアウトと再試行回数の上限を設定する: スクリプトで失敗した更新を再試行できますが、無限ループにはまらせるべきではありません。スクリプトが無期限に実行されたり、修復処理のループを繰り返したりしないよう、必ず制限を設定してください。
ログと終了コードを記録: すべての実行は、追跡可能で内容を把握できる状態にしておく必要があります。これにより、監視性と説明責任の向上に役立つとともに、調査や元に戻す対応が必要になった場合に備えて明確な記録を提供できます。
スクリプトのアクセス許可を管理: 不正アクセスや未承認のスクリプトを防ぐため、スクリプトの作成、編集、承認、実行を行えるユーザーを必ず制限してください。
スクリプトライブラリを定期的に見直す: スクリプトは、意図したとおりに機能しなくなった場合、見直し、更新、または削除が必要になることがよくあります。ライブラリを確認し、古くなったスクリプトを廃止し、オペレーティングシステム、アプリケーション、またはクライアント要件が変わったときにワークフローを更新するようにしてください。
MSPsは、スクリプト支援によるパッチ適用の有効性をどのように測定できますか？
MSPsは、スクリプトによってパッチ適用の完了率が向上しているか、繰り返し発生する失敗が減っているか、不要な技術者の介入が抑えられているかを測定する必要があります。スクリプト支援によるパッチ適用の効果は、実行したスクリプト数だけでなく、成功と効率性を示す運用上の成果を通じて測定できます。
次の指標を必ず追跡してください。
パッチ成功率
初回インストール成功率
自動的に修復される障害の割合
技術者の介入が必要なエンドポイント数
失敗したパッチの平均解決時間
再起動待ちのエンドポイント
メンテナンス時間帯を繰り返し逃しているデバイス
スクリプトの失敗率とタイムアウト率
クライアントまたはエンドポイントグループによるパッチ完了
パッチ承認からインストール確認完了までの時間
MSPsがパッチ自動化スクリプトで避けるべきよくある間違い
スクリプト作成は複雑なプロセスになることがあるため、MSPsが自動化スクリプトを作成・使用する際によくあるミスがいくつかあります。スクリプトが意図したとおりに実行されるよう、これらのミスには十分注意してください。
よくあるミスには次のようなものがあります。
スクリプトを、集中管理されたパッチ適用ポリシーを補完・支援するツールではなく、その代替として使用すること。
すべてのクライアントでスクリプトをテストせずに実行し、クライアントごとにスクリプトをテストして調整しないこと。
同じスクリプトをすべてのエンドポイントタイプに適用すると、互換性のないデバイスやオペレーティングシステムでスクリプトが実行される可能性があります。
再試行回数を無制限にすると、対処されないままスクリプトが失敗と再試行の無限ループに陥る可能性があります。
スクリプトが実行されたことを、インストールを確認する代わりにパッチ成功の証拠と見なしてしまうこと。
オフラインのデバイスを考慮しないと、デバイスが重要な更新プログラムを受け取れない可能性があります。
スクリプトに資格情報を埋め込むと、サイバーセキュリティ上のリスクが生じます。
エラーをエスカレーションする代わりに抑制してしまうこと。
承認なしで高リスクの変更を行うこと。
スクリプトの所有者と変更履歴を文書化しないと、説明責任と管理性が低下します。
機能が重複する大規模なスクリプトライブラリを作成すると、管理が煩雑になり、冗長になりがちです。
クライアント固有のスケジュールや再起動要件を無視すること。
Splashtop AEMがスクリプト支援によるパッチ設定をどのようにサポートするか
スクリプト作成やパッチの設定は、難題である必要はなく、ましてや乗り越えられないものである必要はありません。Splashtop AEM（Autonomous Endpoint Management）を使用すると、MSPsはパッチの設定、管理対象エンドポイントグループ全体でのスクリプトの実行、エンドポイントステータスの確認、例外へのリモート対応をSplashtopコンソールから行えます。
Splashtop AEMでは、次のことが可能です。
1. オペレーティングシステムとサードパーティのパッチ適用を自動化
Splashtop AEM は、MSPs にパッチ自動化をもたらします。これにより、MSPs は、オペレーティングシステムやサードパーティアプリケーションを含む管理対象デバイス全体で、定期的なアップデートを自動化するポリシーを設定できます。これらのポリシーがパッチ適用プロセスの基盤となり、スクリプトは例外対応や追加チェックを支援することで、パッチ管理をさらに改善できます。
2. 複数のエンドポイントでスクリプトを実行
Splashtop AEMを使用すると、MSPsは選択したエンドポイントグループ全体でスクリプトをスケジュールし、実行できます。これにより、各デバイスを個別に接続する必要がなくなり、複数のデバイスを同時にサポートできるため、時間を節約し、効率を向上できます。スクリプトはバックグラウンドで実行することもできるため、ユーザーの作業を妨げることなく定期的なメンテナンスを行えます。
3. 実行結果とパッチ結果を確認する
デバイスとパッチのステータス情報を1か所に集約することで、Splashtop AEMは技術者がどのパッチが正常にインストールされたか、どこで失敗が発生したか、どのデバイスに追加の対応が必要かを特定するのに役立ちます。これにより、MSPsは結果を確認し、失敗に対応する必要があるタイミングを把握できるため、エンドポイント全体で適切なパッチ適用を確実にしやすくなります。
4. 残っている例外をリモートで解決
エンドポイントに追加の対応が必要な場合、MSPの技術者はSplashtopのリモートサポート機能を使ってデバイスにリモートアクセスし、トラブルシューティングを行えます。
手作業を増やさずにパッチ設定を改善
自動化スクリプトはパッチ設定を改善するための強力なツールですが、適切に使用する必要があります。スクリプトは、準備状況の確認、結果の検証、基本的な問題の修復など、管理されたパッチ適用ワークフロー内で特定の役割に使用すると最も効果的です。
スクリプトはパッチ設定で重要な役割を果たし、パッチ自動化やポリシーと連携してエンドポイントを最新の状態に保ちます。MSPsが明確な再試行ルールとエスカレーションルールを設定し、クライアントごとの管理を維持し、未解決の問題を技術者に振り分けることで、パッチ設定の一貫性、追跡性、管理のしやすさが向上します。
Splashtop AEM を使用すると、パッチ自動化はさらに効率的になります。MSPs は Splashtop AEM を使用して、パッチポリシーの設定、管理対象エンドポイントグループ全体でのスクリプトのスケジュールまたは実行、設定結果の監視、例外への対処を行えます。
Splashtop AEMがパッチ適用の自動化、エンドポイント全体でのスクリプト実行、パフォーマンス結果の監視をどのように実現するか、見てみませんか？今すぐ無料トライアルを始めましょう。
