Contexte :
Le problème décrit ci-dessous a été rencontré dans le cadre de la mise en place d’un serveur WSUS sous Windows Server 2012 R2.
Problème rencontré :
Suite à la mise en place de WSUS, toutes les installations de mises jours depuis les serveurs étaient en échec ainsi que la remontée des rapports.
Un code d’erreur apparait : 80244016.
Analyse :
Pour obtenir plus de détails sur ce type de problème, l’outil WireShark peut être utilisé depuis un « client » WSUS afin d’analyser les flux réseau entre le client et le serveur WSUS.
Il faut ensuite filtrer les résultats obtenus sur les protocoles http et https.
La traceWireShark permet de mettre en évidence qu’une erreur de type « http/1.1 400 Bad Request » est déclenchée.
En observant en détail la requête http, on observe que le client WSUS tente de récupérer un fichier « .cab » sur le serveur WSUS avec le nom complet du serveur WSUS (FQDN).
La requête essai de communiquer avec l’host : hote.mondomaine.com.
Explication :
Le problème est dû à une incohérence entre la configuration du site IIS du serveur WSUS et l’URL positionnée sur les clients WSUS.
Les deux valeurs doivent être identiques (soit le nom NetBIOS du serveur WSUS, soit son FQDN).
Pour trouver le paramètre erroné il suffit de vérifier tous les endroits où l’URL est rentrée.
Le premier point à vérifier est la configuration de la stratégie de groupe positionnant l’URL WSUS sur le client.
Pour vérifier il suffit de lancer la commande « Rsop.msc » sur le client WSUS, puis d’aller dans le dossier « Windows Update » dans la section Configuration Ordinateur / Modèle d’administration / Composant Windows :
L’URL est positionnée dans le paramètre « Spécifier l’emplacement intranet du service de mise à jour Microsoft »
Il ne reste plus qu’à vérifier la configuration de IIS. Une fois la page de management est ouverte il faut se mettre sur le site « WSUS Administration ».
Puis aller dans le paramètre « Bindings »
Et d’éditer l’adresse http.
Dans notre exemple, la GPO demande au client d’utiliser le FQDN du serveur alors que le site IIS accepte uniquement les requêtes adressées au nom court.
Résolution :
Pour résoudre le problème, il suffit de modifier le « host name » du site Web IIS par le FQDN du serveur.
Suite au redémarrage de IIS, les clients WSUS peuvent appliquer les mises à jour avec succès.
On peut vérifier en relançant une capture de trames et on s’aperçoit bien que le serveur WSUS répond avec le code 200, ce qui signifie que la requête a été traitée avec succès.
