MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. LPD s’arrête/crashe après les mises à jour de juillet 2024 (CVE‑2024‑38027) : KIR, correctif d’août et migration IPP

LPD s’arrête/crashe après les mises à jour de juillet 2024 (CVE‑2024‑38027) : KIR, correctif d’août et migration IPP

Windows Server

LPDSVC qui s’arrête après les mises à jour de juillet 2024 ? Voici un guide complet pour diagnostiquer, atténuer (KIR) et corriger définitivement le problème, puis préparer la sortie de LPR/LPD au profit d’IPP.

Sommaire

Vue d’ensemble de la question

Après l’installation des correctifs de sécurité du 9 juillet 2024 (Patch Tuesday), de nombreux environnements ont observé l’arrêt ou le crash du service LPDSVC — souvent dès le premier job d’impression LPR. Le comportement affecte principalement des serveurs Windows qui exposent une file LPD à des clients UNIX/Linux ou à des solutions tierces (SAP, suivi d’impression, etc.).

Le problème a été reconnu par l’éditeur comme une régression des mises à jour de juillet 2024 : « Printing jobs using LPD protocol might fail ». Les plateformes concernées et KB cumulatives de juillet 2024 sont :

  • Windows Server 2016 — KB 5040434
  • Windows Server 2019 — KB 5040430
  • Windows Server 2022 — KB 5040437

Le correctif officiel et définitif a été publié avec le Patch Tuesday du 13 août 2024. Voir la section « Correctif officiel » plus bas. Sources : notes « Release Health » et documentation « Known Issue Rollback » (Microsoft Learn, références non liées).

Impact, symptômes et périmètre

Environnements typiquement touchés

  • Serveurs d’impression Windows jouant le rôle de passerelle LPD vers des imprimantes réseau, utilisés par des clients UNIX/Linux via LPR.
  • Intégrations d’applications (par ex. SAP, systèmes industriels, solutions d’audit/billing d’impression) qui s’appuient sur LPR/LPD.
  • Infrastructures où LPR/LPD a été conservé pour compatibilité historique malgré sa dépréciation et les recommandations de migration vers IPP.

Symptômes observés

  • Arrêt du service LPDSVC après le premier ou les premiers jobs LPR ; reprise manuelle ou automatique possible, puis nouvel arrêt.
  • Échecs côté client : time-out, message « lpr: error – connection broken », ou statut « impossible d’envoyer au serveur LPD ».
  • Journaux d’événements système :
    • Service Control Manager : événements d’arrêt inattendu (7031/7034) ciblant LPDSVC.
    • Éventuellement Application Error (1000) si le crash est intercepté, mentionnant svchost.exe hébergeant LPDSVC.

Comment confirmer rapidement que vous êtes concerné

  1. Vérifiez la présence des KB de juillet 2024 sur le serveur : Get-HotFix -Id KB5040434,KB5040430,KB5040437 2>$null | Format-Table -Auto
  2. Contrôlez l’état du service : Get-Service -Name LPDSVC | Format-List Name,Status,StartType
  3. Inspectez les événements récents liés à LPDSVC : Get-WinEvent -LogName System | Where-Object { $_.ProviderName -eq 'Service Control Manager' -and ($_.Id -in 7031,7034) } | Select-Object TimeCreated, Id, LevelDisplayName, Message | Sort-Object TimeCreated -Descending | Select-Object -First 20
  4. Reproduisez avec un job LPR de test (depuis un client Linux/UNIX ou un poste Windows équipé de l’outil lpr), puis observez si LPDSVC s’arrête.

Solutions de contournement (temporaire)

Plusieurs approches ont été employées par les administrateurs avant la parution du correctif définitif. Elles restent utiles pour : a) stabiliser rapidement en prod ; b) servir de plan B si un rollback ciblé est nécessaire.

Désinstaller la cumulative de juillet et bloquer sa réinstallation

Objectif : revenir au comportement antérieur et prévenir la réinstallation automatique le temps d’appliquer le correctif d’août ou supérieur.

Commandes locales (élévation requise) :

:: Désinstaller la KB ciblée (remplacer par le KB de l’OS)
wusa /uninstall /kb:5040430 /quiet /norestart

\:: Ou via DISM (afficher puis supprimer le package)
dism /online /get-packages | findstr Rollup
dism /online /remove-package /packagename\:Package\_for\_RollupFix~~31bf3856ad364e35~~amd64\~\~10.0.x.y /norestart

Gestion centralisée : sur WSUS, Decline la KB ; sur Intune / Windows Update for Business, pause l’anneau concerné ou applique une safeguard hold selon la politique interne. Documentez l’écart de patching.

Known Issue Rollback (KIR) par stratégie de groupe

Objectif : activer le « rollback » fourni par l’éditeur sans désinstaller la cumulative, via une GPO issue d’un package KIR spécifique à l’OS.

  1. Installer le package KIR correspondant sur un contrôleur de domaine ou poste d’admin (il ajoute un modèle ADMX/ADML « Known Issue Rollback »).
  2. Créer une nouvelle GPO, chemin : Configuration ordinateur → Modèles d’administration → Known Issue Rollback (libellé spécifique au KB).
  3. Positionner le paramètre sur « Désactivé » : paradoxal mais attendu — « Désactivé » active le rollback.
  4. Lier la GPO à l’OU des serveurs affectés, gpupdate /force, puis redémarrer le serveur.
  5. Validation : gpresult /r ou RSOP.msc montre l’application de la GPO ; la stabilité de LPDSVC revient immédiatement après redémarrage si le rollback est actif.

Important : un KIR est temporaire. Il n’est plus requis (et doit être retiré) dès que la cumulative corrigée est déployée.

Rendre le service plus résilient en attendant (Recovery)

Pour limiter l’impact utilisateur pendant l’investigation ou la fenêtre de déploiement :

  1. Ouvrir services.msc → LPDSVC → onglet Récupération.
  2. Définir Premier échec, Deuxième échec et Échecs suivants sur Redémarrer le service avec un délai de 1 minute.
  3. Cocher « Autoriser les actions pour les arrêts comportant des erreurs ».

Automatisation PowerShell/SC :

:: Traiter les arrêts non « crash » comme des échecs
sc.exe failureflag LPDSVC 1

\:: Redémarrer le service à 1 min sur 3 échecs, remise à zéro du compteur après 24 h
sc.exe failure LPDSVC reset= 86400 actions= restart/60000/restart/60000/restart/60000

\:: Vérifier la configuration de récupération
sc.exe qfailure LPDSVC

À éviter absolument

  • Ne pas remplacer manuellement lpdsvc.dll par une version antérieure : cela brise l’intégrité système (catalogues, signature), empêche les mises à jour et ajoute un risque de sécurité élevé.

Correctif officiel (définitif)

Le dysfonctionnement LPD a été corrigé dans les cumulative updates de août 2024 (13 août 2024). Installez au minimum ces versions, ou toute cumulative ultérieure :

SystèmeKB (août 2024)Statut
Windows Server 2016KB5041773LPD « might fail » : Résolu (Release Health).
Windows Server 2019KB5041578LPD « might fail » : Résolu (Release Health).
Windows Server 2022KB5041160LPD « might fail » : Résolu (Release Health).

Action recommandée :
1) Déployez la cumulative d’août 2024 (ou plus récente) sur tous les serveurs impactés.
2) Supprimez les KIR et GPO temporaires après validation.
3) Rétablissez une configuration de récupération « normale » du service si vous aviez renforcé les redémarrages automatiques uniquement pour mitigation.

Références : notes Release Health Windows Server 2016, 2019 et 2022 (Microsoft Learn, non liées ici).

Procédure de déploiement sûre (pas à pas)

  1. Inventaire : identifiez précisément les serveurs exposant LPD et les KB installées. $servers = @('srv-impr-01','srv-impr-02') # À adapter $kbs = @('KB5040434','KB5040430','KB5040437') # Juillet 2024 $fixKbs = @('KB5041773','KB5041578','KB5041160') # Août 2024 Invoke-Command -ComputerName \$servers -ScriptBlock { \$svc = Get-Service -Name LPDSVC -ErrorAction SilentlyContinue \$hot = Get-HotFix 2>\$null \[pscustomobject]@{ ComputerName = \$env\:COMPUTERNAME LPD\_Status = if(\$svc) { \$svc.Status } else { 'NotInstalled' } KB\_July = (\$hot | Where-Object {\$*.HotFixID -in \$using\:kbs}).HotFixID -join ',' KB\_August = (\$hot | Where-Object {\$*.HotFixID -in \$using\:fixKbs}).HotFixID -join ',' } } | Format-Table -Auto
  2. Lab/Pilote : installez la cumulative d’août (ou supérieure) sur un serveur de test avec charge LPR représentative, puis validez la stabilité pendant un cycle complet (pics et heures creuses).
  3. Plan de déploiement : utilisez des anneaux (Pilote → Vague 1 → Vague 2). Sur WSUS, approuvez la cumulative corrective ; sur Intune/WUfB, configurez les anneaux ou les deadlines appropriées.
  4. Migration des contournements :
    • Si vous aviez d-désinstallé la cumulative de juillet : réinstallez directement la cumulative d’août (ou ultérieure).
    • Si vous aviez appliqué un KIR : laissez la GPO active jusqu’au redémarrage post-correctif, puis retirez-la.
  5. Validation :
    • Scénarios LPR réels (depuis chaque application/plateforme critique).
    • Surveillance des journaux (Service Control Manager 7031/7034 : absence d’événements récents visant LPDSVC).
    • Vérification des files et du débit pendant une plage étendue.
  6. Nettoyage : suppression des GPO KIR, retour à une politique de récupération standard, documentation du changement et fermeture de l’incident.

Bonnes pratiques d’exploitation et de durcissement

Planifier la sortie de LPR/LPD

LPR/LPD est déprécié. Lorsque c’est possible, adoptez :

  • IPP (Internet Printing Protocol) côté clients UNIX/Linux et solutions modernes (CUPS, etc.).
  • Windows Standard TCP/IP Port Monitor côté clients Windows en direct vers les imprimantes réseau, ou IPP Everywhere si supporté.

Avantages : chiffrement et authentification possibles, meilleures capacités de diagnostic, moins de dépendances héritées.

Concevoir pour l’observabilité

  • Activez des compteurs de performance (spouleur, files d’impression, latences réseau) et une journalisation exploitable (SIEM, alertes sur 7031/7034 ciblant LPDSVC).
  • Mettez en place des synthetics LPR/IPP (jobs de test horaires) pour détecter les régressions immédiatement après un patch.
  • Segmentez les rôles : évitez d’agréger LPD, spouleur et services tiers sur un même hôte lorsque le volume est important.

Gouvernance des mises à jour

  • Implémentez des anneaux de déploiement (Pilote → Production) et des critères de go/no-go basés sur des métriques (taux d’échec, événements critiques, saturation CPU/IO).
  • Documentez les KIR appliqués, leur périmètre et leur date d’expiration. Nettoyez-les systématiquement après correction.

FAQ (points de friction fréquents)

Pourquoi régler la GPO KIR sur « Désactivé » ?

Le paramètre exposé par le modèle KIR inverse la logique : l’état « Désactivé » active le rollback. C’est le comportement attendu et documenté par l’éditeur.

Un redémarrage est-il obligatoire après application du KIR ?

Oui, il est recommandé pour garantir que le composant rollbacké est chargé et que le service LPDSVC démarre sur une base saine.

Le problème réapparaît après avoir installé la cumulative d’août 2024

Vérifiez que vous avez bien installé la KB corrective minimale (ou une cumulative plus récente) pour la version de l’OS et que l’hôte a été redémarré. Contrôlez que d’anciennes GPO KIR n’imposent plus de rollback. En cas de persistance, reproduisez avec un job de test, collectez System et Application et comparez les versions binaires chargées au démarrage.

Est-il risqué de désinstaller une cumulative de sécurité ?

Oui : cela réouvre les failles corrigées en juillet 2024. Si vous utilisez cette option, limitez la fenêtre d’exposition, appliquez des compensating controls (filtrage réseau, durcissement des serveurs d’impression) et planifiez l’installation de la cumulative corrective dès validation.

Remplacer manuellement lpdsvc.dll est-il une bonne idée ?

Non. Cela brise la cohérence du système, peut empêcher l’installation de mises à jour et n’est pas supporté. Préférez KIR ou la cumulative corrective.

Playbooks & scripts utiles

1) Détection de parc : serveurs impactés et état du service

$servers = Get-Content .\serveurs-lpd.txt  # un FQDN par ligne

\$report = foreach (\$s in \$servers) {
try {
\$svc = Invoke-Command -ComputerName \$s -ScriptBlock { Get-Service -Name LPDSVC -ErrorAction SilentlyContinue }
\$hot = Invoke-Command -ComputerName \$s -ScriptBlock { Get-HotFix 2>\$null }
\[pscustomobject]@{
Server     = \$s
LPD        = if(\$svc) { \$svc.Status } else { 'Non installé' }
KB\_Juillet = (\$hot | ? HotFixID -match '^KB50404(34|30|37)\$' | % HotFixID) -join ','
KB\_Aout    = (\$hot | ? HotFixID -match '^KB5041(773|578|160)\$' | % HotFixID) -join ','
}
} catch {
\[pscustomobject]@{ Server=\$s; LPD='Injoignable'; KB\_Juillet='?'; KB\_Aout='?' }
}
}
\$report | Sort-Object Server | Format-Table -Auto

# Export CSV pour suivi

\$report | Export-Csv .\etat-lpd.csv -NoTypeInformation -Encoding UTF8

2) Appliquer des règles de « Recovery » cohérentes (SC)

$servers = Get-Content .\serveurs-lpd.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
  sc.exe failureflag LPDSVC 1 | Out-Null
  sc.exe failure     LPDSVC reset= 86400 actions= restart/60000/restart/60000/restart/60000 | Out-Null
  sc.exe qfailure    LPDSVC
}

3) Désinstaller la cumulative de juillet (si et seulement si nécessaire)

$kb = 'KB5040430'  # Adapter à la version de l'OS
Invoke-Command -ComputerName (Get-Content .\serveurs-lpd.txt) -ScriptBlock {
  param($id)
  Start-Process -FilePath "wusa.exe" -ArgumentList "/uninstall /kb:$id /quiet /norestart" -Wait
  Write-Host "KB $id désinstallée (si présente). Redémarrage planifié séparément."
} -ArgumentList $kb

Méthode de test LPR avant/après correctif

  1. Choisir un fichier de test <100 Ko (ex. un fichier texte).
  2. Depuis un client Linux/UNIX : lpr -H <serveur-windows> -P <file-LPD> /etc/hosts
  3. Observer la réception côté serveur et l’état de LPDSVC (aucun arrêt attendu après correctif).
  4. Répéter avec 50–100 envois en rafale pour valider la résistance en charge : for i in $(seq 1 100); do lpr -H <serveur> -P <file> /etc/hosts; done

Stratégie de migration : sortir proprement de LPR/LPD

Pour réduire l’exposition aux régressions futures et moderniser l’impression :

  • IPP côté UNIX/Linux via CUPS : créez des files IPP vers vos imprimantes ou vers un serveur d’impression moderne sécurisé.
  • Clients Windows : privilégiez les ports Standard TCP/IP ou IPP Everywhere si disponible.
  • Sécurité : désactivez la fonctionnalité « Services d’impression LPD » sur les serveurs qui n’en ont plus l’usage, fermez le port 515/TCP et mettez à jour la documentation applicative.

Points d’attention opérationnels

  • Lorsque vous retirez un KIR, prévoyez un redémarrage pour revenir au code corrigé.
  • Surveillez vos tableaux de bord après patch : files d’attente, latence d’impression, erreurs par file et par application.
  • Maintenez un catalogue des dépendances (qui parle LPR ? où ? pourquoi ?) afin de prioriser la migration vers IPP.

Résumé exécutable

  • Symptôme : LPDSVC s’arrête/crashe après les mises à jour KB5040434/430/437 (juillet 2024). Régression LPD reconnue (Microsoft Learn).
  • Workarounds : désinstallation temporaire ; KIR + GPO (mettre la GPO sur « Désactivé » pour activer le rollback) ; règles de Recovery pour redémarrer automatiquement le service.
  • Fix définitif : installer la cumulative août 2024 ou plus récente (KB5041773/KB5041578/KB5041160 selon l’OS) puis retirer KIR/GPO temporaires.
  • À moyen terme : migrer loin de LPR/LPD (déprécié) vers IPP ou Standard Port Monitor selon les clients.

Annexe : matrice de décision rapide

SituationAction immédiateRisqueÉtape suivante
Prod instable, arrêt LPDSVC répétéAppliquer KIR via GPO (Désactivé), Recovery à 1 minFaible (rollback officiel)Déployer la cumulative août 2024+
Pas de KIR disponible immédiatementDésinstaller la cumulative de juillet 2024 et bloquerMoyen (exposition de sécurité)Installer la cumulative corrigée dès validation
Environnement stable et fenêtre de maintenanceInstaller directement la cumulative août 2024+FaibleRetirer KIR/GPO et normaliser Recovery
Vision long termePlan de migration vers IPPTrès faibleRetrait LPD, fermeture du port 515

Crédits et sources

Informations consolidées à partir des notes Release Health Windows Server 2016/2019/2022 et du guide Known Issue Rollback. Pour les détails officiels, consultez Microsoft Learn (aucun lien externe n’est inclus ici conformément aux exigences de publication).

Ce guide rassemble l’état de l’incident (LPD qui s’arrête/crashe après juillet 2024), les contournements éprouvés (KIR + GPO, désinstallation ciblée, durcissement Recovery), la résolution officielle d’août 2024 et la trajectoire de migration vers IPP. Il est conçu pour être directement exploitable en production, avec des scripts et des check-lists opérationnelles.

Windows Server
Windows Update Windows Server LPD LPR KIR KB5040430 Impression Patch Tuesday KB5040434 KB5040437
Sommaire