Partager via

Résoudre les problèmes de gestion des mises à jour logicielles dans Configuration Manager

  • Article

Cet article vous aide à résoudre les problèmes liés au processus de gestion des mises à jour logicielles dans Configuration Manager. Il inclut l’analyse des mises à jour logicielles clientes, les problèmes de synchronisation et les problèmes de détection avec des mises à jour spécifiques.

Version du produit d’origine : Configuration Manager (current branch), System Center 2012 R2 Configuration Manager, System Center 2012 Configuration Manager
Numéro de base de connaissances d’origine : 4505440

Étendue de votre problème

Ce guide suppose qu’un point de mise à jour logicielle a déjà été installé et configuré. Pour plus d’informations sur la configuration des mises à jour logicielles dans Configuration Manager, consultez Préparer la gestion des mises à jour logicielles.

Avant de commencer à résoudre les problèmes, il est important de souligner que, mieux vous comprenez le problème que vous rencontrez, plus rapidement et plus il vous sera facile de le résoudre. Que vous soyez chargé de résoudre un problème que vous rencontrez ou un problème signalé par une personne de votre organisation, prenez un moment et répondez aux questions suivantes :

  1. Qu’est-ce qui ne fonctionne pas et/ou quel est votre objectif ?
  2. Quelle est la fréquence ou le modèle du problème ? Le problème persiste-t-il ?
  3. Comment saviez-vous que le problème existe ?
  4. A-t-il déjà fonctionné ? Si c’est le cas, quand a-t-il cessé ? Quelque chose a-t-il changé dans l’environnement juste avant qu’il ne fonctionne ?
  5. Quel pourcentage de clients sont affectés ?
  6. Qu’est-ce qui a déjà été fait (si quelque chose) pour essayer de le corriger ?
  7. Connaissez la version exacte du client et la version du serveur. Ces systèmes sont-ils à jour ?
  8. Qu’est-ce que les clients affectés ont en commun ? Par exemple, même sous-réseau, site AD, domaine, emplacement physique, site, système de site.

Connaître et comprendre les réponses à ces questions vous mettra sur le meilleur chemin pour une résolution rapide et facile à tout problème que vous rencontrez.

Si vous connaissez la zone spécifique dans le processus de gestion des mises à jour logicielles que vous souhaitez résoudre, sélectionnez-la ci-dessous. Commencez par l’analyse des mises à jour logicielles clientes si vous ne savez pas et nous allons parcourir l’ensemble du processus de début à la fin.

Analyse des mises à jour logicielles clientes

Le processus d’analyse du client est décrit dans les étapes suivantes. Confirmez chaque étape pour établir correctement l’emplacement du problème.

Étape 1 : Le client envoie une demande d’emplacement WSUS au point de gestion

La première chose que le client fait est de définir le serveur WSUS qui sera sa source de mise à jour pour les analyses de mises à jour logicielles. Ce processus est détaillé ci-dessous.

  1. Lorsque le client Configuration Manager doit traiter une analyse des mises à jour logicielles, l’Agent d’analyse crée une demande d’analyse basée sur la stratégie disponible, comme indiqué dans ScanAgent.log :

    CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={SourceID}  
ContentVersion=38  
CScanAgent::ScanByUpdates- Added Policy to final ScanRequest List UpdateSourceID={SourceID}, Policy-ContentVersion=38, Required-ContentVersion=38

  2. L’agent d’analyse envoie maintenant une demande d’emplacement WSUS aux services d’emplacement, comme indiqué dans ScanAgent.log :

    Inside CScanAgent::ProcessScanRequest()  
CScanJobManager::Scan- entered  
ScanJob({JobID}): CScanJob::Initialize- entered  
ScanJob({JobID}): CScanJob::Scan- entered  
ScanJob({JobID}): CScanJob::RequestLocations- entered  
- - - - - -Requesting WSUS Server Locations from LS for {WSUSLocationID} version 38  
- - - - - -Location Request ID = {LocationRequestID}  
CScanAgentCache::PersistInstanceInCache- Persisted Instance CCM_ScanJobInstance  
ScanJob({JobID}): - - - - - -Locations requested for ScanJobID={JobID} (LocationRequestID={LocationRequestID}), will process the scan request once locations are available.

    Conseil

    Chaque travail d’analyse est stocké dans WMI dans la CCM_ScanJobInstance classe :

    Espace de noms : root\CCM\ScanAgent classe : CCM_ScanJobInstance

  3. Location Services crée une demande d’emplacement et l’envoie au point de gestion. L’ID de package d’une demande d’emplacement WSUS est l’ID unique de la source de mise à jour. Dans LocationServices.log :

    CCCMWSUSLocation::GetLocationsAsyncEx  
Attempting to persist WSUS location request for ContentID='{ContentID}' and ContentVersion='38'  
Persisted WSUS location request LocationServices  
Attempting to send WSUS Location Request for ContentID='{ContentID}'
WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest>  
Created and Sent Location Request '{LocationRequestID}' for package {ContentID}

  4. La messagerie CCM envoie le message de demande d’emplacement au point de gestion. Dans CcmMessaging.log :

    Sending async message '{Message}' to outgoing queue 'mp:[http]mp_locationmanager'  
Sending outgoing message '{Message}'. Flags 0x200, sender account empty

  5. Le point de gestion analyse cette requête et appelle la MP_GetWSUSServerLocations procédure stockée pour obtenir les emplacements WSUS de la base de données. Dans MP_Location.log :

    MP LM: Message Body : \<WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> MP_LocationManager  
MP LM: calling MP_GetWSUSServerLocations

    Dans SQL Server Profiler :

    exec MP_GetMPSitesFromAssignedSite N'PS1'  
exec MP_GetSiteInfoUnified N'<ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2-PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo>'  
exec MP_GetWSUSServerLocations N'{WSUSServerLocationsID}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'

  6. Après avoir obtenu les résultats de la procédure stockée, le point de gestion envoie une réponse au client. Dans MP_Location.log :

    MP LM: Reply message body: <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply>

  7. La messagerie CCM reçoit la réponse et la renvoie aux services d’emplacement. Dans CcmMessaging.log :

    Message '{Message1}' got reply '{Message2}' to local endpoint queue 'LS_ReplyLocations'  
OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={*Message1*}):  
Delivered successfully to host 'PS1SYS.CONTOSO.COM'.  
Message '{Message2}' delivered to endpoint 'LS_ReplyLocations'

  8. Location Services analyse la réponse et renvoie l’emplacement à l’agent d’analyse. Dans LocationServices.log :

    Processing Location reply message LocationServices  
WSUSLocationReply : <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply>  
Calling back with the following WSUS locations  
WSUS Path='http://PS1SITE.CONTOSO.COM:8530', Server='PS1SITE.CONTOSO.COM', Version='38'  
WSUS Path='https://PS1SYS.CONTOSO.COM:8531', Server='PS1SYS.CONTOSO.COM', Version='38'  
Calling back with locations for WSUS request {WSUSLocationID}

  9. L’Agent d’analyse dispose désormais de la stratégie et de l’emplacement source de mise à jour avec la version de contenu appropriée. Dans ScanAgent.log :

    *****WSUSLocationUpdate received for location request guid={LocationGUID}  
ScanJob({JobID}): CScanJob::OnLocationUpdate- Received  
Location=<http://PS1SITE.CONTOSO.COM:8530>, Version=38  
ScanJob({JobID}): CScanJob::Execute- Adding UpdateSource={SourceID}, ContentType=2, ContentLocation=<http://PS1SITE.CONTOSO.COM:8530>, ContentVersion=38

  10. L’agent d’analyse avertit WUAHandler d’ajouter la source de mise à jour. WUAHandler ajoute la source de mise à jour au Registre. Il lance une actualisation de stratégie de groupe si le client est dans le domaine pour voir si la stratégie de groupe remplace le serveur de mise à jour ajouté. Les entrées suivantes sont consignées WUAHandler.log montrant une nouvelle source de mise à jour ajoutée :

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it  
Its a completely new WSUS Update Source  
Enabling WUA Managed server policy to use server: <http://PS1SITE.CONTOSO.COM:8530>
Policy refresh forced  
Waiting for 2 mins for Group Policy to notify of WUA policy change  
Waiting for 30 secs for policy to take effect on WU Agent.  
Added Update Source ({UpdateSource}) of content type: 2

    Pendant ce temps, l’agent Windows Update voit une modification de configuration WSUS. Dans WindowsUpdate.log :

    * WSUS server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
* WSUS status server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
Sus server changed through policy.

    Les clés de Registre suivantes sont vérifiées et définies :

    Sous-clé de Registre Nom de la valeur Type Données
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate WUServer REG_SZ URL complète du serveur WSUS, y compris le port. Par exemple, <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate WUStatusServer REG_SZ URL complète du serveur WSUS, y compris le port. Par exemple, <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU UseWUServer REG_DWORD 0x1

    Pour un client existant, nous pouvons nous attendre à voir le message suivant dans WUAHandler.log indiquer quand la version du contenu a incrémenté :

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it.  
WSUS update source already exists, it has increased version to 38.

  11. Une fois la source de mise à jour ajoutée, l’Agent d’analyse déclenche un message d’état et démarre l’analyse. Dans ScanAgent.log :

    ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2  
ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

Résoudre les problèmes à l’étape 1

Problèmes Les points à vérifier
ScanAgent.log n’affiche aucune stratégie disponible pour une source de mise à jour et aucune WUAHandler.log n’existe ou aucune activité actuelle dans WUAHandler.log Vérifiez le paramètre Activer les mises à jour logicielles sur les clients .
Les services d’analyse ou d’emplacement ne reçoivent pas l’emplacement du serveur WSUS

  • Un rôle de point de mise à jour logicielle (SUP) est-il installé pour le site ?

    Si ce n’est pas le cas, installez et configurez un point de mise à jour logicielle et surveillez SUPSetup.log de progression. Pour plus d’informations, consultez Installer et configurer un point de mise à jour logicielle.

  • Si un rôle SUP est installé, est-il configuré et synchronisant ?

    Vérifiez WCM.log, WSUSCtrl.log et WSyncMgr.log pour les erreurs.

    • select * from WSUSServerLocations
    • select * from Update_SyncStatus
Le client reçoit l’emplacement WSUS, mais ne parvient pas à configurer les clés de Registre WSUS

L’actualisation de la stratégie de groupe a-t-elle répondu dans le délai d’expiration de 2 minutes par WUAHandler.log ? Si c’est le cas, WUAHandler indique-t-il que les paramètres de stratégie de groupe ont été remplacés par une autorité supérieure (contrôleur de domaine) ?

Pour plus d’informations, consultez La stratégie de groupe remplace les informations de configuration WSUS appropriées.

Pour plus d’informations sur la résolution des problèmes d’analyse des mises à jour logicielles, consultez Résoudre les problèmes d’analyse des mises à jour logicielles.

Étape 2 : l’agent d’analyse demande l’analyse et WUAHandler démarre l’analyse

Une fois que le client a identifié et défini le serveur WSUS qui sera sa source de mise à jour pour les analyses de mises à jour logicielles, l’Agent d’analyse demande l’analyse à partir de WUAHandler qui utilise l’API de l’agent Windows Update pour demander une analyse de mise à jour logicielle à partir de l’agent Windows Update. Une analyse peut provenir des points suivants :

  • Analyse planifiée ou manuelle des mises à jour logicielles
  • Une nouvelle évaluation planifiée ou manuelle du déploiement mis à jour par les logiciels
  • Déploiement qui devient actif

L’analyse déclenche une évaluation. Dans ScanAgent.log :

ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

Les résultats de l’analyse incluent les mises à jour remplacées uniquement lorsqu’elles sont remplacées par les service Packs et les mises à jour de définition. Dans WUAHandler.log :

Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')  
Running single-call scan of updates.  
Async searching of updates using WUAgent started.

Conseil

Passez en revue WUAHandler.log après une analyse des mises à jour logicielles pour voir si de nouvelles entrées se produisent. Si aucune nouvelle entrée ne se produit, il indique qu’aucun sup n’est retourné par le point de gestion.

Résoudre les problèmes à l’étape 2

De nombreux problèmes liés à l’analyse des mises à jour logicielles peuvent être causés par l’une des raisons suivantes :

  • Fichiers ou clés de Registre manquants ou endommagés.
  • Problèmes d’inscription des composants.

Pour résoudre ces problèmes, consultez les échecs d’analyse en raison de composants manquants ou endommagés.

Il existe un problème connu selon lequel un client Windows 7 ConfigMgr 2012 R2 32 bits demandant une analyse de mise à jour ne retourne pas les résultats de l’analyse de l’analyse à Configuration Manager. Le client signale un état de conformité incorrect et les mises à jour ne sont pas installées lorsque Configuration Manager demande le cycle de mise à jour. Toutefois, si vous utilisez l’applet du panneau de configuration Windows Update, les mises à jour s’installent généralement correctement. Lorsque vous rencontrez ce problème, vous recevez un message similaire à celui suivant dans WindowsUpdate.log :

WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E

Il s’agit d’un problème d’allocation de mémoire, les ordinateurs Windows 7 64 bits ne voient pas cette erreur, car leur espace d’adressage est effectivement illimité. Toutefois, ils présentent une mémoire élevée et une utilisation élevée du processeur, ce qui peut affecter les performances. Les clients X86 présentent également une utilisation élevée de la mémoire (généralement environ 1,2 Go à 1,4 Go).

Pour résoudre ce problème, appliquez le client Windows Update pour Windows 7 : juin 2015.

Lors de la résolution des échecs d’analyse, vérifiez les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que l’agent Windows Update a signalé. Par conséquent, l’erreur dans WUAHandler serait la même erreur que celle signalée par l’agent Windows Update lui-même. Vous trouverez plus d’informations sur l’erreur dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez les fichiers journaux Windows Update.

Votre meilleure source d’informations provient des journaux et des codes d’erreur qu’ils contiennent. Pour plus d’informations sur les codes d’erreur, consultez Les erreurs courantes et l’atténuation de Windows Update.

Étape 3 : Windows Update Agent (WUA) démarre l’analyse sur l’ordinateur WSUS

L’agent Windows Update démarre une analyse après avoir reçu une demande du client Configuration Manager (CcmExec). Si ces valeurs de Registre sont correctement définies sur un ordinateur WSUS qui est un sup valide pour le site via une stratégie locale, vous devez voir une demande de recherche d’API COM à partir du client Configuration Manager (ClientId = CcmExec). Dans WindowsUpdate.log :

COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]  
COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec] PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent ** START ** Agent: Finding updates [CallerId = CcmExec]  
Agent * Include potentially superseded updates  
Agent * Online = Yes; Ignore download priority = Yes  
Agent * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"  
Agent * ServiceID = {ServiceID} Managed  
Agent * Search Scope = {Machine}

PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent * Added update {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 to search result  
Agent * Added update {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 to search result  
Agent * Found 163 updates and 70 categories in search; evaluated appl. rules of 622 out of 1150 deployed entities  
Agent ** END ** Agent: Finding updates [CallerId = CcmExec]  
COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]  
COMAPI - Updates found = 163  
COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]

Résoudre les problèmes à l’étape 3

Pendant une analyse, l’agent Windows Update doit communiquer avec les répertoires virtuels et SimpleAuthWebService les ClientWebService répertoires sur l’ordinateur WSUS pour effectuer une analyse. Si le client ne peut pas communiquer avec l’ordinateur WSUS, l’analyse échoue. Ce problème peut se produire pour de nombreuses raisons, notamment :

  • Problèmes liés au proxy

    Pour résoudre ces problèmes, consultez les échecs d’analyse en raison de problèmes liés au proxy.

    Pour plus d’informations sur les serveurs proxy, consultez les articles suivants :

  • Erreurs de délai d’expiration HTTP

    Pour résoudre les erreurs de délai d’expiration HTTP, passez d’abord en revue les journaux iis (Internet Information Services) sur l’ordinateur WSUS pour vérifier que les erreurs sont réellement retournées par WSUS. Si l’ordinateur WSUS ne retourne pas l’erreur, le problème est probablement lié à un pare-feu ou un proxy intermédiaire.

    Si l’ordinateur WSUS retourne l’erreur, vérifiez la connectivité avec l’ordinateur WSUS. Voici la procédure à suivre :

    1. Pour vérifier que le client se connecte au serveur WSUS approprié, recherchez l’URL de l’ordinateur WSUS utilisé par le client de l’agent Windows Update. Cette URL est disponible en vérifiant la sous-clé de HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate Registre ou en consultant le fichier WindowsUpdate.log.

      Les raisons courantes pour lesquelles l’affectation WSUS peut être incorrecte sont les suivantes :

      • Conflits de stratégie de groupe
      • Ajout d’un sup à un site secondaire après l’installation initiale du client

      Note

      La stratégie de groupe Active Directory peut remplacer la stratégie WSUS locale.

      La fonctionnalité de mise à jour logicielle configure automatiquement un paramètre de stratégie de groupe local pour le client Configuration Manager afin qu’il soit configuré avec l’emplacement source du point de mise à jour logicielle et le numéro de port. Le nom du serveur et le numéro de port sont requis pour que le client recherche le point de mise à jour logicielle.

      Si un paramètre de stratégie de groupe Active Directory est appliqué aux ordinateurs pour l’installation du client du point de mise à jour logicielle, il remplace le paramètre de stratégie de groupe local. Si la valeur du paramètre défini dans la stratégie de groupe Active Directory est différente de celle définie par Configuration Manager, l’analyse échoue sur le client, car elle ne peut pas localiser l’ordinateur WSUS approprié. Dans ce cas, WUAHandler.log affiche le message suivant :

      Les paramètres de stratégie de groupe ont été remplacés par une autorité supérieure (contrôleur de domaine) pour : serveur <http://server> et stratégie ACTIVÉ

      Le point de mise à jour logicielle pour l’installation du client et les mises à jour logicielles doivent être le même serveur. Et il doit être spécifié dans le paramètre de stratégie de groupe Active Directory avec le format de nom et les informations de port correctes. Par exemple, il serait <http://server1.contoso.com:80> si le point de mise à jour logicielle utilisait le site web par défaut.

    2. Si l’URL du serveur est correcte, accédez au serveur à l’aide d’une URL similaire à celle suivante pour vérifier la connectivité entre le client et l’ordinateur WSUS :

      <http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab>

      Pour vérifier si le client peut accéder au ClientWebService répertoire virtuel, essayez d’accéder à une URL similaire à celle-ci :

      <http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml>

      Pour vérifier si le client peut accéder à l’URL SimpleAuthWebService, essayez d’accéder à une URL similaire à celle-ci :

      <http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx>

      Si l’une de ces URL échoue, certaines des raisons possibles sont les suivantes :

      • Problèmes de résolution de noms sur le client. Vérifiez que vous pouvez résoudre le nom de domaine complet de l’ordinateur WSUS.

      • Problèmes de configuration de proxy.

      • Autres problèmes de connectivité liés au réseau.

      • Problèmes de configuration de port. Il est donc judicieux de vérifier que les paramètres du port sont corrects. WSUS peut être configuré pour utiliser l’un des ports suivants : 80, 443 ou 8530, 8531.

        Pour que les clients communiquent avec l’ordinateur WSUS, les ports appropriés doivent être autorisés sur le pare-feu sur l’ordinateur WSUS. Les paramètres de port sont configurés lorsque le rôle de système de site du point de mise à jour logicielle est créé. Ces paramètres de port doivent être identiques aux paramètres de port utilisés par le site web WSUS. Sinon, le Gestionnaire de synchronisation WSUS ne parvient pas à se connecter à WSUS s’exécutant sur le point de mise à jour logicielle pour demander la synchronisation. Les procédures suivantes fournissent des informations sur la façon de vérifier les paramètres de port utilisés par WSUS et le point de mise à jour logicielle.

        1. Déterminez les paramètres de port WSUS utilisés dans IIS 7.0 et versions ultérieures.

        2. Déterminez les paramètres de port WSUS dans IIS 6.0.

        3. Configurez les ports pour le point de mise à jour logicielle.

        4. Vérifier la connectivité des ports

          Pour vérifier la connectivité des ports à partir du client, exécutez la commande suivante :

          telnet SUPSERVER.CONTOSO.COM <portnumber>

          Par exemple, exécutez la commande suivante si le port est 8530 :

          telnet SUPSERVER.CONTOSO.COM 8530

          Si le port n’est pas accessible, telnet retourne une erreur semblable à celle-ci :

          Impossible d’ouvrir la connexion à l’hôte, sur le port <PortNumber>

          Cette erreur suggère que les règles de pare-feu ne sont pas configurées pour autoriser la communication pour l’ordinateur WSUS. Cette erreur peut également suggérer qu’un périphérique réseau intermédiaire bloque ce port. Pour vérifier, essayez le même test à partir d’un client sur le même sous-réseau local. Si cela fonctionne, les ordinateurs sont configurés correctement. Toutefois, un routeur ou un pare-feu entre les segments bloque le port et provoque l’échec.

      • Problèmes de disponibilité IIS.

        1. Sur l’ordinateur WSUS, ouvrez le Gestionnaire des services Internet (IIS).
        2. Développez Sites, cliquez avec le bouton droit sur le site web de l’ordinateur WSUS, puis cliquez sur Modifier les liaisons.
        3. Dans la boîte de dialogue Liaisons de site, les valeurs de port HTTP et HTTPS sont affichées dans la colonne Port .
        4. Sur le serveur WSUS, ouvrez le Gestionnaire des services Internet (IIS).
        5. Développez Sites web, cliquez avec le bouton droit sur le site web de l’ordinateur WSUS, puis cliquez sur Propriétés.
        6. Cliquez sur l’onglet Site web. Le paramètre de port HTTP s’affiche dans le port TCP et le paramètre de port HTTPS s’affiche dans le port SSL.
        7. Dans la console Configuration Manager, accédez aux serveurs de configuration>de site d’administration>et aux rôles de système de site, puis cliquez sur le< volet droit de SiteSystemName.>
        8. Dans le volet inférieur, cliquez avec le bouton droit sur Point de mise à jour logicielle, puis cliquez sur Propriétés.
        9. Accédez à l’onglet Général , spécifiez ou vérifiez les numéros de port de configuration WSUS.

  • Erreurs d'authentification

    Il est généralement indiqué lorsque l’analyse échoue avec des erreurs d’authentification 0x80244017 (état HTTP 401) ou 0x80244018 (état HTTP 403).

    Tout d’abord, vérifiez les paramètres de proxy WinHTTP corrects à l’aide des commandes suivantes :

    • Sur Windows Vista ou versions ultérieures : netsh winhttp show proxy
    • Sur Windows XP : proxycfg.exe

    Si les paramètres du proxy sont corrects, vérifiez la connectivité avec l’ordinateur WSUS en effectuant les étapes décrites dans les erreurs de délai d’expiration HTTP. Passez également en revue les journaux IIS sur l’ordinateur WSUS pour vérifier que les erreurs HTTP sont retournées par WSUS. Si l’ordinateur WSUS ne retourne pas l’erreur, le problème est probablement lié à un pare-feu ou un proxy intermédiaire.

  • Problèmes de certificat

    Les problèmes de certificat sont indiqués par le code d’erreur 0x80072F0C qui signifie qu’un certificat est requis pour terminer l’authentification du client. Pour résoudre ce problème, consultez Échec de l’analyse avec l’erreur 0x80072f0c.

Étape 4 : WUAHandler reçoit les résultats de l’agent Windows Update et marque l’analyse comme terminée

Les informations suivantes sont consignées WUAHandler.log :

Async searching completed.  
Finished searching for everything in single call.

Résoudre les problèmes à l’étape 4

Les problèmes ici doivent être résolus de la même façon que les échecs d’analyse à l’étape 3.

Comme mentionné précédemment dans ce guide, lors de la résolution des échecs d’analyse, vérifiez les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que l’agent Windows Update a signalé. Ainsi, l’erreur dans WUAHandler serait la même erreur que celle signalée par l’agent Windows Update lui-même. Vous trouverez plus d’informations sur l’erreur dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez les fichiers journaux Windows Update.

Il existe de nombreuses raisons pour lesquelles une analyse de mise à jour logicielle peut échouer. Cela peut être dû à l’un des problèmes mentionnés précédemment, ou à un problème de communication ou de pare-feu entre le client et l’ordinateur du point de mise à jour logicielle. Votre meilleure source d’informations provient des journaux et des codes d’erreur qu’ils contiennent. Pour plus d’informations sur les codes d’erreur, consultez Les erreurs courantes et l’atténuation de Windows Update.

Étape 5 : WUAHandler analyse les résultats de l’analyse

WUAHandler analyse ensuite les résultats, qui incluent l’état d’applicabilité pour chaque mise à jour. Dans le cadre de ce processus, les mises à jour remplacées sont supprimées. L’état d’applicabilité est vérifié pour toutes les mises à jour qui s’alignent sur les critères soumis par CCMExec à l’agent Windows Update. La chose importante à comprendre ici est que vous devez voir les résultats d’applicabilité pour les mises à jour si ces mises à jour se trouvent dans un déploiement ou non.

Les entrées suivantes sont consignées WUAHandler.log :

> Pruning: update id (70f4f236-0248-4e84-b472-292913576fa1) is superseded by (726b7201-862a-4fde-9b12-f36b38323a6f).  
> ...  
> Update (Installed): Security Update for Windows 7 for x64-based Systems (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104)  
> Update (Missing): Security Update for Windows 7 for x64-based Systems (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200)  
> ...  
> Successfully completed scan.

Résoudre les problèmes à l’étape 5

Les problèmes peuvent être résolus de la même façon que les échecs d’analyse à l’étape 3.

Comme mentionné précédemment dans ce guide, lors de la résolution des échecs d’analyse, vérifiez les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que l’agent Windows Update a signalé. Ainsi, l’erreur dans WUAHandler serait la même erreur que celle signalée par l’agent Windows Update lui-même. Vous trouverez plus d’informations sur l’erreur dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez les fichiers journaux Windows Update.

En règle générale, il existe de nombreuses raisons pour lesquelles une analyse de mise à jour logicielle peut échouer. Cela peut être dû à l’un des problèmes mentionnés précédemment, ou à un problème de communication ou de pare-feu entre le client et l’ordinateur du point de mise à jour logicielle. Votre meilleure source d’informations provient des journaux et des codes d’erreur qu’ils contiennent. En guise de référence, consultez les erreurs courantes et l’atténuation de Windows Update.

Étape 6 : Mettre à jour le magasin enregistre l’état et déclenche un message d’état pour chaque mise à jour dans WMI

Une fois les résultats de l’analyse disponibles, ces résultats sont stockés dans le magasin de mises à jour. La banque de mises à jour enregistre l’état actuel de chaque mise à jour et crée un message d’état pour chaque mise à jour. Ces messages d’état sont transférés au serveur de site en bloc à la fin du cycle de création de rapports des messages d’état (qui est minutes, par défaut). Nous envoyons uniquement un message d’état dans les circonstances suivantes :

  • Un message d’état précédent n’a jamais été envoyé pour une mise à jour (entrée de journal : n’a pas été signalée avant, création d’une nouvelle instance).
  • L’état d’applicabilité d’une mise à jour a changé depuis l’envoi du dernier message d’état.

UpdatesStore.log afficher l’état pour la mise à jour manquante (KB2862152) enregistrée et un message d’état déclenché :

Processing update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) with ProductID = 0fa1201d-4330-4fa8-8ae9b877473b6441  
Update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) hasn't been reported before, creating new instance.  
Successfully raised state message for update (505fda07-b4f3-45fb-83d9-8642554e2773) with state (Missing).  
Successfully added WMI instance of update status (505fda07-b4f3-45fb-83d9-8642554e2773).

StateMessage.log indiquant l’état enregistré avec l’ID d’état 2 (manquant) :

Adding message with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 to WMI  
State message(State ID : 2) with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 has been recorded for SYSTEM

Conseil

Pour chaque mise à jour, une instance de la CCM_UpdateStatus classe est créée ou mise à jour et stocke l’état actuel de la mise à jour. La classe CCM_UpdateStatus se trouve dans l’espace de noms ROOT\CCM\SoftwareUpdates\UpdatesStore.

Résoudre les problèmes à l’étape 6

Les problèmes ici doivent être résolus de la même façon que les échecs d’analyse à l’étape 3.

Comme mentionné précédemment dans ce guide, lors de la résolution des échecs d’analyse, vérifiez les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que l’agent Windows Update a signalé. Ainsi, l’erreur dans WUAHandler serait la même erreur que celle signalée par l’agent Windows Update lui-même. Vous trouverez plus d’informations sur l’erreur dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez les fichiers journaux Windows Update.

En règle générale, il existe de nombreuses raisons pour lesquelles une analyse de mise à jour logicielle peut échouer. Cela peut être dû à l’un des problèmes mentionnés précédemment, ou à un problème de communication ou de pare-feu entre le client et l’ordinateur du point de mise à jour logicielle. Votre meilleure source d’informations provient des journaux et des codes d’erreur qu’ils contiennent. En guise de référence, consultez les erreurs courantes et l’atténuation de Windows Update.

Étape 7 : Les messages d’état sont envoyés au point de gestion

Lorsque WUAHandler reçoit correctement les résultats de l’agent Windows Update, il marque l’analyse comme terminée et enregistre le message suivant dans WUAHandler.log :

Async searching completed. WUAHandler  
Finished searching for everything in single call

Résoudre les problèmes à l’étape 7

Les problèmes ici doivent être résolus de la même façon que les échecs d’analyse à l’étape 3, bien que les échecs à ce stade soient probablement exposés dans le fichier WindowsUpdate.log spécifiquement. Pour comprendre comment lire WindowsUpdate.log, consultez les fichiers journaux Windows Update.

En règle générale, il existe de nombreuses raisons pour lesquelles une analyse de mise à jour logicielle peut échouer. Cela peut être dû à l’un des problèmes mentionnés précédemment, ou à un problème de communication ou de pare-feu entre le client et l’ordinateur du point de mise à jour logicielle. Votre meilleure source d’informations provient des journaux et des codes d’erreur qu’ils contiennent. En guise de référence, consultez les erreurs courantes et l’atténuation de Windows Update.

Synchronisation WSUS vers Microsoft Update

La synchronisation WSUS avec Microsoft Update est décrite dans les étapes suivantes. Confirmez chaque étape pour établir correctement l’emplacement du problème.

Étape 1 : La synchronisation commence par une requête planifiée ou manuelle

Lorsqu’une synchronisation est déclenchée, nous nous attendons à voir les messages suivants dans le SoftwareDistribution.log du serveur WSUS :

Pour la synchronisation manuelle :

Changew3wp.6AdminDataAccess.StartSubscriptionManuallySynchronization manually started  
Info WsusService.27EventLogEventReporter.ReportEvent  
EventId=382,Type=Information,Category=Synchronization,Message=A manual synchronization was started.

Pour la synchronisation planifiée :

InfoWsusService.10EventLogEventReporter.ReportEvent  
EventId=381,Type=Information,Category=Synchronization,Message=A scheduled synchronization was started.

Résoudre les problèmes de synchronisation manuelle à l’étape 1

  1. Vérifiez que le service WSUS est en cours d’exécution. Si une synchronisation manuelle a démarré mais reste à 0 %, c’est parce que le service WSUS (Update Services sur WSUS 3.x ; WSUSService sur Windows Server 2012 et versions ultérieures) est dans un état arrêté.

  2. Réinitialisez le cache MMC de la console WSUS en procédant comme suit :

    1. Fermez la console WSUS.
    2. Arrêtez le service WSUS (Update Services sur WSUS 3.x ; Service WSUS sur Windows Server 2012 et versions ultérieures).
    3. Accédez à %appdata%\Microsoft\mmc.
    4. Renommez wsus en wsus_bak.
    5. Démarrez le service WSUS.
    6. Ouvrez la console WSUS et essayez une autre synchronisation manuelle.

Résoudre les problèmes de synchronisation planifiée à l’étape 1

  1. Essayez une synchronisation manuelle à partir de la console WSUS.
  2. Si une synchronisation manuelle fonctionne correctement, vérifiez les paramètres de synchronisation planifiés.

Étape 2 : WSUS génère une connexion à Microsoft Update (MU)

Une fois la synchronisation démarrée, le serveur WSUS tente d’établir une connexion HTTP via WinHTTP. Tenez compte des facteurs suivants lors de la résolution des problèmes de connexion :

WSUS <=winhttp=> Entités <réseau => Internet

  • Existe-t-il une entité réseau (proxy, pare-feu, filtre de sécurité, et ainsi de suite) entre l’ordinateur hôte WSUS et Internet ?
  • Si un proxy existe et que le serveur WSUS est requis pour utiliser le proxy, le proxy est-il configuré dans les paramètres WSUS appropriés ?

Résoudre les problèmes de synchronisation manuelle à l’étape 2

  1. Vérifiez que le service WSUS est en cours d’exécution. Si une synchronisation manuelle a démarré mais qu’elle reste à 0 %, c’est parce que le service WSUS (Update Services sur WSUS 3.x ; Le service WSUS sur Windows Server 2012 et versions ultérieures) est dans un état arrêté.

  2. Réinitialisez le cache MMC de la console WSUS en effectuant les étapes suivantes :

    1. Fermez la console WSUS.
    2. Arrêtez le service WSUS (Update Services sur WSUS 3.x ; Service WSUS sur Windows Server 2012 et versions ultérieures).
    3. Accédez à %appdata%\Microsoft\mmc.
    4. Renommez wsus en wsus_bak.
    5. Démarrez le service WSUS.
    6. Ouvrez la console WSUS et essayez une autre synchronisation manuelle.

Résoudre les problèmes de synchronisation planifiée à l’étape 2

  1. Essayez une synchronisation manuelle à partir de la console WSUS.
  2. Si une synchronisation manuelle fonctionne correctement, vérifiez les paramètres de synchronisation planifiés.

Étape 3 : l’ordinateur WSUS reçoit des informations de produit et de classification de Microsoft Update et de toutes les métadonnées abonnées

Une fois que WSUS reçoit des informations de produit et de classification et toutes les métadonnées abonnées de Microsoft Update, la synchronisation WSUS est terminée.

Problèmes d’installation, de remplacement ou de détection avec des mises à jour spécifiques

Les problèmes de déploiement qui se produisent avec des mises à jour spécifiques peuvent être divisés en zones ci-dessous. Lorsque vous commencez à résoudre les problèmes, tenez compte des composants suivants associés à ces zones.

Zones (Areas) Installation Remplacement Détection
Composants
  • WUA
  • Mettre à jour le programme d’installation (services à base de composants (CBS), MSI)
  • CCMExec
 Mettre à jour les métadonnées
  • WUA
  • Mettre à jour les métadonnées
  • Programme d’installation de mise à jour (CBS, MSI)

Problèmes d’installation

Qu’est-ce que le programme d’installation (CBS, MSI, autre) ?

CBS

Pour les mises à jour qui s’appliquent à Windows Vista et versions ultérieures, CBS est utilisé pour gérer l’installation.

  1. Rassemblez le journal CBS (%Windir%\Logs\Cbs\Cbs.log) et effectuez une révision initiale pour obtenir des informations sur la cause de l’échec. La résolution des problèmes basés sur l’installation via les journaux CBS dépasse le cadre de ce guide. Pour plus d’informations, consultez Corriger les erreurs d’altération de Windows à l’aide de l’outil DISM ou System Update Readiness.
  2. La mise à jour s’installe-t-elle correctement en tant qu’utilisateur connecté ? Si c’est le cas, échoue-t-il uniquement lorsqu’il est installé dans le contexte système ? Dans ce cas, concentrez-vous sur la résolution des problèmes d’installation manuelle dans le contexte système.

MSI (Windows Installer)

Pour les mises à jour logicielles non Windows, MSI est utilisé pour gérer l’installation.

  1. Rassemblez et passez en revue les journaux MSI par défaut pour la mise à jour. Consultez l’article de la base de connaissances associé pour la mise à jour pour tout problème connu ou FAQ.

  2. Activez la journalisation Windows Installer et reproduisez l’échec.

    Lors de l’examen des journaux résultants, vérifiez la valeur de retour 3 dans le journal et les lignes qui précèdent cette entrée pour obtenir un aperçu de l’échec.

  3. Vérifiez si la même mise à jour ne parvient pas à s’installer manuellement dans le contexte du système local. Pour ce faire, utilisez les mêmes commutateurs d’installation qui ont échoué pendant le déploiement des mises à jour logicielles.

    En cas d’échec, testez l’installation en tant qu’utilisateur connecté avec les mêmes commutateurs d’installation. Vérifiez s’il s’agit d’un problème d’installation sous le système local. Si cela fonctionne, vous pouvez ensuite concentrer le problème sur la façon d’installer correctement la mise à jour à l’aide du contexte système local. Il peut nécessiter la vérification des conseils de déploiement administratif dans la Base de connaissances pour la mise à jour ou la mise à jour en ligne.

Problèmes de remplacement

Essayez d’isoler le problème lié au remplacement à l’aide des questions suivantes :

  1. Pour plus d’informations sur la façon de contrôler quand Configuration Manager expire une mise à jour, consultez les règles de remplacement.
  2. Si une mise à jour a expiré par Configuration Manager, Microsoft recommande que la dernière mise à jour de superseding soit déployée. Si vous devez toujours déployer les mises à jour expirées, elles peuvent être déployées en dehors d’un déploiement de mises à jour logicielles par le biais de la distribution de logiciels ou de la gestion des applications.
  3. Pour des questions relatives spécifiquement à la logique de remplacement d’une mise à jour, consultez d’abord l’article de la Base de connaissances pour la mise à jour pour plus d’informations. Vous pouvez également passer en revue le remplacement dans le catalogue Microsoft Update, la console WSUS ou la console Configuration Manager.

Problèmes de détection

Déterminer l’état de conformité par mise à jour sur un client

  1. Consultez l’article de la base de connaissances de mise à jour pour connaître les problèmes connus liés à la mise à jour.
  2. Exécutez l’action Cycle d’analyse des mises à jour logicielles sur le client Configuration Manager.
  3. Passez en revue les UpdatesStore.log et les WindowsUpdate.log.

Résoudre les problèmes d’applicabilité des mises à jour

  1. Vérifiez si des conditions préalables sont manquantes à l’aide de l’article de la Base de connaissances pour la mise à jour. Par exemple, la mise à jour nécessite-t-elle que l’application ou le système d’exploitation soit corrigé à un niveau spécifique du Service Pack ?
  2. Vérifiez que l’ID de mise à jour unique de la mise à jour en question correspond à ce qui est déployé. Par exemple, la mise à jour en question est-elle une mise à jour 32 bits, mais est ciblée sur un hôte 64 bits ?

Plus d’informations

Pour plus d’informations sur la configuration des mises à jour logicielles dans Configuration Manager, consultez les articles suivants :

Vous pouvez également publier une question dans notre forum de support Configuration Manager pour la sécurité, les mises à jour et la conformité ici.

Visitez notre blog pour obtenir toutes les dernières actualités, informations et conseils techniques sur Configuration Manager.