Suivre l’évaluation de la conformité des mises à jour logicielles
S’applique à : Configuration Manager
Avant de pouvoir déployer des mises à jour logicielles sur des clients, les clients doivent exécuter une analyse de conformité des mises à jour logicielles. Nous vous recommandons de laisser suffisamment de temps aux clients pour terminer les résultats d’analyse et de conformité des rapports afin de pouvoir passer en revue les résultats de conformité et déployer uniquement les mises à jour requises sur les clients.
Lorsque le point de mise à jour logicielle (SUP) est installé et synchronisé, une stratégie d’ordinateur à l’échelle du site est créée qui informe les ordinateurs clients que les mises à jour logicielles Configuration Manager ont été activées pour le site. Lorsqu'un client reçoit la stratégie de l'ordinateur, une analyse d'évaluation de la conformité est planifiée pour démarrer de façon aléatoire dans les deux heures suivantes. Lorsque l’analyse est démarrée, un processus de l’agent client des mises à jour logicielles efface l’historique de l’analyse, envoie une demande pour rechercher le serveur WINDOWS Server Update Services (WSUS) qui doit être utilisé pour l’analyse et met à jour la stratégie de groupe locale avec l’emplacement WSUS.
Pour obtenir une vue d’ensemble du processus d’évaluation de la conformité, consultez l’évaluation de conformité des mises à jour logicielles.
Stratégie d’analyse des mises à jour logicielles
Avant qu’un client puisse essayer d’analyser les mises à jour, il a besoin de la stratégie UpdateSource. Cette stratégie est créée sur le serveur de site après une synchronisation réussie du sup sup. Cette section explique comment cette stratégie est créée par le processus suivant :
Étape 1 : Après une synchronisation réussie, WSyncMgr met à jour la version du contenu et l’heure de la dernière synchronisation dans la base de données
Après une synchronisation réussie sur un site principal, WSyncMgr met à jour l’heure de la dernière synchronisation et la version du contenu dans la base de données pour le sup. Pour ce faire, exécutez la spProcessSUMSyncStateMessage procédure stockée. Dans l’exemple de trace SQL Server Profiler suivant, cette procédure stockée est exécutée pour mettre à jour la version de contenu vers 36 :
declare @Error int ; exec spProcessSUMSyncStateMessage N'2014-01-17 17:59:54', N’PS1', N'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}', 1, 0, '36', @Error output, N’PS1SITE. CONTOSO. COM'
Étape 2 : SMSDBMON est déclenché et supprime un . Fichier STN dans policypv.box
spProcessSUMSyncStateMessage met à jour le Update_SyncStatus tableau avec la nouvelle version de contenu et l’heure de synchronisation. Cette mise à jour de la Update_SyncStatus table déclenche SMSDBMON pour supprimer une <UpdateSource_UniqueID>. Le fichier STN (STN signifie Notification de l’outil d’analyse) dans policypv.box pour indiquer une modification dans la définition de l’outil d’analyse. Les informations suivantes sont consignées SMSDBMON.log :
RCV : UPDATE on Update_SyncStatus for UpdSyncStatus_iu [{C2D17964-BBDD-4339-B9F3-12D7205B39CC}][46680] SMS_DATABASE_NOTIFICATION_MONITOR
SND : E :\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}. STN (non zéro) [46680] SMS_DATABASE_NOTIFICATION_MONITOR
Étape 3 : Le fournisseur de stratégies crée ou met à jour la stratégie UpdateSource dans la base de données
La <UpdateSource_UniqueID>. Le fichier STN informe le fournisseur de stratégie qu’il doit se réveiller et mettre à jour la stratégie UpdateSource dans la base de données.
Les informations suivantes sont consignées PolicyPv.log :
Trouvé {C2D17964-BBDD-4339-B9F3-12D7205B39CC}. STN SMS_POLICY_PROVIDER
Ajout de l’ID de l’outil d’analyse {C2D17964-BBDD-4339-B9F3-12D7205B39CC} SMS_POLICY_PROVIDER
Ajout à la liste de suppression : E :\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}. STN SMS_POLICY_PROVIDER
Dans la trace SQL Server Profiler :
select PolicyID, PolicyAssignmentID, SourceCRC, PADBID from SettingsPolicy où SourceID = N’PS1' et SourceType = N’UpdateSource'
sélectionnez Version dans la stratégie où PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}'
IF EXISTS (select PolicyID from Policy where PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}') update Policy set Version = N'40.00' where PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}' ELSE insert Policy (PolicyID, Version) values (N'{d0855677- b0a6-4e33-9bd5-7b0d06f0a2be}', N'40.00')exec sp_describe_undeclared_parameters N’UPDATE Policy SET Body = @P1 where PolicyID = N'{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}''
IF EXISTS (select PADBID from PolicyAssignment where PADBID where PADBID = 16777218) update PolicyAssignment set Version = N'40.00', InProcess = 1, BodyHash = null where PADBID = 16777218 ELSE insert PolicyAssignmentID, PADBID, Version, Valeurs PolicyID (N'{375c8020-3cae-4736-89ca-ccf1ce6e3709}', 16777218, N'40.00', N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}')exec sp_describe_undeclared_parameters N’UPDATE PolicyAssignment SET Body = @P1 where PADBID = 16777218'
update PolicyAssignment set InProcess = 0, BodySignature = N’BodySignatureTruncated', TombstoneBodySignature = N’TombstoneBodySignatureTruncated<>', HashAlgOID = N'1.2.840.113549.1.1.11', HashAlgId = 32780, BodyHash = N’BodyHashTruncated><', TombstoneBodyHash = N’TombstoneBodyHashTruncated<>' où PADBID = 16777218<>
Pour afficher cette stratégie dans la base de données, exécutez la requête suivante :
SELECT CONVERT(XML, Body, 1), * FROM Policy WHERE PolicyID = (SELECT PolicyID FROM SettingsPolicy WHERE SourceType = 'UpdateSource')
Cette stratégie contient la version de contenu du serveur de mise à jour utilisée pour rechercher l’emplacement de l’ordinateur WSUS sur lequel le client peut analyser. Une fois cette stratégie créée ou mise à jour dans la base de données, les clients obtiennent la stratégie UpdateSource nouvelle ou mise à jour pendant le prochain cycle d’évaluation de stratégie.
Étape 4 : La stratégie est téléchargée et évaluée sur le client
Les informations suivantes sont consignées PolicyAgent.log sur le client :
Téléchargement réussi de la stratégie 'CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be} »,PolicySource="SMS :PS1 »,PolicyVersion="40.00"' PolicyAgent_ReplyAssignments
Stratégie 'CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be} »,PolicyVersion="40.00 »,PolicySource="SMS :PS1"' compilé avec succès PolicyAgent_PolicyDownload
Dans PolicyEvaluator.log sur le client :
Mise à jour de la stratégie CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be} »,PolicySource="SMS :PS1 »,PolicyVersion="40.00 » PolicyAgent_PolicyEvaluator
Stratégie appliquée CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be} »,PolicySource="SMS :PS1 »,PolicyVersion="40.00 » PolicyAgent_PolicyEvaluator
État de stratégie pour [CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be} »,PolicyVersion="40.00 »,PolicySource="SMS :PS1"] est actuellement [Actif] PolicyAgent_PolicyEvaluator
Pour rechercher la PolicyID stratégie UpdateSource sur un client, exécutez la requête WQL suivante :
- Espace de noms :
ROOT\ccm\Policy\Machine\RequestedConfig - Requête :
SELECT * FROM CCM_Policy_Policy5 WHERE PolicyCategory = 'UpdateSource'
Une fois cette stratégie compilée sur le client, les informations UpdateSource sont stockées dans la classe WMI suivante :
Espace de noms : ROOT\ccm\Policy\Machine\ActualConfig
Classe : CCM_UpdateSource
Conseil
Si vous comparez l’instance de CCM_UpdateSource classe sur le client avec le corps XML récupéré à partir de la table de stratégie, vous remarquerez que le contenu du code XML est identique à l’instance.
Étape 5 : l’agent d’analyse est averti que la stratégie UpdateSource est mise à jour
Les informations suivantes sont consignées ScanAgent.log sur le client :
À l’intérieur de CScanAgent ::Notify() ScanAgent
CScanAgent ::OnPolicyChange - Notification Policy InstanceModificationEvent reçue ScanAgent
Emplacement du serveur WSUS
Après avoir reçu la stratégie UpdateSource, le client a la configuration nécessaire pour lancer une analyse. Toutefois, les mises à jour de stratégie ne lancent pas d’analyses immédiates. Une analyse peut être déclenchée manuellement via le panneau de configuration Configuration Manager ou se produire automatiquement à l’heure planifiée suivante. À ce stade, le client localise l’ordinateur WSUS avec la version de contenu spécifiée dans la stratégie. Ce processus est très similaire à la façon dont le client trouve l’emplacement d’un point de distribution pour un package et une version spécifiques.
Étape 1 : l’agent d’analyse crée une demande d’analyse basée sur la stratégie disponible
Les informations suivantes sont consignées ScanAgent.log :
CScanAgent ::ScanByUpdates - Stratégie disponible pour UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC} ContentVersion=38 ScanAgent
CScanAgent ::ScanByUpdates - Ajout d’une stratégie à la version finale de la liste ScanRequest UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC}, Policy-ContentVersion=38, Required-ContentVersion=38 ScanAgent
Étape 2 : l’agent d’analyse envoie une demande pour l’emplacement WSUS aux services d’emplacement
L’agent d’analyse demande maintenant l’emplacement WSUS à partir des services d’emplacement et attend une réponse. Dans cet exemple, l’ID de demande d’emplacement est {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}. Les informations suivantes sont consignées ScanAgent.log :
À l’intérieur de CScanAgent ::P rocessScanRequest() ScanAgent
CScanJobManager ::Scan- entré ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::Initialize- entré ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::Scan- entré ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::RequestLocations- entré ScanAgent
- Demande d’emplacements de serveur WSUS à partir de LS pour {C2D17964-BBDD-4339-B9F3-12D7205B39CC} version 38 ScanAgent
- - -ID de demande d’emplacement = {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
CScanAgentCache ::P ersistInstanceInCache- Instance persistante CCM_ScanJobInstance ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : - - - - -Emplacements demandés pour ScanJobID={4CD06388-D509-46E4-8C00-75909EDD9EE8} (LocationRequestID={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}), traite la demande d’analyse une fois les emplacements disponibles. ScanAgent
Chaque travail d’analyse est stocké dans WMI dans la CCM_ScanJobInstance classe :
Espace de noms : root\CCM\ScanAgent
Classe : CCM_ScanJobInstance
Étape 3 : Location Services envoie la demande d’emplacement au point de gestion
Location Services crée une demande d’emplacement et l’envoie au point de gestion. L’ID de package d’une demande d’emplacement WSUS est l’ID unique UpdateSource. Les informations suivantes sont consignées LocationServices.log :
CCCMWSUSLocation ::GetLocationsAsyncEx LocationServices
Tentative de persistance de la demande d’emplacement WSUS pour ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' et ContentVersion='38' LocationServices
Requête d’emplacement WSUS persistante LocationServices
Tentative d’envoi d’une demande d’emplacement WSUS pour ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' LocationServices
WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"Content ID="{C2D17964-BBDD-4339-B9F3- 12D7205B39CC} » Version="38"></><AssignedSite SiteCode="PS1"/><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></WSUSLocationRequest> LocationServices
Demande d’emplacement créée et envoyée « {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} » pour le package {C2D17964-BBDD-4339-B9F3- 12D7205B39CC} LocationServices
Étape 4 : CCM Messaging envoie le message de demande d’emplacement au point de gestion
Les informations suivantes sont consignées CcmMessaging.log :
Envoi d’un message asynchrone « {76453CC6-76BA-4B68-BE30-BA70754570BB} » à la file d’attente sortante « mp :[http]mp_locationmanager » CcmMessaging
Envoi du message sortant « {76453CC6-76BA-4B68-BE30-BA70754570BB} ». Indicateurs 0x200, compte d’expéditeur vide CcmMessaging
Étape 5 : Le point de gestion analyse la requête, obtient l’emplacement WSUS à partir de la base de données et envoie une réponse
Le point de gestion analyse cette requête et appelle la MP_GetWSUSServerLocations procédure stockée pour obtenir les emplacements WSUS de la base de données. Les informations suivantes sont consignées MP_Location.log :
MP LM : Corps du message : <WSUSLocationRequest SchemaVersion="1.00"CONTENT ID="{C2D17964-BBDD-4339-B9F3- 12D7205B39CC} » Version="38"></AssignedSite SiteCode="PS1"/ClientLocationInfo OnInternet="0"ADSite Name=""ADSite Name=""AssignedSite SiteCode="PS1"/><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></WSUSLocationRequest> MP_ LocationManager
MP LM : appel de MP_GetWSUSServerLocations MP_LocationManager
Dans la trace 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'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}',N'38',N’PS1',N’PS1',N’N'0',N’CONTOSO. COM'
Après avoir obtenu les résultats de la procédure stockée, le point de gestion envoie une réponse au client. Les informations suivantes sont consignées MP_Location.log :
MP LM : Corps du message de réponse :
<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>>< MP_LocationManager
Étape 6 : la messagerie CCM reçoit la réponse et la renvoie aux services d’emplacement
Le fichier CcmMessaging.log sur le client indique qu’une réponse a été reçue. Ce message a été remis aux services d’emplacement :
Message « {76453CC6-76BA-4B68-BE30-BA70754570BB} » a reçu la réponse « {8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C} » à la file d’attente de points de terminaison local « LS_ReplyLocations » CcmMessaging
OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={76453CC6-76BA-4B68-BE30-BA70754570BB}) : remis avec succès à l’hôte « PS1SYS.CONTOSO.COM ». CcmMessaging
Message « {8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C} » remis au point de terminaison « LS_ReplyLocations » CcmMessaging
Étape 7 : Location Services analyse la réponse et renvoie l’emplacement à l’agent d’analyse
Les informations suivantes sont consignées LocationServices.log :
Traitement du message de réponse locationServices 1/20/2014 12:18:09 PM
WSUSLocationReply : <WSUSLocationReply SchemaVersion="1.00"Sites><SITE><MPSite SiteCode="PS1"/><LocationRecords 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> LocationServices
Rappel avec les emplacements WSUS suivants LocationServices
Chemin WSUS ='http://PS1SITE.CONTOSO.COM:8530, Server='PS1SITE. CONTOSO. COM', Version='38' LocationServices
WSUS Path='https://PS1SYS.CONTOSO.COM:8531, Server='PS1SYS. CONTOSO. COM', Version='38' LocationServices
Rappel avec des emplacements pour la requête WSUS {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} LocationServices
Étape 8 : l’agent d’analyse avertit WUAHandler d’ajouter la source de mise à jour au Registre
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. Les informations suivantes sont consignées ScanAgent.log :
WSUSLocationUpdate reçu pour le guid de demande d’emplacement={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::OnLocationUpdate- Received Location=http://PS1SITE.CONTOSO.COM:8530, Version=38 ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::Execute- Adding UpdateSource={C2D17964-BBDD-4339-B9F3-12D7205B39CC}, ContentType=2, ContentLocation=http://PS1SITE.CONTOSO.COM:8530, ContentVersion=38 ScanAgent
L’agent d’analyse avertit WUAHandler d’ajouter la source de mise à jour. WUAHandler ajoute la source de mise à jour au Registre et lance une actualisation de stratégie de groupe (si le client est dans le domaine) pour déterminer si la stratégie de groupe remplace le serveur de mise à jour que nous venons d’ajouter. Les informations suivantes sont consignées WUAHandler.log sur un nouveau client montrant une nouvelle source de mise à jour ajoutée :
Son type de source de mise à jour WSUS ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}), l’ajoutant. WUAHandler
Il s’agit d’une nouvelle source de mise à jour WSUS. WUAHandler
Activation de la stratégie de serveur managé WUA pour utiliser le serveur :http://PS1SITE.CONTOSO.COM:8530WUAHandler
Actualisation de la stratégie forcée. WUAHandler
En attendant 2 minutes pour que la stratégie de groupe informe le changement de stratégie WUA... WUAHandler
Attendre 30 secondes pour que la stratégie prenne effet sur l’agent WU. WUAHandler
Ajout de la source de mise à jour ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) du type de contenu : 2 WUAHandler
Pendant ce temps, l’agent Windows Update voit une modification de configuration WSUS. Les informations suivantes sont consignées WindowsUpdate.log :
2014-01-20 12:18:11:520 968 9d0 Agent * Serveur WSUS :
http://PS1SITE.CONTOSO.COM:8530(Modifié)
2014-01-20 12:18:11:520 968 9d0 Agent * Serveur d’état WSUS :http://PS1SITE.CONTOSO.COM:8530(Modifié)
2014-01-20 12:18:11:520 968 9d0 AU Sus a changé par le biais de la stratégie.
Les clés de Registre suivantes sont vérifiées et définies :
| Sous-clé de Registre | Nom de la valeur | Type | Données |
|---|---|---|---|
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate |
WUServer | REG_SZ | URL complète du serveur WSUS, y compris le port. Par exemple, http://PS1Site.Contoso.com:8530 |
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate |
WUStatusServer | REG_SZ | URL complète du serveur WSUS, y compris le port. Par exemple, http://PS1Site.Contoso.com:8530 |
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU |
UseWUServer | REG_DWORD | 0x1 |
Pour un client existant, nous pouvons nous attendre à voir les éléments suivants dans WUAHandler.log indiquer quand la version du contenu a incrémenté :
Son type de source de mise à jour WSUS ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}), l’ajoutant. WUAHandler
La source de mise à jour WSUS existe déjà, elle a augmenté la version à 38. WUAHandler
Étape 9 : l’agent d’analyse lance l’analyse
Une fois la source de mise à jour ajoutée, l’Agent d’analyse déclenche un message d’état et lance l’analyse. Les informations suivantes sont consignées ScanAgent.log :
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : Raised UpdateSource ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) message d’état réussi. StateId = 2 ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - successfully requested Scan, ScanType=1 ScanAgent
Analyse des mises à jour logicielles sur les clients
Une fois la stratégie source de mise à jour et l’emplacement source de mise à jour disponibles, l’Agent d’analyse lance l’analyse. L’analyse des mises à jour logicielles est effectuée par l’agent Windows Update. Toutefois, le client Configuration Manager interagit avec l’agent Windows Update pour effectuer une analyse et obtenir les résultats de l’analyse. Cette interaction est gérée par le composant Gestionnaire de l’agent Windows Update (WUAHandler), qui communique avec l’agent Windows Update.
Étape 1 : l’agent d’analyse demande l’analyse et WUAHandler lance l’analyse
L’agent d’analyse demande l’analyse à partir de WUAHandler, qui utilise l’API de l’agent Windows Update pour demander une analyse de mise à jour logicielle auprès de l’agent Windows Update. Les informations suivantes sont consignées ScanAgent.log :
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - successfully requested Scan, ScanType=1 ScanAgent
Les informations suivantes sont consignées WUAHandler.log :
Les résultats de l’analyse incluent les mises à jour remplacées uniquement lorsqu’elles sont remplacées par les service Packs et les mises à jour de définition. WUAHandler
Critères de recherche est (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') WUAHandler
Exécution d’une analyse d’appel unique des mises à jour. WUAHandler
Recherche asynchrone des mises à jour à l’aide de WUAgent démarrée. WUAHandler
Étape 2 : Windows Update Agent (WUA) démarre l’analyse sur l’ordinateur WSUS
L’agent Windows Update démarre une analyse après avoir reçu une demande du client Configuration Manager (CcmExec). Étant donné que la valeur windows Update Server a déjà été définie sur le serveur SUP, cette analyse est effectuée sur le serveur WSUS sur lequel le rôle SUP est installé. Les informations suivantes sont consignées WindowsUpdate.log :
2014-01-20 12:18:42:694 3856 708 COMAPI -- START -- COMAPI : Search [ClientId = CcmExec]
2014-01-20 12:18:42:752 3856 708 COMAPI <<-- SOUMIS -- COMAPI : Search [ClientId = CcmExec]
2014-01-20 12:18:47:511 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, URL du serveur =http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12:18:48:662 968 f58 Agent ** START ** Agent : Recherche de mises à jour [CallerId = CcmExec]
2014-01-20 12:18:48:662 968 f58 Agent * Inclure les mises à jour potentiellement remplacées
2014-01-20 12:18:48:662 968 f58 Agent * En ligne = Oui ; Ignorer la priorité de téléchargement = Oui
2014-01-20 12:18:48:662 968 f58 Agent * Critères = « (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') »
2014-01-20 12:18:48:662 968 f58 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Géré
2014-01-20 12:18:48:662 968 f58 Agent * Étendue de recherche = {Machine}
L’agent Windows Update analyse désormais sur le serveur WSUS et signale les résultats à CcmExec (en particulier WUAHandler). Les informations suivantes sont consignées WindowsUpdate.log :
2014-01-20 12:18:49:175 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, URL du serveur =
http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12:18:52:680 968 f58 Agent * Ajout de la mise à jour {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 tosearch result
2014-01-20 12:18:52:683 968 f58 Agent * Ajout de la mise à jour {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 au résultat de la recherche
2014-01-20 12:18:52:694 968 f58 Agent * Trouvé 163 mises à jour et 70 catégories dans la recherche ; évalué appl. Règles de 622 sur 1150 entités déployées
2014-01-20 12:18:52:745 968 f58 Agent ** END ** Agent : Recherche de mises à jour [CallerId = CcmExec]
2014-01-20 12:18:52:755 3856 708 COMAPI >>-- REPRISE -- COMAPI : Search [ClientId = CcmExec]
2014-01-20 12:18:53:137 3856 708 COMAPI - Mises à jour trouvées = 163
2014-01-20 12:18:53:137 3856 708 COMAPI -- END -- COMAPI : Search [ClientId = CcmExec]
Étape 3 : WUAHandler reçoit les résultats de l’agent Windows Update et marque l’analyse comme terminée
Les informations suivantes sont consignées WUAHandler.log :
Recherche asynchrone terminée. WUAHandler
Fin de la recherche de tout en un seul appel. WUAHandler
Étape 4 : 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. Les informations suivantes sont consignées WUAHandler.log :
Pruning : update id (70f4f236-0248-4e84-b472-292913576fa1) est remplacé par (726b7201-862a-4fde-9b12-f36b38323a6f). WUAHandler
...
Mise à jour (installée) : Mise à jour de sécurité pour Windows 7 pour systèmes x64 (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104) WUAHandler
Mise à jour (manquante) : Mise à jour de sécurité pour Windows 7 pour systèmes x64 (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200) WUAHandler
...
Analyse réussie. WUAHandler
Étape 5 : Mettre à jour le magasin enregistre l’état et déclenche un message d’état pour chaque mise à jour dans WMI
Une fois les résultats de l’analyse disponibles, ces résultats sont stockés dans le magasin de mises à jour. La banque de mises à jour enregistre l’état actuel de chaque mise à jour et crée un message d’état pour chaque mise à jour. Ces messages d’état sont transférés au serveur de site en bloc à la fin du cycle de création de rapports des messages d’état (qui est de 15 minutes, par défaut).
UpdatesStore.log afficher l’état pour la mise à jour manquante (KB2862152) enregistrée et un message d’état déclenché :
Traitement de l’état de la mise à jour à partir de la mise à jour (505fda07-b4f3-45fb-83d9-8642554e2773) avec ProductID = 0fa1201d-4330-4fa8-8ae9- b877473b6441 UpdatesStore
L’état de mise à jour à partir de la mise à jour (505fda07-b4f3-45fb-83d9-8642554e2773) n’a pas été signalé avant, créant une nouvelle instance. UpdatesStore
Message d’état déclenché avec succès pour la mise à jour (505fda07-b4f3-45fb-83d9-8642554e2773) avec l’état (manquant). UpdatesStore
Ajout réussi de l’instance WMI de l’état de mise à jour (505fda07-b4f3-45fb-83d9-8642554e2773). UpdatesStore
StateMessage.log affichant le message d’état enregistré avec l’ID d’état 2 (manquant) :
Ajout de message avec TopicType 500 et TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 à WMI StateMessage
Message d’état(ID d’état : 2) avec TopicType 500 et TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 a été enregistré pour SYSTEM StateMessage
Pour chaque mise à jour, une instance de la CCM_UpdateStatus classe est créée ou mise à jour, et elle stocke l’état actuel de la mise à jour. La classe CCM_UpdateStatus se trouve dans l’espace de noms ROOT\CCM\SoftwareUpdates\UpdatesStore.
De même, une instance de la CCM_StateMsg classe est créée ou mise à jour et stocke l’état actuel de la mise à jour. La classe CCM_StateMsg se trouve dans l’espace de noms ROOT\CCM\StateMsg.
Étape 6 : Les messages d’état sont envoyés au point de gestion
Comme mentionné précédemment, les messages d’état sont envoyés au point de gestion en fonction de la planification du cycle de rapport des messages d’état, qui est configurée sur 15 minutes par défaut. Une fois qu’un message d’état est envoyé au point de gestion, la MessageSent propriété de l’instance de message d’état dans la CCM_StateMsg classe a la valeur True.
Dans StateMessage.log :
Corps StateMessage : <Xml Report Body Tronncated> StateMessage
Messages d’état transférés avec succès au mp StateMessage
Voici comment le corps du message d’état ressemble à notre mise à jour. Normalement, ce corps XML est trop volumineux pour le journal et est tronqué dans CMTrace. Toutefois, vous pouvez voir l’ensemble du corps XML dans le Bloc-notes.
Corps StateMessage : <?xml version="1.0 » encoding="UTF-16 » ?>
<><Report ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType 1</ClientType><>ClientID>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion 25.00.7958.1000></ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage 437</CodePage><>SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/< Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><version 1.0/Version>1.0</Version Format>><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000 » SerialNumber="232 »><Topic ID="505fda07-b4f3-45fb-83d9-8642554e2773 » Type="500 » IDType="3 » User=" » User=""SID=""/><State ID="2 » Criticality="0"/><UserParameters Flags="0 » Count="1"><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report> StateMessage
Messages d’état transférés avec succès au mp StateMessage
Flux de traitement des messages d’état
Nous savons maintenant comment un message d’état est enregistré et l’emplacement WMI où ces messages d’état sont stockés. Nous savons également que les messages d’état non envoyés sur un client sont envoyés au point de gestion toutes les 15 minutes par défaut, conformément au cycle de création de rapports des messages d’état. Cette planification peut être modifiée dans la messagerie d’état des paramètres client personnalisés ou par défaut.
Bien que StateMessage.log signale correctement les messages d’état transférés au MP, le composant Message d’état n’envoie pas réellement ces messages lui-même. Tous les messages envoyés et reçus à partir du point de gestion sont gérés par le composant De messagerie CCM sur le client. La messagerie CCM est le composant réel qui communique avec le point de gestion pour l’envoi et la réception de données. Le point de gestion comporte différentes files d’attente définies pour gérer différents types de trafic entrant. Pour les messages d’état, la file d’attente qui gère ce trafic est la MP_RelayEndpoint file d’attente.
Étape 1 : le composant Message d’état commence à envoyer des messages au point de gestion
Dans StateMessage.log :
Corps StateMessage : <?xml version="1.0 » encoding="UTF-16 » ?><><Report ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType 1</ClientType><>ClientID>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion 25.00.7958.1000></ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage 437</CodePage><>SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/< Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><version 1.0/Version>1.0</Version Format>><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000 » SerialNumber="232 »><Topic ID="505fda07-b4f3-45fb-83d9-8642554e2773 » Type="500 » IDType="3 » User=" » User=""SID=""/><State ID="2 » Criticality="0"/><UserParameters Flags="0 » Count="1"><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report> StateMessage
Messages d’état transférés avec succès au mp StateMessage
Étape 2 : CCM Messaging envoie un message contenant le corps XML du message d’état au point de gestion
La messagerie CCM envoie un message à la MP_RelayEndpoint file d’attente avec succès. Ce message n’a pas de réponse, contrairement à celui que nous avons remarqué précédemment dans la section Demande d’emplacement WSUS où le message avec la demande d’emplacement a reçu une réponse.
Dans CcmMessaging.log :
Envoi d’un message asynchrone « {95F79010-D0EB-49A6-8A1E-3897883105F2} » à la file d’attente sortante « mp :mp_relayendpoint » CcmMessaging
Envoi du message sortant « {95F79010-D0EB-49A6-8A1E-3897883105F2} ». Indicateurs 0x200, compte d’expéditeur vide CcmMessaging
POST : Host=PS1SYS. CONTOSO.COM, Path=/ccm_system/request, Port=443, Protocol=https, Flags=512, Options=480 CcmMessaging
Le message « {95F79010-D0EB-49A6-8A1E-389783105F2} » ne répond pas à CcmMessaging
OutgoingMessage(Queue='mp_mp_relayendpoint', ID={95F79010-D0EB-49A6-8A1E-3897883105F2}) : remis avec succès à l’hôte « PS1SYS.CONTOSO.COM ». CcmMessaging
Étape 3 : le message est reçu sur le point de gestion, puis MP_Relay traite le message et crée un fichier SMX
Comme tous les messages sont envoyés à l’aide de HTTP/HTTPS et reçus par IIS. Dans cet exemple, cette requête est adressée au répertoire virtuel CCM_System.
Dans le journal IIS :
192.168.2.12 CCM_POST /ccm_system/request - 443 - 192.168.2.62 ccmhttp - 200 0 0 542 31
Une fois le message reçu avec succès sur le point de gestion, le MP_Relay composant traite ce message, convertit le message en fichier SMX et déplace le fichier SMX vers l’emplacement approprié selon que le point de gestion est colocalisé sur le serveur de site ou non.
- Sur un point de gestion à distance : \SMS\mp\outboxes\StateMsg.box
- Sur un point de gestion colocalisé sur le serveur de site : \inboxes\auth\StateSys.box\incoming
Dans MP_Relay.log sur un point de gestion colocalisé sur le serveur de site :
Gestionnaire de messages Mp : démarrer le traitement des messages pour Relay----------------------- MP_RelayEndpoint
Gestionnaire de messages Mp : FileType=SMX MP_RelayEndpoint
Corps du message : <corps XML tronqué> MP_RelayEndpoint
Relais : dir de boîte de réception : E :\ConfigMgr\inboxes\auth\statesys.box\entrant MP_RelayEndpoint
Priorité dans le message = 5 MP_RelayEndpoint
Répertoire de priorité d’état = E :\ConfigMgr\inboxes\auth\statesys.box\entrant MP_RelayEndpoint
Inv-Relay : tâche terminée avec succès MP_RelayEndpoint
Dans MP_Relay.log sur un point de gestion à distance :
Gestionnaire de messages Mp : démarrer le traitement des messages pour Relay------------------------------ MP_RelayEndpoint
Gestionnaire de messages Mp : FileType=SMX MP_RelayEndpoint
Corps du message :
<?xml version="1.0 » encoding="UTF-16 » ?>
<><Report ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType 1</ClientType><>ClientID>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion 25.00.7958.1000></ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage 437</CodePage><>SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/< Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><version 1.0/Version>1.0</Version Format>><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000 » SerialNumber="232 »><Topic ID="505fda07-b4f3-45fb-83d9-8642554e2773 » Type="500 » IDType="3 » User=" » UserSID=""/><State ID="2 » Criticality="0"/><UserParameters Flags="0 » Count="1"><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report> MP_RelayEndpoint
Tâche Inv-Relay : traitement du corps du message MP_RelayEndpoint
Relais : dir de boîte de réception : C :\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Priorité dans le message = 5 MP_RelayEndpoint
Répertoire de priorité d’état = C :\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Inv-Relay : tâche terminée avec succès MP_RelayEndpoint
Le corps XML ressemble à ce qui est connecté StateMessage.log sur le client.
Étape 4 : le Gestionnaire de distribution de fichiers MP envoie le fichier SMX au serveur de site (uniquement lorsque le point de gestion n’est pas colocalisé sur le serveur de site)
Lorsque le point de gestion est distant vers le serveur de site, une fois que le fichier arrive dans les boîtes de réception\StateMsg.box, le Gestionnaire de répartition de fichiers MP (MPFDM) est responsable du déplacement de ces fichiers vers la boîte de réception StateMsg.box sur le serveur de site. Lorsque le point de gestion est colocalisé sur le serveur de site, ces fichiers sont déplacés directement vers le dossier de boîte de réception approprié, de sorte que MPFDM n’est pas impliqué.
Dans MPFDM.log sur un point de gestion à distance :
Fichier déplacé C :\SMS\MP\OUTBOXES\statemsg.box\TAZGYTSJ. SMX à \\PS1SITE.CONTOSO.COM\SMS_PS1\inboxes\auth\statesys.box\incoming\TAZGYTSJ. SMX SMS_MP_FILE_DISPATCH_MANAGER
Pour que MPFDM déplace les fichiers vers la boîte de réception appropriée, le point de gestion à distance doit être en mesure d’accéder au Registre du serveur de site pour déterminer les emplacements sources de la boîte de réception. Par conséquent, le service Registre distant doit être en cours d’exécution et l’accès au Registre ne doit pas être bloqué par la stratégie de groupe. MPFDM détermine les emplacements de la boîte de réception en accédant à la clé de Registre suivante sur le serveur de site :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Inbox Source
Étape 5 : le composant StateSys sur le serveur de site traite le message d’état dans la base de données
Une fois le fichier arrivé dans \inboxes\auth\StateSys.box sur le serveur de site, le composant State System Manager (StateSys) se réveille et traite le ou les fichiers SMX.
Dans StateSys.log avec la journalisation détaillée activée :
Notification de boîte de réception déclenchée, pause pendant 10 secondes...... SMS_STATE_SYSTEM
Nouveaux messages d’état à traiter, en commençant à traiter le thread de traitement SMS_STATE_SYSTEM
Thread « State Message Processing Thread #0 » id :4316 démarré SMS_STATE_SYSTEM
nombre total de chucks chargés (1) SMS_STATE_SYSTEM
CMessageProcessor - Fichier de traitement : YCE2H3VD. SMX SMS_STATE_SYSTEM
CMessageProcessor : 1 enregistrements traités avec 0 enregistrements non valides. SMS_STATE_SYSTEM
CMessageProcessor : 1 fichier de message traité dans ce lot, avec 0 fichiers incorrects. SMS_STATE_SYSTEM
nombre total de chucks chargés (0) SMS_STATE_SYSTEM
Thread « State Message Processing Thread #0 » id :4316 terminé normalement SMS_STATE_SYSTEM
Dans StateSys.log sans journalisation détaillée activée :
Nouveaux messages d’état à traiter, en commençant à traiter le thread de traitement SMS_STATE_SYSTEM
Thread « State Message Processing Thread #0 » id :1988 démarré SMS_STATE_SYSTEM
nombre total de chucks chargés (1) SMS_STATE_SYSTEM
nombre total de chucks chargés (0) SMS_STATE_SYSTEM
Thread « State Message Processing Thread #0 » id :1988 terminé normalement SMS_STATE_SYSTEM
Le fichier StateSys.log n’enregistre pas le nom du fichier, sauf si la journalisation détaillée est activée pour State System Manager.
Le fichier SMX déplacé vers le dossier StateSys.box contient le xml du corps du message. Lorsque StateSys traite ce fichier, il appelle la spProcessStateReport procédure stockée et transmet ce corps XML à la procédure stockée en tant que paramètre.
Dans la trace SQL Server Profiler :
exec dbo.spProcessStateReport N'< ?xml version="1.0 » encoding="UTF-16 » ?>
<><Report ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType 1</ClientType><>ClientID>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion 25.00.7958.1000></ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage 437</CodePage><>SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5/< Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType Full</ReportType><>Date>20140120220131.071000+000</Date><version 1.0/Version>1.0</Version Format>><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000 » SerialNumber="239 »><Topic ID="505fda07-b4f3-45fb-83d9-8642554e2773 » Type="500 » IDType="3 » User=" » User=""SID=""/><State ID="2 » Criticality="0"/><UserParameters Flags="0 » Count="1"><Param 200</Param><>/UserParameters></StateMessage></ReportBody></Report>'
spProcessStateReport est une procédure stockée CLR et la définition CLR a la logique pour déterminer le type de message d’état en cours de traitement. Selon le type de message d’état, il traite le message d’état de manière appropriée et insère les données dans la base de données.
Vous trouverez des noms conviviaux de tous les types de rubriques et ID de message d’état en interrogeant la table avec la SR_StateNames commande suivante :
SELECT * FROM SR_StateNames
Résumé des mises à jour logicielles
Avant que les données de conformité des mises à jour logicielles puissent être présentées dans la console ou les rapports, les données de conformité des mises à jour logicielles doivent être résumées. Cela est nécessaire, car la console et les rapports affichent généralement uniquement les données résumées. Le composant Système d’état sur le serveur de site effectue la synthèse des mises à jour logicielles, ainsi que le résumé pour d’autres composants, tels que les applications, les déploiements DCM et l’intégrité du client. Vous trouverez des informations sur toutes les tâches de synthèse effectuées par le système d’état en interrogeant la vSR_SummaryTasks vue dans la base de données Configuration Manager. State System exécute ces tâches selon une planification configurée et enregistre les détails de chaque tâche dans StateSys.log :
Tâche démarrée '< TaskName>' SMS_STATE_SYSTEM
La tâche «< TaskName> » s’est terminée correctement après l’exécution pendant 15 secondes, avec l’état 8. SMS_STATE_SYSTEM
Pour la plupart de ces tâches, l’état enregistré par StateSys.log n’est pas un code d’erreur. Au lieu de cela, il s’agit du nombre de lignes retournées par la procédure stockée SQL Server appropriée qui effectue le résumé.
Les tâches de synthèse spécifiques aux mises à jour logicielles sont les suivantes :
Évaluateur de conformité de l’affectation SUM
Résume les messages d’état pour toutes les affectations de groupe de mises à jour logicielles (déploiements). Cette tâche s’exécute toutes les heures par défaut. Il peut être lancé manuellement pour un déploiement spécifique dans les déploiements de surveillance>de console> Configuration Manager, cliquez avec le bouton droit sur le déploiement, puis cliquez sur Exécuter le résumé.
SUM Update Group Status Summarizer
Résume l’état des groupes de mises à jour. Cette tâche s’exécute toutes les heures par défaut. Il peut être lancé manuellement pour un groupe de mises à jour spécifique dans les groupes de mises à jour logicielles de la bibliothèque de logiciels de bibliothèque de logiciels de la bibliothèque >>de logiciels configuration Manager, cliquez avec le bouton droit sur le groupe de mises>à jour logicielles, puis cliquez sur Exécuter le résumé.
Vous pouvez également modifier la planification de cette tâche en cliquant avec le bouton droit sur groupes de mises à jour logicielles ou en sélectionnant Planifier le résumé dans le ruban.
SUM Update Status Summarizer
Résume l’état des mises à jour pour tous les clients. Cette tâche s’exécute toutes les heures par défaut. Il peut être lancé manuellement dans les mises à jour logicielles de la bibliothèque de logiciels de la>console> Configuration Manager, puis cliquez sur Exécuter le résumé. Vous pouvez également modifier la planification par défaut en sélectionnant Résumé de la planification.
État de la mise à jour SUM Migrate
Migre l’état de mise à jour en interne dans la base de données. Cette tâche s’exécute toutes les 24 heures par défaut. Elle ne peut pas être lancée manuellement à partir de la console Configuration Manager.
SUM Delete Aged Status
Supprime l’ancienne état des tables spécifiques à la mise à jour logicielle dans la base de données. Cette tâche s’exécute toutes les 24 heures par défaut. Elle ne peut pas être lancée manuellement à partir de la console Configuration Manager.
Basculement de point de mise à jour logicielle
Dans System Center 2012 Configuration Manager SP1 et versions ultérieures, un site peut avoir plusieurs suPs. Cela fournit une tolérance de panne pour les situations où un sup devient indisponible. Pour plus d’informations sur le basculement et le basculement des suPs, consultez les articles suivants :