Gestion de mises à jour de logiciel dans Configuration Manager de résolution des problèmes


Utilisateurs à domicile: cet article est conçu uniquement pour les professionnels de l’informatique et les agents du support technique. Si vous avez besoin résoudre un problème, veuillez demander à la Communauté Microsoft.

À quoi sert ce guide ?

Ce guide vous aide à dépanner le processus de gestion de mise à jour de logiciel dans Microsoft System Center Configuration Manager, y compris l’analyse de mise à jour de logiciel client, les problèmes de synchronisation et les problèmes de détection de mises à jour spécifiques.

Les informations contenues dans ce guide s’applique à System Center 2012 Configuration Manager (ConfigMgr 2012), System Center 2012 R2 Configuration Manager (ConfigMgr 2012 R2) et toutes les versions du Gestionnaire de Configuration de la branche actuels.

À qui s'adresse-t-il ?

Ce guide est destiné aux professionnels de l’informatique qui ont besoin de comprendre, de diagnostiquer et de dépannage du processus de gestion des mises à jour de logiciel dans Microsoft System Center Configuration Manager.

Comment ça marche ?Elle est divisée en trois sections principales :

  • Analyse de la mise à jour du logiciel du client
  • WSUS à la synchronisation de Microsoft Update
  • Problèmes d’installation, le remplacement ou la détection avec mises à jour spécifiques

Ce guide suppose qu’un Point de mise à jour de logiciel a déjà été installé et configuré. Pour plus d’informations sur la configuration des mises à jour logicielles dans le Gestionnaire de Configuration, consultez les rubriques suivantes :

Configuration des mises à jour de logiciel dans Configuration Manager

Durée d'exécution estimée :

30 à 45 minutes.

Avant d’entrer dans les étapes de résolution des problèmes réels, il est important de souligner que peut paraître évident, mieux vous comprendrez le problème qu'auquel vous êtes confronté, plus rapide et plus simple que sera pour vous fournir une solution. Si vous êtes chargé de la résolution d’un problème que vous rencontrez vous-même, ou un problème signalé pour vous par une personne de votre organisation, il est recommandé que vous prenez et répondez aux questions suivantes :

  1. Ce qui n’est pas spécifiquement utilisation et/ou quel est votre objectif ?
  2. Quelle est la fréquence ou le motif pour le même problème ? Le problème est toujours lieu ?
  3. Comment que vous découvrez que le problème se produit ?
  4. A cela déjà fonctionné ? Dans ce cas, lorsque s’est il arrêté ? A rien modifier dans l’environnement droite avant qu’il ne fonctionne plus ?
  5. Quel est le pourcentage de clients sont affectés ?
  6. Ce qui a déjà été fait (le cas échéant) pour essayer de résoudre le problème ?
  7. Connaître la version exacte du client et la version du serveur. Ces systèmes ne sont à jour ?
  8. Les clients concerné ont en commun (par exemple, même sous-réseau, site AD, domaine, emplacement physique, site, système de site, etc.) ?

Connaissance et compréhension des réponses à ces questions vous mettront sur le meilleur chemin pour une résolution rapide et facile pour tout problème que vous rencontrez.

Si vous connaissez la zone spécifique au sein du processus de gestion des mises à jour de logiciel que vous souhaitez résoudre, sélectionnez ci-dessous. Cas de doute, commencez par analyse de mise à jour de logiciel Client et nous allons l’intégralité du processus du début à la fin.

Avant d’entrer dans les étapes de résolution des problèmes réels, il est important de souligner que peut paraître évident, mieux vous comprendrez le problème qu'auquel vous êtes confronté, plus rapide et plus simple que sera pour vous fournir une solution. Si vous êtes chargé de la résolution d’un problème que vous rencontrez vous-même, ou un problème signalé pour vous par une personne de votre organisation, il est recommandé que vous prenez et répondez aux questions suivantes :

  1. Ce qui n’est pas spécifiquement utilisation et/ou quel est votre objectif ?
  2. Quelle est la fréquence ou le motif pour le même problème ? Le problème est toujours lieu ?
  3. Comment que vous découvrez que le problème se produit ?
  4. A cela déjà fonctionné ? Dans ce cas, lorsque s’est il arrêté ? A rien modifier dans l’environnement droite avant qu’il ne fonctionne plus ?
  5. Quel est le pourcentage de clients sont affectés ?
  6. Ce qui a déjà été fait (le cas échéant) pour essayer de résoudre le problème ?
  7. Connaître la version exacte du client et la version du serveur. Ces systèmes ne sont à jour ?
  8. Les clients concerné ont en commun (par exemple, même sous-réseau, site AD, domaine, emplacement physique, site, système de site, etc.) ?

Connaissance et compréhension des réponses à ces questions vous mettront sur le meilleur chemin pour une résolution rapide et facile pour tout problème que vous rencontrez.

Si vous connaissez la zone spécifique au sein du processus de gestion des mises à jour de logiciel que vous souhaitez résoudre, sélectionnez ci-dessous. Cas de doute, commencez par analyse de mise à jour de logiciel Client et nous allons l’intégralité du processus du début à la fin.

Le processus d’analyse client est indiqué dans les étapes suivantes. Vérifiez chaque étape afin d’établir correctement l’où le problème est.

La première chose que le client n’est définie le serveur WSUS à sa source de mise à jour pour les analyses de mise à jour de logiciel. Ce processus est détaillé ci-dessous.

ScanAgent.log:

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

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ée dans WMI dans la classe CCM_ScanJobInstance :

Namespace : root\CCM\ScanAgent classe : CCM_ScanJobInstance

LocationServices.log:

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}   

CcmMessaging.log:

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

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

Générateur de profils SQL :

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'  

 

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>  

 

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'  

 

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}  

 

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  

 

WUAHandler.log (* nouveau Client affichant ajouté une nouvelle Source de mise à jour) :
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 changeWaiting for 30 secs for policy to take effect on WU Agent.  Added Update Source ({UpdateSource}) of content type: 2  

 

Pendant ce temps, l’Agent de mise à jour Windows voit une configuration de WSUS de modifier :

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éfinissez :

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AUUseWUServer (ce doit être une valeur Dword de 1)
  • WUServer HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate (ce doit être une valeur de chaîne qui est l’URL du serveur WSUS complet y compris le port)
  • WUStatusServer (ce doit être une valeur de chaîne qui est l’URL du serveur WSUS complet y compris le port)

 

Exemple :

Nom de la clé : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

Nom de la valeur : WUServer

Type : REG_SZ

Données : http://PS1Site.Contoso.com:8530

 

Nom de la valeur : WUStatusServer

Type : REG_SZ

Données : http://PS1Site.Contoso.com:8530

 

Nom de la clé : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU

Nom de la valeur : UseWUServer

Type : REG_DWORD

Données : 0 x 1

 

 

Remarque : Pour un client existant, nous pouvons nous attendre à voir ce qui suit dans WUAHandler.log pour indiquer lorsque la version du contenu est incrémentée :

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

 

ScanAgent.log:

ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2 ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
  1. Lorsque le client Configuration Manager doit traiter une analyse de mise à jour de logiciel, analyse de l’Agent crée une demande d’analyse basée sur la stratégie disponible, comme indiqué ici :
  2. Analyse envoie maintenant de l’Agent une WSUS emplacement demande de Services de localisation comme indiqué ici :
  3. Services de localisation crée un emplacement de la demande et l’envoie au point de gestion. L’ID de package pour une demande d’emplacement de WSUS est l’ID Unique de mise à jour Source.
  4. CCM de messagerie envoie le message de demande d’emplacement du point de gestion :
  5. Le point de gestion traite cette demande et appelle la procédure stockée de MP_GetWSUSServerLocations pour obtenir les emplacements de WSUS à partir de la base de données :
  6. Après avoir obtenu les résultats de la procédure stockée, le point de gestion envoie une réponse au client :
  7. CCM de messagerie reçoit la réponse et l’envoie aux Services d’emplacement :
  8. Services de localisation analyse la réponse et envoie l’emplacement à analyser de l’Agent :
  9. Agent d’analyse a désormais la stratégie et l’emplacement source de mise à jour avec la version appropriée du contenu.
  10. Analyser l’Agent avertit WUAHandler pour ajouter la source de mise à jour. WUAHandler ajoute la source de mise à jour dans le Registre et 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 que nous venons d’ajouter.
  11. Une fois l’updatesource est ajouté avec succès, Agent d’analyse déclenche une analyse de Message d’état et d’initiatesthe :

Résolution des problèmes

Journal des problèmes Que se passe-t-il à vérifier
ScanAgent.log indique aucune stratégie disponible pour une Source de mise à jour et aucune WUAHandler.log existe ou aucune activité en cours dans WUAHandler.log Vérifiez les mises à jour de logiciel activer sur la définition des clients. Pour plus d’informations, consultez le document de TechNet suivant : Sur les paramètres de Client dans Configuration Manager
ScanAgent/LocationServices ne reçoivent aucun emplacement du serveur WSUS Un rôle de Point de mise à jour logicielle (SUP) est installé pour ce site ? Si ce n’est pas le cas, installer et configurer un Point de mise à jour de logiciel et surveiller le fichier SUPSetup.log pour le cours. Pour plus d’informations, consultez : Installer et configurer un Point de mise à jour de logiciel Si un rôle SUP est installé, est configuré et la synchronisation ? Recherchez les erreurs WCM.log, WSUSCtrl.log et WSyncMgr.log . Sélectionner * à partir de WSUSServerLocations Sélectionnez * à partir de Update_SyncStatus
Client reçoit l’emplacement de WSUS, mais ne parvient pas à configurer les clés de Registre WSUS Actualisation de la stratégie de groupe n’a répondu dans le délai d’attente de 2 minutes par WUAHandler.log? Si tel est le cas, WUAHandler fait référence à « paramètres de stratégie de groupe ont été remplacés par une autorité supérieure (contrôleur de domaine) » ? Recherchez un objet de stratégie de groupe qui est définie dans le domaine.

 

 

 

Une fois que le client a identifié et configurer le serveur WSUS à sa source de mise à jour pour les analyses de mise à jour de logiciel, analyse de l’Agent demande ensuite l’analyse à partir de WUAHandler qui utilise l’API de l’Agent de mise à jour de Windows pour demander une mise à jour analyser à partir de l’Agent Windows Update. Une analyse de risque à partir d’une analyse de la mise à jour logicielle planifiée ou manuelle, d’une réévaluation du déploiement manuelle ou planifiée logicielle mise à jour ou d’un déploiement qui devenue actif qui déclenche une évaluation.

ScanAgent.log:

 

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

WUAHandler.log:

Analyser les résultats comprennent des mises à jour remplacées uniquement lorsqu’elles sont remplacées par les service packs et les mises à jour de définition.

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 Consultez WUAHandler.log après une mise à jour du logiciel d’analyse pour voir si toutes les nouvelles écritures se produisent. Si aucune nouvelle entrée ne se produit, cela peut indiquer ne qu’aucun SUP renvoyé par le Point de gestion.

Résolution des problèmes

Un certain nombre de problèmes liés à l’analyse de mise à jour logicielle peut être provoqué par les clés de Registre ou des fichiers manquants ou endommagés, ou par des problèmes d’enregistrement de composant. Ceux-ci sont réparables, l’utilitaire de mise à jour Windows, mise à jour de l’Agent de mise à jour de Windows ou de la réinitialisation du magasin de données de l’Agent de mise à jour de Windows :

La résolution des problèmes de mise à jour de Windows :

2714434 - description de la résolution des problèmes de mise à jour de Windows (http://support.microsoft.com/kb/2714434)

Mise à jour de l’Agent de mise à jour de Windows :

949104 - comment mettre à jour l’Agent Windows Update à la version la plus récente (http://support.microsoft.com/kb/949104)

Si le client exécute une version antérieure de l’Agent de mise à jour de Windows, n’oubliez pas qu’il y a un problème dans lequel un client de ConfigMgr 2012 R2 de Windows 7 32 bits demande une analyse de la mise à jour échoue pour retourner les résultats de l’analyse vers le Gestionnaire de Configuration. Ainsi, le client pour indiquer l’état incorrect de la conformité et les mises à jour ne pas s’installer lorsque le Gestionnaire de Configuration de demande le cycle de mise à jour. Toutefois, si vous utilisez le panneau de configuration Windows Update, les mises à jour installera généralement très bien. Si vous rencontrez ce problème, vous devriez remarquer un message semblable au suivant dans WindowsUpdate.log:

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

Fondamentalement, c’est un problème d’allocation de mémoire, donc les ordinateurs Windows 7 64 bits ne verront pas cette erreur car leur espace d’adressage est effectivement illimitée. Ils, cependant, présentera élevée de la mémoire et l’utilisation élevée du processeur, éventuellement affecter les performances. Notez que x86 clients présente également l’utilisation de mémoire haute (en général environ 1,2 à 1,4 Go).

Pour plus d’informations sur ce problème particulier, consultez l’article suivant :

Conseil de prise en charge : Analyse de mise à jour de ConfigMgr 2012 échoue et provoque l’état de conformité incorrect

Heureusement, il existe un correctif pour ce problème ici :

3050265 - Windows mise à jour Client pour Windows 7 : juin 2015 (https://support.microsoft.com/en-us/kb/3050265)

Réinitialisation de la banque de données de l’Agent Windows Update :

Pour réinitialiser la banque de données de l’Agent Windows Update, procédez comme suit :

  1. Arrêtez le service de mise à jour de Windows en exécutant net stop wuauserv à partir d’une invite de commande.
  2. Renommez le dossier C:\Windows\SoftwareDistributionC:\Windows\SoftwareDistribution.old.
  3. Démarrez le service de mise à jour de Windows en exécutant net start wuauserv à partir d’une invite de commande.
  4. Initier un cycle d’analyse de mise à jour logicielle.

Résumé

Pour résumer, lors de la résolution des échecs d’analyse, les journaux que vous devez examiner sont WUAHandler.log et WindowsUpdate.log. WUAHandler signale simplement que signalés par l’Agent de mise à jour de Windows, l’erreur dans WUAHandler serait la même erreur a été signalée par l’Agent de mise à jour de Windows lui-même, donc plus d’informations sur l’erreur introuvable dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez l’article suivant de la base de connaissances :

902093 - comment lire le fichier Windowsupdate.log (https://support.microsoft.com/en-us/kb/902093)

Votre meilleure source d’informations proviendront les journaux et les codes d’erreur qu’ils contiennent. En tant que référence, vous trouverez la liste complète des codes d’erreur Windows Update ici :

938205 - liste de codes d’erreur Windows Update (http://support.microsoft.com/kb/938205)

 

Une fois demandée, Windows Update Agent (WUA) démarre l’analyse par rapport à son serveur WSUS configuré.

L’Agent Windows Update démarre une analyse après réception d’une demande du client Configuration Manager (CcmExec). Si ces valeurs de Registre sont correctement définies sur un ordinateur WSUS 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) comme suit :

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.asmxAgent ** 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}  

 

WindowsUpdate.log:

 

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ésolution des problèmes

Lors d’une analyse, l’Agent de mise à jour de Windows a besoin de communiquer avec les répertoires virtuels ClientWebService et SimpleAuthWebService sur l’ordinateur WSUS afin d’effectuer une analyse. Si le client ne peut pas communiquer avec l’ordinateur WSUS, l’analyse échouera. Cela peut se produire pour plusieurs raisons, y compris

  • Problèmes de proxy
  • Erreurs de délai d’attente HTTP
  • Erreurs d’authentification
  • Problèmes de certificat

Nous allons aborder chacune de ces ci-dessous.

Problèmes de proxy

L’Agent Windows Update utilise WinHTTP pour rechercher les mises à jour disponibles. Lorsqu’il existe un serveur proxy entre le client et l’ordinateur WSUS, les paramètres de proxy doivent être configurés correctement sur les clients pour leur permettre de communiquer avec les services WSUS à l’aide du nom de domaine complet. Dans le cas de problèmes de proxy, WindowsUpdate.log peut signaler des erreurs semblables aux suivantes :

0x80244021 or HTTP Error 502 - Bad gateway0x8024401B or HTTP Error 407 - Proxy Authentication Required0x80240030 - The format of the proxy list was invalid0x8024402C - The proxy server or target server name cannot be resolved

Dans la plupart des cas, vous pouvez ignorer le proxy pour les adresses locales dans la mesure où l’ordinateur WSUS se trouve probablement dans l’intranet quand même. Toutefois, si le client est connecté à Internet, vous devez vous assurer que le serveur proxy est configuré pour autoriser cette communication. Vous pouvez exécuter les commandes suivantes pour afficher les paramètres de proxy WinHTTP :

  • Sur Windows XP : proxycfg.exe
  • Sous Windows Vista ou version ultérieure : netsh winhttp afficher proxy

Bien que les paramètres de proxy configurés dans Internet Explorer dans les paramètres de proxy de WinINET, paramètres de proxy WinHTTP ne sont pas nécessairement le même que les paramètres de proxy définis dans Internet Explorer. Toutefois, si les paramètres de proxy sont définis correctement dans Internet Explorer, vous pouvez importer la configuration proxy à partir d’Internet Explorer à utiliser en tant que les paramètres de proxy WinHTTP. Pour importer la configuration proxy à partir d’Internet Explorer, exécutez la commande suivante :

  • Sur Windows XP : proxycfg.exe-u
  • Sur Windows Vista et ci-dessus : source de netsh winhttp import proxy = ie

Pour plus d’informations, consultez les rubriques suivantes :

900935 - comment le client Windows Update détermine quel serveur proxy à utiliser pour se connecter au site Web Windows Update

934864 - Microsoft DNS et l’utilisation de WINS pour enregistrement WPAD

DNS et la prise en charge DHCP de détection automatique des clients pare-feu et de Proxy Web : https://technet.microsoft.com/en-us/library/cc302584.aspx

Erreurs de délai d’attente de HTTP

Pour résoudre les erreurs de délai d’attente HTTP, tout d’abord examiner les journaux d’IIS sur l’ordinateur WSUS pour confirmer que les erreurs sont réellement renvoyés à partir de WSUS. Si l’ordinateur WSUS ne retourne pas l’erreur, le problème est probablement lié à un proxy ou un pare-feu intermédiaire.

Si l’ordinateur WSUS a renvoyé une erreur, vérifiez la connectivité avec l’ordinateur WSUS. Voici la procédure :

Pour confirmer que le client se connecte au serveur WSUS approprié, recherchez l’URL de l’ordinateur WSUS utilisé par le client de Windows Update Agent. Vous pouvez le trouver en vérifiant la clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate ou en consultant le fichier WindowsUpdate.log .

Raisons fréquentes pour lesquelles l’affectation de WSUS peut être incorrecte incluent des conflits de stratégie de groupe ou de l’ajout d’un SUP sur un site secondaire après l’installation initiale.

Remarque Stratégie de groupe Active Directory peut se substituer à la stratégie locale de WSUS

La fonctionnalité mises à jour logicielles configure automatiquement un paramètre de stratégie de groupe local pour le client Configuration Manager afin qu’il est configuré avec l’emplacement de source de Point de mise à jour de logiciels et d’un numéro de port. Le nom du serveur et le port numéro sont requises pour le client trouver le Point de mise à jour de logiciel.

Si un paramètre de stratégie de groupe Active Directory est appliqué aux ordinateurs pour l’installation du Point de mise à jour du logiciel client, il remplace le paramètre de stratégie de groupe local. De ce fait, si la valeur du paramètre est définie dans la stratégie de groupe d’annonces est différente de celle qui est définie par le Gestionnaire de Configuration, l’analyse échoue sur le client, car il ne peut pas localiser l’ordinateur WSUS approprié. Dans ce cas, WUAHandler.log affichera les éléments suivants :

Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://server and Policy ENABLED 

Le Point de mise à jour de logiciels pour les mises à jour d’installation et logiciel client doit être le même serveur et doit être spécifié dans le paramètre de stratégie de groupe Active Directory avec les informations de port et le format du nom correct. Par exemple, il serait http://server1.contoso.com:80 si le Point de mise à jour de logiciel a été à l’aide du site Web par défaut.

En supposant que le serveur de l’URL est correcte, d’accéder au serveur à l’aide d’une URL semblable à la suivante pour vérifier la connectivité entre le client et l’ordinateur WSUS :

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

Pour vérifier les whetherthe clients peuvent accéder au répertoire virtuel ClientWebService, essayez d’accéder au aURL semblable à celui-ci :

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

Pour vérifier si le client peut accéder à la SimpleAuthWebService, essayez d’accéder à une URL similaire à ceci :

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

Si un d'entre eux échoue, quelques-unes des raisons possibles sont les suivantes :

Échecs ici peuvent être dû à des problèmes de configuration de port et il est conseillé de vérifier que les paramètres du port sont corrects. WSUS peut être configuré pour utiliser un des ports suivants : 80, 443 ou 8530, 8531.

Pour les clients de communiquer avec l’ordinateur WSUS, les ports appropriés doivent être autorisées sur le pare-feu sur l’ordinateur WSUS. Les paramètres de port sont configurés lors de la création du rôle de système de site de Point de mise à jour de logiciels. Ces paramètres de port doivent être le même que les paramètres de port utilisés par le site Web de WSUS ou le Gestionnaire de synchronisation WSUS ne pourra pas se connecter à WSUS s’exécutant sur le Point de mise à jour de logiciels à la demande de 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 de logiciels.

Déterminer les paramètres de port WSUS utilisé dans IIS 7.0 et versions supérieures

Déterminer les paramètres de port WSUS dans IIS 6.0

Configurer des ports pour le Point de mise à jour de logiciels

Vérifiez la connectivité du port

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

Telnet SUPSERVER. CONTOSO.COM

Par exemple, si notre port était 8530 nous utilisez la commande suivante :

Telnet SUPSERVER. CONTOSO.COM 8530

Si le port n’est pas accessible, telnet retournera une erreur semblable au suivant :

Could not open connection to the host, on port <PortNumber>

 

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

  1. Assurez-vous que le client à l’aide de l’URL de droite
  2. Tester l’URL
    • Problèmes de résolution de nom 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. Reportez-vous à l’étape 1 ci-dessus.
    • Autres problèmes de connectivité liés au réseau.
    • Problèmes de configuration du port (voir ci-dessous).
    • Problèmes de disponibilité IIS.
    1. Sur l’ordinateur WSUS, ouvrez le Gestionnaire des Services Internet (IIS).
    2. Développez Sites, cliquez sur le site Web de l’ordinateur WSUS et 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és dans la colonne Port .
    1. Sur le serveur WSUS, ouvrez le Gestionnaire des Services Internet (IIS).
    2. Développez Sites Web, cliquez sur le site Web de l’ordinateur WSUS, puis cliquez sur Propriétés.
    3. 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 est affiché dans le port SSL.
    1. Dans la console Configuration Manager, accédez au volet Administration -> Configuration du Site -> les serveurs et les rôles de système de Site, puis cliquez sur dans le volet de droite de < SiteSystemName > .
    2. Dans le volet inférieur, cliquez droit sur le Point de mise à jour de logiciel et puis cliquez sur Propriétés.
    3. Accédez à l’onglet Général et spécifier/Vérifiez que les numéros de port de configuration de WSUS.

Erreurs d’authentification

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

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

  • Sous Windows Vista ou version ultérieure : netsh winhttp afficher proxy
  • Sur Windows XP : proxycfg.exe

En supposant que les paramètres de proxy sont corrects, de vérifier la connectivité avec l’ordinateur WSUS en suivant les étapes dans les Erreurs de délai d’expiration HTTP . Également passer en revue les journaux d’IIS sur l’ordinateur WSUS pour confirmer que les erreurs HTTP sont retournés à partir de WSUS. Si l’ordinateur WSUS ne retourne pas l’erreur, le problème est probablement lié à un proxy ou un pare-feu intermédiaire.

Problèmes de certificat

Les problèmes de certificat sont généralement indiquées par le code d’erreur 0x80072F0C qui signifie « un certificat est requis pour effectuer l’authentification du client. » Cette erreur doit se produire uniquement si l’ordinateur WSUS est configuré pour utiliser SSL. Dans le cadre de la configuration de SSL, les répertoires virtuels de WSUS doivent être configurés pour utiliser SSL et être défini sur « Ignorer » les certificats clients. Si le site Web de WSUS ou de l’un de ces répertoires virtuels sont correctement configuré pour « Accepter » ou « Exiger les certificats clients », vous recevrez cette erreur.

Suivez ces étapes pour résoudre les erreurs liées à des problèmes de certificats :

Vérifiez que le Point de mise à jour de logiciel est configuré pour SSL

  1. Dans la console Configuration Manager, accédez au volet Administration -> Configuration du Site -> les serveurs et les rôles de système de Site, puis cliquez sur < SiteSystemName > dans le volet de droite.
  2. Dans le volet inférieur, cliquez droit sur le Point de mise à jour de logiciel et puis cliquez sur Propriétés.
  3. Dans l’onglet Général , cliquez sur communication exiger SSL pour le serveur WSUS.

Vérifiez que l’ordinateur WSUS est configuré pour SSL

  1. Ouvrez la console WSUS sur le Point de mise à jour de logiciel pour le site.
  2. Dans le volet d’arborescence de la console, cliquez sur Options .
  3. Cliquez sur Source de mise à jour et serveur Proxy , dans le volet d’affichage.
  4. Vérifiez que l’option Utiliser SSL lors de la synchronisation des informations de mise à jour est activée.

Vérifiez que le certificat d’authentification serveur est ajouté au site Web d’Administration WSUS

Pour ajouter le certificat d’authentification serveur pour le site Web d’Administration WSUS, effectuez les opérations suivantes :

  1. Sur l’ordinateur WSUS, ouvrez le Gestionnaire des Services Internet (IIS).
  2. Développez Sites, cliquez sur Site Web par défaut, site Web d’Administration de WSUS si WSUS est configuré pour utiliser un site Web personnalisé, puis sélectionnez Modifier les liaisons.
  3. Cliquez sur l’entrée HTTPS et puis cliquez sur Modifier. .
  4. Dans la boîte de dialogue Modifier la liaison de Site , sélectionnez le certificat D’authentification serveur et puis cliquez sur OK.
  5. Cliquez sur OK dans la boîte de dialogue Modifier la liaison de Site , puis sur Fermer.
  6. Fermez le Gestionnaire Internet Information Services (IIS).

IMPORTANT Assurez-vous que le nom de domaine complet spécifié dans les propriétés de système de Site correspond au nom de domaine complet spécifié dans le certificat. Si le Point de mise à jour de logiciel accepte les connexions à partir de l’intranet uniquement, le nom du sujet ou autre nom du sujet doit contenir le nom de domaine complet de l’intranet. Lorsque le Point de mise à jour de logiciel accepte les connexions client à partir d’Internet, le certificat doit toujours contenir à la fois le nom de domaine Internet complet et le nom de domaine complet de l’intranet car WCM et WSyncMgr toujours utiliseront le nom de domaine complet de l’intranet pour vous connecter au Point de mise à jour de logiciels. Si le Point de mise à jour de logiciel accepte les connexions à partir d’Internet et l’intranet, à la fois le nom de domaine Internet complet et le nom de domaine complet de l’intranet doivent être spécifiés en utilisant le délimiteur entre les deux noms de symbole « et commercial » (&).

Vérifiez que SSL est configuré sur l’ordinateur WSUS

Le lien suivant s’applique à System Center Configuration Manager 2007, mais les mêmes étapes peuvent être utilisés pour configurer SSL sur WSUS dans Configuration Manager 2012 :

Comment faire pour configurer le Site Web WSUS pour utiliser SSL

IMPORTANT Vous ne pouvez pas configurer le site Web de WSUS ensemble afin d’exiger SSL, car alors tout le trafic vers le site WSUS doivent être cryptées. WSUS crypte uniquement les métadonnées de mise à jour. Si un ordinateur tente de récupérer les fichiers de mise à jour sur le port HTTPS, le transfert échouera.

WUAHandler reçoit les résultats de l’Agent de mise à jour de Windows et marque la tâche d’analyse complète.

WUAHandler.log:

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

Résolution des problèmes

Ici les problèmes doivent être traités de la même manière que des échecs d’analyse dans l’étape précédente.

Comme indiqué précédemment dans ce guide, lors du dépannage des échecs d’analyse, les journaux que vous devez examiner sont WUAHandler.log et WindowsUpdate.log. Car WUAHandler signale simplement que signalés par l’Agent de mise à jour de Windows, l’erreur dans WUAHandler serait la même erreur a été signalée par l’Agent de mise à jour de Windows lui-même, donc plus d’informations sur l’erreur se trouve dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez l’article suivant de la base de connaissances :

902093 - comment lire le fichier Windowsupdate.log

En règle générale, il y a plusieurs raisons peuvent expliquer pourquoi une analyse de la mise à jour de logiciel peut échouer. Il peut résulter d’un des problèmes mentionnés ci-dessus, ou il pourrait simplement baissent à un problème de pare-feu ou de communication entre le client et l’ordinateur du Point de mise à jour de logiciel. Votre meilleure source d’informations proviendront les journaux et les codes d’erreur qu’ils contiennent. En tant que référence, vous trouverez la liste complète des codes d’erreur Windows Update ici :

938205 - liste de codes d’erreur Windows Update

WUAHandler analyse ensuite les résultats, y compris l’état de l’application pour chaque mise à jour. Dans le cadre de ce processus, les mises à jour remplacées sont nettoyées. En outre, l’état de l’application est activée pour toutes les mises à jour qui s’alignent sur les critères soumis par CCMExec à l’Agent de mise à jour de Windows. L’important à comprendre ici est que vous devez voir les conditions d’application des résultats des mises à jour si ces mises à jour sont dans un déploiement ou non.

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ésolution des problèmes

Ici les problèmes doivent être traités de la même manière que des échecs d’analyse dans l’étape précédente.

Comme indiqué précédemment dans ce guide, lors du dépannage des échecs d’analyse, les journaux que vous devez examiner sont WUAHandler.log et WindowsUpdate.log. Car WUAHandler signale simplement que signalés par l’Agent de mise à jour de Windows, l’erreur dans WUAHandler serait la même erreur a été signalée par l’Agent de mise à jour de Windows lui-même, donc plus d’informations sur l’erreur se trouve dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez l’article suivant de la base de connaissances :

902093 - comment lire le fichier Windowsupdate.log

En règle générale, il y a plusieurs raisons peuvent expliquer pourquoi une analyse de la mise à jour de logiciel peut échouer. Il peut résulter d’un des problèmes mentionnés ci-dessus, ou il pourrait simplement baissent à un problème de pare-feu ou de communication entre le client et l’ordinateur du Point de mise à jour de logiciel. Votre meilleure source d’informations proviendront les journaux et les codes d’erreur qu’ils contiennent. En tant que référence, vous trouverez la liste complète des codes d’erreur Windows Update ici :

938205 - liste de codes d’erreur Windows Update

Mise à jour de banque enregistre l’état et génère un Message d’état pour chaque mise à jour dans WMI.

Une fois les résultats d’analyse sont disponibles, ces résultats sont stockés dans le magasin de mises à jour. Mise à jour de banque 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 vers le serveur de Site en vrac à la fin du cycle de rapport d’état du Message (ce qui est des minutes par défaut). Veuillez noter que nous envoyer 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 du journal : n’a pas été signalé avant, création d’instance)
  • L’état de l’application d’une mise à jour a été modifié depuis le dernier message d’état a été envoyé.

UpdateStore.log indiquant l’état manquant mise à jour (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 affichage d’état sollicités enregistrées avec l’état ID 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 classe CCM_UpdateStatus est créée ou mis à jour, et il stocke l’état actuel de la mise à jour. La classe CCM_UpdateStatus se trouve dans l’espace de noms ROOT\CCM\SoftwareUpdates\UpdatesStore.

Résolution des problèmes

Ici les problèmes doivent être traités de la même manière que des échecs d’analyse dans l’étape précédente.

Comme indiqué précédemment dans ce guide, lors du dépannage des échecs d’analyse, les journaux que vous devez examiner sont WUAHandler.log et WindowsUpdate.log. Car WUAHandler signale simplement que signalés par l’Agent de mise à jour de Windows, l’erreur dans WUAHandler serait la même erreur a été signalée par l’Agent de mise à jour de Windows lui-même, donc plus d’informations sur l’erreur se trouve dans WindowsUpdate.log. Pour comprendre comment lire WindowsUpdate.log, consultez l’article suivant de la base de connaissances :

902093 - comment lire le fichier Windowsupdate.log

En règle générale, il y a plusieurs raisons peuvent expliquer pourquoi une analyse de la mise à jour de logiciel peut échouer. Il peut résulter d’un des problèmes mentionnés ci-dessus, ou il pourrait simplement baissent à un problème de pare-feu ou de communication entre le client et l’ordinateur du Point de mise à jour de logiciel. Votre meilleure source d’informations proviendront les journaux et les codes d’erreur qu’ils contiennent. En tant que référence, vous trouverez la liste complète des codes d’erreur Windows Update ici :

938205 - liste de codes d’erreur Windows Update

Lorsque WUAHandler reçoit correctement les résultats à partir de Windows Update Agent, elle marque la tâche d’analyse complète et enregistre les éléments suivants :

WUAHandler.log:

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

Résolution des problèmes

Ici les problèmes doivent être traités de la même manière que des échecs d’analyse dans l’étape précédente, bien que les échecs à ce stade seront probablement soient facilement identifiables dans le fichier WindowsUpdate.log spécifiquement. Pour comprendre comment lire WindowsUpdate.log, consultez l’article suivant de la base de connaissances :

902093 - comment lire le fichier Windowsupdate.log

En règle générale, il y a plusieurs raisons peuvent expliquer pourquoi une analyse de la mise à jour de logiciel peut échouer. Il peut résulter d’un des problèmes mentionnés ci-dessus, ou il pourrait simplement baissent à un problème de pare-feu ou de communication entre le client et l’ordinateur du Point de mise à jour de logiciel. Votre meilleure source d’informations proviendront les journaux et les codes d’erreur qu’ils contiennent. En tant que référence, vous trouverez la liste complète des codes d’erreur Windows Update ici :

938205 - liste de codes d’erreur Windows Update

Synchronisation avec Microsoft Update WSUS est décrite dans les étapes suivantes. Vérifiez chaque étape afin d’établir correctement l’où le problème est.

Lorsqu’une synchronisation est déclenchée, nous prévoyons voir ce qui suit dans les SoftwareDistribution.log du serveur WSUS :

Manuelle :

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

PLANIFIÉE :

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

Résolution des problèmes

Synchronisation manuelle

  1. Confirmez que le service de theWSUS s’exécute.  Si vous voyez la thata la synchronisation manuelle a démarré mais qu’il reste à 0 %, il s’agit généralement car le service WSUS (« Services de mise à jour » sur WSUS 3.x ; « WSUSService » dans Windows Server 2012 +) qui est à l’état arrêté.
  2. Réinitialiser le cache de la console MMC Console WSUS en effectuant les opérations suivantes :

    1. Fermez la console WSUS
    2. Arrêtez le service WSUS (« Services de mise à jour » sur WSUS 3.x ; « Service WSUS » dans Windows Server 2012 +)
    3. Accédez à %appdata%\Microsoft\mmc
    4. Renommer « services wsus » à « wsus_bak »
    5. Démarrez le service WSUS
    6. Ouvrez la Console WSUS et essayez une autre synchronisation manuelle

Synchronisation planifiée

  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ée.

Après le démarrage d’une synchronisation, le serveur WSUS tente d’établir une connexion HTTP via WinHTTP. Lors du dépannage de la connexion, tenez compte des facteurs suivants :

WSUS < = winhttp = > <> = Internet d’entités réseau

Une entité réseau (proxy, pare-feu, filtre de sécurité, etc.) existe entre l’ordinateur hôte WSUS et Internet ?

Si un serveur proxy existe et que le serveur WSUS est requis pour utiliser le serveur proxy, le proxy est configuré dans les paramètres corrects de WSUS ?

Résolution des problèmes

Synchronisation manuelle

  1. Vérifiez que le service WSUS est en cours d’exécution. Si vous voyez qu’une synchronisation manuelle a démarré mais qu’il reste à 0 %, il s’agit généralement car le service WSUS (« Services de mise à jour » sur WSUS 3.x ; « Service WSUS » dans Windows Server 2012 +) qui est à l’état arrêté.
  2. Réinitialiser le cache de la console MMC Console WSUS en effectuant les opérations suivantes :
    1. Fermez la console WSUS
    2. Arrêtez le service WSUS (« Services de mise à jour » sur WSUS 3.x ; « Service WSUS » dans Windows Server 2012 +)
    3. Accédez à %appdata%\Microsoft\mmc
    4. Renommer « services wsus » à « wsus_bak »
    5. Démarrez le service WSUS
    6. Ouvrez la Console WSUS et essayez une autre synchronisation manuelle

Synchronisation planifiée

  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ée.

Une fois que WSUS reçoit le produit et les informations de classification et de métadonnées auquel vous êtes abonnée à partir de Microsoft Update, la synchronisation de WSUS est terminée.

Problèmes de déploiement qui se produisent avec les mises à jour spécifiques peuvent être réparties dans les zones ci-dessous. Lorsque vous commencez le dépannage, prendre en compte les éléments suivants associés à ces zones.

Zones ->InstallationRemplacementDétection
Composants ->Windows Update Agent mise à jour d’installation (CBS, MSI) CCMExecMettre à jour des métadonnéesProgramme d’installation de mise à jour des métadonnées de mise à jour Windows Update Agent (CBS, MSI)

Quel est le programme d’installation (CBS, MSI, autres) ?

Obligations convertibles (composant en fonction de l’entretien) :

Les mises à jour qui s’appliquent au système d’exploitation Windows (Windows Vista en cours), CBS permet de gérer l’installation.

  1. 1 rassembler le journal CBS (% Windir%\Logs\Cbs\Cbs.log) et d’effectuer un aperçu de gain de révision initiale dans la cause de l’échec. Résolution des problèmes d’installation basée via les journaux des obligations convertibles sont au-delà de la portée de cet utilitaire, toutefois, l’article suivant de la Base de connaissances peut aider :947821 - erreurs de corruption de corriger de Windows à l’aide de l’outil DISM ou de préparation de mise à jour système
  2. La mise à jour est installé correctement en tant qu’un utilisateur connecté ? Si il est installé correctement en tant qu’un utilisateur connecté, il n’échoue lors de l’installation dans le contexte système ? Si tel est le cas, se concentrer sur la résolution des problèmes liés à l’échec d’une installation manuelle dans le contexte système.
MSI (Windows Installer) :
Pour les mises à jour de Windows non MSI permet de gérer l’installation.
  1. Rassembler et passez en revue les fichiers journaux par défaut pour la mise à jour. Consultez l’article correspondant de la base de connaissances pour la mise à jour pour les problèmes connus/FAQ.
  2. Enregistrement d’étendre Windows Installer et reproduire la défaillance. Consultez l’article suivant de la Base de connaissances pour plus d’informations :223300 - comment faire pour activer la journalisation de Windows Installerlorsque vous examinez les journaux qui en résulte, recherchez dans le journal et les lignes précédant cette entrée pour un aperçu de l’échec de la valeur de retour 3.
  3. Vérifiez si la même mise à jour échoue à installer manuellement dans le contexte du système local à l’aide des mêmes commutateurs d’installation a échoué lors du déploiement de la mise à jour de logiciel. En cas d’échec, testez l’installation comme étant l’utilisateur connecté avec les commutateurs d’installation même à comprendre s’il s’agit d’un problème avec l’installation sur le système local. Si cela fonctionne, le problème peut puis se concentrer sur la manière d’installer correctement la mise à jour en utilisant le contexte du système local. Cela peut nécessiter la recherche des conseils de déploiement administratif dans la base de connaissances pour la mise à jour ou en ligne.

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

  1. Pour les questions sur le contrôle lorsque le Gestionnaire de Configuration expire à une mise à jour, consultez la section « Règles de remplacement » ici : https://technet.microsoft.com/en-us/library/gg712312.aspx
  2. Si une mise à jour a expiré par Configuration Manager, Microsoft recommande de déployer la mise à jour plus récente de remplacement. Si vous avez besoin déployer les mises à jour expirées, il peuvent être déployés en dehors d’un déploiement de mise à jour de logiciels via la gestion d’application/de distribution de logiciels.
  3. Pour les questions concernant spécifiquement la logique de remplacement d’une mise à jour, vous devez prendre l’article de la base de connaissances pour la mise à jour pour plus d’informations. Vous pouvez également consulter le remplacement dans la console Configuration Manager, console WSUS ou du catalogue Microsoft Update.

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

  1. Consultez l’article de la mise à jour KB des problèmes connus avec la mise à jour.
  2. Exécuter l’action « Cycle d’analyse de logiciel mises à jour » sur le client Configuration Manager.
  3. Consultez UpdatesStore.log et WindowsUpdate.log.

Résolution des problèmes d’applicabilité de la mise à jour

  1. Vérifiez si tous les composants requis sont manquants pour la mise à jour à l’aide de la base de connaissances. Par exemple, la mise à jour ne nécessite pas l’application ou le système d’exploitation sont corrigés pour être à un niveau de pack de service spécifique ?
  2. Vérifiez que l’ID Unique de mise à jour de la mise à jour en question correspond à ce qui est déployé. Par exemple, est la mise à jour en question à un x86 mise à jour mais qui est ciblé pour un x64 hôte ?

Félicitations ! Votre problème de processus de gestion des mises à jour de logiciel a été résolu.

Pour plus d’informations concernant la configuration des mises à jour logicielles dans le Gestionnaire de Configuration, consultez les éléments suivants :

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

https://social.technet.microsoft.com/Forums/en-US/home?forum=configmanagersecurity

Visitez notre blog pour tous les les dernières news, informations et conseils techniques sur Microsoft System Center Configuration Manager :

https://blogs.technet.microsoft.com/configurationmgr