NPS ne redémarre pas et affiche l’erreur 0x80020003 “Member not found” sur Windows Server 2012/2019 ? Voici une méthode éprouvée pour diagnostiquer, assainir et stabiliser votre service, même avec un grand volume de stratégies.
Vue d’ensemble
Sur certaines plateformes Windows Server (observé en 2012 et 2019), le service Network Policy Server (NPS) peut refuser de démarrer après un arrêt du service, malgré des vérifications classiques (redémarrage, correctifs, pare‑feu/NTP/AD/certificats, droits sur C:\Windows\System32\ias, SFC/DISM). Un signal faible mais récurrent : au‑delà d’environ 140 stratégies réseau, NPS commence à ignorer les nouvelles entrées puis finit par échouer au démarrage avec l’erreur 0x80020003.
Il n’existe aucun plafond officiel documenté sur le nombre de stratégies. Néanmoins, un volume élevé combiné à des incohérences de configuration (groupes AD introuvables, doublons, attributs manquants, conditions contradictoires) dégrade fortement les performances et peut conduire à un échec dès l’initialisation du service.
Symptômes et contexte
| Élément | Observation typique |
|---|---|
| Version OS | Windows Server 2012/2012 R2/2019 (souvent virtualisé) |
| Service | NPS (IAS), ne démarre pas ou se termine immédiatement |
| Message | 0x80020003 — Member not found (COM) |
| Seuil empirique | > ~140 stratégies réseau (policies) : apparition d’ignores, puis échec |
| Journalisation | Événements Network Policy and Access Services (source IAS) sans détail clair, ou silence anormal |
| Essais d’auto‑réparation | SFC/DISM, reboot, mises à jour : sans effet durable |
Ce que signifie vraiment l’erreur 0x80020003
0x80020003 est un code générique COM “Member not found”. Côté NPS, il surgit typiquement lors du chargement de la configuration : le service attend un élément (attribut, référence, objet) qui n’existe plus ou n’est pas valide (par exemple un groupe AD supprimé mais encore référencé dans une condition de stratégie). Avec un nombre élevé de stratégies, la probabilité de rencontrer une telle incohérence augmente, et le coût de validation au démarrage explose, jusqu’à rompre l’initialisation.
Hypothèse directrice : volume × incohérences
- Volume élevé : plus de règles à parser, évaluer, instancier. Les contrôles d’intégrité (groupes, attributs EAP/RADIUS) se multiplient.
- Incohérences : doublons, conditions incompatibles, groupes AD renommés/supprimés, secrets partagés divergents, attributs d’authentification manquants.
- Ordre de traitement sous‑optimal : règles générales au‑dessus de règles spécifiques, entraînant un parcours long et coûteux.
- Facteurs externes : latence DNS/AD, indisponibilité de CRL/OCSP (EAP‑TLS), surcharge CPU/IO.
Plan d’action recommandé (priorisé)
Confirmer rapidement le seuil problématique
- Désactiver par blocs des stratégies (par 20, puis 10, puis 5) pour repasser en‑dessous de ~140. Tenter le démarrage NPS à chaque itération.
- Procéder par dichotomie : isoler le bloc fautif qui fait basculer le service de “démarre” à “ne démarre plus”.
- Dans la console NPS, pousser en bas (ou désactiver) les règles les moins critiques pour accélérer le test.
Réduire et consolider
Objectif : moins de stratégies, plus expressives. Concentrez‑vous sur le regroupement de cas proches et l’élimination des redondances.
| Signal | Action de consolidation | Gain attendu |
|---|---|---|
| Multiples règles par SSID/site | Utiliser Client Friendly Name ou des plages IP client pour regrouper | Réduction du nombre de règles |
| Stratégies par groupe AD granulaire | Remonter d’un niveau (groupe parent), ou utiliser des conditions OU | Moins de vérifications AD |
| Conditions contradictoires | Supprimer les doublons, clarifier l’ordre spécifique > générique | Parcours plus court, logique lisible |
| Règles pour chaque type de port NAS | Regrouper via NAS Port Type combiné | Maintenance simplifiée |
Segmenter l’architecture
Plutôt qu’un NPS “tout‑en‑un” complexe, utilisez des Connection Request Policies (CRP) pour aiguiller le trafic vers plusieurs serveurs NPS plus simples :
| Modèle | Routage | Quand l’utiliser |
|---|---|---|
| Par périmètre | CRP redirige par NAS Identifier / SSID / IP vers NPS‑Site‑A / NPS‑Site‑B | Grandes organisations multi‑sites |
| Par fonction | CRP sépare 802.1X filaire / Wi‑Fi / VPN | Politiques et certificats distincts |
| Par sensibilité | CRP isole les flux “haute sécurité” (EAP‑TLS) vers un NPS dédié | Trajectoires auditables et durcies |
Assainir la configuration (export → audit → import)
Le cycle export → audit → import est la méthode la plus efficace pour retrouver un état propre.
Exporter (avec secrets)
netsh nps export filename="C:\Temp\nps.xml" exportPSK=YES
Ce qu’il faut auditer dans l’XML
- Doublons de stratégies (noms quasi identiques, mêmes conditions).
- Groupes AD introuvables : références à des groupes supprimés/renommés.
- Attributs RADIUS/EAP manquants ou mal typés (ex. EAP‑TLS sans chaîne complète).
- Conditions incompatibles ou jamais satisfaites (règles “mortes”).
- Secrets partagés incohérents entre clients RADIUS et NPS.
Outillez l’audit avec PowerShell
Exemple de script pour compter les stratégies, lister des références à des groupes AD et vérifier leur existence (module AD requis) :
# Exécuter en PowerShell avec RSAT AD (Import-Module ActiveDirectory)
[xml]$nps = Get-Content 'C:\Temp\nps.xml'
# 1) Compter les stratégies réseau et de demande de connexion
\$policyNodes = \$nps.SelectNodes('//Policy') # ajuster selon votre schéma d'export
Write-Host "Nombre total de noeuds \ :" \$policyNodes.Count
# 2) Heuristique : rechercher des conditions qui ressemblent à des références de groupes AD
# (selon versions, les références apparaissent en clair "DOMAIN\Groupe" ou par SID)
\$groupRefs = Select-String -Path 'C:\Temp\nps.xml' -Pattern '\\\\.+?\\' -AllMatches |
ForEach-Object { $\_.Matches.Value.Trim() } | Sort-Object -Unique
Write-Host "Groupes référencés (heuristique) : " \$groupRefs.Count
# 3) Vérifier l'existence des groupes
\$notFound = @()
foreach (\$g in \$groupRefs) {
try {
\$grp = Get-ADGroup -Identity \$g -ErrorAction Stop
} catch {
\$notFound += \$g
}
}
if (\$notFound.Count -gt 0) {
Write-Host "Groupes introuvables :" -ForegroundColor Yellow
\$notFound | ForEach-Object { Write-Host " - $\_" }
} else {
Write-Host "Tous les groupes référencés ont été trouvés dans AD."
} Remarques : l’export NPS évolue selon les versions ; adaptez les sélecteurs XPath/regex si nécessaire. L’objectif est d’attraper les incohérences criantes avant réimport.
Réinstaller le rôle NPS (facultatif mais propre)
Si la configuration est trop dégradée, une désinstallation/réinstallation du rôle peut assainir la pile :
# Élevé/administrateur
Uninstall-WindowsFeature NPAS
Install-WindowsFeature NPAS -IncludeManagementTools
Puis réimporter la configuration nettoyée :
netsh nps import filename="C:\Temp\nps.xml"
Vérifier les références externes critiques
- Active Directory : tous les groupes référencés existent et sont orthographiés de manière stable ; privilégiez des groupes globaux/universels bien gérés.
- Certificats : pour EAP‑TLS, vérifier la validité, les EKU, et la chaîne complète (autorités mères, CRL/OCSP accessibles).
- Clients RADIUS : cohérence des secrets partagés, des adresses IP et des noms conviviaux.
- DNS/NTP : résolution stable des contrôleurs de domaine, horloges synchronisées.
Observer et diagnostiquer
Activez le tracing pour voir où NPS cale :
netsh ras set tracing * enabled
Les journaux se trouvent sous %windir%\tracing. Pensez à désactiver ensuite :
netsh ras set tracing * disabled
Contrôlez également le service et les journaux :
sc query ias
wevtutil qe "Microsoft-Windows-NetworkPolicyAndAccessServices/Operational" /f:text /c:50
Compteurs utiles (PerfMon)
| Catégorie | Compteur | Interprétation |
|---|---|---|
| Network Policy Server / RADIUS | Access Requests/sec | Charge entrante ; corréler avec CPU/latences |
| Network Policy Server / RADIUS | Pending Requests | Accumulation = saturation ou back‑end lent |
| Network Policy Server / RADIUS | Dropped Packets | Pertes = délai d’expiration ou surcharge |
| System/Process | Processor %, Working Set | Repérer la pression CPU/RAM pendant le démarrage |
Procédures ciblées selon le stade de panne
NPS ne démarre pas du tout
- Réduire rapidement le périmètre : désactiver des lots de stratégies pour revenir < ~140 puis relancer.
- Exporter ce qui reste opérationnel :
netsh nps export .... - Auditer l’XML et corriger (doublons, groupes inexistants, attributs EAP incohérents).
- Réinstaller le rôle NPS si nécessaire, puis réimporter la config nettoyée.
- Redémarrer le service et valider le flux (authentifications de test, latence).
NPS démarre mais se comporte mal
- Réordonner les stratégies du plus spécifique au plus générique.
- Regrouper des conditions proches (NAS, SSID, groupes) pour réduire le volume.
- Vérifier l’accessibilité AD/PKI (tests
nltest,certutil -verify). - Évaluer une segmentation (CRP vers plusieurs NPS) si la consolidation atteint ses limites.
Modèles de consolidation : exemples concrets
Regrouper par Client Friendly Name
Au lieu d’une stratégie par point d’accès, utilisez des libellés cohérents (ex. WLC-Paris-*, WLC-Lyon-*) et une seule règle par site avec une condition de nom convivial par motif.
Mutualiser par type d’accès
Combinez les conditions NAS Port Type (Ethernet + Wireless) quand le traitement est identique (mêmes groupes AD et même méthode EAP), et séparez uniquement quand la logique diverge.
Regrouper des groupes AD
Remplacez plusieurs groupes très granulaires par un groupe parent si les droits sont équivalents côté NPS. Documentez ce regroupement dans la description du groupe AD.
Nettoyage avancé : détection des doublons et règles inatteignables
Sur grosses configurations, on voit souvent :
- Doublons : même jeu de conditions mais libellés différents ; créez une seule stratégie.
- Stratégies jamais évaluées : elles se trouvent en bas, masquées par des règles “attrape‑tout”.
- Contradictions : ex. un groupe AD exigé et exclu dans la même chaîne.
Heuristique PowerShell pour repérer des règles identiques (à adapter à votre schéma d’export) :
[xml]$nps = Get-Content 'C:\Temp\nps.xml'
$pols = $nps.SelectNodes('//Policy')
$hash = @{}
foreach ($p in $pols) {
# Construire une signature simple : concat des conditions triées
$conds = ($p.SelectNodes('.//Condition') | ForEach-Object { $_.OuterXml }) -join '|'
$sig = [System.BitConverter]::ToString((New-Object -TypeName System.Security.Cryptography.SHA1Managed).ComputeHash([Text.Encoding]::UTF8.GetBytes($conds)))
if ($hash.ContainsKey($sig)) { $hash[$sig] += ,$p } else { $hash[$sig] = @($p) }
}
$dups = $hash.GetEnumerator() | Where-Object { $_.Value.Count -gt 1 } | ForEach-Object { $_.Value }
"Groupes de stratégies potentiellement dupliquées : " + $dups.Count
Capacité, performance et montée en version
- Ressources : assurez‑vous que CPU/RAM/IO ne sont pas étriqués, surtout au moment du démarrage (pics de parsing).
- Scale‑out : au‑delà d’un certain volume, préférez plusieurs NPS simples et thématiques plutôt qu’un monolithe complexe.
- Haute disponibilité : configurez vos NAS/contrôleurs WLAN pour interroger un second NPS en secours (même configuration importée).
- Pipeline CI : versionnez l’XML d’export NPS (sans secrets) pour suivre l’historique et faciliter les rollbacks.
Checklist d’assainissement express
| Étape | But | Fait ? |
|---|---|---|
| Désactivation par blocs < 140 | Valider l’hypothèse volume/seuil | □ |
| Export XML avec secrets | Préparer l’audit | □ |
| Audit des groupes AD | Éliminer les références cassées | □ |
| Détection des doublons | Réduire le nombre de stratégies | □ |
| Réinstallation du rôle (si besoin) | Repartir d’une base saine | □ |
| Réimport de la config nettoyée | Rétablir le service | □ |
| Réordonnancement spécifique > générique | Optimiser l’évaluation | □ |
| Segmentations via CRP | Alléger chaque NPS | □ |
| Monitoring PerfMon + traces | Détecter les régressions | □ |
Questions fréquentes
Existe‑t‑il un nombre maximum de stratégies NPS ?
Aucune limite officielle publiée. En pratique, au‑delà d’un certain volume/complexité, la stabilité peut se dégrader. L’observation d’un palier près de 140 stratégies est cohérente avec des charges réelles.
Pourquoi SFC/DISM n’aident pas ?
Parce que le problème est majoritairement configurationnel (références invalides, logique contradictoire), pas un fichier système corrompu.
Faut‑il migrer vers Windows Server 2022 ?
Cela peut améliorer la robustesse globale, mais si la configuration reste lourde et incohérente, les symptômes reviendront. Priorité : réduction/segmentation/assainissement.
Comment cloner proprement la configuration sur un second NPS ?
Via netsh nps export sur la source et netsh nps import sur la cible (adapter certificats si EAP‑TLS). Conservez les secrets hors dépôt.
Étapes détaillées (récapitulatif opérationnel)
- Mesurer : compter les stratégies, repérer le palier d’échec (~140). Vérifier CPU/RAM/IO et l’ordre des règles.
- Réduire : fusionner des cas proches (NAS, groupes, SSID), supprimer doublons et règles mortes.
- Assainir : export XML, audit des groupes AD et attributs EAP/RADIUS, correction, import.
- Segmenter : CRP vers plusieurs NPS par site/fonction/sensibilité.
- Surveiller : activer les traces RAS ponctuellement, suivre PerfMon (Access Requests/sec, Pending Requests, Dropped Packets).
- Sécuriser : lettres de service entre équipes (référentiels groupes AD, naming des clients RADIUS), versionner la config.
Synthèse
Le refus de démarrer de NPS avec l’erreur 0x80020003 est généralement le symptôme d’une configuration volumineuse et hétérogène. Il n’existe pas de plafond officiel sur le nombre de stratégies, mais un seuil pratique peut se manifester autour de ~140 règles, surtout si des références AD ou EAP sont invalides. Les remèdes efficaces sont (1) réduction/consolidation des stratégies, (2) segmentation de l’architecture via des CRP vers plusieurs NPS, et (3) assainissement par export → audit → import. Les réparations génériques (SFC/DISM) ne traitent pas la cause racine si elle est dans la configuration. En appliquant ce plan, vous restaurerez un NPS stable, lisible et performant.