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 d’accorder suffisamment de temps aux clients pour effectuer l’analyse et signaler les résultats de conformité afin que vous puissiez examiner 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 pour informer les ordinateurs clients que Configuration Manager Software Mises à jour a été activé pour le site. Lorsqu’un client reçoit la stratégie de machine, une analyse d’évaluation de la conformité est planifiée pour démarrer de manière aléatoire dans les deux prochaines heures. Lorsque l’analyse est démarrée, un processus de l’agent client software Mises à jour efface l’historique d’analyse, envoie une demande pour rechercher le serveur Windows Server Update Services (WSUS) qui doit être utilisé pour l’analyse et met à jour le stratégie de groupe local avec l’emplacement WSUS.
Pour obtenir une vue d’ensemble du processus d’évaluation de la conformité, consultez Évaluation de la conformité des mises à jour logicielles.
Stratégie d’analyse des mises à jour logicielles
Avant qu’un client puisse essayer de rechercher des 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. 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 suppl. Pour ce faire, exécutez la spProcessSUMSyncStateMessage procédure stockée. Dans l’exemple SQL Server Profiler trace suivant, cette procédure stockée est exécutée pour mettre à jour la version de contenu vers la version 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 la Update_SyncStatus table avec la nouvelle version du contenu et l’heure de synchronisation. Cette mise à jour de la Update_SyncStatus table déclenche la suppression d’un <UpdateSource_UniqueID> par SMSDBMON. 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 éléments suivants sont connectés SMSDBMON.log :
RCV : MISE À JOUR sur Update_SyncStatus pour 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égie crée ou met à jour la stratégie UpdateSource dans la base de données
UpdateSource_UniqueID<>. Le fichier STN avertit 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 éléments suivants sont connectés 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 de à supprimer la liste : E :\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}. STN SMS_POLICY_PROVIDER
Dans SQL Server Profiler trace :
sélectionnez PolicyID, PolicyAssignmentID, SourceCRC, PADBID dans 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 (sélectionnez PolicyID dans Policy où 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 (sélectionnez PADBID dans PolicyAssignment where PADBID = 16777218) update PolicyAssignment set Version = N'40.00', InProcess = 1 , BodyHash = null where PADBID = 16777218 ELSE insert PolicyAssignment (PolicyAssignmentID, PADBID, Version, PolicyID) valeurs (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<>' where 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 qui est utilisée pour rechercher l’emplacement de l’ordinateur WSUS que 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 au cours du cycle d’évaluation de stratégie suivant.
Étape 4 : la stratégie est téléchargée et évaluée sur le client
Les éléments suivants sont connectés PolicyAgent.log sur le client :
Téléchargement 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"' correctement compilée 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
L’é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 trouver le PolicyID de la stratégie UpdateSource sur un client, exécutez la requête WQL suivante :
- 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 les 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 semble identique à celui du instance.
Étape 5 : L’agent d’analyse est averti que la stratégie UpdateSource est mise à jour
Les éléments suivants sont connectés ScanAgent.log sur le client :
Inside CScanAgent ::Notify() ScanAgent
CScanAgent ::OnPolicyChange- Policy InstanceModificationEvent notification reçue ScanAgent
Emplacement du serveur WSUS
Après avoir reçu la stratégie UpdateSource, le client dispose de 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 en fonction de la stratégie disponible
Les éléments suivants sont connectés ScanAgent.log :
CScanAgent ::ScanByUpdates- Policy available for UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC} ContentVersion=38 ScanAgent
CScanAgent ::ScanByUpdates - Ajout de la stratégie à la mise à jour finale de la liste ScanRequestSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC}, Policy-ContentVersion=38, Required-ContentVersion=38 ScanAgent
Étape 2 : L’agent d’analyse envoie une requête pour l’emplacement WSUS aux services de localisation
L’agent d’analyse demande maintenant l’emplacement WSUS à partir des services de localisation et attend une réponse. Dans cet exemple, l’ID de demande d’emplacement est {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}. Les éléments suivants sont connectés ScanAgent.log :
Inside CScanAgent ::P rocessScanRequest() ScanAgent
CScanJobManager ::Scan - entrée ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::Initialize- entered ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::Scan- entered ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : CScanJob ::RequestLocations- entered 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-4E4-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 : Les services de localisation envoient 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 pour une demande d’emplacement WSUS est l’ID unique UpdateSource. Les éléments suivants sont connectés LocationServices.log :
CCCMWSUSLocation ::GetLocationsAsyncEx LocationServices
Tentative de conservation de la demande d’emplacement WSUS pour ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' et ContentVersion='38' LocationServices
LocationServices de la demande d’emplacement WSUS persistante
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="38"></><AssignedSite « 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 : La messagerie CCM envoie le message de demande d’emplacement au point de gestion
Les éléments suivants sont connectés CcmMessaging.log :
Envoi du 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 à partir de la base de données. Les éléments suivants sont connectés MP_Location.log :
MP LM : Corps du message : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{C2D17964-BBDD-4339-B9F3- 12D7205B39CC} » Version="38"/><AssignedSite Code="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 SQL Server Profiler trace :
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'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 éléments suivants sont connectés 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 de localisation
Le fichier CcmMessaging.log sur le client indique qu’une réponse a été reçue. Ce message a été remis aux services de localisation :
Le message « {76453CC6-76BA-4B68-BE30-BA70754570BB} » a reçu la réponse « {8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C} » à la file d’attente de point de terminaison locale « LS_ReplyLocations » CcmMessaging
OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={76453CC6-76BA-4B68-BE30-BA70754570BB}) : remise 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 : Les services de localisation analysent la réponse et renvoient l’emplacement à l’agent d’analyse
Les éléments suivants sont connectés LocationServices.log :
Message de réponse Emplacement de traitement LocationServices 1/20/2014 12 :18 :09 PM
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> LocationServices
Rappel avec les emplacements WSUS suivants LocationServices
Chemin WSUS='http://PS1SITE.CONTOSO.COM:8530', Server='PS1SITE. CONTOSO. COM', Version='38' LocationServices
CHEMIN WSUS='https://PS1SYS.CONTOSO.COM:8531', Server='PS1SYS. CONTOSO. COM', Version='38' LocationServices
Rappel avec des emplacements pour la demande 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 éléments suivants sont connectés ScanAgent.log :
WSUSLocationUpdate reçu pour la demande d’emplacement guid={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 stratégie de groupe (si le client est dans le domaine) pour voir si stratégie de groupe remplace le serveur de mise à jour que nous venons d’ajouter. Les éléments suivants sont connectés WUAHandler.log sur un nouveau client montrant une nouvelle source de mise à jour en cours d’ajout :
Son type de source de mise à jour WSUS ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}), l’ajoutant. WUAHandler
Il s’agit d’une toute 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 forcée de la stratégie. WUAHandler
Attendre 2 minutes pour stratégie de groupe notifier la modification de la 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 éléments suivants sont connectés 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 STATUS WSUS :http://PS1SITE.CONTOSO.COM:8530(Modifié)
2014-01-20 12 :18 :11 :520 968 9d0 AU Serveur Sus modifié via 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 | Data |
|---|---|---|---|
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate |
WUServer | REG_SZ | URL complète du serveur WSUS, y compris le port. Par exemple, http://PS1Site.Contoso.com:8530 |
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate |
WUStatusServer | REG_SZ | URL complète du serveur WSUS, y compris le port. Par exemple, http://PS1Site.Contoso.com:8530 |
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU |
UseWUServer | REG_DWORD | 0x1 |
Pour un client existant, nous pouvons nous attendre à voir ce qui suit dans WUAHandler.log indiquer quand la version de contenu a été incrémentée :
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 est passée à 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 éléments suivants sont connectés ScanAgent.log :
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}) : levée du message d’état UpdateSource ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}). 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 de source de mise à jour et l’emplacement de la source de mise à jour disponibles, l’Agent d’analyse lance l’analyse. L’analyse des mises à jour logicielles est en fait 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 de gestionnaire d’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 à WUAHandler, qui utilise l’API de l’agent Windows Update pour demander une analyse des mises à jour logicielles à l’agent Windows Update. Les éléments suivants sont connectés ScanAgent.log :
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - successfully requested Scan, ScanType=1 ScanAgent
Les éléments suivants sont connectés WUAHandler.log :
Les résultats de l’analyse incluent les mises à jour remplacées uniquement lorsqu’elles sont remplacées par des Service Packs et des mises à jour de définition. WUAHandler
Recherche critères est (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') WUAHandler
Exécution d’une analyse par appel unique des mises à jour. WUAHandler
La recherche asynchrone des mises à jour à l’aide de WUAgent a démarré. WUAHandler
Étape 2 : Windows Update Agent (WUA) démarre l’analyse sur l’ordinateur WSUS
Windows Update Agent démarre une analyse après avoir reçu une requête du client Configuration Manager (CcmExec). É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 éléments suivants sont connectés WindowsUpdate.log :
2014-01-20 12 :18 :42 :694 3856 708 COMAPI -- START -- COMAPI : Recherche [ClientId = CcmExec]
2014-01-20 12 :18 :42 :752 3856 708 COMAPI <<-- SOUMIS -- COMAPI : Recherche [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 * Criteria = « (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 * Recherche Scope = {Machine}
Windows Update Agent analyse désormais le serveur WSUS et signale les résultats à CcmExec (en particulier WUAHandler). Les éléments suivants sont connectés 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 ; règles appl évaluées 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 : Recherche [ClientId = CcmExec]
2014-01-20 12 :18 :53 :137 3856 708 COMAPI - Mises à jour trouvé = 163
2014-01-20 12 :18 :53 :137 3856 708 COMAPI -- END -- COMAPI : Recherche [ClientId = CcmExec]
Étape 3 : WUAHandler reçoit les résultats de l’agent Windows Update et marque l’analyse comme terminée
Les éléments suivants sont connectés WUAHandler.log :
Recherche asynchrone terminée. WUAHandler
Nous avons terminé la recherche de tous les éléments dans un appel unique. 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 éléments suivants sont connectés WUAHandler.log :
Nettoyage : l’ID de mise à jour (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 terminée avec succès. WUAHandler
Étape 5 : Le magasin de mises à jour enregistre le status et déclenche un message d’état pour chaque mise à jour dans WMI
Une fois les résultats de l’analyse disponibles, ces résultats sont stockés dans le magasin des mises à jour. Le magasin de mise à jour enregistre l’état actuel de chaque mise à jour et crée un message d’état pour chaque mise à jour. Ces messages d’état sont transférés au serveur de site en bloc à la fin du cycle de création de rapports de messages status (soit 15 minutes par défaut).
UpdatesStore.log indiquant l’état de mise à jour manquante (KB2862152) en cours d’enregistrement et un message d’état déclenché :
Traitement de la mise à jour status de la mise à jour (505fda07-b4f3-45fb-83d9-8642554e2773) avec ProductID = 0fa1201d-4330-4fa8-8ae9- b877473b6441 UpdatesStore
La mise à jour status de la mise à jour (505fda07-b4f3-45fb-83d9-8642554e2773) n’a pas été signalée auparavant, ce qui crée de nouvelles instance. UpdatesStore
Message d’état correctement déclenché pour la mise à jour (505fda07-b4f3-45fb-83d9-8642554e2773) avec état (manquant). UpdatesStore
Ajout de wMI instance de mise à jour status (505fda07-b4f3-45fb-83d9-8642554e2773). UpdatesStore
StateMessage.log affichant le message d’état enregistré avec l’ID d’état 2 (manquant) :
Ajout d’un 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, un instance de la CCM_UpdateStatus classe est créé ou mis à jour, ce qui stocke la status actuelle de la mise à jour. La CCM_UpdateStatus classe se trouve dans l’espace de ROOT\CCM\SoftwareUpdates\UpdatesStore noms .
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 CCM_StateMsg classe se trouve dans l’espace de ROOT\CCM\StateMsg noms .
É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é du message d’état instance dans la CCM_StateMsg classe est définie sur True.
Dans StateMessage.log :
Corps StateMessage : <Xml Report Body Tronqué> StateMessage
Messages d’état transférés avec succès au mp StateMessage
Voici à quoi ressemble le corps du message d’état pour 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 de StateMessage : <?xml version="1.0 » encoding="UTF-16 » ?>
<ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType>1/ClientType ClientType 1</ClientType><ClientID>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.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</Format>version><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessageTime="20140120171855.573000+000 » SerialNumber="232 »><Topic ID="505fda07-b4f3-45fb-83d9-8642554e2773 » Type="500 » IDType="3 » User=" » User=" » UserSID=""/><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, selon le cycle de création de rapports de 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 que les messages d’état ont été transférés avec succès au mp 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 a 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 file d’attente MP_RelayEndpoint .
Étape 1 : Le composant Message d’état commence à envoyer des messages au point de gestion
Dans StateMessage.log :
Corps de StateMessage : <?xml version="1.0 » encoding="UTF-16 » ?><ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType>1</ClientType ClientID><>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.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</Format>version><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessageTime="20140120171855.573000+000 » SerialNumber="232 »><Topic ID="505fda07-b4f3-45fb-83d9-8642554e2773 » Type="500 » IDType="3 » User=" » User=" » UserSID=""/><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 : La messagerie CCM envoie un message contenant le corps XML du message d’état au point de gestion
Ccm Messaging envoie un message à la file d’attente MP_RelayEndpoint 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 du 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-3897883105F2} » n’a pas de réponse CcmMessaging
OutgoingMessage(Queue='mp_mp_relayendpoint', ID={95F79010-D0EB-49A6-8A1E-3897883105F2}) : remise 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 sont reçus par IIS. Dans cet exemple, cette requête est envoyé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 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é ou non sur le serveur de site.
- Sur un point de gestion distant : \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 : rép de la boîte d’envoi : E :\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
Priorité dans le message = 5 MP_RelayEndpoint
State Priority Directory = E :\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
Inv-Relay : la tâche s’est 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 » ?>
<ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType>1/ClientType ClientType 1</ClientType><ClientID>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.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</Format>version><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessageTime="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
Relay : dir de boîte d’envoi : C :\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Priorité dans le message = 5 MP_RelayEndpoint
State Priority Directory = C :\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Inv-Relay : la tâche s’est terminée avec succès MP_RelayEndpoint
Le corps XML semble identique à ce qui est connecté StateMessage.log sur le client.
Étape 4 : Mp File Dispatch Manager 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 le fichier arrivé dans les boîtes d’envoi\StateMsg.box, mp File Dispatch Manager (MPFDM) est chargé de déplacer 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 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 vers \\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 distant 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 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 à 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 SMS_STATE_SYSTEM
Id du thread « State Message Processing Thread #0 » : 4316 démarré SMS_STATE_SYSTEM
nombre total de mandrins chargés (1) SMS_STATE_SYSTEM
CMessageProcessor - Fichier de traitement : YCE2H3VD. SMX SMS_STATE_SYSTEM
CMessageProcessor : 1 enregistrement traité avec 0 enregistrement non valide. SMS_STATE_SYSTEM
CMessageProcessor : 1 fichier de message traité dans ce lot, avec 0 fichier incorrect. SMS_STATE_SYSTEM
nombre total de chucks chargés (0) SMS_STATE_SYSTEM
Id du thread « State Message Processing Thread #0 » : 4316 s’est 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 SMS_STATE_SYSTEM
ID du thread « State Message Processing Thread #0 » : 1988 a démarré SMS_STATE_SYSTEM
nombre total de mandrins chargés (1) SMS_STATE_SYSTEM
nombre total de chucks chargés (0) SMS_STATE_SYSTEM
Id du thread « State Message Processing Thread #0 » : 1988 s’est 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 qui est déplacé vers le dossier StateSys.box contient le code 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 SQL Server Profiler trace :
exec dbo.spProcessStateReport N'< ?xml version="1.0 » encoding="UTF-16 » ?>
<ReportHeader Identification Machine ClientInstalled>1</ClientInstalled><ClientType>1/ClientType ClientType 1</ClientType><ClientID>GUID : A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.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</Format>version><1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessageTime="20140120171855.573000+000 » SerialNumber="239 »><Topic ID="505fda07-b4f3-45fb-83d9-8642554e2773 » Type="500 » IDType="3 » User=" » User=" » UserSID=""/><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 du CLR a la logique permettant de 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 pouvez trouver des noms conviviaux de tous les types de rubriques et ID de message d’état en interrogeant la SR_StateNames table avec la commande suivante :
SELECT * FROM SR_StateNames
Résumé des mises à jour logicielles
Pour 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 n’affichent généralement que des données résumées. Le composant Système d’état sur le serveur de site effectue le résumé des mises à jour logicielles, ainsi que le résumé d’autres composants, tels que les applications, les déploiements DCM et l’intégrité du client. Vous pouvez trouver des informations sur toutes les tâches de résumé effectuées par State System 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 journalise les détails de chaque tâche dans StateSys.log :
Tâche «< TaskName> » démarrée SMS_STATE_SYSTEM
La tâche «< TaskName> » s’est terminée correctement après une exécution de 15 secondes, avec status 8. SMS_STATE_SYSTEM
Pour la plupart de ces tâches, le status journalisé 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é d’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 Configuration Manager console >Monitoring>Deployments, cliquez avec le bouton droit sur le déploiement, puis cliquez sur Exécuter le résumé.
SUM Update Group Status Summarizer
Résume status 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 Configuration Manager console >Software Library>Software Mises à jour>Groupes de mises à jour logicielles, cliquez avec le bouton droit sur le groupe de mises à jour, 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 status de mises à jour pour tous les clients. Cette tâche s’exécute toutes les heures par défaut. Il peut être lancé manuellement dans Configuration Manager console >Software Library>Software Mises à jour, puis cliquez sur Exécuter le résumé. Vous pouvez également modifier la planification par défaut en sélectionnant Planifier le résumé.
État de la mise à jour sum Migrate
Migre les status de mise à jour en interne dans la base de données. Cette tâche s’exécute toutes les 24 heures par défaut. Il ne peut pas être lancé manuellement à partir de la console Configuration Manager.
SUM Delete Aged Status
Supprime les anciennes status des tables spécifiques aux mises à jour logicielles dans la base de données. Cette tâche s’exécute toutes les 24 heures par défaut. Il ne peut pas être lancé 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 sup devient indisponible. Pour plus d’informations sur le basculement et le basculement des suPs, consultez les articles suivants :