Operations Manager

※長期間下書きのままになってしまっていたようなので、そのまま公開してしまう… SCOM経由でOperational Insightsにデータを送信する形態の場合に、そのデータ送信が途絶えてしまう…というトラブルがありました。 結局その後トラブルシュートすることで - Operations ManagerのDBの空き容量が少ない場合にSCOMとしては概ね正常に動いていながらも、Operational Insightsにはデータを送信しない事象が出る - SCOMからOperational Insightsへのデータ送信の確認はパフォーマンスモニタで行える ということがわかりましたので、メモとして残しておきます。 1に関してはきちんとSCOM自身の監視にて警告がでており、DBの拡張を実施することで正常に動作するようになりました。 2に関しては、Health Service Management GroupsのHTTPからはじまるカウンタにてデータ送信の状況が確認できます。以下のページに方法が書かれています。 - [Operational Insights のプロキシとファイアウォール設定の構成](https://azure.microsoft.com/ja-jp/documentation/articles/operational-insights-proxy-firewall/#operations-manager)

- [Download System Center Management Pack for Microsoft Azure (Technical Preview) from Official Microsoft Download Center](http://www.microsoft.com/en-us/download/details.aspx?id=50013) 待望の新しいAzure管理パックが出てきています。この管理パックの特徴はなんといっても… - AzureのREST APIをキックする方式 - Azure Resource Managerによって標準的な手法で公開されるパフォーマンスデータを取得する - 新しいARM対応サービスに**自動対応**する 「自動対応」がとても嬉しいですね。全部ARMにきちんと寄せていってもらえると思ってますので、Azureの監視は何でもかんでもこれだけでOKになる…はず！

Channel9に上がっている、Igniteの動画をみました。SCOMのダッシュボード作成に関してのセッションです。 セッションの要点としては… - SCOM 2012 R2 UR2, SCOM 2012 SP1 UR6から新しいダッシュボードウィジェットが追加されていて簡単にグラフィカルなダッシュボードが作成できる - SQL Serverの管理パックは素敵でグラフィカルなUIだが、そのウィジェットを任意のグループで利用できるものを開発中。 （おそらくDownload Microsoft System Center Management Pack for SQL Server from Official Microsoft Download Centerが該当のものだと思います。私は未検証です。） - Azureの管理パックは既存の物は新しいサービスが登場しても追従できないなど問題があった。今新しいものを作成していて、それだと新しいサービスにも自動追従しながら簡単にパフォーマンスカウンタを取得しつつ、アラートを出力するルールを定義できる。 もちろん動画を見てもらえば作成のデモまで見られるのですが、時間の無い方は以下にどんなものが新しいウィジェットとして提供されているかのサンプルがあるので見てもらえると良いと思います。 - [New Widgets.docx](http://blogs.technet.com/cfs-filesystemfile.ashx/__key/telligent-evolution-components-attachments/01-4616-00-00-03-62-79-94/New-Widgets.docx) 以下、ドキュメントからの引用です。 Component Description Sample Visualization Alert Widget Displays alerts that match the specified criteria in a table format. Contextual Alert Widget Same as Alert Widget except the target object is set from another widget. ...

SCOMではUNIX/Linuxのサポートも拡充されています。以下はUbuntu 14.04にエージェントを配布する例です。 リソースプールの作成 Linuxホストの監視をその他のWindowsサーバー群と同じ管理サーバーで行うにしても、別の管理サーバーで行うにしても、まず、リソースプールを追加するのがお勧めです。 ### 証明書 次に、リソースプール内の管理サーバーが全ての管理サーバーの公開鍵を保持するように構成する必要があります。 - Managing Resource Pools for UNIX and Linux Computers (UNIX および Linux コンピューター用のリソース プールの管理) 今回の環境では、管理サーバーが1台のみの検証環境なのでこの作業はスキップします。 ### UNIX/Linux アカウント UNIX/Linux用のアカウント情報を作成します。 プロファイルとしては上記の3つのプロファイルがありますので、それぞれに割り当てます。このあたりはどこに、どのアカウントを割り当てるのか…というのは環境しだいですね。 ### エージェントの配布 もちろんSSHキーを用いて認証してもいいのですが(構成次第)、ここではユーザー名とパスワードで認証しています。 このように失敗してしまうのは管理パックが古いからです。以下のページから最新の管理パックをダウンロードしインポートすることで対処できます。 - Download System Center 2012 Management Pack for UNIX and Linux Operating Systems (2015/04) from Official Microsoft Download Center これでエージェントのインストールは完了です。

SCOMには「プロセス監視」の管理パックテンプレートがあり、お手軽にプロセスの監視が出来ます。 結構細かい指定がコンソールから簡単に行えるので、重宝します。 が、そこはSCOM、やはりエージェントを導入していないとこれは動作しません。 エージェントが導入されていない、エージェントレス監視のサーバーは監視対象外となります。 これは、管理パックをエクスポートしてRemotable属性の値を確認することでも確認できます。 AvailabilityHealth Error true Normal Error $Data[Default=‘0’]/Context/DataItem/Item0Context/DataItem/ProcessInformations/ProcessInformation[./ProcessName =‘cmd.exe’]/ActiveInstanceCount$ cmd.exe 60 1 5 60 むりやりこれをRemotable=”true”と書き換えてしまってインポートし直すと、監視できているように見えますが、実際にはきちんと動作していません。 監視対象にはなっています。しかし、cmd.exeの数はエージェントレスで監視しているサーバーのものではない数(監視エージェント上のプロセスの数)が戻ってきてしまい、正常に監視できていません。この方法は使えません。 そもそもSCOMは思想的にも機能的にもエージェントを入れて監視するのが有効なので、無理にエージェントレスで頑張る必要は無いですし、お勧めできません。 ですが、やろうと思えば出来るよ・・・ということの一例としてスクリプトを自分で書いてcmd.exeのプロセスの数をリモートからモニターする管理パックを作成してみます。 ユニットモニターを作成します。 スクリプトを記述します。 ‘=================================================================================== ’ AUTHOR: Masahiko Ebisuda ’ Script Name: ProcessMonitor.vbs ’ DATE: 2015/07/13 ’ Version: 1.0 ’ COMMENT: Script to monitor process number. ‘=================================================================================== Option Explicit SetLocale(“en-us”) Dim ProcessName, objWMIService,colProcesses, objProcess, ComputerName, count ...

Linux Application Monitoring and Management with Microsoft System Center | Microsoft Ignite 2015 | Channel 9 System Center 2016でのLinux管理に関してのIgniteでのセッションです。動画がじっくり見られます。 MicrosoftがWindowsにとどまらずLinuxに対しても管理の幅を広げようとしている取り組みがよくわかるセッションになっています。SCOMでの監視、SCCMでの管理…と派手さは無いものの、着実な進化ですね。きちんとOMIプロバイダーを作成して…とプラットフォームをきちんとつくって進めているあたりはMicrosoftらしいところだなぁと思います。 System Center製品ではないもののDSCの話が出てくるのも昨今の流れ的に象徴的だなと思います。 WindowsもLinuxも両方まとめて同じ技術で管理できる世界に随分なってきました。

Microsoft Virtual Academy(MVA)では無償で良質のコンテンツが多数提供されています。 今回はその中でも特にお勧めのコンテンツを紹介します。 ID管理 まずID関連で超お勧めなのは安納さんの「クラウド時代のActive Directory次の一手シリーズ」です。 - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 1 回 Active Directory の位置づけ](http://bit.ly/1QjvAQu) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 2 回 Active Directory ドメイン サービスの新しい役割](http://bit.ly/1GPP3rl) - [クラウド時代の Active Direcrory 次の一手シリーズ ~ 第 3 回 Active Directory フェデレーション サービスの役割 解説編](http://bit.ly/1AHn4ZT) - [クラウド時代の Active Direcrory 次の一手シリーズ ~ 第 4 回 Active Directory フェデレーション サービスの役割 構築編](http://bit.ly/1M2dstR) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 5 回 認証のためのプロキシ Web Application Proxy](http://bit.ly/1FnQusO) - [クラウド時代の Active Directory 次の一手シリーズ ~ 第 6 回 Microsoft Azure Active Directory とは](http://bit.ly/1LVTTmv) 社内でActive Directoryで管理させていたWindows PCをつかってWindows統合認証をしていれば幸せになれる時代はとっくに終ってしまって、これからのクラウド時代で様々なSaaSを効果的に利用しながらID管理もシンプルに保ちつつ、セキュリティも担保していかなくてはいけないのが現在の状況です。ID管理はやっぱり肝です。これらのコンテンツで大きな流れを理解することが出来ます。「フェデレーションってよく聞くけどなんだか難しそう…」という人におすすめです。 ...

先日、色々と事情があって現在稼働しているSCOM2012SP1と同じ構成で新規にSCOMサーバーを構築する必要がありました。普通に構築するだけ…だったはずなのですが、ドハマりしたので記録しておきます。 インストーラーで普通にインストールを進めていくと、レポートサーバーの構成で以下のようにインストーラーがクラッシュするという状況になってしまいました。 CLR20r3, setupchainerui.exe, System.NullReferenceExceptionあたりで検索すると何人かは同じような状況の人がいましたがどれも状況としては合致せず。どうやらReporting Serviceの構成から情報を持ってくるあたりで構成が不完全だったりSCOM側で持っている情報との不整合があると落ちてしまうようです。インストーラー側でのエラーチェックが不完全なように見えます。 半日かけてトラブルシュートをしたのですが、どうしても解決できなかったので、仕方なくSCOM自体をアンインストールし、SQL ServerからもSCOM関連のDBを削除し、セットアップを一からやり直した所インストールに成功しました。 SQL Server側は何も変更せずにインストールに成功したので、やはり問題はSCOMのインストーラーにあるとおもわれますが、詳細は不明です…。

SCOMは管理パックを導入すると様々なレポートが使えるようになります。 基本的にはレポートを実行すれば良いのですが、その際に、「オブジェクト」をきちんと選択する必要があります。 例えば、例としてSQL Serverのレポートを見てみましょう。 レポートを実行すると、グループ、あるいはオブジェクトを追加する項目があり、そこには「フィルターオプションが適用されています。」と出ています。実際に「オプション」を確認すると「SQL Server 2014 DB Engine」というクラスのオブジェクトのみが検索されるように指定されています。 この場合、単純に管理者としては「検索」ボタンを押すだけでレポートの対象となるオブジェクトの一覧を入手でき、その中からデータを表示したいオブジェクトを選択すれば良いことになります。 このように管理パックにて適切なフィルタオプションが指定されている場合は簡単なのですが、中にはこのフィルタオプションが定義されていないレポートもあります。 例えば上記は「Active Directory Server Common Library」の「AD SAMアカウントの変更」レポートですが、フィルタオプションが定義されていないので単純に「検索」ボタンを押すと全ての種類のクラス、全てのオブジェクトが表示されてしまいます。 この状態から適切なオブジェクトを選択するのにはきちんとSCOMの「クラス」「オブジェクト」の概念を理解しておく必要があります。急がばまわれ…で、きちんとオブジェクト指向の考え方を学ぶのが一番いいと思いますが、取り急ぎ…ということであれば、レポートの説明をきちんと読めば大抵何を選べばよいのか書いてあります。 この例であれば「Active Directoryドメインコントローラーコンピューターの役割」の種類のオブジェクトを選択すれば良いと書いてあります。 きちんとフィルタオプションを定義してあげれば、その後は検索ボタンを押すだけで目的のオブジェクトのみが出てきます。 あとは、必要なものを追加してあげれば良いです。 ※違うレポートの画面になってますが、これは「AD SAMアカウントの変更」イベントが記録されておらず、レポートが出力されなかったためです。出力が出る別のレポートにしてありますが、やってることは全く同一です。 なお、レポートのパラメータは「パラメータエリアの表示/非表示」のボタンで表示を切り替えられます。 一度レポートを実行すると、パラメータエリアは自動的に非表示になるのですが、オブジェクトを追加/削除したい場合、期間を変更したい場合などには再度パラメータエリアを表示してそこからの変更が便利です。私ははじめこれに気が付かず、何度もレポート新規に実行して無駄な時間を過ごしていました…。

Operations Manager用のExchange Server 2013管理パックに含まれるレポートが動作せず、レポートを開始しようとすると「レポートを初期化できません。」というエラーが出てしまう事象が発生しました。色々と調査をして原因にたどり着きとりあえず回避はできたのですが、トラブルシューティング中にかなり紆余曲折してしまったので、「わかっている今ならこうやってすんなり対処できるはず」というものを同じような問題に遭遇する人や将来の自分のためにまとめておきます。 発生した事象 SCOM上のレポートにてExchange Server 2013関連のレポートを実行しようとすると、以下のエラーが出てしまいます。 日付: 2015/02/09 17:12:33 アプリケーション: Operations Manager アプリケーションのバージョン: 7.1.10226.0 重要度: エラー メッセージ: レポートを初期化できません。 System.ArgumentNullException: 値を Null にすることはできません。 パラメーター名: GroupList 場所 Microsoft.EnterpriseManagement.Mom.Internal.UI.Reporting.Parameters.Controls.Monitoring.ReportMonitoringObjectXmlEditorBase.LoadValues(ReportParameterInfoCollection reportParameters) 場所 Microsoft.EnterpriseManagement.Mom.Internal.UI.Reporting.Parameters.ReportParameterBlock.LoadValues() 場所 Microsoft.EnterpriseManagement.Mom.Internal.UI.Console.ReportForm.SetReportJob(Object sender, ConsoleJobEventArgs args) レポーティングサービスのWebサイトからの確認 SCOM上でのレポート実行では情報に乏しいので、実態であるレポーティングサービスのWebからも確認します。 同様にエラーになります。「ReportRules」が選択式にも関わらず、何も値が入っていないのが直接の原因であることがわかりました。 ほぼすべてのレポートで同様の状態になっており、問題の原因はリンクされているレポートで発生していることもわかりました。 様々なレポートのリンク先となっているレポートにて問題を確認します。 ReportRulesが選択式にも関わらず値が入っていないためにエラーになっているのは同じ状況です。 レポートのプロパティより、ReportRulesはクエリベースのパラメータであることがわかります。Webからは確認できないので、レポートビルダーにてレポートを開き確認していきます。 レポートビルダーでのレポート定義の確認 実際にレポートビルダーでレポートを開いて確認していくと、以下のようにデータソースへの接続ができずに失敗してしまいます。 なので、前準備として、一時的にData Warehouse Mainの接続設定を変更します。 もともとは以下のように「資格情報は必要ありません」となっています。 これを以下のように「レポートサーバーに保存され、セキュリティで保護された資格情報」に変更します。 ※この接続設定変更部分はあまりよくわからずに実行している点があります。実際にこれでレポートビルダー上で資格情報を要求され、うまく確認可能になるのですが、もう少し深い理解が必要だと感じています。 準備ができたので、レポートを開いていきます。 レポートのURLは、「Reporting Services構成マネージャー」から確認できますので、そこを開きます。 問題となっているパラメータの設定を確認します。 「Exchange2013_Report_GetRelatedRules」というデータセットから値を取得していることがわかりました。次は「Exchange2013_Report_GetRelatedRules」データセットを確認します。 ...

SCOMでのO365監視設定の手順を書き残しておきます。 O365 管理パック - https://www.microsoft.com/en-us/download/details.aspx?id=43708 上記から入手できます。手順はいっしょにダウンロードできるWordドキュメントから入手できます。 O365監視用ユーザー作成 https://login.microsoftonline.com　にアクセスする。 管理者アカウントでサインインを行う。 管理画面にて「新しいユーザーを追加する」をクリック ※この時入力する「連絡用電子メールアドレス」は結局管理者であれば全てのアカウントのパスワード管理ができるので、任意のものを入力すれば良いです。 ライセンスは「何も割り当てずに」次へをクリックします。 (オプション)監視用ユーザーのパスワードを無期限にする #### Microsoft Online Services Sign-In Assistant for IT Professionals RTWのインストール http://www.microsoft.com/en-us/download/details.aspx?id=41950 からダウンロードしてインストール。64ビット版推奨。 Azure Active Directory Module for Windows PowerShell(64ビットバージョン)のインストール http://go.microsoft.com/fwlink/p/?linkid=236297 からAzure Active Directory Module for Windows PowerShellをダウンロードしてインストールします。 Azure ADへの接続 Import-module MSOnline connect-msolservice Azure ADに接続できるクレデンシャルを入力する。 ユーザーのパスワードを無期限にする Set-MsolUser -UserPrincipalName -PasswordNeverExpires $true SCOMへのO365管理パック追加 管理パックダウンロード 以下のURLから管理パックをダウンロードします。 https://www.microsoft.com/en-us/download/details.aspx?id=43708 ...

SCOMで監視をしているとスクリプトのデバックをしたくなることがあります。実際に自分でスクリプトを動かしてみて動作を確認したり、直接スクリプトを参照して内部ロジックを確認したり…。 これを行うにはまず、該当のモニターのタイムアウトを1秒とかに設定してしまって、意図的にタイムアウトさせてしまい、その情報をイベントログに記録させてしまうのが一番早いです(おそらく)。 これでタイムアウトを短くしてしまえば、タイムアウトした時に、イベントログにタイムアウトしたスクリプト名やその時の引数等が記録されます。 あとはスクリプトファイルを捕まえてあげれば自由にデバッグできるようになります。 エージェント側で実際のスクリプトを確認します。 C:\Program Files\System Center Operations Manager\Agent\Health Service State このディレクトリ以下に実際のスクリプト等が格納されているのでコマンドプロンプトにてサブディレクトリも含めてスクリプト検索を行います。ゲートウェイが存在している環境では別のディレクトリに格納されていると思います。 dir /b /s *.vbs このようにスクリプト一覧が出力されますので、目的のスクリプトを確保することができます。 また、SCOMサーバー側でも管理パックをエクスポートすることで定義を確認する方法もあります。 SCOM PowerShellから以下のコマンドで管理パックをエクスポートして、中身に対してスクリプト名で検索をかけるとよいでしょう。 Get-SCOMManagementPack | Export-SCOMManagementPack -path c:\mp たとえば、GetSQL2012DBFilesFreeSpace.vbsであれば以下のようになります。 目的のものが手に入ったら、あとは、コマンドプロンプトで実際にスクリプトに正しい引数を与えながらデバッグを実行することになります。スクリプトをコピーしてprintfデバッグをしてもよいですし、環境が許せばデバッグ実行をするのもよいでしょう。 vbscriptであればcscriptに//Xオプションをつけることでデバッグ実行ができます。もちろんその場合にはデバッガーが環境に入っていないといけません。 c:\tmp>cscript /? Microsoft (R) Windows Script Host Version 5.8 Copyright (C) Microsoft Corporation. All rights reserved. Usage: CScript scriptname.extension [option…] [arguments…] Options: //B Batch mode: Suppresses script errors and prompts from displaying //D Enable Active Debugging //E:engine Use engine for executing script //H:CScript Changes the default script host to CScript.exe //H:WScript Changes the default script host to WScript.exe (default) //I Interactive mode (default, opposite of //B) //Job:xxxx Execute a WSF job //Logo Display logo (default) //Nologo Prevent logo display: No banner will be shown at execution time //S Save current command line options for this user //T:nn Time out in seconds: Maximum time a script is permitted to run //X Execute script in debugger //U Use Unicode for redirected I/O from the console ...

ここの所色々忙しくて全然ブログに投稿できておりませんでした。やっと少し自分の時間を持てるようになってきたので久しぶりの更新です。 忙しくしている間に、Microsoft MVPとしてCommunity Camp 2014のWebinarで喋らせてもらいましたのでその時の資料を共有しておきます。 **System centerを中心とした統合管理-オンプレミスからクラウドまで **from Masahiko Ebisuda 今回のイベントの主旨を考えて、なるべく難しくなり過ぎないように…と思って作成しましたが、さて、どうだったか…。そもそも難しい上に、オンラインで相手の顔が見えない状態だとさらに難しいですね。精進が必要です。

SCOMで監視をしたり、レポートを作成したりする場合にその「対象」を特定したいという場面は良くあります。単一サーバーなら直接オブジェクトを選択すれば良いのですが、複数サーバーを対象としたい場合にはグループを作成し、それを利用する事ができます。 管理パックを導入すると「OSがWindowsであるコンピューター」や「SQL Serverが入っているコンピューター」などのみが表示されるビューが生成されますが、それらは予めグループを定義してあり、そのグループのメンバを表示するような形で実装されています。これと同じことを自分で行えば良いわけです。 それぞれのオブジェクトのプロパティで定義されている値をキーにしてグループを作成するのはコンソールから簡単に行えます。「SQL Serverを持っているWindows Server」のような「関係」をキーにしてグループを作成するのはコンソールからは無理で、オーサリングツールを利用したりXMLを編集するような対応が必要です。 ここでは単純に複数のサーバーを1つのグループにまとめる方法を紹介します。一番良くやる事だと思いますので。諸事情によりSCOM 2007 R2の画面になっていますが、SCOM 2012, 2012 R2でも全く同じです。 ここでは、stcex2010,とstcdc2の2台のみを1つのグループに入れてみたいと思います。 「作成」にて新しいグループを作成します。 任意の名前と管理パックを指定します。(※ここであえてfor Demoという管理パックを選択して失敗する手順にしています。後で解説します。) ここでは明示的にオブジェクトを追加します。 ここで沢山選択肢があり、混乱するかもしれません。 何をしようとしているのかをもう一度確認します。 今、グループを作りたいのは「Windowsコンピュータ」の2台を1つのグループに入れたいのです。 上記のビューのプロパティを見てみると「Windowsコンピュータ」がターゲットに指定されています。 この「Windowsコンピュータ」というのは「クラス」です。「Windowsコンピュータ」クラスの具体的なオブジェクトとして「STCEX2010」「STCDC2」というものがあるわけです。オブジェクト指向プログラミングでいうところのクラスととインスタンス(≒オブジェクト)と同じ話です。 ですので、ここで「Windowsコンピュータ」を選択して検索をするとWindowsコンピュータの一覧が出てきます。 目的の2台のサーバーを追加します。 これでグループができました。 ビューを作成して、このグループを対象にして確認してみます。 「特定のコンピュータ」をグループとして選択するのはわかりやすいと思います。問題は左側でクラス定義を選択する所です。 今回は「Windowsコンピュータ」クラスを対象にしているので、ここも「Windowsコンピュータ」を選択すべきです。 これでうまくいきそうに思いますが・・・。OKボタンを押すと以下のエラーが表示されます。 封印していない管理パックの情報は他の管理パックから参照できないというルールがあります。これは封印していない=変更される可能性がある=他の管理パックから参照した場合にあとからそれが破綻するかもしれない→NGというロジックだと思われます。 なので、グループは「規定の管理パック」に作成する必要があります。 SCOM 2012 R2の環境では「規定の管理パック用言語パック」という名前でした。変な名前ですね。 これで、任意のコンピューターのみが表示されるビューを作成することが出来ました。 ここで利用しているグループはレポートの表示対象としても選択が可能です。 参考：How to Create Groups in Operations Manager

System Center Operations Managerの根幹を成しているのは「管理パック」です。「管理パックを導入して監視するんでしょ?」という程度の理解の方も多いと思いますし、本当に理解しようと思うと中々深いものだったりします。ここでは私なりに簡単にポイントを紹介したいと思います。 管理パックの実態はXML 管理パックは例えばWindows Server用のものは以下からダウンロードできます。 - [Download System Center Management Pack for Windows Server Operating System from Official Microsoft Download Center](http://www.microsoft.com/en-US/download/details.aspx?id=9296) ダンロードして、msiをインストールして該当フォルダを開いてみるとわかりますが、以下のように拡張子がmpというファイルが出てきます。これが管理パックそのものです。 テキストエディタ等で開いてみるとわかりますが、これ自体は人間が読める形にはなっていません。いわゆる「封印=seal」されている状態です。じゃぁ、実態はXMLじゃないじゃないか、と思われるかもしれませんが、SCOMに取り込んだうえで、PowerShellコマンドでエクスポートするときちんと生のXMLが見えてきます。 たとえば、Windows Server 2012の管理パックを見てみましょう。 Monitoring用とDiscovery用の2つの管理パックがあり、さらにそれぞれの日本語の言語パックがあることがわかります。 エクスポートします。 これで生のXMLの形で出力することができました。参考にOneDriveにおいておきましたので是非実際にXMLファイルの中身を覗いてみてください。 - http://1drv.ms/1njJsNj ガッツリとXMLで記述されている中でところどころvbscriptやpowershellが記述されています。 このように管理パックの実態はXMLであり、その中身が生で覗けますので、管理パックによって何がなされるのかは完全に把握することができます。 見つける、監視する、収集する では、管理パックの中で何をしているのか、ということですが非常にざっくりというと、以下の様な動きになっています。 - SCOMサーバーに取り込まれた管理パックはSCOMクライアントに送られる - まず、Discoveryのルールが実行され、監視目的のもの(=クラス)がそのシステムに存在するかどうかが判定される - 監視目的のもの(=クラス)が見つかった場合、そのクラスに対して定義されているモニタリングのルール(実態はvbscirptやpowershell)が実行される。 - 実行結果がSCOMサーバーに伝わり必要に応じてDBに記録されたり(パフォーマンスデータ等)、アラートが生成されたりする ポイントは「まず、監視対象が存在しているかどうかを判定する、見つける」というロジックが組み込まれている点です。管理パックのなかで「クラス」が定義され、そのクラスがある…という存在判定の定義があり、さらにクラスがあったならば行うべきルールが定義されているのです。 ですので、システム管理者はどのシステムにどの監視対象があるか、どの監視項目をどのサーバーに適用すべきか…というようなことを自分で把握、管理する必要なく、管理パックを導入すればそのなかで必要性を含めて判断してくれる…というわけです。 #もちろん必要に応じて意図的に「このサーバーは監視させない」というようなこともコントロール可能なわけですし、それ自体も管理パックで「上書き」することで実現されているのですが、ここでは深く説明はしないことにします。 管理者に見せる 最終的には収集した情報をSCOMのコンソール上やレポート上で「管理者に見せる」必要があります。ビューだったり、ダッシュボードだったり、レポートだったりです。この見せるための情報も管理パックに記述されています。 百聞は一見に如かず…というわけで、個人的にはSCOM管理パックの中身を直接覗くことをお勧めします。そうすればSCOMがどのようなコンセプトでどのように動作しているのかというのが非常にクリアにわかってくると思います。

System Center Operations Managerは様々なデバイスをそれこそオンプレミスのサーバーからアプリケーションからクラウドまでなんでも監視できます。もちろんネットワークデバイスの監視もバッチリ守備範囲です。非常に簡単な操作でネットワーク機器群を監視可能です。 基本的にネットワーク機器にきちんとSNMPの設定が行われていれば、たった1つのネットワーク機器に対して監視を行えばあとは芋づる式にデバイスを発見して監視してくれます。 technet上では以下の記事にネットワークデバイスの検出方法が書かれています。 - [How to Discover Network Devices in Operations Manager](http://technet.microsoft.com/en-us/library/hh278846.aspx) 以下簡単な実行方法です。 まず、検出ウィザードを実行します。 検出するデバイスとして「ネットワークデバイス」を選択します。 検出の種類を選択します。ネットワークデバイスを全て監視したい場合には「再帰的検出」を選択すると手間を大幅に減らすことができます。 ここで、検出に使用するアカウントを作成する…という表現になっていますが、SNMPのコミュニティ名を指定するだけなのでちょっと「アカウント」という印象とは異なります。 アカウント(SNMPコミュニティ名)の指定が終わったら次はネットワークデバイスを指定します。 アカウント情報は監視するサーバーに配布されている必要があります。ここでは「はい」を選択します。 ネットワーク検出ルール実行直後はまだ状態は「保留中」のままになっています。しばらく我慢して待ちます。 しばらくすると状態が「プロープ中」になります。 検出が完了すると、ネットワークデバイスが監視されます。

System Center 2012 R2のサイジング情報をまとめようとしてみています。まだまとめきっておりませんが、必要になったらこのページを更新していこうと思っています。情報がありましたら、コメント等で教えてもらえると嬉しいです。 なお、いつも英語版が更新されてから日本語版が後日翻訳および更新される…という感じですので極力英語のドキュメントを直接参照することをお勧めします。特にSPや新製品の登場でサポート状況が切り替わるタイミングでは英語版でしか最新の情報が確認できない期間があります。 SCCM - [Planning for Hardware Configurations for Configuration Manager](http://technet.microsoft.com/en-us/library/hh846235) - [Configuration Manager のハードウェア構成の計画](http://technet.microsoft.com/ja-jp/library/hh846235) - [Coretech Blog » Blog Archive » System Center 2012 Configuration Manager SQL recommendations](http://blog.coretech.dk/kea/system-center-2012-configuration-manager-sql-recommendations/) SCOM - [Operations Manager 2012 Sizing Helper Tool - System Center: Operations Manager Engineering Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/momteam/archive/2012/04/02/operations-manager-2012-sizing-helper-tool.aspx) - [System Requirements: System Center 2012 SP1 - Operations Manager](http://technet.microsoft.com/en-us/library/jj656654.aspx) - [システム要件: System Center 2012 SP1 - Operations Manager](http://technet.microsoft.com/ja-jp/library/jj656654.aspx) SCSM ...

System Center Operations ManagerではWindows OSのパフォーマンスカウンタを取得、保持し、グラフ描画を行うことができます。これはSCOMの基本機能なのでできるのは当たり前なのですが、データの取得単位と描画方法がそんなに細かくなく、しかも取得データが丸められてしまうので細かく見たいケースで困る…という話を聞いたので手元の環境で実際の動作を確認してみました。 以下、実際にルールを作成してみた結果です。 ルールの作成 Windowsパフォーマンスを収集するルールを作成します。 ここでパフォーマンスカウンターを取得する間隔を選択することができます。GUI上では最小単位は1分でした。 取得したパフォーマンスの「最適化」の選択が行えます。ここでの選択によりグラフの描画のされ方とデータベース容量が変化するわけですね。今回は生データを見られるように最適化を使用しない設定で進めました。 ビューの作成 収集ルールは作成したので、次はその結果を見るビューを作成します。 結果、以下のように1分単位での生データをそのまま表示することが出来ました。 というわけで、GUIで普通に作成する中では最小単位は1分間隔に見えました。もっと細かい単位で取得することもできるのかもしれませんがそれは調べていません。 SCOMをつかったパフォーマンスデータ収集はデータを長期間保存することが前提であることが多いと思われるので、この程度でも実用上は特に問題ないかなとは思います。

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)