none
スキーマ拡張後に、クライアント端末のログオン時間が遅くなる RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    富士ソフト　平田と申します。
    いつもお世話になっております。

    Windows 2003 R2 ActiveDirectoryについて1点確認させてください。

    Windows 2003 R2 SP2のActiveDirectory環境をWindows 2008 R2 ActiveDirectoryへローリングアップグレードする為、sysprep32を実行しスキーマの拡張を実施しました。
    スキーマ拡張後、スキーマ拡張前より端末のログオンが10秒程度遅いとの指摘を受けております。
    どのような点から原因の追究を行えばよいでしょうか？

    ログオン時間の確認は、スキーマ拡張前と拡張後に同一の端末で複数回確認しており、複数回とも10秒程度遅れております。

    スキーマ拡張以外の設定変更は行っておりません。

    何か原因調査のためのヒントがございましたら、ご教授いただけますと幸いです。
    よろしくお願いいたします。


    2013年8月5日 12:12
    |

回答

  • Question
    サインインして投票
    0
    サインインして投票

    まず、スキーマの拡張が原因でログオン時間が遅れるというのは考えづらいですね。

    基本的なログオンプロセスは

    1. クライアントがDNSに問い合わせてSRVレコードからDCの情報を取得する
    2. クライアントがDCにアクセスする
    3. DCはGCにクエリしユニバーサルメンバーシップ情報を取得する
    4. DCが肯定応答を出してログオンが完了する

    このプロセスでどこがネックになっているのかを調査するのがいいのではないでしょうか？

    一番あやしいのは3番あたりかなとおもいます。

    以上、参考になれば幸いです。

    MVP:Virtual Machine Blog:MCTの憂鬱

    http://naonao71.wordpress.com/

    • 回答の候補に設定 佐伯玲 2013年8月8日 0:33
    • 回答としてマーク 平田 将司 2013年8月8日 9:08
    2013年8月6日 12:43
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    この話ですが、「原因のあたりをつけてピンポイントで攻める」というのは、今の段階では難しいと思います。ABEさんのコメントで暗示されていると思っていますが、スキーマの設定変更が問題を招来したのではなくて、既存で存在した問題が、「たまたま」このタイミングで具現化したような気がします。

    ですから、どの部分に問題があるのか、ネットワークトレースで実測してみるのが問題のあぶり出しに有効な気がします。Windowsのログオン時にどのようなパケットがやり取りされるのかについては、したの情報で把握いただけると思いますので、どこかのセクションで遅延していないか確かめられるかもしれません。また、「問題なくログオンできるクライアント」で取得したネットワークトレース情報と合わせ見ることで違いが分かるのではないでしょうか。

    http://technet.microsoft.com/ja-jp/library/bb742590.aspx

    2013年8月8日 4:01
    |
    モデレータ

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    まず、スキーマの拡張が原因でログオン時間が遅れるというのは考えづらいですね。

    基本的なログオンプロセスは

    1. クライアントがDNSに問い合わせてSRVレコードからDCの情報を取得する
    2. クライアントがDCにアクセスする
    3. DCはGCにクエリしユニバーサルメンバーシップ情報を取得する
    4. DCが肯定応答を出してログオンが完了する

    このプロセスでどこがネックになっているのかを調査するのがいいのではないでしょうか？

    一番あやしいのは3番あたりかなとおもいます。

    以上、参考になれば幸いです。

    MVP:Virtual Machine Blog:MCTの憂鬱

    http://naonao71.wordpress.com/

    • 回答の候補に設定 佐伯玲 2013年8月8日 0:33
    • 回答としてマーク 平田 将司 2013年8月8日 9:08
    2013年8月6日 12:43
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    ご回答をありがとうございます。

    やはり、スキーマ拡張が原因では考えづらいですよね。

    私としてもスキーマ拡張時の複製負荷やネットワーク的な負荷を想定しているのですが、根拠に乏しいので・・・。

    やはりログオンプロセスの調査を行う場合は、以下のサイトを参考にNet Logon サービスのデバッグ ログを有効にしてログを調査していくしかないのでしょうか？
    http://support.microsoft.com/kb/109626/ja

    2013年8月8日 1:05
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    この話ですが、「原因のあたりをつけてピンポイントで攻める」というのは、今の段階では難しいと思います。ABEさんのコメントで暗示されていると思っていますが、スキーマの設定変更が問題を招来したのではなくて、既存で存在した問題が、「たまたま」このタイミングで具現化したような気がします。

    ですから、どの部分に問題があるのか、ネットワークトレースで実測してみるのが問題のあぶり出しに有効な気がします。Windowsのログオン時にどのようなパケットがやり取りされるのかについては、したの情報で把握いただけると思いますので、どこかのセクションで遅延していないか確かめられるかもしれません。また、「問題なくログオンできるクライアント」で取得したネットワークトレース情報と合わせ見ることで違いが分かるのではないでしょうか。

    http://technet.microsoft.com/ja-jp/library/bb742590.aspx

    2013年8月8日 4:01
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    ご回答をありがとうございます。

    頂きました情報を基に、調査を進めていきたいと思います。

    ご対応をありがとうございました。

    2013年8月8日 9:09
    |