MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Windows 2000 & SQL 2000 : perte d’accès par nom après migration de DC vers Windows Server 2019 (DNS/WINS, NetBIOS, correctifs)

Windows 2000 & SQL 2000 : perte d’accès par nom après migration de DC vers Windows Server 2019 (DNS/WINS, NetBIOS, correctifs)

Windows Server

Après migration du contrôleur de domaine vers Windows Server 2019, un serveur Windows 2000 avec SQL Server 2000 n’est plus résolu par son nom alors que l’IP répond. Ce guide terrain détaille un diagnostic pas‑à‑pas et des correctifs concrets pour rétablir la résolution et stabiliser les connexions SQL.

Sommaire

Vue d’ensemble

Scénario classique : la montée de niveau d’Active Directory (2019) durcit les paramètres DNS et retire souvent les briques héritées (WINS/NetBIOS). Résultat : la résolution par nom d’un serveur Windows 2000 (hébergeant SQL Server 2000) tombe en panne, alors que le ping sur l’IP répond toujours. Les applications pointant vers NOMSRV ou NOMSRV.domaine.local échouent, mais IP:PORT fonctionne.

Réponse courte : problème de résolution de noms (DNS / WINS / NetBIOS) introduit par la migration, plus qu’un souci réseau ou SQL. Windows 2000 dépend souvent de DNS dynamiques non sécurisés et/ou de WINS/NetBIOS que l’environnement 2019 n’expose plus par défaut.

Pourquoi « nom KO / IP OK » après migration ?

  • DNS AD 2019 en mises à jour « sécurisées uniquement » : Windows 2000 ne s’y enregistre pas automatiquement. L’enregistrement A (et PTR) peut manquer ou être obsolète.
  • Disparition de WINS/NetBIOS : si l’appli passait par Named Pipes / NetBIOS, la résolution NetBIOS (WINS ou diffusion) n’existe plus ou n’est plus routée.
  • Clients mal configurés : postes/développements pointant vers un DNS non‑AD (routeur/FAI), suffixe DNS absent, caches périmés.
  • SQL 2000 en port dynamique : si la résolution SSRP (UDP 1434) ou le nom ne répond plus, l’auto‑découverte d’instance nommée échoue.

Arbre décisionnel express

SymptômeCause la plus probableAction immédiate
ping IP OK, ping NOM KOEnregistrement DNS manquant ou erronéCréer A/PTR statiques dans DNS AD 2019
nslookup NOM renvoie « Non-existent domain »Zone DNS sans l’hôte Windows 2000Ajouter A/PTR, purger caches
nbtstat -a NOM KO / Named Pipes utilisésWINS/NetBIOS absentsActiver WINS (temporaire) ou fichier lmhosts
Connexion SQL par IP:PORT OK mais par NOM KORésolution de nom casséeAlias client NOM → IP,PORT + correction DNS

Vérifications rapides (5–10 min)

Depuis un client

nslookup NOMSRV
ping NOMSRV
ping NOMSRV.domaine.local
nbtstat -a NOMSRV     (si l’application s’appuie sur NetBIOS/Named Pipes)
ipconfig /all         (DNS doit pointer vers les DNS AD 2019)
  • Attendu : nslookup retourne l’IP du Windows 2000. ping NOMSRV et ping NOMSRV.domaine.local répondent sur la bonne IP.
  • Indice : si ipconfig /all affiche un DNS externe ou un routeur, c’est probablement la cause.

Sur le DNS AD (2019)

  • Vérifier la présence d’un enregistrement A pour NOMSRV et d’un PTR dans la zone inverse.
  • Si la zone est en « Mises à jour dynamiques : sécurisées uniquement », Windows 2000 ne s’enregistrera pas tout seul.

Sur le serveur Windows 2000

  • Contrôler le suffixe DNS principal (doit correspondre au domaine).
  • Purger/forcer l’enregistrement si la zone le permet : ipconfig /flushdns ipconfig /registerdns
  • La carte réseau doit pointer vers le DNS AD (pas vers le routeur).

Correctifs concrets (par ordre d’impact/risque)

1) Corriger DNS (recommandé, immédiat)

  1. Créer manuellement l’hôte dans DNS AD 2019 :
    • Enregistrement A : NOMSRV.domaine.local → 192.168.x.y
    • PTR : créer ou cocher « Créer l’enregistrement de pointeur associé (PTR) »
  2. Ajouter un CNAME stable pour l’application (ex. : sql-legacy → NOMSRV.domaine.local) et mettre à jour les chaînes de connexion pour viser ce CNAME.
  3. Forcer l’usage des DNS AD sur tous les clients :
    • DHCP : Option 006 (serveurs DNS) = vos DC/DNS 2019; Option 015 (nom de domaine DNS).
    • Postes statiques : carte réseau → DNS AD uniquement.
  4. Nettoyer les caches des clients : ipconfig /flushdns

Astuce PowerShell (sur un DC/DNS 2019)

# Ajout A + PTR
Add-DnsServerResourceRecordA -ZoneName "domaine.local" -Name "NOMSRV" -IPv4Address 192.168.x.y -CreatePtr

# Alias convivial

Add-DnsServerResourceRecordCName -ZoneName "domaine.local" -Name "sql-legacy" -HostNameAlias "NOMSRV.domaine.local" </code></pre>

</div>

<h3>2) Si l’application dépend de NetBIOS/WINS</h3>
<p>Beaucoup d’applications SQL&nbsp;2000 utilisaient <em>Named Pipes</em> (NetBIOS). Sans WINS, un nom court comme <code>NOMSRV</code> ne se résout plus en dehors du sous‑réseau ou si la diffusion est bloquée.</p>
<ol>
  <li><strong>Déployer/activer un WINS</strong> (fonctionnalité héritée) et y <strong>créer une entrée statique</strong> pour <code>NOMSRV</code>.</li>
  <li><strong>Publier WINS via DHCP</strong>&nbsp;: Option&nbsp;044 (serveurs WINS/NBNS) et Option&nbsp;046 (type de nœud) — recommander <strong>H‑node (0x8)</strong>.</li>
  <li><strong>Configurer WINS</strong> sur le serveur&nbsp;2000 et les clients, puis rafraîchir&nbsp;:
    <pre><code>nbtstat -RR

Alternative quick‑fix et ciblée (limiter aux postes critiques) :

  • C:\Windows\System32\drivers\etc\hosts  →  192.168.x.y&nbsp;&nbsp;NOMSRV
  • C:\Windows\System32\drivers\etc\lmhosts  (pour NetBIOS) : 192.168.x.y NOMSRV #PRE #DOM:domaine

3) Côté SQL Server 2000 : stabiliser protocole et port

  1. Ouvrir SQL Server Network Utility (outil SQL 2000) sur le serveur.
  2. Activer TCP/IP et fixer un port statique (ex. 1433) sur l’instance (surtout si c’est l’instance par défaut).
  3. Adapter les connexions clientes :
    • TCP forcé : tcp:NOMSRV,1433 ou NOMSRV,1433
    • Instance nommée/dynamique : s’assurer que UDP 1434 (SSRP) passe entre client et serveur.
  4. En dernier recours, créer un alias client mappant NOMSRV → IP,PORT (cliconfg.exe sur les postes, onglet Alias).

Tests rapides de port/connexion

# Sur un poste moderne
Test-NetConnection NOMSRV -Port 1433
sqlcmd -S tcp:NOMSRV,1433 -Q "SELECT @@VERSION"

# Sur un poste ancien

telnet NOMSRV 1433
osql -S tcp\:NOMSRV,1433 -E -Q "SELECT @@VERSION"

4) Paramètres de zone si vous tenez aux mises à jour automatiques

  1. Temporairement basculer la zone DNS en « Non sécurisées et sécurisées » pour laisser Windows 2000 s’enregistrer.
  2. Figer l’enregistrement du serveur en statique.
  3. Repasser la zone en « Sécurisées uniquement » après enregistrement.

Approfondir le diagnostic

Contrôles DNS côté serveur 2019

# Lister l’hôte
Get-DnsServerResourceRecord -ZoneName "domaine.local" -Name "NOMSRV"

# Vérifier la zone inverse (adapter le nom de zone)

Get-DnsServerResourceRecord -ZoneName "x.y.168.192.in-addr.arpa" -RRType PTR

Point d’attention : conflits d’IP (doublon ARP) ou ancien enregistrement obsolète référant à une vieille IP.

Sur Windows 2000 : état NetBIOS/DNS

nbtstat -n       # Noms NetBIOS locaux
nbtstat -c       # Cache NetBIOS
ipconfig /all    # Suffixe DNS, serveurs DNS &amp; WINS

Ordre de résolution typique

Les noms FQDN (hôte.domaine.local) passent par DNS. Les noms courts (NOMSRV) peuvent s’appuyer sur le suffix search list DNS et/ou NetBIOS. En environnement modernisé sans WINS ni diffusion, les noms courts se brisent à travers les sous‑réseaux.

Ports et flux à autoriser (à minima)

ServicePort/ProtocoleUsage
DNSTCP/UDP 53Résolution de noms
SQL Server (instance par défaut)TCP 1433Connexion TDS
SQL SSRP (instances nommées dynamiques)UDP 1434Découverte du port d’instance
SMB/NetBIOS (Named Pipes)TCP 445, TCP 139, UDP 137–138Nom NetBIOS et transport des Pipes

Sécurité & compatibilité (à lire avant tout assouplissement)

  • Ne réactivez pas globalement SMB1, NTLMv1 ou des suites TLS obsolètes. Si des dépendances existent pour Windows 2000, segmentez le serveur (VLAN/ACL), limitez l’exposition aux hôtes/ports strictement nécessaires, journalisez et surveillez.
  • Filtrage : autorisez uniquement client → SQL 2000 sur TCP 1433 (et UDP 1434 si requis), client → DNS sur 53, et client ↔ NOMSRV sur 139/445 uniquement si Named Pipes imposés.
  • Journalisation DNS côté DC et audit des échecs de connexion côté SQL pour détecter les résolutions erronées ou les tentatives hors périmètre.

Plan de sortie (fortement recommandé)

  1. Geler le nom d’accès : créer un CNAME permanent (ex. sql-legacy) et faire migrer toutes les connexions vers ce nom. Ainsi, la future bascule ne touchera pas les clients.
  2. Chemin de migration SQL réaliste :
    • Option upgrade : SQL 2000 → SQL 2008/2008 R2 (compatibilité niveau 80) → versions supportées (2019/2022).
    • Option extraction : BCP/SSIS vers une base cible récente, puis réécriture des objets incompatibles (text/ntext/image, anciens JOIN, etc.).
  3. Isolation jusqu’à extinction : garder Windows 2000 dans un segment à part, pas critique, avec contrôle d’accès strict et sauvegardes validées.

Procédure pas‑à‑pas recommandée

  1. Valider la résolution :
    • Sur un DC 2019 : créer A/PTR pour NOMSRV.
    • Sur un client : nslookup NOMSRV doit retourner l’IP correcte.
  2. Uniformiser la configuration client :
    • DHCP Option 006 et 015 = DNS AD 2019 et domaine correct.
    • ipconfig /flushdns sur les postes.
  3. Stabiliser SQL :
    • Forcer TCP et le port (1433) sur SQL 2000.
    • Tester sqlcmd -S tcp:NOMSRV,1433 (ou osql).
  4. Nom court requis ?  Ajouter WINS (temporaire) ou lmhosts ciblé. Publier WINS via DHCP 044/046.
  5. Mettre à jour l’application pour pointer vers sql-legacy.domaine.local (CNAME) ou vers tcp:sql-legacy,1433.

Exemples concrets

Chaînes de connexion robustes

Driver=SQL Server;Server=tcp:sql-legacy,1433;Database=MaBase;Trusted_Connection=Yes;

Pour les clients très anciens :

Provider=SQLOLEDB;Data Source=tcp:sql-legacy,1433;Initial Catalog=MaBase;Integrated Security=SSPI;

Alias client (cliconfg.exe)

  1. Ouvrir Client Network Utility (cliconfg.exe).
  2. Onglet Alias → Ajouter.
  3. Nom serveur : NOMSRV → Protocole : TCP/IP → Serveur : 192.168.x.y → Port : 1433.

Vérifier l’instance et le port directement

netstat -ano | find "1433"
# Rechercher l'écoute SQL (pid du service SQLServer)

FAQ rapide

Q : Pourquoi ping par nom échoue mais nslookup réussit ?
R : ping peut tester d’abord des noms courts/suffixes ou cache local, alors que nslookup interroge directement le DNS défini. Purgez ipconfig /flushdns et contrôlez les suffixes.

Q : Faut‑il réactiver SMB1/NTLMv1 ?
R : Évitez globalement. Isolez le serveur Windows 2000 et n’ouvrez que les ports requis.

Q : Peut‑on corriger côté SQL uniquement ?
R : Fixer le port et forcer tcp:NOM,PORT stabilise les connexions, mais corriger DNS reste nécessaire pour la pérennité.

Checklist de validation

  • nslookup NOMSRV → renvoie l’IP correcte (A/PTR présents).
  • Postes utilisent uniquement les DNS AD 2019 (DHCP 006/015).
  • ping NOMSRV et ping NOMSRV.domaine.local OK.
  • SQL 2000 écoute en TCP 1433 (ou port fixé) et test sqlcmd/osql OK.
  • Si NetBIOS indispensable : WINS opérationnel (ou lmhosts sur postes critiques) + nbtstat -RR.
  • CNAME sql-legacy en place, chaînes de connexion mises à jour.
  • Segmentation réseau appliquée, ports limités, journaux activés.

Résumé opérationnel

  • Symptôme : IP OK, nom KO ⇒ DNS/WINS post‑migration.
  • Correctif rapide : créer A/PTR statiques pour NOMSRV, forcer l’usage des DNS AD, purger les caches.
  • Si NetBIOS requis : WINS (ou lmhosts) + nbtstat -RR.
  • SQL 2000 : TCP activé, port fixe (1433), connexions tcp:nom,port, UDP 1434 si instance nommée.
  • Sécurité : segmenter, limiter les protocoles anciens, planifier la migration.

Annexes utiles

Comparatif de paramètres DNS de zone

ParamètreAvant (hérité)Après (2019)Impact Windows 2000Mesure de contournement
Mises à jour dynamiquesNon sécurisées et sécuriséesSécurisées uniquementW2K ne s’enregistre plusAjouter A/PTR manuels | fenêtre temporaire « non sécurisées »
NetBIOS/WINS intégrésParfois activésDésactivésRésolution noms courts casséeWINS temporaire ou lmhosts ciblé
Clients DNSDNS mixtes (FAI/routeur)Doivent viser DC/DNSRésolutions incohérentesDHCP Option 006/015, GPO réseau

Modèles de fichiers

hosts

192.168.10.25   NOMSRV
192.168.10.25   NOMSRV.domaine.local

lmhosts

# Fichier lmhosts (extraits)
192.168.10.25   NOMSRV    #PRE  #DOM:domaine
# Mettre à jour puis exécuter : nbtstat -RR

Commandes d’administration DNS (ligne de commande)

dnscmd /RecordAdd domaine.local NOMSRV A 192.168.10.25
dnscmd /RecordAdd 10.168.192.in-addr.arpa 25 PTR NOMSRV.domaine.local

DHCP : options pertinentes

OptionSignificationValeur recommandée
006Serveurs DNSIP des DC/DNS 2019
015Nom de domaine DNSdomaine.local
044Serveurs WINS/NBNSIP du serveur WINS (si utilisé)
046Type de nœud NetBIOS0x8 (H‑node)

Mises en garde finales

  • Les « Modes de compatibilité » sur Windows Server 2019 n’aident pas : SQL 2000 tourne sur Windows 2000, pas sur 2019.
  • Gardez un inventaire des dépendances (ODBC/OLE DB, pilotes, chaînes de connexion) et un plan de tests reproductible (scripts sqlcmd/osql).
  • Documentez la cartographie des ports et verrouillez‑la dans vos firewalls une fois validée.

En appliquant ces étapes — correction DNS (A/PTR/CNAME), réactivation maîtrisée de la résolution NetBIOS si nécessaire, stabilisation du port SQL et uniformisation des clients — vous rétablissez rapidement l’accès par nom tout en préparant une migration sécurisée hors des technologies héritées.

Windows Server
DNS troubleshooting Windows Server NetBIOS SQL Server 2000 WINS
Sommaire