こんにちはますのです。
最近はAWSでWindowsServerの構築を行っており、構築完了したEC2インスタンスをAMIとして固めてゴールデンイメージとして運用を試みようと頑張っていました。
AMIから起動後しばらくすると「Windowsのライセンス認証：設定を開き、Windowsのライセンス認証を行ってください。」といったメッセージが。
ライセンス認証でWindows はライセンス認証されていませんと表示され、何やらうまくいっていないことを確認しました。
解決方法や原因について調査したので備忘録として残します。
AMI作成時にやったこと
- EC2Launch v1からSysprepを実行した直後のEC2インスタンスをAMIイメージ保存
- EBSはKMSキーで暗号化済
- 展開先はプライベートサブネット
- 展開先のCIDRは元のEC2インスタンスと同じ
ライセンス認証失敗が発生する原因
主な原因としては、展開したEC2インスタンスが「Windows AWS Microsoft Key Management Service（Microsoft KMS）」へアクセス出来ていないためです。
Windows インスタンスは、Windows AWS KMS のアクティブ化を使用します。インスタンスから A problem occurred when Windows tried to activate. Error Code 0xC004F074 サーバーにアクセスできない場合、AWS KMS というメッセージが表示される可能性があります。Windows は 180 日ごとにライセンス認証を行う必要があります。EC2Config では、確実に、引き続き Windows でアクティブ化されるように、アクティブ化の期限が切れる前に AWS KMS サーバーに接続します。
Windows インスタンスは、アマゾン ウェブ サービス (AWS) の Microsoft Key Management Service (Microsoft KMS) を使用してアクティベーションします。インスタンスが Microsoft KMS サーバーにアクセスできない場合、Windows のアクティベーションエラーメッセージが表示されることがあります。または、Microsoft KMS クライアント設定に問題がある可能性があります。
対応方法
EC2インスタンスのリンクローカルアドレス（169.254.169.250 / 169.254.169.251 等）のルートテーブルを更新します。
[手順：Windows のライセンス認証ができません]
１．管理者権限を持つ PowerShell プロンプトから、EC2Launch モジュールをインポートします。
PS C:\> Import-Module "C:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psd1"２．Add-Routes 関数を呼び出して、新しいルートのリストを表示します。
PS C:\> Add-Routes３．Set-ActivationSettings 関数を呼び出します。
PS C:\> Set-Activationsettings４．次のスクリプトを実行して、Windows のライセンス認証を行います。
PS C:\> cscript "${env:SYSTEMROOT}\system32\slmgr.vbs" /ato実行例です。
図のように、「NextHop：所属しているサブネット」に変更されます。
最後に「activated successfully」と表示され完了です。
余談：筆者は時間経過で解決したので対応不要だった
ちなみにですが、今回わたしのケースでは上記ルートテーブルの更新は不要でした。
理由は以下の通りです。
- Microsoft KMSへのルートテーブルは更新されていた
- 所属するサブネット（CIDR）は変更していないためMicrosoft KMSサーバと疎通出来ていた
- Microsoft KMSサーバとの疎通は7日ごとにライセンス認証を更新する
【キー管理サービスのライセンス認証の更新】
KMS ライセンス認証の有効期間は 180 日間 (ライセンス認証の有効期間) です。 ライセンス認証を維持するために、KMS クライアント コンピューターは、180 日ごとに 1 回以上、KMS ホストに接続してライセンス認証を更新する必要があります。 KMS クライアント コンピューターは、既定で 7 日ごとにライセンス認証を更新します。 KMS ライセンス認証に失敗した場合、クライアント コンピューターは 2 時間ごとに再試行します。 クライアント コンピューターのライセンス認証が更新されると、アクティブ化の有効期間が再び開始されます。
数時間～数日経過して認証されていることもあり、上記事象と合致したことからルートテーブルの更新は筆者のケースでは対応不要と判断しました。
ライセンス認証されなかった事象の解説
ここから先は技術解説となりますので参考情報としてご覧ください。
Microsoft KMSへアクセス出来ない理由
通常、EC2インスタンスを構築した時点で、Microsoft KMSへのルートテーブルがEC2インスタンスに構成されています。
AMIから復元した際にMicrosoft KMSへのルートテーブルが更新されなかったことが考えられます。
Microsoft KMSルートテーブル更新の失敗要因
- EC2Launch v1搭載サーバ（WindowsServer2016、WindowsServer2019）からのAMI復元
- 元のEC2インスタンスと別のネットワーク（VPCやサブネット）へ復元
１．EC2Launch v1搭載サーバからのAMI復元
EC2Launch v1はWindowsServer2016、WindowsServer2019のAMIにデフォルトで適用されています。
実行方法はPowerShellスクリプトになり、タイミングは「最初のインスタンスの起動1回のみ実行」がデフォルト動作となります。
EC2Launch は最初のインスタンスの起動中に、デフォルトで以下のタスクを実行します。
・インスタンスに関する情報をレンダリングする新しい壁紙を設定します。
・コンピュータ名を設定します。
・Amazon EC2 コンソールにインスタンス情報を送信します。
・EC2 コンソールに RDP 証明書のサムプリントを送信します。
・管理者アカウントに、ランダムなパスワードを設定します。
・DNS サフィックスを追加します。
・オペレーティングシステムパーティションを動的に拡張して、未使用の領域が含まれるようにします。
・ユーザーデータを実行します (指定された場合)。ユーザーデータを指定する方法については、「インスタンスユーザーデータの使用」を参照してください。
・メタデータサービスと AWS KMS サーバーに到達するために永続的な静的ルートを設定します。
なお、WindowsServer2022はEC2Launch v2となります。
EC2Launch v2はv1と挙動が異なり、インスタンスの停止→起動時や再起動時にタスクを実行する挙動となります。
つまり別のサブネットにAMIから復元しても、毎回ルートテーブルが更新されるようになり、Windowsライセンス認証失敗は発生しなくなります。
EC2Launch v2 は、インスタンスの起動時、またはインスタンスが停止後に起動された場合、または再起動された場合にタスクを実行するサービスです。
そのためルートテーブルなどが更新されない事象が発生していました。
今後WindowsServer2022を利用することが増えていけば、この記事もお役御免となります。
２．別のネットワーク（VPCやサブネット）へ復元
先に記述したように、EC2インスタンスは起動時に各種設定が行われています。
※パスワード設定やメタデータサービスアクセスのルートテーブルなど
また、EC2Launch v1の場合、EC2Launchを起動する設定にしていない限りAMI復元時に起動しないものとなります。
そのため別サブネットに復元した場合、ルートテーブルが異なりMicrosoft KMSサーバへアクセス出来なくなるようです。
ルートテーブルの確認方法
PS C:\> route print実行例です。
赤枠部分が該当箇所です。「Gateway Address」がEC2インスタンスの所属しているネットワークか確認しましょう。
リンクローカルアドレスの詳細
- 169.254.169.254：インスタンスメタデータ
- 169.254.169.250：Microsoft KMS
- 169.254.169.251：Microsoft KMS
- 169.254.169.249：GRID ライセンス
- 169.254.169.123：Amazon Time Sync Service
- 169.254.169.253：Amazon DNS サーバー
メタデータの取得やDNS、NTPなどにも影響してくる箇所です。
ルートテーブルが更新されているかは念のために確認しておきましょう。