Windowsで「組織のライセンス認証サーバーに接続できない」エラーが発生：原因と解決策

「組織のライセンス認証サーバーに接続できない」と出たら、会社・学校の管理PCか個人PCかを先に分けます。組織のKMS認証を使う端末では、社内ネットワークや指定VPNへの接続が必要な場合があります。VPNを一律に切断したり、インターネットにつながるだけで認証サーバーにも届くと判断したりしないでください。

Windowsの［設定］に表示される認証状態、エラーコード、エディションを確認し、管理PCはIT部門へ連絡します。このガイドはWindowsのライセンス認証を対象とし、Officeの認証やリモートデスクトップのRDS CALとは区別します。実際の認証操作を行った検証結果は含みません。

最初に見る場所と記録する情報

Windows 11は［設定］→［システム］→［ライセンス認証］、Windows 10は［設定］→［更新とセキュリティ］→［ライセンス認証］で状態を確認します。WindowsのHome/Pro/Enterpriseなどのエディション、表示される文面と0xから始まるコード、発生日時、直前の再インストールや構成変更を記録してください。

0xC004F074はKMSへ接続できない場合の代表例ですが、似た文面でも原因は同じとは限りません。DNSの問題、認証対象のエディションやキーの種類、サーバーの状態などはコードに応じて調べます。「有効期限」と表示されたことだけで、購入済みライセンスの権利が消えたと断定しないでください。

会社・学校のPC：指定のネットワーク経路を確認する

社外利用中なら、組織が認めるVPNや社内接続が必要かをIT部門へ確認します。VPN接続済みでも、社内DNSやKMSへの経路が利用できるとは限りません。インターネットのWebサイトが開くことと、社内の認証サーバーへ接続できることは別です。

KMSは一度認証すれば永久に接続不要という方式ではなく、定期的な更新を伴います。長く社内へ接続していなかった端末では、認証状態の更新ができていない可能性があります。認証方式や更新間隔を利用者が勝手に変更せず、組織が指定する接続手順を使ってください。

複数の利用者が同時に発生しているなら、端末ごとのリセットよりもサーバーやネットワーク側の調査を優先します。1台だけなら、その端末の認証方式、DNS、時刻、ネットワークと直前の変更を比較します。

個人購入のPCで表示された場合

組織に属さない個人PCなのにこの表示がある場合は、インストールされたエディションとライセンスの種類が購入内容に合うかを確認します。中古PC、修理や再インストール後、販売店でセットアップされた端末などでは、販売店へ購入時のライセンス説明を問い合わせることが有用です。表示だけで違法な端末と決めつける必要はありません。

ネット上の不明なKMSサーバーを設定する、無料認証ツールを実行する、出所不明のキーを購入する、といった方法は使いません。正規のデジタルライセンスや購入記録と現在のエディションを確認し、Microsoftの認証トラブルシューティングや販売元のサポートへ進みます。Homeの権利があるだけでEnterpriseが認証できるわけではありません。

読み取りでライセンス状態を確認する

管理者が詳細を調べる場合のコマンドプロンプト例です。/dlvは詳細情報、/xprは現在の認証状態の期限を表示するもので、プロダクトキーの入れ替えや認証先の変更は行いません。組織の指示に従って実行します。

cscript //nologo "%windir%\system32\slmgr.vbs" /dlv
cscript //nologo "%windir%\system32\slmgr.vbs" /xpr

DescriptionにVOLUME_KMSCLIENTがあるか、License Status、参照しているKMSホストやポートが意図したものかを管理者が確認します。KMS、MAK、Retail、OEMなどを区別し、違う方式向けの修正コマンドを混ぜないでください。

出力には内部ホスト名や端末識別情報、キーの一部などが含まれます。必要部分だけを社内サポートへ渡し、全文を公開掲示板へ貼らないでください。完全なプロダクトキー、パスワード、認証トークンを共有する必要はありません。

管理者向け：DNS・ポート・時刻を切り分ける

KMSの自動検出ではDNSのSRVレコードを使います。まず対象端末が組織の指定DNSを利用しているかを確認します。公開DNSへ切り替えると社内の認証先を発見できなくなることがあるため、認証エラーの万能対処としてDNSを変更しません。

ipconfig /all
nslookup -type=SRV _vlmcs._tcp.example.com

example.comは説明用です。管理者が確認した組織のDNSサフィックスへ置き換え、正規のKMSホストとポートが返るかを調べます。レコードがないから即座に公開サーバーを探すのではなく、固定設定や別のボリューム認証方式を使っているかも確認します。

次はWindows PowerShellのTCP到達性確認例です。kms.example.comは組織で確認した実際のホストへ、1688は実際のポートへ置き換えます。1688はKMSの既定値ですが、変更された構成もあります。

Test-NetConnection -ComputerName 'kms.example.com' -Port 1688

TcpTestSucceededがTrueでも、認証の権利、エディション互換性、サーバーの応答内容まで成功した証明にはなりません。FalseならDNS・経路・サーバー待受・ファイアウォールのどこかを管理者が調べます。端末のファイアウォール全停止や、インターネット全体へポートを開放する対処はしません。

時刻とタイムゾーンが正しいかも確認します。時刻のずれが原因となる場合がありますが、ドメイン端末の時刻同期先を無断で外部へ変更しないでください。管理者はクライアントとホストの認証ログ、サービスの状態、対応するOS・キーを合わせて調査します。

接続が直った後に認証を再試行する場合

設定画面や管理者の指示から再試行します。管理者がslmgrを使う場合の例は次の通りです。/atoは読み取りではなく、設定済みの認証方式に従って認証を試みる操作なので、対象方式と接続先が正しいことを確認してから行います。

cscript //nologo "%windir%\system32\slmgr.vbs" /ato

再試行後は設定画面の認証状態と返された結果を確認します。失敗を繰り返す場合は、新しいエラーコードを記録して調査します。/skmsで認証先を固定する、/ipkでキーを変更する、/upkでキーを削除する、/rearmを繰り返す操作を通常の復旧手順として実行しません。

IT部門や販売店へ渡すチェックリスト

端末の管理元、Windowsのエディションとバージョン、エラーコード・文面・時刻、社内/VPN接続の状況、最後に正常だった時期、再インストールや機器交換の有無をまとめます。管理者が求めた場合だけ/dlvの必要部分やログを渡し、個人PCでは購入記録と販売時のエディションを確認します。

「サーバーにつながらない」「認証方式が違う」「適用できるライセンスがない」は別の問題です。ネットワークだけを何度も初期化したり、直ちに新しいライセンスを買ったりする前に、どの段階で失敗しているかを切り分けてください。

公式資料

Microsoft：Windows認証エラーの確認 / KMSのトラブルシューティング / Slmgr.vbsオプション