BGInfo affiche encore « Server 2016 » après mise à niveau vers Windows Server 2022 : guide complet et automatisation

Après une mise à niveau in‑place de Windows Server 2016 vers 2022, BGInfo peut continuer à afficher l’ancienne version. Ce guide explique les causes, fournit deux méthodes robustes pour corriger l’anomalie (registre et WMI) et détaille l’automatisation à grande échelle.

Vue d’ensemble du problème

La mise à jour sur place préserve la majorité de la configuration et des applications, mais elle « recycle » aussi certaines clés du registre. BGInfo s’appuie par défaut sur des valeurs historiques de HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Résultat : le fond d’écran généré mentionne encore « Server 2016 » même si le système d’exploitation tourne désormais sur le noyau 10.0 Build 20348 de Windows Server 2022. Dans certains cas, le volet Spécifications de l’appareil de l’explorateur de fichiers récupère la même information obsolète.

Pourquoi BGInfo conserve l’ancienne version ?

BGInfo lit, à chaque exécution, les entrées suivantes :

• ProductName
• ReleaseId
• CurrentBuild
• CurrentVersion

Si un programme de mise à jour n’écrase pas l’ensemble du jeu de valeurs, BGInfo interprète l’ancienne combinaison. Les contrôles graphiques de l’interface Paramètres, eux, interrogent plutôt l’API interne Windows Version Helper, qui renvoie bien 2022. D’où la divergence visible.

Solutions et correctifs

Approche	Étapes clés	Avantages / Inconvénients
A. Corriger la clé de registre lue par BGInfo	Ouvrir Regedit.exe en mode administrateur. Se rendre sur : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion Contrôler / ajuster : CurrentVersion = 10.0 ProductName = Windows Server 2022 Standard ReleaseId = 2009 CurrentBuild = 20348 Fermer BGInfo puis le relancer, ou exécuter Bginfo.exe /timer:0.	Effet immédiat sur l’affichage. Pas besoin de modifier les fichiers .bgi. Risque : écriture manuelle dans le registre ; prudence requise. À répéter après une future mise à niveau majeure.
B. Éviter le registre : requête WMI dans BGInfo	Ouvrir BGInfo ▶ Custom Fields ▶ New… Choisir WMI Query puis saisir : SELECT Caption FROM Win32_OperatingSystem Insérer le champ personnalisé dans le modèle d’image. Enregistrer le fichier .bgi, puis lancer BGInfo sur chaque machine.	Remonte toujours le nom complet, sans dépendre du registre. Solution pérenne (fonctionne après les futures upgrades). Nécessite de mettre à jour le fichier .bgi si vous en déployez plusieurs. Exécution légèrement plus lente (appel WMI).

Mise à jour de l’utilitaire BGInfo

Assurez‑vous d’employer la version 4.29 (ou ultérieure) de Sysinternals. Les versions plus anciennes ignoraient certaines éditions de Windows Server 2022 et pouvaient forcer un retour à « Server 2016 » même après correction du registre.

Vérifications post‑mise à niveau

Avant de modifier quoi que ce soit, confirmez que l’OS est réellement perçu comme 2022 côté noyau :

winver
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Vous devez voir « Microsoft Windows Server 2022 Standard » et une version de Build ≥ 20348. Si c’est déjà le cas, le problème est circonscrit à BGInfo (ou à une valeur de registre isolée).

Forcer le rafraîchissement du cache BGInfo

BGInfo écrit le fond d’écran final dans %TEMP%\BGInfo*.bmp. Après tout changement, supprimez ce fichier ou lancez :

Bginfo.exe /silent /timer:0

Vous pouvez également utiliser l’argument /log pour tracer l’exécution et isoler d’éventuels messages d’erreur.

Automatisation PowerShell pour les grandes fermes

Sur un parc de dizaines de serveurs, la modification manuelle est irréaliste. Voici un script modulaire :

# Paramètres
$Servers = Get-Content .\ListeServeurs.txt   # Un nom NetBIOS ou FQDN par ligne
$BgiPath  = "\\srv-fichiers\BGI\Template2022.bgi"  # Votre fichier .bgi WMI-ready

foreach ($Srv in $Servers) {
    Write-Host "Traitement de $Srv..."
    try {
        Invoke-Command -ComputerName $Srv -ScriptBlock {
            # 1. Lire la version réelle depuis WMI
            $OS = Get-CimInstance -ClassName Win32_OperatingSystem
            $Caption = $OS.Caption
            if ($Caption -match "2022") {
                # 2. Vérifier/mettre à jour le registre si besoin
                $RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
                $CurrentProduct = (Get-ItemProperty -Path $RegPath -Name ProductName).ProductName
                if ($CurrentProduct -notmatch "2022") {
                    Set-ItemProperty -Path $RegPath -Name ProductName  -Value "Windows Server 2022 Standard"
                    Set-ItemProperty -Path $RegPath -Name CurrentVersion -Value "10.0"
                    Set-ItemProperty -Path $RegPath -Name ReleaseId      -Value "2009"
                    Set-ItemProperty -Path $RegPath -Name CurrentBuild   -Value "20348"
                }
                # 3. Déployer le .bgi WMI
                $Dest = "C:\Tools\BGInfo\Template2022.bgi"
                Copy-Item -Path $using:BgiPath -Destination $Dest -Force
                Start-Process "C:\Tools\BGInfo\Bginfo.exe" -ArgumentList "$Dest /silent /timer:0" -Wait
            } else {
                Write-Warning "Le serveur $env:COMPUTERNAME n'est pas en 2022. Ignoré."
            }
        } -AsJob
    } catch {
        Write-Error "Impossible de joindre $Srv : $_"
    }
}

Points clés du script :

• Get‑CimInstance garantit la détection de la version sans dépendre du registre.
• Les opérations réversibles (Set‑ItemProperty) sont conditionnées par la présence de « 2022 » pour éviter la corruption involontaire de serveurs encore en 2016.
• Invoke‑Command lance le traitement en parallèle si l’administrateur dispose de WinRM configuré.
• Le fichier .bgi transmis est basé sur la requête WMI ; il n’a pas besoin d’être mis à jour lors des futurs passages à Server 2025 ou 2026.

Réparer un dépôt WMI corrompu

Dans de rares cas (< 1 % des migrations), la requête Win32_OperatingSystem continue de retourner 2016. La cause : un dépôt WMI partiellement corrompu. Procédez comme suit :

winmgmt /verifyrepository
# Si le message indique une incohérence :
winmgmt /salvagerepository
# Puis tester à nouveau

Redémarrez ensuite le service Windows Management Instrumentation ou la machine entière, puis relancez BGInfo. Si la valeur est correcte, le fond d’écran l’affichera dès la prochaine connexion.

Bonnes pratiques après correction

• Sauvegarde : exportez la clé CurrentVersion avant toute modification. En cas d’erreur, une restauration rapide évite un redéploiement complet.
• Inventaire : générez un rapport CSV via Get‑CimInstance pour vérifier la cohérence version/registre sur l’ensemble du parc.
• Surveillance : planifiez une tâche BGInfo quotidienne avec /silent afin de maintenir le visuel à jour sans intervention manuelle.
• Cycle de vie : lorsque Windows Server 2025 sortira, prévoyez d’ajouter une étape de mise à jour automatique du fichier .bgi ou du script d’initialisation.

Résumé des avantages et inconvénients

Critère	Méthode Registre	Méthode WMI
Modifications requises	Écriture directe de 4 valeurs	Ajout d’un champ personnalisé dans BGInfo
Persistance après upgrade futur	Mise à jour manuelle à répéter	Aucune action ; version récupérée dynamiquement
Facilité de déploiement massif	Script PowerShell nécessaire	Distribution d’un fichier .bgi unique
Risque d’erreur manuelle	Moyen (registre)	Faible

Conclusion

Deux chemins s’offrent à vous pour remédier à l’affichage obsolète de BGInfo : mettre à jour les clés de registre ou basculer vers une requête WMI native. Pour des environnements limités (un ou deux hôtes), la correction du registre suffit. Pour des infrastructures plus larges ou à forte automatisation, la stratégie WMI — combinée à un fichier .bgi standardisé et à un script PowerShell — garantit une maintenance quasi nulle et une compatibilité future. Quelle que soit l’approche retenue, vérifiez toujours la version réelle via winver et conservez des sauvegardes des clés modifiées.

En appliquant ces bonnes pratiques, BGInfo affichera désormais « Windows Server 2022 » sur chaque bureau, reflétant fidèlement la réalité de votre parc.