SCOMコンソールからのエージェントをインストール/アンインストール時に失敗したとき

自分メモ。

Console based Agent Deployment Troubleshooting table
https://blogs.technet.microsoft.com/kevinholman/2009/01/27/console-based-agent-deployment-troubleshooting-table/
のコードを見ながら、トラブルシューティングすれば良いです。


「アンインストールメニューがグレーアウトでリモートからの削除不可」のケースもあったりします。

リモート管理できないエージェントで発生すること、下記情報に記載あります。
No option to remove agent from monitored client from Management server
http://www.systemcentercentral.com/forums-archive/topic/no-option-to-remove-agent-from-monitored-client-from-management-server/
よって、作業対象のサーバーにRDPで接続し、SCOMエージェントを削除後、新SCOMからプッシュインストールを試行すれば良い模様。

※ちなみに、リモート管理できないエージェントを管理可能にする、下記からたどれるアンサポートなSQLスクリプトもあるようですね。。。
SCOM RC2 Managed Agent options grayed out
https://social.technet.microsoft.com/Forums/systemcenter/en-US/a600cb2c-bba0-46c0-b2ac-7293e0f0f401/scom-rc2-managed-agent-options-grayed-out?forum=operationsmanagerdeployment

Linux Agent for SCOMのインストールが証明書のエラーでうまくいかない

Azure VMに限った話ではないのですが、久しぶりに遭遇したのでメモ書きしておきます。
Open Source Software Management Packs for System Center 2016 Technical Preview 2 その2
と合わせてお読みいただければ、Linux Agent for SCOMのインストールエラーに対応できます。

AzureのVM対して、Linux Agent for SCOMのインストールを行いましたが、エラー発生。

これは、見たことがあると思い、拙作のブログ記事を探しました。
VyattaをSC 2012 R2 OMで監視できるか。
に解決方法を書いていました。
証明書に関する問題に公式の解決方法が載っています。

openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates
を実行しました。

Azure VMは、cloudapp.net配下だった。。。

証明書に関する問題に書かれている
/opt/microsoft/scx/bin/tools/scxsslconfig -f -h hostname -d domain.name
を実行してみます。


/opt/microsoft/scx/bin/tools/scxadmin -restart
でLinux Agent for SCOMを再起動します。


再度ウィザード実行したところ、今度は成功しました。


以上、ご参考になれば幸いです。

Open Source Software Management Packs for System Center 2016 Technical Preview 2 その2

注）開発途中の製品ですので、あくまでも2015年7月時点の情報となります。今後開発が進むに従い、本記事の内容と差異が発生するはずです。これをもって、次期System Center がこうなると判断するのは早計ですので、ご注意ください。

前回の投稿から日が開いてしまいましたが、続編です。
Open Source Software Management Packs for System Center 2016 Technical Preview 2を試しますといいたいところですが、UNIX/Linux MPのAgentを入れないと、そもそもどうにもなりません。

ということで、そちらを先に書いていきます（当ブログではある意味おなじみかつポンコツな内容ですけど）。

FWがオンになっている場合は、1270/TCPを開けておきましょう。
CentOS 7の場合


CentOS 6.6の場合


1270/TCPが開いていないとこうなります。


Linux側は、sudoさせようと思って設定しました。

失敗しました。。。

先に進みたかったので、rootを使う作戦に変更（安易すぎるけど）。

OM管理サーバーのAdministratorsグループにOMアクションアカウントが入っていないため、エラーになりました。。。

OM管理サーバーのAdministratorsグループにOMアクションアカウントを入れます。

OM管理サーバーのAdministratorsグループにOMアクションアカウントを入れた後に、OM管理サーバーを再起動していないため、エラーになりました。

ということで、OM管理サーバーを再起動します。
再起動後に、再トライ。

上手くUNIX/Linux MP Agentがインストールできました。

この後、UNIX/Linux用のアクションアカウントをを作成します。
まずは、モニター用。

で、More Secureにしたのですが、テスト用なので、
Less Secureに変更しました。。。


続いてエージェントメンテナンス用。


UNIX/Linux用のアクションアカウントが作成できました。


UNIX/Linux用のアクションアカウントをRun As Profileに関連付けます。
先ほど作ったモニター用のアカウントをUNIX/Linux Action Accountに関連付けます。


引き続いて、エージェントメンテナンス用をUNIX/Linux Agent Maintenance Accountに関連付けます。


ここまでで、UNIX/Linux管理パックに必要な設定が終わりました。
そうすると無事に監視できます。


長くなりましたので、Open Source Software Management Packsの設定は、別記事とします。