- - PR -
『コンピュータの設定を適用しています』に時間がかかる
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-01-12 22:48
こんばんわ.
ゴメンナサイ,自分にも「hosts ファイルで代替する」と BackDoor 様が書いていると判断しました. 逆に,BackDoor 様はどのような意図で書かれたのでしょうか?
ということは,つまり domain controller を探すのに 「hosts で代替させたら一時的に回避できる」という意図ではなかったのでしょうか? | ||||||||||||
|
投稿日時: 2007-01-13 09:41
こんにちは。
複数の方から同様の指摘を頂くということは、説明不足だったということですね。 相談者の環境では、クライアントPCにhostsの定義は無い、もしくは定義はあっても localhostのみだと想像しました。 今回の現象が名前解決の問題と判断しましたので、hostsにADサーバだけを追加 すれば現象の回避策になるのでは? と考えて提案させて頂いた次第です。 kaz様には釈迦に説法のようで恐縮ですが、前のコメント中の名前解決のフローで わかりますように、複数のアプローチが動作します。 私のところでは開発環境が複雑なのでクライアントPCに複数NICを実装していたり DNSに全てのnodeが登録されていなかったりしているので、こうした対応は通常に 行なっており、特に問題は発生しておりません。 根本解決とは別な意味で、私の考えている(実施している)方法に問題があるなら ご指摘頂きたいという意図でした。 | ||||||||||||
|
投稿日時: 2007-01-13 10:16
たしかに、「代替」という言葉は使っていらっしゃいませんし、 その言いかえが気に障ったなら謝罪します。 しかし、DNSよりも優先されるからhostsに書いておくという「逃げ」は通用しません。 繰り返しになりますが、SRV レコードを検索できないからです。 ダウンレベルクライアント95,98,MEはないようですので、板主さんの 環境ではDNSのみが唯一のドメインコントローラの検索手段です。 domain.local → IPアドレスが引けるだけではだめで、 グローバルカタログも検索できる必要があります。 これはhostsでは不可能です。
どのレベルで使用できるか出来ないかですが、ホスト名からIPアドレスを引く という意味ではAD環境でも「使用できます。」 ただし、ADドメインへのログオンには不十分です。 不十分といったのは Aレコードの代わりにhostsを使用し、 SRVレコードはDNSから検索させるという方法もありうるからです。 しかし、SRVレコードが検索できる→DNSが正常に動作している→Aレコードも検索できる はずなので、DNSよりも優先される検索先としてhostsを参照させて現象回避するという 手法もほとんど意味がありません。 問題のクライアントがドメインコントローラのAレコードの検索のみうまくいかない という状況がもしあり得るのだとすれば、それはそれで有効でしょうが、 はたして、そういった状況がありうるのか?
パケットロスが起きていても、リトライの結果、 一応正常に動作しているようにみえることがあります。 正常なクライアントを問題のクライアントが接続されている HUBに接続(ケーブルも問題のクライアントと同じもの)してみて正常に 動作しているなら、HUB ケーブル までは問題がないことがハッキリします。 あとは問題のクライアントのハードウェア(NICその他)及びソフトウェア (ドライバその他)にあるっぽいということで絞りこみができます。 労を惜しまず、検証してみることをお勧めします。 | ||||||||||||
|
投稿日時: 2007-01-13 11:40
みなさん、こんにちは。
いろいろ意見、提案、ありがとうございます。 とりあえず、現象発生待ちですので、発生後、根気良く調査します。 (来週いっぱい様子を見ます。) ただ、先日発生したクライアントも1回だけ発生してその後発生してないのもあるので不思議なところです。
そうですね。 上記を試してみます。 なお、当社ではhostsは、イントラネットサーバーへのアクセスの定義のみしており、ADドメインへのログオンとしては使用してません。 ただし、lmhostsの方には定義してます。 クライアントをADドメインに所属させるのに必要と思ったからですが、これっておかしいですかね? (当社は本社にのみドメインコントローラが存在し、支店のクライアントはWAN越しにログオンしてます。lmhostsにドメインコントローラを記述してないとADドメインに所属させることができませんでした。) 今回の『コンピュータの設定を適用しています』に時間がかかる現象は、LAN上、WAN上のクライアントに限らず発生しています。 | ||||||||||||
|
投稿日時: 2007-01-13 11:49
まるちねす様、返信ありがとうございます。
お恥ずかしい次第ですが、AD環境のDNSの検索に関して勘違いしておりました。 「DNSは直接IPアドレスで指定されているのでは無い」と思い込みがありました。 先ほど社内環境で検証してみましたが、固定IPアドレス方式でもDHCPサーバ利用 方式でもDNSのアドレスはIPアドレスで取得されました。 # 要するにhostsにADサーバを登録する行為自体に意味が無い・・・。 # 今回は「思い込み」の怖さを痛感しました。 # このスレッドをご覧の皆様にお騒がせしましたことお詫びします。 従って当初「名前解決の問題」と思っていた認識自体が誤りで、 「クライアントPC〜ADサーバ間のネットワークの問題」が真の問題だと 思われます。 James Ping様へ 私はネットワーク屋ですが、この現象(接続が不安定)は最も原因が特定し難い ケースだと思います。 # 類似したケースで最もひどい時はLANアナライザを常駐させ原因究明に2ヶ月 # 程度かかったケースもありました。 今回は現象が起こるPCの物理的なロケーションから障害箇所を絞り込むアプローチ が良さそうに思われます。 | ||||||||||||
|
投稿日時: 2007-01-13 15:58
lmhostsやwins あるいは ブロードキャストでドメインコントローラを発見するのは NTドメインの場合で Active Directory で kerberos を使う場合にはできません。 ただし、NTLM を使う場合はできる? でしたっけ。 (レガシークラアイトが混在した環境は経験がありませんのでどなたかフォローを。) すなわちNTドメイン的に AD ドメインに参加している場合。 クライアントが2000,XPのみならlmhosts wins hosts ブロードキャスト 一切 不要で、Netbios over TCP/IP (NBT)は無効にできるくらいです。 NBT は 過去との互換性のためにあり、レガシークライアントがない場合や、 どうしても NBT がなければならないアプリケーションがない限り使用する必要は ありません。 SMB Over TCP/IP を直接ホストする利点 http://support.microsoft.com/kb/315267/ja AD ドメイン = DNS 必須 でありますから、クライアントの 優先DNSサーバー 代替DNSサーバー にADドメインのサーバー(DCを含む)及びクライアントのレコードを含むDNSを 設定するだけでよいはずです。 もし、それでドメインに参加できないというなら、DNSをクエリするための ポートがフィルタされているとかではないでしょうか。 WAN越しとのことですが、IPSECトンネルを構築しているのでしょうか? 私の環境ではIPSECトンネルでつながれた二つのセグメント 192.168.0 と 192.168.7 があり、 192.168.0 のみに DC が存在し、192.168.7 のクライアントはWAN越しに DNSの動的更新 及び DNSのクエリ を行い AD ドメインに参加、ログオンできて います。 イントラネット内のDNS(AD統合ゾーンならDCが兼ねることが多い) のみをクライアントの参照先とし、インターネット上のFQDNを解決させるためには そのDNSにフォワーダを定義するのがお作法です。 名前解決手段を ある場合にはDNS あるばあいには lmhosts というように 使い分ける必要はないのではないでしょうか? >>クライアントをADドメインに所属させるのに必要と思ったからですが、 >>これっておかしいですかね おかしいか、どうかはともかく管理があきらかに煩雑になります。 | ||||||||||||
|
投稿日時: 2007-01-13 19:41
こんばんわ.
regacy な Active Directory の client がいる場合以外にも, application によっては NetBIOS 名の解決ができないと ちゃんと動いていくれないものもあるようです. ※どれかは忘れましたが,かなり以前にそのような事案がありました. なので,NetBIOS を無効にする場合は検証ありきだと思います. | ||||||||||||
|
投稿日時: 2007-01-13 19:50
まるちねすさん、こんばんは。
そうですね。 いまとなっては、lmhostsに記述は不要と自分も思います。 当社のADドメイン構築をした3、4年前は、自分で勉強して試行錯誤しながら作業しており、WAN越しのADドメイン所属がlmhostsの記述で解決したため、そのまま今日までlmhostsに記述してました。 (当時は、クライアントの 優先DNSサーバー 、代替DNSサーバー の設定をちゃんとしてなかったのかもしれません。今は全クライアントは、ちゃんと設定しています。)
たしかに管理が煩雑になるでしょうね。 当社の場合は、ドメインコントローラがたびたび変わるわけではないのでこのままでもいいかなと思ってます。 今回の現象は、BackDoorさんがおっしゃったように原因をつかむのに時間がかかる感じがします。とりあえず、現象発生したクライアントのグループポリシーの適用元を収集をしたいと思います。 ところで、ついでにお聞きしたいのですが、ドメインコントローラが複数あった場合、クライアントがどのような判断で見にいくドメインコントローラを決めているのでしょうか?(いろいろ調べたのですが、わかりませんでした。) 1台のクライアントで時間の同期元とコンピュータのポリシーの適用元とユーザーのポリシーの適用元が異なっているものがありました。 単純にその都度、負荷がかかっていないドメインコントローラを自動的に見にいっているんですかね?・・・ [ メッセージ編集済み 編集者: James Ping 編集日時 2007-01-13 21:33 ] |