企業や組織でActive Directory Domain Services(AD DS)を運用していると、新しい機能を有効化するタイミングは慎重になるものです。特にDatabase 32k Pages Featureのように、一度切り替えると後戻りができない機能は、事前準備や手順の確認が欠かせません。本記事では、Database 32k Pages Featureの概要から有効化手順、そしてトラブル回避のためのポイントまでを詳しく解説します。システム管理者の方々が安心して作業に臨めるよう、具体的な事例やテスト方法、バックアップ戦略などを網羅的に紹介します。
Database 32k Pages Featureとは
AD DSのデータベース(以下、NTDS.DITファイル)は、MicrosoftのJETエンジンをベースとして動作しています。従来の既定のページサイズは8Kで、多くの環境で長年利用されてきました。しかし、組織の規模拡大やオブジェクト数増大に伴い、より高いパフォーマンスや大容量データへの対応が求められるケースが増えています。こうした要求に対応するため、MicrosoftはDatabase 32k Pages Feature(ページサイズ32K)を用意しています。
32Kページサイズのメリット
- 大容量オブジェクトをより効率的に扱える
- 大量の読み書きが発生する際にパフォーマンス向上が見込まれる
- 機能的には新しいバージョンのAD DS環境と親和性が高い
一方で、ページサイズの拡大に伴い、消費するリソース(メモリやストレージ)が増加する可能性があるため注意が必要です。
問題の概要：「ドメインコントローラー上のJETデータベースページサイズが一致しない」エラー
Windows Serverの最新版を導入し、フォレスト/ドメイン機能レベルを最新バージョン(2025想定)まで引き上げた後、下記のPowerShellコマンドを実行した際にエラーが発生するケースがあります。
Enable-ADOptionalFeature -Identity 'Database 32k pages feature' `
-Scope 'ForestOrConfigurationSet' -Target <フォレスト名>エラーの内容は「ドメインコントローラー(DC)上のJETデータベースページサイズがすべて一致していない」というもので、実際には各DCのページサイズが8Kに設定されていることが原因です。このエラーは、Database 32k Pages Featureを有効化するための前提条件を満たしていない(すべてのDCが32Kである必要がある)場合に発生します。
なぜ前提条件を満たさないとエラーになるのか
AD DSのデータベースは、複数のドメインコントローラー間でレプリケーションを行いながら、一貫したディレクトリ情報を保持しています。ページサイズの異なるデータベース同士は整合性を保ちにくいため、一部のドメインコントローラーだけを32Kページサイズにしてしまうと、レプリケーションエラーやデータ不整合が起こりかねません。これを未然に防ぐため、機能有効化の段階でページサイズの統一が求められるのです。
前提条件と注意点
Database 32k Pages Featureを適用する前に、以下のポイントをしっかり確認しましょう。
有効化が不可逆であること
32Kへの切り替えは一度行うと8Kには戻せません。これはAD DS内部のデータベース構造そのものを変更するためであり、従来の形式にはダウングレードできない仕様になっています。そのため、手軽に試すというよりは、十分な検証を経てから本番環境に反映することが大前提となります。
すべてのドメインコントローラーでページサイズを統一する必要
上記のエラー文にもある通り、DCごとにページサイズが異なる状態のままでは、有効化に失敗します。組織内に複数のドメインやサイトが存在し、多数のDCが分散している場合は、手順やスケジュール管理が大きな課題になります。古いサーバーをまとめてリプレースするタイミングなど、組織の都合に合った計画的な実施が望まれます。
バックアップと事前テストの重要性
8Kページサイズの環境から32Kページサイズの環境に移行する際、何かしらのトラブルが発生するリスクをゼロにするのは困難です。そこで「何があっても元に戻せる」ための対策として、DCのシステム状態バックアップやNTDS.DITのバックアップを取得しておきましょう。また、本番環境と同等のテスト環境を用意できる場合は、事前に手順をリハーサルすることでリスクを大幅に低減できます。
ページサイズの変更方法と推奨手順
AD DSのページサイズは、ドメインコントローラーを昇格したタイミング(AD DSをインストールしたタイミング)で決定されます。既存のAD DSを構成したままページサイズだけを切り替えることは難しく、大きく分けて以下の2つのアプローチが考えられます。
アプローチ1：既存のDCを降格し、再度昇格する
- 対象のDCを降格してAD DSをアンインストール
- 新しくAD DSをインストールする際、インストーラのオプションやレジストリ設定などにより32Kページサイズでセットアップ
- 再度ドメインコントローラーとして昇格してドメインに参加
この方法では、同じ物理サーバーや仮想マシンを再利用しつつページサイズを変更できますが、降格・昇格の作業中にサービス停止時間が発生します。また、FSMO(フレキシブル・シングル・マスタ・オペレーション)ロールを保持しているDCを降格する場合は、事前にほかのDCへロールを移動しておく手間がかかります。
アプローチ2：新しいDCを追加し、古いDCを退役する
- 新しいサーバー(または仮想マシン)を用意
- 初期セットアップ時に32KページサイズでAD DSをインストールし、ドメインに参加
- 必要に応じてFSMOロールなどを移行
- 既存の8KページサイズのDCを降格・退役
こちらは新規サーバーを追加投入する分のコストや機器の準備が必要ですが、古い環境を残しつつ段階的に切り替えることができるため、本番稼働への影響を最小限に抑えやすい利点があります。大規模環境や24時間365日止められないシステムでは、こちらの方法がより現実的なシナリオとなるケースが多いでしょう。
具体的な準備作業の流れ
ページサイズの統一に向けた具体的な準備や作業手順を、フェーズごとに整理してみましょう。
フェーズ1：情報収集と事前調査
- 既存のドメインコントローラーの台数、配置(サイト構成)、ハードウェアスペックをリストアップ
- 各DCが持つ役割(FSMOロールやグローバルカタログなど)を確認
- すべてのDCが8Kページサイズであることをコマンドやレジストリ、イベントログなどで再チェック
- 組織の運用方針やダウンタイムの許容度合いを把握
フェーズ2：テスト環境での検証
可能な限り本番環境と近い構成(台数、サイト数、ドメイン数など)を用意し、新たに32KページサイズでDCを構成した際の挙動やレプリケーションを確認します。テスト時には以下の点を重視してください。
- 新DC追加後のレプリケーション状況(Active Directory Sites and ServicesやRepadminコマンドで確認)
- FSMOロール移動時の動作やイベントログ
- クライアントPCやアプリケーションからの認証可否
- グループポリシーの適用状況
フェーズ3：バックアップ取得
作業直前には、システム状態バックアップやNTDS.DITのコピーなどを確実に行いましょう。バックアップの取得方法は以下の例を参照してください。
# Windows Server Backupのインストール (必要な場合)
Install-WindowsFeature Windows-Server-Backup
# システム状態バックアップを取得 (例: Dドライブにバックアップ)
wbadmin start systemstatebackup -backupTarget:D: -quietこのようにPowerShellで実行してもよいですし、サードパーティ製品を使ってイメージバックアップを行っても構いません。万が一トラブルが発生した場合に備え、本番直前の状態を保存しておくことが重要です。
フェーズ4：ページサイズ変更作業
前述したアプローチ1またはアプローチ2を選択し、DCのページサイズを32Kへ移行していきます。新規DCを追加する場合の大まかな流れを例示すると以下のようになります。
- 新しいWindows Serverを用意し、OSの初期設定を実施
- 役割と機能の追加ウィザード、またはPowerShellを使って「Active Directoryドメインサービス」をインストール
Install-ADDSForestまたはInstall-ADDSDomainControllerコマンドなどを活用し、32Kページサイズを指定(通常はレジストリの事前設定や応用的な方法が必要)- ドメインコントローラーとして昇格し、レプリケーションをチェック
- 旧サーバーのFSMOロールを移行(以下のPowerShell例を参考)
# PDC Emulatorを移行する例
Move-ADDirectoryServerOperationMasterRole -Identity "NewDC01" -OperationMasterRole PDCEmulator- 旧DCを降格し、AD DSの役割をアンインストール
- 動作確認(イベントログ、Repadmin、クライアント認証、GPOなど)
この一連の流れを、ドメイン全体あるいはフォレスト全体に対して繰り返し実施していきます。
トラブルシューティングのポイント
大きな構成変更を伴う作業では、突発的なエラーや予期せぬ不具合が起こる可能性があります。以下に代表的なトラブルシュートの観点を示します。
レプリケーションエラー
新しいDCを追加した後や旧DCを降格した際に、レプリケーションエラーが発生する場合があります。repadmin /replsummaryやrepadmin /showreplなどを用いてステータスを確認し、必要に応じてDNS設定やサイトリンク、ファイアウォール設定を見直しましょう。
FSMOロール移行の失敗
特定のDC間で通信障害がある場合、FSMOロールの移行に失敗することがあります。移行先のDCが正しく稼働し、ネットワーク的にも疎通できることを事前に確認してください。最悪の場合は強制移行も可能ですが、後々の整合性トラブルを引き起こしかねないため、可能な限り通常手順で移行しましょう。
グループポリシーの適用漏れ
昇格や降格のタイミングで、グループポリシーのレプリケーションが遅延したり、SYSVOLフォルダーの状態が不一致になったりすることがあります。DCに障害がないかをイベントビューアの「File Replication Service」や「DFS Replication」のログを確認しながらチェックしてください。
クライアント認証の遅延や失敗
クライアントPCのDNS設定が旧DCを参照していたり、新DCの情報がDNSへ正しく登録されていない場合、認証がうまくいかないケースがあります。IPアドレスの登録状況やDNSサーバーのフォワーダー設定、あるいはDHCPのスコープオプションなどを見直してみてください。
パフォーマンスとリソース使用量
32Kページサイズに切り替えると、大きなページを扱うぶんメモリ使用量が増加することが考えられます。特に次の点に注意してください。
メモリ搭載量の見直し
ドメインコントローラーのメモリ容量が少なすぎると、パフォーマンスが低下したり、場合によっては動作不良を引き起こす可能性があります。8Kページサイズで問題なかった環境でも、32Kに移行するなら余裕を持ったメモリ搭載量(最低16GB以上など)を検討しましょう。
ディスクI/Oへの影響
ページサイズが大きくなると、1回のディスクI/Oで読み書きするデータ量も増えます。一般的にはランダムアクセスの効率が改善されることもありますが、古いディスク構成やI/O性能が低いストレージを使用している場合は、思わぬボトルネックが生じるかもしれません。SSDやNVMeなどの高速ストレージを活用することで、スループット面で有利に働きます。
イベントログや監視ツールによる継続的モニタリング
移行後は「Directory Service」や「DNS Server」などのイベントログを定期的にチェックし、異常なエラーや警告が発生していないかを監視してください。さらに、サーバーリソースを可視化する監視ツール(SCOMなど)を導入していれば、CPU・メモリ・ディスクI/Oなどの値を参考にすることで移行の影響を定量的に把握できます。
移行後に確認しておきたいポイント
すべてのドメインコントローラーが32Kページサイズへと移行し、Database 32k Pages Featureが有効化できたら、以下のポイントを最終確認します。
フォレスト全体の機能レベル
フォレストおよびドメインの機能レベルを確認して、最新バージョンに正しくなっているかチェックします。PowerShellで確認する例を示します。
# ドメイン機能レベルの確認
Get-ADDomain | Select-Object DomainMode
# フォレスト機能レベルの確認
Get-ADForest | Select-Object ForestModeもし想定と異なる値であれば、正しく反映されているか再確認し、必要に応じてドメインレベル/フォレストレベルの引き上げを行います。
レプリケーションの健全性
レプリケーションの状況を再度確認し、すべてのDCが正常に同期されているかを確かめます。大規模環境では、サイトやサブネットの設定を見直し、不要なネットワーク遅延や名前解決エラーがないかを確認しましょう。
運用上のメリット検証
32Kページサイズへ移行したことで、どの程度パフォーマンス改善が見られるかを計測してみるとよいでしょう。特にユーザーログオン数の多い朝の時間帯や、集中処理が走るバッチタイムなどでのLDAP応答速度を測定すると効果を把握しやすいかもしれません。もし十分な効果が得られないと感じる場合は、サーバースペック全体の見直しや、他のボトルネック要因(ネットワーク帯域など)を探ることが重要です。
よくある質問(FAQ)
Q1. 小規模環境(DCが1～2台)の場合でも32Kにするメリットはあるの？
A1. 利用ユーザー数が少ない場合は、8Kのままでも十分なパフォーマンスが得られることも多いでしょう。しかし、将来的にユーザー数やグループ数、オブジェクト数が大幅に増える見込みがある場合は、早めに32Kへ移行しておくのも一つの手です。ただし切り替えが不可逆である点は同様に考慮してください。
Q2. 全DCを同時に降格・再インストールすることは避けたいが、段階的に進めてもいいの？
A2. 段階的な移行は可能です。ただし、最終的にすべてのDCが32Kにならないとオプション機能は有効化できません。最初に新しいDCを32Kで立ち上げ、レプリケーションを正常化してから旧DCを降格していく方法が一般的です。
Q3. 既存のDCに対してページサイズを直接変更するスクリプトやコマンドはないの？
A3. 残念ながら、JETデータベースのページサイズはAD DSインストール時点で決定されており、あとからコマンドで変更することはできません。再インストールまたは新規サーバー追加しか方法がないと考えましょう。
Q4. 万が一トラブルでAD DSが起動しなくなった場合はどうすればいい？
A4. 事前に取得したシステム状態バックアップや、ベアメタルリカバリ用のバックアップを元に復旧を試みることになります。また、複数のDCを運用している場合は、正常なDCを持つサイトからレプリケーションを行うことで復旧できるケースもあります。大前提として、バックアップ体制と復旧手順をドキュメント化しておきましょう。
まとめ
Database 32k Pages Featureを有効化することで、より大きなオブジェクトを扱いやすくなり、場合によってはパフォーマンス向上が期待できる反面、一度有効化すると元に戻せない不可逆的な処理です。組織のAD DS環境が大規模かつ24時間稼働が求められる場合などは、降格・昇格のスケジュールやバックアップ・テスト体制を入念に準備しましょう。
ページサイズが統一されていない状態で機能を有効化しようとしても、エラーが発生して処理が進まず、かえってダウンタイムやトラブルの要因になりかねません。最善策は、まずはテスト環境で成功事例を作り、本番環境に段階的に適用していくことです。移行完了後は、レプリケーションエラーやリソース使用状況を継続的に監視し、安定稼働を確認してから運用に乗せることをおすすめします。
大掛かりな作業だからこそ、事前の情報収集や綿密な計画が重要です。組織のニーズに応じて、最適な方法を選択しながら安全かつ確実に移行を進めてください。
コメント