Résoudre les problèmes d’installation, de démarrage et d’authentification de SQL Server avec des gMSA

S’applique à : SQL Server sur Windows

Résumé

Cet article est le point d’entrée vers les défaillances liées à l’installation de SQL Server, à la mise à niveau, au démarrage des services, à SQL Server Agent, aux instances de cluster de basculement (FCI), à Kerberos, aux serveurs liés et aux groupes de disponibilité, qui se produisent lorsque les services SQL Server s’exécutent sous un compte de service administré de groupe (gMSA). La plupart de ces symptômes ont les mêmes causes sous-jacentes, qu’un gMSA soit impliqué ou non ; chaque article de scénario se concentre donc sur les vérifications spécifiques au gMSA et renvoie, pour tout le reste, à l’article canonique de dépannage.

Commencez par la liste de contrôle de validation rapide. Utilisez ensuite le chemin de résolution des problèmes correspondant à l’échec observé pour trouver l’article de scénario qui comporte les étapes de diagnostic et de résolution. Pour plus d’informations sur la sélection et la configuration des comptes de service pour SQL Server, y compris les comptes de service gérés et les gMSA, consultez Configurer Windows comptes de service et autorisations. Pour connaître la création et la gestion de gMSA dans Active Directory, consultez Gérer les comptes de service gérés par groupe.

Prerequisites

Important

Collectez des preuves avant de modifier les comptes de service, la stratégie de sécurité, les valeurs du Registre, les SPN ou les paramètres du cluster de basculement. Enregistrez le temps d’échec et le fuseau horaire du serveur. Exécutez les commandes de validation de l’hôte localement sur chaque serveur autonome concerné, nœud de cluster ou réplica, puis comparez les résultats. Remplacez l’exemple de compte, de service, d’instance et de noms de domaine par des valeurs de votre environnement.

Liste de contrôle pour une validation rapide

Exécutez ces vérifications sur chaque hôte concerné avant d’ouvrir un article spécifique au scénario. Pour un FCI ou un groupe de disponibilité, exécutez-les sur chaque nœud propriétaire possible ou sur chaque réplica, puis comparez les résultats.

  1. Vérifiez les identités de service configurées de SQL Server et de SQL Server Agent en examinant la valeur Log On As dans Gestionnaire de configuration SQL Server et la sortie SERVICE_START_NAME de sc.exe qc.

    Pour une instance par défaut, exécutez les commandes suivantes.

    sc.exe qc MSSQLSERVER
sc.exe qc SQLSERVERAGENT

    Résultat attendu :SERVICE_START_NAME identifie le gMSA prévu. Pour une instance nommée, utilisez MSSQL$<InstanceName> et SQLAgent$<InstanceName>. Remplacez par <InstanceName> le nom de l’instance.

  2. Vérifiez qu’Active Directory peut trouver le compte gMSA en exécutant Get-ADServiceAccount et en vérifiant que la commande renvoie le compte attendu.

    Exécutez la commande suivante dans une session PowerShell avec élévation de privilèges.

    Get-ADServiceAccount -Identity 'SQLgMSA' -Properties PrincipalsAllowedToRetrieveManagedPassword

    Résultat attendu :Get-ADServiceAccount retourne le compte prévu et répertorie l’hôte.

  3. Vérifiez que le compte d’ordinateur hôte, ou un groupe qui le contient, est répertorié dans PrincipalsAllowedToRetrieveManagedPassword.

  4. Testez la récupération du mot de passe depuis chaque hôte concerné ou tout nœud propriétaire potentiel en exécutant localement Test-ADServiceAccount et en confirmant qu’il renvoie True.

    Exécutez la commande suivante dans une session PowerShell avec élévation de privilèges.

    Test-ADServiceAccount -Identity 'SQLgMSA'

    Résultat attendu :Test-ADServiceAccount retourne True sur chaque hôte qui peut exécuter le service SQL Server.

  5. Vérifiez que Service Control Manager considère le compte de service comme géré en exécutant sc.exe qmanagedaccount pour le nom exact du service SQL Server ou SQL Server Agent et en vérifiant qu’il indique TRUE.

    Pour une instance par défaut, exécutez les commandes suivantes.

    sc.exe qmanagedaccount MSSQLSERVER
sc.exe qmanagedaccount SQLSERVERAGENT

    Résultat attendu :qmanagedaccount rapports TRUE.

  6. Vérifiez le DNS, la découverte du contrôleur de domaine, l’état du canal sécurisé et la synchronisation de l’heure.

    Exécutez les commandes suivantes. Remplacez contoso.com par le nom de domaine Active Directory.

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

    Résultat attendu : un contrôleur de domaine est découvert, le canal sécurisé réussit et l’état de temps est sain.

  7. Si SQL Server démarre, confirmez le schéma d’authentification actuel en interrogeant sys.dm_exec_connections à partir d’une session Windows distante authentifiée.

Pour obtenir des vérifications gMSA supplémentaires au niveau de l'hôte qui ne sont pas spécifiques à SQL Server, consultez Résoudre les problèmes de gMSA pour les conteneurs Windows.

Choisir un chemin de résolution des problèmes

Symptôme observé Reportez-vous à
Le programme d’installation rejette le gMSA ou ne peut pas le valider Résoudre les problèmes d’installation et de mise à niveau avec des gMSA
Le programme d’installation échoue avec 0x84BB0001 ou « Accès refusé » Le programme d’installation échoue avec l’erreur 0x84BB0001
Erreur 1069, ID d’événement 7041 ou ID d’événement 7038 Résoudre les échecs de démarrage de service avec des gMSA
Le service échoue uniquement pendant le démarrage Résoudre les échecs de démarrage de service avec des gMSA
IsManagedAccount ou qmanagedaccount est FALSE Résoudre les échecs de démarrage de service avec des gMSA
SQL Server Agent démarre, mais les travaux échouent Résoudre les problèmes d’échec des travaux de l’Agent SQL Server avec les gMSA
Échec de l’installation, de l’ajout de nœud, du démarrage ou du basculement de FCI Résoudre les problèmes liés aux échecs des instances de cluster de basculement avec les gMSA
Échec de secours NTLM, erreur SPN, LOGON ANONYME ou échec d’authentification du point de terminaison du groupe de disponibilité Résoudre les problèmes liés à Kerberos et aux échecs d’authentification avec des gMSA
Échec de la mise à niveau avec l’erreur 29569 SQL Server mise à niveau échoue avec l’erreur 29569

Collecter des données de diagnostic

Si la liste de contrôle de validation rapide et les vérifications spécifiques au scénario n’isolent pas la cause, collectez les données de diagnostic suivantes avant de poursuivre l’investigation ou d’ouvrir un cas de support. Rassemblez chaque artefact à partir du même intervalle d’échec afin que la preuve soit corrélée.

Collectez les éléments spécifiques à gMSA suivants sur chaque hôte, nœud ou réplique concerné :

  • Get-ADServiceAccount résultat, y compris PrincipalsAllowedToRetrieveManagedPassword.
  • Test-ADServiceAccount résultat.
  • sc.exe qc et sc.exe qmanagedaccount résultats pour les services SQL Server et SQL Server Agent.
  • nltest /dsgetdc, nltest /sc_verify et w32tm /query /status en sortie.
  • Attributions efficaces des droits utilisateur et gpresult sortie.
  • Propriété des SPN et vérification des doublons pour le gMSA.
  • Pour un FCI, le journal du cluster couvrant la transition de ressource.

Collectez les données de diagnostic standard SQL Server suivantes pour le même intervalle :

  • Journaux de configuration, y compris Detail.txt, Summary.txt et les journaux spécifiques aux fonctionnalités. Consultez Afficher et lire les fichiers journaux d’installation de SQL Server.
  • Journaux d’erreurs SQL Server actuels et archivés, journaux de SQL Server Agent et historique des tâches en échec.
  • Journaux d’événements système, d’application et de sécurité pertinents.

Pour la sélection d’outils et la collecte automatisée, consultez Résolution des problèmes et outils de diagnostic pour SQL Server. Vous pouvez utiliser SQL LogScout pour automatiser la collecte lorsqu’elle est appropriée pour l’examen.

Contenu connexe

  • Dernière mise à jour :