Vous cherchez une ISO Windows Server 2019 exactement au build 10.0.17763.10127 ? Voici pourquoi cette build est introuvable côté client et comment déployer, vérifier et documenter une alternative pleinement supportée et conforme.
Contexte et problématique
Un administrateur doit déployer Windows Server 2019 avec le numéro de build 10.0.17763.10127. Malgré des recherches dans les canaux classiques (images « Updated », VLSC/MSDN, Microsoft Update Catalog, historique des mises à jour), aucune ISO publique ou LCU n’aboutit à ce build précis.
Constat essentiel : cette build n’est pas publiée côté client. Les numéros de build très élevés (au-delà de ~9000 pour la branche 17763) correspondent généralement à des artefacts internes (validation en labo, anneaux internes) et ne sont pas proposés aux clients.
Point de repère : au 21 mai 2024, la build la plus élevée distribuée publiquement pour Server 2019 est 10.0.17763.5820. Server 2019 partage la base Windows 10 version 1809 (famille de build 17763) et reçoit des Cumulative Updates (LCU) mensuelles portées par une Servicing Stack Update (SSU) quand nécessaire.
Pourquoi vous ne trouverez pas 10.0.17763.10127
- Absence de publication : aucune source officielle ne référence 10.0.17763.10127 pour le grand public (ISO, LCU, images « Updated »).
- Numérotation LCU : le suffixe (UBR, Update Build Revision) augmente à chaque LCU. Certains numéros existent uniquement dans des canaux internes et ne deviennent jamais publics.
- Risque d’erreur de saisie : la demande initiale peut cacher une coquille (par ex. 17763.1027) ou une exigence minimale (≥ 17763.1027) plutôt qu’un pin exact.
Stratégie recommandée pour avancer
Vérifier et recadrer l’exigence
Avant toute chose, validez par écrit ce qui est réellement exigé : un build exact ou un seuil minimal. Proposez la formulation ci‑dessous à votre partenaire/auditeur.
Bonjour,
Pour Windows Server 2019, le build 10.0.17763.10127 n'est pas distribué publiquement.
Confirmez-vous qu'un build exact 10.0.17763.10127 est requis,
ou qu'un build public ≥ 17763.1027 (ou autre seuil) est acceptable ?
Merci de votre confirmation.
Installer la version supportée la plus récente
Déployez l’ISO officielle Windows Server 2019 (RTM 17763.1 ou une ISO « Updated ») puis appliquez la dernière SSU et la dernière LCU pour atteindre la build publique la plus récente (ex. 17763.5820 au 21/05/2024). Vous garantissez ainsi la compatibilité, le support éditeur et l’exposition minimale au risque sécurité.
Cas d’usage conformité FIPS 140
Si l’objectif est la conformité FIPS, aucune build spéciale n’est nécessaire : Windows Server 2019 fournit des modules cryptographiques validés FIPS 140. Il suffit d’activer le mode FIPS via stratégie locale ou GPO (voir plus bas). Documentez l’activation et les preuves associées (captures de la stratégie, résultat de commandes).
Comprendre la numérotation (OS Build)
Terme | Définition | Exemple pour Server 2019 |
---|---|---|
Build principal | Base système (CurrentBuild) | 17763 |
UBR | Update Build Revision (augmente à chaque LCU) | … 5820 |
Chaîne complète | Version du noyau + build + UBR | 10.0.17763.5820 |
Équivalence Windows 10 | Branche commune (mécanique de patching identique) | Windows 10 1809 |
Procédure pas‑à‑pas : déployer, mettre à jour, vérifier
Préparer l’image
- Téléchargez et stockez l’ISO Windows Server 2019 (édition Standard/Datacenter selon besoin). Montez-la sur une station d’intégration ou un serveur MDT/SCCM/ConfigMgr.
- Identifiez l’index WIM correspondant à l’édition et au mode d’installation (Server Core/avec expérience).
dism /Get-WimInfo /WimFile:D:\sources\install.wim
Mettre à jour en ligne (post‑installation)
- Installez la SSU la plus récente pour 17763, puis la LCU la plus récente.
- Redémarrez si demandé, puis vérifiez la build.
:: Exemple d'installation manuelle (.msu)
wusa.exe <SSU_x64.msu> /quiet /norestart
wusa.exe <LCU_x64.msu> /quiet /norestart
shutdown /r /t 0
Mettre à jour hors ligne (servicing de WIM)
Pratique pour produire une image « à jour » réutilisable (MDT/ConfigMgr/Autounattend).
mkdir C:\WIM\Mount
dism /Mount-Image /ImageFile:D:\sources\install.wim /Index:2 /MountDir:C:\WIM\Mount
dism /Image:C:\WIM\Mount /Add-Package /PackagePath:C:\Updates\SSU_x64.msu
dism /Image:C:\WIM\Mount /Add-Package /PackagePath:C:\Updates\LCU_x64.msu
dism /Unmount-Image /MountDir:C:\WIM\Mount /Commit
Configurer WSUS / contrôle de la dérive
Si vous devez geler une build le temps d’un audit ou d’une validation applicative, approuvez uniquement les LCUs nécessaires dans WSUS et bloquez l’installation automatique côté serveur via GPO.
GPO | Chemin | Paramètre recommandé |
---|---|---|
Configurer les Mises à jour automatiques | Configuration ordinateur → Modèles d’administration → Composants Windows → Windows Update | Activé, téléchargement uniquement (option 3) pendant la phase d’audit |
Spécifier l’emplacement du service Intranet Microsoft Update | … → Windows Update | URL WSUS interne (HTTP/HTTPS) |
Sélectionner la date d’installation des MàJ qualité | … → Windows Update → Windows Update for Business | Reporter de X jours si nécessaire |
Vérifier la build installée
Après mise à jour, consignez des preuves (screenshots, sorties de commandes) :
winver
systeminfo | findstr /i "OS Version"
PowerShell
(Get-ComputerInfo).OsName, (Get-ComputerInfo).OsVersion, (Get-ComputerInfo).OsBuildNumber
PowerShell
$cv = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
"$($cv.ProductName) — build $($cv.CurrentBuild).$($cv.UBR)"
Activer et documenter le mode FIPS (si requis)
FIPS n’exige pas un build spécifique. Activez et documentez :
- Stratégie locale : Sécurité locale → Options de sécurité → Système cryptographique : utiliser des algorithmes conformes à FIPS 140.
- GPO : Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Options de sécurité (même paramètre).
- Registre (alternative script) :
PowerShell
New-Item -Path "HKLM:\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy" -ErrorAction SilentlyContinue | Out-Null
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy" -Name Enabled -Type DWord -Value 1
Attention : certaines applications peuvent être incompatibles avec le mode FIPS. Testez avant généralisation.
Différencier « build exact » et « seuil minimal »
Beaucoup d’exigences naissent d’un mapping ancien ou d’une note d’audit ambiguë. Évitez de figer un numéro exact introuvable et proposez un critère de compatibilité plus robuste :
- Seuil minimal : « Windows Server 2019, build ≥ 17763.1027 ».
- Fenêtre de stabilité : « Windows Server 2019, LCU ≤ J‑30 » (gèle la ligne de base pendant la recette).
- Liste d’API/Fonctionnalités : « Crypto NG + TLS 1.2 activé, ciphers X/Y » plutôt qu’un build numéroté.
Scripts utiles (automatisation)
Mettre à jour un serveur fraîchement installé
PowerShell
# Exécution en console admin
Set-ExecutionPolicy Bypass -Scope Process -Force
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Install-Module PSWindowsUpdate -Force
Import-Module PSWindowsUpdate
# Laisser WSUS si configuré, sinon Microsoft Update
Get-WindowsUpdate -MicrosoftUpdate
Install-WindowsUpdate -AcceptAll -AutoReboot
Extraire et consigner la ligne de base
PowerShell
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$os = @{
ProductName = $cv.ProductName
ReleaseId = $cv.ReleaseId
CurrentBuild= $cv.CurrentBuild
UBR = $cv.UBR
Display = "$($cv.ProductName) $($cv.CurrentBuild).$($cv.UBR)"
}
$os | Format-List
Tableau : erreurs fréquentes et corrections
Symptôme | Cause probable | Correction |
---|---|---|
« ISO 10.0.17763.10127 introuvable » | Build interne non publié | Recadrer l’exigence, viser la dernière build publique (ex. 17763.5820 au 21/05/2024) |
Build reste à 17763.1 après LCU | SSU manquante ou ordre d’installation inversé | Installer SSU d’abord, puis LCU. Redémarrer. |
Applications cassées après activation FIPS | Incompatibilité avec algorithmes FIPS-only | Tester en pré‑prod, documenter les exceptions, ajuster le périmètre |
Serveur met à jour au‑delà de la build validée | WU non contrôlé, WSUS absent | GPO « Télécharger uniquement », WSUS avec approbation manuelle |
Modèle de dossier de preuve (audit)
- Inventaire : exports
systeminfo
,Get-ComputerInfo
, capturewinver
. - Patch baseline : capture du registre (
CurrentBuild
,UBR
), exportdism /online /Get-Packages
. - Conformité : screenshot GPO FIPS et Windows Update, journal d’installation SSU/LCU.
- Traçabilité : email de confirmation partenaire/auditeur sur le critère accepté.
FAQ rapide
La build 10.0.17763.10127 existe‑t‑elle quelque part ?
Elle peut exister en interne chez l’éditeur mais n’est pas proposée au public. Vous ne trouverez ni ISO ni LCU pour y parvenir côté client.
Pourquoi parle‑t‑on de 17763.xxxx pour Server 2019 ?
Server 2019 partage la base 17763 (Windows 10 1809). Le suffixe « xxxx » (UBR) est incrémenté par les LCUs mensuelles.
Faut‑il un build particulier pour FIPS 140 ?
Non. Il faut activer le mode FIPS et prouver sa mise en œuvre. Les modules requis sont fournis par l’OS.
Comment “geler” la build pendant la recette ?
Pilotez via WSUS : approuvez uniquement les LCUs validées et configurez la GPO « Télécharger uniquement ».
Peut‑on exiger un build exact en production ?
Possible contractuellement, mais risqué techniquement si le build n’est pas public. Préférez un seuil minimal ou un critère fonctionnel.
Checklist opérationnelle
- Télécharger l’ISO Server 2019 et identifier le bon index WIM.
- Installer SSU puis LCU les plus récentes pour 17763.
- Redémarrer, vérifier
CurrentBuild.UBR
et archiver les preuves. - Configurer WSUS/GPO pour maîtriser la dérive durant l’audit.
- Activer FIPS si requis et consigner les impacts applicatifs.
- Formaliser l’acceptation d’un seuil (ex. ≥ 17763.1027) si le build exact n’est pas public.
Récapitulatif
La build 10.0.17763.10127 n’est pas une version publique de Windows Server 2019. Le meilleur chemin consiste à déployer l’OS depuis une image officielle, puis à appliquer la dernière SSU et la dernière LCU afin d’atteindre la build publiée la plus récente (par exemple 17763.5820 au 21/05/2024). Pour les enjeux d’audit ou de conformité, documentez votre ligne de base, contrôlez les mises à jour via WSUS/GPO, activez FIPS si demandé, et recadrez l’exigence vers un seuil minimal mesurable et durable.
Annexes : blocs prêts à l’emploi
Commande d’inventaire express (PowerShell)
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
[PSCustomObject]@{
ProductName = $cv.ProductName
EditionID = $cv.EditionID
ReleaseId = $cv.ReleaseId
CurrentBuild = $cv.CurrentBuild
UBR = $cv.UBR
DisplayBuild = "$($cv.CurrentBuild).$($cv.UBR)"
} | Format-List
Extrait d’Autounattend.xml
(serveur Core, langue/clé à adapter)
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-International-Core">
<InputLocale>fr-FR</InputLocale>
<SystemLocale>fr-FR</SystemLocale>
<UILanguage>fr-FR</UILanguage>
<UserLocale>fr-FR</UserLocale>
</component>
</settings>
</unattend>
Bloc WSUS (GPO) – mémo
Configuration ordinateur
└─ Modèles d’administration
└─ Composants Windows
└─ Windows Update
├─ Spécifier l’emplacement du service Intranet Microsoft Update
├─ Configurer les Mises à jour automatiques (option 3 recommandé en recette)
└─ Ne pas inclure de pilotes avec les Mises à jour Windows
Arguments clés à partager avec un auditeur
- Le build 10.0.17763.10127 n’est pas distribué publiquement ; aucune ISO/LCU officielle ne le référence.
- Une politique de patching alignée SSU/LCU + gel temporaire via WSUS/GPO est plus sûre qu’un pin sur un build introuvable.
- Les exigences de sécurité (FIPS 140) sont atteintes sans build spécifique ; seule l’activation du mode FIPS et les preuves associées sont nécessaires.
Conclusion pratique : renoncez à traquer un build « fantôme ». Standardisez votre pipeline (ISO officielle → SSU → LCU → preuves), maîtrisez la dérive par WSUS, et traduisez l’exigence en critères mesurables et supportés.