Solucionar problemas de gerenciamento de atualização de software no Configuration Manager
Este artigo ajuda você a solucionar problemas do processo de gerenciamento de atualização de software no Configuration Manager. Inclui verificação de atualização de software 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 original do KB: 4505440
Escopo do seu problema
Este guia pressupõe que um ponto de atualização de software já tenha sido instalado e configurado. Para obter mais informações sobre como configurar atualizações de software no Configuration Manager, consulte Preparar-se para o gerenciamento de atualizações de software.
Antes de iniciar a solução de problemas, é importante enfatizar que, quanto melhor você entender o problema que está enfrentando, mais rápido e fácil será corrigi-lo. Se você tem a tarefa de corrigir um problema que está enfrentando ou um problema relatado a você por alguém em sua organização, reserve 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 para o problema? O problema ainda está acontecendo?
- Como você percebeu que o problema existe?
- Já funcionou? Se sim, quando parou? Alguma coisa mudou no ambiente logo antes de parar de funcionar?
- Qual a porcentagem de clientes afetados?
- O que já foi feito (se é que foi feito) para tentar consertá-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 entender as respostas a essas perguntas o colocará no melhor caminho para uma resolução rápida e fácil de qualquer problema que esteja enfrentando.
Se você conhece a área específica do processo de gerenciamento de atualizações de software que deseja solucionar, selecione-a abaixo. Comece com a verificação de atualização de software cliente se não tiver certeza e percorreremos todo o processo do começo ao fim.
- Verificação de atualização de software cliente
- Sincronização do WSUS com o Microsoft Update
- Problemas de instalação, substituição 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 está o problema.
Etapa 1: O cliente envia uma solicitação de localização do 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 observado no 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 localização do WSUS para os Serviços de Localização, conforme observado na 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 localização e a enviam para o ponto de gerenciamento. A ID do pacote para uma solicitação de local do 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 localização 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 analisa essa solicitação e chama o
MP_GetWSUSServerLocations
procedimento armazenado para obter os locais do 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
No 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 analisam a resposta e enviam o local de volta ao 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 da 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 o 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 seguintes entradas são registradas 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 do conteúdo foi 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 gerará 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 nenhuma WUAHandler.log existe ou nenhuma atividade atual dentro WUAHandler.log | Verifique a configuração Habilitar atualizações de software em clientes . |
O Agente de Verificação ou os Serviços de Localização não recebem o local do servidor WSUS |
|
O cliente recebe o local do WSUS, mas não consegue configurar as chaves do Registro do WSUS | A atualização da Diretiva de Grupo respondeu dentro do tempo limite de 2 minutos por WUAHandler.log? Em caso afirmativo, o WUAHandler indica 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 problemas de falhas de verificação de atualização de software.
Etapa 2: O Agente de Verificação solicita a verificação e o WUAHandler inicia a verificação
Depois que o cliente tiver identificado e definido o servidor WSUS que será sua fonte de atualização para verificações de atualização de software, o Agente de Verificação solicitará a verificação do WUAHandler que usa a API do Windows Update Agent para solicitar uma verificação de atualização de software do Windows Update Agent. Uma varredura pode resultar de:
- Uma verificação de atualização de software agendada ou manual
- Uma reavaliação de implantação atualizada de software agendada ou manual
- Uma implantação que se torna ativa
A verificação aciona uma avaliação. Em ScanAgent.log:
ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
Os resultados da verificação incluirão atualizações substituídas somente quando forem substituídas 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, isso indicará que nenhum SUP é 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 ou chaves de registro ausentes ou corrompidos.
- Problemas de registro de componentes.
Para corrigir esses problemas, consulte Falhas de verificação devido a componentes ausentes ou corrompidos.
Há um problema conhecido de que um cliente Windows 7 ConfigMgr 2012 R2 de 32 bits solicitando uma verificação de atualização não retorna os resultados da verificação para Configuration Manager. Isso faz com que o cliente relate o status de conformidade incorreto e as atualizações não sejam instaladas quando o Configuration Manager solicita o ciclo de atualização. No entanto, se você usar o miniaplicativo do painel de controle do Windows Update, as atualizações geralmente serão instaladas corretamente. Quando você estiver enfrentando esse problema, receberá uma mensagem semelhante à seguinte em WindowsUpdate.log:
WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E
É um problema de alocação de memória, os computadores com Windows 7 de 64 bits 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, aplique o Windows Update Client 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 o Windows Update Agent relatou. Portanto, o erro no WUAHandler seria o mesmo erro relatado pelo próprio Windows Update Agent. Mais informações sobre o erro podem ser encontradas em WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Arquivos de log do Windows Update.
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 Erros comuns e mitigação do Windows Update.
Etapa 3: Windows Update Agent (WUA) inicia a verificação no computador WSUS
O Windows Update Agent inicia uma verificação depois de receber uma solicitação do cliente do Configuration Manager (CcmExec). Se esses valores do Registro forem definidos corretamente para um computador WSUS que seja um SUP válido para o site por meio de uma política local, você deverá ver uma solicitação de pesquisa da 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 precisa se comunicar com os ClientWebService
diretórios virtuais e SimpleAuthWebService
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:
Questões relacionadas com procuração
Para corrigir esses problemas, consulte Falhas de verificação devido a problemas relacionados ao proxy.
Para obter mais informações sobre servidores proxy, consulte os seguintes artigos:
Erros de tempo limite HTTP
Para solucionar erros de tempo limite HTTP, primeiro examine os logs do IIS (Serviços de Informações da Internet) 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 está 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:
Para confirmar se o cliente está se conectando ao servidor WSUS correto, localize a URL do computador WSUS usado pelo cliente Windows Update Agent. Essa URL pode ser encontrada verificando a subchave do
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
Registro ou exibindo o arquivo WindowsUpdate.log.Os motivos comuns pelos quais a atribuição do WSUS pode estar incorreta incluem:
- Conflitos de Diretiva 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 local do WSUS.
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 do ponto de atualização de software e o número da porta. O nome do servidor e o número da porta são necessários para que o cliente encontre o ponto de atualização de software.
Se uma configuração de Diretiva de Grupo do Active Directory for aplicada a computadores para instalação do cliente do ponto de atualização de software, ela substituirá a configuração de Diretiva de Grupo local. Se o valor da configuração definida na Política de Grupo do Active Directory for diferente daquele definido pelo Configuration Manager, a verificação falhará no cliente porque ele não pode localizar o computador WSUS correto. Nessa 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 ENABLEDO ponto de atualização de software para instalação do cliente e atualizações de software deve ser o mesmo servidor. E deve ser especificado na configuração da Política de Grupo do Active Directory com o formato de nome e as informações de porta corretos. Por exemplo, seria <
http://server1.contoso.com:80
> se o ponto de atualização de software estivesse usando o site padrão.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 o
SimpleAuthWebService
, tente acessar uma URL semelhante a esta:<
http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx
>Se algum desses URLs falhar, alguns dos possíveis motivos 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 do computador WSUS. As configurações de porta são definidas quando a função do sistema de sites do 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 Gerenciador de Sincronização do WSUS não conseguirá 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.
Determine as configurações de porta do WSUS usadas no IIS 7.0 e versões posteriores.
Determine as configurações de porta do WSUS no IIS 6.0.
Configure portas para o ponto de atualização de software.
Verificar a conectividade da porta
Para verificar a conectividade da 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, o telnet retornará um erro semelhante ao seguinte:
Não foi possível abrir a conexão com o host, na porta <PortNumber>
Esse 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 estão configurados corretamente. No entanto, um roteador ou firewall entre segmentos está bloqueando a porta e causando a falha.
Problemas de disponibilidade do IIS.
- No computador WSUS, abra o Gerenciador de Serviços de Informações da Internet (IIS).
- Expanda Sites, clique com o botão direito do mouse no site do computador WSUS e clique em Editar Associações.
- Na caixa de diálogo Associações de Site, os valores de porta HTTP e HTTPS são exibidos na coluna Porta.
- No servidor WSUS, abra o Gerenciador de Serviços de Informações da Internet (IIS).
- Expanda Sites, clique com o botão direito do mouse no site do computador WSUS e clique em Propriedades.
- 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.
- No console do Configuration Manager, vá para Servidores de Configuração>do Site de Administração>e Funções do Sistema de Sites e clique no painel direito SiteSystemName.<>
- No painel inferior, clique com o botão direito do mouse em Ponto de Atualização de Software e clique em Propriedades.
- Vá para a guia Geral , especifique ou verifique os números de porta de configuração do WSUS.
Erros de autenticação
Normalmente, é indicado quando a verificação falha com erros de autenticação 0x80244017 (Status HTTP 401) ou 0x80244018 (Status HTTP 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 estiverem corretas, verifique a conectividade com o computador WSUS concluindo as etapas em Erros de tempo limite HTTP. Examine 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 está com um firewall ou proxy intermediário.
- No Windows Vista ou versões posteriores:
Problemas de certificado
Os problemas de certificado são indicados pelo código de erro 0x80072F0C que significa "Um certificado é necessário para concluir a autenticação do cliente". Para corrigir esse problema, consulte Falha na verificação com 0x80072f0c de erro.
Etapa 4: WUAHandler recebe resultados do Windows Update Agent e marca a verificação como concluída
Os seguintes itens estão conectados 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 as 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 o Windows Update Agent relatou. Portanto, o erro no WUAHandler seria o mesmo erro relatado pelo próprio Windows Update Agent. Mais informações sobre o erro podem ser encontradas em WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Arquivos de log do Windows Update.
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 do 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 Erros comuns e mitigação do Windows Update.
Etapa 5: WUAHandler analisa os resultados da verificação
Em seguida, o WUAHandler analisa os resultados, que incluem o estado de aplicabilidade para cada atualização. Como parte desse processo, as atualizações substituídas são removidas. 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 entender aqui é que você deve ver os resultados de aplicabilidade das atualizações, independentemente de essas atualizações estarem em uma implantação ou não.
As seguintes entradas são registradas 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 as 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 o Windows Update Agent relatou. Portanto, o erro no WUAHandler seria o mesmo erro relatado pelo próprio Windows Update Agent. Mais informações sobre o erro podem ser encontradas em WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Arquivos de log do Windows Update.
De um 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 do 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 Erros comuns e mitigação do Windows Update.
Etapa 6: O repositório de atualizações registra o status e gera uma mensagem de estado para cada atualização no WMI
Depois que os resultados da verificação estiverem disponíveis, esses resultados serão armazenados no repositório de atualizações. O repositório de atualizações 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 são minutos, por padrão). Só enviamos uma mensagem de estado nas 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 registrada e uma mensagem de estado sendo gerada:
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 a mensagem de estado sendo registrada com o 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 CCM_UpdateStatus
classe é criada ou atualizada e armazena o status atual da atualização. A classe CCM_UpdateStatus
está no namespace ROOT\CCM\SoftwareUpdates\UpdatesStore
.
Solucionar problemas na etapa 6
Os problemas aqui devem ser resolvidos da mesma forma que as 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 o Windows Update Agent relatou. Portanto, o erro no WUAHandler seria o mesmo erro relatado pelo próprio Windows Update Agent. Mais informações sobre o erro podem ser encontradas em WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Arquivos de log do Windows Update.
De um 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 do 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 Erros comuns e mitigação do Windows Update.
Etapa 7: As mensagens de estado são enviadas para o ponto de gerenciamento
Quando o WUAHandler recebe com êxito os resultados do Windows Update Agent, 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 as falhas de verificação na etapa 3, embora as falhas neste estágio provavelmente sejam exibidas especificamente no arquivo WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Arquivos de log do Windows Update.
De um 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 do 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 Erros comuns e mitigação do Windows Update.
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 está o problema.
Etapa 1: a sincronização é iniciada 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 tiver sido iniciada, mas permanecer em 0%, é porque o serviço WSUS (Update Services no WSUS 3.x; WSUSService no Windows Server 2012 e versões posteriores) está em um estado parado.
Redefina o cache MMC do console do WSUS seguindo estas etapas:
- Feche o console do WSUS.
- Interromper o serviço WSUS (Update Services no WSUS 3.x; Serviço WSUS no Windows Server 2012 e versões posteriores).
- Navegue até
%appdata%\Microsoft\mmc
. - Renomeie wsus para wsus_bak.
- Inicie o serviço WSUS.
- Abra o console do WSUS e tente outra sincronização manual.
Solucionar problemas de uma sincronização agendada na etapa 1
- Tente uma sincronização manual no console do 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 de conexão:
WSUS <=winhttp=> Entidades <de rede => Internet
- Existe uma entidade de rede (proxy, firewall, filtro de segurança e assim por diante) entre o computador host do WSUS e a Internet?
- Se existir 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 tiver sido iniciada, mas permanecer em 0%, é porque o serviço WSUS (Update Services no WSUS 3.x; Serviço WSUS no Windows Server 2012 e versões posteriores) está em um estado parado.
Redefina o cache MMC do console do WSUS concluindo as seguintes etapas:
- Feche o console do WSUS.
- Interromper o serviço WSUS (Update Services no WSUS 3.x; Serviço WSUS no Windows Server 2012 e versões posteriores).
- Navegue até
%appdata%\Microsoft\mmc
. - Renomeie wsus para wsus_bak.
- Inicie o serviço WSUS.
- Abra o console do WSUS e tente outra sincronização manual.
Solucionar problemas de uma sincronização agendada na etapa 2
- Tente uma sincronização manual no console do 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 todos os metadados assinados
Depois que o WSUS receber informações de produto e classificação e quaisquer metadados assinados do Microsoft Update, a sincronização do WSUS será concluída.
Problemas de instalação, substituição ou detecção com atualizações específicas
Os problemas de implantação que ocorrem com atualizações específicas podem ser divididos nas áreas abaixo. Ao iniciar a solução de problemas, considere os seguintes componentes associados a essas áreas.
Áreas | Instalação | Substituição | Detecção |
---|---|---|---|
Componentes |
|
Atualizar metadados |
|
Problemas de instalação
Qual é o instalador (CBS, MSI, outro)?
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 do 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 do CBS está além do escopo deste guia. Para obter mais informações, consulte Corrigir erros de corrupção do Windows usando a ferramenta DISM ou Preparação para Atualização do Sistema. - A atualização é instalada com êxito como um usuário conectado? Em caso afirmativo, ele falha apenas quando é 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 Installer)
Para atualizações de software que não sejam do Windows, o MSI é usado para lidar com a instalação.
Reúna e examine os logs MSI padrão para a atualização. Verifique o artigo da base de dados de conhecimento associado para obter a atualização para ver se há problemas conhecidos ou perguntas frequentes.
Habilite o log do Windows Installer e reproduza a falha.
Ao revisar os logs resultantes, verifique o valor de retorno 3 no log e nas linhas anteriores a essa entrada para obter informações sobre a falha.
Verifique se a mesma atualização não é instalada 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 é um problema com a instalação no sistema local. Se funcionar, você poderá concentrar o problema em como instalar corretamente a atualização usando o contexto do sistema local. Pode ser necessário verificar as diretrizes de implantação administrativa dentro da KB para a atualização ou online.
Problemas de substituição
Tente isolar o problema relacionado à substituição usando as seguintes perguntas:
- Para perguntas sobre como controlar quando o Configuration Manager expira uma atualização, consulte Regras de substituição.
- Se uma atualização tiver expirado pelo Configuration Manager, a Microsoft recomenda que a atualização de substituiçã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 substituição de uma atualização, primeiro examine o artigo da base de dados de conhecimento da atualização para obter mais informações. Você também pode examinar a substituição no Catálogo do Microsoft Update, 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
- Examine o artigo da base de dados de atualização para ver se há problemas conhecidos com a atualização.
- Execute a ação Ciclo de Verificação de Atualizações de Software no cliente Configuration Manager.
- Revise UpdatesStore.log e WindowsUpdate.log.
Solucionar problemas de aplicabilidade de atualização
- Verifique se algum pré-requisito está ausente usando o artigo da base de dados para a atualização. Por exemplo, a atualização exige que o aplicativo ou sistema operacional seja corrigido para um nível específico de service pack?
- Confirme se a ID de Atualização Exclusiva da atualização em questão corresponde ao que está 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:
- Planejar atualizações de software no Configuration Manager
- Como configurar um ponto de atualização de software para usar o cluster NLB (Balanceamento de Carga de Rede)
- Como habilitar a verificação de CRL para atualizações de software
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 as últimas notícias, informações e dicas técnicas sobre o Configuration Manager.