Microsoftは2025年4月11日（米国時間）、Windows Server 2025の既知の問題のリストに新たに1つの重大なバグを追加しました。そのバグとは、ドメインコントローラーであるWindows Server 2025が再起動されると、ネットワークトラフィックを正しく管理できなくなることがあるというものです。結果として、ドメインに必要なプロトコルやポートへのアクセスがブロックされてしまう可能性があります。

Domain controllers manage network traffic incorrectly after restarting｜Windows message center（Microsoft Learn）

間もなくリリースから半年に、こんなバグが発覚

　Windows Server 2025のActive Directoryドメインコントローラーが、ネットワークトラフィックを正しく管理できなくなることがあるという問題の原因は、ドメインコントローラーが再起動されるたびにドメインファイアウォールプロファイルを使用しないため発生すると説明されています。ファイアウォールプロファイルを決定するのは、ネットワークアダプターのネットワーク接続プロファイルのネットワークカテゴリ（Public、Private、DomainAuthentiacated）であり、そのカテゴリに対してファイアウォールプロファイル（Public、Private、Domain）が決まります。そのため、問題はネットワーク接続プロファイルのほうにあると私は想像しています。

　手元の検証環境のWindows Server 2025のドメインコントローラーを確認してみると、ネットワーク接続プロファイルはプライベート（Private）になっており、プライベート（Private）ファイアウォールプロファイルが使用されていました（画面1）。筆者を含め、なぜ半年間も（Windows Server 2025のバグとして）気付かれることなく、公にされることもなかったのでしょうか。ドメインコントローラーおよびドメインに参加するメンバーのネットワーク接続プロファイルはドメイン（DomainAuthentiacated）でなければならないことは常識です。そしてプロファイル名（ネットワーク名）はActive DirectoryのDNSドメイン名になるはずです。筆者の環境の場合、プライベート（Private）ファイアウォールプロファイルであったため、クライアントからの通信に影響することがなく（クライアント側のネットワーク接続プロファイルは正常）、その結果として気付かなかったのでしょう。ちなみに、Windows Server 2025のメンバーサーバーではこのような問題は発生していません。

画面1　検証環境のWindows Server 2025のドメインコントローラーのネットワークは、ドメイン（DomainAuthentiacated）ではなく、プライベート（Private）になっていた

　Windows Server 2025に新規にActive Directoryドメインサービスの役割を追加して、ドメインコントローラーに昇格させてみたところ、昇格直後のネットワーク接続プロファイルのカテゴリはドメイン（DomainAuthentiacated）で問題はありませんでした。その後、再起動ではなく、シャットダウンして、起動してみると、パブリック（Public）に切り替わっていました。プライベートになるのか、パブリックになるのかは、昇格前のネットワーク接続プロファイルで決まるようです。つまり、ドメインコントローラーに昇格後、一度でも再起動またはシャットダウンすると、以前のネットワーク接続プロファイルに戻ってしまうという状況です。もし、プライベート（Private）であれば通信への影響は少ないかもしれませんが、プライベート（Public）に戻ってしまうとクライアントがドメインコントローラーに到達できないなど、大きく影響します。

回避策はRestart-NetAdapter *の実行

　Microsoftはこの問題を将来の品質更新プログラムのリリースで解決するとしています。当面の回避策としては、次のPowerShellのコマンドラインを実行して、ネットワークアダプターを再起動することです（画面2）。注意点は、ドメインコントローラーが再起動されるたびに（起動するたびに）、この回避策を実行する必要があることです。

画面2　PowerShellでネットワークアダプターを再起動すると、問題は即座に解消する

回避策をスタートアップスクリプトで実装

　回避策を自動化するには、ローカルコンピューターポリシー（Gpedit.msc）を使用して、上記のコマンドラインを記述したPowerShellスクリプト（.ps1）をコンピューターのスタートアップスクリプトとして追加します（画面3）。問題が根本的に解決されるまでは、これで対処できるでしょう。

画面3　回避策のコマンドラインを含むPowerShellスクリプトを、コンピューターのスタートアップスクリプトとして登録する

回避策をスケジュールタスクで実装

　Microsoftは回避策を繰り返し実行するために、スケジュールタスクを作成することを薦めています。その場合は、タスクスケジューラ（taskschd.msc）を使用して、プログラム「powershell.exe」、引数「Restart-NetAdapter *」を「システム起動時（スタートアップ時、コンピューターの起動時）」に実行するタスクを作成し、セキュリティオプションでタスクの実行時に使うユーザーアカウントに「SYSTEM」を指定し、「ユーザーがログオンしているかどうかにかかわらず実行する」と「最上位の特権で実行する」を有効にします（画面4）。なお、ドメインコントローラーの場合、実行アカウント（既定はログオン中のユーザー名）に「SYSTEM」を明示的に設定しないと、ログオンなしで実行するタスクがLaunch Failureエラー（エラー値: 2147943726、タスクの履歴で確認可能）で実行されない場合があるようです。

画面4　システム起動時タスクを作成して、回避策のコマンドラインをコンピューター起動時に自動実行させる

Windows Server 2025大特集（1）｜...｜ニュース