ManagerのセルフサービスポータルでOrchestratorのRunbookを公開するあたりの操作ははじめてやるとわかりにくいと評判ですが、一度わかってしまえば大したことないのも事実です。今回はちょっとこの辺りのメモを自分用に書いておきます。Manger側が一方的にRunnbookを認識しRunbookを実行する仕組みです。Managerを認識する事は基本的にしていないという理解をしていくのがまず良いでしょう。Manager用のアクティビティを使う場合は例外です。ManagerにOrchestratorへのコネクタを作成します。ManagerのコネクタはOrchestratorのWebサービスを叩き、Runbookを認識します。Manger上に「Runbook」が表示されます。Manager上で使えるように「活動」テンプレートに組み込みます。Managerの「サービスリクエスト」テンプレートに組み込めるようになりました。サービスリクエストテンプレートは複数の「活動」を組み込んでワークフローを定義できるものだからです。そのサービスリクエストをセルフサービスポータルに公開していきます。セルフサービスポータルにサービスリクエストを公開するにはその入れ物として「リクエスト提供」と「サービス提供」を用意する必要があります。リクエスト提供にはサービスリクエストがアイテムとして登録でき、サービス提供にはリクエスト提供が複数登録できます。これらは事実上、セルフサービスポータル上のカテゴリ(≒サービス提供)とアイテム(≒リクエスト提供)となります。Automation活動テンプレート内で自由にマッピングする事が出来ます。Automation活動を元にその親のSRや関連アイテム等に対して芋づる式にアクセスすることが出来ます。Manager」イベントログ内で確認できます。Managerを元に作られているからです。(2016/01/26追記)Runbook自体を編集するのは構わないですが、Runbookの引数(パラメータ)の数を変更してしまうと、紐づくものが全て無効となってしまい、一から再設定する事になってしまうので注意。必要がなくてもはじめからRunbookのパラメータとしてRubook自体のIDはとっておくようにしたほうが良い。しておけばあとから関連するアイテムを取得し、色々とプロパティをいじろうとするときに全部設定しなおしとならないし、このようにしたくなる可能性は高い。Rubookの引数を変更するレベルでいじってしまい、再作成になった場合に、「以前は動いていたのに、変更後、Runbookが「開始」されるだけで実行されなくなってしまう」という状態に複数回陥った。この際に何度も綺麗に作りなおしても再度「開始」されるばかりでかなりハマってしまったが、実際には過去のおかしな状態のまま実行中になったサービスリクエストが中途半端にRunbookをキックすることが原因の模様。この場合、一度全てのオープン中のサービスリクエストを全部クローズしてから綺麗にやり直すと良い。Service」が実行されていないケースもあった。その他参考になる情報へのリンクも貼っておきます。コメントをキャンセルメールアドレスが公開されることはありません。書籍windowsインフラ管理者入門という本を書きました。お手にとっていただければと思います。Previewになっています。