Rozwiązywanie problemów z instalacją, uruchamianiem i uwierzytelnianiem SQL Server przy użyciu kont gMSA

Dotyczy: SQL Server w Windows

Podsumowanie

Ten artykuł stanowi punkt wyjścia do rozwiązywania problemów związanych z instalacją programu SQL Server, jego uaktualnianiem, uruchamianiem usług, usługą SQL Server Agent, wystąpieniem klastra trybu failover (FCI), protokołem Kerberos, serwerem połączonym i grupą dostępności, które występują, gdy usługi SQL Server są uruchamiane przy użyciu grupowego konta usługi zarządzanej (gMSA). Większość z tych objawów ma te same podstawowe przyczyny, niezależnie od tego, czy używany jest obiekt gMSA, dlatego każdy artykuł dotyczący danego scenariusza zawiera tylko kontrole specyficzne dla gMSA i odsyła do głównego artykułu dotyczącego rozwiązywania problemów w pozostałym zakresie.

Zacznij od listy kontrolnej szybkiego sprawdzania poprawności. Następnie użyj ścieżki rozwiązywania problemów zgodnej z zaobserwowanym niepowodzeniem, aby znaleźć artykuł scenariusza zawierający kroki diagnostyki i rozwiązywania problemów. Aby uzyskać informacje na temat wybierania i konfigurowania kont usług dla SQL Server, w tym zarządzanych kont usług i kont gMSA, zobacz Konfigurowanie kont usług i uprawnień Windows. Aby uzyskać informacje o tworzeniu kont usług zarządzanych przez grupę i zarządzaniu nimi w usłudze Active Directory, zobacz Zarządzanie kontami usług zarządzanymi przez grupę.

Wymagania wstępne

Important

Zbierz informacje przed zmianą kont usług, zasad zabezpieczeń, wartości rejestru, identyfikatorów SPN lub ustawień klastra failover. Zarejestruj czas awarii i strefę czasową serwera. Uruchom lokalnie polecenia weryfikacji hosta na każdym objętym problemem serwerze samodzielnym, każdym węźle klastra lub każdej replice, a następnie porównaj wyniki. Zastąp przykładowe nazwy kont, usług, wystąpień i domen wartościami ze środowiska.

Lista kontrolna szybkiej weryfikacji

Uruchom te testy na każdym hoście, którego dotyczy problem, przed otwarciem artykułu specyficznego dla scenariusza. W przypadku klastra pracy awaryjnej (FCI) lub grupy dostępności uruchom je na każdym węźle, który może być właścicielem, lub na każdej replice i porównaj wyniki.

  1. Potwierdź skonfigurowane konta usług SQL Server i SQL Server Agent, sprawdzając wartość Log On As w SQL Server Configuration Manager oraz dane wyjściowe SERVICE_START_NAME z sc.exe qc.

    Dla domyślnej instancji uruchom następujące polecenia.

    sc.exe qc MSSQLSERVER
sc.exe qc SQLSERVERAGENT

    Oczekiwany wynik:SERVICE_START_NAME identyfikuje zamierzony gMSA. W przypadku nazwanego wystąpienia użyj elementów MSSQL$<InstanceName> i SQLAgent$<InstanceName>. Zastąp <InstanceName> nazwą wystąpienia.

  2. Upewnij się, że usługa Active Directory może odnaleźć konto gMSA, uruchamiając Get-ADServiceAccount i sprawdzając, czy zwraca ono właściwe konto.

    Uruchom następujące polecenie w sesji programu PowerShell z podwyższonym poziomem uprawnień.

    Get-ADServiceAccount -Identity 'SQLgMSA' -Properties PrincipalsAllowedToRetrieveManagedPassword

    Oczekiwany wynik:Get-ADServiceAccount Zwraca zamierzone konto i wyświetla listę hostów.

  3. Upewnij się, że konto komputera-hosta lub grupa, do której ono należy, jest wymienione w PrincipalsAllowedToRetrieveManagedPassword.

  4. Przetestuj pobieranie hasła na każdym hoście, którego dotyczy problem, lub na potencjalnym węźle właściciela, uruchamiając lokalnie Test-ADServiceAccount i potwierdzając, że zwraca True.

    Uruchom następujące polecenie w sesji programu PowerShell z podwyższonym poziomem uprawnień.

    Test-ADServiceAccount -Identity 'SQLgMSA'

    Oczekiwany wynik:Test-ADServiceAccount zwraca True wartość na każdym hoście, który może uruchomić usługę SQL Server.

  5. Potwierdź, że Menedżer kontroli usług traktuje konto usługi jako zarządzane, uruchamiając sc.exe qmanagedaccount dla dokładnej nazwy usługi SQL Server lub SQL Server Agent i sprawdzając, czy zgłasza TRUE.

    Dla domyślnej instancji uruchom następujące polecenia.

    sc.exe qmanagedaccount MSSQLSERVER
sc.exe qmanagedaccount SQLSERVERAGENT

    Oczekiwany wynik:qmanagedaccount raporty TRUE.

  6. Potwierdź konfigurację DNS, wykrywanie kontrolera domeny, stan bezpiecznego kanału i synchronizację czasu.

    Uruchom następujące polecenia. Zastąp ciąg contoso.com nazwą domeny Active Directory.

    nltest /dsgetdc:contoso.com
nltest /sc_verify:contoso.com
w32tm /query /status

    Oczekiwany wynik: kontroler domeny zostanie wykryty, ustanowienie bezpiecznego kanału zakończy się powodzeniem, a synchronizacja czasu działa prawidłowo.

  7. Jeśli SQL Server zostanie uruchomiony, potwierdź bieżący schemat uwierzytelniania, wysyłając sys.dm_exec_connections zapytanie z zdalnej sesji uwierzytelnionej Windows.

Aby uzyskać dodatkowe sprawdzenia gMSA na poziomie hosta, które nie są specyficzne dla programu SQL Server, zobacz Rozwiązywanie problemów z gMSA dla kontenerów Windows.

Wybieranie ścieżki rozwiązywania problemów

Obserwowany objaw Zapoznaj się z
Instalator odrzuca gMSA lub nie może go zweryfikować Rozwiązywanie problemów z błędami instalacji i uaktualniania za pomocą agentów gMSA
Instalacja nie powiedzie się z błędem 0x84BB0001 lub „Odmówiono dostępu” Instalacja kończy się niepowodzeniem z powodu błędu 0x84BB0001
Błąd 1069, identyfikator zdarzenia 7041 lub zdarzenie o identyfikatorze 7038 Rozwiązywanie problemów z błędami uruchamiania usługi przy użyciu gMSA
Usługa kończy się niepowodzeniem tylko podczas rozruchu Rozwiązywanie problemów z błędami uruchamiania usługi przy użyciu gMSA
IsManagedAccount lub qmanagedaccount jest FALSE Rozwiązywanie problemów z błędami uruchamiania usługi przy użyciu gMSA
SQL Server Agent uruchamia się, ale zadania kończą się niepowodzeniem Rozwiązywanie problemów z niepowodzeniami zadań SQL Server Agent przy użyciu kont gMSA
Konfigurowanie FCI, dodawanie węzła, uruchamianie lub przełączenie awaryjne kończy się niepowodzeniem Rozwiązywanie problemów z awariami wystąpień klastra pracy awaryjnej przy użyciu gMSA
Przełączenie awaryjne na NTLM, błąd SPN, ANONYMOUS LOGON lub błąd uwierzytelniania punktu końcowego grupy dostępności Rozwiązywanie problemów z błędami uwierzytelniania kerberos i gMSA
Uaktualnianie kończy się niepowodzeniem z powodu błędu 29569 uaktualnianie SQL Server kończy się niepowodzeniem z powodu błędu 29569

Zbieranie danych diagnostycznych

Jeśli lista kontrolna szybkiej weryfikacji i kontrole specyficzne dla danego scenariusza nie pozwalają ustalić przyczyny, przed kontynuowaniem analizy lub otwarciem zgłoszenia do pomocy technicznej zbierz następujące dane diagnostyczne. Zbierz każdy artefakt z tego samego interwału awarii, aby dowody korelowały.

Zbierz następujące informacje dotyczące gMSA z każdego hosta, węzła lub repliki objętych problemem:

  • Get-ADServiceAccount dane wyjściowe, w tym PrincipalsAllowedToRetrieveManagedPassword.
  • Test-ADServiceAccount wynik.
  • sc.exe qci sc.exe qmanagedaccount dane wyjściowe dla usług SQL Server i SQL Server Agent.
  • nltest /dsgetdc, nltest /sc_verifyi w32tm /query /status dane wyjściowe.
  • Skuteczne przypisania praw użytkownika i gpresult dane wyjściowe.
  • Własność SPN i sprawdzanie duplikatów dla gMSA.
  • Dla klastra trybu failover (FCI): dziennik klastra obejmujący przejście zasobu.

Zbierz następujące standardowe dane diagnostyczne SQL Server dla tego samego interwału:

  • Dzienniki konfiguracji, w tym Summary.txt, Detail.txt oraz dzienniki specyficzne dla funkcji. Zobacz Wyświetlanie i odczytywanie plików dziennika instalacji SQL Server.
  • Bieżące i zarchiwizowane dzienniki błędów SQL Server, dzienniki SQL Server Agent i historia zadań, które zakończyły się niepowodzeniem.
  • System, aplikacja i odpowiednie dzienniki zdarzeń zabezpieczeń.

Aby zapoznać się z wyborem narzędzi i automatyczną kolekcją, zobacz Rozwiązywanie problemów i narzędzia diagnostyczne dla SQL Server. Możesz użyć funkcji SQL LogScout , aby zautomatyzować zbieranie, gdy jest ona odpowiednia do badania.

Treści powiązane

  • Ostatnia aktualizacja o