SQL Server 2022 : service qui s’arrête après migration sur Windows Server 2019 — erreurs Named Pipes Provider (Error 40) et conflit de port, guide de dépannage complet

Après migration vers SQL Server 2022 sous Windows Server 2019, le service démarre puis s’arrête, avec erreurs Named Pipes Provider, Error 40 et conflit de port. Ce guide pas‑à‑pas détaille un diagnostic reproductible et des correctifs concrets pour remettre l’instance en service.

Sommaire

Contexte et symptômes observés

Cas réel : une application métier a été déplacée vers une nouvelle instance SQL Server 2022 (Windows Server 2019). À l’ouverture, le service MSSQLSERVER démarre puis s’arrête rapidement. Les journaux client et serveur indiquent des erreurs de connectivité, notamment :

Named Pipes Provider, error 40 – Could not open a connection avec codes 0/2.
Messages autour des ports TCP, de l’initialisation réseau ou de l’impossibilité d’écouter.

Mesures déjà tentées : compte de service membre Enterprise Admin, protocole TCP/IP activé, pare‑feu Windows désactivé temporairement sur les deux serveurs. Aucune remédiation technique n’a toutefois été proposée dans la discussion d’origine.

Pourquoi ce problème apparaît après une migration

Plusieurs facteurs peuvent provoquer l’arrêt immédiat d’une instance fraîchement migrée :

Collision de port : un autre service écoute déjà le port prévu (souvent 1433) ; SQL ne parvient pas à se lier à l’adresse.
Configuration réseau incohérente : ports dynamiques résiduels, Listen All mal paramétré, Named Pipes activé inutilement.
Chiffrement forcé mal configuré : Force Encryption activé sans certificat valide (onglet Certificate), entraînant des erreurs d’initialisation TLS (TDSSNIClient).
Paramètres de démarrage erronés : chemins -d/-l vers master/mastlog incorrects après déplacement des fichiers.
Droits ou accès disque insuffisants : le compte de service ne peut pas lire/écrire dans les répertoires DATA/LOG/ERRORLOG.
Nom d’instance et ports dynamiques : instance nommée sans SQL Browser actif, ou UDP 1434 bloqué.
Niveau de correctifs : bogues corrigés dans des Cumulative Updates récents de SQL Server 2022.

Check‑list prioritaire

Ouvrir l’ERRORLOG et relever les premiers messages d’arrêt.
Forcer un port TCP statique (par ex. 1433) et désactiver Named Pipes.
Contrôler les paramètres de démarrage (-d, -l, -e) et l’accès disque.
Tester la connectivité depuis le serveur applicatif (Test-NetConnection, sqlcmd).
Si besoin, démarrer en mode mono‑utilisateur pour corriger la configuration.
Installer le dernier Cumulative Update de SQL Server 2022 et mettre à jour les clients.

Tableau de correspondance symptômes → causes → correctifs

Symptôme	Cause probable	Preuve à rechercher	Correctif
Service démarre puis s’arrête	Port déjà occupé	`ERRORLOG` : TDSSNI/17182 ; `netstat` montre :1433 utilisé	Forcer un port statique libre, libérer le port ou modifier la configuration
Erreur 40 côté client	Instance injoignable (port, firewall, Browser)	Test réseau échoue, UDP 1434 filtré	Ouvrir/autoriser TCP 1433 ou port choisi ; activer SQL Browser si instance nommée
Erreurs TLS/TDSSNI au démarrage	Chiffrement forcé sans certificat valide	EventID 17182/17826, SCHANNEL dans Windows	Désactiver temporairement Force Encryption, réinstaller un certificat conforme
Erreur 17113/17120	Chemin master invalide, fichiers manquants	ERRORLOG signale échec d’ouverture de master.mdf	Corriger `-d`/`-l` dans les paramètres de démarrage ou restaurer les fichiers
Connexion locale ok, distante non	Firewall ou SPN/Kerberos	Connexion en NTLM ou échec du ticket Kerberos	Créer les SPN, ouvrir le port, ou forcer l’utilisation du port dans la chaîne de connexion

Diagnostic rapide dans l’ERRORLOG

Ouvrez ...\MSSQL\Log\ERRORLOG (ou via SQL Server Configuration Manager → SQL Server Services → clic droit → Propriétés → Chemin du ErrorLog) et recherchez :

17182/17826 : échec d’initialisation TDSSNIClient (ports/certificats).
17113/17120 : impossible d’ouvrir master/mastlog.
26023 : collision d’adresses IP ou de ports.
Stack dump au démarrage : installez un CU et vérifiez les extensions/trace flags.

Remédiations détaillées

Stabiliser la configuration réseau

Ouvrir SQL Server Configuration Manager → Protocoles pour l’instance concernée.
Désactiver Named Pipes (réduit la surface d’attaque et les confusions de résolution).
Dans TCP/IP → Propriétés → IP Addresses :
- Laisser Listen All sur Yes (recommandé) et configurer uniquement IPAll.
- Effacer TCP Dynamic Ports et saisir un TCP Port statique (ex. 1433).
Redémarrer le service SQL.
Vérifier qu’aucun autre processus n’écoute le port choisi : netstat -ano | find ":1433" Get-NetTCPConnection -LocalPort 1433 | Format-Table -Auto Si un PID occupe le port, identifier le processus : tasklist /FI "PID eq <PID>"

Gérer les instances nommées et SQL Browser

Pour une instance nommée, deux approches :

Port statique + chaîne de connexion avec port : <serveur>,14330 par exemple (aucun besoin de SQL Browser).
Ports dynamiques : lancer SQL Browser et autoriser UDP 1434 pour la résolution du port. Commandes : sc query sqlbrowser sc start sqlbrowser

Corriger chiffrement TLS et certificats

Si Force Encryption est sur Yes sans certificat serveur valide (CN=FQDN, EKU=Server Auth, clé privée exportable, dans l’ordinateur local), l’instance peut échouer au démarrage. Correctifs :

Dans Configuration Manager → Protocols, onglet Flags : basculer Force Encryption à No pour relancer l’instance.
Installer un certificat conforme dans le magasin Ordinateur et le sélectionner dans l’onglet Certificate du protocole SQL.
Redémarrer et rebasculer Force Encryption à Yes si requis.

En cas de blocage persistant, contrôler les journaux Schannel dans l’Observateur d’événements Windows.

Assainir le compte de service

Privilèges requis : Log on as a service, lecture/écriture sur les répertoires DATA/LOG/ERRORLOG, et idéalement Perform volume maintenance tasks pour l’initialisation instantanée des fichiers (performance).
Éviter d’utiliser un Enterprise Admin : privilégier le compte virtuel NT SERVICE\MSSQLSERVER (instance par défaut) ou un compte de service de domaine dédié à privilèges minimaux.
Tester avec le compte par défaut : si le service démarre, un problème d’autorisations ciblé est probable sur l’ancien compte.

Vérifier les paramètres de démarrage

Ouvrir SQL Server Configuration Manager → SQL Server Services → Propriétés → Startup Parameters et confirmer :

-d pointe vers master.mdf valide.
-l pointe vers mastlog.ldf valide.
-e pointe vers le répertoire ERRORLOG accessible.

Après migration, ces chemins sont parfois rompus (changement de lettres de lecteur ou de structure de dossiers).

Démarrage de secours

Deux modes utiles quand l’instance refuse de démarrer :

Mono‑utilisateur (réparer une configuration, ouvrir SSMS) : sqlservr.exe -m -s MSSQLSERVER Seul le premier client qui se connecte prend la main. Fermer SSMS si un outil agent s’accroche en boucle.
Configuration minimale (ignore la plupart des paramètres et des procédures au démarrage) : sqlservr.exe -f -s MSSQLSERVER

Pour les instances nommées, remplacez MSSQLSERVER par le nom d’instance exact.

Mettre à jour le moteur et les clients

Lancer SELECT @@VERSION; pour relever la build.
Installer le dernier CU de SQL Server 2022 correspondant à votre édition.
Mettre à jour les pilotes côté application (ODBC, OLE DB, ADO.NET) afin d’éviter des échecs de négociation TLS/ALPN ou des incompatibilités de protocole.

Batterie de tests de connectivité

Depuis le serveur applicatif :

# Test simple du port
Test-NetConnection <serveur> -Port 1433

# SQLCMD en authentification Windows

sqlcmd -S ,1433 -E -l 5 -Q "SELECT @@SERVERNAME, @@VERSION;"

# SQLCMD vers instance nommée via SQL Browser

sqlcmd -S <instance> -E -l 5

# Vérifier le port réellement ouvert par SQL dans l'ERRORLOG

type "C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ERRORLOG" | find "Server is listening"

Quand l’instance est nommée et le Browser indisponible, privilégiez la syntaxe <serveur>,<port> pour court‑circuiter la découverte UDP 1434.

Cas particuliers et pièges courants

Ports dynamiques orphelins : un ancien port dynamique peut rester dans IPAll → TCP Dynamic Ports. Laisser cette valeur vide si vous forcez un port statique.
Écoute multi‑NIC : si plusieurs cartes réseau existent, validez que l’adresse choisie est Enabled et qu’aucune IP non routée n’est prioritaire.
Antivirus/EDR : exclure les dossiers DATA/LOG/TempDB/Backup et le processus sqlservr.exe pour éviter des locks au démarrage.
SPN/Kerberos : si le compte de service est un compte de domaine et que vous utilisez Kerberos, enregistrez les SPN : setspn -S MSSQLSvc/<FQDN>:1433 <DOMAINE\CompteService> setspn -S MSSQLSvc/<FQDN> <DOMAINE\CompteService> Un SPN manquant n’empêche pas le service de démarrer mais peut faire échouer l’authentification Kerberos.
Procédures de démarrage bloquantes : si des startup procs custom plantent, démarrez en -f (configuration minimale) ou avec le trace flag approprié pour ignorer leur exécution, puis corrigez le code.

Plan de retour en production rapide

Stabiliser le port : TCP 1433 statique, Named Pipes désactivé, redémarrage.
Valider l’écoute : netstat/Get-NetTCPConnection doivent montrer sqlservr.exe sur le port choisi.
Ouvrir le firewall : règle entrante TCP sur le port du moteur ; UDP 1434 si instance nommée + Browser.
Tester via sqlcmd depuis le serveur applicatif.
Corriger TLS si l’ERRORLOG cite TDSSNI/SChannel : désactiver temporairement Force Encryption, installer un certificat valide, réactiver.
Vérifier les paramètres -d/-l/-e et les autorisations NTFS.
Mettre à jour SQL Server et les clients.

Procédure guidée étape par étape

Étape 1 : ouvrir et lire l’ERRORLOG

Recherchez les premières erreurs fatales : ce sont les plus causales. Quelques motifs typiques :

TDSSNIClient initialization failed : conflit de port ou TLS.
FCB::Open failed sur master.mdf : chemins invalides.
Insufficient system memory to run this query dès le démarrage : contraintes mémoire, min server memory trop élevé, démarrage en -f pour corriger.

Étape 2 : forcer un port TCP et nettoyer la pile réseau

Désactivez Named Pipes et n’autorisez que TCP/IP.
Fixez un port statique dans IPAll (1433 ou un port libre) et videz TCP Dynamic Ports sur toutes les IP.
Redémarrez, puis validez l’écoute.

Étape 3 : vérifier l’accès du compte de service

Le compte doit lire/écrire les chemins DATA/LOG/ERRORLOG. En cas de doute, basculez temporairement sur NT SERVICE\MSSQLSERVER via Configuration Manager ; si l’instance démarre, ajustez les droits du compte d’origine.

Étape 4 : tester la connectivité de bout en bout

Test-NetConnection <serveur> -Port 1433
sqlcmd -S <serveur>,1433 -E -l 5 -Q "SELECT @@SERVERNAME;"

Si la connexion réussit en local mais échoue à distance : vérifier le firewall et, pour les instances nommées, l’état de SQL Browser (UDP 1434).

Étape 5 : démarrage en mode mono‑utilisateur

Utilisez‑le pour exécuter des corrections T‑SQL (ex. désactiver Force Encryption via sp_configure si vous y avez accès ou supprimer un startup proc). Rappelez‑vous : un seul client peut se connecter.

Étape 6 : mise à jour et validation finale

Installez le dernier CU disponible pour SQL Server 2022, puis vérifiez à nouveau l’ERRORLOG (Server is listening on <adresse>:1433). Testez avec l’application en spécifiant explicitement le port : Data Source=<serveur>,1433;...

Scripts et commandes utiles

Repérer rapidement les ports utilisés par SQL

Get-Process -Name sqlservr | Select-Object -ExpandProperty Id | `
  ForEach-Object { Get-NetTCPConnection -OwningProcess $_ }

Créer des règles firewall Windows

New-NetFirewallRule -DisplayName "SQL Server 1433 Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 1433 -Action Allow

New-NetFirewallRule -DisplayName "SQL Browser 1434 UDP Inbound" `
-Direction Inbound -Protocol UDP -LocalPort 1434 -Action Allow

Contrôler les paramètres de démarrage en registre (lecture seule, prudence) :

Get-ItemProperty `
"HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQLServer\Parameters"

Vérifier l’état du service et capturer un démarrage

sc query MSSQLSERVER
Start-Transcript -Path C:\Temp\sql_start_log.txt
net start MSSQLSERVER
Stop-Transcript

Bonnes pratiques post‑remise en service

Conserver TCP/IP seul si l’application ne requiert pas Named Pipes.
Documenter et standardiser le port statique par environnement.
Gérer les certificats TLS avec renouvellement automatique et surveillance de l’expiration.
Limiter les privilèges du compte de service et activer l’audit minimal.
Automatiser la vérification de l’ERRORLOG au démarrage et l’alerte sur erreurs 17182/17826/17113.

Questions fréquentes

Faut‑il désactiver le pare‑feu pour tester ?
Non. Préférez créer une règle entrante limitée au port SQL et aux sous‑réseaux autorisés. Désactiver globalement le pare‑feu masque des problèmes et dégrade la sécurité.

Pourquoi l’erreur 40 apparaît alors que le service s’arrête ?
Parce que le client tente de se connecter pendant que le moteur redémarre ou n’écoute pas le port attendu. L’erreur 40 est un symptôme ; la cause est à chercher dans l’ERRORLOG côté serveur.

Une instance peut‑elle écouter un port non standard ?
Oui. Fixez un port libre (ex. 14330) et adaptez la chaîne de connexion (serveur,14330). Pensez à la règle firewall correspondante.

Quand utiliser SQL Browser ?
Si vous conservez des ports dynamiques ou des instances multiples et que les clients se connectent via serveur\instance. Sinon, port statique + connexion explicite suffit et simplifie le réseau.

Exemple de déroulé complet

Arrêt/Redémarrage : le service s’arrête immédiatement.
Lecture ERRORLOG : 17182 au démarrage, TDSSNIClient et échec d’écoute sur 0.0.0.0:1433.
Configuration Manager : TCP/IP seul, Listen All=Yes, TCP Dynamic Ports vide, TCP Port=14330.
Firewall : création d’une règle TCP entrante 14330.
Validation : netstat montre sqlservr sur :14330.
Tests : sqlcmd -S serveur,14330 ok ; application reconfigurée sur serveur,14330.
Post‑mortem : port 1433 occupé par un outil de monitoring hérité. Remédiation : standardisation du port SQL et documentation.

Contournements en cas d’urgence

Restauration temporaire de la base applicative sur une instance SQL Server 2019 stable pour reprendre le service le temps de corriger la 2022.
Changement de port rapide (ex. 14330) pour contourner un conflit, puis retour à 1433 après résolution.

Résumé opératoire

Le triptyque gagnant est toujours le même : ERRORLOG (cause racine), port TCP statique (écoute garantie), tests de bout en bout (sqlcmd depuis le serveur applicatif). Ajoutez à cela un compte de service à privilèges maîtrisés et un certificat TLS valide, et l’instance SQL Server 2022 cessera de s’arrêter au démarrage.

SQL Server 2022 : service qui s’arrête après migration sur Windows Server 2019 — erreurs Named Pipes Provider (Error 40) et conflit de port, guide de dépannage complet