SCOMでコーヒーの残量を監視する管理パックがありました。これは面白い。 技術的には以下の流れで実装しているようです。 - 定期的に画像を取得し、特定のパスに保存 - 画像内のpixcelを数え、残量を把握 - 残量に応じてステータスを変更 実際の管理パックは以下で公開されています。 - [Coretech Blog » Blog Archive » OpsMgr 2007 R2 (SCOM): Coretech Coffee Monitor Management Pack – 0.0.0.1](http://blog.coretech.dk/jgs/opsmgr-2007-r2-scom-coretech-coffee-monitor-management-pack-0001/) SCOMの管理パックってスクリプトをかけちゃうんですね。ということはもうなんでもありなわけで。私もなにかおもしろいものを監視してみたいな！ photo credit: . SantiMB . via photopin cc
SCOMでサーバー群を監視していますが、稀に「監視しない」という状態になってしまうことがあります。 原因は追求出来ていないのですが、サービスを停止した上で、キャッシュファイルを削除することで復旧させることができています。 監視サーバー 停止するサービス - System Center Management Configuration - System Center Management - System Center Data Access 削除するキャッシュファイル 「C:\Program Files\System Center Operations Manager 2007\Health Service State」に含まれているフォルダ全て 監視対象サーバー 停止するサービス - System Center Management 削除するキャッシュファイル 「C:\Program Files\System Center Operations Manager 2007\Health Service State」に含まれているフォルダ全て 参考URL - [管理サーバーやエージェントの調子がおかしいです。どこをチェックすれば良いでしょうか?](http://technet.microsoft.com/ja-jp/systemcenter/gg651150.aspx) - [Getting headaches trying to figure out why you are seeing the 'Not Monitored' state for Management Servers or Agents? - System Center: Operations Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/momteam/archive/2008/03/10/getting-headaches-trying-to-figure-out-why-you-are-seeing-the-not-monitored-state-for-management-servers-or-agents.aspx) - [Thoughts on OpsMgr and System Center 2012: OpsMgr Agent stays in ‘Not Monitored’ status. Is DNS OK?](http://thoughtsonopsmgr.blogspot.jp/2009/10/opsmgr-agent-stays-in-not-monitored.html)
SCOMエージェントのインストール作業をGUI操作で何度も実行するのが面倒になったので、さくっとPowerShellスクリプトを書きました。RemotePowerShellを使ってSCOMサーバーに入ってからInstall-SCOMAgentを叩く作りになってますので、ネットワーク上のどのPC上からでも実行できます。 [gist id=7426819]
System Centerを理解したい、評価したい場合に、まずはじめに「コンポーネントが沢山ある！どれが何だかわからない！」「どういう関係があるのかわからない！」という疑問を誰もが持つと思います。私も取り組み始めてから半年程度たつまではよくわかっていませんでした。そこでそういう人向けに各コンポーネントの概要を説明したいと思います。私の主観がバリバリに入っていますのでそこは注意してください。 名称 略称 概要 System Center Configuration Manager SCCM サーバー/クライアントに対しての構成管理、更新管理を行う。アプリケーション配布、ソフトウェア更新、OS展開、インベントリ収集、検疫ネットワークとの連携(ソフトウェア更新部分担当)、マルウェア対策、各種レポート表示(これはレポーティングサービスに依存)など対応範囲は広く、その分複雑。必要になる技術も多岐に渡る。様々な属性を元に柔軟にデバイスのコレクションを定義でき、目的に応じて多彩な設定を行えるのが強み。 ソフトウェア更新にはWSUSをエンジンとして使う、OS展開はWDSを使う、レポートはSQL Serverのレポーティングサービスを使う、SCEPはSCCMの機構の中で動くなど、他のソフトウェアとの連携も多い。 SCCMのクラウド版とも言えるものがIntune。ただ、ItuneよりもはるかにSCCMでできることの方が多く、SCCMとIntuneとで連携も行えるため、補完関係にあるとも言える。 何をするにしてもリアルタイムで結果が返ってくるわけではなく、設定してあとはほったらかしてそのうち終わってる…というような時間軸で作業を行う。せっかちさんには辛い。 System Center Endpoint Protection SCEP ウイルス、マルウェア対策のエンジン。SCEPのクライアントエージェントのみで動作させてパターンファイルはインターネットから…ということも可能だが、基本的にSCCMと組み合わせて使用する。 SCCMではクライアント設定をデバイスコレクションに展開してクライアントを展開させ、裏でWSUSを使ってソフトウェア更新の機能でパターンファイルを更新し、結果はレポーティングサービスで確認する…というSCCMらしい統合方法になっている。 他のウイルス対策ソフトと比較してしまうと展開や基盤の構築の大変さが目立ってしまうが、SCCMで元々管理している環境であれば管理が楽に行えるのでメリットが出てくる。 System Center Virtual Machine Manager SCVMM 複数のHyper-VホストやHyper-Vクラスタを束ねて管理を行うことができる。「テナント」「クラウド」の概念を持ち、物理リソースの制限を行うことができる(このクラウドはこの物理サーバー上でのみ仮想マシンを実行できる等)。これによっていわゆる「プライベートクラウド」を作成することができる。マシンテンプレートを作成し、手軽に展開が行える。一歩進んだ使い方としてはネットワークの仮想化やサービスを展開してノードを増減させたり、構成を変更してその変更を既存のサービスに展開することもできる。 SCVMMを使わなくてもHyper-Vマネージャーやフェールオーバークラスタマネージャーだけで問題無い…と私も使う前は思っていたし今でも小規模であればそれで良いと思うがきちんと様々なものを作成して自動化して楽をしていこうと思ったらSCVMMの導入は必須になる。ただし、ツールとしては出来はそんなに良くなく、よくSCVMMでは操作できないが、Hyper-Vマネージャーやフェールオーバーマネージャーでは操作できるという状況が発生する。VMWareやXen Serverの管理も行え、Hyper-V+SystemCenterへの移行がしやすくなっている。 よく誤解されるが、SCVMMにはAzureとの連携機能は無い。 System Center App Controller SCAC SCVMMおよびAzureへの接続機能を持ち、SilverlightベースのWebインターフェースを持たせることができる。SCVMMコンソールよりも出来る事は少ないがWebコンソールから手軽に操作できるのでセルフサービスポータルとしての利用が可能。 SCVMMに完全に依存するが、インターフェースとしては出来がよく操作も軽快。SCVMMのコンソールを使うよりもSCACを使う方が操作感は良いと感じる。 System Center Operations Manager SCOM 監視やログ収集を行う事ができる。開発者が作成した「管理パック」を使うことで開発者の意図する監視を製品に詳しくなくても何も考えずに行うことができるのが売り。ただし、管理パックの設定のまま監視を行うとアラートや通知メールが大量に生成されてまともに監視できないという矛盾を抱えている。管理パック毎なので適度なレベルの管理パックも存在しているかもしれない。 なので、管理パックが望む監視レベルになるようにカスタマイズ(別の管理パックで上書き)するという追加タスクがほぼ必ず発生するのが現実。 ネットワーク上のノードの監視やアプリケーションレベルの監視等も行える。ノードやアプリケーションはクラウド上でも良い。 System Center Data Protection Manager SCDPM バックアップを行うことができる。通常のバックアップソフトとの違いというのはあまりないと感じる。バックアップ対象とのブロックレベルでの差分を取得していくことが特徴…という説明が良くあるが、ファイルサーバーに対してはそうだが、その他に関してはアプリケーション毎に対応がまちまちなので注意が必要。 SCDPMで保護してある過去のバージョンにWindowsのエクスプローラーのバージョンタブからアクセスできる(その代わりVSSのバージョンにはアクセスできなくなる)などの機能もある。 バックアップした結果を別のSCDPMでテープのように「インベントリ」を取得して再利用することができないためSCDPM自体の保護を行おうとするとSCDPMが2台構成になる構成パターンがあるなど結構豪快な所がある。 System Center Service Manager SCSM System Centerの製品群の中で一番重要であり、一番手が出しにくい運用管理のためのコンポーネント。インシデント管理、問題管理、変更管理等が行える。ITIL(正確にはMOF)の考え方に基づいた設計になっており、ITILを理解した運用管理者がSCSMを使うと非常に効果が高い…はず。私がITILを理解していないので実際の所が良くわからない。SCSMを教科書通りに使おうと思うと運用のしかた自体を変更する必要に迫られるはずで、すでに運用がしっかりと決まっている所への導入は難しく逆にITILを意識していない運用をしている所への導入はITILの理解から必要になり難しそうに思われる(想像)。 …という想像が先にたってしまい手をつけずらいので、心理的ハードルをどのようにクリアするかという問題がまずある。実際にはそんなにハードルが高くないのかもしれない。分からない。 一方ユーザーにセルフサービスを提供する機能がSCSMにあり、その前提条件はSharePoint Server(!)になっている。SharePointをまず構築しないといけないということでより一層ハードルが上がる。 また各種コンポーネントとのコネクタも多くをSCSMが持ち、運用に中心に来るものなのでこれを使いこなすことがSystem Centerスイートの価値を引き上げるものになるはず。 System Center Orchestrator SCO System Centerの製品群の中でSCOを一番重要なコンポーネントにあげる人も多いキーコンポーネント。自動化を行うことができる。 プログラミングがあまり得意でない人でも扱えるように処理がアイコンとして表現されており、アイコンを配置し、アイコン同士を矢印で繋ぎ、条件設定等をするだけで処理を作成できる。 System Centerコンポーネント群を操作するための「統合パック」がマイクロソフトによって準備されており、様々な処理がコンポーネントをまたいで簡単に行える。 実際にはPowerShellを使って処理の自動化は簡単に行えるものが多いので、PowerShellが書ける人なら「いらない」というケースもあると思われる。しかし一方で処理がRunbookという単位にまとまり内容が可視化され、格納場所も実行方法も統一されるのでそれだけでも運用の属人化を防ぐためには良いと考える人もいる。何なら全てPowerShellで処理を書いてSCOからはそれをキックするだけのRunbookを用意するだけでも構わないし、何でもかんでもSCOでやるのであればVisual Studioで統合パック自体も作成できてしまうという懐の深さもある。でも、Runbookのバージョン管理ができないなどの危うさもある。 ...
恥ずかしながら、本番環境でSCOM2012の使用期限が切れてしまいました。SCOM2012はインストールウィザードでライセンスキーを聞いてくれず、後から別途PowerShellでライセンスキーを入力する必要があるのですが、それに気が付きませんでした。製品群が多数あって、同時並行で操作していると私と同じようにうっかり忘れてしまう人も多いのではと思います。 対処方法は以下に書かれていました。 - [System Center 2012 Operations Manager のプロダクトキーを入力する方法 - Japan System Center Support Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/systemcenterjp/archive/2012/05/08/3496599.aspx) 他のコンポーネントと同じようにインストールウィザードで聞いてくれるといいのですけどね…。 期限切れの状態になると、上記ブログに書かれている手順のままだと「New-SCOMManagementGroupConnection」を入力した時点でエラーが出てしまいますが、これは無視して良い…というか、このコマンド自体ライセンス適用には不必要な模様です。
System Center 2012 SP1でチャージバックレポートを実装し、常時課金レポートを公開しています。まだ正式運用前ではあるのですが、挙動確認のために仮想マシンを増減させて正しく計算されるのかみていたら、ある日を境にまったく課金されないクラウドが出来てしまいました。きちんと動いているクラウドもあるのですが。どうにも法則性がわからず、基本的な部分から見なおしていたら、SCOM上できちんとSCVMMが監視できていないことに気が付きました。 なにやら状態が灰色になってしまっています。調べたところ、きちんと監視できていない状態になってしまっているとのこと。 - [監視されていないグレーのエージェント](http://technet.microsoft.com/ja-jp/library/hh212723.aspx) 確認して、結局今回はSCVMMサーバー上でWindows Management Instrumentationを再起動することで正常に監視できる状態に戻りました。これでチャージバックレポートの結果も正常に戻りそうです。 SCOMの監視状況自体をよく見ておかないといけないですね。
SCOMにWSUSのビューを追加する方法が紹介されています。SCOMのカスタマイズは何でもかんでも管理パックで面白いですね。 - [Extending the Windows Server Update Services (WSUS) 3.0 management pack (#SCOM)](http://www.systemcentercentral.com/extending-the-windows-server-update-services-wsus-3-0-management-pack-scom/)
SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCOMにWSUSのビューを追加する方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/06/25/scom%E3%81%ABwsus%E3%81%AE%E3%83%93%E3%83%A5%E3%83%BC%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95/)
新規にSCOMで監視をするサーバーが4台ほどあったのでいつもようにプッシュインストールを行いました。すると、1台だけ何故か以下のようにインストールに失敗してしまいました。 ちょっと調べましたが、色々と複雑なことが起きているようで、時間もあまりなかったこともあり、深く追求せずに対象サーバー上での手動でのエージェントインストールを行いました。 - MOMAgent.msi セットアップ ウィザードを使ってエージェントをインストールする [**http://technet.microsoft.com/ja-jp/library/hh212915.aspx**](http://technet.microsoft.com/ja-jp/library/hh212915.aspx) エージェントの手動インストールはSCOMのインストールDVDから行えます。 インストールは通常通り成功し、あとは、管理コンソールから承認を行なってあげれば通常通り監視が行えます。 SCOMのエージェントインストールに関しては色々トラブルシューティングをするまえにまずは手動でのインストールを試してしまうのが時間効率的に良いことが多いようです。
SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCOM管理エージェントのインストールに失敗する。「この操作は現在インストールされている製品に関してのみ有効です」 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/06/12/scom%E7%AE%A1%E7%90%86%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%AB%E5%A4%B1%E6%95%97%E3%81%99%E3%82%8B%E3%80%82/)
Exchange Server 2013を監視するためのSystem Center Operations Manager用の管理パックが公開されています。 - Released: Exchange Server 2013 Management Pack - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/15/released-exchange-server-2013-management-pack.aspx - MP Blog: Exchange 2013 Management Pack released - System Center: Operations Manager Engineering Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/momteam/archive/2013/05/14/exchange-2013-management-pack-released.aspx ダウンロードはこちらから行えます。 - Download Microsoft Exchange Server 2013 Management Pack from Official Microsoft Download Center http://www.microsoft.com/en-us/download/details.aspx?id=39039 今回の管理パックは監視コンセプトが以前とは変更され「ユーザーに対してどのような影響があるのか」という視点がより強くなるそうです。 - Lessons from the Datacenter: Managed Availability - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2012/09/21/lessons-from-the-datacenter-managed-availability.aspx ...
System Center Operations Manager用のExchange Server 2013 Management Packが公開されています。Exchange Server Blogの方にリンク先等載せておきました。 - [SCOM用のExchange Server 2013 Management Packが公開されています | Exchange Server Blog](http://ebi.dyndns.biz/exchange/2013/06/scom%e7%94%a8%e3%81%aeexchange-server-2013-management-pack%e3%81%8c%e5%85%ac%e9%96%8b%e3%81%95%e3%82%8c%e3%81%a6%e3%81%84%e3%81%be%e3%81%99/)
SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCOM用のExchange Server 2013 Management Packが公開されています。 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/06/03/scom%E7%94%A8%E3%81%AEexchange-server-2013-management-pack%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82/)
SCSMのSCOMアラートコネクタをSCSM側で作成して「おかしいなー、同期できないなー」と思っていたのですが単純に構成が足りていませんでした。 下記のTechnetに作成手順がきちんと書いてあります。 - How to Create a System Center Operations Manager Connector http://technet.microsoft.com/en-us/library/hh524325.aspx 私はてっきり他のコネクタと同じようにSCSM側でSCOM Alertコネクタを作成すればそれで完了だと思ってしまったのですが、実際にはSCOM側の管理コンソールの内部コネクタにて配信登録をしてあげる必要がありました。調べ初めてからは５分で解決したのですが、直感的にわかりずらく、トラブルなのではないかと思い、ネットで調べ始めるまでに時間がかかってしまいました。 教訓はきちんとTechnetを読みましょう！ということですね…。(でも読みづらいんですよね…。)
SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCSMのSCOM Alertコネクタの作成方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/04/19/scsm%E3%81%AEscom-alert%E3%82%B3%E3%83%8D%E3%82%AF%E3%82%BF%E3%81%AE%E4%BD%9C%E6%88%90%E6%96%B9%E6%B3%95/)
ExchangeブログJapanでSCOMへExchange Server 2010の管理パック導入後にOutlook Anywhere関連のアラートが出る場合のその除外方法が紹介されています。 Exchange 2010 管理パックで発生する HTTP 接続関連のアラートについて - Exchange ブログ JAPAN - Site Home - TechNet Blogs もちろん本当にOutlook Anywhereが構成されている環境でアラートが出てしまうならそれは本当に障害なのですが、Outlook Anywhereを意図的に構成していない場合には誤検知ということになります。なので、不必要なルールを無効化することになるのですが・・・。量が多いですね。 無効化するモニタの一覧 KHI: 自動検出による HTTP 接続 - RPC over HTTP エラー (ログオン) KHI: 自動検出による HTTP 接続 - アドレス帳エラー (NSPI) KHI: 自動検出による HTTP 接続 - アドレス帳エラー (ABREF) KHI: 自動検出による HTTP 接続 - 自動検出エラー KHI: 自動検出による HTTP 接続 - RPC クライアント アクセス エラー (接続) KHI: 自動検出による HTTP 接続 - RPC クライアント アクセス エラー (ログオン) KHI: 自動検出による HTTP 接続 - 予期しない例外 KHI: ローカル サーバーへの HTTP 接続 - RPC over HTTP が失敗しました (RpcProxy) KHI: ローカル サーバーへの HTTP 接続 - アドレス帳エラー (NSPI) KHI: ローカル サーバーへの HTTP 接続 - アドレス帳エラー (ABREF) KHI: ローカル サーバーへの HTTP 接続 - 予期しない例外 KHI: ローカル サーバーへの HTTP 接続 - RPC クライアント アクセス エラー (接続) KHI: ローカル サーバーへの HTTP 接続 - RPC クライアント アクセス エラー (ログオン) KHI: ローカル サーバーへの HTTP 接続 - 予期しない例外 KHI: Test-OutlookConnectivity (内部) コマンドレットを実行できませんでした。 KHI: ローカル サーバー上の Outlook のパフォーマンス障害 (RpcProxy) - RPC-over-HTTP を経由した Outlook 接続で接続問題が発生している可能性があります。 ...
SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [Excahnge Server 2010管理パック導入後に不必要なHTTP接続関連アラートが出ないように構成する | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/11/excahnge-server-2010%E7%AE%A1%E7%90%86%E3%83%91%E3%83%83%E3%82%AF%E5%B0%8E%E5%85%A5%E5%BE%8C%E3%81%AB%E4%B8%8D%E5%BF%85%E8%A6%81%E3%81%AAhttp%E6%8E%A5%E7%B6%9A%E9%96%A2%E9%80%A3%E3%82%A2%E3%83%A9/)
SystemCenter Operations Manager 2012 SP1のエージェントをSystemCenter Service Manager 2012 SP1のWebポータルにインストールできず困っています。 そもそも、Service ManagerはOperations Managerを元に作られたのでエージェントがインストール出来ない…という時期もあり、でも、SP1ではサポートされるようになった・・・というように講習等で習いました。以下のドキュメントにもSP1ではサポートされると書いてあります。 http://technet.microsoft.com/en-us/library/hh524312.aspx System Center 2012 – Operations Manager System Center 2012 – Operations Manager is supported by Service Manager and Service Manager SP1 for connectors and agents. However, only corresponding System Center versions are supported when you register a data source in the Data Warehouse workspace. System Center 2012 – Operations Manager agents were not supported with System Center 2012 – Service Manager. However, the agent that is automatically installed by System Center 2012 – Service Manager SP1 is compatible with System Center 2012 – Operations Manager and System Center 2012 – Operations Manager SP1. After Service Manager Setup completes, you must manually configure the agent to communicate with the Operations Manager management server. ...
SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [Service Manager WebポータルにOperations Managerのエージェントがインストール出来ない | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/09/service-manager-web%E3%83%9D%E3%83%BC%E3%82%BF%E3%83%AB%E3%81%ABoperations-manager%E3%81%AE%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88%E3%81%8C%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC/)
Active Directory Domain Services管理パックが更新され、Windows Server 2012に対応しています。 Active Directory Domain Services Management Pack for System Center