Ask the Network & AD Support Team

Windows Server 2008 R2 における ADMT の注意事項について

こんにちは、Windows プラットフォーム サポートの北川です。

Windows Server 2008 R2 がリリースされ、これから Active Directory ドメイン移行の検証などを行われる方もいるかと思います。
現時点では ADMT（Active Directory 移行ツール） を使用した移行に関して、いくつか注意点があり、それについての新しい KB が公開されましたので、ここでご紹介いたします。
元々、ADMT 3.1 は Windows Server 2008 R2 を対象としておらず、インストールすることも出来ませんが、それを Windows Server 2008 にインストールすることで、Windows Server 2008 R2 を移行先のターゲット ドメインとすることをサポートします、でもいくつか注意事項があるよ！という内容です。
Windows Server 2008 R2 に完全対応した ADMT は鋭意開発中です。本リリースには、まだ時間がかかる見通しなので、現時点で移行作業を検討される場合は ADMT 3.1 を Windows Server 2008 にインストールしてお使い下さいますようお願いいたします。

- Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers
< http://support.microsoft.com/kb/976659/en-us>

--- 抜粋 ---------------------------------------------------
• ADMT 3.1 must be run from a Windows Server 2008-based computer. The computer must be a member server or a domain controller.
• ADMT can be installed on any computer that is running Windows Server 2008, unless the computers are Read-Only domain controllers or in a Server Core configuration.
• The target domain must be based on Windows 2000 Server, Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.
• The source domain must be based on Windows 2000 Server, Windows Server 2003, or Windows Server 2008.
• The ADMT agent, which is installed by ADMT on computers in the source domains, can operate on computers that are running Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, or Windows Server 2008 R2.
------------------------------------------------------------

上記に記載がございますとおり、現在リリースされている ADMT 3.1 は Windows Server 2008 で実行する必要があります。
ご注意いただく点といたしましては、上記の通りなのですが、端的に申し上げますと以下の通りです。

・ADMT 3.1 を Windows Server 2008 R2 にインストールしない
・ADMT を RODC にインストールしない
・移行元ドメインは Windows Server 2008 R2 以外の Active Directory ドメイン (Windows 2000 以降のドメイン) 

また、ADMT 3.1 をインストールした Windows Server 2008 を Windows Server 2008 R2 にインプレース アップグレードすると ADMT がアンインストールできなくなる問題が確認できていますのでご注意ください。この問題に関しては、別の KB がございますので、そちらもご紹介いたします。

- You cannot uninstall ADMT 3.1 after you perform an in-place upgrade to Windows Server 2008 R2
< http://support.microsoft.com/kb/974625/en-us>

移行作業を始める前に、上記を踏まえ、検証いただけると幸いです。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

NAP internal-1 ～ WSHA がチェックできる項目 (ファイアウォール、ウィルス対策ソフト、スパイウェア対策アプリケーション)

こんにちは。Windows プラットフォーム サポート担当の石丸です。
本日は、Windows Server 2008 / Vista 以降の OS で使用できる NAP 機能について解説させていただきます。

なお、この内容をご参照されるにあたって必要となるNAP の基本的な概念や、アーキテクチャーについては、下記の公開情報などをご参照ください。

TechNet - ネットワーク アクセス保護
http://technet.microsoft.com/ja-jp/library/cc753550(WS.10).aspx

MSDN - Network Access Protection
http://msdn.microsoft.com/en-us/library/aa369712(VS.85).aspx

本稿では、Windows の標準で使用可能な WSHA (Windows システム正常性エージェント) がチェックできる項目についてご紹介します。

大きく分類するとファイアウォール、ウィルス対策ソフト、スパイウェア対策アプリケーション、セキュリティ更新プログラムに関する状態、の計 4 つについてチェックすることができますが、セキュリティ更新プログラムについての確認の仕組みは他の 3 つの項目と比較して若干複雑です。このため、まず本稿ではファイアウォール、ウィルス対策ソフト、スパイウェア対策アプリケーションについてご紹介し、セキュリティ更新プログラムについての確認の仕組みについては、次回お伝えする予定です。

- WSHA とは？
まず最初に、WSHA について簡単に解説します。

NAP では、SHA (システム正常性エージェント) と呼ばれるエージェントがクライアントコンピューター上で動作しており、クライアントの状態を収集して SoH (正常性ステートメント) という形式にとりまとめ、NPS サービス上で稼動する SHV (システム正常性検証ツール) に報告します。SHA は 1 つのコンピューターに複数登録することができ、どのような項目をチェックするかはそれぞれの SHA に依存します。

SHA にはサード パーティ製の製品もありますが、Windows 標準で使用可能な SHA (と、もちろんそれに対応する SHV) があります。これが WSHA (Windows セキュリティ正常性エージェント) です。WSHA は Windows XP SP3 以降、Windows Vista、Windows 7、Windows Server 2008、Windows Server 2008 R2 に標準で搭載されており (残念ながら、Windows Server 2003 では NAP クライアント機能はサポートされていません！)、NPS サービス上の WSHV (Windows セキュリティ正常性検証ツール) と連携することで、クライアントのセキュリティの正常性を検証します。


 

図中の EC、ES は、それぞれ NAP 強制クライアントと、NAP 強制サーバーを示しています。それぞれのコンポーネントの役割については、冒頭でもご紹介いたしました下記の公開情報にて解説されています。あわせてご参照ください。

TechNet - ネットワーク アクセス保護
http://technet.microsoft.com/ja-jp/library/cc753550(WS.10).aspx

なお、WSHA は Network Access Protection Agent サービスを開始すると、同時に動作を開始します。

- WSHA でチェックできる項目
前述の通り、WSHA は Windows 標準で使用することができる SHA であり、チェックすることができる項目はあらかじめ定められています。具体的には、下記の項目をクライアントのセキュリティ状態として管理し、SoH として WSHV に送付します。

1. インストールされている ファイアウォール ソフトウェアの状態
2. インストールされている ウィルス対策ソフトの状態
3. インストールされている スパイウェア対策アプリケーションの状態
4. 自動更新の設定状態
5. セキュリティ更新プログラムの適用状態
6. 最後に Windows Update サイトと通信を行ってからの経過時間
7. Windows Update の接続先の種類 (Microsoft Update / Windows Update / WSUS )
8. 現在適用されていないセキュリティ更新プログラムの重要度

また、WSHA が使用する SoH のフォーマットは、下記の公開情報でも紹介されています。

- 参考情報
MSDN - WSHA SoH
http://msdn.microsoft.com/en-us/library/cc251363(PROT.13).aspx

- Microsoft 製品とサード パーティ製品について
WSHA は、ファイアウォール、ウィルス対策ソフト、スパイウェア対策アプリケーションの設定状況を、コントロール パネルの "セキュリティ センター" から受け取ります。



ご存知の方も多いかと思いますが、Windows XP 以降の OS ではファイアウォール製品として Windows ファイアウォールが、Windows Vista 以降の OS ではスパイウェア対策アプリケーションとして Windows Defender が既定でインストールされています。もちろん、サード パーティ製のセキュリティ製品であっても、セキュリティセンターに対応しているものであれば NAP の検疫チェックの対象となります。逆に言えば、セキュリティセンターが認識できないセキュリティ製品を有効にしていても、クライアントのセキュリティ状態は正常と見なされませんのでご注意ください。


それでは、それぞれのセキュリティチェックの項目が取りうる状態について、より詳細に解説していきます。

1. インストールされている ファイアウォール ソフトウェアの状態
ファイアウォールの状態は、"Firewall_ClientStatusCode" として SoH に格納されます。取り得る状態は下記の通りです。

· マイクロソフト製品のファイアウォールが有効 / 無効
· サード パーティ製品のファイアウォールが有効 / 無効
· ファイアウォールが一時停止されている / されていない

この項目を評価する WSHV の設定は、下記の項目です。



[ネットワーク接続に対してファイアウォールが有効] のチェックがオンになっている場合は、下記の状態はポリシー非準拠と判定されます。

· ファイアウォールが無効である場合
· ファイアウォールが一時停止されている場合

** "一時停止" のステータスは、現在の Microsoft から提供されているセキュリティ製品では実装されておらず、一部のサード パーティ製のセキュリティ製品でサポートされているステータスを管理するために用意されており、Windows Vista 以降の OS でサポートされています。セキュリティ センターではこのステータスは "警告状態" として取り扱われ、NPS サーバーでは無効になっている場合と同等に扱われます。

2. インストールされている ウィルス対策ソフトの状態
ウィルス対策ソフトの状態は、"AntiVirus_ClientStatusCode" として SoH に格納されます。取り得る状態は下記の通りです。

· マイクロソフト製品のウィルス対策ソフトが有効 / 無効
· サード パーティ製品のウィルス対策ソフトが有効 / 無効
· ウィルス定義ファイルが最新である / 最新ではない
· ウィルス対策ソフトが一時停止されている / されていない

この項目を評価する WSHV の設定は、下記の項目です。



[ウィルス対策ソフトウェアが有効] のチェックがオンになっている場合は、下記の状態はポリシー非準拠と判定されます。

· ウィルス対策ソフトが無効である場合
· ウィルス対策ソフトが一時停止されている場合

追加オプションである [ウィルス対策が最新の状態] のチェックがオンになっている場合は、下記の状態はポリシー非準拠と判定されます。

· ウィルス定義ファイルが最新ではない場合

3. インストールされている スパイウェア対策アプリケーションの状態 (Windows Vista 以降の OS のみ)
スパイウェア対策アプリケーションの状態は、" Antispyware_ClientStatusCode" として SoH に格納されます。取り得る状態は下記の通りです。

· マイクロソフト製品のスパイウェア対策アプリケーションが有効 / 無効
· サード パーティ製品のスパイウェア対策アプリケーションが有効 / 無効
· スパイウェア定義ファイルが最新である / 最新ではない
· スパイウェア対策アプリケーションが一時停止されている / されていない

この項目を評価する WSHV の設定は、下記の項目です。



[スパイウェア対策アプリケーションが有効] のチェックがオンになっている場合は、下記の状態はポリシー非準拠と判定されます。

· スパイウェア対策アプリケーションが無効である場合
· スパイウェア対策アプリケーションが一時停止されている場合

追加オプションである [スパイウェア対策が最新の状態] のチェックがオンになっている場合は、下記の状態はポリシー非準拠と判定されます。

· スパイウェア定義ファイルが最新ではない場合

次回は、引き続き、セキュリティ更新プログラムについての確認の仕組みをご紹介して参ります。


「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

Metadata Cleanup の WebCast を公開しました！！

こんにちは、Windows プラットフォームサポート担当の北川 隆介（キタガワ リュウスケ）です。

本日 2009 年 10 月 16 日に Active Directory のリストアに関する WebCast を公開いたしました。

スピーカーは渡會が担当させていただきました。熱い心をもったエンジニアです。ハキハキした Talk をぜひ、お聞き下さい。

リストアといってもバックアップからのリストアやメタデータを削除し、新たに DC を追加する方法など手段は複数ございます。

その中のひとつの手順ではございますが、メタデータ クリーンアップに関するご説明、およびデモを作成いたしましたのでご覧いただけますと幸いにございます。

今までの WebCast の中では少し長めの構成になっていますが、2部作になっていますので、今日は [理論編] 、明日は [実践編] というようにご覧いただけます。

メタデータ クリーンナップについて、詳細をご覧になりたい方は [理論編] を。

理論は知っているけど、実際に作業する前に手順を知りたいという方は [実践編] をご覧ください。

もちろん、両方見ていただけると幸いです♪

Active Directory のリストア

<http://technet.microsoft.com/ja-jp/ee676512.aspx>

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

RPC サーバーを利用できません？

こんにちは。Windows プラットフォーム サポート担当の石丸です。

・ RPC サーバーを利用できません
・ エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません

Windows のシステム管理者の方なら、一度はこのようなエラー メッセージを見たことがあるかも知れません。

Active Directory の複製処理を GUI から実行した時とか・・・

ntdsutil コマンドで Active Directory の管理を行う時とか・・・

デバッグ ログの中にも・・・

今日は管理者の皆様を悩ませている（かも知れない？）このエラーメッセージの意味と対処方法について解説していきます。


1.  RPC とは？

RPC とは Remote Procedure Call の略で、その名の通りリモート コンピューター上に実装された機能を呼び出すための仕組みです。

しかしながら、Web や電子メールなどが普及していることからも明らかなように、昨今のシステムの多くはネットワーク上のコンピューターの機能を利用してすることを前提として動作しています。「リモートコンピューターの機能を呼び出す」 という言葉だけを見ると、HTTP や SMTP のような通常のクライアント / サーバー型のアプリケーションとの違いがわかりにくいかもしれません。そこで、まず簡単ではありますが、下記にその違いについて解説します。


- 通常のクライアント / サーバー型アプリケーション
従来のクライアント / サーバー型のアプリケーションでは、クライアント側に実装された機能によってリクエストを生成します。リクエストを受けたサーバーはその内容を読み取って、サーバー側で実装された機能によって処理を行い、レスポンスを返します。




- RPC アプリケーション
一方で、RPC アプリケーションではサーバー側に実装された機能をプロシージャーの単位で呼び出します。イメージは、下図の通りです。



この例では、RPC クライアント アプリケーションが RemoteFunction という名前のプロシージャーを呼び出していますが、このプロシージャーによって呼び出される機能はクライアント側には実装されていません。RPC サーバーへのリクエストの作成、送信は RPC クライアント スタブライブラリが代行し、目的のプロシージャーはリモート コンピューター上で実行され、結果のみが RPC クライアントアプリケーションに返されます。このようにして、RPC クライアント アプリケーションは、サーバーに対してどのようにリクエストを送るかなどを意識せずに、その機能のみを利用できます。

** もちろん、リモートだけではなく、ローカル コンピューター上に実装されている RPC サーバー アプリケーションの機能を呼び出すことも可能です。呼び出すプロシージャーが同じであれば、実装されているのがローカルかリモートかによらず、同一の手順で処理を行えることも RPC の利点の一つです。


- それでは、「RPC サーバーを利用できません」とは？
前述の通り、RPC の機能を利用するクライアント アプリケーションは、「どのプロシージャーを呼び出すか」、「どのサーバーから呼び出すか」などの情報を RPC クライアント スタブ ライブラリに渡してプロシージャーの実行結果を待ちます。

通常は、前述の通り目的のプロシージャーが RPC サーバーによって実行され、成功、失敗などのメッセージが応答として RPC クライアントアプリケーションに返されるのですが、ネットワーク通信の問題などによって RPC サーバーに対してリクエストを送信できない場合、RPC クライアント アプリケーションは RPC スタブ ライブラリからエラーメッセージを受け取ります。



これが、問題のエラー メッセージ "RPC サーバーを利用できません" が発生する仕組みです。

RPC スタブ ライブラリは、OS で共通のコンポーネントが使用されます。多くの場合、アプリケーション側ではプロシージャーの実行結果として受け取ったエラーコードやメッセージをそのままの形でイベント ビューアやダイアログ ボックス、デバッグ ログなどに出力するので、RPC で利用する様々なアプリケーションでこの共通のエラーメッセージが出力されることになります。

2.  主に考えられる原因と RPC エンドポイント マッパー

エラー メッセージの意味がわかったところで、実際に RPC サーバーへの通信に失敗する原因にはどのようなものがあるのでしょうか。下記に、代表的な例をご紹介します。


- 名前解決のトラブル、経路上の障害
まず第一に考えられるのが、名前解決のトラブルや、ネットワーク経路上の通信トラブルです。多くの場合、RPC の通信は TCP/IP プロトコル上で動作しますので、IP 層での疎通ができていることがまず第一の条件となります。問題の発生しているコンピューターが宛先のコンピューターと疎通できているか、宛先として指定しているコンピューター名の名前解決が正常に行えているかを、ping コマンドや nslookup コマンドで確認してみましょう。名前解決の仕組みやネットワークの疎通の確認方法については、本 Blog の過去の記事 <Windows 名前解決の順序> もご参考にしていただければ幸いです。


- ファイアウォールによる RPC に必要な通信のフィルタリング
さて、上記の確認を行ったところ、名前解決も正しく行えていて、ping コマンドでネットワークの疎通も確認できている・・・にも拘わらず、何故か "RPC サーバーを利用できません" のエラーが出力されてしまう場合は、RPC で使用するポートが経路途中のファイアウォールや、コンピューター上のパーソナル ファイアウォールによってフィルタリングされている可能性があります。

Windows における RPC の実装では RPC エンドポイントマッパーと呼ばれる仕組みが用意されており、多くの RPC アプリケーションがこの仕組みを利用しています。この仕組みを使って RPC の通信が行われる場合、使用されるポートの選択方法が通常のクライアント / サーバーアプリケーションと比較して少しだけ複雑になっています。このため、これらの正しく仕組みを理解した上で、必要なポート番号による通信をあらかじめ許可しておくことが肝要となります。


- RPC エンドポイント マッパーによる RPC 動的ポート通知の仕組み
それでは、RPC エンドポイント マッパーの動作の仕組みを見ていきましょう。まずは、下の図をご覧ください。

図の通り、RPC サーバー側では、RPC エンドポイント マッパーが 135/tcp でリッスンしており、RPC クライアント アプリケーションからの要求を受け付けています。RPC エンドポイント マッパーの役割は、RPC クライアントが呼び出そうとしているアプリケーションの ID から、そのアプリケーションが使用しているリッスン ポート番号を伝えることです。エンドポイント マッパーからポート番号を受け取った RPC クライアントは、そのポート番号を宛先として目的のプロシージャーの呼び出しを実行します。


- RPC 動的ポート割り当てについて
RPC は数多くの Windows 標準のコンポーネントで使用されており、呼び出しの際にオンデマンドでアクティブ化されるものも存在します。また、Windows 標準のコンポーネントに限らず、個別に開発されたサード パーティー製のアプリケーションも RPC の仕組みを利用することも多々あります。このように、多数の RPC アプリケーションが様々なタイミングで起動することから、各アプリケーションに固定的にポート番号を割り当てるような実装方法では、ポート番号のバッティングが発生した際にアプリケーションの起動に失敗する可能性が出てきます。その度にポート番号の調整を行うことは、管理面から考えると非効率的と言えるでしょう。

このような背景もあって、RPC サーバー アプリケーションの多くは固定のポート番号でリッスンするのではなく、"RPC 動的ポート" の範囲から現在利用可能なポート番号を取得して使用します。そして、アプリケーションの起動時に自身が使用するポート番号を RPC エンドポイント マッパーに登録して、前述したような仕組みでクライアントがどのポート番号に対してアクセスすればよいかを取得できるようにしているのです。

** RPC 動的ポート割り当てを使用せず、固定ポート番号でリッスンを行い、クライアント側からも直接そのポート番号への通信を行う RPC アプリケーションも存在します。例えば、Windows Server 2003 R2 以降で実装された DFS Replication の機能では、5722/tcp が固定的に使用されています。


- ファイアウォールで許可しなければならないポート番号
RPC サーバー アプリケーションは、起動時に自身がリッスンするポート番号をエンドポイントマッパーに登録します。RPC サーバー アプリケーションが使用するポート番号は、Windows Server 2003 / Windows XP の既定では 1024 番～ 5000 番、Windows Server 2008 / Windows Vista の既定では 49152 番 ～ 65535 番です。このため、RPC サーバーの下記のポート番号宛ての通信が、経路上のファイアウォール、コンピューター上のパーソナル ファイアウォールなどで許可されている必要があります。

・ 135/tcp (RPC エンドポイント マッパー / 全 OS バージョン共通)
・ 1024-5000/tcp,udp (RPC 動的ポート / Windows Server 2003, Windows XP の場合)
・ 49152-65535/tcp,udp (RPC 動的ポート / Windows Server 2008, Windows Vista の場合)

しかしながら、"1024-5000/tcp,udp" や "49152-65535/tcp,udp" のように、広範囲のポート番号の通信をファイアウォールで許可することはセキュリティ上望ましくないと判断されるお客様も多くいらっしゃいます。このような要件を満たすために、RPC 動的ポートで使用されるポートの範囲を変更する方法が下記の弊社サイトにて公開されています。

- 参考情報
ファイアウォールで動作するように RPC の動的ポート割り当てを構成する方法
http://support.microsoft.com/kb/154596/ja

The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008 (英語)
http://support.microsoft.com/kb/929851/en-us

ただし、動的ポートの範囲をあまり狭くしすぎるとポートの枯渇が発生し、やはり RPC サーバー アプリケーションが正常に起動できなくなるなどの問題が発生します。お客様環境の要件合わせて、ある程度余裕を持たせた適切な範囲で設定していただくことをお勧めしております (サポート技術情報 154596 にて記載しております "最低でも 100" という数字も目安になります)。


3.  トラブルシューディング : ネットワーク トレースの解析

最後に、実際にエラーが発生した場合に、ネットワーク トレースを用いてトラブル シューディングを行う方法をご紹介します。

ネットワーク トレースを取得すると、通信のどの段階で問題が発生しているかを特定することが容易となります。弊社からも Microsoft Network Monitor というツールを公開しており、下記の Web サイトからダウンロードしてご利用いただくことが可能です。

Microsoft Network Monitor 3.3
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f


- RPC エンドポイントマッパー (135/tcp) 宛の通信がフィルタリングされている場合
例えば、ntdsutil コマンドを用いて Active Directory の FSMO ロールをメンバー サーバーから変更しようとした際に、下記のようにエラーとなり、操作が行えない現象が発生しているとします。



現象を再現させて、上記のエラーメッセージが出力されるタイミングでのネットワーク トレースを取得します。



上の図が、採取されたネットワークトレースです。Frame 3 ～ Frame4 から、DNS の名前解決には成功していることがわかります。

一方で、Frame 5 ～ Frame7 を見ると、目的のホストである 2k3r2sp2-01 の 135/tcp へのアクセスを行おうとしているにもかかわらず、応答が返されていないことがわかります。このことから、経路上、もしくは目的のサーバー上で、135/tcp 宛の通信がフィルタリングされていることが疑われます。


- RPC 動的ポート (1024-5000/tcp,udp or 49152-65535/tcp,udp) 宛の通信がフィルタリングされている場合
RPC 動的ポートが利用できない場合は、下記のように少し異なるエラーメッセージが出力されます。



ネットワーク トレースを見てみましょう。



Frame8 ～ Frame 11 を見ると、エンドポイント マッパー宛の通信に成功していることがわかります。目的のプロシージャーの呼び出しに使用するべきポート番号が 1026/tcp であることが通知されています。
** 使用される RPC の種類によってはパケットのフォーマットが異なり、この例と同じようにポート番号が表示されない場合があります。ご注意ください。

 

その後、受領したポート番号 1026/tcp 宛に通信を行おうとして、応答が返されていない様子が確認できます。やはり同様に、RPC 動的ポートで使用する通信が経路上、宛先サーバー上でフィルタリングされている可能性が考えられます。


- RPC エンドポイントマッパーにアプリケーションが登録されていない場合
ポートの枯渇などが原因で、RPC サーバー アプリケーションが RPC 動的ポートのバインドに失敗して RPC エンドポイント マッパーにアプリケーションが登録されていない場合もやはり、ネットワーク トレースによってその状況を確認することができます。

やはり同様に、下記のようなエラーメッセージが表示されます。



では、ネットワーク トレースを見てみましょう。



経路上でポートがフィルタリングされている場合と異なり、RPC エンドポイント マッパー (135/tcp) から EP_S_NOT_REGISTERD のエラー コードが返されていることがわかります。これは、指定した RPC サーバー アプリケーションが RPC エンドポイント マッパーに登録されていないことを意味します。

RPC 動的ポートの枯渇とそのトラブルシューディング方法については、下記の Web サイトでも情報を公開しております。

- 参考情報
RPC エンドポイント マッパーのエラーのトラブルシューティングを行う方法
http://support.microsoft.com/kb/839880/ja

「RPC サーバーを利用できません」、「エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません」 のメッセージが出力された場合は、前述したような、名前解決の問題、ネットワーク 通信の経路上の問題、RPC で使用されるポートのフィルタリング、ポートの枯渇などが原因となっていることがほとんどです。本記事が原因追求のご参考となれば幸いです。



「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

Windows 名前解決の順序

こんにちは。Wndows プラットフォーム サポート担当の石丸です。

今日はネットワーク通信を円滑に行うためには欠かせない名前解決が、Windows ではどのような優先順位で行われるかをご紹介します。

一般的に名前解決と言うとまず DNS を思い浮かべるかもしれませんが、Windows では DNS 以外でもブロードキャストや WINS サーバー、HOSTS ファイル、LMHOSTS ファイルなどの様々な仕組みが使われています。このため、自分が今一体何を使って名前解決を行っているかを混乱してしまうかもしれません。システムの設計段階で正しく名前解決が行われる順序を把握しておかないと、突然目的のホストとの通信が行えなくなったりと思いもよらないトラブルの原因となってしまうこともあります。

1. Winsock (Windows Socket) と NetBIOS

Windows ではネットワーク通信を行うための基本的な API を提供するモジュールとして、Winsock と NetBIOS を用意しています。最近では、ほとんどの TCP/IP アプリケーションが Winsock を使用して通信を行っていますが、まだ OS が古いバージョンの頃に開発されたアプリケーションとの互換性を保つために、NetBIOS が使用されることも決して少なくはありません。

** 例えば Windows のファイル共有などに使用される SMB 通信では、Windows Vista がリリースされた現在でも Winsock を使用するDirect Hosting SMB (445/tcp) と NetBIOS over TCP/IP (139/tcp) が併用されています。

重要なのは、Winsock と NetBIOS では、名前解決を行うために使用されるリソースが全く異なることです。このため、どちらの API がネットワーク通信に使用されているかをそれぞれのアプリケーションで確認して、正しい名前解決の順序を把握することが重要となります。


2. Winsock の名前解決

- Winsock 名前解決の順序
さて、肝心の名前解決の順序ですが、基本的な順序は以下の通りです。
1) DNS リゾルバーキャッシュ (*1) を確認して、指定された名前に対応するレコードがキャッシュされている場合は、そのアドレスを返します。
2) HOSTSファイル (*2) を参照し、指定された名前に対応するレコードが登録されている場合はそのアドレスを返します。
3) 登録されている DNS サーバーに問い合わせを行い、受領したアドレスを返します。
4) 上記 1 ～ 3 で名前解決に成功しない場合は、NetBIOS 名前解決を行います。

(*1) "ipconfig /displaydns" コマンドを使用することで、現在、クライアントが保持している DNS リゾルバーキャッシュを確認できます。
(*2) HOSTS ファイルは、"%SystemRoot%\system32\drivers\etc" に存在します。

- HOSTS ファイルに記載したレコードは・・・？
HOSTS ファイルに記載したレコードは、DNS リゾルバー キャッシュに自動的に格納されます。実は、DNS リゾルバー キャッシュを管理する DNS Client サービスが起動している場合は、名前解決が行われるたびに HOSTS ファイルを参照せず、このキャッシュを使用することでパフォーマンスの向上が図られています。

この様子を、下記で確認してみましょう。

1) HOSTS ファイルを編集します。

2) ipconfig /displaydns コマンドで、リゾルバー キャッシュの内容を確認します。

登録した "2003sp2-01" の順引き、逆引きのレコードがそれぞれ DNS リゾルバー キャッシュに格納されている様子が確認できます。

** なお、DNS Client サービスが停止している場合は DNS リゾルバー キャッシュが使用できないため、HOSTS ファイルが直接参照されます。

- Winsock 名前解決の結果を確認する方法
実際に目的のホスト名が Winsock の名前解決によってどのアドレスに解決されるかを確認する方法として、最も簡単なのは Ping コマンドを使用することです。Ping では、Winsock による名前解決が行われるためです。コマンド プロンプトから

   ping hostname

と入力して、期待通りの IP アドレスと通信を行おうとしているかどうかを確認しましょう。

3. NetBIOS の名前解決

NetBIOS 名は DNS の完全修飾名のような階層構造を持たない、単一ラベルの名前です。最大 16 バイトのフィールドを持ちますが、末尾の 1 バイトはサフィックスとして役割を指定するために使用されるため、実際に名前として使用できるのは 15 バイトまでとなります。NetBIOS 名のサフィックスについての詳細は、下記の公開情報をご参照ください。

<参考情報>
NetBIOS サフィックス (NetBIOS 名の 16 番目の文字)
http://support.microsoft.com/kb/163409/ja

- ノード タイプによる違い
さて、NetBIOS の名前解決の順序は、Winsock と比べると少し複雑です。NetBIOS の世界では “ノード タイプ” と呼ばれる概念があり、名前解決を行う自身のコンピューターがどのノード タイプに設定されているかどうかで、名前解決を行う順番が異なるためです。ノードタイプには下記の 4 つがあります。

コンピューターが自身をどのノードタイプと認識するかは、OS のバージョンやコンピューターが持つ役割によって異なります。”ipconfig /all” コマンドを使用することで、現在のノード タイプを確認することができます。

一方で、ノード タイプが正しく表示されないという既知の問題もございますので、ご注意ください。

<参考情報>
"Ipconfig /All" コマンドを実行すると Node Type が Unknown と表示される
http://support.microsoft.com/kb/310570/ja

- NetBIOS 名前解決の順序
1) NetBIOS 名前キャッシュ (*1) を確認して、指定された名前に対応するレコードがキャッシュされている場合は、そのアドレスを返します。
2) 自身のノードタイプに従い、ブロードキャスト、および WINS サーバーの照会により指定された名前の解決を行います。
3) LMHOSTS ファイル (*2) の参照が有効になっている場合 (*3) は当該ファイルを参照して、指定された名前に対応するレコードが登録されている場合はそのアドレスを返します。

(*1) "nbtstat -c" コマンドを使用すると、現在クライアントが保持している NETBIOS 名前キャッシュを確認できます。
(*2) LMHOSTS ファイルは、"SystemRoot%\system32\drivers\etc"に存在します。
(*3) "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netbt\Parameters\EnableLMHOSTS" により指定します。既定値は 1 (有効) です。

- LMHOSTS ファイルに記述したレコードを優先させる方法
上記の通り、NetBIOS 名前解決では、LMHOSTS に記述したレコードよりも NetBIOS 名前キャッシュやノード タイプに従った名前解決が優先されるため、HOSTS ファイルと同じように、強制的に LMHOSTS に記述したアドレスを使用したい場合には不便に感じるかもしれません。

このような要望を満たしたい場合は、下記の手順で LMHOSTS ファイルに記述したレコードに "#PRE" のオプションを追加することで、あらかじめ NetBIOS 名前キャッシュに記述したレコードを登録しておくことができます。

<手順>
1) "%SystemRoot%\system32\drivers\etc\" に、"LMHOSTS" ファイルを作成します。

2) ファイルをメモ帳などのエディタで開き、下記のようにレコードを追加します。
192.168.1.101           hostnameA          #PRE
192.168.1.102           hostnameB          #PRE

3) コマンドプロンプトを開き、下記のコマンドで NetBIOS 名前キャッシュ テーブルの再読み込みを行います。(現在保持しているキャッシュは削除されますので、ご注意ください。)
nbtstat –R

**  "#PRE" は大文字で記述する必要がありますので、ご注意ください。


4. おまけ：トラブルシュート

期待通りに名前解決できない。おかしいなあ・・・と思った時は、一度キャッシュを削除してみましょう。

<コマンド>
Winsock : ipconfig /flushdns
NetBIOS : nbtstat –R
予期せぬレコードがキャッシュに入っていることが原因で名前解決に失敗していることが、意外に多かったりしますよ！

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

DFSR の デバッグログについて

はじめまして。Windows プラットフォームサポート担当の 比留間 友一（ひるまともかず）です。

今回は、Windows Server 2003 R2 以降で導入された、DFS Replication (DFSR) のトラブルシューティングにおける影の主役、デバッグログについてお話したいと思います。

1. DFSR のデバッグログとは？

DFSR サービスは、バックグラウンドで人知れず（？） 循環形式のデバッグログを出力しつづけています。

いざトラブルシューティング！ となった際には、このデバッグログを解析する必要が出てくる場合も少なくありません。

私たちサポート担当者にとっては、まさしく命綱とも言える存在ですが、「デバッグログ」という名の通り、トラブルが発生しない限りは見る必要もありませんので、少しでもディスクの使用量や I/O を節約したい環境では、出力先のドライブを変えたいと思うこともあるかもしれません。

一方で、大規模なレプリケーショングループを構成している環境では、デフォルトの出力設定ではログサイズが足りず、肝心な情報が上書きされてしまっていて記録が残っていない、といった事も起こり得ます。

2. 現在のデバッグログの出力設定を確認する

既定の状態で、DFSR デバッグログは、 %windir%\debug フォルダに出力されます。

1ファイルにつき、約 200,000 行のエントリを出力し、100世代のファイルで循環出力を行います。

この設定で、およそ 50 – 100 MB程度のディスク容量を使用します。

現在ログが出力されているログファイルは DFSRxxxxx.log というファイル名で、その他のログファイルは、DFSRxxxxx.log.gz というファイル名で、GZ 形式で圧縮されています。

（xxxxx の部分には通し番号が入ります。）

現在のデバッグログの出力設定は、以下のコマンドで確認することができます。

コマンド構文

Dfsrdiag DumpMachineCfg /mem:<サーバー名>

3. デバッグログの出力設定を変更する

DFSRサービスを実行しているサーバー上で、WMIC コマンドを使用することで、デバッグログの出力設定を変更することができます。

なお、デバッグログの出力設定は、レプリケーションの対象となりませんので、各サーバーごとに個別に設定する必要があります。

出力対象となるログの重要度（DebugLogSeverity）を変更する：

既定値：4

有効範囲：1 – 5

コマンド構文

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogseverity=5

DebugLogSeverity の説明は以下のとおりです。

5 で最も詳細な出力になります。

既定で 4 が設定されていますが、詳細なトラブルシューティングの場合を除けば、通常、この設定の出力で十分です。

1 … ログのヘッダ部分のみ記録します。

2 … エラー [ERROR] イベントおよび、上記の全てを出力します。

3 … 警告 [WARN] イベントおよび、上記の全てを出力します。

4 … 情報レベルのイベントおよび、上記の全てを出力します。

5 … 内部処理の詳細なトレース情報および、上記の全てを出力します。

1ファイルあたりに書き込まれるログエントリ数 (MaxDebugLogMessages) を変更する：

既定値：200000

有効範囲：1000 - 4294967295 (FFFFFFFF)

コマンド構文

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set maxdebuglogmessages=500000

使用するログファイル数 (DebugLogFiles) を変更する：

既定値：100

有効範囲：1 – 10000

コマンド構文

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set maxdebuglogfiles=200

ログの出力先パス (DebugLogFilePath) を変更する：

既定値：%windir%\debug

コマンド構文

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set debuglogfilepath="d:\dfsrlogs"

注意：出力先のパスは事前に手動で作成しておく必要があります。

指定されたパスが存在しない場合、 DFSR サービスの再起動時に、既定の %windir%\debug に設定が戻ります。

デバッグログの出力の有無 (EnableDebugLog) を変更する：

既定値：TRUE

有効範囲：TRUE または FALSE

コマンド構文

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set enabledebuglog=true

注意：FALSE 設定にすると、デバッグログが一切出力されなくなります。これにより、トラブルの発生時に原因の特定が困難になる可能性があります。デバッグログの出力自体がシステムに何らかの悪影響を及ぼしている場合以外は、デバッグログの出力を無効にすることはお勧めできません。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

Windows ファイアウォールの設定がきえた～？！（Windows XP）

みなさん、こんにちは！

既に多くの環境では Windows Vista が主流になっているかと思いますが、今回はまだまだお問い合わせの良くある Windows XP の Windows ファイアウォールに関する情報をご紹介いたします。

ドメイン環境の Windows Server 2003 や Windows XP の端末において、Windows ファイアウォールを無効に設定していたり、特定のポートなどに関しての例外を設定していたのに、ある日突然 Windows ファイアウォールが有効になった、または例外設定が消えていたなどという問題は無かったでしょうか。また、その後、いつの間にかその設定が元通りに戻り、例外設定が復活していたりして、「どうして??」 と思うことがあるかもしれません。

1. このような現象が発生している理由

====================================

この問題が発生している場合、実際には設定が消えていたり、変更されているわけではなく、読み込まれているプロファイルが切り替わったことが原因である場合がほとんどです。

Windows ファイアウォールには [ドメイン プロファイル]、[スタンダード プロファイル] という二つのプロファイルが存在します。

ドメインに参加しており、ドメインにログオンした場合にはドメイン プロファイルが読み込まれ、そのプロファイルに設定されている項目が反映されます。

ドメインのメンバーでない場合や、ドメインのメンバーでもドメイン コントローラーと通信できないなどの理由で、キャッシュ ログオンをした場合などには、スタンダード プロファイルが読み込まれます。

もし、設定していた Windows ファイアウォールの例外設定が消えたと思ったら、その時にどちらのプロファイルが読み込まれているかを確認してみてください。

片方のプロファイルでしかファイアウォール無効や例外設定がされていなかった場合、もう片方のプロファイルが読み込まれていたことが原因で、設定自体が削除されたように見えてしまうことがあります。

2. どちらのプロファイルが読み込まれているかを確認する方法

===============================================================

どちらのプロファイルが読み込まれているのかを確認するには、現象が発生している端末にて、コマンド プロンプトから以下のコマンドを実行します。

図1

これを正常時と現象発生時で比較し、プロファイルが異なっている場合には、読み込まれたプロファイルが異なることが原因で現象が発生していることがわかります。

また、レジストリを確認することでも 各プロファイルにて Windows ファイアウォールが有効になっているか、例外設定がされているかを確認することができます。

Windos XP や Windows Server 2003 の場合、Windows ファイアウォールの設定はレジストリに格納されているので、レジストリ エディタを開き、下記レジストリ キーを確認することで、それぞれのプロファイルの設定を確認することができます。

・ドメイン プロファイルの設定情報

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile

・スタンダード プロファイルの設定情報

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile

図2

例えば、レジストリ EnableFirewall の値が 1 の場合は Windows ファイアウォールが有効になっており、0 の場合には無効になっていることがわかります。

3. この問題を回避する方法について

====================================

問題を回避する方法は至ってシンプルです。読み込まれるプロファイルが異なることが原因なので、どちらが読み込まれてもいいように、二つのプロファイルの設定を同一にするのです。どちらも設定が同じなので、読み込まれるプロファイルによって例外の設定が消えたり、Windows Firewall の有効 / 無効が切り替わることは無いはずです。

これを実現する一つの方法として、既に例外設定などを片方のプロファイルで設定している場合、netsh コマンドを使用して、設定が行われていないプロファイルに例外設定を一つ一つ追加する方法があります。しかし、多数の例外設定が設定されている場合、かなりの工数が必要になることが予想されます。

* netshコマンドを使用したファイアウォールの管理方法の詳細については下記リンクをご参照ください。

ヘルプ : Netsh を使用して Windows ファイアウォールを管理する

http://technet.microsoft.com/ja-jp/library/cc776229(WS.10).aspx

その場合、既に設定されているプロファイルのレジストリをエクスポートし、別のプロファイル用に内容に変更を加えた上で、レジストリをインポートすることで、工数を減らすことができます。

以下では設定がスタンダード プロファイルにのみされている場合に、その設定をドメイン プロファイルにインポートする方法を記述いたします。

1) まず最初に、スタンダード プロファイルの設定をエクスポートします。

レジストリ エディタの左ペインから Standard Profile のレジストリ キーを右クリックし、エクスポートを選択することで、レジストリ値をエクスポートすることができます。

図3

エクスポートを選択すると、ファイル名、保存先を選択するウィンドウが表示されるので、適当な場所に保存します。

2) エクスポートした情報をドメイン プロファイル用に変更します。

エクスポートした reg 形式のファイルを右クリックし、編集を選択すると、テキスト形式でファイルが開きます。

図4

ここに記録されているのがスタンダード プロファイルの設定の全てです。

これをドメイン プロファイル用に変更するには、単純に [] で囲まれているレジストリ キーに含まれる StandardProfile という文字を DomainProfile に書き換えるだけです。

図5

変更後、メニュー バーにあるファイルから名前をつけて保存を選択し、reg 形式で保存します。

* 例えば、domain.reg という名前で保存します。

3) ドメイン プロファイル用のレジストリをインポートする。

これは至って簡単で、 2) で作成した reg 形式のファイルをダブル クリックするだけです。

ダブル クリックすると以下のメッセージが表示されるので、”はい”を選択します。

正常にレジストリにインポートされると以下のメッセージが表示されます。

レジストリ エディタを開き、ドメイン プロファイルの設定を確認すると、スタンダード プロファイルと全く同じ設定になっていることが確認できます。

これにより、ドメイン プロファイル、スタンダード プロファイルのいずれが読み込まれても、ファイアウォールの有効/無効が切り替わったり、例外設定が消えるといった問題は発生しなくなります。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

サポート技術情報　(6/7-6/20) - Windows Server 2008 R2 資料公開　編

みなさん、こんにちは！

そろそろ蒸し暑い日々が多くなってきましたが、お元気にしておられますでしょうか？

＜今週のPickup： Windows Server 2008 R2 資料公開＞

現在ベータ版を提供しております次世代サーバー Windows Server 2008 R2 に関するホワイトペーパー、パワーポイント形式の資料などを纏めた Web サイトを公開しました！。

このページより、様々な資料がダウンロードできます。

是非いちどご参照ください！

Windows Server 2008 R2 Documentation & Resources

http://www.microsoft.com/downloads/details.aspx?FamilyID=079eb880-6e15-4381-9edf-53cfaff3ab02&displayLang=en#filelist

提供資料一覧

＜サポート技術情報一覧＞

6/7-6/20に公開されましたサポート技術情報 (Knowledge Base) の一覧をご案内いたします！

是非ご活用くださいませ！

AD Recycle Bin – Windows Server 2008 R2 Active Directory の新機能

Windows Server 2008 R2 から Active Directory にもゴミ箱の機能が追加されます。ここではその新機能についてご説明致します。

1) これまでの機能について
これまでの Windows では、Active Directory にて削除してしまったオブジェクトを復元する方法は 2 通りありましたが、いずれの方法にも以下のような問題がありました。

1. バックアップから非 Authoritative Restore でオブジェクトを復元する
   バックアップを復元するにはドメイン コントローラを 「ディレクトリ サービス復元モード」 で起動する必要がある為、その間作業をするドメイン コントローラが利用できなくなる。
2. Deleted Objects コンテナから復元する
   Deleted Objects コンテナへと移動されたオブジェクトは属性の多くが削除されている為、リストア後各オブジェクトの削除された設定(所属グループ等) を手動で再設定する必要がある。

Windows Server 2008 R2 から追加される Active Directory のゴミ箱の新機能を用いる事により、これまでのように DC の機能を停止する事なく、さらにオブジェクトの全属性を復元する事が可能となりました。

2) 設定方法
Active Directory のゴミ箱を利用するにはまず Windows Server 2008 R2 のフォレスト機能レベルが必要になります。つまり、ドメイン コントローラがすべて Windows Server 2008 R2 である必要があります。また、Active Directory のゴミ箱の機能は既定では無効になっている為、Powershell の Enable-ADOptionalFeature コマンドで設定を有効にします。詳細な手順は以下の通りです。

1. Powershell.exe を起動し、以下のコマンドで Active Directory の機能をロードします。
   import-module ActiveDirectory
   
   
2. 以下のコマンドを実行し、Active Directory ゴミ箱の機能を有効します。設定を有効にすると、無効にできない旨を示す警告が表示されるので Y を入力します。
   Enable-ADOptionalFeature ‘Recycle Bin Feature’ –Scope ForestorConfigurationSet –Target <AD 名>
   
   実行例：
    

3) 動作説明
これまでの Active Directory では以下の流れでオブジェクトは削除されました。

1. Active Directory からオブジェクトを削除すると、該当オブジェクトは DeletedObjects コンテナに移動されます。この時、オブジェクトの大半の属性が削除されます。
2. tombstoneLifetime を過ぎるとオブジェクトが DeletedObjects からも削除され、データベースから完全に削除されます。

Active Directory のゴミ箱を有効にした場合、オブジェクトを削除してから属性が削除されるまでに時間 (msds-DeletedObjectLifetime) があり、この間はオブジェクトを完全に復元する事ができます。つまり、以下のように上記流れに 1 ステップ追加されます。

1. Active Directory からオブジェクトを削除すると、該当オブジェクトは DeletedObjects コンテナに移動されますが、Active Directory のゴミ箱の機能が有効な場合には、このタイミングでは属性が削除される事はありません。
2. msDS-deletedObjectLifetime 属性に保持される期間 (既定では tombstoneLifetime と同じ) が過ぎた後、属性が削除されます。この時、オブジェクトは DeletedObjects に既に存在する為、オブジェクトはそのままの状態で属性のみが削除されます。
3. tombstoneLifetime を過ぎるとオブジェクトが DeletedObjects からも削除され、データベースから完全に削除される。

4) オブジェクト復旧手順
オブジェクトを復旧するには Powershell の Get-ADObject 並びに Restore-ADObject コマンドを利用します。以下の手順では例としてユーザー User1 を復元します。

1. Powershell.exe を起動し、以下のコマンドで Active Directory に機能をロードします。
   import-module ActiveDirectory
   
2. Get-ADObject を利用し、削除したオブジェクトを特定します。
   a) まずワイルドカード (*) を利用し、該当する可能性のあるオブジェクトを列挙します。以下のコマンドでは名前に user の文字列を含むオブジェクトを Deleted Objects コンテナから検索した結果、2 つ該当するオブジェクトが見つかっています。
   
   実行例：
   
   b) Get-ADObject で該当オブジェクトのみを特定します。ここでは、上で表示された User1 のみを復元するため、そのオブジェクト名を Filter します。 (削除されたオブジェクト名は <User名>\0ADEL:<GUID> の形式でリネームされています。)
   
   実行例：
    
   
3. Restore-ADObject を利用して、2. で特定したオブジェクトを復元します。以下のコマンドでは 2. で特定したオブジェクトを | でそのまま Restore-ADObject に渡します。
   
   実行例：
    

この時、ツリー形式のオブジェクトを復元する場合には必ず親ディレクトリから復元してください。(OU をすべて復元する場合には親 OU を復元してから、中のオブジェクトを復元します。)

英文にはなりますが、以下の technet に詳細が記載されています。

   Active Directory Recycle Bin in Windows Server 2008 R2 Step-by-Step Guide [R2]
   http://technet.microsoft.com/en-us/library/dd392261.aspx

5) 注意点について
Active Directory のゴミ箱の機能はスキーマ拡張と同様、後戻りができない機能になります。一度ゴミ箱の機能を有効にすると、既定の無効に戻す事はできません。

ご注意：ここに記載した内容は Windows Server 2008 R2 RC 版での情報ですのでご了承ください。製品版での動作・情報が変更となる可能性にご留意ください。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

サポート技術情報　(5/31-6/6) - RODC紹介編

サポート技術情報　(5/31-6/6) - RODC紹介編

みなさん、こんにちは！お元気ですか？

うわさのあたらしい検索エンジン Bing、もうお使いでしょうか？

http://www.bing.com/?cc=jp

まだ触ったことないという方、ぜひ一度おためしください！

Feedback は右下の [ご意見ご感想] からお送りいただけますので、ぜひ！

<今週の Pick Up： RODC ガイド>

今週は RODC に関するガイドが幾つかあたらしく公開されましたので、この機会に少し RODC についての情報をご紹介いたします！

最近では実際にサポートのお問い合わせをいただく機会も少しずつ増えてきましたので要チェックです！

● RODC とは？

すでによくご存知の方も多いかとはおもいますが、Windows Server 2008 においては、読み取り専用ドメイン コントローラー (RODC) が新しく登場しています。

読み取り専用ドメイン コントローラー (RODC) は、Windows Server 2008 にて追加された新しい種類のドメイン コントローラです。

RODC では、Active Directoryのデータベースを読み取り専用のパーティションとして保持しており、書き込みを行うことができません。

地方営業所などの遠隔拠点地 = “ブランチオフィス” への IT 環境の整備も重要な管理者の役割のひとつです。このような “ブランチオフィス” への設置を主にターゲットにしています。

たとえば、遠隔地のオフィスや WAN 環境のオフィスなど、認証等の処理をするためのサーバーが必要なものの、通常の書き込みが可能なドメインコントローラーを設置するにはセキュリティなどの観点から不安な拠点があるとします。このような拠点には、従来のドメイン コントローラーを設置した場合、物理的な盗難や書き込みが発生することにより、ドメイン全体への影響が懸念されるため、ドメインコントローラーを設置することを控えることが多くありました。しかし設置しない場合、認証のための処理が WAN 回線を往来するなどの必要があるため、トラフィックや処理時間の増加が発生してしまい悩みの種でした。。。。

しかし！ 新しい RODC を使用することで、このような拠点には、より安全にドメインコントローラーを設置することが出来ます！

● 一般的な RODC についての説明 (インストール方法や設定方法など) は下記に情報があります。併せてご参照ください

RODC とは

http://technet.microsoft.com/ja-jp/library/cc755058(WS.10).aspx

RODC の機能

http://technet.microsoft.com/ja-jp/library/cc753223(WS.10).aspx

ステップ バイ ステップ ガイド - 読み取り専用ドメインコントローラ

http://technet.microsoft.com/ja-jp/library/cc772234(WS.10).aspx

付録 B : RODC を使用した認証プロセスのしくみ

http://technet.microsoft.com/ja-jp/library/cc771144(WS.10).aspx

RODC についてよく寄せられる質問

http://technet.microsoft.com/ja-jp/library/cc754956(WS.10).aspx

● RODC in ブランチオフィス

下記のホワイト ペーパーにて、新しい Windows Server 2008 における新機能を、ブランチオフィスへの IT 環境整備に役立つ利点を中心として、説明しています。

たとえば、現在ブランチオフィスに設置している Windows Server 2003 などのドメイン コントローラーを、Windows Server 2008 の読み取り専用ドメイン コントローラー (RODC) にアップグレードする場合の検討方法などについての情報が含まれています。

下記の WEB サイトよりホワイト ペーパーをダウンロード可能です。

　タイトル： Read-Only Domain Controller (RODC) Branch Office Guide

　リンク： http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0b2a6fcb-8b78-4677-a76c-2446039ab490

● RODC in 境界ネットワーク (Perimeter Network)

外部ネットワークと内部ネットワークの境界ネットワーク (いわゆる DMZ) といいます。この境界ネットワークにおける IT 環境の整備に Windows Sever 2008 のご利用を検討されている方も多いのではないでしょうか。

RODC を境界ネットワークに配置することも可能です。

ただし、境界領域であることから、様々な点を考慮する必要があります。

下記のガイドでは、境界ネットワークに Active Directory の機能を持たせる必要性、サンプルモデル、RODC 配置について説明をしています。

下記の WEB サイトよりホワイトペーパーをダウンロード可能です。

　タイトル：Active Directory Domain Services in the Perimeter Network (Windows Server 2008)

　リンク：http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c1d0fd00-bf31-4b20-95c6-279a4ce7c2b4

<今週公開されたサポート技術情報　リスト>

今週 新たに公開されましたサポート技術情報のリストをご案内いたします。

文書番号 972034 においては、端末に保存してある HOSTS ファイルを既定に戻すための方法をご案内しており、自動修正ツールを “Microsoft Fix it” にてご提供しています。

名前解決がおかしくなった?! 、HOSTSファイルを戻したい！という方は、ぜひご参照ください！

ドメインにログオンできない ～ セキュア チャネルの破損 ～

はじめまして！ Windows プラットフォーム サポート担当の石丸 宰 (いしまる つかさ) です。

今日は、"セキュア チャネルの破損" が原因でドメインにログオンできなくなる現象について、その見分け方と対処方法をご紹介したいと思います。


1. "セキュア チャネル" と "コンピューター アカウント パスワード"

Active Directory ドメインのメンバーとなっているクライアントは、ドメインコントローラー (以下 DC と記述) との間の通信を保護するために、セキュア チャネルと呼ばれる通信チャネルを使用します。認証に使用される資格情報などはこのセキュアチャネルによって暗号化され、安全な状態でネットワークを経由してやりとりされます。セキュア チャネルは下の図のように、クライアントごとに個別に作成されます。

* なお、 "クライアント" はドメインのメンバーを指しており、 Windows Server 2003 / 2008 も DC でなければ、以下の説明や図では、"クライアント" に含まれます。



DC とクライアントはお互いに、セキュア チャネルを確立するために必要となる "コンピューター アカウント パスワード" を持ちあっています。このパスワードは、DC 上ではコンピューター アカウントの属性値に、クライアント上では LSA シークレットと呼ばれる領域にそれぞれ格納されています。

クライアント コンピューターが起動すると、まず最初にコンピューターアカウントのパスワードを用いて資格情報を生成し、DC にコンピューター認証の要求を送信します。認証に成功すると、認証処理の中で生成されたセッション・キーを用いてクライアントと DC の間にセキュア チャネルが確立されます。前述の通り、ユーザーのドメインへのログオン要求などの通信はセキュア チャネルを用いて行われるような仕組みになっているので、コンピューター認証に失敗し、セキュアチャネルが確立ができないような状況ではユーザーはドメインにログオンすることはできません。

何らかの理由によって DC とクライアントが保持するコンピューター アカウントのパスワードに不整合が生じた場合、セキュア チャネルを確立することができなくなり、そのコンピュータからはドメインへのログオンができなくなります。これが、セキュアチャネルの破損と呼ばれる現象です。


2. セキュア チャネル破損の見分け方は？

それでは次に、ログオン失敗の原因がセキュアチャネルの破損であるか否かをどのようにして見分ければよいか、その方法をご紹介します。

- ログオン失敗時のふるまい
セキュア チャネルが破損していると、通常は正しいユーザー名とパスワードを入力してもデスクトップにログオンすることができないのですが、コンピュータ起動後のネットワーク確立に時間を要している場合などには、以前にログオンに成功した際にキャッシュした情報を用いてクライアントコンピュータにはログオンできるようになっている場合もあります。この場合は、一見ドメインへのログオンに成功しているかのように見えます。

* ただし、クライアントにキャッシュ ログオンしている状況では、自分のデスクトップを開いてローカルコンピュータのリソースを使用することはできるものの、ネットワーク経由でドメインのリソースを使用する場合には、様々な制約を受けることがあります。

また、キャッシュ ログオンもできずにデスクトップにログオンできない場合のエラーメッセージも、Windows XP では下記の画面のように表示され、この場合は DC との接続に何らかの不具合が発生していることがうかがえるのですが・・・




Windows Vista では通常のパスワード間違いの場合と同様、下のような画面が表示されることがあります。



これでは、ユーザー名、パスワードの間違いとの区別がつきません。

また、これらのエラーメッセージはネットワークの接続状況などの条件に応じて、色々と表示される内容が異なります。このため、ログオン失敗時のふるまいからセキュアチャネルの破損が原因でログオンに失敗していることを見分けることは難しい場合が多いのです。

- クライアントのシステムログで Netlogon 3210 の出力を確認！
では、どうやってセキュアチャネルの破損を見極めればよいのでしょうか。経験上、最も確率の高い方法はクライアントコンピューターの [イベント ビューア] を開き、システム ログに Netlogon 3210 のエラーイベントが出力されていないかどうかを確認することです。

ユーザー名とパスワードを正しく入力しているはずなのにドメインにログオンできない、もしくはキャッシュログオンしてしまうといった場合は、まずはクライアント コンピューターの管理者権限を持つローカル アカウントでログオンして、システム ログを確認してみましょう！

下記の画面のように、Netlogon 3210 のエラーイベント出力されていれば、セキュア チャネルの破損が疑わしいと考えられます。

<Windows Vista の場合>


<Windows XP の場合>



- DC 側のシステムログもあわせて確認！
さらに、セキュア チャネルの破損によってログオンできないような状況では、DC 側の イベント ビューアのシステム ログにも下記のような Netlogon 5722 のエラーイベントが出力されることがあります。(ただし、このイベントはセキュア チャネルの破損の状況によっては出力されないこともありますのでご注意ください。)



クライアント側の Netlogon 3210 に加えて、DC 側でも Netlogon 5722 のエラー イベントの出力を確認できた場合は、セキュア チャネルの破損である可能性がかなり高いと判断できます。


3. セキュア チャネルが破損した時の対処方法

結論から先にお話しすると、セキュアチャネルが破損してしまった場合、問題の発生したクライアント コンピューターを一度ドメインの登録から外して、再度ドメインに参加させる必要があります。

コンピューター アカウントのパスワードは、ユーザーアカウントのパスワードのように DC 側でパスワードのリセットを行って、次回以降はユーザーが新しく設定したパスワードを使用する・・・といった方法を使うことができません。これは、コンピューターアカウント パスワードの更新はセキュア チャネルを使用して、DC とクライアントの間で対話的に行う必要があり、どちらからが一方的にパスワードを変更することはできないからです。

もしクライアント側で保持しているパスワード情報のみがおかしくなってしまったのであれば、クライアントをバックアップからリストアするという方法もありますが、そのような状況は稀でしょう。また、詳しくは後述していますが、サポート ツールで提供されている nltest や netdom などのツールを使用しても、クライアントコンピューターをセキュアチャネルが破損した状態から回復させることはできません (ただ、余談ではありますが、セキュアチャネルが破損したのが DC である場合は、KB 435000 に記載されている手順で対処できる場合があります) 。

それでは、下記にクライアントをドメインに再参加させる手順をご紹介します。

1) [コントロール パネル] を開き、[システム] をダブル クリックします。
2) (Windows Vista の場合) 開いた画面の左側のメニューから、"システムの詳細設定" をクリックします。
3) [コンピュータ名] タブを開き、[変更] ボタンをクリックします。
4) [ワークグループ] のラジオボタンを選択し、ワーク グループ名を入力して [OK] をクリックします。
5) コンピューターを再起動します。
6) 再度、1 ～ 3 の手順を実施して、コンピュータ名 / ドメイン名の変更の画面を開きます。
7) [ドメイン] のラジオ ボタンを選択し、再参加するドメイン名を入力して [OK] をクリックします。
8) コンピューターを再起動します。


4. セキュア チャネルが破損する原因は？

セキュア チャネルが破損する原因は様々ですが、一般的には下記のような状況で発生することが多いようです。

• クライアントがバックアップからリストアされた際に、クライアントの保持するパスワードが古いパスワードに書き換えられ、DC が保持するコンピューター アカウントのパスワードと不整合が生じた場合
• DC 上の Active Directory のデータベースがバックアップから復元された際に、DC が保持するコンピューター アカウントのパスワードが古いパスワードに書き換えられ、クライアントの保持するパスワードと不整合が生じた場合
• クライアントのドメイン参加後、DC 上の管理ツールなどで、当該のコンピューターアカウントが一旦削除され、再度同じコンピューター名のアカウントが作成された場合
• クライアントのドメイン参加後、DC 上の管理ツールなどで、当該のコンピューターアカウントに対して "アカウントのリセット" が実施された場合
• クライアントで使用されていたコンピューター名が他のクライアントで使用され、ドメインへのログオンなどが行われた場合
• サード パーティ製のアプリケーションにより、クライアントもしくは DC が保持するコンピューター アカウントのパスワードに関する情報を書き換えたために不整合が生じた場合
• ファイルの破損、ディスクへの書き込みのエラーなどで、DC 上の Active Directory データベースに問題が生じた。もしくは、同じ理由でクライアントの保持するパスワードに問題が生じた場合

上記の中でも、特に弊社に寄せられるお問い合わせが多いケースとしては、クライアントコンピューターをバックアップからリストアした場合です。

コンピューター アカウントのパスワードは、既定では 30日間隔で自動的に更新されます。このため、クライアントと DC のいずれか一方のみを古いバックアップデータからリストアすると、片方に古いコンピューター アカウントのパスワードが復元されてしまい、不整合が生じることが原因です。

もちろん、これら以外の理由でもセキュア チャネルが破損する可能性はあるのですが、ほとんどの場合は問題発生後の事後調査となってしまうため、最終的に原因がわからないことが多いというのが実情です。 


5. セキュア チャネルの状態を確認・変更するツール

最後に、セキュア チャネルの状態を確認・変更することができるツールとして、"nltest" と "netdom" をご紹介します。

nltest と netdom は、ドメインの信頼関係やセキュア チャネルの状態などの Active Directory に関するさまざまなテスト、管理を行うことができる、強力なコマンドラインユーティリティです。これらのコマンドには非常に多くのオプションが用意されており、様々な目的に使用することができます。詳しくは "/?" オプションでコマンドを実行して、ヘルプの内容をご確認ください。本稿ではそれらのオプションの中から、セキュアチャネルに関するコマンド オプションの利用方法をご紹介したいと思います。

- 導入方法
これらのツールは Windows Server 2008 では既定でインストールされていますが、Windows 2003、XP では Windows サポート ツールのインストールが、Windows Vista においては Microsoft Remote Server Administration Tools for Windows Vista (RSAT) のインストールが必要となります。( => RSAT についての詳細はこちらの記事をご参照ください！)

- ダウンロード先 URL
Windows Server 2003 Service Pack 2 32-bit Support Tools
http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en

Windows XP Service Pack 2 サポート ツール
http://www.microsoft.com/downloads/details.aspx?FamilyID=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=ja

Windows Vista 用 Microsoft リモート サーバー管理ツール
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=9ff6e897-23ce-4a36-b7fc-d52065de9960

Windows Vista for x64-based Systems 用 Microsoft リモート サーバー管理ツール
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=d647a60b-63fd-4ac5-9243-bd3c497d2bc5 

- セキュア チャネルの検証を行う
クライアント コンピューターと DC との間で正しくセキュア チャネルを確立できているかどうかを検証します。例えば、セキュア チャネルが破損していてキャッシュログオンしているクライアント コンピューターに対して下記のコマンドを実行するとエラーの結果が出力されます。
<コマンド実行例>
  nltest /SC_VERIFY:{ドメイン名}
  netdom verify {コンピューター名} /domain:{ドメイン名}

- コンピューター アカウントパスワードのリセット
セキュア チャネルの確立に使用するコンピューターアカウントのパスワードをリセットします。
<コマンド実行例>
  nltest /SC_RESET:{ドメイン名}
  netdom reset {コンピューター名} /domain:{ドメイン名}

- コンピューター アカウントパスワードの更新
セキュア チャネルの確立に使用するコンピューターアカウントのパスワードを更新します。
<コマンド実行例>
  nltest /SC_CHANGE_PWD:{ドメイン名}

** 留意事項-1 **
上記のいずれのコマンドも、nltest はクライアント側で、netdom は DC 側で実行します。

** 留意事項-2 **
nltest や netdom を用いてパスワードのリセットや更新を行うためには、DC との間でセキュア チャネルが確立されている必要があります。このため、セキュアチャネルの破損後には、これらのコマンドを用いてもパスワードのリセットや更新を行うことはできません。一度破損してしまったセキュア チャネルを復旧するためには、やはりドメインへの再参加を行う必要があることにご留意ください。

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

Microsoft Remote Server Administration Tools (RSAT)

みなさん、こんにちは！

今日は、お使いになると便利な管理ツールのインストール手順をご紹介します。

もうすでにご活用いただいている皆様も多いかと思いますが、すこし手順が複雑なツールなので、おさらいとしてもお役に立てれば幸いです。わたしもこの手順をすっかり忘れていて苦労したことがあります。。。

Windows Vista / Windows Server 2008 においては、新しい管理ツールMicrosoft Remote Server Administration Tools (RSAT) をご用意しています。

このツールは、以前のバージョンの OS において Administration Pack として提供されていたツールの後継版で、同様に以前のバージョンの OS にありました Support Tools に含まれている一部のツールも同梱されています。

(Windows Vista 以降は、Administration Pack や Support Tools はインストールできません。)

このツールを導入することで、管理者はサーバを管理するための様々な機能を使用することができます。

Active Directory環境においては、NETDOM, NLTEST などのコマンドや、グループ・ポリシー・管理コンソール（GPMC）を利用される管理者の方が多いかと思いますが、これ等のツールは RSATに含まれています。

特にVista RTMでは GPMCがインストールされていますが、SP1 を適用すると GPMC が削除されてしまいます。このため、Vista SP1 においては、RSAT を導入していただく必要があります。突然 GPMCが消えてしまった！と驚いた皆様、RSAT にてご用意しておりますので、インストールくださいますようお願いします。

注意： 本ツールの適用対象は Windows Vista SP1 以降です。

- ツールの入手先

以下のウェブサイトより、RSAT ツールをダウンロードして下さい。

<32 ビット版>

Windows Vista 用 Microsoft リモート サーバー管理ツール

http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=9ff6e897-23ce-4a36-b7fc-d52065de9960

<64 ビット版>

Windows Vista for x64-based Systems 用 Microsoft リモート サーバー管理ツール

http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=d647a60b-63fd-4ac5-9243-bd3c497d2bc5

- インストール手順

1. 入手した RSAT ツールを、端末にインストールします。
ツールをダブルクリックし、インストールを開始します。ウィザードに従い、インストールを完了してください。

2. RSAT 機能を有効化します。
[コントロールパネル] - [プログラム] - [プログラムと機能] - [Windows の機能の有効化または無効化] を開きます。

3. [Windows の機能] ウィンドウにおいて、[リモートサーバー管理ツール] にチェックを入れてください。ご利用になる機能にチェックをいれることで機能が有効化できます。

サポート技術情報　(5/24-5/30) - W2k8/vista SP2 リリース・5月度日本語KB紹介 編

みなさん、こんにちは！

いよいよ梅雨の足音が聞こえてきたようで、通勤、通学に傘が手放せない日々ですね。

今週も、最新公開技術情報をご案内いたします

<今週の Pickup： Windows Server 2008 /Vista SP2 公開>

すでにご存知の方も多数かと思いますが、5 月 26 日に Windows Server 2008 および Windows Vista の Service Pack 2 が公開されました！

今週公開しましたサポート技術情報 968849 において、最新のサービスパックの入手先 (現在はSP2) をご紹介するページを公開しました。

タイトル： 最新の Service Pack for Windows Server 2008 の入手方法

URL:　http://support.microsoft.com/?kbid=968849

サービスパックの入手先、リリースノート、よく寄せられる質問への参照先などが纏めてありますので、SP2 についての確認事項がありましたら、ぜひこのページをご参照ください。

<今週公開されたサポート技術情報　リスト>

今週あらたに公開されましたサポート技術情報のリストです。

また、5 月度に、あらたに公開されました、日本語のサポート技術情報のリストです。

Microsoft では主に英語の技術情報を公開し、日本語の機械翻訳を提供していますが、日本のお客様にもわかりやすいように、手動翻訳もしくは日本オリジナル技術情報も提供しています。

Network および Active Directory に関連する情報だけではありませんが、ぜひご一読いただければと思います。

サポート技術情報　(5/10-5/23) - W2k8 フォレスト障害回復ホワイトペーパーのご紹介　編

みなさん、こんにちは！

雨の日が続き洗濯物がたまる日々ですね。。。

今週もあたらしい技術情報のご案内いたします！ 皆様のお役に立てますと幸いです！

Net Technet White Paper Pick Up

Microsoft では、運用に際してご参考になるガイドをホワイトペーパーとして公開しています。

今回は、先日公開されました、Active Directory運用者の方に是非ご参照いただきたい Active Directory障害対策のホワイトペーパーをご紹介します。

Windows Server 2008: Planning for Active Directory Forest Recovery

http://www.microsoft.com/downloads/details.aspx?familyid=326C8A7A-DCAD-4333-9050-A6303FF3155C&displaylang=en

フォレスト全体に発生した問題により、すべてのドメインコントローラを復旧しなければならない、というような障害に備えるためのホワイトペーパーです。

障害に備えてバックアップを行う方法、障害回復手順などが纏められています。

スキーマ拡張などは、フォレスト全体のドメインコントローラに影響を与えます。作業後に問題が発生した場合は、ロールバックを行わなければなりません。

そのような場合に備えて、ぜひ一度ご確認ください。

新しく公開された Knowledge Base

5/10-5/23 にあらたに公開されたサポート技術情報のリストをご案内します。今週もぜひご参照いただけますと幸いです！

サポート技術情報 (5/3-5/9) - Wk28 /Vista SP2 TCPの Half-Open 上限数 編

みなさん、こんにちは！

五月も後半になってきましたね。

いよいよ陽気も急に初夏を感じるようになってきて、時が過ぎるのは早いものですね。。。

さて、今週も、5/3– 5/9 に新たに公開されました公開技術情報をご紹介いたします。

(公開技術情報 969710)

Windows Server 2008 SP2 および Windows Vista SP2における機能変更： TCPの Half-Open 上限数

さて、Windows Server 2008 SP2 および Windows Vista SP2  も、RC版が公開されております。

現在、この環境でテストや検証をされている方も多いのではないでしょうか。

サービスパックにおいては、様々な修正が含まれており、また機能の変更が行われます。

今日は、SP2 おけるTCIP/IP における機能変更点のひとつが、今週公開されました公開技術情報 969710 で説明しておりますのでご紹介いたします！

              文書番号：969710

              タイトル：How to enable the half-open TCP connections limit in Windows Vista with Service Pack 2 and in Windows Server 2008 with Service Pack 2

              URL： http://support.microsoft.com/kb/969710/en-us

TCP の接続において、コネクション確立中の状態や片側にて接続が終了しており。片側にのみ接続が残っている状態など、完全ではない TCPコネクションを ハーフオープン (Half-Open) の状態の接続といいます。

Windows server 2008 SP1 および Windows Vista SP1 までは、Half-Open の接続を、最大 10 まで許可する設定になっておりました。

しかしながら、Windows Server 2008 SP2 および Windows Vista SP2　からは、既定で、Half-Open のTCP接続の最大上限数を設けないように変更されました。

従来どおり、Half-Open の接続上限数を、最大 10 に設定するためには、下記のレジストリ値を 1 に設定します。

- レジストリ

キー： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableConnectionRateLimiting

値： １ (制限する)

- 参考

なお、Windows Server 2008 SP2 および Windows Vista　SP2 についての情報は、下記の Technet サイトに情報が集められております。

ぜひ併せてご確認くださいませ。

　タイトル：　Windows Server 2008 Service Pack 2 および Windows Vista Service Pack 2

URL： http://technet.microsoft.com/ja-jp/windows/dd262148.aspx

今週公開された公開技術情報リスト

さて、5/3– 5/9 に新たに公開されました Active Directory およびネットワークに関するサポート技術情報のリストをご紹介いたします。

運用などにご活用いただけると幸いです！