ServiceDesk Plus Cloud ナレッジベース

ManageEngine > サポート > ServiceDesk Plus Cloud ナレッジベース > 活用Tips > 【実例】Network Configuration Managerとの連携による、コンフィグバックアップ失敗時、コマンド投入時のリクエスト管理
戻る

【実例】Network Configuration Managerとの連携による、コンフィグバックアップ失敗時、コマンド投入時のリクエスト管理

  • 作成日：2026年1月19日 | 更新日：2026年2月27日

概要

ServiceDesk Plus Cloud（以下SDPC）とManageEngineが提供するネットワーク機器コンフィグ管理ツール「Network Configuration Manager（以下NCM）」を連携することで、NCMで発生した以下のイベントをSDPCのリクエストとして起票し、インシデント管理を行うことができます。

  • コンフィグバックアップの失敗
  • コマンド投入の承認依頼

本ナレッジではSDPCにリクエスト起票されるNCMのイベントと、SDPCでのリクエスト起票～対応までの一連の対応イメージを記載します。

    • SDPCはEnterprise Editionである必要があります。
    • NCMのEdition制限はありません。
    • NCMと連携できるSDPCのインスタンスは1つのみです。

参考：SDPCのライセンス情報の確認方法、SDPCのEdition比較ページ

目次

  1. NCMとの連携で実現できること
  2. SDPCに起票されるリクエスト内容（件名、説明）
  3. 【実例】NCMとSDPCを連携する際の事前準備
  4. 連携方法
  5. 【実例】リクエスト対応の流れ
    1. コンフィグバックアップ失敗
    2. コマンド投入の承認依頼

NCMとの連携で実現できること

SDPCとNCMを連携することで、NCMで発生した以下のイベントに対して、SDPCのリクエストとして起票します。
これによりNCMのインシデント（コンフィグバックアップ失敗）や承認依頼をSDPCで一元的に管理できます。

「コマンド投入の承認依頼」は、NCMにログインしているユーザーがコマンド投入の操作を実行した際、NCMの管理者ユーザーによる承認が必要な場合に発生します。NCMにデフォルトで実装されている「オペレーター」権限のユーザーや、「ロール」機能で読み取り権限のみが付与されたユーザーによるコマンド投入操作が該当します。
※デフォルトで利用できるNCMのユーザーアカウント数は2つです。それを超えるユーザーアカウントが必要な場合はオプションとして追加する必要があります（NCMの価格ページ）。

・コンフィグレットの実行：「ロール」機能で「装置管理」に書き込み権限を付与すると、SDPCには起票されません。
・コンフィグのアップロード：「ロール」機能で「コンフィグ自動化」に書き込み権限を付与すると、SDPCには起票されません。
参考：NCMのユーザー権限の詳細

SDPCに起票されるリクエスト内容（件名、説明）

NCMで各イベントが発生すると、SDPCには以下の件名と説明でリクエストが起票されます。

起票されるリクエストの依頼者は、「ServiceDesk Plus Cloudとの連携」マニュアルの手順4に記載のSDPCのアカウント名（表示名）です。
依頼者情報を変更する場合は、リクエストを開き画面上部の［編集］から「依頼者」を変更します。表示されている依頼者を削除することで、別の依頼者を選択できるようになります。

コンフィグバックアップの失敗

リクエストの件名
<コンフィグバックアップが失敗した装置のIPアドレス>_NCM_Backup_Failure

説明
Device Configuration Backup failed for <コンフィグバックアップが失敗した装置の表示名> at <イベント発生日時>

  • 同じ装置でコンフィグバックアップが失敗すると、2回目以降のイベントは同じリクエスト内にメモとして追加されます。
  • 「説明」の内容は、NCMのアラート画面で表示されるメッセージと同じです。

コンフィグレットの実行

リクエストの件名
Custom Template Upload

説明
Requesting Custom Template Upload for <コンフィグレットの実行対象装置の表示名>, . Visit here https://<NCMをインストールしているサーバーのIPアドレス:ポート番号>/apiclient/ember/index.jsp#/NCMChangeManagement/PendingRequests

同じ装置にコンフィグレット実行の承認依頼を複数回行った場合、別のリクエストとして新たに起票されます。

コンフィグのアップロード

リクエストの件名
Version Upload

説明
Requesting Version Upload for <コンフィグのアップロード対象装置の表示名>, . Visit here https://<NCMをインストールしているサーバーのIPアドレス:ポート番号>/apiclient/ember/index.jsp#/NCMChangeManagement/PendingRequests

同じ装置にコンフィグのアップロードの承認依頼を複数回行った場合、別のリクエストとして新たに起票されます。

【実例】NCMとSDPCを連携するための事前準備

事前準備

NCM側の事前準備
  • SDPCでリクエスト対応する技術担当者の社員に、NCMの管理者権限のユーザーアカウントを付与する
SDPC側の事前準備

件名や説明の内容をもとに、リクエストテンプレートや業務ルールなどの自動化設定を行います。
以下は、「コンフィグバックアップに失敗した場合」を想定した設定例です。

  • NCM関連のリクエストを対応する専用の「技術担当者グループ」を作成
    技術担当者グループの設定マニュアル

    • リクエスト起票時にグループメンバーに通知する場合、［管理］→［自動化］→［通知ルール］で、「新規リクエストがグループに追加されたとき、グループメンバーに通知」にチェックが入っていることを確認します。
      通知ルールのマニュアル
    • 「技術担当者グループ」の作成または編集画面で、「新規リクエストがグループに追加されたときグループの技術担当者に通知」をチェックし、通知対象の技術担当者を選択します。
      グループメンバーに通知する場合は、上記の通知ルールとあわせてこちらの設定が必要です。
  • NCM専用の「リクエストテンプレート」を作成
    作成した技術担当者グループへの割り当てやリクエストの対応優先度などのフィールドを事前に定義し、技術担当者向けの対応方針を記載します。
    リクエストテンプレートの作成マニュアル

    • 優先度、緊急度、カテゴリー、技術担当者グループなど、各フィールドを設定します。
    • 一次対応する技術担当者が決まっている場合は、「技術担当者」フィールドも指定します。
    • 「Resolution」欄に、コンフィグバックアップが失敗した際に対応するトラブルシューティングの手順を記載します。

      ＜記入例＞

      Network Configuration Managerでコンフィグバックアップに失敗しました。
      <Network Configuration ManagerにアクセスするURL>
      以下の内容を確認してみてください。
      1. NCMにログインして、［ツール］→［pingツール］→［ping］で対象装置のIPアドレスを入力して、Pingが通るか確認します。
        1. Pingが通る場合、次のステップに進みます。
        2. Pingが通らない場合、実機の電源が切れていないか、ケーブルが抜けていないか物理層の確認を行ってください。
      2. NCMの［インベントリ］→［装置］で対象装置の認証アイコンをクリックし、認証情報を再度入力の上、［保存とテスト］を実行します。
        認証情報の有効性を確認します。

        1. 認証に成功する場合、次のステップに進みます。
        2. 認証に失敗する場合、TeraTermやコンソールで直接接続できるか確認してください。
          1. 接続に成功する場合、NCMで設定している認証情報に誤りがある可能性があります。パスワードやプロンプト情報が正しいか確認します。
          2. 接続に失敗する場合、パスワードの初期化方法や今後の対応手順をベンダーに確認してください。
      3. コンフィグバックアップを実行し、成功するか確認します。
        1. 成功する場合、対応は以上です。今後の経過を確認してください。
        2. コンフィグバックアップに失敗する場合、ネットワークの瞬断などがないか確認してください。
          ネットワークに問題ない場合、ゾーホージャパンのサポートに問い合わせてください。
          https://www.manageengine.jp/support/

  • リクエストが起票された後、作成したリクエストテンプレートに自動で切り替えるための業務ルールを作成
    業務ルールのマニュアル

    • 条件のセクションで、「件名、が～を含む、NCM_Backup_Failure」を設定します。
    • アクションで「フィールドを更新」を選択し、「テンプレート」「<作成したリクエストテンプレート名>」を設定します。
    • 「リクエスト の値を業務ルールの値で上書きする」にチェックを入れます。
    • 上記の例では、リクエスト内でトラブルシューティングの手順を表示するために、業務ルールを使用してテンプレートの切り替えを行っています。
      業務ルールを使用して、グループや優先度のフィールドを更新することもできます。
    • リクエストテンプレートに「チェックリスト」を設定し、クローズルールで「すべての関連付けられたチェックリストが完了済み」を有効化することで、チェックリストのチェックが完了していないとリクエストをクローズできないように設定することもできます。
      その他、技術担当者によるクローズ時のコメントを必須化する設定もあります。
      リクエストクローズルールの設定

 

連携方法

「ServiceDesk Plus Cloudとの連携」マニュアルを参考に、NCMとSDPCを連携します。

 

【実例】リクエスト対応の流れ

コンフィグバックアップ失敗

  1. NCMでコンフィグバックアップの失敗イベントが発生します。
  2. SDPCにリクエストが起票されます。
    「NCMとSDPCを連携するための事前準備」のSDPCの事前準備の内容に応じて、技術担当者グループへの通知やリクエストの項目の自動更新が行われます。
  3. 通知を受け取った技術担当者は、リクエストをピックアップする、または他の技術担当者に割り当てます。
  4. 技術担当者は、リクエスト内の［回答］タブを開き、事前に記されたトラブルシューティングの手順に沿って、コンフィグバックアップが失敗した原因を確認します。
  5. NCMでコンフィグバックアップが成功するようになったら、SDPCのリクエスト内の［チェックリスト］を開き、チェック項目に漏れがないか確認します。
  6. SDPCでリクエストをクローズします。
    チェック項目に漏れがあると、エラーメッセージが表示されます。

SDPCの「トリガー」機能を使用して、技術担当者がリクエストをクローズしたことを関連の技術担当者に通知することができます。
※クローズ時に技術担当者グループに通知する通知ルールは実装されていません。
トリガー設定のマニュアル

＜メッセージ例＞
技術担当者「${last_updated_by.name}」がリクエストID「${display_key.display_value}」をクローズしました。

  • リクエストの件名：$Title
  • クローズコメント：${closure_info.closure_comments}

詳細は以下のURLを確認してください。
$RequestLink

 

コマンド投入の承認依頼

NCMの「コンフィグレットの実行」操作について記載します。
「コンフィグのアップロード」操作の場合、「SDPCに起票されるリクエスト内容（件名、説明）」の「コンフィグのアップロード」に記載の件名や説明と置き換えてください。

  1. NCMでコンフィグレットの実行操作が行われます。
  2. SDPCにリクエストが起票されます。
    「NCMとSDPCを連携するための事前準備」のSDPCの事前準備の内容を参考に設定したリクエストテンプレートや業務ルールに応じて、技術担当者グループへの通知やリクエストの項目の自動更新が行われます。
  3. 通知を受け取った技術担当者は、リクエストをピックアップする、または他の技術担当者に割り当てます。
  4. 技術担当者は、リクエスト内の［会話］タブから対象装置のホスト名を確認し、本文に記載のURLからNCMの「保留中のリクエスト」画面を表示します。
  5. NCMで実行予定のコンフィグレットを確認し、承認や拒否の操作を行います。
  6. SDPCでリクエストをクローズします。

 

このナレッジの総閲覧回数： 79

関連するナレッジはありません