SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
本日 [Microsoft SQL Server code-named ‘Denali’ CTP1] の提供が開始されました。
Code Name Denali ですが、次期 SQL Server の CTP 版になります。
# SQL Server 2011 になるのかなと。 
SSMS が VIsutal Studio 2010 ベース (.NET Framework 4.0 もインストールされます) に変更されています。 
SSMS が刷新され、レポートが Word 形式でもエクスポートできるようになりました。 
PDF のレポートに関してもフォントが埋め込まれるようになったみたいですね。 
Availability Groups という機能が増えているようなのですが、これは WSFC の必要があるようですね。
日本語の照合順序に関しては、[Japanese_XJIS_100] が最新のようですね。 
まだ、ヘルプが見れないので新規にどのような機能が入ったのかは調べられていないのですがクラスタに関しては今週中に構築してみたいと思います。
SQL Server の管理をするために使用する SQL Server Management Studio (SSMS) ですが、サーバーにはインストールをしているケースが多いと思いますが、保守用のクライアントには入っていないことがあるかもしれないです。
そんな時に便利なのが RemoteApp。
正確に言うと以下の更新プログラムをインストールすることで使用できるようになる、アプリケーションのコンソールリダイレクト機能を使用します。
# Windows 7 / 2008 / 2008 R2 は更新プログラムをインストールしないでも使用できます。
RemoteApp? を有効にするための WindowsR XP SP3 用の更新プログラム
RemoteApp? を有効にするための WindowsR Vista SP1 以降用の更新プログラム
残念ながら Windows Server 2003 用はないのですよね…。
これが使用できるのは、Windows XP SP3 / Windows Vista SP1 以降 / Windows 7 / Windows Server 2008 / Windows Server 2008 R2 上で実行されているプログラムをクライアントで使用したいときに限定がされます。
XP / Vista の初期で使用されている、RDP 6.x 系でも使用できます。
最新の RDP 7.0 を使用したい場合は以下の更新プログラムをインストールします。
Windows XP 用の更新プログラム (KB969084)
Windows Vista 用の更新プログラム (KB969084)
有効にするための方法はいろいろとあるのですが一番単純なのは、起動したいアプリケーションがインストールされているサーバー (今回は SQL Server をインストールしているサーバー) で以下のレジストリを 1 にすることだと思います。
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTsAppAllowList]
[fDisabledAllowList] (REG_DWORD) 
デフォルトは [0] になっていますのでこれを [1] に変更します。
# 再起動は不要です。
これでサーバーで起動できるアプリケーションをリモートデスクトップ経由でリダイレクトできるようになります。
サーバーのアプリケーションを利用したい端末で以下の内容を記載した [.rdp] という拡張子のファイルを作成します。
IP アドレスを記載している部分は接続したいサーバーの IP アドレスに変更してください。
# 最後の行は改行されてしまっていますが一行で記載します。
|
full address:s:192.168.0.1 |
リモートデスクトップを使用していますので、サーバー側でリモートデスクトップを有効にする必要もあります。
# 3389 はリモートデスクトップのポートですので。 
上の画像では、NLA (ネットワーク レベル認証) で設定をしていますが、NLA でない設定でも問題はありません。
後は作成した RDP ファイルを実行して、リモートデスクトップ接続をすれば RemoteApp で SSMS を起動することが可能です。 
SSMS が起動してきているのですが、[(リモート)] となっているのが確認できます。
これはリモートデスクトップ経由でアプリケーションが実行されていることになります。 
タスクマネージャーから確認をしても同様に (リモート) となっています。 
リモートデスクトップで接続ができる環境にインストールされているプログラムを透過的に利用したい場合は結構便利だと思います。
私は、XP の環境で Hyper-V マネージャーを使用したい場合にもこの方法を使用して使っていたりします。
# UAC が働くので、一度ダイアログが表示されてしまいますが。 
先日、
@IT などを運営されている
アイティメディア株式会社様
の会議スペースをお借りして開催された、SQL Server の勉強会に参加をしてきました。
その勉強会の中で SQL Server の [Resource] データベースについて質問を受けたので、このデータベースについて少し書いてみたいと思います。
Resource データベースに関しては、Books Online で以下のように記載されています。
|
Resource データベースは、読み取り専用のデータベースで、SQL Server に含まれるすべてのシステム オブジェクトがこれに格納されます。 |
各データベースのシステムビューやシステムストアドプロシージャーなどで使用されている、[sys.xxxx] 関連の情報は [Resource] データベースの内容を透過的に参照している形になります。
# Resource データベースは SSMS (SQL Server Management Studio) には表示されません。 
普段何気なく使用している、[sys.master_files] のようなシステムビューですが、これは [ビュー] と名前がついている用に実体ではなく、実表を参照しているものになります。
ではこの実体はどこに格納されているかというと実体は [master] データベースに保存されています。
試しに [sys.master_files] のビュー定義を確認してみたいと思います。
確認するためには、[SELECT OBJECT_DEFINITION(OBJECT_ID(‘sys.master_files’))] というように OBJECT_DEFINITION を使います。
|
CREATE VIEW sys.master_files AS |
ビューの元になるデータは [master.sys.sysbrickfiles] というテーブルになっています。
Resource データベースはこのようなシステムビューやシステムストアドプロシージャを格納し、master 上に格納されている情報を透過的に見せるために使用されています。
# 今回のベース表になっている、[master.sys.sysbrickfiles] は直接参照できないので。
この Resource データベースですが、以下の 2 つのファイルから構成されています。
通常、システムデータベースは
[C:Program FilesMicrosoft SQL ServerMSSQL10_50.<インスタンス ID>MSSQLDATA]
というディレクトリに格納されるのですが、リソースデータベースのファイルは、
[C:Program FilesMicrosoft SQL ServerMSSQL10_50.<インスタンス ID>MSSQLBinn]
に格納がされます。
インスタンスのプログラム扱いでファイルが格納されていますね。
この Resource データベースですが、バージョンがあり [SELECT SERVERPROPERTY(‘ResourceVersion’)] というクエリを実行することでバージョンを確認することができます。
このバージョンですが、SQL Server のバージョンと一致するようで、
となります。
修正プログラムをインストールすると、Resource データベースのバージョンも更新されます。
Resouce データベースには実データではなく実データを見せるための定義が格納されているので、Books Online で
|
SQL Server では、Resource データベースをバックアップできません。 |
と書かれているのは、実データは含まれず定義のみが格納されており適切なバージョンの SQL Server をインストールすれば最適な状態になるからだと思います。
Resource データベースは SSMS に表示がされないので通常はどのような情報が格納されているのか見ることはできないのですが、実はデータベースのファイルをコピーしてアタッチすることで内容を確認することができます。
# mssqlsystemresource.mdf / ldf は読み取り専用で SQL Server 上で認識されているのでオンラインでもコピー可能です。
通常のアタッチでは、以下のようなエラーになります。 
このエラーですが、[mssqlsystemresource] というデータベース名でアタッチをしようとしたために発生しています。
# Resource データベースですが内部的には、[mssqlsystemresource] で認識されているためだと思います。
[次の名前でアタッチ] のデータベースの名前を変更することで Resource データベースをアタッチすることが可能です。
今回は、Resource というデータベース名でアタッチしています。 
アタッチをすることで Resource データベースの内容を直接確認することが可能になります。 
通常、[sys.xxxxx] はシステム ビューやシステム ストアド プロシージャーとして認識されているのですが、アタッチした Resource データベースではユーザービュー / ユーザー ストアド プロシージャーとして認識がされます。
# システムビューやシステム ストアド プロシージャーとしても認識はされるのですが。
システム ビュー / システム ストアド プロシージャーの状態では、スクリプト化ができないため [OBJECT_DEFINITION] を介して定義を確認していました。 
ユーザーオブジェクトになっていればスクリプト化が可能なため、[sys.xxxx] といったものも簡単に内容を確認できます。 
Resource データベースは SQL Server 2005 になってから搭載されたものなのですが、通常使用している中ではあまり意識はしないので、どんなデータが入っているのかイメージがしにくいのですよね…。
# 私は、sys. 系の定義が入っているだけだと考えているのですが。
OpsMgr の勉強の続きです。
OpsMgr ではインストール時にいくつかのサービスアカウントの設定があります。 
ローカルシステムアカウントやローカル Administrator を使用するとインストールすることはできるのですが、実運用環境に置いては権限が強すぎる、アカウントを変更する必要があるというケースが考えられると思います。
インストール時に指定したアカウントが設定される個所についてみていきたいと思います。
アカウントに関しては、OpsMgr の管理コンソールの [管理] アカウントで大体のユーザーを確認することができます。
各アカウントがどのように使用されるかは以下の技術情報に記載されています。
Operations Manager 2007 のアカウント情報
管理サーバー アクション アカウントに関しては、ローカルの [Users] グループのユーザーで設定が可能なようです。
最低限の権限を持つユーザーで設定ができるようですね。
管理サーバー アクションアカウントは、[種類:アクション アカウント] に設定がされます。 
[Local System Action Account] はデフォルトで作成されます。
このアカウントには、[Local System] (ローカルシステムアカウント) が設定されており、管理サーバー アクション アカウントを [ローカルシステム] で設定した場合には、このアクションアカウントのみが作成された状態になります。 
アクションアカウントについては、[実行アカウントの作成] で [アクション アカウント] を選択することで新規に作成ができますので、アカウントを変更したいとなったら、新規に実行アカウントを作成すれば良さそうですね。 
[Local System Action Account] 以外に関しては、ユーザー名を変更することができますので新規に作成しなくても変更することで対応ができそうです。 
[ローカル セキュリティ ポリシー] の [ユーザー権利の割り当て] として以下の権限が付与されているようです。
[サービスとしてログオン] 
サービスアカウントとして、アクションアカウントが設定されているサービスはないのですが、[サービスとしてログオン] の権限が付与されているようでした。
SQL Server のログインとしても設定がされていますのでこちらも変更の必要がありそうです。 
SDK と Config サービスアカウントに関しては、ローカルの [Administrators] グループのユーザーの必要があるようです。
Administrators グループに属していないユーザーをアカウントに設定しようとするとこのようなエラーになります。 
このエラーですが、サービスアカウントとしてローカルユーザーを使用する場合も表示されるようで、ローカルアカウントを使用する場合はローカルの [Administrator] でないと駄目でした。
# Administrators グループのローカルユーザーではインストールできませんでした。
ここで設定したアカウントに関しては、OpsMgr の管理コンソールで指定できるアカウントではなくサービスアカウントとして設定がされます。
変更については技術情報が提供されています。
Operations Manager 2007 で SDK と Config サービス アカウントを変更する方法
設定したアカウントは以下のサービスのアカウントとして設定がされます。
[Ops Mgr VSS Writer Service] 
このサービスに関しては上述の技術情報に記載されていないのですよね…。
ただ、サービスアカウントとしては設定がされていますので、変更の必要はあると思います。
[System Center Data Access] 
[System Center Management Configuration] 
[ローカル セキュリティ ポリシー] の [ユーザー権利の割り当て] として以下の権限が付与されているようです。
[サービスとしてログオン] 
[セキュリティ監査の生成] 
こちらも SQL Server のログインができていますので作成する必要がありそうです。 
このアカウントはローカルの [Users] グループで問題ないようです。
データウェア ハウス 書き込みアカウントは [種類:Windows] の [データウェアハウス アクション アカウント] として設定がされます。 
実行アカウントを作成する場合は [Windows] で作成すれば良さそうですね。 
このアカウントは編集することができますので、新規に作成しなくてもすでに作成されているアカウントを変更することでも対応できそうです。 
データベース用のアカウントですので、SQL Server にもログインが作成されています。 
このアカウントはローカルの [Users] グループで問題ないようです。
データウェア ハウス 書き込みアカウントは [種類:Windows] の [データウェアハウスのレポート展開アカウント] として設定がされます。
実行アカウントを作成する場合はデータウェアハウス アクション アカウントと同様 [Windows] で作成すれば良さそうですね。 
このアカウントも編集することが可能です。 
データリーダーアカウントについてはサービスのアカウントとしても設定されています。
[SQL Server Reporting Services] 
Reporting Service のサービスアカウントとしても設定がされるみたいですね。
OpsMgr の Reporting Service のアカウント変更に関しては技術文書が提供されています。
Operations Manager 2007 でレポート サーバー実行アカウントのパスワードを変更する方法
サービスからではなく [Reporting Services 構成マネージャー] から変更を行います。 
ローカルセキュリティポリシーとしてもいくつか権限が付与されているようです。
[サービスとしてログオン] 
[バッチジョブとしてログオン] 
SQL Server のログオンとしても設定がされています。 
ここまで書いた内容を簡単にまとめると下表のようになります。
| アカウント | グループ | OpsMgr アカウント | サービス | ユーザー権利の割り当て | SQL ログイン |
| 管理サーバー アクション アカウント |
Users | アクション アカウント | サービスとしてログオン | あり | |
| SDK と Config サービスアカウント |
Administrators | OpsMgrVSSWriter OMSDK OMCFG |
サービスとしてログオン セキュリティ監査の生成 |
あり | |
| データウェア ハウス 書き込みアカウント |
Users | データ ウェアハウス アクションアカウント |
あり | ||
| データ リーダー アカウント | Users | データウェアハウスの レポート展開アカウント |
ReportServer |
サービスとしてログオン |
あり |
インストール時に暫定アカウントとして使っていない限り変更の必要はないとは思いますが、設定したユーザーがどこに設定されているかを知っていると便利かなと思いまとめてみました。
Winodws Server 2008 R2 SP1 RC のインストールが終わったので Hyper- マネージャーを少し触っています。
Windows Server 2008 R2 SP1 RC の評価ガイドは以下からダウンロードできるのですが現状は Beta の内容がベースになっているようで、RC での変更点は記載されていないようでした。
Windows Server 2008 R2 SP1 RC Reviewer’s Guide
Download Windows Server 2008 R2 Technical Whitepaper
Hyper-V マネージャーは RTM / Beta / RC で設定できる内容や表示内容に変更があります。
それぞれを比較していきたいと思います。
SP1 Beta / RC で起動した仮想マシンですが、構成ファイルに SP1 特有の定義が入るためエクスポートしても RTM にインポートできなくなりますのでご注意ください。
# エクスポート前やエクスポート後の構成ファイルを手で書き換えればインポートできるかもしれませんが…。
■仮想マシンの一覧画面
SP 1 では Dynamic Memory の機能が追加されています。
SP1 以降では、仮想マシンの一覧画面が Dynamic Memory に対応した表示になっています。
[RTM] 
[SP1 Beta] 
[SP1 RC] 
Beta では、[現在のメモリ] [使用可能なメモリ] という表示だったものが、SP1 Beta では、[Assgined Memory] [Memory Demand] [Memory Status] という表示になっています。
Beta では、[現在のメモリ] に、仮想マシンに割り当てらている物理メモリ、[使用可能なメモリ] に [(現在のメモリ – 仮想マシンのコミットチャージ) / 現在のメモリ] の値が表示されています。 
Dynamic Memory で仮想マシンにメモリが割り当てられる場合は、使用可能めなメモリがマイナスを示すことはありませんが、メモリが割り当てられなくなり、コミットチャージが割り当てられている物理メモリを超えた場合、この値はマイナスになります。 
上の画像は使用可能なメモリがマイナスとなっているときの仮想マシンの状態になります。
# Dynamic Memory はスタートアップ RAM が 1024 MB、最大 RAM が 1536 MB で設定しています。
[コミット (MB)] が 2046 MB になっていますが、[現在のメモリ] は 1536 MB になっています。
そのため、[(1536 ? 2046) / 1536 = ?0.33203125 = ?33%] となります。
仮想マシンに割り当てられているメモリが足りていないということですね。
SP1 RC だと、[Assgined Memory] [Memory Demand] [Memory Status] の 3 項目に表示が変更がされています。 
Beta の [使用可能なメモリ] に相当するのは、[Memory Demand] と [Memory Status] に分けられたようです。
仮想マシンのコミットチャージが [Memory Demand] に表示され、[Assigned Memory] と [Memory Demand] の比較が [Memory Status] に表示されます。
[Assigned Memory] と [Memory Demand] の値に差がある (メモリに余裕がある) 場合は、[OK] が表示されます。 
[Assigned Memory] と [Memory Demand] の値に差がな少ない (メモリに余裕が少ない) 場合は、[Low] が表示されます。
具体的にどれくらいの値になると [Low] になるかが記載されているドキュメントは見つからなかったのですが、割合が 86% ぐらいになると Low にはなるようでした。
[Memory Demand] が [Assgined Memory] を超えた (メモリに余裕がない) 場合は、[Warning] となります。 
NUMA アーキテクチャが使われている環境では、NUMA ノード内のメモリに当てはまる範囲で、仮想マシンのメモリを設定するのがベストプラクティスとなっています。
# NUMA ノード内に当てはまらないメモリを割り当てた場合、パフォーマンスが低下することがあります。
Hyper-V のパフォーマンスおよび容量の要件
SP1 では、[Hyper-V の設定] の設定が追加されています。
[RTM] 
[SP1 Beta] 
[SP1 RC] 
SP1 では、[NUMA ノードにまたがるメモリ割り当て] という設定が追加されています。
デフォルトでは、[仮想マシンに NUMA ノードをまたがるメモリを割り当てる] が有効に設定されています。
この設定ですが変更をすると再起動が必要となりますので、稼働中は変更することができないので注意が必要です。 
この設定ですがレジストリに格納がされています。 
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionVirtualizationNumaSpanning]
この DWORD に値が設定されます。
[仮想マシンに NUMA ノードをまたがるメモリを割り当てる] を有効にしている場合は、[1] が、無効にしている場合は、[2] が設定されます。
RTM からアップグレードした場合は DWORD が存在していないようです。存在しない場合は有効という判断なのかもしれないですね。
Dynamic Memory のバッファの設定方法が SP1 Beta と RC では変更されています。
[RTM] 
[SP1 Beta] 
[SP1 RC] 
SP1 Beta ではメモリバッファーはスライドバーだったのですが、SP1 RC ではテキストボックスに変更がされています。
RetemoFX 関連の設定に関しては変わっていないようですね。 
RTW した際にはまた変更されているかもしれませんが、ひとまず気づいたことをまとめてみました。
先日 Windows Server 2008 R2 SP1 RC の提供が開始されました。
Windows 7 および Windows Server 2008 R2 Service Pack 1 (SP1) Release Candidate (RC) のダウンロード
インストールの方法などを軽くまとめてみたいと思います。
# Windows 7 SP1 RC のインストールも同様の内容になります。
SP1 Beta をインストールしている状態で、SP1 RC をインストールしようとすると以下のエラーになります。 
SP1 Beta をインストールしている状態では、SP1 RC をインストールすることはできません。
SP1 RC のダウンロードページにも以下の記載がされています。
|
Windows 7 または Windows Server 2008 R2 の Service Pack 1 Beta がコンピュータにインストールされている場合は、Release Candidate をインストールする前にその Beta をアンインストールする必要があります。 |
よく寄せられる質問にもこのことは記載されています。
Windows 7 および Windows Server 2008 R2 Service Pack 1 (SP1) Release Candidate (RC) に関してよく寄せられる質問
SP1 Beta をインストールしている場合はアンインストールをする必要があります。
アンインストールについては技術情報が用意されています。
# Windows 7 用の技術情報ですが Windows Server 2008 でも同様です。また、RC 用ですが Beta でも使えます。
Windows 7 SP1 RC 版をアンインストールする方法
アンインストールは簡単で、[KB976932] の更新プログラムをアンインストールすると完了します。 
アンインストール終了後、再起動をすれば一連の作業は完了です。
再起動時にもアンインストール処理が走っているので結構時間がかかります…。 
こちらが SP1 Beta の winver の結果です。 
アンインストールをするとバージョンが RTM のものに変更されます。 
この状態になると SP1 RC が適用可能となります。
それでは、SP1 RC を適用してみたいと思います。
今回は ISO 版を使用しているので [setup.exe] を実行します。
# 各 SP を単体でダウンロードした場合は、ダウンロードしたファイルを実行します。
/x を使用するとファイルを手動で展開することが可能です。
セットアップを起動したら、[次へ] をクリックします。 
[同意します] を有効にして、[次へ] をクリックします。 
[インストール] をクリックして、インストールを開始します。 
再起動されるとインストールは完了です。 
SP1 RC のインストールが完了した後の winver の内容がこちらになります。 
Windows Server 2008 R2 RC の winver には有効期限が表示されていないのですが、[2011 年 11 月 30 日] が使用期限となるようです。
SP1 RC の検証については別の機会にまとめていきたいと思います。
少し System Center も触れるようになりたいなと思い、まずは System Center Operations Manager 2007 R2 (OpsMgr) から勉強を始めてみました。
# PRO 機能と絡めればおもしろそうだと思ったので。
OpsMgr で使用できる SQL Server は以下の技術情報に記載されています。
Operations Manager 2007 R2 でサポートされている構成
日本語の技術情報では、[Operations Manager の Operations データベース] には [SQL Server 2008] までしか記載がされていないのですが、英語の技術情報の [Operations Manager Operations database] には、[SQL Server 2008 R2] が記載されています。
Operations Manager 2007 R2 Supported Configurations
SQL Server 2008 R2 を使用したインストールについては KB が提供されています。
Support for System Center Operations Manager 2007 R2 that runs on a SQL Server 2008 R2 database
OpsMgr のインストーラーでデータベースを作成するのではなく、手動でデータベースを作成してそれを使うように OpsMgr をインストールすることで、SQL Server 2008 R2 を使用することが可能です。
# SQL Server 2005 SP1 または、SQL Server 2008 でインストールをして、SQL Server 2008 R2 にアップグレードするという手法もあるようなのですが、今回は新規インストールした SQL Server 2008 R2 を使用します。
ひとつ気になっているのは、
|
The Alert View window does not open when you click the Alert View link in the notification emails. |
という記載があるところでしょうか。
通常の操作で、アラートビューでどのようなことができて、SQL Server 2008 R2 を使った場合にどのような挙動になるのかがわかっていないのですが…。
機能としては以下のコンポーネントをインストールすれば OpsMgr 用のデータベースとして使用することができます。
# 管理ツールは必須ではないのですが、あると便利なのでインストールしています。 
SQL Server 2008 R2 のインストールで OpsMgr に合わせた設定は以下の 2 点になります。
この設定でインストールした SQL Server を使用して、OpsMgr をインストールしていきます。
今回は Windows Server 2008 R2 にインストールをします。
OpsMgr をインストールするためには IIS をインストールする必要があります。
IIS で必要となる役割は以下の KB に記載がされています。
Windows Server 2008 を実行しているコンピューターで System Center Operations Manager 2007 の Web コンソールのインストールに失敗する場合がある
この KB は Windows Server 2008 用のものですが、Windows Server 2008 R2 でも役割の機能を追加すれば OpsMgr をインストーすることが可能です。
他には、ASP.NET Ajax Extensions 1.0 が必要になりますので、以下の URL からダウンロードしインストールしておく必要があります。 
ASP.NET AJAX 1.0
.NET Framework 3.5 も必要になるのですが、これに関しては SQL Server 2008 R2 をインストールする際にインストールをしていますので、OpsMgr の前提チェックではエラーになりません。
それでは、OpsMgr をインストールしていきたいと思います。
OpsMgr の基本的な機能を使用するためには、[Operations Manager 2007 R2 のインストール] と [Operations Manager 2007 R2 レポートのインストール] を実行します。 
Operations Manager 2007 R2 のインストールをデフォルトの設定のまま行おうとすると、以下のコンポーネントが選択された状態となっています。 
この状態でインストールをしようとすると、前提条件の確認をパスすることができません。 
[ログの表示] をクリックして、内容を確認してみます。
そうすると SQL Server のチェックでエラーとなっていることが確認できます。 
SQL Server 2008 R2 を使用する場合、インストーラーでデータベースを作成することができません。
データベースに関しては手動で作成する必要があります。
手動で作成する際の手順は以下の内容になります。
以上でデータベースの手動作成は完了です。
再度インストールを実行して、インストールするコンポーネントから [Database] を外すと、前提条件のチェックをパスすることができます。 
下の画像では、警告付きとなっていますがこれはメモリが 1.5 GB の環境でインストールをしているためです。
# OpsMgr のインストールは 2GB 以下のメモリだと警告になります。正常にインストールはできるので問題はありませんが。 
データベースの設定になったら、先ほどデータベースを作成したサーバー名を指定します。 
あとは通常の OpsMgr のインストールと同じです。
まずは検証してみたいということであれば、すべてのサービスアカウントを [ローカル システム] に設定するとインストールを行うことができます。
# 後の設定はデフォルトで。 
[完了] をクリックして、インストールを完了します。
[暗号化キーのバックアップ] は [SecureStorageBackup.exe] を手動で実行することで後から実行することも可能ですので、今回はバックアップが起動したらすぐに閉じて終了しています。 
■Operations Manager 2007 R2 レポートのインストール
続いて [Operations Manager 2007 R2 レポートのインストール] を実行します。
こちらもデフォルトでは、[Data Warehouse] がインストールされる設定になっています。 
この設定のままインストールを続けると前提条件をパスすることができません。 
ログの表示でエラーを確認すると先ほどと同じで、SQL Server でエラーとなっています。 
レポート用のデータベースもインストーラーからではなく、手動で作成する必要があります。
以上でデータベースの手動作成は完了です。
再度インストールを実行して、インストールするコンポーネントから [Data Warehouse] を外すと、前提条件のチェックをパスすることができます。
ルート管理サーバーとしては、OpsMgr をインストールしているサーバーを指定して、[次へ] をクリックします。 
データベースサーバー、Reporting Serives サーバーも自サーバーですので、OpsMgr をインストールしているサーバーを指定して、[次へ] をクリックします。 
Repoting Services のサーバーを選択して、[次へ] クリックしたタイミングで応答がなくなる (砂時計のアイコンになったまま次の画面に遷移しない) ことがたまにあるのですが、その場合はタスクマネージャーを起動して、[msiexec.exe] のプロセスを終了させると画面が遷移します。 
次の画面は、データウェアハウス用のアカウント設定画面になります。
検証の場合は、データウェアハウス用のアカウントはローカルの Administrator を設定すると早いかもしれません。 
あとはデフォルトの設定でインストールを行います。 
このままインストールをすると以下のエラーが発生します。 
最後の手順として、Reporting Service で使用されているグループの名前を一時的に変更する必要があります。
この状態で再度インストールを実行すると今度はエラーが発生しない状態で完了します。 
インストールが完了したらグループ名を元に戻します。 
OpsMgr でサーバーが管理できていることを確認してみたいと思います。 
レポートも表示できていますので、Reporting Serivces との連携もできています。 
OpsMgr の現時点の最新版は OpsMgr 2007 R2 CU3 になりますので、CU3 も適用を検討しておいた方が良いかと。
System Center Operations Manager 2007 R2 Cumulative Update 3 (KB 2251525) – 日本語
操作方法についてはこれから勉強しないと。
今日は検証がしたい内容があり、Exchange 5.5 の環境をすこし触っていました。
OWA を使って基本的な確認が終わったので、Outlook を使っても確認がしたいなと思って、手元にあった Windows XP + Outlook 2007 の環境で Exchange 5.5 に接続をしようとしたところこのようなエラーが。
[サポートされていないバージョンの Microsoft Exchange 上にあります。] とのメッセージが。
Exchange 5.5 だから仕方ないですかね…。
このメッセージですが、英語だとこのような内容になるようです。
| Cannot open your default e-mail folders. the resource that you are trying to use is located on an unsupported version of Microsoft Exchange |
Exchange 2010 で接続ができないときの定番である暗号化の設定についても Outlook 側は無効にしても接続はできませんでした。 
このメールボックスですが、Outlook 2003 からは接続ができるのでサーバーの設定としては特に問題はなさそうなんですよね。
今回は Outlook 2007 で Exchange 5.5 に対して MAPI で接続するという要件の検証ではなく、たまたまテストで使っていたゲスト OS にインストールされている Outlook が 2007 だっただけなのであっさりあきらめて、Outlook 2003 に切り替えてしまいました。
英語のメッセージを参考に検索エンジンで調べてみたところ、Exchange 5.5 は非サポートなのでつながらないのではという内容の情報がかなり見つかったので、この組み合わせで MAPI でつながらないのは有名な話なのかもしれないですね。
MAPI では接続ができないのですが、POP3 を使ってみたところ正常に接続ができ、メールの配信も可能でした。 
めったに使うことのない情報だと思いますが、メモとして。
作成された展開用パッケージのインストールについてまとめていきたいと思います。
展開用パッケージをインストールする前に、MED-V のクライアントコンポーネントをインストールする必要があります。
これで展開用パッケージをインストール可能にするためのクライアントコンポーネントがインストールされます。
このクライアントコンポーネントなのですが、ファイル名に Client とついていますが、[MED-V Host Agent] がインストールされます。
ヘルプやダウンロードできるドキュメント内の MED-V Host Agent と記載されているものはこのクライアントコンポーネントをインストールしないと使用することができません。
# ちょっと名前が紛らわしいですよね…。
続いて展開用パッケージのインストールを行います。
# 展開用パッケージは多言語対応されている用で日本語で表示されます。
[Launch MED-V] が有効になっているので、完了後に MED-V が実行されるのですが、今回は以下のメッセージが表示されてしまいました。 
MED-V のパッケージのインストールまではワークグループ環境で実行ができるのですが、MED-V の実行は [ドメイン環境が必須] になります。
ドメインユーザー以外で MED-V を実行しようとしても上記のメッセージが出力されてしまい実行することができませんので注意が必要です。
デフォルトの設定でパッケージを作成するとログイン時に MED-V が自動で実行されるように設定がされています。
ドメインユーザーでログインすると以下のダイアログが表示されるのですが、これは MED-V が自動で実行されているためです。 
[Start] をクリックして、即時実行してみます。
そうすると仮想マシンとして MED-V で展開した仮想マシンが自動で作成/実行されます。 
また、通知領域に MED-V Host Agent のアイコンが表示され、[MED-V Configuring <ワークスペース名> for use.] というメッセージが出力されます。 
今回は [Attended Setup] にしていますので、実行中の sysprep の状況を確認することができます。
# 初回起動時は sysprep による初期化が行われ起動まで時間がかかります。
応答ファイルが適切に構成されておらず、無応答セットアップになっていない場合はセットアップの途中で止まっている可能性もありますので、一度 [Attended Setup] でテスト展開をしてみて、正常に展開することは本番運用でも確認したほうが良さそうですね。 
Sysprep 終了後に、Sysprep.inf で設定していた WMIC と FtsCompletion.exe が実行されます。 
FtsCompletion.exe の実行が終了すると自動でシャットダウン → 起動されます。 
起動されると、[initializing.] になり、
仮想マシンへのログインの認証ダイアログが表示され、
# [資格情報を記憶する] を有効にしておいた方がいいかは調査中です。
認証が通ると、ワークスペースの初期化が進み [applications are ready for use] となり、 
スタートメニューに公開プログラムが表示されます。
# MED-V 用のフォルダはできず、スタートメニューの直下に表示されました。 
MED-V の管理ですが、Administration Toolkit で管理することができ、[MedvHost.exe /toolkit] から実行することができます。
# MED-V_Client をインストールしている必要があります。 
この管理コンソールから展開しているアプリケーションと、Web リダイレクトの URL を確認することができます。 
ここまでで、MED-V の初期設定は完了です。
MED-V を使用して、IE8 と IE6 を実行した画面が以下の画像になります。 
Web リダイレクションが実行されると以下のように表示がされます。
ホスト OS の IE で Web リダイレクション対象の URL を開こうとすると自動的に MED-V のゲスト OS の IE が起動されます。 
ここまでの手順だと MED-V の Web Redirection が正常に動作しないので手順を見直す必要があるのですよね…。
MED-V は展開パッケージの VHD と差分ハードディスクで構成されており、MED-V を起動するたびに差分ハードディスクが削除されてしまい初期状態に戻ってしまいます。
# sysprep が永久ループしたのもこの辺の動作が影響していると思ってきました。
この辺の設定も見直さないといけないのですよね…。
2010/10/21 追記
永久ループしていたのは、MED-V のゲスト OS をドメインに参加させていなかったいことが原因のようです。
MED-V のゲスト OS をドメインに参加させないと、Sysprep 後に [FtsCompletion.exe] が実行され、シャットダウン → 起動という処理が実行される際にエラーとなりワークスペースの初期構成が失敗してしまい、仮想マシンが新規作成 (差分ディスクを再作成) され再度 Sysprep が実行されてしまうという流れが繰り返されてしまっていました。
FtsCompletion.exe のシャットダウン後に以下のダイアログが表示され、ワークスペースの初期構成が失敗したというメッセージが表示されます。 
ドメインに参加をさせたところ [FtsCompletion.exe] が実行 → シャットダウン → 起動 が終了し、ワークスペースの初期構成が正常に完了して、仮想マシンが再作成されるということがなくなりました。
この現象ですが、FtsCompletion.exe をインストールしなかった場合にも発生します。
MED-V のゲスト OS に関しては FtsCompletion.exe のインストールは必須のようですね。
# このプログラムをインストールしないと Web リダイレクトも動作しないようですし。
MED-V のワークスペースの初期化が正常に完了しないと、MED-V は XP Mode 相当の配置となるようで、Windows Virtual PC の直下に公開プログラムが表示されます。
# ワークスペースが初期化されていない状態だとこのような表示になるようです。 
まだまだ検証することはありそうなので、この辺は別の投稿でまとめていきたいと思います。
ここまでで事前作業は終了しましたので展開用のパッケージを作成していきます。
MED-V Workspace Packager を使用して展開用のパッケージファイルを作成します。
以上でパッケージの作成は完了です。
パッケージを作成すると、
が作成されます。
setup.exe/msi はセットアップ用のファイルになります。
.ps1/reg はレジストリ登録用のファイルになっているようです。
MED-V のレジストリは、[HKEY_LOCAL_MACHINESoftwareMicrosoftMedvv2] に格納され、MED-V のパッケージ作成で設定した値はこのレジストリに設定がされるようです。
# Web Redirection の URL もこのレジストリ内に設定がされます。
setup.exe を実行してインストールをするとレジストリへの設定反映もされますので、単体で実行する必要はないのですが、後からちょっと設定を変えたいというときにはこれらのファイルを変更すると良さそうでsう。
.medv は展開用の VHD が格納されています。
この
ファイルは zip 圧縮のファイルになりますので、拡張子を .zip に変更するとファイルを展開することができます。 
VHD 内のファイルを少し変更したい場合は、VHD マウントをして変更することもできそうですね。
セットアップを実行すると展開用パッケージをインストールすることができるのですが、MED-V クライアントがインストールされていない状態でセットアップを実行してもエラーとなります。 
展開用パッケージのインストールは次の投稿でまとめたいと思います。
