locked
ドメインサーバー移行後の不具合について RRS feed

  • 質問

  • こんにちは。いつもお世話になっております。

    昨年、ADMTでWindows2003サーバーから2008にATMTを使って移行しました。

    全てのPCの移行が終わり、旧ドメインがぶら下がったままになっているので、電源を落としました。

    すると、電源を落した後にあるPCがドメインログオンはできたものの、ファイルサーバーのアクセス権のあるフォルダが参照できないという現象が発生しました。ドメインサーバーを起動後したところ、参照できるようになりました。

    次に電源を切るのと同じことですが、旧ドメインサーバーのLANケーブルを抜いたら、再度参照できない状態になりましたが、認証ダイヤログが出てきたので、新ドメインのアカウントで認証したところ、参照できるようになりました。

    しばらくその状態で何も起こらなかったので、数日LANケーブルを抜いたままにしていたところ、今度は、ドメインにログオンできないアカウントが出てきました。ログを見ると、下記のようなメッセージが並んでいました。

    NETLOGON[ID:5722]  コンピューター **** からのセッション設定を認証できませんでした。セキュリティ データベースで参照されたアカウント名は ****$ です。次のエラーが発生しました: アクセスが拒否されました。
    Microsoft-Windows-DfsSvc [ID:14550] DFS 名前空間サービスは、このドメイン コントローラーでフォレスト間の信頼情報を初期化できませんでした。操作は定期的に再試行されます。リターンコードはレコード データに格納されています。
    NETLOGON[ID:5719] 次の理由のため、このコンピューターはドメイン *****のドメイン コントローラーの セキュリティで保護されたセッションをセットアップできませんでした: 現在、ログオン要求を処理できるログオン サーバーはありません。これにより、認証の問題が発生する可能性があります。このコン ピューターがネットワークに接続されていることを確認してください。 問題が解決されない場合は、ドメイン管理者に問い合わせてください。

    仕方なく、ドメインを抜けて、再度参加し直したところ、元通りログオンして通常に使える状態になりました。

    ログオンキャッシュの情報が無くなるにつれ、そうしたPCが日々何台か出てきて、一斉にドメイン入り直しという作業が起こることを危惧しています。

    お作法ですと、旧ドメインに対しては、DCPROMO.EXE でドメインコントローラの降格を行い、ドメインから離脱、という手順で切り離すとのことですが、何台こうした状況が発生するのか、何が原因なのかよく判らないので、その後の措置を躊躇っています。

    どの端末でそうした状態になるのかが判れば、計画的にドメインの入り直し作業を行うことが出来ると思うのですが、各アカウントの認証先が判るような情報はサーバー上に存在するのでしょうか?



    • 編集済み hatsujiro 2016年3月17日 23:57
    2016年3月17日 6:57

すべての返信

  • チャブーンです。

    この件ですが、ADMTで「コンピュータの移行」を行う際、ウィザードの中で「セキュリティの変換」を行っていないから、ではないでしょうか?

    移行時には新旧のSID情報が必要ですのでこの設定を行わないのですが、旧ドメイン情報を切り離す前までには、各コンピュータ上で必ず実施する必要があります。追加置換モードによる「セキュリティの変換」ウィザードを各クライアントコンピュータオブジェクトに実施し、旧ドメイン情報をクリアにしてください。

    なお、クライアントコンピュータへの実施に際には、ユーザプロファイルを含む全内容を変換する必要があります。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。


    2016年3月22日 3:00
  • チャブーン様

    コメント有難うございました。

    >この件ですが、ADMTで「コンピュータの移行」を行う際、ウィザードの中で「セキュリティの変換」を行っていないから、で
    >はないでしょうか?

    「セキュリティの変換」ウィザードは移行手順の一つとして実行しています。
    チェックリストで作業内容の一つとして実施していますので、おそらく間違い無く実施はされていると思います。

    ただし、追加モードではなく、置換モードで行っていますので、この辺りが何か影響を及ぼしているのかもしれません。

    このあとコンピュータの移行を行っており、大半のアカウントは特に異常が出ていません。 このセキュリティ変換ウィザードは再実行できるものなのでしょうか?
    • 編集済み hatsujiro 2016年3月22日 4:26
    2016年3月22日 4:25
  • チャブーンです。

    セキュリティの変換ウィザードは最終的には「置換モード」で行う必要があります(以前のSID情報を切り離すため)。その意味ではおっしゃる操作は正しいと思います。(書き違えていたようですみません)

    https://technet.microsoft.com/ja-jp/library/cc974439(v=ws.10).aspx

    上記の方法で、セキュリティの変換ウィザードを再実施できます。うえの資料は「追加モード」ですが、ここでは置換モードで実行する必要があること、「ユーザープロファイル」も含めたすべての項目が移行対象になる、という理解です。

    あと、メンバーサーバ(ファイルサーバ)の方も、セキュリティの変換ウィザードで必要なアクセス許可を置換する必要があります。

    https://technet.microsoft.com/ja-jp/library/cc974405(v=ws.10).aspx


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    • 回答の候補に設定 佐伯玲 2016年3月24日 2:34
    2016年3月23日 1:32
  • チャブーン様 コメント有難うございました。
    数日間同じ状態のまま様子を見ていますが、エラーの出方が少し変わってきてこのパターンに替りました。

    NETLOGON[ID:5719] 次の理由のため、このコンピューターはドメイン ***** のドメイン コントローラーの セキュリティで保護されたセッションをセットアップできませんでした: 現在、ログオン要求を処理できるログオン サーバーはありません。
    GroupPolicy[ID:1053]グループ ポリシーの処理に失敗しました。ユーザー名を解決できませんでした。次のいずれかまたは両方が原因である可能性があります:
    a) 現在のドメイン コントローラーでの名前解決エラー。 b) Active Directory のレプリケーションの潜在期間 (別のドメイン コントローラーに作成されたアカウントが現在のドメイン コントローラーにレプリケートされていない)。
    TermDD[ID:53]ターミナル サーバーのセキュリティ層で、プロトコル ストリームにエラーが検出され、クライアントが切断されました。 クライアント IP: ***.****.*.**。
    エラーを見る限り、ドメインの同期が取れていない、という問題に変わってきたように見えますが、これは、コマンドによりドメインを同期させたほうがよいのでしょうか?同期しようとするドメインが無ければ、エラーも出なくなる、というのは楽観的でしょうか。^^;
    しばらく様子をみて、変わらないようであれば、またLANケーブルを繋いで、AD機能をアンインストールして、ドメインから切り離すかどうか考えてみます。

    2016年3月24日 10:12
  • 横からすみません。気になったのですが移行後のクライアントの優先DNS設定はどうなっているのでしょうか?
    確かADMTでクライアント移行処理後も優先DNS設定は手動で新サーバー(W2008)に変えないといけなかったような記憶があるのですが・・・。無関係でしたら申し訳ないです。

    2016年3月25日 7:42
  • チャブーンです。

    カディスさん、素晴らしい情報ありがとうございます。

    カディスさんがおっしゃる通り、クライアント参照先DNSサーバ、の設定はADMTで移行後も変わらないはずですので(旧DNSサーバ)、そのままだと旧ドメインコントローラをシャットダウンすると、名前解決に問題が出て、ログオンができません。

    その意味だと、クライアントおよびメンバーサーバすべてについていえると思いますので、チェックが必要かと思います。

    旧ドメインコントローラをシャットダウンする前に、グループポリシー(スタートアップスクリプト)で参照先DNSサーバの設定を変えてしまえば、いろいろな意味でラクかと思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。



    2016年3月25日 13:31
  • カディス様コメント有難うございました。

    DNSの設定は移行時の作業チェックリストの中に入れており、作業をしている筈ではあります。ケーブルを抜いてからすでに1週間以上経過しているので、キャッシュも既に無効になっているので、この状態ですと、ドメインにログオンが出来ない状態になるのではないかと思います。そうした報告は挙がってはいないのですが、確認はしてみます。

    どうも有難うございました。

    2016年3月28日 2:46
  • チャブーン様コメント有難うございます。

    確かにスタートアップスクリプトで設定してしまえば、間違いはないですね。実装してみようと思います。

    エラーは相変わらず同じものが出続けています。

    2016年3月28日 2:49
  • チャブーンです。

    この件ですが、DNSクライアント設定修正を行っておられるということでしたら、あらためて確認させていただきたいことがあります。

    • 使っている「クライアントOS」はなんでしょうか?
    • NetLogonエラーメッセージをいただいていますが、このエラーは「ドメインコントローラ」から取得しましたか?それともほかのサーバorクライアントでしょうか?


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2016年3月28日 3:05
  • チャブーン様 コメント有難うございます。
    • 使っている「クライアントOS」はなんでしょうか?
    • NetLogonエラーメッセージをいただいていますが、このエラーは「ドメインコントローラ」から取得しましたか?それともほかのサーバorクライアントでしょうか?

    使用しているOSは、サーバー(ドメインコントローラ)がW2008R2 EnterPriseのクラウド環境、クライアントは全てWindows7を使用しています。
    また、これらのエラーメッセージは、DC上のイベントビューア-システムログから拾ったものです。クライアントのほうは、特にメッセージは出ておらず、このところ、アクセス権のあるフォルダにアクセスできないというトラブルも発生していません。
    2016年3月29日 23:46
  • ETLOGON[ID:5719] 次の理由のため、このコンピューターはドメイン ***** のドメイン コントローラーの セキュリティで保護されたセッションをセットアップできませんでした: 現在、ログオン要求を処理できるログオン サーバーはありません。

    この部分だけ・・・・

    以下のコマンドを実行して同じエラーが出なければ無視できるかと思います。

    nltest /dsgetdc:%userdnsdomain%

    確認済みでしたら済みません。

    2016年3月30日 0:24
  • チャブーンです。

    移行後のシステムの環境ですが、

    使用しているOSは、サーバー(ドメインコントローラ)がW2008R2 EnterPriseのクラウド環境、クライアントは全てWindows7を使用しています。

    ドメインコントローラはクラウド上にあり、クライアントはオンプレミス(ローカルネットワーク)にあるということなのでしょうか?

    ドメインコントローラがクラウド環境にある場合、クラウドネットワーク=ローカルネットワーク間はVPNで接続されていなければならないはずです。どちらのクラウドかは存じませんが、AzureならAzure VPNでネットワーク間VPNが構成されることになります。

    Azure VPNの場合、MTUの問題で必要な通信がうまくできないことがあるので、MTU設定を変更する必要があります。詳細については、したの情報を参考にしてください。

    https://support.microsoft.com/ja-jp/kb/2902923


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2016年3月31日 2:34
  • uham様 コメント有難うございます。

    このコマンドは知りませんでしたので、現在のまま(ケーブルを抜いた状態)で、

    >nltest /dsgetdc:%userdnsdomain%

    を実行してみました。当然ですが、新ドメインの情報に繋がっている旨の情報が出ますが、コマンドに対するエラーも出ませんし、シスログ上でのエラーも出ません。

    このコマンドの使い方が良く判っていないのですが、コマンドを入力したPCがどのドメインに属しているかを参照している?とすれば、どのPCかが特定できないので、全てのPCでこれを実行(ログインスクリプト等で)することが必要、ということでしょうか?

    逆に質問になってしまい済みません。


    • 編集済み hatsujiro 2016年4月1日 6:11
    2016年4月1日 6:09
  • チャブーン様 コメント有難うございます。

    新ドメインコントローラはクラウド上、移行前の旧ドメインコントローラはオンプレです。

    旧ドメインコントローラのケーブルを抜いて、全てのクライアント(オンプレ)を新ドメインに移行した状態でも、何処からか、旧ドメインへのログオン要求が出ている、というエラーになります。

    使用クラウドはAzureではなく、ネットプロバイダの提供するクラウドです。その業者の提供する網内にある共用サーバーを使用しています。

    移行もその業者のサポートを受けているので、おそらくMTUの問題はクリアはしているとは思うのですが、これについての言及はありませんでした。念のため、確認してみます。

    情報有難うございました。

    2016年4月1日 6:17
  • お世話になります。上記の続きです。

    状況が変わりませんので、ちょっと乱暴かもしれませんが、旧ドメインの2台(プライマリ・セカンダリ)からドメインコントローラを削除しました。
    dcpromoを実行した後にワークグループサーバーにしましたが、特にエラーは発生することもなく終了しました。
    これで跡形もなく解決かと思ったのですが、1日に1~2回、

    次の理由のため、このコンピューターはドメイン ***** のドメイン コントローラーの セキュリティで保護されたセッションをセットアップできませんでした:
    現在、ログオン要求を処理できるログオン サーバーはありません。
    これにより、認証の問題が発生する可能性があります。このコン ピューターがネットワークに接続されていることを確認してください。 問題が解決されない場合は、ドメイン管理者に問い合わせてください。 
    のメッセージが出ています。*****の部分は、旧ドメイン名なのですが、何処が出しているのかの情報も出ていません。

    セキュリティログと照らしわせてみると、「Kerberos認証チケット(TGT )が要求されました。」というログと全てタイムスタンプが合致しています。

    https://msdn.microsoft.com/ja-jp/library/cc787646%28v=ws.10%29.aspx などを見ると、信頼関係の認証の仕組みのようなことが書いてあったので、新ドメインサーバーで「ActiveDirectoryと信頼関係」にある新ドメインのプロパティを見ると、旧ドメインの記述が残っています。これは手動で削除しなければいけないものなのでしょうか?

    2016年4月14日 1:19
  • チャブーンです。

    このNetLogonエラーの件ですが、状況から信頼先のドメインコントローラに対して、自分自身がセッション確認をしている可能性がありますね。

    信頼関係にある(他ドメインの)ドメインコントローラを削除した場合ですが、自分自身の「信頼関係を設定したオブジェクト(TDOといいます)」は、そのまま残ります。したがって[Active Directoryドメインと信頼関係]から、対象の信頼を削除する必要があります。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2016年4月15日 4:53
  • チャブーン様 いつもお世話になっております。

    コメント有難うございました。

    信頼関係を削除したところ、エラーは出なくなりました。

    数日は何もエラーが出なくなり、やれやれと思っていたのですが、週末をはさんで、今度は、エラーコード14550で、

    DFS 名前空間サービスは、このドメイン コントローラーでフォレスト間の信頼情報を初期化できませんでした。操作は定期的に再試行されます。リターン コードはレコード データに格納されています。

    のエラーが出るようになりました。サポートサイトを検索したところ、DFSサービスを再起動とのことが書かれてありましたので、それを実行したところ、今のところ出ていません。これでやっとドメインの移行が終わったかとほっとしています。

    幾度もメッセージを頂きまして感謝致します。どうも有難うございました。

    2016年4月18日 8:20