パスワードと証明書の信頼認証のみをサポートしているためです。以上のドメインコントローラーのみが、公開キーの信頼認証をサポートしています。以上のドメインコントローラーでも、パスワードと証明書の信頼認証を認証する方法が理解されています。これらのクライアントの認証の負荷はそのまま共有されます。すべての形式の認証を処理できるため、認証の負荷が大きくなり、簡単にオーバーロードされるようになります。以降にアップグレードすると、2つのドメインコントローラー間で公開キーの信頼認証が配布されます。パスワードおよび証明書信頼の認証の分散は変更されません。クライアントの数は変わりません。負荷が大きくなっていますが、負荷は適切に分散されています。アップグレードしたシナリオを見てみましょう。配分は変化していないことがわかります。作業の量が増加しています。認証に相当していました。公開キーの信頼できるドメインコントローラーあたりの100公開キー信頼認証のボリュームを表します。ままですが、パスワードと証明書の信頼認証のボリュームは、以前のドメインコントローラー間で縮小されています。ここでいくつかの結論が得られます。コントローラーをアップグレードすると、新しい認証の配分は変化しますが、古い認証の配分は変化しません。コントローラーをアップグレードしても、パスワードと証明書信頼の認証の配分には影響しません。コントローラーがパスワードと証明書信頼の認証に対応できるためです。コントローラーよりも認証の負荷が大きくなります。コントローラーでのパスワードと証明書信頼の認証の量は減少します。アップグレードしても、認証の配分には影響しません。認証の量が変化するだけです。意味することを説明しました。コントローラー間で均等には分散されません。要求読み込みのベースラインが必要です。カウンターを提供します。公開キー信頼にクライアントをアップグレードすることを予定しているサイトを選択します。認証トラフィックが最も多くなる時期を選択します。月曜日の午前中は、すべてのユーザーがいっせいにオフィスに戻ってくるため適しています。カウンターを有効にします。カウンターを収集します。時に従業員が出社するようにスケジュールされているとします。ログがデータをラップしていないことを確認します。認証の上昇トレンド、ピーク、下降トレンドを確認できます。注意すべての認証トラフィックをキャプチャします。(コンピューターやサービスは最初に電源を入れたときに認証されます。評価では、この認証を検討する必要があります)。要求の最大数を探します。サイトで要求が最大数になったときの中央値を確認します。これは、サイトの認証の量が最も多い時間を表します。コントローラーの認証の数を加算します。これで、ピーク時のサイトの合計認証数が得られました。コントローラー間での認証の配分を決定できます。分布をパーセンテージに変換するには、商を10で乗算します。なることを確認します。認証の配分を確認します。超えないことが理想的です。常に、予期しない事態のために一部の容量を予約することをお勧めします。操作を処理することです。コントローラーのアップグレード候補として識別します。展開の最初のフェーズを監視します。以降にアップグレードする前と後の認証のデルタをメモしておきます。クライアントの最初のフェーズに起因する認証を表します。次のようなステートメントを作成できる、環境のベースラインが提供されます。切り替えたクライアントの数と_x_は、アップグレードされたドメインコントローラーからの認証率の増加率に等しいものです。クライアント数を増やして、展開を適切にフェーズすることができます。それ以降のドメインコントローラーで配布された認証のボリュームが変更されることに注意してください。それ以降のドメインコントローラーが1つしかない場合、配布は行われません。ドメインコントローラーが責任を持つ認証の量を増やしているだけです。ドメインコントローラーの数を増やすと、認証量は増加しますが、変更されません。したがって、ドメインコントローラーをさらに追加すると、各ドメインコントローラーが責任を持つ認証の負担が減少します。