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

최근에 Windows Server 2016을 자신의 환경에 배포하는 고객에게 도움을 주었습니다. 또한 이 기회를 통해 정품 인증 방법론을 KMS 서버에서 Active Directory 기반 정품 인증으로 마이그레이션했습니다.

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

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 . 제품을 찾을 수 없음 오류가 다시 발생했습니다.

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

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

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

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

그래서 DNS는 괜찮다는 것을 알고 있습니다. Active Directory는 KMS 정품 인증 원본으로 올바르게 구성되어 있습니다. 물리적 서버가 제대로 활성화되었습니다. VM만 관련된 문제일까요? 이 시점에서 흥미로운 측면으로, 다른 부서의 누군가가 12개 이상의 Windows Server 2016 가상 머신도 구축하기로 결정했다고 고객이 알려주는 것입니다. 그래서 지금 나는 그것을 처리하는 또 다른 다스 서버가 활성화되지 않습니다 가정합니다. 그러나 이러한 서버는 잘 활성화되었습니다.

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

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

여기서는 Datacenter 환경에서 발생한 결과만 수집했지만 결과는 동일했습니다. 스위치를 /ato 사용하여 활성화를 강제했습니다. 제품이 성공적으로 활성화되었다는 멋진 메시지가 표시됩니다.

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

이제, 무엇이 잘못되었을까요? 이러한 머신이 제대로 정품 인증되도록 설치된 키를 제거하고 이러한 일반 키를 추가하는 이유는 무엇일까요? 다른 12개 정도의 머신이 아무 문제 없이 정품 인증되는 이유는 무엇일까요? 앞에서 설명한 대로 문제를 살펴보는 초기 단계에서 중요한 사항을 놓쳤습니다. 나는 철저히 혼란스러웠기 때문에 초기 블로그에서 포스터에 손을 뻗었다. 포스터는 즉시 문제를 보고 내가 일찍 놓친 것을 이해하는 데 도움이되었습니다.

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

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

그러면 이 RETAIL 채널은 무엇을 의미할까요? 이는 운영 체제를 설치하는 데 사용된 미디어가 MSDN ISO임을 의미합니다. 고객에게 돌아가서 어떤 기회에 두 번째 Windows Server 2016 ISO가 네트워크 주위에서 작동하고 있는지 물어보았습니다. 예, 다른 ISO가 네트워크에 있었고 다른 12개의 머신을 만드는 데 사용되었습니다. 두 개의 ISO를 비교했으며, 가상 서버를 구축하기 위해 저에게 제공된 것은 실제로 MSDN ISO였습니다. 네트워크에서 MSDN ISO를 제거했으며 이제 모든 기존 서버가 활성화되었으며 향후 빌드에서 활성화가 실패하는 것에 대해 더 이상 걱정할 필요가 없습니다.