VMware vSphereのホストを更改し、旧ホストをDR（災害対策）サイトへ転用するとき、Windows Serverのライセンスは「ROK/OEMだから移せない」「DRだから不要とも言い切れない」で迷いがちです。WS2012 R2 Standard（ROK）→WS2019更改を例に、判断軸と現実的な設計パターンを整理します。
今回のケースを整理する（現状とゴール）
まずは論点を「バージョン合わせ」ではなく、「どの物理サーバー（ホスト）に、どの権利（ライセンス）を割り当てるか」に落として考えます。Windows Serverのライセンスは、VM単位よりも物理ホスト（コア）単位の影響が大きいからです。
| 項目 | 現状 | 更改後（希望） |
|---|---|---|
| 仮想基盤 | VMware vSphere ホスト3台 | 新ホスト3台へ更改（旧ホスト3台はDRへ転用） |
| Windows Serverライセンス形態 | Windows Server 2012 R2 Standard（ROK＝OEM系） | Windows Server 2019へ統一したい（ただし費用と条件次第） |
| 悩み | 旧ホストをDRに回すとき、追加ライセンスは必要？ 新ホストは何を買うべき？ | |
結論から：判断軸は「ROK/OEMの移設条件」＋「Software AssuranceでDR権利を使うか」
結論を先に言うと、設計の軸は次の2つです。
- ROK/OEMライセンスは原則として“そのサーバー本体にひも付く”ため、ライセンスだけを新ホストへ移す発想は危険（例外や補足条件は購入元・製品条件次第）。
- DR側のWindows Serverライセンスを抑えたいなら、本番側をSoftware Assurance（SA）付きで購入し、SAの災害対策（バックアップ）権利を使えるかがポイント。ただしDR運用条件が厳しいため、運用設計と監査耐性が必須。
この考え方は、Microsoft Q&Aでも「ROKはOEMの要素が強いので購入元へ転用可否を確認し、OEM/ROKのFAQも参照」と案内されています。
ROK（OEM系）とは何か：移設できる/できないの境界線
ROK（Reseller Option Kit）は、サーバーベンダーが提供するOEM形態の一種で、一般に安価な代わりにハードウェアに強く紐づくのが特徴です。HPEのOEM/ROK FAQでは、ROKを含むOEMライセンスは「新しいサーバーと一緒に販売される」「エンドユーザーは原則としてサーバーから移せない（例外：SA追加や製品条件で再割り当て権が明記される場合など）」という整理が明確に書かれています。
| 観点 | OEM/ROK（例：WS 2012 R2 ROK） | ボリューム/サブスク（例：Open Value / EA / MCA / CSPなど） |
|---|---|---|
| 購入形態 | サーバーとセット（ベンダー/リセラー経由） | ハードと切り離して購入可能（契約・商流に依存） |
| 他サーバーへの移設 | 原則不可になりやすい（条件確認が必須） | 契約・製品条件に沿って再割り当て（原則ルールあり） |
| Software Assurance（SA） | 付けられる場合があるが、購入後90日以内など期限があることが多い | 付けやすい（SA込みプログラムもある） |
| 向くケース | 単体サーバー運用、コスト優先、構成が固定 | 更改・移設・DRなど、運用で柔軟性が必要 |
補足として、Dellのナレッジでも「OEMライセンスはハードウェアに紐づき、サーバー筐体に付与される」旨が説明されています。つまり“古いサーバーをDRサイトへサーバー本体ごと移す”なら、OEM/ROKの整理上は筋が通りやすい一方、“ライセンスだけを新サーバーへ移す”は難しくなるのが一般的です。
ROKの落とし穴：ベンダー固有の仕組み（BIOSロック）
OEM/ROKはベンダーの仕組みで特定メーカーのハードウェア上だけで有効になる場合があります。例えばHPEのFAQでは、HPE OEM（ROKを含む）は最適化され、BIOSロックによってHPEサーバー以外にはインストールできない旨が説明されています。
また、ROKメディアをVMware上で使うときに「system not supported」系のメッセージで止まるケースがあり、HPEのFAQではVM設定に次の行を追加する案内があります（環境により要確認）。
SMBIOS.reflectHost = "TRUE"
実務メモ：「移設できるか？」は、Microsoftの一般論だけでなく、OEM/ROKの契約条件（ベンダー、型番、購入形態、SA付与有無）で結論が変わり得ます。監査・更新のタイミングで揉めやすいので、購入元（ベンダー/リセラー）へ書面ベースで確認するのが安全です。
Windows Serverの仮想化ライセンスは「ホストに割り当ててVMを動かす」発想が基本
Windows Server Standard / Datacenterは、（バージョンにより細部はありますが）基本的に物理サーバーの全コアをライセンスして、そのサーバー上で動かせるWindows Server VMの数が決まります。
| エディション | 仮想化の基本権利（イメージ） | vSphereで選ばれやすい理由 |
|---|---|---|
| Standard | 全コアをライセンスするとVM 2台分（OSE 2つ）まで。VMを増やすなら同じコア数分のライセンスを積む | VMが少ないホストなら安いが、VMが増えると管理とコストが跳ねる |
| Datacenter | 全コアをライセンスするとVM台数無制限 | VM密度が高い、DR/移行でVM移動が多い環境で「計算がシンプル」 |
HPEのOEM/ROK FAQでも、Standardは「全コアをライセンスした場合に2つのOSE（VM）まで」「追加のVMを増やすなら（2台ごとに）再度全コア分のライセンスが必要」という考え方が明記されています。vSphere環境でStandardを選ぶと、ホストごとのVM数とDR時に動かしたいVM数でライセンス量が大きく変わる点に注意してください。
「DRだから無条件にDR側ライセンス不要」は誤解になりやすい
DR（災害対策）と言っても、運用の“温度”によって扱いが変わります。MicrosoftのSA権利（バックアップインスタンス）は便利ですが、使える条件が明文化されています。
| DRの温度感 | 典型的な状態 | ライセンス上の注意 |
|---|---|---|
| コールド（Cold） | 通常は停止。複製だけ保持し、テスト/災害時のみ起動 | SAのDR権利でカバーできる可能性が高い（ただし条件順守が前提） |
| ウォーム（Warm） | 平常時も起動。パッチ適用や監視、限定的な処理を実行 | 「通常時に実行している」扱いになりやすく、追加ライセンスが必要になりがち |
| ホット（Hot） | 常時稼働。負荷分散や業務の一部を処理 | ほぼ確実に本番扱い。DR権利の範囲外になりやすい |
SAの災害対策（バックアップ）権利で押さえるべき条件
MicrosoftのWindows Serverライセンスガイダンスでは、SAのDR権利（バックアップインスタンス）の実行条件が具体的に示されています。代表的なポイントだけ噛み砕くと次の通りです。
- バックアップインスタンスは、DRテスト（90日ごとに1週間以内）、災害で本番が落ちている期間、切替前後の短期間など、限定的な期間だけ実行できる。
- DR側のOSEは、その期間以外は動かしっぱなしにできない。
- DRサーバーは、本番と同じクラスターに属してはいけない（同一vSphereクラスタ内の“待機ホスト”をDR扱いにするのは危険）。
- DRサーバーはDR用途に限定され、本番用途に使えない。
- そして重要なのが、SAが切れたらDR権利も終了する点（CAL等も含めてSA維持が求められる）。
ポイント：vSphereの場合、「旧ホストをDRに回す」と言いながら、同じクラスタに残してHA/DRSの対象にしてしまうと、設計意図が“DR”ではなく“本番の冗長化”と見なされやすくなります。SAのDR権利を狙うなら、クラスタ分離・用途分離・稼働ルール（起動時間の制限）をセットで設計してください。
候補案を現実的に評価する（よくある3案＋追加案）
ここからは、質問で挙がりやすい案を「成立条件」「落とし穴」「向くケース」で整理します。なお、MicrosoftのOpen Licenseプログラムは2022年1月1日以降、新規購入や更新ができない旨がアナウンスされています。現在の新規調達はCSPやOpen Valueなど、別の商流になる点も合わせて確認してください。
| 案 | 新ホスト（本番） | 旧ホスト（DR） | メリット | 注意点 | 向くケース |
|---|---|---|---|---|---|
| 案A：バージョン合わせでDR側も購入 | WS2019 ROK（OEM） | WS2019（ボリューム/サブスク等）を別途購入 | DRを“いつでも起動できる”運用に寄せやすい。テスト頻度が高くても運用が楽 | DR側の追加コストが増える。ROKは他社機に移せない等の制約は残る | DRをウォーム運用したい、月次で長時間テストしたい |
| 案B：本番をSA付きにしてDR側は追加購入しない | WS2019（ボリューム）＋SA | 追加ライセンスなし（SAのDR権利でバックアップインスタンス運用） | DR側コストを抑えられる可能性。運用ルールを守れば合理的 | 起動時間制限・クラスタ分離など条件が厳しい。SA維持費が継続的に発生 | DRはコールドで良い、テストは四半期ペース、監査対応を整えられる |
| 案C：本番をDatacenter＋（必要なら）SAでシンプル化 | WS2019 Datacenter（ボリューム、必要に応じSA） | DRは案B同様、条件を守って運用（または必要分だけ別途購入） | 本番ホストのVM台数が多いほど計算が簡単。将来増設にも強い | VMが少ないと割高になることがある。DR権利を使うなら運用条件は同じ | 各ホストのWindows VMが多い、今後も増える見込み |
| 追加案：DR基盤をオンプレから切り離す | 本番はオンプレ継続 | DRはAzure等へ（構成とコスト次第） | DRサイトのハード維持が不要になる場合がある。拠点災害に強い | 回線・ランニング・設計が別物。Windows Serverの持ち込み可否も要検討 | DRサイトの運用負担が重い、拠点分散を強化したい |
案Aがハマるパターン：DRテストが「四半期1週間」では足りない
SAのDR権利は便利ですが、テスト頻度や稼働時間が要件と合わないケースがあります。例えば、月次で長時間の切替訓練をする、DR側でパッチ検証や業務リハーサルをする、といった“ウォーム寄り”の運用をしたい場合は、DR側を最初からライセンスしてしまったほうが監査・運用が楽です。
案Bが刺さるパターン：DRは「回すための場所」で、平常時は触らない
一方で、DRの思想が「いざという時に短期間だけ動けばよい」「定期テストも四半期で十分」という組織では、本番ライセンスにSAを付けてDR権利を使うのが合理的になりやすいです。ただし、SAは“付けて終わり”ではなく、次のような運用設計のセットが必要です。
- DR側vSphereクラスタを本番クラスタから分離し、用途をDRに限定する（「同一クラスタ内の待機ホスト」にしない）。
- DR側Windows VMの起動・停止ルールをRunbook化し、テスト実施日・稼働時間のログを残す。
- CAL（ユーザーCAL/デバイスCAL）や管理系ライセンスも含め、SA要件があるものは契約を維持できるように更新計画に組み込む。
CAL（アクセスライセンス）を見落とすと、DR設計が崩れる
Windows ServerはOSライセンスだけで完結しません。ユーザー/デバイスがサーバー機能にアクセスするなら、基本的にCAL（Client Access License）またはExternal Connector（EC）が必要です。最新のWindows Serverライセンスガイダンスでは、CAL/ECは同じバージョン、またはそれ以前のサーバーにアクセスできるという整理が示されています。
| 持っているCAL/EC | アクセスできるWindows Serverの目安 | 更改・DRでの意味 |
|---|---|---|
| 2019 CAL/EC | 2019（およびそれ以前） | 本番/DRとも2019なら整合を取りやすい |
| 2022 CAL/EC | 2022・2019（およびそれ以前） | 将来アップグレードも見据えるなら余裕が出る |
| 2025 CAL/EC | 2025・2022・2019（およびそれ以前） | 最新LTSCへ寄せたい組織向け |
DR側をSAの権利で運用する場合でも、ガイダンス上はCAL/ECや管理ライセンスについてSA維持が求められる旨が記載されています。「OSだけ合っていればOK」にならないので、CALもセットで棚卸ししてください。
「旧ホストはWS2012 R2 ROKのままDRに使える？」の現実
ここは勘違いが多いポイントです。旧ホストに紐づいたWS2012 R2 ROKを持っていても、DRで起動するVMがWS2019なら、WS2012 R2の権利でWS2019を動かすことは通常できません。
- DRで起動するVMのOSバージョンが2012 R2のままなら、旧ライセンスで整合が取りやすい。
- 本番を2019へ更改し、DRでも2019のVMを起動したいなら、2019を動かせる権利が別途必要（＝DR側をライセンスするか、SAのDR権利でバックアップインスタンスとして動かすか）。
さらに、WS2012 R2は延長サポートが2023年10月10日で終了しています。DRであっても、長期に2012 R2を残すなら、ESU（延長セキュリティ更新）等の扱いも含めてセキュリティ・監査面の説明が必要になります。
失敗しないためのチェックリスト（見積り前にやること）
ライセンスの相談をすると「結局いくら？」に寄りがちですが、見積りの前に決めるべき前提があります。ここを曖昧にすると、あとから“想定外の追加購入”になりやすいです。
| チェック項目 | 確認ポイント | 理由 |
|---|---|---|
| 新ホストの物理コア数 | 各ホストのCPU/コア数（将来増設も） | Windows Serverはコア課金が基本。Standard積み増し/Datacenter選択に直結 |
| ホストあたりのWindows VM台数 | 平常時とDR切替時（最大）で何台動かすか | Standardは2VM単位で増える。DR側をライセンスするかの判断材料 |
| DRテストの頻度・稼働時間 | 四半期？月次？テスト時に何時間/何日動かす？ | SAのDR権利は実行期間に条件があるため |
| DRサイトの構成 | 本番とクラスタ分離できるか、用途をDR専用にできるか | 同一クラスタは“本番の冗長化”に見えやすく、DR権利の前提から外れやすい |
| 既存ROK/OEMの契約条件 | 購入元へ「サーバー本体をDRへ移設する場合の扱い」を確認 | OEM条件はベンダー差があり、監査時に根拠が求められる |
| CALの扱い | ユーザー/デバイス数、RDS CALの有無、SA要件の有無 | OSだけ合っても、アクセスライセンス不足で監査リスクが残る |
おすすめの進め方（現場で揉めない順序）
- Step 1：現状のホスト構成（コア数）とWindows VM台数を棚卸しする。
- Step 2：DR要件を「コールド/ウォーム/ホット」で言語化し、テスト頻度と稼働時間を決める。
- Step 3：新ホストのWindows ServerをStandardかDatacenterか決める（VM密度が高いならDatacenterが有利になりやすい）。
- Step 4：DR側を“追加購入で自由度を取る”か、“SAのDR権利でコストを取る”かを決める。
- Step 5：ROK/OEMの転用可否（旧サーバー本体をDRへ移設する扱い）を購入元に確認し、回答を保管する。
参考情報（一次情報中心）
- Microsoft Q&A: Disaster Recovery licensing（ROK/OEMは購入元へ確認、OEM FAQ参照）
- HPE: FAQ for Microsoft OEM licensing – Windows Server（ROK/OEMの前提、SA追加期限、仮想化の考え方）
- Microsoft: Windows Server Licensing Guidance（DR権利の実行条件、CALの考え方、Open Licenseの扱いなど）
- Microsoft: Open Licenseプログラム変更（2022年以降の新規購入の扱い）
- Microsoft Lifecycle: Windows Server 2019（サポート期間）
- Microsoft Lifecycle: Windows Server 2012 R2（延長サポート終了日とESU）
- Dell: Windows Server OEM License（OEMが筐体に紐づく考え方）
本記事は一般的な情報整理です。最終的な適用可否は、Microsoftの最新のライセンス条項（Product Terms等）と、購入元（OEM/リセラー）の条件に従って判断してください。
コメント