DFS名前空間にアクセスするときの長い一時停止

最近、共有ファイルにDFSを使用するようにWindowsネットワークを移行しました。迷惑な問題を除いて、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を使用して指定されます。すべてのコンピューターは、Service Packとパッチが適用された最新の状態です。

実際のフォルダーターゲット（つまり、DFSフォルダーが指すSMB共有）は複数のファイルサーバーとアプリケーションサーバーに散在し、すべてWindows 2008 R2を実行し、Windows 2003 R2を実行する2つのアプリケーションサーバー（レプリケーションセットアップなし） 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よりもWindows XP / 2003の方が少し悪いかもしれませんが、私は「違いが心理的なものだけではないかどうかはわかりません。

基になるフォルダーターゲットに直接アクセスしても、遅延はまったくありません。つまり、DFSが指すSMB共有が（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ドメイン名です）。数秒後、DOMAINのLLMNRルックアップをブロードキャストします。これに続いて、DOMAINの別のブロードキャストNetBiosルックアップが続きます。これらの3つのルックアップがブロードキャストされた（そしてタイムアウトしたと仮定します）後、DCは最終的にDFSルートサーバーへの（正しい）紹介でクライアントに応答します。

DOMAINのこれらのブロードキャスト名のルックアップは、DFS共有を開くための長い遅延が発生した場合にのみ送信されていました。 〜7秒経過しました）。そのため、これらのブロードキャスト名のルックアップは明らかに遅延の原因でした。

問題が何であるかがわかったので、これらのブロードキャスト名の検索が発生した理由を解明しようとしました。もう少しグーグルといくつかの試行錯誤の後、答えが見つかりました：DNSのみの環境でDFSを使用するときに必要なように、ドメインコントローラーのDfsDnsConfigレジストリキーを1に設定していませんでした。

我々もともとセットアップDFS私たちの環境には、私たちはいつでした DNSのみの環境のためにDFSを構成する方法について、様々な物品（例えば読みマイクロソフトKB244380など）をして、このレジストリキーを知っていたが、とき/どのように上の指示をmisintepretedていましたこれを使って。

KB244380より：

すべてのコンピューターが完全修飾名を理解するには、DFS名前空間に参加する各サーバーにDFSDnsConfigレジストリキーを追加する必要があります。

これは、レジストリキーがドメインコントローラーでも必要であることを認識せずに、DFS 名前空間サーバーでのみ設定する必要があることを意味すると考えました。ドメインコントローラーでDfsDnsConfigを1に設定（および「DFS Namespace」サービスを再起動）すると、問題は解消されました。

明らかにこの結果に満足していますが、これが唯一の問題であると私はまだ100％確信していないことを付け加えます-DfsDnsConfig = 1をDCに追加しても問題を解決するのではなく、問題を回避するだけかどうか。非DNSのみの環境であっても、DFSの紹介プロセス中にDCがドメイン（ドメイン内のサーバーではなく、ドメイン名自体）を検索しようとする理由がわかりません。他の（明らかにはるかに小さい/単純な）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サーバーに与えられます。DNSサーバーに、応答するIPアドレスを識別するために使用するサブネットマスクを指定する必要があります。

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がなくても物事が常に期待どおりまたは高速に動作しないため、これにはかなり反対です関係ありません。

クライアントは、DFS紹介をキャッシュします。つまり、\ domain.name \ namespaceを入力すると、実際のサーバーdomain.nameが参照するものがキャッシュされます。紹介がキャッシュから期限切れになると、クライアントは基本的にDFSトポロジを最初から「発見」する必要があるため、遅延が発生します。

こちらをご覧ください：http : //technet.microsoft.com/en-us/library/cc758234(WS.10).aspxおよびこちらhttp://blogs.technet.com/filecab/archive/2006/01/20この仕組みの詳細については、/ 417832.aspx。

可能な解決策？それをハックする方法は、数分ごとに「キープアライブ」を実行する小さなプログラムを作成することです。たとえば、最初に見つかったファイルをfopenし、すぐにfcloseするCプログラム。私はこれを試したりテストしたりしていません。もしそれをやろうとするなら、慎重に検討する必要があります。

ユーザーには、DFS共有にマップされたドライブをクリックしてから、共有内のフォルダーを表示および参照できるまでの遅延（最大1分）が発生するという同様の問題がありました。

ユーザーは、同じボリューム上の異なるDFS共有にマップされたホームドライブも持ち、そこにあるフォルダーにアクセスするときに遅延はありませんでした。

2つの違いはアクセスベースの列挙（ABE）です-問題の共有はこれを有効にします（数千のフォルダーを持つユーザーの一般的なドライブです-ABEは、ユーザーがアクセス許可を持つフォルダーのみを表示することを意味します）。

ABEを無効にすると、問題は完全に解消されました。ユーザーがすべてのフォルダーを見ると混乱するため、これは明らかに解決策ではありません。一時的な手段としてスペアディスクを使用してDFS共有をサーバーにレプリケートしましたが、この新しいターゲットでABEが有効になっていても、遅延はなくなりました。

問題のあるサーバーは2k3R2であり、稼働時間は150日（！）を超えているため、再起動され、問題のあるボリュームでCHKDSKが実行されます。これにより問題が発生した場合は、ここに投稿します。新しいターゲットは2k8サーバー上にあります。

dfsutil / spcflushとdfsutil / pktflushは、マルチサイトネットワークでも解決策になる可能性があります。ホームサイトのDFSリンクがキャッシュからではなくローカルサーバーから来ていることを確認してください。

元のポスターがWINSを使用していないことは知っていますが、非常によく似た問題を解決するためにこの投稿を最も多く使用したため、他の人のために投稿しています。私たちにとっては、ドメインと同じ名前でワークステーションに名前を付けることに決めた人になってしまいました。そのため、DCは、DFS紹介のドメイン名でルックアップを行うたびに、そのワークステーションに解決しようとしていたため、かなりの数10秒の遅延が発生しました。DCを指す静的な20エントリがWINSに配置され、これにより問題が解決しました。WINSがない場合、DCを指すLMHOSTSファイルにマシン名としてドメイン名を配置して20のルックアップを取得し、優先順位を設定して、LMHOSTSがNetBIOS名を解決するための最初の場所になるように設定できます。

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx このページでは、ドメインコントローラーとDFSNの両方が実際に言及されています（それが役立つ場合）。

DFSドメインコントローラーとルートサーバーのレジストリエントリ

次のレジストリエントリは下にあります

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

ルートサーバーおよびドメインコントローラー上。すべてのエントリはREG_DWORDです。

そこで、この記事を検索に使用しました。すべてをセットアップしても、まだ問題がありました。数日かけて問題を調査し、「Microsoft」をすべて除外した後、ネットワーク関連であると推測しました。当社判明WANアクセラレータが問題でした。ネットワーク担当者にドメインコントローラーのアクセラレーションをオフにしてもらい、すべてが良くなりました。

コントローラーがたくさんあったので、スクリプト（dnsdfs.cmd servername）もそうでした：

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs

20台のDFSサーバーがありますが、すべてのサーバーが同じ施設にあるかどうかについては言及していません。

これらのサーバーが同じ施設になく、他のサイトがそれぞれ独自のドメインを持っている場合、クライアントフェールバックが有効になっていることを確認することができます。

Google検索でここにたどり着き、同じ問題を抱えている人のために...

最初に、ネームスペース内のすべてのリンクが使用可能で正常であることを確認します。それは私の場合に起こったことで、まだネームスペースにダウンしているサーバーへのリンクがあったので、DNSを開くときの長い休止は、そのサーバーを検索して失敗したためでした。DFSでそのリンクを無効にすると、長い一時停止はなくなりました。

Authenticated Usersグループに、マップされているルートディレクトリの内容をリストするアクセス権があることを確認します。たとえば、x：ドライブが\ domain.local \ departents \ Marketingにマップされている場合、ユーザーは\ domain.local \ departmentsのリストアクセス許可が必要になります。2008/2012では、アクセス許可を継承する可能性のあるサブフォルダーの内容を一覧表示できないように、[このフォルダーのみ]に適用される高度なアクセス許可の下で指定できます。