System Center

Windows Server 2012で作成したHyper-Vクラスタが、いつからかきちんと動作しない状態になってしまっていました。 発生していた現象は以下のようなものです。 - 仮想マシンを起動しようとすると「コンピューター'xxxxx'のメモリまたはディスク領域が不足しているため、要求された操作の実行に失敗しました。」とのエラーで仮想マシンの起動ジョブに失敗する。しかし実際には起動できている。 - その他の操作も色々な場面で不規則に失敗したり、成功したりする。 - 仮想マシンのライブマイグレーションが実行できない。フェールオーバークラスタマネージャーからは実施できる。 - 仮想マシンの設定が開けない。SCVMMからも、フェールオーバークラスタマネージャーからも、Hyper-Vマネージャーからも同様。 クラスタノードを削除したり、エージェントを再インストールしたりなど色々と試したのですが改善しませんでした。結局、Webを検索し以下のフォーラムの情報を見つけました。 - [クラスタ共有ボリュームへの仮想マシン作成](http://social.technet.microsoft.com/Forums/ja-JP/winserver8/thread/b8207e48-8966-4941-9aa1-6882d85f6716) 原因はフォーラムでの情報と同じように物理ホストにMcAfee VirusScan Enterpriseを導入していたことでした。 VirusScan(オンアクセススキャン)を停止させることで問題なく動作するようになりました。 やはりWindows Server 2012への各種ソフトウエアの対応はまだまだですね。基本的な構成でも事前の確認が必要なようです。

Channel9にてMMS2013の動画が大量に187セッション分も公開されています。私にとってこのタイミングでのこの内容はヨダレが出るレベルで価値ある情報です。 - [MMS 2013 | Channel 9](http://channel9.msdn.com/Events/MMS/2013/) 全編英語で翻訳も無しなので英語ができないと厳しいです。こういう時には頑張って英語をやっていてよかったなと思います。SystemCenter系のセッションはかたっぱしから見て行きたい…ところですが、とりあえずRatingの高いものから見ていこうと思います。

Channel9にてMMS2013の動画が大量に187セッション分も公開されています。私にとってこのタイミングでのこの内容はヨダレが出るレベルで価値ある情報です。 - [MMS 2013 | Channel 9](http://channel9.msdn.com/Events/MMS/2013/) 全編英語で翻訳も無しなので英語ができないと厳しいです。こういう時には頑張って英語をやっていてよかったなと思います。SystemCenter系のセッションはかたっぱしから見て行きたい…ところですが、とりあえずRatingの高いものから見ていこうと思います。

VHDXファイルは簡単に拡張することができます。 この40GBのボリュームを拡張します。仮想マシンが起動し、マウントしたままでは拡張できないので、仮想マシンをシャットダウンします。 シャットダウンしたうで、仮想マシンのプロパティから該当ディスクを選択し、[VHDを拡張する]にチェックを入れて目的のサイズを入力します。 VHDを拡張した上でコンピューターを起動すると、上記のように未割り当て領域が見えるようになります。 この状態で、ボリュームを拡張します。この操作はOSが入っているパーティションに行うことはできないのでその場合には別のマシンにマウントするなりしてこの操作を行います。 あとはウィザードに従って進めます。 これでパーティションまで拡張することが出来ました。 非常に簡単に容量を拡張できるので楽でいいのですが、スナップショットが存在している状態でこの操作を行うとエラーが発生し、SCVMMから差分ディスクが見えなくなります。その状態でも容量は拡張されたし、正常に動いているようでもありますが、かなり気持ちが悪いです。スナップショットがある場合にはこの操作は行わないことをおすすめします。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCVMMでのVHDXファイルとパーティションの拡張方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/22/scvmm%E3%81%A7%E3%81%AEvhdx%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%A8%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E6%8B%A1%E5%BC%B5%E6%96%B9%E6%B3%95/)

Windows Serverバックアップの機能が追加されていないサーバーに対してDPMでベアメタル、システム状態の保護をしようとしても、整合性が取れません。これはWindows Server バックアップの機能を追加することで対処出来ます。 Windows Serverバックアップを追加した上で、整合性チェックを実施します。 これでも整合性が取れない場合には該当サーバーにてwbadmin.exeにて個別にテストを実施します。 wbadmin.exe start systemstatebackup -backuptarget:C: このコマンドが成功するようであれば、DPMからも成功するはずです。エラーが出るようであればそれを個別に対処します。ログファイルはC:WindowsLogsWindowsServerBackupにあります。 最終的にうまくいけば以下の用に保護の状態が「OK」になります。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [DPMでベアメタル回復、システム状態に対しての整合性が取れない場合の対処方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/03/dpm%E3%81%A7%E3%83%99%E3%82%A2%E3%83%A1%E3%82%BF%E3%83%AB%E5%9B%9E%E5%BE%A9%E3%80%81%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E7%8A%B6%E6%85%8B%E3%81%AB%E5%AF%BE%E3%81%97%E3%81%A6%E3%81%AE%E6%95%B4/)

64bit OSに対して32bitプログラムでレジストリに値を書き込むと、64bit版のレジストリエディタでは「HKEY_LOCAL_MACHINESoftwareWOW6432Node」に値が保存されます。32bitのレジストリエディタからは通常通りの値に見えます。 - [64 ビット バージョンの Windows でシステム レジストリを表示する方法](http://support.microsoft.com/kb/305097/ja) System Center Configuration Managerにてレジストリの中に書き込まれている値をインベントリで収集する場合にこの部分が混乱の元になります。 また、クライアントにインストールされるエージェントは基本的に以下のようになります。 - 32ビットOSにインストールされるエージェントは32ビット - 64ビットOSにインストールされるSCCMのエージェントは64ビット どちらのバージョンのエージェントが動いているかはタスクマネージャーでccmexec.exeを確認すれば確認する事ができます。 32bitでレジストリに値を書き込むようにしておき、それを64bitのクライアントから読もうとすると読めない!というような事になってしまう可能性があります。 対策としては、32bit、64bitにかかわらずレジストリの同じ場所に値が書き込まれるべきで、.net frameworkで作成されているプログラムであれば、これはプロジェクトのビルド設定でプラットフォームターゲットを「Any CPU」に設定すればOKです。 32bitOS上のVisual Studioで新規にプロジェクトを作った状態だと、この値はx86に設定されていました。注意が必要だと思います。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMでレジストリに値を格納、インベントリで取得するときの32bit, 64bitの違いについての注意点 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/01/sccm%E3%81%A7%E3%83%AC%E3%82%B8%E3%82%B9%E3%83%88%E3%83%AA%E3%81%AB%E5%80%A4%E3%82%92%E6%A0%BC%E7%B4%8D%E3%80%81%E3%82%A4%E3%83%B3%E3%83%99%E3%83%B3%E3%83%88%E3%83%AA%E3%81%A7%E5%8F%96%E5%BE%97/)

SCCMにはまだ触り始めたばかりですが、何度かインストールを繰り返しています。その中で「何もしていないのにエラーが出ている」という現象にすでに何度か遭遇しています。どうやら普通にインストーラーを走らせただけでもうまく構成が完了していないようなケースがあるようです。 ですので、インストール直後にはまず正常性の確認を実行。何かうまくいかないときにもすぐに正常性の確認を実行。…と、癖をつける必要がありそうです。 まず、確認すべきなのは[サイトのステータス]。以下の場所できちんとすべてのステータスがOKになっていることを確認します。 さらに、[コンポーネントのステータス]でもすべてのコンポーネントのステータスがOKになっていることを確認します。 上記はほぼインストール直後で境界および境界グループの設定後に何台かクライアントを導入しただけの環境ですが、エラーおよび警告が発生してしまっていました。 エラーメッセージを表示します。 上記からはActive Directory内のコンテナ、オブジェクトへの権限が無いか、スキーマ拡張がなされていない…という事がわかります。修正後、カウンタをリセットしてしばらくすればステータスはOKに戻ります。万が一問題が解決されていなければ再度ステータスは重大に変化します。 上記のエラーの例は単に私の操作ミスでしたが、何かあった時にはここにまず反応が出てきますので常に確認をするべきと思われます。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMの正常性確認は都度行う必要があるようです。 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/17/sccm%E3%81%AE%E6%AD%A3%E5%B8%B8%E6%80%A7%E7%A2%BA%E8%AA%8D%E3%81%AF%E9%83%BD%E5%BA%A6%E8%A1%8C%E3%81%86%E5%BF%85%E8%A6%81%E3%81%8C%E3%81%82%E3%82%8B%E3%82%88%E3%81%86%E3%81%A7%E3%81%99%E3%80%82/)

SCCM自体ほぼリアルタイムに反応するようなシステムではなく、設定が反映されるまでに長い時間がかかってしまいます。ですが、そういう環境でも「なるべく早く設定を反映したい、結果を得たい」という時にはクライアント側でアクションをキックする、ということができます。 クライアントアクションは以下のように多数存在しています。 クライアントコンピューター上で1台ずつすべて操作をするのも大変なので、スクリプトでキックできると素敵です。これはCPAPPLET.CPAppletMgrというCOMオブジェクトを使うことで可能です。以下、VBScriptとPowerShellのスクリプト例です。 [gist id=“4942879”] [gist id=“4942874”] 参考になれば幸いです。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMのクライアントアクションをスクリプトで実行する方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/16/sccm%E3%81%AE%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88%E3%81%A7%E5%AE%9F%E8%A1%8C/)

SCCMで何かうまくいかないことが起きた時には、ログファイルを確認することになります。サーバー側、クライアント側両方に多数のログが生成されているのですが、メモ帳で開いて見るのは中々厳しいログです。そこでサーバー上にログファイルを閲覧するためのツールが用意されています。 ツールの置かれている場所は"C:\Program Files\Microsoft Configuration Manager\tools\cmtrace.exe"です。 初回起動時には、*.logへの関連付けの設定が行えます。 サーバー上のログファイルは"C:Program FilesMicrosoft Configuration ManagerLogs"に格納されています。 何か問題がある場合には、問題の箇所が赤でハイライトされます。 単純にインストールしただけなのにうまく動いていない事が結構あるので、ログファイルはこまめにチェックしたほうがよさそうです。 ログファイルの場所に関しては以下のKBに記載されています。 - Configuration Manager のログ ファイルのテクニカル リファレンス http://technet.microsoft.com/ja-jp/library/hh427342.aspx あまりにも多くのログファイルがあってクラクラしますね…。 さらに、このツールはクライアントPCにコピーすればクライアントPC上のログの確認にも使えます。ノートパットで見るよりもはるかに便利なので是非使ってみて下さい。追記されたものも自動的に見られて便利です。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMのログファイルの確認方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/13/sccm%E3%81%AE%E3%83%AD%E3%82%B0%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E7%A2%BA%E8%AA%8D%E6%96%B9%E6%B3%95/)

SCCM Clientがすでにインストール済みかどうかを判定する必要がありました。色々と方法が考えられます。 - インストールログ内の成功の時だけに出る文字列を探す - クライアントエージェントの実行ファイルの存在有無で判定する - レジストリ内にキーが存在するかどうかで判定する 他にも色々あると思います。 そんな中で今回は、クライアント上でサービスが存在しているかどうかを判定基準にすることにしました。具体的には以下のような感じです。 sc query CcmExec > nul if %errorlevel%==0 goto Installed :Not_Installed echo “SCCMクライアントはインストールされていません。” goto end :Installed echo “SCCMクライアントはインストールされています。” goto end :end 「CcmExec」というのがSCCM Clientのサービスの名前なのでその存在をscコマンドで確認しています。 2013/02/15追記 上記のロジックは、Windows7では正常に動作するのですが、WindowsXPでは正常に動作しないことがわかりました。Windows XPではsc query CcmExecが失敗してもerrorlevelとして0を返してくるからです。そこで以下のようにきちんとscコマンドの結果としてサービス名が表示されていることを判定するようにしました。これならWindows7, Xpの両方で動作します。その他OSは未テストですが、おそらくうまく動作すると思います。 [gist id=4958024]

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCM Clientがインストール済みかどうかを判定する方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/12/sccm-client%E3%81%8C%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E6%B8%88%E3%81%BF%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E3%82%92%E5%88%A4%E5%AE%9A%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95/)

TechnetRadioにてSystemCenter2012のRTMからSP1へのアップグレード方法が動画で紹介されています。 全編英語で字幕も無しではありますが、アップグレードの様子を実際の画面で見せてくれるので英語が苦手でも大丈夫だと思います。 #私は長年の英語勉強のおかげでほぼすべて聞き取ることができて(できたつもりになることができて)、頑張ってよかったなぁという感じです。 概要は以下です。 - RTMからSP1はインプレースアップグレードできる。 - 前提条件としてADK内のコンポーネントを3つだけいれる必要がある。これは前提条件チェックで教えてくれる。 - クライアントのバージョンアップも必要。やり方は色々あって何でもいいがおすすめはサイト設定から「Automatic Client Upgrade」を有効にする方法。 「SP1はインプレースでアップグレードできるからすごい！」っていうのりだったけど、ServicePackはインプレースできて当たり前であって、そうできない方が…という気も…。(まぁ、SystemCenter2012SP1はほとんど別製品みたいなところはありますが。) 動画は以下です。25分程度あります。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCM2012 RTMからSP1へのアップグレード方法(動画) | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/01/25/sccm2012-rtm%E3%81%8B%E3%82%89sp1%E3%81%B8%E3%81%AE%E3%82%A2%E3%83%83%E3%83%97%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%89%E6%96%B9%E6%B3%95%E5%8B%95%E7%94%BB/)

MCP70-246を取得する必要があり、講習で「ホストベースでバックアップを取得した仮想マシンをファイル単位でリストアするにはDPMサーバーにHyper-Vロールをインストールする必要がある。」ということを教えてもらいました。練習問題を通してです。これは一体どういう事なんでしょうか。本当でしょうか。 ファイル単位でのリストアとHyper-Vロールが関係する……ということはアイテム単位のリストア時には以下のような内部処理になるという事でしょうか?(※以下は私の推測です。) - バックアップはVHDファイル等の仮想マシンを構成するファイル単位で行われる。 - アイテム単位のリストア時には一度自身のローカルディスク上に、上記のバックアップファイルをリストアし、それを自身のHyper-V上の仮想マシンとして動作させる。 - 上記の仮想マシンからアイテム単位で取り出す。 うーん。こんな事をしなくても普通にVHDファイルをマウントしてそこから中身を取り出せば良いだけに思います。そして、VHDファイルを直接マウントする機能はWindows Server 2008 R2から実装されています。 - [Windows 7／Windows Server 2008 R2でVHDファイルを直接マウントする － ＠IT](http://www.atmarkit.co.jp/fwin2k/win2ktips/1231vhdmount/vhdmount.html) もしかして、この制限はSCDPMやOSが古いバージョンの際の制限であり、SCDPM 2012, 2012 SP1あたりでは撤廃されている制限だったりしないのでしょうか?と、気になったので、情報を確認してみます。 まず、Hyper-Vロールを入れないとだめよっていう情報は以下のあたりにあります。 [DPM 2010 管理者コンソール] の [回復] タブの画面から、任意の回復ポイントを選択することでリストアを行うことができます。また、VM 単位でのリストアが可能である他、DPM サーバーに Hyper-V サーバーとしての役割がインストールされている場合は、さらに、VM 内のアイテムレベルでのリストアも可能となります。 DPM 2010 による Hyper-V 2.0 CSV 環境での仮想マシンのリストア - Japan System Center Support Team Blog - Site Home - TechNet Blogs DPM 2010に対しての言及であり、このときにはWindows Server 2008 R2も存在しているのでOSの制限で…というわけではなさそうです。DPM 2012, 2012 SP1あたりではどうなのでしょうか。 If you use a version of Windows Server that is earlier than Windows Server 2008, you must have the Hyper-V role enabled on the DPM server to perform item-level recoveries. During item-level recovery, DPM has to mount the VHDs of the protected virtual machines. Recovering Hyper-V data DPM 2012 SP1の情報ありました。はやり2008 R2以降であればhyper-vロールが無くてもアイテム単位で戻せるようですね。私の予想は当たっていたようです。 ...