Solucionar problemas de gerenciamento de atualização de software no Configuration Manager

Artigo
03/28/2022
28 minutos para ler

Este artigo ajuda você a solucionar problemas do processo de gerenciamento de atualização de software no Configuration Manager. Ele inclui verificação de atualização de software do cliente, problemas de sincronização e problemas de detecção com atualizações específicas.

Versão original do produto: Configuration Manager (branch atual), System Center 2012 R2 Configuration Manager, System Center 2012 Configuration Manager
Número KB original: 4505440

Escopo do seu problema

Este guia assume que um ponto de atualização de software já foi instalado e configurado. Para obter mais informações sobre como configurar atualizações de software no Configuration Manager, consulte Prepare for software updates management.

Antes de começar a solucionar problemas, é importante enfatizar que, quanto melhor você entender o problema que está enfrentando, mais rápido e mais fácil será para você corrigi-lo. Se você tem a tarefa de corrigir um problema que está enfrentando ou um problema relatado por alguém em sua organização, tire um momento e responda às seguintes perguntas:

O que especificamente não está funcionando e/ou qual é o seu objetivo?
Qual é a frequência ou padrão do problema? O problema ainda está acontecendo?
Como você se deu conta de que o problema existe?
Já funcionou? Se sim, quando parou? Alguma coisa foi alterada no ambiente antes de parar de funcionar?
Qual porcentagem de clientes são afetados?
O que já foi feito (se alguma coisa) para tentar corrigi-lo?
Conheça a versão exata do cliente e a versão do servidor. Esses sistemas estão atualizados?
O que os clientes afetados têm em comum? Por exemplo, mesma sub-rede, site do AD, domínio, local físico, site, sistema de sites.

Conhecer e compreender as respostas a essas perguntas colocará você no melhor caminho para uma resolução rápida e fácil para qualquer problema que você esteja enfrentando.

Se você conhece a área específica dentro do processo de gerenciamento de atualização de software que você gostaria de solucionar problemas, selecione-a abaixo. Comece com a verificação de atualização de software do cliente se não tiver certeza e vamos passar por todo o processo do início ao fim.

Verificação de atualização de software cliente
Sincronização do WSUS com o Microsoft Update
Problemas de instalação, supersedência ou detecção com atualizações específicas

Verificação de atualização de software cliente

O processo de verificação do cliente é descrito nas etapas a seguir. Confirme cada etapa para estabelecer corretamente onde o problema está.

Etapa 1: o cliente envia uma solicitação de local WSUS para o ponto de gerenciamento

A primeira coisa que o cliente faz é definir o servidor WSUS que será sua fonte de atualização para verificações de atualização de software. Esse processo é detalhado abaixo.

Quando o cliente do Configuration Manager precisa processar uma verificação de atualização de software, o Agente de Verificação cria uma solicitação de verificação com base na política disponível, conforme notado em 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

O Agente de Verificação agora envia uma solicitação de local WSUS aos Serviços de Localização conforme indicado em 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.

Dica

Cada trabalho de verificação é armazenado no WMI na CCM_ScanJobInstance classe:

Namespace: root\CCM\ScanAgent Classe: CCM_ScanJobInstance

Os Serviços de Localização criam uma solicitação de local e a enviam para o ponto de gerenciamento. A ID do pacote para uma solicitação de local WSUS é a ID exclusiva da fonte de atualização. Em 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}

O CCM Messaging envia a mensagem de solicitação de local para o ponto de gerenciamento. Em CcmMessaging.log:

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

O ponto de gerenciamento analisará essa solicitação e chamará MP_GetWSUSServerLocations o procedimento armazenado para obter os locais WSUS do banco de dados. Em 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

Em 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'

Depois de obter os resultados do procedimento armazenado, o ponto de gerenciamento envia uma resposta ao cliente. Em 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>

O CCM Messaging recebe a resposta e a envia de volta aos Serviços de Localização. Em 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'

Os Serviços de Localização analisarão a resposta e enviarão o local de volta para o Agente de Verificação. Em 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}

O Agente de Verificação agora tem a política e o local de origem de atualização com a versão de conteúdo apropriada. Em 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

O Agente de Verificação notifica WUAHandler para adicionar a fonte de atualização. WUAHandler adiciona a fonte de atualização ao Registro. Ele inicia uma atualização de Política de Grupo se o cliente estiver no domínio para ver se a Política de Grupo substitui o servidor de atualização adicionado. As entradas a seguir são registradas em WUAHandler.log mostrando uma nova Fonte de Atualização sendo adicionada:

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 esse tempo, o Windows Update Agent vê uma alteração de configuração do WSUS. Em WindowsUpdate.log:

* WSUS server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
* WSUS status server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
Sus server changed through policy.

As seguintes chaves do Registro são verificadas e definidas:

Subchave do Registro	Nome do valor	Tipo	Dados
`HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate`	`WUServer`	REG_SZ	A URL completa do servidor WSUS, incluindo a porta. Por exemplo, <`http://PS1Site.Contoso.com:8530`>
`HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate`	WUStatusServer	REG_SZ	A URL completa do servidor WSUS, incluindo a porta. Por exemplo, <`http://PS1Site.Contoso.com:8530`>
`HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU`	`UseWUServer`	REG_DWORD	0x1

Para um cliente existente, podemos esperar ver a seguinte mensagem em WUAHandler.log para indicar quando a versão de conteúdo tiver sido incrementada:

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

Depois que a fonte de atualização for adicionada com êxito, o Agente de Verificação levantará uma mensagem de estado e iniciará a verificação. Em ScanAgent.log:

ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2  
ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

Solucionar problemas na etapa 1

Problemas O que verificar

ScanAgent.log não mostra nenhuma política disponível para uma fonte de atualização e nenhum WUAHandler.log existe ou nenhuma atividade atual no WUAHandler.log Verifique a configuração Habilitar atualizações de software nos clientes.

O Agente de Verificação ou Os Serviços de Localização não recebe o local do servidor WSUS

Problemas	O que verificar
ScanAgent.log não mostra nenhuma política disponível para uma fonte de atualização e nenhum WUAHandler.log existe ou nenhuma atividade atual no WUAHandler.log	Verifique a configuração Habilitar atualizações de software nos clientes.
O Agente de Verificação ou Os Serviços de Localização não recebe o local do servidor WSUS	Uma função de ponto de atualização de software (SUP) está instalada para o site? Caso não seja, instale e configure um ponto de atualização de software e monitore SUPSetup.log para progresso. Para obter mais informações, consulte Instalar e configurar um ponto de atualização de software. Se uma função SUP estiver instalada, ela será configurada e sincronizada? Verifique WCM.log, WSUSCtrl.log e WSyncMgr.log para ver se há erros. `select * from WSUSServerLocations` `select * from Update_SyncStatus`
O cliente recebe o local do WSUS, mas falha ao configurar as chaves do Registro WSUS	A atualização da Política de Grupo respondeu dentro do tempo de tempo de 2 minutos por WUAHandler.log? Se sim, o WUAHandler denota que as configurações de política de grupo foram substituídas por uma autoridade superior (Controlador de Domínio)? Para obter mais informações, consulte Política de Grupo substitui as informações corretas de configuração do WSUS.

Uma função de ponto de atualização de software (SUP) está instalada para o site?
Caso não seja, instale e configure um ponto de atualização de software e monitore SUPSetup.log para progresso. Para obter mais informações, consulte Instalar e configurar um ponto de atualização de software.
Se uma função SUP estiver instalada, ela será configurada e sincronizada?
Verifique WCM.log, WSUSCtrl.log e WSyncMgr.log para ver se há erros.
- select * from WSUSServerLocations
- select * from Update_SyncStatus

O cliente recebe o local do WSUS, mas falha ao configurar as chaves do Registro WSUS

A atualização da Política de Grupo respondeu dentro do tempo de tempo de 2 minutos por WUAHandler.log? Se sim, o WUAHandler denota que as configurações de política de grupo foram substituídas por uma autoridade superior (Controlador de Domínio)?

Para obter mais informações, consulte Política de Grupo substitui as informações corretas de configuração do WSUS.

Para obter mais informações sobre a solução de problemas de falhas de verificação de atualização de software, consulte Solucionar falhas de verificação de atualização de software.

Etapa 2: o Agente de Verificação solicita a verificação e WUAHandler inicia a verificação

Depois que o cliente identificar e definir o servidor WSUS que será sua fonte de atualização para verificações de atualização de software, o Agente de Verificação solicita a verificação do WUAHandler que usa a API do agente de atualização do Windows para solicitar uma verificação de atualização de software do agente de atualização Windows. Uma verificação pode resultar de:

Uma verificação de atualização de software agendada ou manual
Uma reavaliação de implantação agendada ou manual atualizada por software
Uma implantação que se torna ativa

A verificação dispara uma avaliação. Em ScanAgent.log:

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

Os resultados da verificação incluirão atualizações superadas somente quando elas são superadas por service packs e atualizações de definição. Em 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.

Dica

Revise WUAHandler.log após uma verificação de atualização de software para ver se ocorrem novas entradas. Se nenhuma nova entrada ocorrer, indica que nenhum SUP será retornado pelo ponto de gerenciamento.

Solucionar problemas na etapa 2

Muitos problemas com a verificação de atualização de software podem ser causados por um dos seguintes motivos:

Arquivos ausentes ou corrompidos ou chaves do Registro.
Problemas de registro de componentes.

Para corrigir esses problemas, consulte Verificar falhas devido a componentes ausentes ou corrompidos.

Há um problema conhecido de que um cliente 7 ConfigMgr 2012 R2 de 32 bits Windows 7 ConfigMgr 2012 R2 que solicita uma verificação de atualização não retorna resultados de verificação para o Configuration Manager. Isso faz com que o cliente reporte o status de conformidade incorreto e as atualizações não são instaladas quando o Configuration Manager solicita o ciclo de atualização. No entanto, se você usar o Windows painel de controle Atualizar, as atualizações geralmente instalam bem. Ao enfrentar esse problema, você recebe uma mensagem semelhante à seguinte em WindowsUpdate.log:

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

É um problema de alocação de memória, os computadores de 64 bits Windows 7 não verão esse erro, pois seu espaço de endereço é efetivamente ilimitado. No entanto, eles exibirão alta memória e alto uso da CPU, possivelmente afetando o desempenho. Os clientes X86 também exibirão alto uso de memória (geralmente em torno de 1,2 GB a 1,4 GB).

Para corrigir esse problema, Windows Atualizar Cliente para Windows 7: junho de 2015.

Ao solucionar problemas de falhas de verificação, verifique os arquivos WUAHandler.log e WindowsUpdate.log. WUAHandler simplesmente relata o que Windows Update Agent reportou. Portanto, o erro em WUAHandler seria o mesmo erro relatado pelo próprio agente de atualização Windows de atualização. Mais informações sobre o erro podem ser encontradas em WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Windows atualizar arquivos de log.

Sua melhor fonte de informações virá dos logs e dos códigos de erro que eles contêm. Para obter mais informações sobre os códigos de erro, consulte Windows Atualizar erros comuns e mitigação.

Etapa 3: Windows Agente de Atualização (WUA) inicia a verificação no computador WSUS

Windows Update Agent inicia uma verificação após receber uma solicitação do cliente do Configuration Manager (CcmExec). Se esses valores do Registro são definidos corretamente para um computador WSUS que é um SUP válido para o site por meio de uma política local, você deverá ver uma solicitação de pesquisa de API COM do cliente configuration Manager (ClientId = CcmExec). Em 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]

Solucionar problemas na etapa 3

Durante uma verificação, o Windows Update Agent ClientWebService SimpleAuthWebService precisa se comunicar com os diretórios virtuais e no computador WSUS para executar uma verificação. Se o cliente não puder se comunicar com o computador WSUS, a verificação falhará. Esse problema pode acontecer por vários motivos, incluindo:

Problemas relacionados a proxy

Para corrigir esses problemas, consulte Verificar falhas devido a problemas relacionados a proxy.

Para obter mais informações sobre servidores proxy, consulte os seguintes artigos:
- Como o cliente Windows Update determina qual servidor proxy usar para se conectar ao site Windows Atualizar
- Suporte a DNS e DHCP para Descoberta Automática de Cliente de Proxy web e Firewall
Erros de tempo de tempo de HTTP

Para solucionar erros de tempo de tempo HTTP, primeiro revise os logs de Serviços de Informações da Internet (IIS) no computador WSUS para confirmar se os erros estão realmente sendo retornados do WSUS. Se o computador WSUS não estiver retornando o erro, o problema provavelmente será com um firewall ou proxy intermediário.

Se o computador WSUS estiver retornando o erro, verifique a conectividade com o computador WSUS. Estas são as etapas:
1. Para confirmar se o cliente está se conectando ao servidor WSUS correto, localize a URL do computador WSUS usada pelo cliente Windows Update Agent. Essa URL pode ser encontrada verificando a HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate sub-chave do Registro ou exibindo o arquivo WindowsUpdate.log.
  
  Os motivos comuns para que a atribuição WSUS possa estar incorreta incluem:
  - Conflitos de Política de Grupo
  - A adição de um SUP a um site secundário após a instalação inicial do cliente
  Observação
  
  A Política de Grupo do Active Directory pode substituir a política WSUS local.
  
  O recurso de atualizações de software configura automaticamente uma configuração de Política de Grupo local para o cliente do Configuration Manager para que ele seja configurado com o local de origem e o número da porta do ponto de atualização de software. O nome do servidor e o número da porta são necessários para que o cliente localize o ponto de atualização de software.
  
  Se uma configuração de Política de Grupo do Active Directory for aplicada aos computadores para instalação do cliente de ponto de atualização de software, ela substituirá a configuração de Política de Grupo local. Se o valor da configuração definida na Política de Grupo do Active Directory for diferente do definido pelo Configuration Manager, a verificação falhará no cliente porque não pode localizar o computador WSUS correto. Nesta situação, WUAHandler.log mostrará a seguinte mensagem:
  
  As configurações de política de grupo foram substituídas por uma autoridade superior (Controlador de Domínio) para: Servidor <http://server> e Política HABILITADA
  
  O ponto de atualização de software para a instalação do cliente e as atualizações de software devem ser o mesmo servidor. E ele deve ser especificado na configuração da Política de Grupo do Active Directory com o formato de nome correto e informações de porta. Por exemplo, seria se o <http://server1.contoso.com:80> ponto de atualização de software estivesse usando o site padrão.
2. Se a URL do servidor estiver correta, acesse o servidor usando uma URL semelhante à seguinte para verificar a conectividade entre o cliente e o computador WSUS:
  
  <http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab>
  
  Para verificar se o cliente pode acessar o ClientWebService diretório virtual, tente acessar uma URL semelhante a esta:
  
  <http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml>
  
  Para verificar se o cliente pode acessar SimpleAuthWebServiceo , tente acessar uma URL semelhante a esta:
  
  <http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx>
  
  Se alguma dessas URLs falhar, alguns dos motivos possíveis incluem:
  - Problemas de resolução de nomes no cliente. Verifique se você pode resolver o FQDN do computador WSUS.
  - Problemas de configuração de proxy.
  - Outros problemas de conectividade relacionados à rede.
  - Problemas de configuração de porta, portanto, é uma boa ideia verificar se as configurações de porta estão corretas. O WSUS pode ser configurado para usar qualquer uma das seguintes portas: 80, 443 ou 8530, 8531.
    
    Para que os clientes se comuniquem com o computador WSUS, as portas apropriadas devem ser permitidas no firewall no computador WSUS. As configurações de porta são configuradas quando a função de sistema de site de ponto de atualização de software é criada. Essas configurações de porta devem ser as mesmas que as configurações de porta usadas pelo site do WSUS. Caso contrário, o WSUS Synchronization Manager falhará ao se conectar ao WSUS em execução no ponto de atualização de software para solicitar a sincronização. Os procedimentos a seguir fornecem informações sobre como verificar as configurações de porta usadas pelo WSUS e o ponto de atualização de software.
    1. Determine as configurações de porta WSUS usadas no IIS 7.0 e versões posteriores.
    2. Determine as configurações da porta WSUS no IIS 6.0.
    3. Configure portas para o ponto de atualização de software.
    4. Verificar a conectividade de porta
      
      Para verificar a conectividade de porta do cliente, execute o seguinte comando:
```
telnet SUPSERVER.CONTOSO.COM <portnumber>
```
      Por exemplo, execute o seguinte comando se a porta for 8530:
```
telnet SUPSERVER.CONTOSO.COM 8530
```
      Se a porta não estiver acessível, a telnet retornará um erro semelhante ao seguinte:
      
      Não foi possível abrir a conexão com o host, na porta <PortNumber>
      
      Este erro sugere que as regras de firewall não estão configuradas para permitir a comunicação para o computador WSUS. Esse erro também pode sugerir que um dispositivo de rede intermediário está bloqueando essa porta. Para verificar, tente o mesmo teste de um cliente na mesma sub-rede local. Se funcionar, os computadores serão configurados corretamente. No entanto, um roteador ou firewall entre segmentos está bloqueando a porta e causando a falha.
  - Problemas de disponibilidade do IIS.
    1. No computador WSUS, abra o Gerenciador Serviços de Informações da Internet (IIS).
    2. Expanda Sites, clique com o botão direito do mouse no site do computador WSUS e clique em Editar Vinculações.
    3. Na caixa de diálogo Vinculações de Site, os valores de porta HTTP e HTTPS são exibidos na coluna Porta .
    4. No servidor WSUS, abra o Gerenciador Serviços de Informações da Internet (IIS).
    5. Expanda Sites, clique com o botão direito do mouse no site do computador WSUS e clique em Propriedades.
    6. Clique na guia Site . A configuração da porta HTTP é exibida na porta TCP e a configuração da porta HTTPS é exibida na porta SSL.
    7. No console do Configuration Manager, vá para AdministrationSite > ConfigurationServers > e Funções do Sistema de Site e <SiteSystemName> clique no painel à direita.
    8. No painel inferior, clique com o botão direito do mouse em Ponto de Atualização de Software e clique em Propriedades.
    9. Vá para a guia Geral , especifique ou verifique os números da porta de configuração do WSUS.
Erros de autenticação

Normalmente é indicado quando a verificação falha com erros de autenticação 0x80244017 (Http Status 401) ou 0x80244018 (Http Status 403).

Primeiro, confirme as configurações corretas de proxy WinHTTP usando os seguintes comandos:
- No Windows Vista ou versões posteriores:netsh winhttp show proxy
- No Windows XP:proxycfg.exe
Se as configurações de proxy estão corretas, verifique a conectividade com o computador WSUS concluindo as etapas em erros de tempo de tempo HTTP. Revise também os logs do IIS no computador WSUS para confirmar se os erros HTTP estão sendo retornados do WSUS. Se o computador WSUS não estiver retornando o erro, o problema provavelmente será com um firewall ou proxy intermediário.
Problemas de certificado

Os problemas de certificado são indicados pelo código de 0x80072F0C que significa "Um certificado é necessário para concluir a autenticação do cliente". Para corrigir esse problema, consulte Scan fails with error 0x80072f0c.

Etapa 4: WUAHandler recebe resultados do Windows Update Agent e marca a verificação como concluída

Os seguintes estão registrados em WUAHandler.log:

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

Solucionar problemas na etapa 4

Os problemas aqui devem ser resolvidos da mesma forma que falhas de verificação na etapa 3.

Conforme mencionado anteriormente neste guia, ao solucionar problemas de falhas de verificação, verifique os arquivos WUAHandler.log e WindowsUpdate.log. WUAHandler simplesmente relata o que Windows Update Agent reportou. Portanto, o erro em WUAHandler seria o mesmo erro relatado pelo agente de atualização Windows em si. Mais informações sobre o erro podem ser encontradas em WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Windows atualizar arquivos de log.

Há muitos motivos pelos quais uma verificação de atualização de software pode falhar. Pode ser causado por um dos problemas mencionados anteriormente ou por um problema de comunicação ou firewall entre o cliente e o computador de ponto de atualização de software. Sua melhor fonte de informações virá dos logs e dos códigos de erro que eles contêm. Para obter mais informações sobre os códigos de erro, consulte Windows Atualizar erros comuns e mitigação.

Etapa 5: WUAHandler analisará os resultados da verificação

WUAHandler, em seguida, analisará os resultados, que incluem o estado de aplicabilidade para cada atualização. Como parte desse processo, as atualizações supersedadas são podadas. O estado de aplicabilidade é verificado para todas as atualizações que se alinham aos critérios enviados pelo CCMExec ao Windows Update Agent. O importante a ser entendido aqui é que você deve ver os resultados de aplicabilidade para atualizações se essas atualizações estão em uma implantação ou não.

As seguintes entradas são registradas em 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.

Solucionar problemas na etapa 5

Os problemas podem ser resolvidos da mesma forma que falhas de verificação na etapa 3.

De modo geral, há muitos motivos pelos quais uma verificação de atualização de software pode falhar. Pode ser causado por um dos problemas mencionados anteriormente ou por um problema de comunicação ou firewall entre o cliente e o computador de ponto de atualização de software. Sua melhor fonte de informações virá dos logs e dos códigos de erro que eles contêm. Como referência, consulte Windows Atualizar erros comuns e mitigação.

Etapa 6: Atualizar o armazenamento registra o status e gera uma mensagem de estado para cada atualização no WMI

Depois que os resultados da verificação estão disponíveis, esses resultados são armazenados no armazenamento de atualizações. Atualizar o armazenamento registra o estado atual de cada atualização e cria uma mensagem de estado para cada atualização. Essas mensagens de estado são encaminhadas para o servidor do site em massa no final do ciclo de relatório de mensagens de status (que é minutos, por padrão). Enviaremos apenas uma mensagem de estado sob as seguintes circunstâncias:

Uma mensagem de estado anterior nunca foi enviada para uma atualização (entrada de log: não foi relatada antes, criando uma nova instância).
O estado de aplicabilidade de uma atualização foi alterado desde que a última mensagem de estado foi enviada.

UpdatesStore.log mostrando o estado da atualização ausente (KB2862152) sendo gravada e uma mensagem de estado sendo aparecendo:

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 mostrando o estado que está sendo gravado com a ID de Estado 2 (ausente):

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

Dica

Para cada atualização, uma instância da classe CCM_UpdateStatus é criada ou atualizada e armazena o status atual da atualização. A CCM_UpdateStatus classe está localizada no ROOT\CCM\SoftwareUpdates\UpdatesStore namespace.

Solucionar problemas na etapa 6

Os problemas aqui devem ser resolvidos da mesma forma que falhas de verificação na etapa 3.

Etapa 7: As mensagens de estado são enviadas para o ponto de gerenciamento

Quando WUAHandler recebe com êxito os resultados do agente de atualização Windows, ele marca a verificação como concluída e registra a seguinte mensagem em WUAHandler.log:

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

Solucionar problemas na etapa 7

Os problemas aqui devem ser resolvidos da mesma forma que falhas de verificação na etapa 3, embora as falhas neste estágio provavelmente sejam atendidas no arquivo WindowsUpdate.log especificamente. Para entender como ler WindowsUpdate.log, consulte Windows atualizar arquivos de log.

Sincronização do WSUS com o Microsoft Update

A sincronização do WSUS com o Microsoft Update é descrita nas etapas a seguir. Confirme cada etapa para estabelecer corretamente onde o problema está.

Etapa 1: a sincronização começa por meio de uma solicitação agendada ou manual

Quando uma sincronização é disparada, esperamos ver as seguintes mensagens no SoftwareDistribution.log do servidor WSUS:

Para sincronização manual:

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

Para sincronização agendada:

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

Solucionar problemas de sincronização manual na etapa 1

Confirme se o serviço WSUS está em execução. Se uma sincronização manual foi iniciada, mas permanece em 0%, é porque o serviço WSUS (Update Services on WSUS 3.x; O WSUSService Windows Server 2012 e versões posteriores) está em estado interrompido.
Redefinir o cache MMC do console do WSUS seguindo estas etapas:
1. Feche o console do WSUS.
2. Interromper o serviço WSUS (Atualizar Serviços no WSUS 3.x; Serviço WSUS em Windows Server 2012 e versões posteriores).
3. Navegue até %appdata%\Microsoft\mmc.
4. Renomeie wsus para wsus_bak.
5. Inicie o serviço WSUS.
6. Abra o console do WSUS e tente outra sincronização manual.

Solucionar problemas de sincronização agendada na etapa 1

Experimente uma sincronização manual do console WSUS.
Se uma sincronização manual funcionar bem, verifique as configurações de sincronização agendadas.

Etapa 2: O WSUS gera uma conexão com o Microsoft Update (MU)

Depois que uma sincronização é iniciada, o servidor WSUS tenta fazer uma conexão HTTP por meio do WinHTTP. Considere os seguintes fatores ao solucionar problemas da conexão:

WSUS <=winhttp=> entidades de rede <=> Internet

Existe uma entidade de rede (proxy, firewall, filtro de segurança e assim por diante) entre a máquina host WSUS e a Internet?
Se houver um proxy e o servidor WSUS for necessário para usar o proxy, o proxy será configurado dentro das configurações adequadas do WSUS?

Solucionar problemas de sincronização manual na etapa 2

Confirme se o serviço WSUS está em execução. Se uma sincronização manual foi iniciada, mas ela permanece em 0%, é porque o serviço WSUS (Update Services on WSUS 3.x; O Serviço WSUS Windows Server 2012 e versões posteriores) está em estado interrompido.
Reset the WSUS console MMC cache by completing the following steps:
1. Feche o console do WSUS.
2. Interromper o serviço WSUS (Atualizar Serviços no WSUS 3.x; Serviço WSUS em Windows Server 2012 e versões posteriores).
3. Navegue até %appdata%\Microsoft\mmc.
4. Renomeie wsus para wsus_bak.
5. Inicie o serviço WSUS.
6. Abra o console do WSUS e tente outra sincronização manual.

Solucionar problemas de sincronização agendada na etapa 2

Experimente uma sincronização manual do console WSUS.
Se uma sincronização manual funcionar bem, verifique as configurações de sincronização agendadas.

Etapa 3: o computador WSUS recebe informações de produto e classificação do Microsoft Update e quaisquer metadados inscritos

Depois que o WSUS receber informações de produto e classificação e quaisquer metadados inscritos do Microsoft Update, a sincronização do WSUS será concluída.

Problemas de instalação, supersedência ou detecção com atualizações específicas

Problemas de implantação que ocorrem com atualizações específicas podem ser divididos nas áreas abaixo. Ao começar a solucionar problemas, considere os seguintes componentes associados a essas áreas.

Áreas	Instalação	Supersedência	Detecção
Componentes	WUA Update Installer (Serviço Baseado em Componente (CBS), MSI) CCMExec	Atualizar metadados	WUA Atualizar metadados Update Installer (CBS, MSI)

Problemas de instalação

O que é o instalador (CBS, MSI, outros)?

CBS

Para atualizações que se aplicam ao Windows Vista e versões posteriores, o CBS é usado para lidar com a instalação.

Reúna o log CBS (%Windir%\Logs\Cbs\Cbs.log) e execute uma revisão inicial para obter informações sobre a causa da falha. A solução de problemas baseados em instalação por meio de logs CBS está além do escopo deste guia. Para obter mais informações, consulte Corrigir Windows erros de corrupção usando a ferramenta de Preparação de Atualização do Sistema ou DISM.
A atualização é instalada com êxito como um usuário conectado? Nesse caso, ele falhará somente quando estiver instalado no contexto do sistema? Nesse caso, concentre-se na solução de problemas da falha de instalação manual no contexto do sistema.

MSI (Windows Instalador)

Para atualizações de software não Windows, o MSI é usado para lidar com a instalação.

Reúna e revise os logs MSI padrão para a atualização. Verifique o artigo KB associado para saber se há problemas conhecidos ou perguntas frequentes.
Habilita Windows log do Instalador e reproduza a falha.

Ao revisar os logs resultantes, verifique se há o valor de retorno 3 no log e as linhas anteriores a essa entrada para saber mais sobre a falha.
Verifique se a mesma atualização falha ao instalar manualmente no contexto do sistema local. Para fazer isso, use as mesmas opções de instalação que falharam durante a implantação da atualização de software.

Se falhar, teste a instalação como o usuário conectado com as mesmas opções de instalação. Verifique se há um problema com a instalação no sistema local. Se funcionar, você poderá então concentrar o problema em como instalar corretamente a atualização usando o contexto do sistema local. Pode exigir a verificação das diretrizes de implantação administrativa no KB para a atualização ou online.

Problemas de supersedência

Tente isolar o problema relacionado à supersedência usando as seguintes perguntas:

Para saber mais sobre como controlar quando o Configuration Manager expirar uma atualização, consulte Regras de supersedência.
Se uma atualização tiver expirado pelo Configuration Manager, a Microsoft recomenda que a atualização de supersedação mais recente seja implantada. Se você ainda precisar implantar as atualizações expiradas, elas poderão ser implantadas fora de uma implantação de atualização de software por meio da distribuição de software ou do gerenciamento de aplicativos.
Para perguntas relacionadas especificamente à lógica de supersedência de uma atualização, primeiro revise o artigo KB para obter mais informações. Você também pode revisar a supersedência no Catálogo de Atualizações da Microsoft, no console do WSUS ou no console do Configuration Manager.

Problemas de detecção

Determinar o estado de conformidade por atualização em um cliente

Revise o artigo do KB de atualização para saber se há problemas conhecidos com a atualização.
Execute a ação Ciclo de Verificação de Atualizações de Software no cliente do Configuration Manager.
Revise UpdatesStore.log e WindowsUpdate.log.

Solucionar problemas de aplicabilidade de atualização

Verifique se algum pré-requisito está faltando usando o artigo KB para a atualização. Por exemplo, a atualização exige que o aplicativo ou o sistema operacional seja remendado para um nível de service pack específico?
Confirme se a ID de Atualização Exclusiva da atualização em questão corresponde ao que é implantado. Por exemplo, a atualização em questão é uma atualização de 32 bits, mas direcionada a um host de 64 bits?

Mais informações

Para obter mais informações sobre como configurar atualizações de software no Configuration Manager, consulte os seguintes artigos:

Você também pode postar uma pergunta em nosso fórum de suporte do Configuration Manager para segurança, atualizações e conformidade aqui.

Visite nosso blog para obter todas as últimas notícias, informações e dicas técnicas sobre o Configuration Manager.