Partager via


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

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 la base de connaissances d’origine : 4505440

Définir l’é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 la résolution des problèmes, il est important de souligner que, mieux vous comprenez le problème que vous rencontrez, plus il sera rapide et facile pour vous de le résoudre. Que vous soyez chargé de résoudre un problème que vous rencontrez ou un problème qui vous a été signalé par une personne de votre organization, 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 se produit-il toujours ?
  3. Comment avez-vous pris conscience de l’existence du problème ?
  4. Cela a-t-il déjà fonctionné ? Si oui, quand a-t-il été arrêté ? Quelque chose a-t-il changé dans l’environnement juste avant qu’il ne cesse de fonctionner ?
  5. Quel pourcentage de clients sont affectés ?
  6. Qu’est-ce qui a déjà été fait (le cas échéant) pour essayer de le corriger ?
  7. Connaître 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.

Le fait de connaître et de comprendre les réponses à ces questions vous mettra sur la meilleure voie pour résoudre rapidement et facilement le problème que vous rencontrez.

Si vous connaissez le domaine spécifique du processus de gestion des mises à jour logicielles que vous souhaitez résoudre, sélectionnez-le ci-dessous. Commencez par l’analyse des mises à jour logicielles clientes si vous n’êtes pas sûr et nous allons parcourir l’ensemble du processus du 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 déterminer correctement où se trouve le problème.

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

La première chose que fait le client 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 en fonction de 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 désormais une demande d’emplacement WSUS aux services de localisation, 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 pour 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. Ccm Messaging 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 à partir 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. Ccm Messaging reçoit la réponse et la renvoie aux services de localisation. 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. Les services d’emplacement analysent la réponse et renvoient 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 stratégie de groupe si le client se trouve dans le domaine pour voir si stratégie de groupe remplace le serveur de mise à jour ajouté. Les entrées suivantes sont enregistrées WUAHandler.log montrant une nouvelle source de mise à jour en cours d’ajout :

    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 Data
    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 pourrions nous attendre à voir le message suivant dans WUAHandler.log indiquer quand la version de contenu a été incrémentée :

    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 de l’étape 1

Problèmes Éléments à 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 .
L’agent d’analyse ou les services 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 la progression SUPSetup.log. 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 synchronisé ?

    Recherchez les erreurs WCM.log, WSUSCtrl.log et WSyncMgr.log.

    • 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 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 stratégie de groupe remplace les informations de configuration WSUS correctes.

Pour plus d’informations sur la résolution des échecs d’analyse des mises à jour logicielles, consultez Résoudre les échecs 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 à WUAHandler qui utilise l’API agent Windows Update pour demander une analyse des mises à jour logicielles à l’agent Windows Update. Une analyse peut résulter des résultats suivants :

  • Analyse planifiée ou manuelle des mises à jour logicielles
  • Une réévaluation de déploiement de logiciel planifiée ou manuelle mise à jour
  • Un 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 des Service Packs et des 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 de mise à jour logicielle pour voir si de nouvelles entrées se produisent. Si aucune nouvelle entrée ne se produit, cela indique qu’aucune sup n’est retournée par le point de gestion.

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

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

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

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

Il existe un problème connu : un client Windows 7 32 bits ConfigMgr 2012 R2 demandant une analyse de mise à jour ne parvient pas à retourner les résultats de l’analyse à Configuration Manager. Le client signale des status de conformité incorrectes et l’installation des mises à jour échoue lorsque Configuration Manager demande le cycle de mise à jour. Toutefois, si vous utilisez l’applet Windows Update panneau de configuration, les mises à jour s’installent généralement correctement. Lorsque vous rencontrez ce problème, vous recevez un message similaire au 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 autour de 1,2 Go à 1,4 Go).

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

Lors de la résolution des problèmes d’analyse, case activée les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que Windows Update Agent a signalé. Par conséquent, l’erreur dans WUAHandler est la même 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 Windows Update fichiers journaux.

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 Windows Update erreurs courantes et atténuation.

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

Windows Update Agent démarre une analyse après avoir reçu une requête du client Configuration Manager (CcmExec). Si ces valeurs de Registre sont correctement définies sur un ordinateur WSUS qui est un suppl 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 de l’étape 3

Pendant une analyse, l’agent Windows Update doit communiquer avec les ClientWebService répertoires virtuels et SimpleAuthWebService 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 É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, commencez par examiner les journaux IIS (Internet Information Services) sur l’ordinateur WSUS pour vérifier que les erreurs sont effectivement 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 les étapes à effectuer :

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

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

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

      Remarque

      Les stratégie de groupe Active Directory peuvent remplacer la stratégie WSUS locale.

      La fonctionnalité de mises à jour logicielles 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 trouve le point de mise à jour logicielle.

      Si un paramètre d’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 stratégie de groupe local. Si la valeur du paramètre défini dans le stratégie de groupe Active Directory est différente de celle définie par Configuration Manager, l’analyse échoue sur le client, car il 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és

      Le point de mise à jour logicielle pour l’installation du client et les mises à jour logicielles doit être le même serveur. Il doit également être spécifié dans le paramètre stratégie de groupe Active Directory avec le format de nom et les informations de port corrects. Par exemple, ce 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-ci pour vérifier la connectivité entre le client et l’ordinateur WSUS :

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

      Pour case activée 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 case activée si le client peut accéder à , SimpleAuthWebServiceessayez d’accéder à une URL similaire à celle-ci :

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

      Si l’une de ces URL échoue, voici quelques-unes des raisons possibles :

      • 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 du 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 de 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 de l’ordinateur WSUS. Les paramètres de port sont configurés lors de la création du rôle de système de site du point de mise à jour logicielle. 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 en cours d’exécution 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 case activée connectivité de port à 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 le 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 à Administration>Serveurs de configuration> de siteet rôles de système de site, puis cliquez sur le < volet de droite 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é quand 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 Erreurs de délai d’expiration HTTP. Examinez également 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 signalés par le code d’erreur 0x80072F0C qui signifie « 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 Windows Update Agent et marque l’analyse comme terminée

Les éléments suivants sont connectés WUAHandler.log :

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

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

Les problèmes 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 problèmes d’analyse, case activée les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que Windows Update Agent a signalé. Par conséquent, l’erreur dans WUAHandler serait la même 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 Windows Update fichiers journaux.

Il existe de nombreuses raisons pour lesquelles une analyse des mises à jour logicielles 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 Windows Update erreurs courantes et atténuation.

É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 des résultats d’applicabilité pour les mises à jour, que ces mises à jour soient dans un déploiement ou non.

Les entrées suivantes sont enregistré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 de 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 problèmes d’analyse, case activée les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que Windows Update Agent a signalé. Par conséquent, l’erreur dans WUAHandler serait la même 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 Windows Update fichiers journaux.

En règle générale, il existe de nombreuses raisons pour lesquelles une analyse des mises à jour logicielles 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 référence, consultez Windows Update erreurs courantes et l’atténuation.

Étape 6 : Le magasin de mises à jour enregistre la status 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 des mises à jour. Le magasin de mise à 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 de messages status (par défaut, en minutes). Nous n’envoyons un message d’état que 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 auparavant, créant une nouvelle instance).
  • L’état d’applicabilité d’une mise à jour a changé depuis l’envoi du dernier message d’état.

UpdatesStore.log indiquant l’état de mise à jour manquante (KB2862152) en cours d’enregistrement 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, un instance de la CCM_UpdateStatus classe est créé ou mis à jour, et il stocke la status actuelle de la mise à jour. La CCM_UpdateStatus classe se trouve dans l’espace de ROOT\CCM\SoftwareUpdates\UpdatesStore noms .

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

Les problèmes 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 problèmes d’analyse, case activée les fichiers WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement ce que Windows Update Agent a signalé. Par conséquent, l’erreur dans WUAHandler serait la même 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 Windows Update fichiers journaux.

En règle générale, il existe de nombreuses raisons pour lesquelles une analyse des mises à jour logicielles 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 référence, consultez Windows Update erreurs courantes et l’atténuation.

É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 de 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 en particulier. Pour comprendre comment lire WindowsUpdate.log, consultez Windows Update fichiers journaux.

En règle générale, il existe de nombreuses raisons pour lesquelles une analyse des mises à jour logicielles 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 référence, consultez Windows Update erreurs courantes et l’atténuation.

Synchronisation WSUS vers Microsoft Update

La synchronisation WSUS avec Microsoft Update est décrite dans les étapes suivantes. Confirmez chaque étape pour déterminer correctement où se trouve le problème.

Étape 1 : La synchronisation démarre par le biais d’une demande 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 à l’é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êter 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 d’une synchronisation planifiée à l’étape 1

  1. Essayez une synchronisation manuelle à partir de la console WSUS.
  2. Si une synchronisation manuelle fonctionne correctement, case activée les paramètres de synchronisation planifiée.

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

Après le démarrage d’une synchronisation, 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=> Network entities <=> 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 ?
  • S’il existe un proxy et que le serveur WSUS doit utiliser le proxy, le proxy est-il configuré dans les paramètres WSUS appropriés ?

Résoudre les problèmes d’une 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 à l’arrêt.

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

    1. Fermez la console WSUS.
    2. Arrêter 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 d’une synchronisation planifiée à l’étape 2

  1. Essayez une synchronisation manuelle à partir de la console WSUS.
  2. Si une synchronisation manuelle fonctionne correctement, case activée les paramètres de synchronisation planifiée.

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

Une fois que WSUS a reçu les 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 répartis dans les zones ci-dessous. Lorsque vous commencez à résoudre les problèmes, tenez compte des composants suivants associés à ces zones.

Zones Installation Remplacement Détection
Composants
  • WUA
  • Mettre à jour le programme d’installation (services à base de composants (CBS), MSI)
  • CCMExec
Mettre à jour des métadonnées
  • WUA
  • Mettre à jour des métadonnées
  • Mettre à jour le programme d’installation (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 aux 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 liés à l’installation via les journaux CBS dépasse le cadre de ce guide. Pour plus d’informations, consultez Corriger les erreurs d’endommagement de Windows à l’aide de DISM ou de l’outil De préparation des mises à jour système.
  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é sous le contexte Système ? Dans ce cas, concentrez-vous sur la résolution des problèmes d’échec de l’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 examinez 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, case activée la valeur de retour 3 dans le journal et les lignes précédant cette entrée pour obtenir des informations sur l’échec.

  3. Vérifiez si l’installation manuelle de la même mise à jour échoue 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 lors de l’installation sous le système local. Si cela fonctionne, vous pouvez alors concentrer le problème sur la façon d’installer correctement la mise à jour à l’aide du contexte système local. Il peut être nécessaire de vérifier les conseils de déploiement administratif dans la base de connaissances pour la mise à jour ou en ligne.

Problèmes de remplacement

Essayez d’isoler le problème lié au remplacement en utilisant les questions suivantes :

  1. Pour toute question sur la façon de contrôler le moment où Configuration Manager expire une mise à jour, consultez Règles de remplacement.
  2. Si une mise à jour a expiré par Configuration Manager, Microsoft recommande de déployer la dernière mise à jour de remplacement. 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 via la distribution de logiciels ou 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 examiner 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 la mise à jour pour connaître les problèmes connus liés à la mise à jour.
  2. Exécutez l’action Cycle d’analyse Mises à jour logiciel sur le client Configuration Manager.
  3. Passez en revue UpdatesStore.log et 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 de Service Pack spécifique ?
  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-elle 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 sur 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.