Windowsマシンが共有名をどのように解決しているかをどのように把握しますか？
ドメインをあるフォレストから別のフォレストに移行する際に、いくつかの奇妙な問題が発生しています。古いドメインのドメインコントローラーをオフにしようとしましたが、突然、別のドメインで、それ自体のフォレストでアクセスしていた共有が消えました。
Windowsクライアントが共有を解決する方法を理解するのに問題があります。つまり、\ XXXXXX\yyy\zzzzと入力すると、接続するサーバーを特定するためにWindowsは正確に何をしますか？以前は古いドメインにもDFS共有を持っていたので、それが役割を果たしていることに注意してください。
Windowsが何をしているかを追跡するのに役立つツールはありますか？つまり、パス\ XXXXXX\yyy\zzzzを指定すると、このようなログが記録されます。ローカルNETBIOSで名前を確認しています。 NetBIOSで名前が見つかりませんでした。 DFSキャッシュを確認しています...\XXXXX\yyy\zzzzに\ computer.domain.com\shareを使用して、DFSキャッシュで見つかりました
これが全体の話です。あるドメインD1.xxxx.comから別のフォレストのD2.yyyy.comに移行しています。クロスドメインの信頼があり、DFSを除くすべてが移動されました。私たちが抱えていたすべての頭痛の種のために、ドメイン2でのDFSの使用をやめることにしました。代わりに、DFS全体にサービスを提供するD1と呼ばれるD2のホストがあります。セットアップして、すべてのファイルをコピーしました。次に、D1のすべてのドメインコントローラーをオフにして、信頼を削除します。これで、\ D1\root\thingsと入力すると、D2ドメイン上のマシンがD1.yyyy.comのrootと呼ばれる共有に移動することが期待されます。どういうわけかそうはならないようで、その理由がわかりません。クライアントマシンでdfsutil/pkflushを使用しようとしましたが、それでも問題はありません。
私が今やりたいのは、\ D1\root\thingsに接続しようとしたときにクライアントマシンが何をしているかを正確に確認することです。ネットワーク上で何が起こっているかを確認しても役に立ちません。私はそれがまだ古いDFS共有に行こうとしていることを知っています（またはかなり確信しています）。
あなたが尋ねるべき質問は、WindowsがコンピュータまたはDFSの名前をどのように解決するかです。
例を見てください
サーバー名=サーバー
ドメイン名= dom.local
サーバーのFQDN = server.dom.local
あなたのPCのDNSサフィックス= dom.local
共有パスには2つの部分があります。サーバーまたはホスト名「\ servername」と共有自体「share1」最初に、例としてpingを使用して、Windowsが名前をIPに解決したときに何が起こるかを見てみましょう。
あなたが実行します ping serverIPを取得します。この時点で、PCはTCP/IP構成を確認し、DNSサーバーのIPを取得します。次に、このDNSサーバーにクエリを実行して名前を解決します...またはWINS（以下で説明）を使用する場合があります。
多くの人が「そうそう、DNSサーバーにクエリを実行するのは簡単だと思っています。それは明らかだとわかっていました」。そうではありません！それは常にDNSサーバーに問い合わせるわけではなく、これは人々が混乱する場所です。これが実際に起こることです：
あなたのPCは常に最初にこの名前をDNS名に解決しようとします。これに失敗すると、WINSサーバー（ローカルPCがサーバーで構成されている場合）を照会しようとします。これが失敗すると、NetBIOSブロードキャストが実行されます。常にこの順序になります。
ここで、上記のDNSサフィックスに注意してください。それがdom.local以外の場合、このpingは失敗します。これは、pingを実行したときに、server.dom.localのFQDNを入力せず、代わりに「server」だけを使用したためです。 Windowsがバックグラウンドで実行するのは、DNSサフィックスを追加することです（これが目的です）。したがって、ping serverと入力すると、実際にはウィンドウに「pingserver.dom.local」と表示されます。これがFQDNであることに注意してください。うまくいけば、DNSクエリで私がここに行くところを見ることができます。 2つの別個のドメインがあるため、DNSサフィックスは異なる場合があります。たとえば、サーバーにpingを実行したときにdnsサフィックスがdom2.localだった場合、そのサフィックスが追加され、pingserver.dom2.localにTRYが追加されます。繰り返しますが、混乱は実際には画面に表示されないため（失敗するため）、実際には表示されないのにserver.dom.localにクエリを実行していると思われます。これがDNS経由で失敗すると、WINS次にNetBIOSに移動します。他の方法で解決されると、実際に表示されるのは「pingサーバー」です。2つの微妙な違いに注意してください。クエリが機能する場合DNSでは、「ping server.dom.local」と表示され、失敗してWINSまたはNetBIOS）を使用して解決すると、代わりに「pingserver」と表示されます。これはテストして確認する必要があります。 DNSを介して名前を正しく解決しています。ほとんどの人は、名前をpingして応答を受け取り、名前を解決するためDNSが機能していると考えます。DNSが実際に失敗したことを意味しますが、FQDNを解決しなかったという事実に注意を払うことはありません。 2つのドメインが使用されている場合これはIS非常に重要であり、警戒していなければ、名前解決の観点から簡単に大混乱を引き起こす可能性があります。ほとんどの人は、ドメインが1つしかないため、これに気づいていません。 DNSサフィックスの目的を知る必要はありません。
この時点で、共有がどのIP上にあるかを知る必要があります。まったく同じことがDFSツリーにも当てはまります。 DFS名と戻ってきたIPにpingを実行すると、DFSルートがどこにあるかがわかります。今のところDFSのことは忘れてください。 PCに戻ります... DNSクエリがマシン名を解決する場合、それが共有の場所であり、単純で単純です。
クエリがDFS名前空間に対するものである場合は、サーバーを見つけてDFS管理コンソールをロードします。\dom.local\share1だったとしましょう。この例では、dom.localにpingを実行し、192.168.5.4に解決されていることを確認しました。これにRDPして、DFSマネージャーをロードし、「share1」をローカライズします。 DFSマネージャーは、ローカルサーバー上にあるか、別のサーバーにリダイレクトするかを通知します。そこから、実際のサーバーに到達するまでブレッドクラムをたどり、その後共有します。
今意味がありますか？
わかりました、あなたのmroeの追加の詳細に答えて...私はあなたが私の投稿を正しく読んで、何が起こっているのか疑っているとは思いません..ここに行きます。
上記のDNSドメインサフィックスと、ドメインを移管するときにそれらが非常に重要である理由について述べたことを覚えておいてください。共有に接続しようとしているこのPCに、古いドメインのdnsサフィックス（xxxx.com）がまだ付いているとします。 D1を入力またはpingすると、最後にこのDNSサフィックスが追加されます。したがって、実際に接続しているのはd1.xxxx.comです...これは、xxxx.comドメインを削除すると存在しなくなります。\d1\root\thingsだけでなく、\ d1 .yyyy.com\root\thingsに接続してみてください。これが機能するかどうか教えてください。続行できます
この特定の状況では、Wiresharkのようなものが役立つかもしれないと私は信じています。実際にはDNSクエリも表示されます。