![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(316.8, 28.999999999999996%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 33%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDV%3C/text%3E%3C/svg%3E)
こんにちは、
ご質問の内容を整理すると、現在 Windows Server 2022 Standard OEM + MAK キーで構成された Hyper‑V クラスタ上に仮想マシンを稼働させており、別環境で稼働している仮想 OS をコピーして sysprep を実行した上で、KMS 認証に切り替えて今回のクラスタに移動させたいということですね。懸念されているのはライセンス違反にならないかどうか、という点です。
まず前提として、Windows Server の OEM + MAK ライセンスは物理ホストに紐づいており、仮想マシンのライセンスとは別扱いになります。仮想 OS 側を KMS で認証する場合、環境に有効な KMS ホストが存在し、かつその KMS ホストに対して正規のボリュームライセンスキーを使用しているのであれば、コピーした仮想マシンを sysprep で一般化した後に KMS 認証を行うことはライセンス違反にはなりません。Microsoft のライセンス条項では、KMS はボリュームライセンス契約に基づく環境での利用を前提としており、同一契約下の複数 VM に対して利用可能です。
注意すべき点は、OEM + MAK で購入したホスト OS と、KMS で認証するゲスト OS のライセンス体系が異なるため、ホスト側は OEM/MAK のまま、ゲスト側は KMS で認証するという二重構成になります。この点は Microsoft のライセンス規約上問題ありません。違反になるのは、OEM キーを複数 VM に流用したり、KMS 環境が正規のボリュームライセンス契約に基づいていない場合です。
したがって、仮想 OS を sysprep で一般化し、KMS 環境で正規の VL キーを使って認証するのであれば、今回の移行はライセンス違反には該当しません。運用上は、移行後に slmgr /ato で KMS 認証が正常に通ることを確認し、イベントログにエラーがないことをチェックしておくと安心です。
Domic Vo.