ディレクトリ サービス コンポーネントの更新
適用対象: Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012
作成者: Justin Turner、Windows グループ、シニア サポート エスカレーション エンジニア、
Note
この内容は Microsoft カスタマー サポート エンジニアによって作成され、TechNet が通常提供しているトピックよりも詳細な Windows Server 2012 R2 の機能やソリューションの技術的説明を求めている、経験豊かな管理者とシステム設計者を対象としています。 ただし、TechNet と同様の編集過程は実施されていないため、言語によっては通常より洗練されていない文章が見られる場合があります。
このレッスンでは Windows Server 2012 R2 のディレクトリ サービス コンポーネントの更新について説明します。
ここでは、次の内容について学習します
次の新しいディレクトリ サービス コンポーネントの更新について説明します。
次の新しいディレクトリ サービス コンポーネントの更新について説明します。
ドメインとフォレストの機能レベル
概要
このセクションでは、ドメインとフォレストの機能レベルの変更について簡単に説明します。
新しい DFL と FFL
このリリースでは、新しいドメインとフォレストの機能レベルがあります。
フォレストの機能レベル: Windows Server 2012 R2
ドメインの機能レベル: Windows Server 2012 R2
Windows Server 2012 R2 ドメインの機能レベルでは、次のサポートが有効になります。
保護されたユーザーに対する DC 側の保護
Windows Server 2012 R2 ドメインに対して認証する保護されたユーザーは、次の操作ができなくなります。
NTLM 認証で認証を行う
Kerberos の事前認証で DES または RC4 の暗号スイートを使用する
制約なしの委任または制約付き委任を使用して委任される
最初の 4 時間の有効期間を超えてユーザー チケット (TGT) を更新する
Authentication Policies
新しいフォレスト ベースの Active Directory ポリシーです。Windows Server 2012 R2 ドメインのアカウントに適用して、アカウントがサインオンできるホストを制御したり、アカウントとして実行されているサービスに認証のアクセス制御条件を適用したりすることができます。
Authentication Policy Silos
新しいフォレストベースの Active Directory オブジェクトです。ユーザー、マネージド サービス、およびコンピューター アカウント間のリレーションシップを作成して、認証ポリシーまたは認証の分離用のアカウントを分類するために使用できます。
詳細については、「保護されるアカウントの構成方法」を参照してください。
上記の機能に加えて、Windows Server 2012 R2 ドメインの機能レベルにより、ドメイン内のすべてのドメイン コントローラーで Windows Server 2012 R2 を実行できるようになります。 Windows Server 2012 R2 フォレストの機能レベルに新機能はありませんが、フォレストで新しく作成されるドメインは Windows Server 2012 R2 ドメイン機能レベルで自動的に動作することが保証されます。
新しいドメインの作成に適用される最小の DFL
新しいドメインの作成でサポートされる最小限の機能レベルは Windows Server 2008 DFL です。
注意
FRS の廃止は、サーバー マネージャーまたは Windows PowerShell を介して Windows Server 2008 より低いドメイン機能レベルで新しいドメインをインストールする機能を削除することで実現されます。
フォレストとドメインの機能レベルを下げる
フォレストとドメインの機能レベルは、新しいドメインと新しいフォレストの作成時に既定で Windows Server 2012 R2 に設定されますが、Windows PowerShell を使用して下げることができます。
Windows PowerShell を使用してフォレストの機能レベルを上げたり下げたりするには、Set-ADForestMode コマンドレットを使用します。
contoso.com FFL を Windows Server 2008 モードに設定するには:
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
Windows PowerShell を使用してドメインの機能レベルを上げたり下げたりするには、Set-ADDomainMode コマンドレットを使用します。
contoso.com DFL を Windows Server 2008 モードに設定するには:
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
2003 DFL を実行している既存のドメインへの追加のレプリカとして Windows Server 2012 R2 を実行している DC の昇格が機能します。
既存フォレストでの新しいドメインの作成
Adprep
このリリースでは、新しいフォレストまたはドメインの操作はありません。
これらの .ldf ファイルには、デバイス登録サービスのスキーマ変更が含まれています。
Sch59
Sch61
Sch62
Sch63
Sch64
Sch65
Sch67
ワーク フォルダー:
- Sch66
MSODS:
- Sch60
認証のポリシーとサイロ
Sch68
Sch69
NTFRS の廃止
概要
FRS は Windows Server 2012 R2 で非推奨になりました。 FRS の廃止は、Windows Server 2008 の最小ドメイン機能レベル (DFL) を適用することで実現されます。 この適用は、サーバー マネージャーまたは Windows PowerShell を使用して新しいドメインが作成された場合にのみ存在します。
ドメインの機能レベルを指定するには、Install-ADDSForest または Install-ADDSDomain コマンドレットと共に -DomainMode パラメーターを使用します。 このパラメーターでサポートされる値は、有効な整数または対応する列挙文字列値のいずれかになります。 たとえば、ドメイン モード レベルを Windows Server 2008 R2 に設定するには、値 4 または "Win2008R2" のいずれかを指定できます。 これらのコマンドレットを Server 2012 R2 から実行する場合、有効な値には、Windows Server 2008 (3、Win2008)、Windows Server 2008 R2 (4、Win2008R2)、Windows Server 2012 (5、Win2012)、および Windows Server 2012 R2 (6、Win2012R2) が含まれます。 ドメインの機能レベルは、フォレストの機能レベルより低くすることはできませんが、それより高くすることはできます。 このリリースでは FRS が非推奨になるため、Windows Server 2012 R2 から実行した場合、Windows Server 2003 (2, Win2003) は、これらのコマンドレットのパラメーターとして認識されません。
LDAP クエリ オプティマイザーの変更点
概要
LDAP クエリ オプティマイザー アルゴリズムが再評価され、さらに最適化されました。 その結果、複雑なクエリの LDAP 検索効率および LDAP 検索時間のパフォーマンスが向上します。
注意
開発者から: LDAP クエリから ESE クエリへのマッピングの機能強化により、検索のパフォーマンスが向上しました。 一定レベルの複雑さを超える LDAP フィルターではインデックス選択が最適化されないため、パフォーマンスが大幅に低下します (1000 倍以上)。 この変更により、この問題を回避するために LDAP クエリのインデックスを選択する方法が変更されます。
注意
LDAP クエリ オプティマイザー アルゴリズムの全面的な見直しにより、次の結果が得られます。
- 検索時間の短縮
- 効率の向上により、DC はより多くのことを行うことができます
- AD パフォーマンスの問題に関するサポート呼び出しが少なくなる
- Windows Server 2008 R2 (KB 2862304) にバックポート
背景
Active Directory を検索する機能は、ドメインコント ローラーによって提供されるコア サービスです。 その他のサービスや基幹業務アプリケーションは、Active Directory 検索に依存しています。 この機能が使用できない場合、業務が停止する可能性があります。 コアで使用率の高いサービスとして、ドメイン コントローラーが LDAP 検索トラフィックを効率的に処理することが不可欠です。 LDAP クエリ オプティマイザー アルゴリズムは、データベース内で既にインデックスが作成されているレコードを使用して満たすことのできる結果セットに LDAP 検索フィルターをマッピングすることにより、LDAP 検索を可能な限り効率的にしようとします。 このアルゴリズムは再評価され、さらに最適化されました。 その結果、複雑なクエリの LDAP 検索効率および LDAP 検索時間のパフォーマンスが向上します。
変更の詳細
LDAP 検索には次のものが含まれます。
検索を開始する階層内の場所 (NC ヘッド、OU、オブジェクト)
検索フィルター
返される属性の一覧
検索プロセスを次に示します。
可能であれば、検索フィルターを簡略化します。
最小の対象セットを返すインデックス キーのセットを選択します。
インデックス キーの 1 つ以上の交差部分を実行して、対象セットを減らします。
対象セットのレコードごとにフィルター式とセキュリティを評価します。 フィルターが TRUE と評価され、アクセスが許可されている場合は、このレコードをクライアントに返します。
LDAP クエリの最適化作業では、手順 2 と 3 を変更して、対象セットのサイズを小さくします。 より具体的に言うと、現在の実装では、重複するインデックス キーが選択され、冗長な交差が実行されます。
古いアルゴリズムと新しいアルゴリズムの比較
この例にある非効率的な LDAP 検索のターゲットは、Windows Server 2012 ドメイン コントローラー です。 より効率的なインデックスが見つからなかったため、検索は約 44 秒で完了します。
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt
Using server: WINSRV-DC1.blue.contoso.com:389
<removed search results>
Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
DNT_index:516615:N
Pages Referenced : 4619650
Pages Read From Disk : 973
Pages Pre-read From Disk : 180898
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
新しいアルゴリズムを使用したサンプル結果
この例では、上記とまったく同じ検索を繰り返しますが、Windows Server 2012 R2 を対象としています。 LDAP クエリ オプティマイザー アルゴリズムの機能強化により、同じ検索が 1 秒未満で完了します。
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt
Using server: winblueDC1.blue.contoso.com:389
.<removed search results>
Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
idx_userPrincipalName:648:N
idx_postalCode:323:N
idx_cn:1:N
Pages Referenced : 15350
Pages Read From Disk : 176
Pages Pre-read From Disk : 2
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
ツリーを最適化できない場合:
例: ツリー内の式がインデックス付けされていない列の上にあった
最適化を妨げるインデックスの一覧を記録する
ETW トレースとイベント ID 1644 を介して公開
LDP で統計コントロールを有効にするには
LDP.exe を開き、ドメイン コントローラーに接続してバインドします。
[オプション] メニューの [コントロール] を選択します。
[コントロール] ダイアログ ボックスで、[定義済みの読み込み] プルダウン メニューを展開して [統計の検索] を選択してから、[OK] を選択します。
[参照] メニュー で [検索] を選択します。
[検索] ダイアログ ボックスで、[オプション] ボタンを選択します。
[検索オプション] ダイアログ ボックスで [拡張] チェック ボックスがオンになっていることを確認し、[OK] を選択します。
次を試す: LDP を使用してクエリ統計を返す
ドメイン コントローラーで、または AD FS ツールがインストールされているドメインに参加しているクライアントまたはサーバーから次の手順を実行します。 Windows Server 2012 DC と Windows Server 2012 R2 DC を対象に次の手順を繰り返します。
「より 効率的な Microsoft AD 対応アプリケーションの作成」の記事を確認し、必要に応じて参照してください。
LDP を使用して検索統計を有効にする (「LDP で統計コントロールを有効にするには」を参照)
いくつかの LDAP 検索を実行し、結果の上部にある統計情報を確認します。 他のアクティビティでも同じ検索を繰り返すので、メモ帳のテキスト ファイルに記録します。
属性インデックスのためにクエリ オプティマイザーが最適化できる LDAP 検索を実行します。
完了するまでに長い時間がかかる検索を作成してみます (検索がタイムアウトしないように、時間制限オプションを増やすことをお勧めします)。
その他のリソース
より効率的な Microsoft Active Directory 対応アプリケーションの作成
951581 LDAP クエリは、AD または LDS/ADAM ディレクトリ サービスで予想よりも実行速度が遅く、イベント ID 1644 がログに記録される場合があります
1644 イベントの改善
概要
この更新により、トラブルシューティングの目的で役立つ LDAP 検索結果の統計がイベント ID 1644 に追加されます。 また、時間ベースのしきい値でのログ記録を有効にするために使用できる新しいレジストリ値があります。 これらの機能強化は、KB 2800945 を介して Windows Server 2012 および Windows Server 2008 R2 SP1 で使用可能になり、Windows Server 2008 SP2 でも使用できます。
注意
- 非効率的またはコストのかかる LDAP 検索のトラブルシューティングを支援するために、追加の LDAP 検索統計がイベント ID 1644 に追加されます。
- 高コストで非効率的な検索結果のしきい値を指定する代わりに、検索時間のしきい値 (たとえば、100 ミリ秒を超える検索のログ イベント 1644) を指定できるようになりました
背景
Active Directory のパフォーマンスに関する問題のトラブルシューティング中に、LDAP 検索アクティビティが問題の原因になっている可能性があることが明らかになります。 ドメイン コントローラーによって処理される高コストまたは非効率的な LDAP クエリを確認できるように、ログを有効にすることにしました。 ログの記録を有効にするには、フィールド エンジニアリングの診断値を設定する必要があります。また、必要に応じて、高価で非効率的な検索結果のしきい値を指定できます。 フィールド エンジニアリングのログ レベル値を 5 に設定すると、これらの条件を満たす検索はすべて、イベント ID 1644 でディレクトリ サービス イベント ログに記録されます。
イベントには次のものが含まれます。
クライアント IP とポート
開始ノード
フィルター
検索範囲
属性選択
サーバー コントロール
アクセスされたエントリ
返されたエントリ
ただし、検索操作に費やされた時間や、使用されたインデックス (存在する場合) などの重要なデータはイベントにはありません。
イベント 1644 に追加された追加の検索統計情報
使用されるインデックス
参照されるページ
ディスクから読み取られたページ
ディスクから事前に読み込まれたページ
クリーン ページの変更
ダーティ ページの変更
検索時間
最適化を妨げている属性
イベント 1644 ログ記録の新しい時間ベースのしきい値レジストリ値
高コストで非効率的な検索結果のしきい値を指定する代わりに、検索時間のしきい値を指定できます。 50 ミリ秒以上かかったすべての検索結果をログに記録する場合は、(フィールド エンジニアリング値の設定に加えて) 小数点以下 50 桁 / 16 進数 32 を指定します。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032
新旧イベント ID 1644 の比較
OLD
NEW
次を試す: イベント ログを使用してクエリ統計を返す
Windows Server 2012 DC と Windows Server 2012 R2 DC を対象に次の手順を繰り返します。 各検索の後、両方の DC でイベント ID 1644 を確認します。
regedit を使用して、Windows Server 2012 R2 DC の時間ベースのしきい値と Windows Server 2012 DC の古いメソッドを使用して、イベント ID 1644 のログ記録を有効にします。
しきい値を超える LDAP 検索をいくつか実行し、結果の上部にある統計情報を確認します。 前に記録した LDAP クエリを使用して同じ検索を繰り返します。
1 つ以上の属性がインデックス付けされないため、クエリ オプティマイザーが最適化できない LDAP 検索を実行します。
Active Directory レプリケーション スループットの向上
概要
AD レプリケーションでは、レプリケーション トランスポートに RPC を使用します。 既定では、RPC は 8K 送信バッファーと 5K パケット サイズを使用します。 これは、送信インスタンスが 3 つのパケット (約 15K 相当のデータ) を送信し、ネットワーク ラウンド トリップを待機してから送信する必要があるという正味の効果があります。 ラウンドトリップ時間を 3ms とすると、最大スループットは 1 Gbps または 10 Gbps ネットワークでも約 40 Mbps になります。
注意
この更新により、AD レプリケーションの最大スループットが 40 Mbps から約 600 Mbps に調整されます。
- RPC 送信バッファー のサイズが増加し、ネットワーク ラウンド トリップの数が減少します
この影響は、高速で待機時間の長いネットワークで最も顕著になります。
この更新により、RPC 送信バッファー サイズが 8K から 256 KB に変更され、最大スループットが約 600 Mbps に増加します。 この変更により、TCP ウィンドウのサイズが 8K を超えて拡大し、ネットワーク ラウンド トリップの数が減ります。
注意
この動作を変更するための構成可能な設定はありません。