Share via

Solucionar problemas de gerenciamento de atualizações de software no Configuration Manager

  • Artigo

Este artigo ajuda você a solucionar problemas do processo de gerenciamento de atualização de software em Configuration Manager. Ele inclui problemas de verificação de atualização de software cliente, problemas de sincronização e 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 de KB original: 4505440

Escopo de seu problema

Este guia pressupõe 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 Preparar para o gerenciamento de atualizações de software.

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 a você por alguém em sua organização, tire um momento e responda às seguintes perguntas:

  1. O que especificamente não está funcionando e/ou qual é o seu objetivo?
  2. Qual é a frequência ou padrão para o problema? O problema ainda está acontecendo?
  3. Como você ficou ciente de que o problema existe?
  4. Já funcionou? Se sim, quando parou? Alguma coisa foi alterada no ambiente antes de parar de funcionar?
  5. Qual percentual de clientes são afetados?
  6. O que já foi feito (se alguma coisa) para tentar corrigi-lo?
  7. Conheça a versão exata do cliente e a versão do servidor. Esses sistemas estão atualizados?
  8. O que os clientes afetados têm em comum? Por exemplo, a mesma sub-rede, site do AD, domínio, localização física, 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 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 deseja solucionar problemas, selecione-a abaixo. Comece com a verificação de atualização de software do cliente se não tiver certeza e percorreremos todo o processo do início ao fim.

Verificação de atualização de software do 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 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.

  1. Quando o cliente 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 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

  2. O Agente de Verificação agora envia uma solicitação de localização do WSUS aos Serviços de Localização, conforme observado 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 na WMI na CCM_ScanJobInstance classe:

    Namespace: root\CCM\ScanAgent Classe: CCM_ScanJobInstance

  3. O Location Services cria uma solicitação de local e envia-a para o ponto de gerenciamento. A ID do pacote para uma solicitação de localização 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}

  4. 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

  5. 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

    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'

  6. 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>

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

  8. 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}

  9. 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

  10. 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 Política de Grupo se o cliente estiver no domínio para ver se Política de Grupo substitui o servidor de atualização adicionado. As seguintes entradas são registradas no 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 agente de Windows Update 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 marcadas e definidas:

    Subchave do Registro Nome do valor Tipo Data
    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 no WUAHandler.log para denotar quando a versão do conteúdo tiver incrementado:

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

  11. Depois que a fonte de atualização é adicionada com êxito, o Agente de Verificação gera uma mensagem de estado e inicia 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

Issues 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 no WUAHandler.log Verifique a configuração Habilitar atualizações de software na configuração de clientes .
O Agente de Verificação ou os Serviços de Localização não recebem o local do servidor WSUS

  • Uma função SUP (ponto de atualização de software) está instalada para o site?

    Caso contrário, 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 de erros.

    • select * from WSUSServerLocations
    • select * from Update_SyncStatus
O cliente recebe o local do WSUS, mas não configura as chaves do registro do WSUS

Política de Grupo atualização respondeu dentro do tempo limite de 2 minutos por WUAHandler.log? Nesse caso, 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 de configuração corretas do WSUS.

Para obter mais informações sobre a solução de problemas de falhas de verificação de atualização de software, confira Solucionar problemas de 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 Windows Update para solicitar uma verificação de atualização de software do Agente Windows Update. Uma verificação pode resultar de:

  • Uma verificação de atualização de software agendada ou manual
  • Uma reavaliação de implantação atualizada de software agendado ou manual
  • 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 substituídas somente quando forem substituídas por pacotes de serviço 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

Examine WUAHandler.log após uma verificação de atualização de software para ver se ocorrem novas entradas. Se não ocorrerem novas entradas, 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 ou chaves de registro ausentes ou corrompidos.
  • Problemas de registro de componente.

Para corrigir esses problemas, confira Verificar falhas 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 reporte status de conformidade incorreta e as atualizações não são instaladas quando Configuration Manager solicita o ciclo de atualização. No entanto, se você usar o applet do painel de controle Windows Update, as atualizações geralmente instalarão bem. Quando você está enfrentando esse problema, recebe uma mensagem semelhante à seguinte em WindowsUpdate.log:

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

É um problema de alocação de memória, os computadores Windows 7 de 64 bits não verão esse erro, pois o espaço de endereço deles é efetivamente ilimitado. No entanto, eles exibirão alta memória e alto uso de 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 Windows Update Cliente para Windows 7: junho de 2015.

Ao solucionar problemas de falhas de verificação, marcar os arquivos WUAHandler.log e WindowsUpdate.log. WUAHandler simplesmente relata o que Windows Update Agent relatou. Portanto, o erro em WUAHandler seria o mesmo erro relatado pelo próprio Agente Windows Update. Mais informações sobre o erro podem ser encontradas em WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Windows Update 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 Update erros comuns e mitigação.

Etapa 3: Windows Update Agent (WUA) inicia a verificação no computador WSUS

Windows Update Agent inicia uma verificação após receber uma solicitação do cliente Configuration Manager (CcmExec). Se esses valores de registro forem definidos corretamente como 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 agente de Windows Update 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:

  • Problemas relacionados ao proxy

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

    Para obter mais informações sobre servidores proxy, confira os seguintes artigos:

  • Erros de tempo limite HTTP

    Para solucionar problemas de erros de tempo limite HTTP, primeiro examine os logs dos 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 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.

      As razões comuns pelas quais a atribuição do WSUS pode estar incorreta incluem:

      • Política de Grupo conflitos
      • 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 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 localize o ponto de atualização de software.

      Se uma configuração do Active Directory Política de Grupo for aplicada a computadores para instalação do cliente do ponto de atualização de software, ela substituirá a configuração de Política de Grupo local. Se o valor da configuração definida no Active Directory Política de Grupo for diferente do definido por Configuration Manager, a verificação falhará no cliente porque ele 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 instalação do cliente e atualizações de software deve ser o mesmo servidor. E ela deve ser especificada na configuração Política de Grupo do Active Directory com o formato de nome e as informações de porta corretas. Por exemplo, seria <http://server1.contoso.com:80> se o 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 marcar 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 marcar se o cliente pode acessar o SimpleAuthWebService, tente acessar uma URL semelhante a esta:

      <http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx>

      Se alguma dessas URLs falhar, alguns dos possíveis motivos incluem:

      • Problemas de resolução de nomes no cliente. Verifique se você pode resolve 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 da 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 da porta são configuradas quando a função do sistema do 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 não 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 da porta WSUS usadas nas versões IIS 7.0 e posteriores.

        2. Determine as configurações da porta WSUS no IIS 6.0.

        3. Configurar portas para o ponto de atualização de software.

        4. Verificar conectividade de porta

          Para marcar 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 que se assemelha ao seguinte:

          Não foi possível abrir 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, experimente 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 dos 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 Associações.
        3. Na caixa de diálogo Associações do Site , os valores da porta HTTP e HTTPS são exibidos na coluna Porta .
        4. No servidor WSUS, abra o Gerenciador de Serviços de Informações da Internet (IIS).
        5. Expanda Sites da Web, clique com o botão direito do mouse no site do computador WSUS e clique em Propriedades.
        6. Clique na guia Site da Web . A configuração da porta HTTP é exibida na porta TCP e a configuração da porta HTTPS é exibida na porta SSL.
        7. No console Configuration Manager, acesse Servidores deConfiguração> de Site de Administração>e Funções do Sistema de Site e clique no <painel direito SiteSystemName>.
        8. No painel inferior, clique com o botão direito do mouse no Ponto de Atualização de Software e clique em Propriedades.
        9. Acesse a guia Geral , especifique ou verifique os números da porta de configuração do WSUS.

  • Erros de autenticação

    Normalmente, ele é 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 em 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 será com um firewall ou proxy intermediário.

  • Problemas de certificado

    Os problemas de certificado são indicados pelo código de erro 0x80072F0C isso significa que "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 de Windows Update Agent e marca a verificação como concluída

Os seguintes sã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, marcar os arquivos WUAHandler.log e WindowsUpdate.log. WUAHandler simplesmente relata o que Windows Update Agent relatou. Portanto, o erro em WUAHandler seria o mesmo erro que foi relatado pelo próprio Agente Windows Update. Mais informações sobre o erro podem ser encontradas no WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Windows Update arquivos de log.

Há muitos motivos pelos quais uma verificação de atualização de software pode falhar. Isso 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 Update erros comuns e mitigação.

Etapa 5: WUAHandler analisa os resultados da verificaçã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 podadas. O estado de aplicabilidade é verificado para todas as atualizações que se alinham aos critérios enviados pelo CCMExec ao Agente Windows Update. O importante a entender 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 no 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.

Conforme mencionado anteriormente neste guia, ao solucionar problemas de falhas de verificação, marcar os arquivos WUAHandler.log e WindowsUpdate.log. WUAHandler simplesmente relata o que Windows Update Agent relatou. Portanto, o erro em WUAHandler seria o mesmo erro que foi relatado pelo próprio Agente Windows Update. Mais informações sobre o erro podem ser encontradas no WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Windows Update arquivos de log.

De um modo geral, há muitos motivos pelos quais uma verificação de atualização de software pode falhar. Isso 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 Update erros comuns e mitigação.

Etapa 6: Atualizar o repositório 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. 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órios de mensagens status (que é minutos, por padrão). Enviamos 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 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 levantada:

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 gravada com a ID do 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 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.

Conforme mencionado anteriormente neste guia, ao solucionar problemas de falhas de verificação, marcar os arquivos WUAHandler.log e WindowsUpdate.log. WUAHandler simplesmente relata o que Windows Update Agent relatou. Portanto, o erro em WUAHandler seria o mesmo erro que foi relatado pelo próprio Agente Windows Update. Mais informações sobre o erro podem ser encontradas no WindowsUpdate.log. Para entender como ler WindowsUpdate.log, consulte Windows Update arquivos de log.

De um modo geral, há muitos motivos pelos quais uma verificação de atualização de software pode falhar. Isso 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 Update erros comuns e mitigação.

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

Quando WUAHandler recebe com êxito os resultados do Agente Windows Update, ele marca a verificação como completa e registra a seguinte mensagem no 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 falhas neste estágio provavelmente sejam exibidas no arquivo WindowsUpdate.log especificamente. Para entender como ler WindowsUpdate.log, consulte Windows Update arquivos de log.

De um modo geral, há muitos motivos pelos quais uma verificação de atualização de software pode falhar. Isso 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 Update erros comuns e mitigação.

Sincronização do WSUS com o Microsoft Update

A sincronização do WSUS com o Microsoft Update está 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 uma sincronização manual na etapa 1

  1. Confirme se o serviço WSUS está em execução. Se uma sincronização manual tiver começado, mas permanecer em 0%, será porque o serviço WSUS (Atualizar Serviços no WSUS 3.x; O WSUSService em versões Windows Server 2012 e posteriores) está em um estado interrompido.

  2. Redefina o cache MMC do console do WSUS seguindo estas etapas:

    1. Feche o console do WSUS.
    2. Parar o serviço WSUS (Atualizar serviços no WSUS 3.x; Serviço WSUS em versões Windows Server 2012 e 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 uma sincronização agendada na etapa 1

  1. Experimente uma sincronização manual do console do WSUS.
  2. Se uma sincronização manual funcionar bem, marcar 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 o computador host WSUS e a Internet?
  • Se um proxy existir 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 uma sincronização manual na etapa 2

  1. Confirme se o serviço WSUS está em execução. Se uma sincronização manual tiver começado, mas ela permanecer em 0%, será porque o serviço WSUS (Atualizar Serviços no WSUS 3.x; O Serviço WSUS em versões Windows Server 2012 e posteriores) está em um estado interrompido.

  2. Redefina o cache MMC do console do WSUS concluindo as seguintes etapas:

    1. Feche o console do WSUS.
    2. Parar o serviço WSUS (Atualizar serviços no WSUS 3.x; Serviço WSUS em versões Windows Server 2012 e 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 uma sincronização agendada na etapa 2

  1. Experimente uma sincronização manual do console do WSUS.
  2. Se uma sincronização manual funcionar bem, marcar 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 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. Quando você começar a solucionar problemas, considere os seguintes componentes associados a essas áreas.

Áreas Instalação Supersedência Detecção
Componentes
  • WUA
  • Instalador de atualização (CBS (manutenção baseada em componente), MSI)
  • CCMExec
 Atualizar metadados
  • WUA
  • Atualizar metadados
  • Instalador de Atualização (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, a CBS é usada para lidar com a instalação.

  1. Reúna o log da 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 da 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ções do Sistema.
  2. A atualização é instalada com êxito como um usuário conectado? Em caso afirmativo, ele só falha quando é instalado no contexto do Sistema? Nesse caso, concentre-se em solucionar problemas da falha de instalação manual no contexto do sistema.

MSI (Instalador do Windows)

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

  1. Reúna e examine os logs msi padrão para a atualização. Verifique o artigo KB associado para obter a atualização de quaisquer problemas conhecidos ou perguntas frequentes.

  2. Habilite o registro em log do Windows Installer e reproduza a falha.

    Ao revisar os logs resultantes, marcar para o valor de retorno 3 no log e as linhas que precedem essa entrada para obter informações sobre a falha.

  3. Verifique se a mesma atualização falha ao instalar manualmente no contexto do sistema local. Para fazer isso, use os mesmos comutadores 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 os mesmos comutadores de instalação. Verifique se é um problema com a instalação no sistema local. Se funcionar, você poderá focar o problema em como instalar corretamente a atualização usando o contexto do sistema local. Pode exigir a verificação de 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:

  1. Para obter perguntas sobre como controlar quando Configuration Manager expirar uma atualização, consulte Regras de supersedência.
  2. Se uma atualização tiver expirado por 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 de distribuição de software ou gerenciamento de aplicativos.
  3. Para perguntas relacionadas especificamente à lógica de supersedência de uma atualização, primeiro examine o artigo KB para obter mais informações. Você também pode examinar a supersedência no Catálogo de Atualizações da Microsoft, no console do WSUS ou no console Configuration Manager.

Problemas de detecção

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

  1. Examine o artigo de atualização do KB para obter problemas conhecidos com a atualização.
  2. Execute a ação Ciclo de Verificação Atualizações software no cliente Configuration Manager.
  3. Examine UpdatesStore.log e WindowsUpdate.log.

Solucionar problemas de aplicabilidade de atualização

  1. Verifique se há pré-requisitos ausentes usando o artigo KB para a atualização. Por exemplo, a atualização requer que o aplicativo ou o sistema operacional sejam corrigidos em um nível específico do service pack?
  2. Confirme se a ID de Atualização Exclusiva da atualização em questão corresponde ao que foi 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, confira os seguintes artigos:

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

Visite nosso blog para obter todas as últimas notícias, informações e dicas de tecnologia sobre Configuration Manager.