Rozwiązywanie problemów z klientami aktywacji opartej na usłudze Active Directory (ADBA), którzy nie aktywują

Uwaga 16.

Ten artykuł został pierwotnie opublikowany jako blog TechNet 26 marca 2018 r.

Ostatnio pomógłem klientowi w wdrażaniu systemu Windows Server 2016 w swoim środowisku. Skorzystaliśmy z tej okazji, aby przeprowadzić migrację metodologii aktywacji z serwera KMS do aktywacji opartej na usłudze Active Directory.

Jako właściwą procedurę wprowadzania wszystkich zmian rozpoczęliśmy migrację w środowisku testowym klienta. Rozpoczęliśmy wdrażanie, postępując zgodnie z instrukcjami w temacie Aktywacja oparta na usłudze Active Directory a usługa zarządzania kluczami s. Kontrolery domeny w środowisku testowym działały w systemie Windows Server 2012 R2, więc nie musieliśmy przygotowywać lasu. Rola została zainstalowana na kontrolerze domeny systemu Windows Server 2012 R2 i wybraliśmy opcję Aktywacja oparta na usłudze Active Directory jako metodę aktywacji zbiorczej. Zainstalowano klucz usługi KMS i nadaliśmy mu nazwę "Aktywacja usługi KMS AD (** LAB)." Krok po kroku po wpisie w blogu.

Rozpoczęliśmy od utworzenia czterech maszyn wirtualnych, dwóch systemów Windows 2016 Server Standard i dwóch windows 2016 Server Datacenter. W tym momencie wszystko było wspaniałe. Skompilowaliśmy serwer fizyczny z systemem Windows 2016 Server Standard i maszyna została prawidłowo aktywowana.

Szczerze mówiąc, konfiguracja i konfiguracja były bardzo proste, więc ta część była prosta i prosta. Jednak wszystkie maszyny wirtualne, które skompilowałem tydzień wcześniej, pokazały, że nie zostały aktywowane. Wróciłem do maszyny fizycznej i to było w porządku. Poszedłem do klienta, aby omówić, co się stało. Pierwsze pytanie brzmi: "Co zmieniło się w weekend?" A jak zwykle odpowiedź była "niczym". Tym razem nic się nie zmieniło i musieliśmy dowiedzieć się, co się dzieje.

Poszedłem do jednego z serwerów problemu, otworzyłem wiersz polecenia i sprawdziłem dane wyjściowe z slmgr /ao-list polecenia . Przełącznik /ao-list wyświetla wszystkie obiekty aktywacji w usłudze Active Directory.

Wyniki pokazują, że mamy dwa obiekty aktywacji: jeden dla systemu Windows Server 2012 R2 i nowo utworzoną aktywację usługi KMS AD (** LAB), która jest licencją systemu Windows Server 2016. Potwierdza to, że usługa Active Directory jest poprawnie skonfigurowana do aktywowania klientów usługi KMS systemu Windows.

Wiedząc, że slmgr polecenie jest do aktywacji licencji, kontynuowałem różne opcje. Próbowałem przełącznika /dlv , który wyświetli szczegółowe informacje o licencji. Wyglądało to dobrze, uruchomiono wersję standardową systemu Windows Server 2016, istnieje identyfikator aktywacji, identyfikator instalacji, adres URL weryfikacji, nawet częściowy klucz produktu.

Czy ktoś widzi to, czego przegapiłem w tym momencie? Wrócimy do niego po innych krokach rozwiązywania problemów, ale wystarczy powiedzieć, że odpowiedź znajduje się na tym zrzucie ekranu.

Myślę teraz, że z jakiegoś powodu klucz jest uszkodzony, więc używam /upk przełącznika, który odinstalowuje bieżący klucz. Chociaż było to skuteczne w usuwaniu klucza, zazwyczaj nie jest to najlepszy sposób, aby to zrobić. Czy serwer powinien zostać uruchomiony ponownie przed pobraniem nowego klucza, który może pozostawić serwer w złym stanie? Okazało się, że użycie przełącznika (co robię później w rozwiązywaniu /ipk problemów) zastępuje istniejący klucz i jest bezpieczniejszą trasą do podjęcia.

Ponownie uruchomiłem /dlv przełącznik, aby wyświetlić szczegółowe informacje o licencji. Niestety, to nie dało mi żadnych przydatnych informacji, tylko nie znaleziono klucza produktu. Ponieważ nie ma klucza, ponieważ właśnie go odinstalowałem.

Pomyślałem, że to długi strzał, ale próbowałem /ato przełącznika, który powinien aktywować system Windows na znanych serwerach KMS (lub Active Directory, jak to możliwe). Ponownie po prostu nie znaleziono błędu produktu.

Następna myśl polegała na tym, że czasami zatrzymywanie i uruchamianie usługi robi sztuczkę, więc próbowałem to dalej. Muszę zatrzymać i uruchomić usługę Microsoft Software Protection Platform Service (SPPSvc). W wierszu polecenia administracyjnego używam zaufania net stop i net start poleceń. Na początku zauważam, że usługa nie działa, więc myślę, że to musi być.

Jednak po uruchomieniu usługi i próbie ponownego aktywowania systemu Windows nadal występuje błąd nie znaleziono produktu.

Następnie spojrzałem na dziennik zdarzeń aplikacji na jednym z serwerów problemów. Widzę błąd związany z aktywacją licencji, identyfikatorem zdarzenia 8198, który zawiera kod 0x8007007B.

Podczas wyszukiwania tego kodu znalazłem artykuł z informacją o kodzie błędu oznacza, że nazwa pliku, nazwa katalogu lub składnia etykiety woluminu jest niepoprawna. Czytając metody opisane w artykule, nie wydawało się, że żaden z nich pasuje do sytuacji. Po uruchomieniu nslookup -type=all _vlmcs._tcp polecenia znalazłem istniejący serwer KMS (nadal wiele maszyn z systemem Windows 7 i Server 2008 w środowisku, więc konieczne było utrzymanie go w pobliżu), ale także pięciu kontrolerów domeny. Oznaczało to, że nie był to problem z systemem DNS, a problemy były gdzie indziej.

Więc wiem, ŻE DNS jest w porządku. Usługa Active Directory jest prawidłowo skonfigurowana jako źródło aktywacji usługi KMS. Serwer fizyczny został poprawnie aktywowany. Czy może to być problem z tylko maszynami wirtualnymi? Jako interesująca uwaga po stronie w tym momencie, mój klient informuje mnie, że ktoś w innym dziale postanowił zbudować ponad tuzin wirtualnych maszyn z systemem Windows Server 2016, jak również. Więc teraz zakładam, że mam jeszcze kilkanaście serwerów, aby poradzić sobie z tym nie będzie aktywowane. Jednak te serwery aktywowały się dobrze.

Cóż, udałem się z powrotem do slmgr polecenia, aby dowiedzieć się, jak aktywować te potwory. Tym razem użyję przełącznika /ipk , który umożliwi mi zainstalowanie klucza produktu. Poszedłem do dodatku A: Klucze instalacji klienta usługi KMS, aby uzyskać odpowiednie klucze dla standardowej wersji systemu Windows Server 2016. Niektóre serwery to Centrum danych, ale najpierw muszę rozwiązać ten problem.

Użyto przełącznika /ipk do zainstalowania klucza produktu, wybierając klucz systemu Windows Server 2016 Standard.

Stamtąd przechwyciłem tylko wyniki z moich środowisk centrum danych, ale były takie same. Użyłem przełącznika /ato , aby wymusić aktywację. Otrzymujemy niesamowity komunikat, że produkt został pomyślnie aktywowany.

Przy użyciu przełącznika /dlv zobaczymy, że teraz aktywowano nas przez usługę Active Directory.

Co poszło nie tak? Dlaczego musiałem usunąć zainstalowany klucz i dodać te klucze ogólne, aby te maszyny zostały prawidłowo aktywowane? Dlaczego pozostałe tuziny maszyn uaktywniły się bez problemów? Jak powiedziałem wcześniej, brakowało mi czegoś kluczowego na początkowych etapach patrzenia na tę kwestię. Byłem dokładnie zdezorientowany, więc skontaktował się z plakatem z początkowego bloga. Plakat widział problem od razu i pomógł mi zrozumieć, co przegapiłem na początku.

Po uruchomieniu pierwszego /dlv przełącznika w opisie był klucz. Opis to Windows® Operating System, RETAIL Channel. Spojrzałem na to i myślałem, że RETAIL Channel oznacza, że został zakupiony i był prawidłowym kluczem.

Gdy przyjrzymy się danych wyjściowych przełącznika /dlv z prawidłowo aktywowanego serwera, zwróć uwagę, że opis zawiera teraz kanał VOLUME_KMSCLIENT. Dzięki temu możemy wiedzieć, że jest to rzeczywiście licencja zbiorcza.

Co więc oznacza ten kanał HANDLU detalicznego? Oznacza to, że nośnik używany do instalowania systemu operacyjnego to ISO MSDN. Wróciłem do mojego klienta i zapytałem, czy z pewnymi szansami istnieje drugi system Windows Server 2016 ISO unoszący się wokół sieci. Okazuje się, że tak, w sieci był inny iso i został użyty do utworzenia innych tuzinów maszyn. Porównali dwa iso i na pewno wystarczająco dużo, który został mi przekazany do skompilowania serwerów wirtualnych był w rzeczywistości ISO MSDN. Usunęli ten plik ISO MSDN z sieci, a teraz wszystkie istniejące serwery zostały aktywowane i nie martwią się o niepowodzenie aktywacji w przyszłych kompilacjach.