오류 0xC004F074 "KMS(키 관리 서비스)에 연결할 수 없음"

아티클
03/27/2024

이 문서에서는 Microsoft Azure에서 Windows VM(가상 머신)을 활성화하려고 할 때 발생하는 0xC004F074 오류를 resolve 방법에 대해 설명합니다.

필수 구성 요소

PowerShell
소프트웨어 라이선스 관리자(slmgr.vbs) 스크립트
PsPing 도구

증상

Azure Windows VM을 활성화하려고 하면 Windows 스크립트 호스트에서 다음 오류 메시지가 표시됩니다.

오류: 0xC004F074 소프트웨어 라이선싱 서비스는 컴퓨터를 정품 인증할 수 없다고 보고했습니다. KMS(키 관리 서비스)에 연결할 수 없습니다. 자세한 내용은 애플리케이션 이벤트 로그를 참조하세요.

원인

VM은 정품 인증을 위해 KMS 서비스에 연결할 수 없습니다. Azure KMS를 활성화(기본 선택)에 사용하는 경우 활성화 요청은 Azure 공용 IP 주소에서 시작되어야 합니다. 이 연결 실패의 가능한 원인은 다음과 같습니다.

Azure ExpressRoute 또는 네트워크 가상 어플라이언스 사용하여 모든 트래픽이 Azure 외부(일반적으로 온-프레미스 환경으로) 라우팅되는 강제 터널링
네트워크 가상 어플라이언스 또는 표준 내부 부하 분산 장치에 의해 차단되는 트래픽

조사

문제의 특정 원인을 확인하려면 다음 섹션의 세 부분으로 구성된 절차를 따릅니다.

1부: 적절한 KMS 클라이언트 설정 키 구성

참고

이 부분은 Azure Virtual Desktop에서 다중 세션(Virtual Desktop용 Windows 10 Enterprise이라고도 함)Windows 10 Enterprise 실행하는 VM에는 필요하지 않습니다.

VM이 다중 세션 버전을 실행하고 있는지 확인하려면 다음 소프트웨어 라이선스 관리자 스크립트 명령을 실행합니다.

slmgr.vbs /dlv

출력에 문자열이 Name: Windows(R), ServerRdsh edition 포함된 경우 VM이 다중 세션 버전을 실행하고 있으며 이 부분의 나머지 부분을 건너뛸 수 있습니다.

참고

Windows 10 Enterprise 다중 세션 VM을 배포한 다음 제품 키를 다른 버전으로 업데이트하는 경우 VM을 Windows 10 Enterprise 다중 세션으로 되돌리기 수 없습니다. 대신 VM을 다시 배포해야 합니다. 자세한 내용은 Windows VM을 Windows Enterprise 다중 세션으로 업그레이드할 수 있나요?를 참조하세요.

사용자 지정 이미지에서 만든 VM의 경우 VM에 적합한 KMS 클라이언트 설정 키를 구성해야 합니다. 다음 단계를 따릅니다.

관리자 권한 명령 프롬프트 창에서 다음 소프트웨어 라이선스 관리자 스크립트 명령을 실행합니다.
```
cscript c:\windows\system32\slmgr.vbs /dlv
```
출력의 Description 값을 확인하여 VM이 소매(채널) 또는 볼륨(RETAILVOLUME_KMSCLIENT) 라이선스 미디어에서 만들어졌는지 확인합니다.
이전 명령 출력이 RETAIL 채널을 나타내는 경우 다음 소프트웨어 라이선스 관리자 스크립트 명령을 실행합니다. 첫 번째 명령은 사용되는 Windows Server 버전에 대한 KMS 클라이언트 설정 키를 설정하고 두 번째 명령은 또 다른 활성화 시도를 강제합니다.
```
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이 표준 SKU 내부 부하 분산 장치 뒤에 있는지 확인

다음 단계에 따라 VM이 기본적으로 아웃바운드 인터넷 트래픽을 차단하는 표준 SKU 내부 부하 분산 장치 뒤에 있는지 여부를 검사.

Azure Portal가상 머신을 검색하여 선택합니다.
가상 머신 목록에서 VM의 이름을 선택합니다.
VM의 메뉴 창에서 네트워킹 제목을 찾은 다음 부하 분산을 선택합니다. 표시할 부하 분산 리소스가 없음이라는 메시지가 표시되면 VM이 부하 분산 장치 뒤에 있지 않습니다. 이 경우 3부: VM과 Azure KMS 서비스 간의 연결 확인을 진행할 수 있습니다.
부하 분산 장치 리소스가 표시되면 부하 분산 장치의 이름을 선택하여 부하 분산 장치의 개요 페이지로 이동합니다.
부하 분산 장치의 메뉴 창에서 속성을 선택합니다.

속성 페이지에서 SKU 및 부하 분산 유형에 대한 값을 찾은 다음, 다음 표를 참조하여 결론을 확인합니다.

SKU 및 부하 분산 형식의 값	결론
SKU 값은 표준이고 부하 분산 형식 값은 Private입니다.	VM은 기본적으로 아웃바운드 인터넷 트래픽을 차단하는 표준 SKU 내부 부하 분산 장치 뒤에 있습니다. 아웃바운드 연결을 사용하도록 설정하려면 솔루션 2: (표준 내부 부하 분산 장치의 경우) NAT 게이트웨이 또는 표준 공용 부하 분산 장치 사용을 참조하세요.
SKU 값은 표준이 아니며 부하 분산 형식 값은 공용입니다.	VM은 표준 SKU 내부 부하 분산 장치 뒤에 있지 않으며 아웃바운드 인터넷 트래픽은 기본적으로 차단되지 않습니다. 3부: VM과 Azure KMS 서비스 간의 연결을 확인합니다.

3부: VM과 Azure KMS 서비스 간의 연결 확인

VM이 올바른 Azure KMS 서버를 사용하도록 구성되어 있는지 확인합니다. 이렇게 하려면 다음 소프트웨어 라이선스 관리자 스크립트 명령을 실행합니다.
```
Invoke-Expression "$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms azkms.core.windows.net:1688"
```
이 명령은 다음 텍스트를 반환해야 합니다.

키 관리 서비스 컴퓨터 이름이 azkms.core.windows.net:1688 성공적으로 설정되었습니다.
VM의 방화벽이 포트 1688의 KMS 엔드포인트에 대한 아웃바운드 네트워크 트래픽을 차단하지 않는지 확인합니다. 이렇게 하려면 다음 옵션 중 하나를 적용합니다.
- PowerShell에서 Test-NetConnection cmdlet을 실행하여 연결을 확인합니다.
```
Test-NetConnection azkms.core.windows.net -port 1688
```
  연결 시도가 허용되는 경우 cmdlet은 출력 텍스트에 "TcpTestSucceeded: True"를 표시합니다.
- PsPing 도구를 실행하여 연결을 확인합니다.
```
.\psping.exe azkms.core.windows.net:1688
```
  명령 출력에서 두 번째 줄과 마지막 줄은 다음 텍스트와 유사해야 합니다.
  
  Sent = 4, Received = 4, Lost = 0 (0% loss)
  
  가 0보다 큰 경우 Lost VM은 KMS 서버에 연결되지 않습니다. 이 경우 VM이 가상 네트워크에 있고 사용자 지정 DNS 서버가 지정된 경우 DNS 서버가 도메인 이름을 resolve azkms.core.windows.net 수 있는지 확인해야 합니다. 할 수 없는 경우 DNS 서버를 resolve azkms.core.windows.net수 있는 서버로 변경합니다.
  
  참고
  
  가상 네트워크에서 모든 DNS 서버를 제거하는 경우 VM은 Azure의 내부 DNS 서비스를 사용합니다. 이 서비스는 를 resolve kms.core.windows.net수 있습니다.

Azure Network Watcher 다음 홉 테스트를 사용하여 다음 홉 유형이 영향을 받는 VM에서 특정 대상으로 인터넷인지 확인합니다. 다음 홉 테스트를 적용하려면 다음 단계를 수행합니다.

Azure Portal가상 머신을 검색하여 선택합니다.
가상 머신 목록에서 VM의 이름을 선택합니다.
VM의 메뉴 창에서 도움말 제목을 찾은 다음 연결 문제 해결을 선택합니다.

VM의 연결 문제 해결 페이지에서 다음 필드 값을 지정합니다.

필드	값
대상 유형	수동으로 지정
URI, FQDN 또는 IP 주소	20.118.99.224, 40.83.235.53 (의 경우 `azkms.core.windows.net`) 또는 해당 지역에 적용되는 적절한 KMS 엔드포인트의 IP
대상 포트	1688
원본 포트	1688
진단 테스트	다음 홉

진단 테스트 실행 단추를 선택합니다.
진단 테스트가 완료되면 단추 아래에 표시되는 결과 상자를 검토합니다. 다음 홉(원본에서) 테스트의 상태 값은 성공이어야 하며 세부 정보 값에는 다음 홉 유형인 인터넷이 텍스트에 포함되어야 합니다. 다음 홉 유형이 인터넷인 경우 나머지 각 IP에 대해 다음 홉 테스트를 반복합니다. 그러나 다음 홉 유형이 VirtualAppliance, VirtualNetworkGateway 또는 인터넷 이외의 항목으로 표시되는 경우 다음 시나리오 중 하나가 발생할 수 있습니다.
- 트래픽이 Azure KMS 엔드포인트로 전송되기 전에 Azure 외부의 트래픽을 라우팅하는 기본 경로가 있습니다.
- 트래픽은 경로를 따라 어딘가에 차단됩니다.
이러한 시나리오는 솔루션 1: (강제 터널링의 경우) Azure 사용자 지정 경로를 사용하여 활성화 트래픽을 Azure KMS 서버로 라우팅을 참조하세요.

에 대한 연결 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), 서버 데이터 센터 버전(<kms-client-product-key>) 활성화... 제품이 성공적으로 활성화되었습니다.

해결 방법 1: (강제 터널링의 경우) Azure 사용자 지정 경로를 사용하여 활성화 트래픽을 Azure KMS 서버로 라우팅

원인으로 인해 트래픽이 Azure 외부에서 라우팅되는 강제 터널링 시나리오인 경우 네트워크 관리자와 협력하여 올바른 작업 과정을 결정합니다. 한 가지 가능한 솔루션은 강제 터널링 시나리오에서 Windows 정품 인증 실패의 솔루션 섹션에 설명되어 있습니다. organization 정책과 일치하는 경우 이 솔루션을 적용합니다.

해결 방법 2: (표준 내부 부하 분산 장치의 경우) NAT 게이트웨이 또는 표준 공용 부하 분산 장치 사용

표준 내부 부하 분산 장치가 트래픽을 차단하는 경우 아웃바운드 연결에 SNAT(원본 네트워크 주소 변환) 사용에 설명된 대로 문제를 해결하는 두 가지 방법이 있습니다.

프로덕션 배포에서 아웃바운드 연결에 Azure Virtual Network NAT 구성을 사용하는 것이 좋습니다. Azure NAT Gateway에 대한 자세한 내용은 Azure NAT Gateway란?을 참조하세요.

그러나 모든 인터넷 트래픽을 차단해야 하는 요구 사항이 있는 경우 활성화해야 하는 VM의 서브넷에서 NSG(네트워크 보안 그룹) 규칙을 사용하여 아웃바운드 인터넷 액세스를 거부해야 합니다. 플랫폼 내부 규칙으로 인해 포트 1688의 KMS IP에 대한 운영 체제 활성화 트래픽이 계속 활성화되어 있습니다.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유