Windows Server 2019 を再インストールしたら評価版になった時の対処法｜エディション変換とライセンス認証エラー完全解説

Windows Server 2019 Standard をウイルス対応などで何度もクリーンインストールした結果、「いつの間にか評価版になっていて、手元のプロダクトキーでは認証できない」というトラブルは現場で非常によく発生します。本記事では、評価版と製品版の違いから、エディション変換とライセンス認証の具体的な手順、エラーコード別の対処方法、再発防止策までを実運用目線でまとめます。

再インストールしたら評価版になり、認証できない問題の正体

まず押さえておきたいポイントは次のとおりです。

• 評価版 ISO（Evaluation メディア）でインストールすると、エディションは ServerStandardEval や ServerDatacenterEval になります。
• この状態では、市販・ボリューム・OEM の製品版キーを直接入れても認証できません。
• 最初にやるべきことは、評価版 → 製品版への「エディション変換」 であり、「過去インストールの紐づけ解除」ではありません。

Microsoft の公式ドキュメントでも、Windows Server の評価版は DISM コマンドでリテール版に変換してからライセンスを適用する必要があると案内されています。

また、Windows Server ではインターネットから評価版 ISO をダウンロードしやすいため、「つい毎回評価版メディアでインストールしてしまう」パターンも多く見られます。その結果、同じ物理サーバーなのに再インストールのたびに評価版になり、ライセンス認証だけがうまくいかない状態になるわけです。

よくある症状とチェックポイント

症状	具体例
デスクトップ右下に「評価コピー」表示	「Windows Server 2019 Standard Evaluation」や残り日数が表示されている
設定画面からライセンス認証できない	手元の 2019 Standard キーを入れてもエラーコード付きで拒否される
slmgr /dlv で EVAL と表示	チャネルが TIMEBASED_EVAL、ライセンス状態が評価版と表示される
dism /Get-CurrentEdition で Eval 付き	ServerStandardEval / ServerDatacenterEval になっている

これらの症状が揃っているなら、「評価版のまま製品版キーを入れようとしている」のが原因である可能性が非常に高いです。

まず現在の状態をコマンドで正確に確認する

闇雲にキーを入れ直す前に、管理者権限のコマンド プロンプト（または PowerShell）で以下のコマンドを実行して、エディション・評価版／製品版・ライセンス種別 を切り分けましょう。

エディションと評価版かどうかを確認

DISM /online /Get-CurrentEdition
DISM /online /Get-TargetEditions

項目	見るポイント	代表的な表示例
Current Edition	末尾に Eval が付いていないか	ServerStandardEval / ServerDatacenterEval
Target Edition	変換可能なエディションが何か	ServerStandard / ServerDatacenter など

Microsoft は公式に「DISM /Get-CurrentEdition の結果に Eval が付いている場合は評価版」「DISM /Get-TargetEditions で変換可能な製品版を確認してから /Set-Edition で変換する」手順を案内しています。

ライセンス種別・認証状態の確認

slmgr /dlv

slmgr /dlv では、次のような情報を確認できます。

項目	例	意味
説明（Description）	Windows(R), ServerStandardEval edition, TIMEBASED_EVAL channel	評価版（TIMEBASED_EVAL）であることを示す
ライセンスの状態（License Status）	Licensed / Notification / Unlicensed 等	認証済みかどうか
Product Key Channel	Retail / OEM / Volume:MAK / Volume:KMS 等	キーの種別（リテール、OEM、MAK、KMS）
エラーコード	0xC004C020 など	認証失敗時の原因特定に使う

ここまで確認できたら、「評価版かどうか」「どのエディションか」「どの種類のキーか」がはっきりします。次のステップは、評価版であれば製品版へのエディション変換です。

評価版から製品版へエディション変換する大まかな流れ

評価版 → 製品版への変換は、大きく以下のステップで行います。

1. 現在のエディション・評価版かどうかを確認（前述の DISM コマンド）。
2. DISM /Get-TargetEditions で変換先エディションを確認。
3. 必要に応じて AD DS など重要ロールを一時的に外す（特にドメイン コントローラー）。
4. DISM /Set-Edition で評価版を製品版エディションへ変換。
5. 再起動後、slmgr /ipk で手元のキーを登録し、slmgr /ato で認証。

評価版を製品版に変換してからでないと、製品版キーでのライセンス認証は成功しません。

重要：ドメイン コントローラーでは直接変換できない

Active Directory ドメイン コントローラー（AD DS ロールを持つサーバー）が評価版で動いている場合、そのサーバーを 評価版 → 製品版へ直接変換することはサポートされていません。これは Microsoft 公式でも「評価版からリテール版への変換は、ドメイン コントローラー上では行えない」と明記されています。

この場合は、以下いずれかの現実的な方法を取る必要があります。

• 別サーバー or VM を用意して追加のドメイン コントローラーとして構成する
• FSMO 役割をすべて追加 DC に移譲し、元の評価版 DC を降格（AD DS ロール削除）。
• 降格後のサーバーでエディション変換を実行し、再度 DC に昇格させる。
• 必要に応じて FSMO 役割を元のサーバーへ戻す。

もしくは、評価版にこだわらず、最初から製品版 ISO（VL メディアや OEM メディアなど）でクリーンインストールし直すという選択肢もあります。この場合はバックアップと復元計画が前提になりますが、構成がシンプルならこの方が早いケースも少なくありません。

DISM で評価版から Server Standard へエディション変換する手順

事前チェックリスト

• 必ず管理者権限のコマンド プロンプト / PowerShell を使用する。
• 重要データ・システム状態のバックアップを取得しておく。
• AD DS ロール（ドメイン コントローラー）の場合、先に降格しておく。
• 仮想マシンなら可能な限りスナップショットを作成する。

実行コマンド例（ServerStandardEval → ServerStandard）

ドメイン コントローラーではない状態になっていることを確認した上で、次のコマンドを実行します。

DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula

• ServerStandard の部分は /Get-TargetEditions の結果に表示されたターゲットを指定します。
• XXXXX-... の部分は、実際に購入した Windows Server 2019 Standard のプロダクトキーに置き換えます。

処理の途中で 10% 前後でしばらく止まったように見えることがありますが、数分〜十数分程度は待ってみてください。一部の環境では、コマンドが長時間 10% で固まることがあり、その場合は Software Protection サービス（sppsvc）を停止したり、一時的にネットワークを切断することで改善するという報告もあります。

コマンドが成功すると、「Operation completed successfully」のメッセージと共に再起動が求められます。再起動後、再度 DISM /Get-CurrentEdition を実行して ServerStandard になっていることを確認してください。

評価版のままキーを入れてしまった場合の挙動

評価版の状態（ServerStandardEval）で製品版キーを入れようとすると、以下のようなエラーが出ることがあります。

• 0xC004F050（このエディションには使えないキー）
• 0xC004C020（MAK 上限超過）

実際には「評価版なのに製品版キーを入れようとしている」ことが根本原因であり、まずは 評価版 → 製品版への変換が先 である点に注意してください。

変換後にプロダクトキーを投入してライセンス認証する

エディションが ServerStandard（Eval が付かない） になって初めて、製品版キーによる正規のライセンス認証が可能になります。

基本コマンド

:: プロダクトキーを登録
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

:: オンライン認証を実行
slmgr /ato

:: 認証の有効期限を確認（永続かどうか）
slmgr /xpr

• slmgr /ipk 実行時にエラーが出る場合は、キーの種別（Datacenter 用、別バージョン用など）が間違っている可能性があります。
• slmgr /ato 実行時にエラーが出る場合は、回線・プロキシ・ファイアウォールなどのネットワーク要因、またはキー側の問題（上限超過・無効化）を疑います。
• オフライン環境や MAK 上限超過などの場合は、後述の slui 4 による電話認証が選択肢になります。

電話認証ウィザード（必要時）

slui 4

slui 4 を実行すると、国を選択して電話による音声ガイダンスに従いながらインストール ID を読み上げ、確認 ID を入力する形で認証するウィザードが起動します。特に MAK キーでインターネット経由の認証が通りにくいケースや、上限リセット直後などに有効です。

それでも認証できない場合：代表的なエラーコードと対処

評価版 → 製品版への変換を済ませても認証が通らない場合、エラーコードが重要なヒントになります。ここでは代表的なものを整理します。

エラーコード	主な原因	対処の方向性
0xC004C020	MAK キーの認証可能回数を超過	ライセンス発行元（ボリュームライセンス管理者／販売店）へ上限リセットを依頼
0xC004F050	入力したキーがそのエディションと合致しない、または誤入力	エディション名（ServerStandard など）とキー種別を見直す
0xC004C003	プロダクトキーがブロックされている（不正利用・誤登録等）	購入元または Microsoft サポートにキーの状態を問い合わせ
0xC004F074 など	KMS サーバーに到達できない、DNS 未設定など	KMS ホストの稼働状況、DNS 設定、ファイアウォールを確認

Microsoft のトラブルシュート記事でも、エラー 0xC004C020 は「MAK の上限に達した状態」を意味すると説明されており、追加アクティベーションが必要な場合はライセンシング チームへ問い合わせることが推奨されています。

また、0xC004F050 は「現在のエディションに対してキーが不適切な場合」によく発生し、キー自体は正しくても ServerStandard に対して Datacenter 用キーを入れている、といったミスマッチで起こります。

0xC004C003 は「プロダクトキーがブロックされた」状態を示すことが多く、キーの不正コピーや許諾を超えた利用が検知された際に発生します。この場合も、購入元や Microsoft サポートにキーの状態調査を依頼するのがセオリーです。

OEM キー・MAK キーなどライセンス種別による違い

手元のキーの種類によって、挙動や相談先が変わります。ざっくり整理すると次のようになります。

キー種別	特徴	想定される相談先
リテール（箱 / ダウンロード版）	単体購入。原則 1 ライセンス = 1 サーバー	購入元の販売店、または Microsoft サポート
OEM（プレインストール）	サーバーメーカーと紐づく。マザーボード交換に弱い	サーバーメーカーのサポート
Volume:MAK	決められた回数まで複数台にインストール可	組織内のライセンス管理者、ボリュームライセンス販売店、VLSC サポート
Volume:KMS クライアント	社内の KMS サーバーへ定期的に認証しに行く方式	組織のシステム管理者（KMS サーバー運用者）

OEM キーは通常、同一ハードウェア（特にマザーボード）であれば再インストールしても自動的に適用されますが、「評価版メディアからインストールしている場合」は別です。評価版を製品版に変換しない限り OEM キーが適用されないため、やはり エディション変換が先 になります。

「過去インストールの紐づけ解除」は必要か？

質問でよくあるのが「同じキーで何度もインストールしているので、過去インストールの紐づけ解除が必要では？」という不安です。実際のところ、挙動はキー種別によって異なります。

MAK キーの場合

• MAK（Multiple Activation Key）は、あらかじめ決められた回数まで認証できるキーです。
• 同一サーバーを何度も再インストールしても、そのたびに 1 カウント消費します。
• 「アンインストールしたから回数が戻る」という仕組みはありません。
• 上限に達して 0xC004C020 が出るようになったら、発行元（ライセンス販売店や Microsoft ライセンス窓口）に上限リセットを依頼します。

リテールキーの場合

• 通常は 1 ライセンス = 1 サーバーの利用を前提とします。
• 同じサーバーの再インストールであれば、ライセンス条項に反しない範囲で再認証が可能です。
• しかし、あまりに回数が多い場合や、異なるハードウェアで頻繁に認証している場合は、不正使用とみなされキーがブロックされる可能性があります（0xC004C003 等）。

OEM キーの場合

• OEM は基本的に購入したサーバー筐体とセットです。
• マザーボード交換など、大きなハードウェア変更を行うと認証が通らなくなることがあります。
• この場合はサーバーメーカー側の裁量で対応の可否が決まるため、メーカーサポートへの相談が必須です。

いずれの場合も、「過去のインストールを Microsoft 側で個別に解除してもらう」という運用は一般的ではなく、むしろ 評価版・製品版の区別や、キーの種別と上限管理を適切に行うこと が重要です。

誰に相談すべきか？ライセンス種別別の目安

実際にサポートへ連絡する際の目安を整理します。

ケース	主な相談先	事前に用意しておく情報
Volume:MAK / KMS	組織のライセンス管理者、ボリュームライセンス販売店、VLSC サポート	キーの末尾、認証台数の見込み、エラーコード、slmgr /dlv の結果
リテール版（パッケージ / ダウンロード）	購入元の販売店、または Microsoft サポート	購入証憑、プロダクトキー、エラーコード、インストール履歴
OEM 版（プレインストール）	サーバーメーカー（ハードウェアベンダー）のサポート	製品型番、シリアル番号、プロダクトキー、構成変更有無

問い合わせ前に slmgr /dlv の内容や画面のスクリーンショットをまとめておくと、やり取りがスムーズになります。

RDS（リモートデスクトップサービス）構成時の落とし穴

実運用では、RDS（Remote Desktop Services）や VDI 環境の構築時にこの問題が表面化することが多いです。

• 「一般的な標準構成」として、Connection Broker やライセンス サーバー、セッション ホストを AD ドメインに参加させるケースが多い。
• 単一サーバー構成でも、「RDS を入れる前提だから」と先に AD DS をインストールしてドメイン コントローラー化してしまうパターンが多い。
• しかし評価版のまま DC 化すると、あとから /Set-Edition で変換できず詰む。

そのため、RDS を含む構成を作るときは次のような手順が安全です。

1. まずは評価版を使わず、最初から製品版 ISO で Windows Server をインストールする。
2. やむを得ず評価版で検証する場合は、AD DS や RDS のロールを入れる前に評価版 → 製品版へのエディション変換を完了させておく。
3. 重要ロールを載せるサーバーほど、ライセンス認証とエディションを早めに確定させる。

再発防止のための運用ルール例

同じトラブルを繰り返さないために、次のような運用ルールをおすすめします。

メディア管理の徹底

• 評価版 ISO と製品版 ISO をはっきり区別し、名称に Eval や VL などを含めて保管する。
• 再インストール時に使用するメディアを標準化し、「基本は製品版 ISO を使う」ルールを徹底する。
• 評価版を使うのは検証環境に限定し、本番環境では原則使用しない。

ライセンス台帳の作成

• プロダクトキーごとに以下の情報を台帳化する。
  • キー種別（Retail / OEM / MAK / KMS など）
  • 紐づけているサーバー名・用途（本番 / 検証）
  • MAK の場合は想定アクティベーション数、消費回数
• Volume:MAK を使う場合は、VAMT（ボリューム アクティベーション管理ツール）などで自動的にカウントを管理する仕組みを検討する。

構築プロセスに「認証確認」を含める

• サーバー構築標準手順書に、以下のステップを明記する。
  • OS インストール後、DISM /Get-CurrentEdition でエディションを確認。
  • 必要に応じて /Set-Edition を実行して製品版へ変換。
  • slmgr /ipk / /ato / /xpr でライセンス認証を確認。
  • その後で AD DS / RDS / SQL Server など重要ロールをインストール。
• 「ロール構成が終わってからライセンスを考える」のではなく、最初期にライセンスを確定させる習慣を付ける。

コマンド一覧（コピー用）

最後に、本記事で登場した代表的なコマンドをまとめておきます。

:: 現状確認
DISM /online /Get-CurrentEdition
DISM /online /Get-TargetEditions
slmgr /dlv

:: 評価版 → 製品版（ドメイン コントローラーではない状態で）
DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula

:: キー投入と認証
slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /ato
slmgr /xpr

:: 電話認証ウィザード（必要時）
slui 4

まとめ：やることは「評価版を製品版に変換してから、正しい窓口へ相談」

ここまでを簡単にまとめると、ポイントは以下の通りです。

• 評価版メディアでインストールした Windows Server 2019 は、そのままでは製品版キーで認証できない。
• まずは DISM /Get-CurrentEdition / /Get-TargetEditions で現状を確認し、/Set-Edition で評価版から製品版へエディション変換する。
• ドメイン コントローラーは評価版から直接変換できないため、追加 DC を用意して FSMO 移譲 → 降格 → 変換 → 再昇格、または製品版での再構築を検討する。
• 変換後に slmgr /ipk / /ato で認証し、エラーコードごとに原因と相談先を切り分ける。
• 再発防止には、メディア管理・ライセンス台帳・構築手順への「認証確認」の組み込みが有効。

「過去インストールの紐づけ解除」が必要なのではなく、評価版と製品版の扱いの違いと、キー種別ごとの上限管理を整理することが根本解決につながります。この記事を参考に、落ち着いてエディションとライセンス状態を確認し、適切なルートで対処を進めてみてください。