Windows Server 2016の延長サポートは、2027年1月12日に終了します。社内の認証基盤であるActive Directory（以下、AD）をこのOS上で運用している企業にとって、サーバーの移行は待ったなしの課題です。

「2016から2025へ入れ替えるだけ」と考えられがちですが、ADの移行は単純なOSの更新では済みません。ADには過去の設定がそのまま引き継がれるため、長年運用してきた環境ほど構築当時の古い仕様が内部に残っています。これを見落とすと、新しいドメインコントローラー（以下、DC）を追加できない、あるいは全社的なログイン障害を引き起こすといった重大なトラブルにつながります。

この記事では、AD移行で特に見落とされやすい「3つの古い仕様」と、移行前に実施すべき確認・対処の手順、そして移行先としてのクラウドという選択肢について解説します。

「OSを入れ替えるだけ」では済まないActive Directory移行の落とし穴

ADは社内ネットワークの認証と権限管理を担う「企業インフラの要」であり、ファイルサーバーやWebサーバーの移行と同じ感覚で進めると、認証不可やログイン障害といった影響が全社に及びます。

たとえばWindows Server 2008 R2時代に構築したADを、2012、2016へと段階的にアップグレードしてきたとします。この場合、現在のOSが2016でも、内部には2008 R2時代の設定が残っている可能性があります。

特に注意が必要なのは、次の3つです。
まずは、それぞれにどのような問題があるのかを見ていきましょう。

• 機能レベル
• SYSVOLのレプリケーション方式
• Kerberos認証の暗号化方式

これらを確認しないまま移行すると、認証障害やレプリケーション障害といった重大なトラブルが発生するおそれがあります。

① 機能レベル：OSを更新しても自動では上がらない

機能レベルとは、ADシステム全体の動作モードを示す設定で、「チーム全員が合わせる共通のルールブック」にあたります。これはOSをアップグレードしただけでは自動的に更新されません。機能レベルを引き上げるには、稼働中のすべてのDCが、引き上げ先の機能レベルに対応したOSである必要があります。

そのため長年運用しているドメインでは、「2008 R2」「2012 R2」のまま固定されていることが少なくありません。

必要な機能レベルは移行先によって異なります。Windows Server 2022のDCは「2012 R2」または「2016」の機能レベルで利用できますが、Windows Server 2025のDCを追加するには「2016」または「2025」の機能レベルが必要です。要件を満たさない場合、新しいDCを追加できない可能性があります。

参照：Active Directory Domain Services の機能レベル. Microsoft Learn. (参照 2026-10-30)
※DCとして利用する場合の、ドメイン／フォレスト機能レベルとの互換性を示しています。
※Windows Server 2019／2022では「Windows Server 2016」が最新の機能レベルです。Windows Server 2025では新たに「Windows Server 2025」機能レベルが追加されています。

② SYSVOLのレプリケーション方式：古いFRSが残っていないか

SYSVOLは、グループポリシーなどの「社内ルール」を保管する共有フォルダです。その内容をすべてのDCへ配る仕組みがレプリケーションです。

方式には、Windows Server 2003時代から使われてきた古いファイルレプリケーションサービス（以下、FRS）と、現在標準のDFSレプリケーション（以下、DFSR）の2種類があります。長年運用している環境では、設定変更を行わない限りFRSが動き続けているケースが多く見られます。

FRSはすでに非推奨となっており、Windows Server 2016はFRSをサポートする最後のWindows Serverです。Windows Server 2019以降では、FRSでSYSVOLを複製しているドメインに新しいDCを追加できないため、事前にDFSRへの移行が必要です。

③ Kerberos認証の暗号化方式：RC4に依存したアカウントが残っていないか

ユーザーやパソコンが社内システムにアクセスしてよいかを確認する仕組みが、Kerberos（ケルベロス）認証です。かつては暗号化方式に「RC4」が広く使われていましたが、現在の標準はより安全な暗号化方式の「AES」です。

Microsoftは、Kerberos認証におけるRC4の利用縮小を段階的に進めています。2026年1月の更新プログラムで監査による警告が始まったのち、4月以降はRC4が明示的に設定されていないアカウントではAESが既定となりました。さらに7月以降は、この変更を一時的に元へ戻すための設定も廃止され、AESを既定とする変更が本格適用されています。

一方、長年運用している環境では、何年もパスワードを変更していないサービスアカウントが古いRC4のキーを保持したままになっていることがあります。この状態で移行や更新プログラムの適用を行うと、暗号化方式の不一致でKerberos認証が失敗し、ある日突然ログインできない、連携システムが停止するといった障害が発生します。

移行前に確認すべきポイントと対処方法

AD移行の鉄則は、いきなり新しいサーバーを追加しないことです。まずは現在のAD環境がどのような設定で動いているのかを把握（アセスメント）し、移行先の最新OSにどう影響するのかを確認したうえで、必要な設定変更を実施します。

ここでは、前章で紹介した「機能レベル」「SYSVOLのレプリケーション方式」「Kerberos認証の暗号化方式」の3つについて、移行前に何を確認し、問題がある場合にどう対処するのかを具体的に解説します。

① ドメイン／フォレスト機能レベルを確認し、必要に応じて昇格する

現在のドメイン／フォレスト機能レベル、稼働中のすべてのDCのOSバージョン、過去の移行時に降格し忘れて残っている古いDCの有無を洗い出します。

要件を満たしていない場合は、事前に昇格させます。引き上げ先の機能レベルに対応していない古いDCが残っている場合は、先にそのDCを降格・撤去し、管理ツール「Active Directory ドメインと信頼関係」から引き上げます。機能レベルの変更はAD環境全体に影響するため、稼働中のDCやアプリケーションへの影響を確認したうえで慎重に進めましょう。

② SYSVOLのレプリケーション方式を確認し、FRSならDFSRへ移行する

dfsrmig /getglobalstateコマンドやイベントビューアーで、SYSVOLの同期にFRSとDFSRのどちらが使われているかを特定します。あわせて既存のDC間でファイルがエラーなく同期されているかも確認します。ここで同期エラーがあると切り替え作業自体が失敗するため、重要なチェックポイントです。

FRSが使われていた場合は、新しいサーバーを追加する前に切り替えを完了させます。dfsrmigコマンドで「準備（Prepared）」「リダイレクト（Redirected）」「削除（Eliminated）」と段階を踏んで進めます。各段階で、すべてのDCに設定が行き渡ったことを確認するのが安全です。なおこの移行は一方通行で、FRSへは戻せません。

③ Kerberosの暗号化方式を確認し、AES対応へ見直す

次の4点を棚卸しします。

1. サービスアカウントがサポートする暗号化方式（msDS-SupportedEncryptionTypes属性）
2. グループポリシーで許可されているKerberos暗号化方式にAESが含まれているか
3. 長期間パスワードを変更していないアカウントの有無
4. ドメイン参加サーバーや業務アプリケーション側の認証方式

DC上のイベントID 4768・4769のログからは、実際にRC4が使われているアカウントを特定できます。

対象アカウントでAES 128／256ビット暗号化をサポートする設定を有効化し、あわせてパスワードをリセットしてAESベースのキーを再生成します。設定の有効化だけでは内部のキーが古いまま残る場合があるためです。認証方式の変更は「これまで動いていた業務システムが突然つながらなくなる」副作用を伴うため、本番環境の移行前に検証環境で入念にテストしましょう。

移行先はオンプレミスだけではない。クラウドという選択肢

「移行手順は理解したが、物理サーバーの発注から納品まで数か月かかると言われた」という課題に直面する企業が増えています。

2026年は、AI需要の拡大などを背景に、一般サーバー向け部品でも供給逼迫や調達リードタイムの長期化が報告されています。物理サーバーの発注から納品まで時間を要するケースもあり、Windows Server 2016のサポート終了を前に、機器調達の期間も移行計画に織り込む必要があります。

ADの移行先はオンプレミスのリプレイスだけではなく、クラウド上にDCを構築する、あるいはハイブリッド構成にするという選択肢も有力です。

ハードウェアの調達を待たずに移行できる

オンプレミスでADを再構築する場合、機器の選定から発注、納品、キッティングまでに多大な時間を要し、納品遅れがそのまま移行スケジュールの遅延に直結します。クラウドであれば製造や配送を待つ必要がなく、必要なスペックの環境を管理画面からの操作だけで数時間のうちに準備できます。

老朽化対応とリプレイス作業の負担を軽減できる

オンプレミスで運用し続ける限り、数年おきのリプレイス作業（選定・稟議・データ移行・廃棄）や、突然の故障に伴う部品交換への対応は避けられません。

クラウドへ移行すれば、物理サーバーの選定・調達・交換といったハードウェア管理の負担を軽減できます。これまでIT担当者が担ってきた維持管理業務を見直し、運用にかかる負担やコストを最適化する選択肢にもなります。

オンプレミスと組み合わせて認証基盤を冗長化できる

災害や機器の故障でDCが停止すると、社員はパソコンにログインできず、業務システムにもアクセスできない致命的な業務停止に陥ります。社内にDCを置きつつ、クラウド上にもDCを構築して同期させておけば、オンプレミス側のDCに障害が発生した場合にも、クラウド側が認証処理を引き継ぐ構成を検討でき、BCP（事業継続計画）の観点からも有効です。

ただし、クラウドへ移行してもOSのアップデートや稼働監視、セキュリティ対策といった運用は引き続き自社の役割です。ビジネス・アーキテクツでも、クラウドサービス「CLOUD × CLOUD」や運用代行支援「MPSサービス」を通じて、移行から移行後の運用までをご支援しています。

まとめ：現状把握と早めの準備が、安全なAD移行の鍵

Windows Server 2016の延長サポート終了が近づくなか、Active Directoryの移行は多くの企業にとって急務です。お伝えした重要なポイントは、次の2点です。

1. 古い仕様の事前点検と対処が必須
   新しいサーバーをいきなり追加せず、まず現状を把握します。「機能レベル」「FRS」「Kerberosの暗号化方式」に過去の仕様が残っていないかを確認し、事前に対処することで重大なトラブルを防げます。
2. クラウドを含めた柔軟な移行先の検討を
   調達遅延のリスクを回避できるほか、移行後の保守負担の軽減やBCP対策まで含めて、インフラ環境全体を最適化する絶好の機会となります。サポート終了対応を、認証基盤を強くする機会として捉えましょう。

現状を正しく把握し、早めに準備と対策を行うことが、安全にAD移行を進めるための鍵です。

自社での移行・運用に不安がある場合はお気軽にご相談ください

「古い仕様が残っているか調査するノウハウがない」「リソースが不足しており、移行作業やその後の運用まで手が回らない」とお悩みのご担当者さまも多いのではないでしょうか。ビジネス・アーキテクツでは、既存環境の調査から、クラウド環境の設計・構築、移行後のシステム監視・セキュリティ運用までを専門エンジニアがワンストップでご支援します。

お客さまの状況に合わせた移行プランをご提案しますので、AD移行に不安を感じているご担当者さまは、ぜひお気軽にお問い合わせください。