Aujourd’hui je vous partage un troobleshooting issue d’un problème client concernant le déploiement des mises à jour de fonctionnalités avec Configuration Manager.
Le décor
Ici, pas de plan de servicing ni de séquence de tâche, juste un déploiement classique d’une mise à jour de fonctionnalités directement depuis la console Configuration Manager, rien de complexe. Et pourtant, aucune installation ni même de publication dans le Centre logiciel et nous voici en présence d’un cas étrange.
Etant familier avec cette hiérarchie Configuration Manager j’ai rapidement écarté toutes mauvaises configurations coté infrastructure, je me suis penché coté client ou j’étais certain de trouver la cause du soucis.
Dans ces cas là, après avoir validé que le client est conforme – et présent dans une limite de site géré par ConfigMgr – je me penche sur les logs suivantes :
- WUAHandler.log qui enregistre des détails de l’agent Windows Update du client lorsqu’il recherche des mises à jour logicielles.
- ScanAgent.log qui enregistre les détails sur les demandes d’analyse pour les mises à jour logicielles, l’emplacement WSUS et les actions associées.
- UpdatesDeployment.log qui enregistre des détails sur les déploiements sur le client, y compris l’activation, l’évaluation et l’application des mises à jour logicielles.
L’erreur
Après avoir pris connaissance des journaux, je suis maintenant certains que le client ne communique pas correctement avec le Software Update Point.
ScanAgent.log m’indique une erreur lors de la demande d’analyse, m’indiquant une erreur 0x80244017 :
WUAHandler.log m’indique la même chose, erreur 0x80244017 :
Pour finir, la même chose dans UpdatesDeployment.log mais cette fois m’indique clairement qu’aucune mise à jour ne me sera proposée.
Troobleshooting
Maintenant que j’ai cerné mon code erreur, je peux commencer par traduire celui-ci par quelques chose de plus compréhensible via l’Error Lookup de CMTrace.
Une erreur HTTP 401 sur WSUS ou un Software Update Point est généralement lié à la configuration de IIS et/ou du Software Update Point, après vérification des logs IIS, aucune erreur n’est tracée et je valide que mon client est capable de se connecter et de dialoguer avec les Web Services ClientWebService et SimpleAuthWebService
POST /ApiRemoting30/WebService.asmx - 8530 domain.intra\sccmpssrv$ ::1 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+4.0.30319.34209) - 200 0 0 0
De plus, le Software Update Point est configuré sur le port 8530 et n’utilise pas SSL. Ne pouvant remettre en cause l’infrastructure et ayant validé la bonne configuration, je dois continuer mes recherches. Cependant, la cause est très clair, l’Agent Windows Update nécessite une authentification additionnelle lors de sa communication avec le serveur.
Après quelques dizaines de minutes de recherche et une capture d’information avec Fiddler/Wireshark et WindowsUpdate.log je tombe sur une ^piste :
WS WARNING: Proxy List used: ‘proxy.mydomain:80’, Bypass List used: ‘(REDACTED)‘,
Le client utilise une configuration proxy utilisateur paramétrés via GPO mais après vérification la liste des exclusions est correct néanmoins je décide d’ajouter le domaine complet en exception car après tout il est normal de ne pas souhaiter que les clients passent par un proxy pour accéder à des adresses locales.
Mais pourquoi donc le client persiste à vouloir passer par le proxy pour se connecter au serveur ?
La solution
Il existe deux types de paramètres de proxy depuis l’apparition de Windows Vista, les paramètres au niveau de l’utilisateur, qui sont définis via le panneau de configuration des options Internet, et les paramètres au niveau de la machine, qui sont définis à l’aide de la commande « netsh winhttp set proxy. »
Lorsque Windows Update effectue une opération de mise à jour automatique planifiée, il utilise les paramètres au niveau de l’ordinateur.
Maintenant, il y a une différence entre les paramètres au niveau de l’utilisateur et les paramètres au niveau de la machine. Les paramètres au niveau de l’utilisateur permettent de choisir explicitement parmi trois options :
- Ne pas utiliser de proxy
- Recherchez un proxy web sur le réseau et l’utiliser
- Utiliser ce serveur proxy et ces autres paramètres de proxy pour exclusions
Les paramètres au niveau de la machine (système) permettent uniquement de choisir entre « Utiliser ce serveur proxy et ces autres paramètres de proxy » et « Ne pas utiliser de proxy du tout ». Il n’y a aucun moyen de définir explicitement les paramètres de proxy au niveau de la machine sur « Utiliser un proxy web sur le réseau et l’utiliser «
Voici la solution de contournement pour le problème. Il suffit d’exécutez cette commande à partir d’une invite de commande élevée :
netsh winhttp set proxy proxy-server="PROXY" bypass-list="*.domain;"En d’autres termes, nous définissons les paramètres de proxy au niveau de la machine sur « Utiliser le serveur proxy XXX ; mais contourner le proxy lors de l’accès à un site local.
Après un rafraîchissement de la politique ConfigMgr, le Centre Logiciel me propose la mise à jour attendue, confirmé par la les logs.
