활성화되지 않는 ADBA(Active Directory 기반 활성화) 클라이언트 문제 해결

참고

이 문서는 원래 2018년 3월 26일에 TechNet 블로그로 게시되었습니다.

최근에 저는 고객이 환경에 Windows Server 2016 배포할 수 있도록 도왔습니다. 또한 이 기회를 통해 KMS 서버에서 Active Directory 기반 정품 인증으로 정품 인증 방법론을 마이그레이션했습니다.

모든 변경을 위한 적절한 절차로 고객의 테스트 환경에서 마이그레이션을 시작했습니다. Active Directory-Based Activation 및 Key Management Services의 지침에 따라 배포를 시작했습니다. 테스트 환경의 도메인 컨트롤러는 모두 R2 Windows Server 2012 실행 중이므로 포리스트를 준비할 필요가 없었습니다. Windows Server 2012 R2 도메인 컨트롤러에 역할을 설치하고 볼륨 활성화 방법으로 Active Directory 기반 활성화를 선택했습니다. KMS 키를 설치하고 "KMS AD 정품 인증(** 랩)"이라는 이름을 지정했습니다. 블로그 게시물 단계를 단계별로 수행했습니다.

4개의 가상 머신, 2개의 Windows 2016 Server Standard 및 2개의 Windows 2016 Server Datacenter를 빌드하는 것으로 시작했습니다. 이 시점에서 모든 것이 좋았습니다. Windows 2016 Server Standard를 실행하는 물리적 서버를 빌드했으며 컴퓨터가 제대로 활성화되었습니다.

사실, 설정 및 구성은 매우 쉬웠기 때문에 그 부분은 간단하고 직선적이었습니다. 그러나 이전에 빌드한 모든 가상 머신은 활성화되지 않은 것으로 나타났습니다. 나는 물리적 인 기계로 돌아 갔고 괜찮았다. 나는 무슨 일이 있었는지 논의하기 위해 고객에게 갔다. 첫 번째 질문은 "주말 동안 무엇이 변경되었습니까?" 였습니다. 그리고 평소와 같이 대답은 "아무것도"이었다. 이번에는 아무것도 바뀌지 않았고, 우리는 무슨 일이 일어나고 있는지 알아내야했습니다.

문제 서버 중 하나로 이동하여 명령 프롬프트를 열고 명령의 출력을 확인했습니다 slmgr /ao-list . 스위치는 /ao-list Active Directory의 모든 활성화 개체를 표시합니다.

결과에는 Windows Server 2012 R2용 정품 인증 개체와 Windows Server 2016 라이선스인 새로 만든 KMS AD 정품 인증(** LAB)의 두 가지 활성화 개체가 있음을 보여 줍니다. 이렇게 하면 Active Directory가 Windows KMS 클라이언트를 활성화하도록 올바르게 구성되었는지 확인합니다.

명령이 slmgr 라이선스 정품 인증을 위한 것이라는 것을 알았기 때문에 다른 옵션을 계속했습니다. 자세한 라이선스 정보를 표시하는 스위치를 시도 /dlv 했습니다. 이것은 잘 보였다, 나는 Windows Server 2016 표준 버전을 실행했다, 정품 인증 ID, 설치 ID, 유효성 검사 URL, 심지어 부분 제품 키가있다.

누군가가 내가이 시점에서 놓친 것을 볼 수 있습니까? 다른 문제 해결 단계를 수행한 후 다시 돌아가지만 답이 이 스크린샷에 있다고 말하기에 충분합니다.

내 생각은 지금 어떤 이유로, 키가 깨진, 그래서 나는 현재 키를 제거하는 스위치를 사용합니다 /upk . 이는 키를 제거하는 데 효과적이지만 일반적으로 키를 제거하는 가장 좋은 방법은 아닙니다. 새 키를 가져오기 전에 서버를 다시 부팅해야 서버가 잘못된 상태로 남을 수 있나요? 나중에 문제 해결에서 /ipk 수행하는 스위치를 사용하면 기존 키를 덮어쓰고 더 안전한 경로를 사용할 수 있습니다.

자세한 라이선스 정보를 확인하기 위해 스위치를 다시 실행 /dlv 했습니다. 아쉽게도 유용한 정보를 제공하지 않았고 제품 키를 찾을 수 없습니다. 왜냐하면 방금 제거했기 때문에 키가 없기 때문입니다.

긴 샷이라고 생각했지만 알려진 KMS 서버(또는 Active Directory의 경우)에 대해 Windows를 활성화해야 하는 스위치를 시도 /ato 했습니다. 다시 말하지만, 제품을 찾을 수 없음 오류입니다.

다음 생각은 때때로 서비스를 중지하고 시작하는 것이 트릭을 한다는 것이었기 때문에 다음으로 시도했습니다. SPPSvc 서비스(Microsoft Software Protection Platform Service)를 중지하고 시작해야 합니다. 관리 명령 프롬프트에서 신뢰할 수 net stop 있는 명령과 net start 명령을 사용합니다. 처음에는 서비스가 실행되고 있지 않다는 것을 알았기 때문에 이것이 되어야 한다고 생각합니다.

그러나 서비스를 시작하고 Windows를 다시 활성화하려고 시도한 후에도 여전히 제품을 찾을 수 없음 오류가 발생합니다.

그런 다음 문제 서버 중 하나에서 애플리케이션 이벤트 로그를 살펴보았습니다. 0x8007007B 코드가 있는 라이선스 정품 인증, 이벤트 ID 8198과 관련된 오류가 발견되었습니다.

이 코드를 조회하는 동안 오류 코드가 파일 이름, 디렉터리 이름 또는 볼륨 레이블 구문이 올바르지 않음을 의미하는 문서를 발견했습니다. 이 문서에 설명된 방법을 읽으면 그 중 어느 누구도 상황에 맞지 않는 것 같았습니다. 명령을 실행했을 nslookup -type=all _vlmcs._tcp 때 기존 KMS 서버(여전히 환경에 많은 Windows 7 및 Server 2008 컴퓨터가 있으므로 이를 유지해야 함)뿐만 아니라 5개의 도메인 컨트롤러도 발견했습니다. 이는 DNS 문제가 아니고 문제가 다른 곳에 있음을 나타냅니다.

그래서 DNS가 괜찮은 것을 알고 있습니다. Active Directory가 KMS 정품 인증 원본으로 올바르게 구성됩니다. 실제 서버가 제대로 활성화되었습니다. 이것이 VM에만 문제가 될 수 있나요? 이 시점에서 흥미로운 측면 참고로, 내 고객은 다른 부서의 누군가가 12 개 이상의 가상 Windows Server 2016 머신을 구축하기로 결정했다는 것을 알려줍니다. 이제는 정품 인증되지 않을 다른 12개의 서버를 가지고 있다고 가정합니다. 그러나 이러한 서버는 정상적으로 활성화되었습니다.

글쎄, 나는이 괴물을 slmgr 활성화하는 방법을 알아 내기 위해 명령으로 돌아갔다. 이번에는 제품 키를 설치할 수 있는 스위치를 사용 /ipk 하겠습니다. 부록 A: KMS 클라이언트 설정 키로 이동하여 표준 버전의 Windows Server 2016 대한 적절한 키를 가져옵니다. 일부 서버는 데이터 센터이지만 먼저 이 서버를 수정해야 합니다.

스위치를 /ipk 사용하여 제품 키를 설치하고 Windows Server 2016 표준 키를 선택했습니다.

여기에서 데이터 센터 환경의 결과만 캡처했지만 동일했습니다. 스위치를 /ato 사용하여 활성화를 강제했습니다. 제품이 성공적으로 정품 인증되었다는 멋진 메시지가 표시됩니다.

스위치를 /dlv 다시 사용하면 이제 Active Directory에서 활성화된 것을 확인할 수 있습니다.

지금, 무엇이 잘못되었습니까? 설치된 키를 제거하고 이러한 일반 키를 추가하여 이러한 컴퓨터가 제대로 활성화되도록 해야 하는 이유는 무엇인가요? 다른 12개 정도의 컴퓨터가 문제 없이 활성화된 이유는 무엇인가요? 앞서 말했듯이, 나는 문제를 보는 초기 단계에서 뭔가 키를 놓쳤다. 나는 철저히 혼란스러웠기 때문에 초기 블로그에서 포스터에 손을 뻗었다. 포스터는 즉시 문제를 보고 내가 일찍 놓친 것을 이해하는 데 도움이되었습니다.

첫 번째 /dlv 스위치를 실행했을 때 설명에 키가 있었습니다. 설명은 Windows® 운영 체제, RETAIL 채널이었습니다. 나는 그것을 보고 소매 채널이 구입되었고 유효한 키라고 생각했다.

올바르게 활성화된 서버에서 스위치의 /dlv 출력을 살펴보면 이제 설명에 VOLUME_KMSCLIENT 채널이 표시됩니다. 이렇게 하면 실제로 볼륨 라이선스임을 알 수 있습니다.

그렇다면 소매 채널은 무엇을 의미할까요? 운영 체제를 설치하는 데 사용된 미디어가 MSDN ISO임을 의미합니다. 나는 고객에게 돌아가서 우연히 ISO가 네트워크 주위에 떠있는 두 번째 Windows Server 2016 있는지 물었다. 예, 네트워크에 또 다른 ISO가 있었고 다른 12 대의 컴퓨터를 만드는 데 사용되었습니다. 두 ISO를 비교했고 가상 서버를 빌드하기 위해 제공된 ISO는 실제로 MSDN ISO였습니다. 네트워크에서 MSDN ISO를 제거했으며 이제 모든 기존 서버가 활성화되었으며 향후 빌드에서 정품 인증이 실패하는 것에 대해 더 이상 걱정하지 않습니다.