エラー 0xC004F074 "接続できるキー管理サービス (KMS) がありませんでした"

  • [アーティクル]

適用対象: ✔️ Windows VM

この記事では、Microsoft Azure で Windows 仮想マシン (VM) をアクティブ化しようとしたときに発生する0xC004F074 エラーを解決する方法について説明します。

前提条件

現象

Azure Windows VM をアクティブ化しようとすると、Windows スクリプト ホストで次のエラー メッセージが表示されます。

エラー: 0xC004F074 ソフトウェア ライセンス サービスは、コンピューターをアクティブ化できなかったことを報告しました。 キー管理サービス (KMS) に接続できませんでした。 詳細については、アプリケーション イベント ログを参照してください。

原因

VM は、ライセンス認証のために KMS サービスに接続できません。 アクティブ化に Azure KMS が使用されている場合 (既定の選択)、アクティブ化要求は Azure パブリック IP アドレスから送信される必要があります。 この接続エラーの考えられる原因は次のとおりです。

  • すべてのトラフィックが Azure ExpressRoute またはネットワーク仮想アプライアンスを使用して (通常はオンプレミス環境に) Azure の外部にルーティングされる強制トンネリング

  • ネットワーク仮想アプライアンスまたは標準の内部ロード バランサーによってブロックされるトラフィック

調査

問題の具体的な原因を特定するには、次のセクションの 3 部構成の手順に従います。

パート 1: 適切な KMS クライアント セットアップ キーを構成する

Note

この部分は、 Azure Virtual Desktop で Windows 10 Enterprise マルチセッション (Windows 10 Enterprise for Virtual Desktops とも呼ばれます) を実行する VM では必要ありません。

VM がマルチセッション エディションを実行しているかどうかを確認するには、次の Software License Manager スクリプト コマンドを実行します。

slmgr.vbs /dlv

出力に Name: Windows(R), ServerRdsh edition 文字列が含まれている場合、VM はマルチセッション エディションを実行しており、この部分の残りの部分はスキップできます。

Note

Windows 10 Enterprise マルチセッション VM をデプロイし、プロダクト キーを別のエディションに更新する場合、VM を Windows 10 Enterprise マルチセッションに戻すことはできません。 代わりに、VM を再デプロイする必要があります。 詳細については、「 Windows VM を Windows Enterprise マルチセッションにアップグレードできますか?」を参照してください。

カスタム イメージから作成された VM の場合は、VM の適切な KMS クライアント セットアップ キーを構成する必要があります。 次のステップを実行します。

  1. 管理者特権のコマンド プロンプト ウィンドウで、次のソフトウェア ライセンス マネージャー スクリプト コマンドを実行します。

    cscript c:\windows\system32\slmgr.vbs /dlv

  2. 出力の Description 値を調べて、VM がリテール (RETAIL チャネル) またはボリューム (VOLUME_KMSCLIENT) ライセンス メディアから作成されたかどうかを確認します。

  3. 前のコマンド出力で RETAIL チャネルが示されている場合は、次のソフトウェア ライセンス マネージャー スクリプト コマンドを実行します。 最初のコマンドは、使用されている Windows Server のバージョンにKMS クライアント セットアップ キーを設定し、2 番目のコマンドは別のアクティブ化の試行を強制します。

    cscript c:\windows\system32\slmgr.vbs /ipk <kms-client-setup-key>
cscript c:\windows\system32\slmgr.vbs /ato

    たとえば、Windows Server 2016 Datacenter を使用している場合、最初のコマンドは次のように表示されます。

    cscript c:\windows\system32\slmgr.vbs /ipk CB7KF-BWN84-R7R2Y-793K2-8XDDG

パート 2: VM が Standard SKU 内部ロード バランサーの背後にあるかどうかを確認する

既定で送信インターネット トラフィックをブロックする Standard SKU 内部ロード バランサーの背後に VM があるかどうかを確認するには、次の手順に従います。

  1. Azure portal で、[仮想マシン] を検索して選択します。

  2. 仮想マシンの一覧で、VM の名前を選択します。

  3. VM のメニュー ウィンドウで、 Networking 見出しを見つけて、 負荷分散の読み込みを選択します。 表示する負荷分散リソースがありませんというメッセージが表示された場合、VM はロード バランサーの背後にありません。 この場合は、「 パート 3: VM と Azure KMS サービスの間の接続を確認するに進むことができます。

  4. ロード バランサー リソースが表示される場合は、ロード バランサーの名前を選択して、ロード バランサーの Overview ページに移動します。

  5. ロード バランサーのメニュー ウィンドウで、 Properties を選択します。

  6. Properties ページで、SKU と Load Balancing Type の値を見つけて、次の表で結論を確認します。

    SKUと負荷分散の種類の値 まとめ
    SKU 値は Standard で、 Load Balancing Type 値は Private です。 VM は、既定で送信インターネット トラフィックをブロックする Standard SKU 内部ロード バランサーの背後にあります。 送信接続を有効にするには、「 Solution 2: (Standard 内部ロード バランサーの場合) NAT ゲートウェイまたは標準パブリック ロード バランサーを使用するを参照してください。
    SKU 値は Standard ではなく、 Load Balancing Type 値は Public です。 VM は Standard SKU 内部ロード バランサーの背後にありません。送信インターネット トラフィックは既定ではブロックされません。 「 パート 3: VM と Azure KMS サービスの間の接続を確認します。

パート 3: VM と Azure KMS サービス間の接続を確認する

  1. 正しい Azure KMS サーバーを使用するように VM が構成されていることを確認します。 これを行うには、次のソフトウェア ライセンス マネージャー スクリプト コマンドを実行します。

    Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms azkms.core.windows.net:1688"

    このコマンドは、次のテキストを返す必要があります。

    "キー管理サービスのマシン名は azkms.core.windows.net:1688 に正常に設定されました。"

  2. VM 内のファイアウォールで、ポート 1688 の KMS エンドポイントへの送信ネットワーク トラフィックがブロックされていないことを確認します。 これを行うには、次のいずれかのオプションを適用します。

    • PowerShell で Test-NetConnection コマンドレットを実行して、接続を確認します。

      Test-NetConnection azkms.core.windows.net -port 1688

      接続の試行が許可されている場合、コマンドレットは出力テキストに "TcpTestSucceeded: True" と表示されます。

    • PsPing ツールを実行して接続を確認します。

      .\psping.exe azkms.core.windows.net:1688

      コマンド出力では、2 行目から最後の行は次のテキストのようになります。

      Sent = 4, Received = 4, Lost = 0 (0% loss)

      Lostが 0 (ゼロ) より大きい場合、VM は KMS サーバーに接続されません。 この状況では、VM が仮想ネットワーク内にあり、カスタム DNS サーバーが指定されている場合は、DNS サーバーが azkms.core.windows.net ドメイン名を解決できることを確認する必要があります。 できない場合は、DNS サーバーを、 azkms.core.windows.net解決できるサーバーに変更します。

      Note

      仮想ネットワークからすべての DNS サーバーを削除すると、VM は Azure の内部 DNS サービスを使用します。 このサービスは、 kms.core.windows.netを解決できます。

  3. Azure Network Watcher の次ホップテストを使用して、影響を受ける VM から特定の宛先への次ホップの種類が Internet であることを確認します。 次ホップ テストを適用するには、次の手順に従います。

    1. Azure portal で、[仮想マシン] を検索して選択します。

    2. 仮想マシンの一覧で、VM の名前を選択します。

    3. VM のメニュー ウィンドウで、 Help 見出しを見つけて、 Connection のトラブルシューティングを選択します。

    4. VM の Connection のトラブルシューティング ページで、次のフィールド値を指定します。

      フィールド 値
      送信先の種類 手動で指定
      URI、FQDN、または IP アドレス 20.118.99.224、 40.83.235.53 ( azkms.core.windows.netの場合)、またはリージョンに適用される適切な KMS エンドポイントの IP
      宛先ポート 1688
      ソース ポート 1688
      診断テスト 次ホップ

    5. [診断テストの実行] ボタンを選択します。

    6. 診断テストが完了したら、ボタンの下に表示される Results ボックスを確認します。 次ホップ (ソースから) テストには、Success の Status 値が必要です。Details 値には、次ホップの種類 Internet をテキストに含める必要があります。 次ホップの種類が Internet の場合は、残りの IP ごとに次ホップ テストを繰り返します。 ただし、次ホップの種類が VirtualAppliance、 VirtualNetworkGateway、または Internet 以外として表示される場合は、次のいずれかのシナリオが発生している可能性があります。

      • トラフィックが Azure KMS エンドポイントに送信される前に、トラフィックを Azure の外部にルーティングする既定のルートが存在します。

      • パスのどこかでトラフィックがブロックされます。

      これらのシナリオについては、「 ソリューション 1: (強制トンネリングの場合) Azure カスタム ルートを使用してアクティブ化トラフィックを Azure KMS サーバーにルーティングするを参照してください。

  4. azkms.core.windows.netへの接続が成功したことを確認したら、その管理者特権の Windows PowerShell プロンプトで次のコマンドを実行します。 このコマンドは、Windows VM のライセンス認証を複数回試行します。

    1..12 | ForEach-Object {
    Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato";
    Start-Sleep 5
}

    アクティブ化の試行が成功した場合、コマンドは次のテキストのようなメッセージを表示します。

    Windows(R)、Server Datacenter Edition (<kms-client-product-key>) のアクティブ化...製品が正常にアクティブ化されました。

解決策 1: (強制トンネリングの場合) Azure カスタム ルートを使用してアクティブ化トラフィックを Azure KMS サーバーにルーティングする

原因が、トラフィックが Azure の外部にルーティングされる強制トンネリング シナリオである場合は、ネットワーク管理者と協力して、適切な措置を決定してください。 考えられる解決策の 1 つは、「強制トンネリングシナリオで Windows のアクティブ化が失敗する」の「Solution」セクションで説明されています。 組織のポリシーと一致する場合は、このソリューションを適用します。

解決策 2: (Standard 内部ロード バランサーの場合) NAT ゲートウェイまたは標準パブリック ロード バランサーを使用する

標準の内部ロード バランサーがトラフィックをブロックする場合、「送信接続の送信元ネットワーク アドレス変換 (SNAT) を使用する」で説明されているように、問題を解決するには、次の 2 つの異なる方法があります

運用環境のデプロイでは、送信接続に Azure Virtual Network NAT 構成を使用することをお勧めします。 Azure NAT Gateway の詳細については、「Azure NAT Gateway とは」を参照してください

ただし、すべてのインターネット トラフィックをブロックする必要がある場合は、アクティブ化する必要がある VM のサブネットでネットワーク セキュリティ グループ (NSG) 規則を使用して、送信インターネット アクセスを拒否してください。 プラットフォームの内部規則により、ポート 1688 の KMS IP へのオペレーティング システムのアクティブ化トラフィックが有効なままであることに注意してください。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。