SE の雑記

あまり需要があるネタではないかもしれませんがメモとして。
# なにせ NT ネタですので…。

NT のドメインコントローラーを AD にアップグレードする前に [TCP/IP] のプロパティで、DNS のサフィックスを
設定している場合の注意点です。

NT の状態で、ドメイン名として [DOMAIN]、DNS のサフィックスとして [test.net] を設定しています。

この状態で NT を Windows 2000 Server へアップグレードします。

NT ドメインコントローラーをアップグレードすると自動的に Active Directory のインストール ウィザードが起動します。

ドメイン名は [domain.local] として設定してみます。

AD のインストール後のコンピュータ名が以下の画像になります。

通常、ドメインコントローラーのフルコンピュータ名のサフィックスには、ドメイン名が使用されるのですが、
NT の段階で DNS のサフィックスを指定しているとその設定が引き継がれます。
メンバサーバーであれば変更することができるのですが、画像を見てもらえると分かりますように、
ドメインコントローラーの場合は、ボタンがグレーアウトして変更することができません。

サフィックスは DNS の登録されるゾーンにも影響が出ますので、新規にゾーンを作成しないと AD の挙動にも
影響が出る可能性があります。

DNS サフィックスの変更方法は以下の KB に記載されています。

ドメイン コントローラの DNS サフィックスがドメイン名と一致しない

レジストリエディタで以下のレジストリを変更します。

[HKLMSYSTEMCurrentControlSetServicesTcpipParametersNV Domain]

?

上記の画像では [test.net] から [domain.local] に値を変更しています。
変更後、再起動をすると設定が反映されます。

?

NT → 2003 R2 へのアップグレードではどうなるか試してみました。

Windows Server 2003 R2 のインストールが終了すると、Active Directory のインストール ウィザードが開始されます。

ここで、[新しいドメインの完全な DNS 名] を [domain.local] として設定します。

2003 R2 の場合は、ドメイン名が使われるようですね。

ブログの下書きにずっと入っていた内容をようやく投稿できました。

ディスク署名の変更時の修復作業で MSDTC のリソースを使用して修復検証をしていたところ、
ディスクを再作成した際に MSDTC のリソースが起動しなくなりましたので、修復手順を
まとめてみたいと思います。

以下の 2 パターンで検証をしてみました。

1. バックアップが存在しない
2. Windows Server バックアップでバックアップが取得されている

[バックアップが存在しない]

ディスクを復旧しても MSDTC のリソースをオンラインにすることができません。

バックアップが存在しない場合は、復旧元のデータが存在しませんので、MSDTC のリソースのみを
再作成することでリソースをオンラインにすることができるようになります。

1. MSDTC のリソースを [右クリック] → [削除] をクリックします。
   
2. [はい] をクリックします。
   
3. [操作] → [リソースの追加] → [その他のリソース] → [分散トランザクション コーディネータ の追加] を
   クリックします。
   
4. MSDTC のリソースが作成されます。
   この状態ではリソースの依存関係がなにも設定されていないのでオンラインにすることはできません。
   
5. MSDTC のリソースを [右クリック] → [プロパティ] をクリックします。
   
6. [依存関係] タブで、MSDTC で使用する [コンピュータ名] と [クラスタ ディスク] の依存関係を設定し、
   [OK] をクリックします。
   

これでリソースをオンラインにすることができます。

コンピュータ名の再作成が発生すると AD 上のコンピュータアカウントに対しての作業が発生する可能性がありますので、
MSDTC のリソースだけを再作成してあげるのがシンプルではないかと思います。

[Windows Server バックアップでバックアップが取得されている]

続いて MSDTC で使用しているディスクを Windows Server バックアップで取得していた場合を検証してみます。

1. [Windows Server バックアップ] で MSDTC で使用しているディスクの情報を復元します。
   
2. MSDTC のリソースをオンラインにします。
   

バックアップが存在している場合は簡単にオンラインにすることができました。
[msdtc ?resetlog] は実行しなくてもエラーは発生しませんでした。

?

実際の運用ではバックアップを取得していない状態は基本的にない (と信じたいです…。) ので、
バックアップから復元してからオンラインにするパターンになると思いますが、バックアップがなくても
リソースの再作成だけで対応することができそうです。

忘れないうちに基本的な手順だけ投稿しておきたいと思います。

ISA をプロキシサーバーとして使用するときの設定です。

1. アクセスルールの作成
   [ファイアウォール ポリシー] → [タスク] → [アクセス ルールの作成] をクリックします。
   
2. アクセスルールの名称を入力し、[次へ] をクリックします。
   
3. [許可する] を有効にして、[次へ] をクリックします。
   
4. プロトコルとして [HTTP] / [HTTPS] を設定し、[次へ] をクリックします。
   ?
   基本的なプロトコルは ISA にデフォルトで登録されているので、プロトコルを事前に定義しなくても大丈夫です。
   今回は、[Web] のカテゴリに登録されていたプロトコルを選択しています。
   
5. ルールを適用する送信元を選択し、[次へ] をクリックします。
   私は、内部ネットワークに検証環境のプライベート IP を登録してあるので、[内部] の検証環境の全 IP を対象として
   設定しています。
   
6. ルールが適用される宛先を選択し、[次へ] をクリックします。
   今回は、検証環境から HTTP / HTTPS で外部にアクセスしたときに適用されるルールにしたいと思います。
   
7. デフォルトの [すべてのユーザー] の状態で [次へ] をクリックします。
   
8. [完了] をクリックしてルールを作成します。
   
9. [適用] をクリックしてルールを反映させます。
   

それでは作成した、ルールをテストしてみたいと思います。
まずは、クライアントの IE にプロキシの設定をします。
今回はクライアントに Vista Enterprise Edition x86 SP2 を使用しています。

IP は塗りつぶしてしまっていますが、ISA サーバーの IP アドレスを指定しています。

?

ポートは ISA の Web プロキシ用のデフォルトのポートを指定しています。
Web プロキシで使用するポートは ISA の内部ネットワークのプロパティで変更することが可能です。
[構成] → [ネットワーク] → [内部] のプロパティ
?

Web プロキシ用のルールが設定されていない場合は、ブラウザには以下の表示がされます。

ルールを有効にするとプロキシサーバーが要求を受け付けますので、ブラウジングが可能になります。

現在はすべてのユーザーを許可するオープンプロキシとなっていますが、作成したルールのプロパティのユーザーから
[すべてのユーザー] を削除し、[認証されたすべてのユーザー] とすることで、認証されたユーザーのみがブラウザで
インターネットに接続できる構成とすることも可能です。

ユーザーセットは独自に定義することも可能ですので、特定の Windows グループにメンバとして登録されている
ユーザーのみがブラウザでインターネットに接続できるような構成も簡単にできそうです。

認証方式はデフォルトでは [統合] 認証となっていますが、[構成] → [ネットワーク] → [内部] → [Web プロキシ] の
[認証] から認証方式を変更することが可能です。

[URL セット] や [ドメイン名セット] でブラックリストやホワイトリストの定義ができそうですね。

まだ、本当に基礎の基礎しか触れていないのですが、プロキシ環境を使用した検証が必要な場合はこのあたりの設定をすれば
対応できそうかなと思っています。

ISA の次期バージョン TMG が発売されるタイミングで自習書のようなものが提供されるとうれしいです。
ネットワーク関連の知識は弱い方だと思っているのでこのような製品を触りながらスキルアップをしていきたいです。

Windows Server 2003 までの MSCS では、クラスタで使用しているディスクを交換して、ディスク署名が変わると
ClusterRecovery でドライブの変更または、dumpcfg でディスク署名を変更して、交換したディスクを交換前の
ディスクと同じようにするという作業を実施していました。

Windows Server 2008 の WSFC (MSFC) で、ディスク署名が変更されるとどのような動きになり、どのような修復
作業が必要になるのかを調べてみました。

Windows Server 使い倒し塾 の以下の記事を自分なりにまとめてみた形です。
Windows Server 2008 フェールオーバー クラスタで、clusterrecovery.exe によるディスク署名の変更は必要か？

Windows Server 2008 では、DISKPART コマンドからディスク署名の確認 / 変更ができます。
# ディスク署名の確認は以前の OS の DISKPART でもできますね。

ディスク署名の確認 / 変更の操作は以下のコマンドになります。

DISKPART LIST DISK または LIST VOL SELECT DISK <ディスク ID> または SELECT VOL <ボリューム ID> [ディスク署名の確認] UNIQUEID DISK [ディスク署名の変更] UNIQUEID DISK ID=xxxxxxxx

DISKPART を実行して UNIQUEID コマンドから、ディスク署名の確認 / 変更が行えます。

ディスクに対して署名を変更しますので最初に [LIST DISK] または、[LIST VOL] で対象のディスクを確認しています。

LIST VOL ではボリュームの確認になりますが、[SELECT VOL] でボリュームを選択すると、ボリュームを作成している
ディスクが選択されますので、ドライブレターからディスクを判断する場合は、[LIST VOL] で調べて [SELECT VOL] で
ボリュームからディスクを選択するのが使いやすいと思います。

[ディスク署名が変更された場合の修復]

まずはディスク署名だけを変更して、クラスタのディスクがどのようになるかを確認してみました。
H ドライブのディスクが今回、ディスク署名を変更したディスクなのですが、正常にオンラインになっていますね。
Windows Server 2003 以前では、ディスク署名が変わっているとオンラインにすることができませんでした。

以下のログが、イベントビューアに出力されています。
単純なディスク署名の変更だと、クラスタが自動的に署名の修復作業を実施し、最新のディスク署名の値で、
クラスタの構成情報を更新してくれているようです。

[ディスク再作成後の修復]

次は、ディスクを再作成した時にどのような動きになるのか確認してみたいと思います。

何かのリソースで使っているディスクでテストをしたほうがよいと思いますので、DTC で使用しているディスクで
検証してみたいと思います。

一度 iSCSI のディスクを削除し、ターゲット側で新規に作成したディスクを H ドライブとして割り当ててから、
クラスタを起動してみました。

ディスクを再作成した場合、イベントビューアに以下のエラーが出力されていました。

署名の再設定がされなかったみたいですね。

ドライブ文字は一緒にしていますので、MSDTC のディスクとして認識はしていますが、オンラインにはなっていません。

オンラインにすると以下のエラーになります。

この場合は、ディスクの修復をすることでオンラインにすることができます。
ディスクの修復は [フェールオーバー クラスタ管理] から対象のディスクを右クリック → [その他のアクション]
→ [修復] で実行することができます。

ディスクの修復をすることで、代替ディスクとして別のディスクを対象のクラスタディスクとして割り当てることができます。

これでディスクはオンライにできます。

MSDTC のリソースを新規に作成したディスクでオンラインにするためには別の手順が必要になりそうです。
こちらについては別途調べてみたいと思います。
# MSDTC をオンラインにしようとすると以下のエラーが発生します。

2008 になってクラスタのディスク復旧が標準の GUI からできるようになったので復旧手順もシンプルになりそうですね。

ダウンロードが終了したのでインストールをしてみました。

[Windows Virtual PC のインストール]

XP Mode のコアコンポーネントである、Windows Virtual PC をインストールします。
インストールは [MU_WINDOWS_VIRTUAL_PC_xx_435190.MSU] を実行します。
私の環境は Windows Vista x86 を使用しているので今回は 32 bit 版をインストールしています。

Windows Update インストーラーが起動して、更新プログラムの確認が行われます。

[同意します] をクリックします。

[今すぐ再起動] をクリックして再起動します。

再起動後、Windows Virutal PC がインストールされます。

[Windows XP SP3 のイメージのインストール]

続いて、XP Mode で使用する XP のイメージをインストールします。
インストールは [JA_WINDOWS_XP_MODE_X86_X64_439180.EXE] を実行します。
 

[次へ] をクリックします。

[次へ] をクリックします。
 

インストールが開始されます。
※途中で UAC が働きます。

[完了] をクリックします。
 

これでインストールディレクトリに XP の VHD が展開されます。
 

[Windows XP Mode のセットアップ]

[Windows XP Mode] を実行します。

[ライセンス条項に同意する] を有効にし、[次へ] をクリックします。

XP Mode を使用する際のパスワードを入力し、[次へ] をクリックします。
Virtual PC の XP に作成されるユーザーのパスワードですね。
RTM になってユーザー名が変わったようです。
 

[自動更新] の設定を行い、[次へ] をクリックします。

[セットアップの開始] をクリックします。
 

XP Mode のインストールが開始されます。

インストールが完了すると Virutal PC の XP が自動的に起動します。

XP Mode のカテゴリから [JA_RAIL_QFE_FOR_WINDOWS_XP_SP3_X86_439642.EXE] がダウンロードができます。

これは [KB961742-V3] のモジュールのようなのですが、起動してきた XP にはデフォルトでインストール済みとなっていました。

デフォルトで統合コンポーネントもインストール済みです。
 

RTM でも Windows 7 上にアプリケーションを登録する場合は、[C:Documents and SettingsAll Usersスタート メニュー] に
ショートカットを配置すれば登録できます。

XP Mode で使用している OS もゲスト OS ですのでセキュリティが気になります。
いいタイミングで Microsoft Security Essentials が提供開始されたので XP にインストールしておきました。
Microsoft Security Essentials

提供されているイメージは正規品として正常に認識されますのでインストールができます。

統合サービス経由でネットワークにつながりますので、パターンファイルの更新も可能です。
インストールしたら Security Esentials もメニューに追加されました。

パターンファイルを更新するために XP にログインしなくても済むのでこれは便利ですね。

RC の投稿を書いてから 5 か月経過しているのですが、その間ほとんど触っていなかったため、
インストール方法を完全に忘れていました…。

TechNet / MSDN の会員サイトから XP Mode の RTM がダウンロード可能になったようです。

[アプリケーション] → [Windows Virtual PC] からダウンロード可能です。

ダウンロードが終了したらインストール方法を確認して投稿したいと思います。

去年までは Microsoft Event DVD Store でアメリカの Tech・Ed のセッション DVD が購入できていたのですが
今年は Tech・Ed Online が提供されているので単体での販売はなさそうですね。

Tech・Ed Online

クレジットカード支払いになりますが上記サイトでコンテンツ購読することにより PowerPoint の資料と
セッションの動画をダウンロードすることができます。

購読することで閲覧可能になるのは、上記のリンクから? [Start Now] でサイトに入り、[Channel] の [Track] の
各トラックで鍵アイコンの表示されているセッションです。

1 年間の利用で$249 になります。
私は本日、購読をしてみました。
今、一生懸命セッション資料をダウンロード中です。

2009 のものだけでなく 2008 のセッション動画もダウンロードできるようです。
2008 のものは 2,3 セッションしか確認ができていませんが、セッション資料のダウンロードはなさそうでした。

イベントの開催場所も選択できるようになっており、2008 のセッションについてはヨーロッパで開催されたものも
セッション動画は見れるようでした。
開催場所は日本も選べるようになっており、セッションの内容は公開されていないのですが、今後こちらで公開されるのであれば
参加できなかった方が情報を収集する場としてとても便利なのではないでしょうか。

2010 もこのサイトから資料が公開されダウンロードが可能なのであればかなりお得なサービスかと。

Windows を使用していて、例外コードが発生してアプリケーションが終了されることがあります。
例外コードの内容ってどうやって調べるのだろうと思っていたら、@IT に記事がありました。

“Error Code Lookup”ツールでエラー・コードから原因を探る

Windows の例外コードは ＤDK の ntstatus.h で定義されているようなのですが、上記の記事で紹介されている、
Microsoft Exchange Server Error Code Look-up を使用すると調べることができます。

DDK の ntstatus.ht で定義されていることは以下の KB に記載されています。
NTSTATUS エラー コードをメッセージ文字列に変換する方法

Err Code Lookup の使い方は簡単で、モジュールをダウンロードしたら実行して解凍をして、コマンドプロンプトで
実行するだけです。

以下はコマンドの実行例です。

err.exe [/ヘッダファイル名] <例外コード> >err.exe 0xC0000142 # for hex 0xc0000142 / decimal -1073741502 : ? STATUS_DLL_INIT_FAILED??????????????????????????????????????? ntstatus.h # {DLL Initialization Failed} # Initialization of the dynamic link library %hs failed. The # process is terminating abnormally. # 1 matches found for "0xC0000142" >err.exe /ntstatus.h 0xC0000142 # ntstatus.h selected. # for hex 0xc0000142 / decimal -1073741502 : ? STATUS_DLL_INIT_FAILED??????????????????????????????????????? ntstatus.h # {DLL Initialization Failed} # Initialization of the dynamic link library %hs failed. The # process is terminating abnormally. # 1 matches found for "0xC0000142"

?

アプリケーションが終了した場合、例外コードが何を示しているのかを調べるようにすると、一歩進んだ原因の
調査ができるかも知れないですね。

この辺はデバイスドライバの開発をされている方とかはかなり詳しいんでしょうね～。

WSFC / MSFC のログについて調べたことをまとめてみました。
久しぶりのクラスタ関連の投稿です。

検証環境が 2008 無印のものしか用意できていなかったため Windows Server 2008 SP1 で確認しています。
そろそろ R2 のクラスタ検証環境も構築しておきたいと思います。

WSFC のログ (状態を把握する情報) は以下の種類があります。

1. イベントビューア
2. Cluster.log
3. Event Tracing for Windows (ETW)

まずはイベントビューアのログから。

[イベントビューア]

以下の 2 個所からクラスタ関連のイベントビューアのログを確認することができます。

1. システムログ
2. アプリケーションとサービスログ

それぞれのログの表示の仕方は以下の通りです。

システムログ

1. サーバー マネージャを実行します。
2. [診断] → [イベント ビューア] → [Windows ログ] → [システム] を開きます。
   ?
3. WSFC のログのみを表示するにはソースを [FailoverClustering] でログをフィルタリングします。
   フィルタリングは [操作] の [現在のログをフィルタ] で行います。
   
4. [フェールオーバー クラスタ管理] の [クラスタ イベント] で表示される内容もイベントビューアと同様の内容のようですね。
   こちらは直近 24 時間以内の内容でフィルタリングされています。
   ?

アプリケーションとサービスログ

1. サーバー マネージャを実行します。
2. [診断] → [アプリケーションとサービス ログ] → [Microsoft] → [Windows] → [FailoverClustering] → [Operational] を開きます。
   

こちらのログはクラスタの操作ログが出力されるようですね。
細かな動作の内容に関しては [Windows ログ] ではなく、こちらのログを確認したほうがよいかと思います。

[Cluster.log]

Windows Server 2003 まではデフォルトで出力されていたログですね。
Windows Server 2008 ではこのログはデフォルトでは出力されていません。

以下のコマンドを実行して、必要に応じて都度出力する必要があります。

cluster log /generate または cluster log /g

?

このコマンドを実行すると [Cluster.log] が [C:WindowsClusterReports] に出力されます。
[/node:] オプションを指定しない場合は、クラスタを構成する各ノード上にログが出力されています。

このファイルは以前からクラスタを触られている方であれば馴染みのある形式ですよね。
クラスタのログは Tech Center の以下の投稿がとても参考になります。
Cluster Log Level

クラスタのログのレベルは 1 ～ 5 までの 5 段階で設定ができ、デフォルトでは 3 となっています。

Level	Error	Warning	Info	Verbose	Debug
0	?	?	?	?	?
1	○	?	?	?	?
2	○	○	?	?	?
3	○	○	○	?	?
4	○	○	○	○	?
5	○	○	○	○	○

?
以下は [Cluster log] コマンドのヘルプになります。
[/LEVEL] は [0 ～ 10] となっていますが、6 以上は将来の予約値となっているようで現在はまだ使われていないようです。
# R2 になって使用されるようになっているかまではまだ調べられていません。

>cluster log /? このコマンドの構文は次のとおりです: CLUSTER [[/CLUSTER:]クラスタ名] LOG <オプション> <オプション> = ? /G[EN[ERATE]] [/COPY[:"ディレクトリ"]] [/NODE:"ノード名"] ? [/SPAN[MIN[UTE[S]]]:分] ] ? /SIZE:MB 単位のログ サイズ ? /LEVEL:ログ レベル 注意: ? /SIZE は 8 ～ 1024 MB の間である必要があります。 ? /LEVEL は 0 ～ 10 の間である必要があります。 CLUSTER LOG /? CLUSTER LOG /HELP

ログのレベルを変更したいときは、[Cluster log /LEVEL:<レベル>] で変更します。
サイズはデフォルトでは [100 MB] になっていますので変更したい場合は [Cluster log /LEVEL:<サイズ>] で変更します。
現在の設定値を確認したい場合は、[Cluster prop] コマンドで確認することができます。
以下は、コマンドの出力結果です。
[ClusterLogLevel] [ClusterLogSize] が現在の設定値になります。

T? クラスタ???????????? 名前?????????????????????????? 値 — ——————– —————————— ———————– M? 2008-wsfc-01???????? AdminExtensions D? 2008-wsfc-01???????? DefaultNetworkRole???????????? 2 (0x2) S? 2008-wsfc-01???????? Description B? 2008-wsfc-01???????? Security Descriptor??????????? 01 00 14 80 … (288 バイト) M? 2008-wsfc-01???????? GroupsAdminExtensions M? 2008-wsfc-01???????? NetworksAdminExtensions M? 2008-wsfc-01???????? NetworkInterfacesAdminExtensions M? 2008-wsfc-01???????? NodesAdminExtensions M? 2008-wsfc-01???????? ResourcesAdminExtensions M? 2008-wsfc-01???????? ResourceTypesAdminExtensions D? 2008-wsfc-01???????? QuorumArbitrationTimeMax?????? 20 (0x14) D? 2008-wsfc-01???????? QuorumArbitrationTimeMin?????? 7 (0x7) D? 2008-wsfc-01???????? DisableGroupPreferredOwnerRandomization 0 (0x0) D? 2008-wsfc-01???????? ClusSvcHangTimeout???????????? 60 (0x3c) D? 2008-wsfc-01???????? ClusSvcRegroupStageTimeout???? 7 (0x7) D? 2008-wsfc-01???????? ClusSvcRegroupOpeningTimeout?? 5 (0x5) D? 2008-wsfc-01???????? ClusSvcRegroupPruningTimeout?? 5 (0x5) D? 2008-wsfc-01???????? ClusSvcRegroupTickInMilliseconds 300 (0x12c) D? 2008-wsfc-01???????? HangRecoveryAction???????????? 3 (0x3) D? 2008-wsfc-01???????? SameSubnetDelay??????????????? 1000 (0x3e8) D? 2008-wsfc-01???????? CrossSubnetDelay?????????????? 1000 (0x3e8) D? 2008-wsfc-01???????? SameSubnetThreshold??????????? 5 (0x5) D? 2008-wsfc-01???????? PlumbAllCrossSubnetRoutes????? 0 (0x0) D? 2008-wsfc-01???????? CrossSubnetThreshold?????????? 5 (0x5) D? 2008-wsfc-01???????? BackupInProgress?????????????? 0 (0x0) D? 2008-wsfc-01???????? RequestReplyTimeout??????????? 60 (0x3c) D? 2008-wsfc-01???????? WitnessRestartInterval???????? 15 (0xf) D? 2008-wsfc-01???????? SecurityLevel????????????????? 1 (0x1) D? 2008-wsfc-01???????? ClusterLogLevel??????????????? 3 (0x3) D? 2008-wsfc-01???????? ClusterLogSize???????????????? 100 (0x64) D? 2008-wsfc-01???????? WitnessDatabaseWriteTimeout??? 300 (0x12c)

[Cluster.log] はコマンドの実行の都度、生成されますがその情報は Event Tracing for Windows (ETW) で出力された
情報がベースになっているようです。

[Cluster log /g] コマンドを実行すると、[CPrepSrv.exe] が [C:WindowsSystem32winevtLogs] ディレクトリにある、
[ClusterLog.etl.001] [ClusterLog.etl.002] [ClusterLog.etl.003] を読み込み、[Cluster.log] を生成しています。

[Event Tracing for Windows (ETW) ]

最後に ETW のログです。

ETW は Event Tracing for Windows の略で、OS で提供されている汎用トレース機能になります。
この機能により、クラスタの状態が ETL ファイルに出力がされています。
ETW は OS の内部状態を確認するために使用することがあるようなのですが、私は全然詳しくありません･･･。
IT Pro 向けの ETW / XPerf 関連の情報を集めたいなと思っているのですが手付かずです。

ETW によりデバッグおよびパフォーマンス調整を改善する

クラスタの ETW はイベントトレースセッションで自動的に実行されるようになっています。

イベントトレースセッションの設定は以下から確認することができます。

1. サーバー マネージャを実行します。
2. [診断] → [信頼性とパフォーマンス] → [データ コレクタ セット] → [イベント トレース セッション] を開きます。

?

[FailoverClustering] がクラスタのイベントトレースセッションの設定になります。

自動的に実行されているのは [スタートアップ イベント トレース] で [FailoverClustering] が [自動] で設定されているからのようですね。

この機能で出力されているのが、[Cluster.log] のベースになっている、[C:WindowsSystem32winevtLogs] に出力さている、
[ClusterLog.etl.xxx] ファイルになります。

このファイルを直接開いて内容を確認することはできないのですが、[tracerpt] というコマンドを使用すると、CSV や XML で
出力することができます。
以下はコマンドの例になります。

tracerpt ClusterLog.etl.001 ClusterLog.etl.002 ClusterLog.etl.003 -o log.txt ?of CSV tracerpt ClusterLog.etl.001 ClusterLog.etl.002 ClusterLog.etl.003 -of XML

クラスタの場合は ETW を開くより、cluster.log にして開くことのほうが多いと思いますので、使用する機会は
多くないかも知れないですね。

ETL ファイルですので、xperf や xperfview で開くことも可能です。
xperf / xpwerfview は以下のリンクから WPT Kit をダウンロードすることで入手可能です。

Windows Performance Analysis

パフォーマンス系の情報が入っていないからなのか、開いても寂しい表示ですが。

?

以上が、クラスタのログになります。
クラスタで障害が発生した場合は、これらのログを使用して状況を把握していくことになります。
ETW は Cluster.log で確認ができるので、実際にはイベントビューアと cluster.log の 2 種類を使用することになりますね。

この記事はずっと下書きに入っていたのですが、ようやく投稿まで持っていくことができました。

HTTPS で ISA を公開するための手順の続きです。

[Web リスナ の作成? (SSL) ]

作成の手順は証明書関連を除くと HTTP のときとほとんど同じです。
同じ箇所は画像は省略して手順を記載しています。

1. [スタート] → [すべてのプログラム] → [Microsoft ISA Server] から [ISA Server の管理] を開きます。
2. [ファイアウォール ポリシー] を選択し、[ツールボックス] → [ネットワーク オブジェクト] → [Web リスナ]
   → [右クリック] → [新しい Web リスナ] をクリックします。
3. 任意の [Web リスナ名] を入力し、 [次へ] をクリックします。
4. [クライアントとの SSL セキュリティ保護接続を必要とする] を選択し、[次へ] をクリックします。
   
5. 外部からの要求を受け付ける IP アドレスが指定されているネットワークを選択し、[次へ] をクリックします。
6. ネットワークに複数の IP を割り当てている場合は IP 単位で証明書を設定できるようです。
   今回は単一の IP を割り当てていますので、[この Web リスナに 1 つの証明書を使う] を選択し、[証明書の選択] を
   クリックします。
   
7. 証明書の設定が完了していると、サイト用の証明書が選択できるようになっています。
   使用する証明書を選択し、[選択] をクリックし、[次へ] をクリックします。
   
8. [クライアントが ISA Server に～] は [認証なし] を選択し、[次へ] をクリックします。
9. [次へ] をクリックします。
10. [完了] をクリックします。

これで SSL を使用するリスナーの作成は終了です。
あとは HTTP のときと同様にこのリスナーを使用するポリシーを作成します。

[ファイアウォール ポリシーの作成]

こちらも HTTP のときと同じ箇所の画像は省略で。

1. [タスク] → [Web サイトの公開] をクリックします。
2. 任煮の [公開ルール名] を入力し、[次へ] をクリックします。
3. [許可] を選択し、[次へ] をクリックします。
4. [1 つの Web サイトまたは付加分散装置を公開する] を選択し、[次へ] をクリックします。
5. 今回は Web サーバー側も SSL を適用したサイトで作成しているのでこちらの設定を使用しています。
   [公開された Web サーバーまたはサーバー ファームへの接続に SSL を使用する] を選択し、[次へ] をクリックします。
   クライアント ←→ ISA 間は SSL で保護されているので、 ISA ←→ Web サーバー間は SSL を使用しないという
   考え方もあるかも知れません。
   その場合は下のラジオボタンを選択します。
   今まで、SSL のサイト展開をした経験がないのでわからないのですが、一般的にはどちらが多いんでしょう？？
   
6. [内部サイト名] と、必要に応じて [コンピュータ名または IP アドレス～] を有効にして、入力を行い [次へ] をクリックします。
7. [内部公開の詳細] はデフォルトのままで [次へ] をクリックします。
8. [パブリック名] に外部公開のドメイン名を入力し、[次へ] をクリックします。
9. [Web リスナ] に作成した SSL 用のリスナ名を選択し、[次へ] をクリックします。
   
10. 認証方式は、[委任できません。クライアントは直接認証できません] を選択し、[次へ] をクリックします。
    作成したルールを RD ゲートウェイで使用する場合は、ゲートウェイ側と ISA 側の設定にもよるかも知れませんが、
    [委任できません。クライアントは直接認証できます] に設定しないと RD ゲートウェイへの接続時に認証ダイアログに
    ユーザー情報を指定してもログインできないことがあります。
    # 設定を [クライアントは直接認証できます] にしてもユーザー名にはきちんとドメイン名を入力しないと
    　 接続できませんでした。
    RD ゲートウェイには SSL ブリッジという機能があるんですね～。いままで気づきませんでした。
    
11. [次へ] をクリックします。
12. [完了] をクリックします。
13. [適用] をクリックして、今までの設定を反映させます。

これで HTTPS 経由でのリバースプロキシとして使用することが可能です。

ISA のプロキシ機能がうまく使えると検証環境を柔軟に構成変更できる環境にできそうです。