DFS名前空間にアクセスするときに長い一時停止
最近、共有ファイルにDFSを使用するようにWindowsネットワークを移行しました。 1つの厄介な問題を除いて、DFSは正常に機能しています。ユーザーがしばらくの間アクセスしていないDFS名前空間にアクセスしようとすると、大幅な遅延が発生します。私は問題のトラブルシューティングを試みましたが、今のところ成功していません。問題を解決するための指針がここにいる誰かに期待されました。
まず、ネットワークの背景：
ネットワークは、2つのWindows 2008 DCと2つのDNSサーバー（各DCに1つ）を持つWindows 2008機能レベルのActive Directoryドメインを使用します。ネットワークはDNSのみで、WINSはありません。すべてのコンピュータは同じサイトにあり、ギガビットイーサネットで接続されています。 Windows 2008モードには約20のドメインベースのDFS名前空間があり、各DFS名前空間には2つのWindows 2008 DFS名前空間サーバー（すべての名前空間に同じ2つのサーバー）があります。すべての名前空間サーバーはFQDNモードであり、すべてのフォルダーターゲットはFQDNを使用して指定されます。すべてのコンピューターは、サービスパックとパッチが適用された最新の状態です。
実際のフォルダーターゲット（つまり、SMBは、DFSフォルダーが指している共有））が複数のファイルサーバーとアプリケーションサーバーに分散しており、すべてWindows 2008 R2を実行し、Windows 2003 R2を実行する2つのアプリケーションサーバーをレプリケーションなしで実行しています。まったくセットアップします（たとえば、現在すべてのDFSフォルダーには1つのフォルダーターゲットしかありません）。
問題の詳細：
名前空間へのアクセスの遅延は通常1〜10秒で、特定のコンピューターが要求された名前空間に約5分以上アクセスしなかった場合に発生するようです。
たとえば、ユーザーが\\ domain.name\namespace1 \に5分以上アクセスせず、Windowsエクスプローラーを介して\\ domain.name\namespace1 \にアクセスしようとすると、エクスプローラーウィンドウは1〜10秒間フリーズし、最後に\\ domain.name\namespace1に存在するフォルダを再開して表示します。その後、エクスプローラーウィンドウを閉じて、5分以内に\\ domain.name\namespace1 \に再度アクセスしようとすると、コンテンツはほぼ瞬時に表示されます。5分より長く待機すると、再び1〜10秒の一時停止が発生します。
名前空間の「内部」に入ると、すべてが素晴らしくて元気がよくなりますが、遅いのは名前空間への最初の接続だけです。
ブラウジングの遅延は、使用しているWindowsのすべてのバリアントに影響するようです（Windows 2008 x64 SP2、Windows 2003 R2 x86 SP2、Windows XP Pro x86 SP3））-Windowsでは少し悪い可能性があります= XP/2003 Windows 2008よりもですが、違いが心理的なものだけではないのかどうかはわかりません。
基になるフォルダーターゲットに直接アクセスしても、遅延はまったくありません。つまり、SMB DFSが指す共有に直接アクセス（DFSをバイパス））した場合、一時停止はありません。
トラブルシューティング中に、すべてのDFSルートの「キャッシュ期間」が300秒〜5分に設定されていることに気付きました。これは一時停止をトリガーするのに必要な時間と同じであることを考えると、このキャッシュは何らかの形で関連していると思いますが、クライアントで何がキャッシュされているか、したがって5分が経過した後に何を再検索する必要があるかは正確にはわかりません。
問題を解決するために、私はすでに以下を試しました/チェックしました（成功なし）：
- 両方のドメインコントローラーでdcdiagを実行します-問題は見つかりませんでした
- 問題を発見せずにいくつかの基本的なDNSサーバーチェックを実行しました-DNSサーバーを詳細にチェックする方法はわかりませんが、ネットワークがDNS問題を示す可能性のある他の奇妙な動作を示していないことを付け加えます
- クライアントとサーバーでのウイルス対策の無効化
- いくつかの名前空間から名前空間サーバーの1つを削除-違いなし
だからこそ、私は次第です-そして私はアイデアがありません。誰かが遅延を引き起こしている可能性のあるもの、および/または次に何をすべきかを提案できますか？
さて、私たちはついに私たちの環境でこの問題を解決したようです。他の人たちの利益のために、ここに私たちが発見したものと問題をどのように修正したかを示します：
クライアントマシンでWiresharkを使用してネットワークトラフィックをキャプチャ/分析し、そのクライアントがDFS共有へのアクセスを試みている間に、遅延の前/最中/後に何が起こっていたかをさらに洞察するために試みました。
これらのキャプチャは、何か奇妙なことを示しました：クライアントからDCに送信されるDFS要求と、DCからクライアントに返されるDFSルートサーバーへの参照との間DCはいくつかのブロードキャスト名ルックアップをネットワークに送信していました。
まず、DCはDOMAINのNetBIOSルックアップをブロードキャストします（DOMAINはWindows 2000以前のActive Directoryドメイン名です）。数秒後、 [〜 ＃〜] llmnr [〜＃〜] DOMAINのルックアップ。これに続いて、DOMAINのさらに別のブロードキャストNetBiosルックアップが続きます。これらの3つのルックアップがブロードキャストされた後（そしてタイムアウトしたと想定）、DCは最終的にクライアントにDFSルートサーバーへの（正しい）リフェラルで応答します。
これらのDOMAINのブロードキャスト名検索は、DFS共有を開くのに長い遅延が発生したときにのみ送信されていました。Wiresharkのキャプチャから、DCがDFSへの紹介を返さなかったことが明確にわかりました。 3つのルックアップがすべて送信されるまで（そして約7秒が経過するまで）ルートサーバーなので、これらのブロードキャスト名ルックアップは明らかに明らかに遅延の原因でした。
問題がわかったので、これらのブロードキャスト名ルックアップが発生している理由を解明しようとし始めました。 DNSのみの環境でDFSを使用するときに必要なため、ドメインコントローラーのDfsDnsConfigレジストリキーを1に設定していませんでした。
環境でDFSを最初にセットアップするときに、didDNSのみの環境でDFSを構成する方法に関するさまざまな記事（例 Microsoft KB24438 およびその他）とこのレジストリキーを知っていましたが、いつ/どのように使用するかについての説明を誤って解釈していました。
KB244380さんのコメント：
すべてのコンピューターが完全修飾名を理解するには、DFS名前空間に参加する各サーバーにDFSDnsConfigレジストリキーを追加する必要があります。
これは、レジストリキーをDFS名前空間サーバーにのみ設定する必要があることを意味し、ドメインコントローラーにも必要であることを認識していなかったと考えました。ドメインコントローラーでDfsDnsConfigを1に設定（および "DFS名前空間"サービスを再起動）すると、問題はなくなりました。
当然、この結果には満足していますが、これが唯一の問題であると100％確信しているわけではありません。DfsDnsConfig= 1をDCに追加しても、問題を解決するのではなく、問題を回避できただけなのでしょうか。 。非DNSのみの環境でも、DFS紹介プロセス中にDCがDOMAIN（ドメイン内のサーバーではなくドメイン名自体）を検索しようとしている理由を理解できません。他の（確かにはるかに小さい/シンプルな）DNS専用環境のドメインコントローラーでDfsDnsConfig = 1を設定しておらず、同じ問題も発生していません。それでも、問題は解決したので満足しています。
これが同様の問題を経験している他の人に役立つことを願っています-そして途中で提案を提供してくれた人々に感謝します。
これは、DNSサーバーのネットマスクの順序が原因である可能性があります。最近、Server 2003でこれに遭遇しました。これは、現在のサブネットに依存します。
例。
サイト1：IPサブネット10.0.0.0/24サイト2：IPサブネット10.0.1.0/24
サイト2のクライアントはドメインベースの名前空間に対してDNSクエリを実行し、DNSサーバーはサイトのIP境界を認識しないため、デフォルトでサイト1のDFSサーバーが与えられます。応答するIPアドレスを識別するために使用するサブネットマスクをDNSサーバーに通知する必要があります。
http://support.Microsoft.com/kb/842197 を参照してください
Active Directoryチームのブログには、DFS遅延に関する3部構成の記事があります。
http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx
紹介プロセスの基本について説明し、dfsUtilやdfsDiagなどのさまざまなツールを使用して遅延の実際の原因を発見する方法を示します。
問題を見つけるのに役立ちました。ドメインユーザーの共有ディレクトリに対する読み取りアクセス許可がないことが判明しました。
HTH、ダニエル
DNSの問題のようなにおいがしますが、何でも起こります。 Ultrasoundのような診断ツールがとても便利だったので、私は古いFRSをずっと好みました：7
ターゲットのDFSレプリケーションイベントログに何かありますか？ （DFSヘルスレポートは、イベントログから警告を引き出します）
WINSなしで実行することは素晴らしい目標であり、立派ですが、Vista/2008より前のWindowsシステムがあると、期待どおりに動作しないか、速度が速くないため、これにかなり反対しますWINS私の経験ではありません-それは本当に重要ではありませんが。
そこで、この記事を検索に使用しました。私はすべてをセットアップしましたが、それでも問題がありました。問題を調査し、すべての「Microsoft」を除外して数日間費やした後、私はそれがネットワーク関連であったと推測しました。 WANアクセラレータが問題であることがわかりました。ネットワーキングの担当者にドメインコントローラーのアクセラレーションをオフにしてもらい、すべてが改善されました。
dfsutil/spcflushおよびdfsutil/pktflushは、マルチサイトネットワークでも解決策になる可能性があります。ホームサイトのDFSリンクがローカルサーバーからのものであり、キャッシュからのものではないことを確認してください。
DFS共有にマップされたドライブをクリックしてから、共有内のフォルダーを表示および参照できるようになるまでに、ユーザーに遅延（最大1分）が発生するという、同じようなサウンドの問題がありました。
ユーザーはまた、同じボリューム上の別のDFS共有にマップされたホームドライブを持ち、そこのフォルダーにアクセスするときに遅延はありませんでした。
2つの違いはAccess-Based Enumeration（ABE）です-問題の共有ではこれが有効になっています（これはユーザーにとって一般的なドライブであり、何千ものフォルダーがあります-ABEはユーザーがアクセス許可を持つフォルダーのみを表示することを意味します）。
ABEを無効にすると、問題が完全になくなりました。ユーザーがすべてのフォルダを表示して混乱するため、これは明らかに解決策ではありません。一時的な手段として、スペアディスクを備えたサーバーにDFS共有を複製しました。この新しいターゲットでABEを有効にしても、遅延がなくなりました。
問題のあるサーバーは2k3R2であり、稼働時間が150日を超える（！）ため、サーバーが再起動し、問題のあるボリュームでCHKDSKが実行されます。これが問題に何らかの影響を与える場合は、ここに投稿します。新しいターゲットは2k8サーバー上にあります。
多くのコントローラーがあったので、スクリプト（dnsdfs.cmd servername）：
dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs
クライアントはDFSリフェラルをキャッシュします。つまり、\ domain.name\namespaceを入力すると、実際のサーバーのdomain.nameが参照するキャッシュが作成されます。キャッシュからの参照が期限切れになると、クライアントは基本的にDFSトポロジを最初から「発見」する必要があるため、遅延が発生します。
こちらをご覧ください： http://technet.Microsoft.com/en-us/library/cc758234（WS.10）.aspx and here http：//blogs.technet。 com/filecab/archive/2006/01/20/417832.aspx これがどのように機能するかの詳細情報。
可能な解決策？それを行うためのハッキーな方法は、数分ごとに「キープアライブ」を実行する小さなプログラムを書くことかもしれません。例えばfopenが最初に見つけたファイルであり、すぐにfcloseであるCプログラム。私はこれを試したりテストしたりしていないので、それを行う場合は、慎重に検討する必要があります。
元の投稿者がWINSを使用していなかったことは知っていますが、非常に類似した問題を解決するためにこの投稿を最もよく使用したため、他の人のために投稿しています。私たちにとっては、ドメインと同じ名前でワークステーションに名前を付けることにしたのです。したがって、DCがDFS紹介のドメイン名を検索するたびに、そのワークステーションを解決する必要があり、数十秒の大幅な遅延を引き起こしていました。静的20エントリがWINSを指すDCに配置され、これで問題が解決しました。WINSがない場合は、ドメイン名をDCを指すLMHOSTSファイル内のマシン名。20のルックアップを取得し、優先順位を設定して、LMBIOSSがnetbios名を解決するために最初に調べる場所になるようにします。
http://technet.Microsoft.com/en-us/library/cc780950（v = ws.10）.aspx このページでは、ドメインコントローラとDFSNの両方について実際に触れています（参考にできる場合）。
DFSドメインコントローラとルートサーバーのレジストリエントリ
次のレジストリエントリは、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs
ルートサーバーとドメインコントローラー。すべてのエントリはREG_DWORDです。
20台のDFSサーバーがあるが、すべてのサーバーが同じ施設内にあるかどうかについては言及していません。
これらのサーバーが同じ施設内になく、他の各サイトに独自のドメインがある場合は、クライアントのフェールバックが有効になっていることを確認する必要があります。
グーグル検索でここに到達し、同じ問題を抱えている人のために...
まず、名前空間内のすべてのリンクが利用可能であり、適切であることを確認します。それが私の場合に起こったことであり、ネームスペースにはまだダウンしているサーバーへのリンクがありました。そのため、DNSを開くときの長い一時停止は、そのサーバーを検索して失敗したためです。 DFSでそのリンクを無効にすると、長い一時停止はなくなりました。