Risolvere i problemi di gestione degli aggiornamenti software in Configuration Manager
Questo articolo illustra come risolvere i problemi relativi al processo di gestione degli aggiornamenti software in Configuration Manager. Include l'analisi degli aggiornamenti software client, i problemi di sincronizzazione e i problemi di rilevamento con aggiornamenti specifici.
Versione originale del prodotto: Configuration Manager (Current Branch), System Center 2012 R2 Configuration Manager, System Center 2012 Configuration Manager
Numero KB originale: 4505440
Definire l'ambito del problema
Questa guida presuppone che un punto di aggiornamento software sia già stato installato e configurato. Per altre informazioni sulla configurazione degli aggiornamenti software in Configuration Manager, vedere Preparare la gestione degli aggiornamenti software.
Prima di iniziare la risoluzione dei problemi, è importante sottolineare che, meglio si comprende il problema riscontrato, più veloce e più facile sarà risolvere il problema. Indipendentemente dal fatto che l'utente abbia l'incarico di risolvere un problema riscontrato o che si sia verificato un problema segnalato da un utente dell'organizzazione, dedicare qualche minuto e rispondere alle domande seguenti:
- Cosa non funziona e/o qual è il tuo obiettivo?
- Qual è la frequenza o il modello per il problema? Il problema persiste?
- Come sei diventato consapevole del fatto che il problema esiste?
- Ha mai funzionato? In tal caso, quando si è fermato? Qualcosa è cambiato nell'ambiente subito prima che smettesse di funzionare?
- Quale percentuale di client è interessata?
- Cosa è stato fatto già (se qualcosa) per provare a risolverlo?
- Conoscere la versione esatta del client e la versione del server. Questi sistemi sono aggiornati?
- Cosa hanno in comune i client interessati? Ad esempio, la stessa subnet, il sito di Active Directory, il dominio, la posizione fisica, il sito, il sistema del sito.
Conoscere e comprendere le risposte a queste domande ti metterà nel percorso migliore per una risoluzione rapida e semplice a qualsiasi problema riscontrato.
Se si conosce l'area specifica all'interno del processo di gestione degli aggiornamenti software che si vuole risolvere, selezionarla di seguito. Iniziare con l'analisi degli aggiornamenti software client se non si è certi e si esaminerà l'intero processo dall'inizio alla fine.
- Analisi degli aggiornamenti software client
- Sincronizzazione da WSUS a Microsoft Update
- Problemi di installazione, sostituzione o rilevamento con aggiornamenti specifici
Analisi degli aggiornamenti software client
Il processo di analisi client è descritto nei passaggi seguenti. Confermare ogni passaggio per stabilire correttamente dove si trova il problema.
Passaggio 1: Il client invia una richiesta di posizione WSUS al punto di gestione
La prima cosa che il client esegue è impostare il server WSUS che sarà l'origine dell'aggiornamento per le analisi degli aggiornamenti software. Questo processo è dettagliato di seguito.
Quando il client di Configuration Manager deve elaborare un'analisi degli aggiornamenti software, l'agente di analisi crea una richiesta di analisi in base ai criteri disponibili, come indicato in ScanAgent.log:
CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={SourceID} ContentVersion=38 CScanAgent::ScanByUpdates- Added Policy to final ScanRequest List UpdateSourceID={SourceID}, Policy-ContentVersion=38, Required-ContentVersion=38
L'agente di analisi invia ora una richiesta di posizione WSUS a Servizi location, come indicato in 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.
Suggerimento
Ogni processo di analisi viene archiviato in WMI nella
CCM_ScanJobInstance
classe :Spazio dei nomi:
root\CCM\ScanAgent
Classe:CCM_ScanJobInstance
Location Services crea una richiesta di posizione e la invia al punto di gestione. L'ID pacchetto per una richiesta di percorso WSUS è l'ID univoco dell'origine di aggiornamento. In 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}
La messaggistica CCM invia il messaggio di richiesta di posizione al punto di gestione. In CcmMessaging.log:
Sending async message '{Message}' to outgoing queue 'mp:[http]mp_locationmanager' Sending outgoing message '{Message}'. Flags 0x200, sender account empty
Il punto di gestione analizza questa richiesta e chiama la
MP_GetWSUSServerLocations
stored procedure per ottenere i percorsi WSUS dal database. In 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
In SQL Server Profiler:
exec MP_GetMPSitesFromAssignedSite N'PS1' exec MP_GetSiteInfoUnified N'<ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2-PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo>' exec MP_GetWSUSServerLocations N'{WSUSServerLocationsID}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'
Dopo aver ottenuto i risultati dalla stored procedure, il punto di gestione invia una risposta al client. In 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>
La messaggistica CCM riceve la risposta e la invia a Servizi location. In 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'
Location Services analizza la risposta e invia di nuovo la posizione all'agente di analisi. In 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}
L'agente di analisi dispone ora dei criteri e del percorso di origine dell'aggiornamento con la versione del contenuto appropriata. In 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
Scan Agent notifica a WUAHandler di aggiungere l'origine dell'aggiornamento. WUAHandler aggiunge l'origine di aggiornamento al Registro di sistema. Avvia un aggiornamento di Criteri di gruppo se il client è nel dominio per verificare se Criteri di gruppo esegue l'override del server di aggiornamento aggiunto. Le voci seguenti vengono registrate WUAHandler.log che mostra una nuova origine di aggiornamento da aggiungere:
Its a WSUS Update Source type ({WSUSUpdateSource}), adding it Its a completely new WSUS Update Source Enabling WUA Managed server policy to use server: <http://PS1SITE.CONTOSO.COM:8530> Policy refresh forced Waiting for 2 mins for Group Policy to notify of WUA policy change Waiting for 30 secs for policy to take effect on WU Agent. Added Update Source ({UpdateSource}) of content type: 2
Durante questo periodo, l'agente di Windows Update visualizza una modifica della configurazione di WSUS. In WindowsUpdate.log:
* WSUS server: <http://PS1SITE.CONTOSO.COM:8530> (Changed) * WSUS status server: <http://PS1SITE.CONTOSO.COM:8530> (Changed) Sus server changed through policy.
Vengono controllate e impostate le chiavi del Registro di sistema seguenti:
Sottochiave del Registro di sistema Nome valore Tipo Dati HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate
WUServer
REG_SZ URL completo del server WSUS, inclusa la porta. Ad esempio, < http://PS1Site.Contoso.com:8530
>HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate
WUStatusServer REG_SZ URL completo del server WSUS, inclusa la porta. Ad esempio, < http://PS1Site.Contoso.com:8530
>HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU
UseWUServer
REG_DWORD 0x1 Per un client esistente, è possibile che venga visualizzato il messaggio seguente in WUAHandler.log in modo da indicare quando la versione del contenuto è stata incrementata:
Its a WSUS Update Source type ({WSUSUpdateSource}), adding it. WSUS update source already exists, it has increased version to 38.
Dopo l'aggiunta dell'origine dell'aggiornamento, l'agente di analisi genera un messaggio di stato e avvia l'analisi. In ScanAgent.log:
ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2 ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
Risolvere i problemi nel passaggio 1
Problemi | Controlli da eseguire |
---|---|
ScanAgent.log non mostra alcun criterio disponibile per un'origine di aggiornamento e nessuna WUAHandler.log esiste o nessuna attività corrente all'interno di WUAHandler.log | Selezionare l'impostazione Abilita aggiornamenti software nei client . |
L'agente di analisi o i servizi di posizione non ricevono il percorso del server WSUS |
|
Il client riceve il percorso WSUS ma non riesce a configurare le chiavi del Registro di sistema WSUS | L'aggiornamento di Criteri di gruppo ha risposto entro il timeout di 2 minuti per WUAHandler.log? In tal caso, WUAHandler indica che le impostazioni di Criteri di gruppo sono state sovrascritte da un'autorità superiore (Controller di dominio)? Per altre informazioni, vedere Criteri di gruppo esegue l'override delle informazioni di configurazione di WSUS corrette. |
Per altre informazioni sulla risoluzione degli errori di analisi degli aggiornamenti software, vedere Risolvere gli errori di analisi degli aggiornamenti software.
Passaggio 2: Scan Agent richiede l'analisi e WUAHandler avvia l'analisi
Dopo che il client ha identificato e impostato il server WSUS che sarà l'origine dell'aggiornamento per le analisi degli aggiornamenti software, l'agente di analisi richiede l'analisi da WUAHandler che usa l'API dell'agente di Windows Update per richiedere un'analisi degli aggiornamenti software dall'agente di Windows Update. Un'analisi può risultare da:
- Analisi degli aggiornamenti software pianificata o manuale
- Una rivalutazione della distribuzione pianificata o manuale aggiornata dal software
- Una distribuzione che diventa attiva
L'analisi attiva una valutazione. In ScanAgent.log:
ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
I risultati dell'analisi includono gli aggiornamenti sostituiti solo quando vengono sostituiti dai Service Pack e dagli aggiornamenti delle definizioni. In WUAHandler.log:
Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')
Running single-call scan of updates.
Async searching of updates using WUAgent started.
Suggerimento
Esaminare WUAHandler.log dopo un'analisi degli aggiornamenti software per verificare se si verificano nuove voci. Se non si verificano nuove voci, indica che non viene restituito alcun sup dal punto di gestione.
Risolvere i problemi nel passaggio 2
Molti problemi con l'analisi degli aggiornamenti software possono essere causati da uno dei motivi seguenti:
- File o chiavi del Registro di sistema mancanti o danneggiati.
- Problemi di registrazione dei componenti.
Per risolvere questi problemi, vedere Analizzare gli errori a causa di componenti mancanti o danneggiati.
Si è verificato un problema noto che un client ConfigMgr 2012 R2 a 32 bit che richiede un'analisi di aggiornamento non restituisce i risultati dell'analisi a Configuration Manager. Il client segnala lo stato di conformità non corretto e gli aggiornamenti non vengono installati quando Configuration Manager richiede il ciclo di aggiornamento. Tuttavia, se si usa l'applet del pannello di controllo di Windows Update, gli aggiornamenti vengono in genere installati correttamente. Quando si verifica questo problema, viene visualizzato un messaggio simile al seguente in WindowsUpdate.log:
WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E
Si tratta di un problema di allocazione della memoria, i computer Windows 7 a 64 bit non vedranno questo errore perché lo spazio degli indirizzi è effettivamente illimitato. Tuttavia, mostreranno memoria elevata e un utilizzo elevato della CPU, probabilmente che influiscono sulle prestazioni. I client X86 mostreranno anche un utilizzo elevato della memoria (in genere da circa 1,2 GB a 1,4 GB).
Per risolvere questo problema, applicare il client Windows Update per Windows 7: giugno 2015.
Durante la risoluzione degli errori di analisi, controllare i file WUAHandler.log e WindowsUpdate.log. WUAHandler segnala semplicemente ciò che l'agente di Windows Update ha segnalato. L'errore in WUAHandler sarebbe quindi lo stesso errore segnalato dall'agente di Windows Update stesso. Altre informazioni sull'errore sono disponibili in WindowsUpdate.log. Per informazioni su come leggere WindowsUpdate.log, vedere File di log di Windows Update.
La migliore fonte di informazioni proviene dai log e dai codici di errore che contengono. Per altre informazioni sui codici di errore, vedere Errori comuni e mitigazione di Windows Update.
Passaggio 3: Windows Update Agent (WUA) avvia l'analisi sul computer WSUS
Windows Update Agent avvia un'analisi dopo aver ricevuto una richiesta dal client di Configuration Manager (CcmExec). Se questi valori del Registro di sistema sono impostati correttamente su un computer WSUS valido per il sito tramite criteri locali, verrà visualizzata una richiesta di ricerca dell'API COM dal client di Configuration Manager (ClientId = CcmExec). In WindowsUpdate.log:
COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]
COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec] PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>
Agent ** START ** Agent: Finding updates [CallerId = CcmExec]
Agent * Include potentially superseded updates
Agent * Online = Yes; Ignore download priority = Yes
Agent * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"
Agent * ServiceID = {ServiceID} Managed
Agent * Search Scope = {Machine}
PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>
Agent * Added update {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 to search result
Agent * Added update {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 to search result
Agent * Found 163 updates and 70 categories in search; evaluated appl. rules of 622 out of 1150 deployed entities
Agent ** END ** Agent: Finding updates [CallerId = CcmExec]
COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]
COMAPI - Updates found = 163
COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]
Risolvere i problemi nel passaggio 3
Durante un'analisi, l'agente di Windows Update deve comunicare con le ClientWebService
directory virtuali e SimpleAuthWebService
nel computer WSUS per eseguire un'analisi. Se il client non riesce a comunicare con il computer WSUS, l'analisi avrà esito negativo. Questo problema può verificarsi per molti motivi, tra cui:
Problemi correlati al proxy
Per risolvere questi problemi, vedere Analizzare gli errori causati da problemi correlati al proxy.
Per altre informazioni sui server proxy, vedere gli articoli seguenti:
Errori di timeout HTTP
Per risolvere gli errori di timeout HTTP, esaminare prima i log di Internet Information Services (IIS) nel computer WSUS per verificare che gli errori vengano effettivamente restituiti da WSUS. Se il computer WSUS non restituisce l'errore, è probabile che il problema si verifichi con un firewall o un proxy intermedio.
Se il computer WSUS restituisce l'errore, verificare la connettività con il computer WSUS. Di seguito sono riportati i passaggi:
Per verificare che il client si connetta al server WSUS corretto, trovare l'URL del computer WSUS usato dal client dell'agente di Windows Update. Questo URL è disponibile controllando la sottochiave del
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
Registro di sistema o visualizzando il file WindowsUpdate.log.I motivi comuni per cui l'assegnazione wsus potrebbe non essere corretta includono:
- Conflitti di Criteri di gruppo
- Aggiunta di un punto di aggiornamento software a un sito secondario dopo l'installazione iniziale del client
Note
Criteri di gruppo di Active Directory possono eseguire l'override dei criteri WSUS locali.
La funzionalità aggiornamenti software configura automaticamente un'impostazione di Criteri di gruppo locale per il client di Configuration Manager in modo che sia configurata con il percorso di origine del punto di aggiornamento software e il numero di porta. Sia il nome del server che il numero di porta sono necessari per il client per trovare il punto di aggiornamento software.
Se un'impostazione di Criteri di gruppo di Active Directory viene applicata ai computer per l'installazione del client del punto di aggiornamento software, esegue l'override dell'impostazione di Criteri di gruppo locale. Se il valore dell'impostazione definita nei Criteri di gruppo di Active Directory è diverso da quello impostato da Configuration Manager, l'analisi avrà esito negativo nel client perché non riesce a individuare il computer WSUS corretto. In questo caso, WUAHandler.log mostrerà il messaggio seguente:
Le impostazioni di Criteri di gruppo sono state sovrascritte da un'autorità superiore (Controller di dominio) a: Server <
http://server
> e Criteri ABILITATIIl punto di aggiornamento software per l'installazione client e gli aggiornamenti software devono essere lo stesso server. E deve essere specificato nell'impostazione di Criteri di gruppo di Active Directory con il formato del nome e le informazioni sulla porta corretti. Ad esempio, sarebbe <
http://server1.contoso.com:80
> se il punto di aggiornamento software usasse il sito Web predefinito.Se l'URL del server è corretto, accedere al server usando un URL simile al seguente per verificare la connettività tra il client e il computer WSUS:
<
http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab
>Per verificare se il client può accedere alla
ClientWebService
directory virtuale, provare ad accedere a un URL simile al seguente:<
http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml
>Per verificare se il client può accedere a , provare ad accedere
SimpleAuthWebService
a un URL simile al seguente:<
http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx
>Se uno di questi URL ha esito negativo, alcuni dei possibili motivi includono:
Problemi di risoluzione dei nomi nel client. Verificare che sia possibile risolvere il nome di dominio completo del computer WSUS.
Problemi di configurazione del proxy.
Altri problemi di connettività correlati alla rete.
Problemi di configurazione delle porte, quindi è consigliabile verificare che le impostazioni della porta siano corrette. WSUS può essere configurato per l'uso di una delle porte seguenti: 80, 443 o 8530, 8531.
Affinché i client comunichino con il computer WSUS, le porte appropriate devono essere consentite nel firewall nel computer WSUS. Le impostazioni delle porte vengono configurate quando viene creato il ruolo del sistema del sito del punto di aggiornamento software. Queste impostazioni delle porte devono corrispondere alle impostazioni della porta usate dal sito Web WSUS. In caso contrario, Gestione sincronizzazione WSUS non riuscirà a connettersi a WSUS in esecuzione nel punto di aggiornamento software per richiedere la sincronizzazione. Le procedure seguenti forniscono informazioni su come verificare le impostazioni delle porte usate da WSUS e dal punto di aggiornamento software.
Determinare le impostazioni della porta WSUS usate in IIS 7.0 e versioni successive.
Determinare le impostazioni della porta WSUS in IIS 6.0.
Configurare le porte per il punto di aggiornamento software.
Verificare la connettività delle porte
Per controllare la connettività delle porte dal client, eseguire il comando seguente:
telnet SUPSERVER.CONTOSO.COM <portnumber>
Ad esempio, eseguire il comando seguente se la porta è 8530:
telnet SUPSERVER.CONTOSO.COM 8530
Se la porta non è accessibile, telnet restituirà un errore simile al seguente:
Impossibile aprire la connessione all'host sulla porta <PortNumber>
Questo errore suggerisce che le regole del firewall non sono configurate per consentire la comunicazione per il computer WSUS. Questo errore può anche suggerire che un dispositivo di rete intermedio stia bloccando tale porta. Per verificare, provare lo stesso test da un client nella stessa subnet locale. Se funziona, i computer sono configurati correttamente. Tuttavia, un router o un firewall tra segmenti blocca la porta e causa l'errore.
Problemi di disponibilità di IIS.
- Nel computer WSUS aprire Gestione Internet Information Services (IIS).
- Espandere Siti, fare clic con il pulsante destro del mouse sul sito Web per il computer WSUS e quindi scegliere Modifica associazioni.
- Nella finestra di dialogo Associazioni sito i valori delle porte HTTP e HTTPS vengono visualizzati nella colonna Porta.
- Nel server WSUS aprire Gestione Internet Information Services (IIS).
- Espandere Siti Web, fare clic con il pulsante destro del mouse sul sito Web per il computer WSUS, quindi scegliere Proprietà.
- Fare clic sulla scheda Sito Web. L'impostazione della porta HTTP viene visualizzata nella porta TCP e l'impostazione della porta HTTPS viene visualizzata nella porta SSL.
- Nella console di Configuration Manager passare ad Amministrazione>Server di configurazione>del sito e Ruoli del sistema del sito, quindi fare clic sul< riquadro di destra SiteSystemName.>
- Nel riquadro inferiore fare clic con il pulsante destro del mouse su Punto di aggiornamento software e quindi scegliere Proprietà.
- Passare alla scheda Generale , specificare o verificare i numeri di porta di configurazione WSUS.
Errori di autenticazione
Viene in genere indicato quando l'analisi ha esito negativo con errori di autenticazione 0x80244017 (stato HTTP 401) o 0x80244018 (stato HTTP 403).
Prima di tutto, verificare le impostazioni del proxy WinHTTP corrette usando i comandi seguenti:
- In Windows Vista o versioni successive:
netsh winhttp show proxy
- In Windows XP:
proxycfg.exe
Se le impostazioni proxy sono corrette, verificare la connettività con il computer WSUS completando i passaggi descritti in Errori di timeout HTTP. Esaminare anche i log IIS nel computer WSUS per verificare che gli errori HTTP vengano restituiti da WSUS. Se il computer WSUS non restituisce l'errore, è probabile che il problema si verifichi con un firewall o un proxy intermedio.
- In Windows Vista o versioni successive:
Problemi relativi ai certificati
I problemi relativi ai certificati sono indicati dal codice di errore 0x80072F0C significa che "È necessario un certificato per completare l'autenticazione client". Per risolvere questo problema, vedere Analisi non riuscita con errore 0x80072f0c.
Passaggio 4: WUAHandler riceve i risultati dall'agente di Windows Update e contrassegna l'analisi come completata
Di seguito viene eseguito l'accesso WUAHandler.log:
Async searching completed.
Finished searching for everything in single call.
Risolvere i problemi nel passaggio 4
I problemi qui devono essere risolti allo stesso modo degli errori di analisi nel passaggio 3.
Come accennato in precedenza in questa guida, durante la risoluzione degli errori di analisi, controllare i file WUAHandler.log e WindowsUpdate.log. WUAHandler segnala semplicemente ciò che l'agente di Windows Update ha segnalato. L'errore in WUAHandler sarebbe quindi lo stesso errore segnalato dall'agente di Windows Update stesso. Altre informazioni sull'errore sono disponibili in WindowsUpdate.log. Per informazioni su come leggere WindowsUpdate.log, vedere File di log di Windows Update.
Esistono molti motivi per cui un'analisi degli aggiornamenti software potrebbe non riuscire. Potrebbe essere causato da uno dei problemi indicati in precedenza o da un problema di comunicazione o firewall tra il client e il computer del punto di aggiornamento software. La migliore fonte di informazioni proviene dai log e dai codici di errore che contengono. Per altre informazioni sui codici di errore, vedere Errori comuni e mitigazione di Windows Update.
Passaggio 5: WUAHandler analizza i risultati dell'analisi
WUAHandler analizza quindi i risultati, che includono lo stato di applicabilità per ogni aggiornamento. Nell'ambito di questo processo, gli aggiornamenti sostituiti vengono eliminati. Lo stato di applicabilità viene controllato per tutti gli aggiornamenti allineati ai criteri inviati da CCMExec all'agente di Windows Update. L'aspetto importante da comprendere qui è che dovrebbero essere visualizzati i risultati dell'applicabilità per gli aggiornamenti, indipendentemente dal fatto che tali aggiornamenti si trovino in una distribuzione o meno.
Le voci seguenti vengono registrate 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.
Risolvere i problemi nel passaggio 5
I problemi possono essere risolti allo stesso modo degli errori di analisi nel passaggio 3.
Come accennato in precedenza in questa guida, durante la risoluzione degli errori di analisi, controllare i file WUAHandler.log e WindowsUpdate.log. WUAHandler segnala semplicemente ciò che l'agente di Windows Update ha segnalato. L'errore in WUAHandler sarebbe quindi lo stesso errore segnalato dall'agente di Windows Update stesso. Altre informazioni sull'errore sono disponibili in WindowsUpdate.log. Per informazioni su come leggere WindowsUpdate.log, vedere File di log di Windows Update.
In generale, esistono molti motivi per cui un'analisi degli aggiornamenti software potrebbe non riuscire. Potrebbe essere causato da uno dei problemi menzionati in precedenza o da un problema di comunicazione o firewall tra il client e il computer del punto di aggiornamento software. La migliore fonte di informazioni proviene dai log e dai codici di errore che contengono. Come riferimento, vedi Errori e mitigazioni comuni di Windows Update.
Passaggio 6: Aggiornare l'archivio registra lo stato e genera un messaggio di stato per ogni aggiornamento in WMI
Una volta disponibili i risultati dell'analisi, questi risultati vengono archiviati nell'archivio aggiornamenti. L'archivio di aggiornamento registra lo stato corrente di ogni aggiornamento e crea un messaggio di stato per ogni aggiornamento. Questi messaggi di stato vengono inoltrati al server del sito in blocco alla fine del ciclo di report dei messaggi di stato (ovvero minuti, per impostazione predefinita). Viene inviato un messaggio di stato solo nelle circostanze seguenti:
- Un messaggio di stato precedente non è mai stato inviato per un aggiornamento (voce di log: non è stato segnalato prima, creando una nuova istanza).
- Lo stato di applicabilità per un aggiornamento è cambiato dall'ultimo messaggio di stato inviato.
UpdatesStore.log che mostra lo stato dell'aggiornamento mancante (KB2862152) registrato e viene generato un messaggio di stato:
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 che mostra il messaggio di stato registrato con l'ID stato 2 (mancante):
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
Suggerimento
Per ogni aggiornamento, viene creata o aggiornata un'istanza della CCM_UpdateStatus
classe e archivia lo stato corrente dell'aggiornamento. La classe CCM_UpdateStatus
si trova nello spazio dei nomi ROOT\CCM\SoftwareUpdates\UpdatesStore
.
Risolvere i problemi nel passaggio 6
I problemi qui devono essere risolti allo stesso modo degli errori di analisi nel passaggio 3.
Come accennato in precedenza in questa guida, durante la risoluzione degli errori di analisi, controllare i file WUAHandler.log e WindowsUpdate.log. WUAHandler segnala semplicemente ciò che l'agente di Windows Update ha segnalato. L'errore in WUAHandler sarebbe quindi lo stesso errore segnalato dall'agente di Windows Update stesso. Altre informazioni sull'errore sono disponibili in WindowsUpdate.log. Per informazioni su come leggere WindowsUpdate.log, vedere File di log di Windows Update.
In generale, esistono molti motivi per cui un'analisi degli aggiornamenti software potrebbe non riuscire. Potrebbe essere causato da uno dei problemi menzionati in precedenza o da un problema di comunicazione o firewall tra il client e il computer del punto di aggiornamento software. La migliore fonte di informazioni proviene dai log e dai codici di errore che contengono. Come riferimento, vedi Errori e mitigazioni comuni di Windows Update.
Passaggio 7: I messaggi di stato vengono inviati al punto di gestione
Quando WUAHandler riceve correttamente i risultati dall'agente di Windows Update, contrassegna l'analisi come completa e registra il messaggio seguente in WUAHandler.log:
Async searching completed. WUAHandler
Finished searching for everything in single call
Risolvere i problemi nel passaggio 7
I problemi in questo caso devono essere risolti allo stesso modo degli errori di analisi nel passaggio 3, anche se gli errori in questa fase verranno probabilmente visualizzati nel file WindowsUpdate.log in modo specifico. Per informazioni su come leggere WindowsUpdate.log, vedere File di log di Windows Update.
In generale, esistono molti motivi per cui un'analisi degli aggiornamenti software potrebbe non riuscire. Potrebbe essere causato da uno dei problemi menzionati in precedenza o da un problema di comunicazione o firewall tra il client e il computer del punto di aggiornamento software. La migliore fonte di informazioni proviene dai log e dai codici di errore che contengono. Come riferimento, vedi Errori e mitigazioni comuni di Windows Update.
Sincronizzazione da WSUS a Microsoft Update
La sincronizzazione di WSUS con Microsoft Update è descritta nei passaggi seguenti. Confermare ogni passaggio per stabilire correttamente dove si trova il problema.
Passaggio 1: La sincronizzazione inizia tramite una richiesta pianificata o manuale
Quando viene attivata una sincronizzazione, si prevede di visualizzare i messaggi seguenti all'interno del SoftwareDistribution.log del server WSUS:
Per la sincronizzazione manuale:
Changew3wp.6AdminDataAccess.StartSubscriptionManuallySynchronization manually started
Info WsusService.27EventLogEventReporter.ReportEvent
EventId=382,Type=Information,Category=Synchronization,Message=A manual synchronization was started.
Per la sincronizzazione pianificata:
InfoWsusService.10EventLogEventReporter.ReportEvent
EventId=381,Type=Information,Category=Synchronization,Message=A scheduled synchronization was started.
Risolvere i problemi relativi a una sincronizzazione manuale nel passaggio 1
Verificare che il servizio WSUS sia in esecuzione. Se una sincronizzazione manuale è stata avviata ma rimane allo 0%, è perché il servizio WSUS (Update Services in WSUS 3.x; WSUSService in Windows Server 2012 e versioni successive) è in stato arrestato.
Reimpostare la cache MMC della console WSUS seguendo questa procedura:
- Chiudere la console WSUS.
- Arrestare il servizio WSUS (Update Services in WSUS 3.x; Servizio WSUS in Windows Server 2012 e versioni successive).
- Passa a
%appdata%\Microsoft\mmc
. - Rinominare wsus in wsus_bak.
- Avviare il servizio WSUS.
- Aprire la console WSUS e provare un'altra sincronizzazione manuale.
Risolvere i problemi relativi a una sincronizzazione pianificata nel passaggio 1
- Provare una sincronizzazione manuale dalla console WSUS.
- Se una sincronizzazione manuale funziona correttamente, controllare le impostazioni di sincronizzazione pianificate.
Passaggio 2: WSUS genera una connessione a Microsoft Update (MU)
Dopo l'avvio di una sincronizzazione, il server WSUS tenta di stabilire una connessione HTTP tramite WinHTTP. Quando si risolve la connessione, tenere presenti i fattori seguenti:
WSUS <=winhttp=> Entità <di rete => Internet
- Esiste un'entità di rete (proxy, firewall, filtro di sicurezza e così via) tra il computer host WSUS e Internet?
- Se esiste un proxy e il server WSUS è necessario per usare il proxy, il proxy è configurato nelle impostazioni di WSUS appropriate?
Risolvere i problemi relativi a una sincronizzazione manuale nel passaggio 2
Verificare che il servizio WSUS sia in esecuzione. Se una sincronizzazione manuale è stata avviata ma rimane allo 0%, è perché il servizio WSUS (Update Services in WSUS 3.x; Il servizio WSUS in Windows Server 2012 e versioni successive è in stato arrestato.
Reimpostare la cache MMC della console WSUS completando i passaggi seguenti:
- Chiudere la console WSUS.
- Arrestare il servizio WSUS (Update Services in WSUS 3.x; Servizio WSUS in Windows Server 2012 e versioni successive).
- Passa a
%appdata%\Microsoft\mmc
. - Rinominare wsus in wsus_bak.
- Avviare il servizio WSUS.
- Aprire la console WSUS e provare un'altra sincronizzazione manuale.
Risolvere i problemi relativi a una sincronizzazione pianificata nel passaggio 2
- Provare una sincronizzazione manuale dalla console WSUS.
- Se una sincronizzazione manuale funziona correttamente, controllare le impostazioni di sincronizzazione pianificate.
Passaggio 3: Il computer WSUS riceve informazioni sul prodotto e sulla classificazione da Microsoft Update ed eventuali metadati sottoscritti
Dopo che WSUS riceve informazioni sul prodotto e la classificazione e tutti i metadati sottoscritti da Microsoft Update, la sincronizzazione WSUS è stata completata.
Problemi di installazione, sostituzione o rilevamento con aggiornamenti specifici
I problemi di distribuzione che si verificano con aggiornamenti specifici possono essere suddivisi nelle aree seguenti. Quando si inizia la risoluzione dei problemi, considerare i componenti seguenti associati a queste aree.
Aree | Installazione | Sostituzione | Rilevamento |
---|---|---|---|
Componenti |
|
Aggiornare i metadati |
|
Problemi relativi all'installazione
Che cos'è il programma di installazione (CBS, MSI, altro)?
CBS
Per gli aggiornamenti applicabili a Windows Vista e versioni successive, CBS viene usato per gestire l'installazione.
- Raccogliere il log CBS (
%Windir%\Logs\Cbs\Cbs.log
) ed eseguire una revisione iniziale per ottenere informazioni dettagliate sulla causa dell'errore. La risoluzione dei problemi basati sull'installazione tramite i log CBS non rientra nell'ambito di questa guida. Per altre informazioni, vedere Correggere gli errori di danneggiamento di Windows usando lo strumento GESTIONE e preparazione aggiornamenti del sistema. - L'aggiornamento viene installato correttamente come utente connesso? In tal caso, ha esito negativo solo quando viene installato nel contesto di sistema? In questo caso, concentrarsi sulla risoluzione dei problemi relativi all'errore di installazione manuale nel contesto di sistema.
MSI (Windows Installer)
Per gli aggiornamenti software non Windows, l'identità del servizio gestito viene usata per gestire l'installazione.
Raccogliere ed esaminare i log MSI predefiniti per l'aggiornamento. Per eventuali problemi noti o domande frequenti, vedere l'articolo della Knowledge Base associato.
Abilitare la registrazione di Windows Installer e riprodurre l'errore.
Quando si esaminano i log risultanti, verificare il valore restituito 3 all'interno del log e le righe precedenti a tale voce per ottenere informazioni dettagliate sull'errore.
Controllare se lo stesso aggiornamento non riesce a essere installato manualmente nel contesto di sistema locale. A tale scopo, usare le stesse opzioni di installazione non riuscite durante la distribuzione degli aggiornamenti software.
In caso di errore, testare l'installazione dell'utente connesso con le stesse opzioni di installazione. Controllare se si tratta di un problema con l'installazione nel sistema locale. Se funziona, è possibile concentrare il problema su come installare correttamente l'aggiornamento usando il contesto di sistema locale. Potrebbe essere necessario verificare la presenza di indicazioni sulla distribuzione amministrativa all'interno della Knowledge Base per l'aggiornamento o online.
Problemi di sostituzione
Tentare di isolare il problema correlato alla sostituzione usando le domande seguenti:
- Per domande su come controllare quando Configuration Manager scade un aggiornamento, vedere Regole di sostituzione.
- Se un aggiornamento è scaduto da Configuration Manager, Microsoft consiglia di distribuire l'aggiornamento sostituito più recente. Se è ancora necessario distribuire gli aggiornamenti scaduti, possono essere distribuiti all'esterno di una distribuzione degli aggiornamenti software tramite la distribuzione software o la gestione delle applicazioni.
- Per domande correlate in modo specifico alla logica di sostituzione di un aggiornamento, vedere prima l'articolo della Knowledge Base per l'aggiornamento per altre informazioni. È anche possibile esaminare la sostituzione all'interno del Catalogo di Microsoft Update, della console WSUS o della console di Configuration Manager.
Problemi di rilevamento
Determinare lo stato di conformità per ogni aggiornamento in un client
- Vedere l'articolo della Knowledge Base degli aggiornamenti per informazioni sui problemi noti relativi all'aggiornamento.
- Eseguire l'azione Ciclo di analisi aggiornamenti software nel client di Configuration Manager.
- Esaminare UpdatesStore.log e WindowsUpdate.log.
Risolvere i problemi di applicabilità degli aggiornamenti
- Controllare se mancano i prerequisiti usando l'articolo della Knowledge Base per l'aggiornamento. Ad esempio, l'aggiornamento richiede che l'applicazione o il sistema operativo vengano sottoposti a patch a un livello di Service Pack specifico?
- Verificare che l'ID aggiornamento univoco dell'aggiornamento in questione corrisponda a ciò che viene distribuito. Ad esempio, l'aggiornamento in questione è un aggiornamento a 32 bit, ma è destinato a un host a 64 bit?
Ulteriori informazioni
Per altre informazioni su come configurare gli aggiornamenti software in Configuration Manager, vedere gli articoli seguenti:
- Pianificare gli aggiornamenti software in Configuration Manager
- Come configurare un punto di aggiornamento software per l'uso del cluster bilanciamento del carico di rete
- Come abilitare il controllo CRL per gli aggiornamenti software
È anche possibile pubblicare una domanda nel forum di supporto di Configuration Manager per la sicurezza, gli aggiornamenti e la conformità qui.
Visitare il blog per tutte le ultime notizie, informazioni e suggerimenti tecnici su Configuration Manager.