Résoudre les problèmes d’installation et de mise à niveau de SQL Server avec des gMSA

S’applique à : SQL Server sur Windows

Résumé

Cet article vous aide à résoudre les problèmes d'installation et de mise à niveau SQL Server qui se produisent lorsque le programme d'installation rejette ou ne peut pas valider un compte de service administré de groupe (gMSA) pour le service SQL Server ou SQL Server Agent. Il explique comment vérifier les entités de sécurité autorisées à récupérer le mot de passe géré, tester la récupération du mot de passe et résoudre les problèmes de réplication Active Directory, de DNS, de canal sécurisé et de synchronisation de l’heure.

Avant de commencer, consultez les prérequis et exécutez la liste de contrôle de validation rapide dans Résoudre les échecs de configuration, de démarrage et d’authentification de SQL Server avec des gMSA.

Symptoms

Le programme d’installation signale que le compte de service n’est pas valide ou que la validation de compte a échoué.
Le compte gMSA existe, mais le programme d’installation ne peut pas configurer SQL Server ou SQL Server Agent.
L’erreur survient lors de l’installation, de la réparation, de l’ajout de fonctionnalités, de l’ajout d’un nœud ou de la mise à niveau.

Cause

Le programme d’installation doit résoudre le compte et vérifier que l’hôte peut récupérer et utiliser son mot de passe managé. Les causes courantes incluent une réplication incomplète d’Active Directory, des entités de sécurité autorisées incorrectes ou des problèmes de connectivité au domaine.

Les échecs d’installation qui ne sont pas liés au compte de service ont des instructions distinctes. Avant de continuer, vérifiez à partir des journaux d’installation que le premier échec est un échec de validation de compte de service. Pour la résolution générale des échecs du programme d’installation, consultez Erreurs d’installation de SQL Server, et pour l’emplacement des journaux et leur structure, consultez Afficher et lire les fichiers journaux du programme d’installation de SQL Server.

Diagnostiquer les échecs d’installation et de mise à niveau de gMSA

Exécutez les commandes de liste de contrôle de validation rapide sur l’hôte concerné.
Vérifiez que le compte d’ordinateur hôte, ou un groupe autorisé, est répertorié dans PrincipalsAllowedToRetrieveManagedPassword.
Recherchez dans Detail.txt et Summary.txt le premier échec de validation du compte de service.

Résultat attendu :Get-ADServiceAccount retourne le compte prévu et les principaux autorisés, puis Test-ADServiceAccount retourne True.

Résoudre les échecs d’installation et de mise à niveau de gMSA

Utilisez la solution qui correspond à la condition que vous avez identifiée. Relancez l’installation uniquement après que Test-ADServiceAccount renvoie True sur l’hôte concerné.

Corriger les comptes autorisés à récupérer le mot de passe gMSA

À partir d’un ordinateur de gestion sur lequel le module PowerShell Active Directory est installé, passez en revue la configuration actuelle.

Get-ADServiceAccount -Identity 'SQLgMSA' `
  -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

Vérifiez que le compte d’ordinateur affecté SQL Server ou un groupe de sécurité qui contient ce compte d’ordinateur est répertorié. Si l'hôte SQL Server affecté ou un groupe de sécurité approuvé n'est pas répertorié, PrincipalsAllowedToRetrieveManagedPasswordmettez à jour la configuration gMSA via le processus de Active Directory approuvé de votre organisation :
- Si votre organisation gère les hôtes autorisés par le biais d’un groupe de sécurité Active Directory, avez un administrateur Active Directory ajouter le compte d’ordinateur concerné à ce groupe approuvé. Par exemple:
```
Add-ADGroupMember -Identity 'SQL-gMSA-Hosts' `
  -Members 'SQL01$'
```
- Si votre organisation autorise les principaux directement sur le compte gMSA, un administrateur Active Directory met à jour le compte gMSA avec la liste complète des principaux approuvés. Par exemple:
```
Set-ADServiceAccount -Identity 'SQLgMSA' `
  -PrincipalsAllowedToRetrieveManagedPassword `
  'CONTOSO\SQL-gMSA-Hosts'
```
  Avertissement
  
  La valeur PrincipalsAllowedToRetrieveManagedPassword est la liste complète des principaux autorisés. Avant d’utiliser Set-ADServiceAccount, examinez la valeur existante et incluez chaque principal qui doit conserver son autorisation. Ne supprimez pas involontairement d'autres hôtes ou nœuds de cluster SQL Server.
Si vous avez modifié une appartenance à un groupe de sécurité, actualisez l’appartenance au groupe de l’ordinateur concerné en fonction du processus de modification de votre organisation.
Sur chaque hôte qui peut exécuter SQL Server, vérifiez le résultat.
```
Get-ADServiceAccount -Identity 'SQLgMSA' `
  -Properties PrincipalsAllowedToRetrieveManagedPassword

Test-ADServiceAccount -Identity 'SQLgMSA'
```
Résultat attendu : le compte d’ordinateur ou le groupe approuvé prévu apparaît dans PrincipalsAllowedToRetrieveManagedPassword, et Test-ADServiceAccount retourne True.

Si vous souhaitez en savoir plus, consultez les articles suivants :

Résoudre les échecs de réplication d’annuaire, de DNS, de canal sécurisé ou de connectivité au contrôleur de domaine

Sur l’hôte SQL Server affecté, exécutez les vérifications suivantes à partir d’une session PowerShell avec élévation de privilèges. Remplacez contoso.com par le nom de domaine Active Directory.
```
Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.contoso.com' `
  -Type SRV
```
```
nltest /dsgetdc:contoso.com
nltest /sc_verify:contoso.com
w32tm /query /status
```
Corrigez la condition détectée par les vérifications :
- Si la résolution DNS ou la découverte du contrôleur de domaine échoue, corrigez la configuration du client DNS de l'hôte et vérifiez qu'elle utilise des serveurs DNS capables de résoudre le domaine Active Directory.
- Si nltest /sc_verify signale un échec du canal sécurisé, demandez à un administrateur Windows ou Active Directory de réparer le canal sécurisé de domaine de l’ordinateur en suivant la procédure approuvée par l’organisation.
- Si l’état de la synchronisation de l’heure n’est pas sain, corrigez la synchronisation de l’heure avant de refaire le test, car l’authentification Active Directory dépend d’une heure précise.
- Si la modification du principal autorisé n’est pas visible sur le contrôleur de domaine contacté par l’hôte SQL Server, demandez à un administrateur Active Directory de vérifier la réplication. Par exemple:
```
repadmin /replsummary
repadmin /showrepl *
```
  La réplication d’Active Directory dépend de la connectivité réseau, de la résolution de noms DNS, de l’authentification et de l’autorisation, de la précision de l’heure, de la base de données de l’annuaire et de la topologie de réplication. Utilisez repadmin /showrepl et repadmin /replsummary pour identifier les échecs de la réplication Active Directory.
Une fois la condition sous-jacente corrigée, réexécutez Test-ADServiceAccount.
```
Test-ADServiceAccount -Identity 'SQLgMSA'
```
Résultat attendu : un contrôleur de domaine est découvert, la vérification de canal sécurisé réussit, la synchronisation du temps est saine, la configuration gMSA est visible à partir du contrôleur de domaine contacté et Test-ADServiceAccount retourne True.

Collecter des données de diagnostic

Si le programme d’installation ne peut toujours pas valider le compte gMSA après avoir effectué ces étapes, collectez les données de diagnostic sur l’hôte concerné pendant la même période que celle de l’échec. Pour obtenir les données de preuve spécifiques à gMSA et les journaux d’activité de SQL Server standard à collecter, consultez Collecte des données de diagnostic dans la vue d’ensemble de la résolution des problèmes gMSA. Utilisez ces données pour poursuivre l’enquête ou ouvrir un cas de support.

Commentaires

Cette page a-t-elle été utile ?

Dernière mise à jour : 2026-10-01