O Windows Update não funciona no Windows 2012 R2 Standard

14

Eu herdei recentemente o gerenciamento de um servidor Windows 2012 em um site remoto.

Eu verifiquei o Windows Update e ele não está atualizando desde março. Quando eu digo ao Windows para verificar se há atualizações, ele age como se estivesse verificando, mas parece dizer que por horas. Se eu tentar reiniciar o serviço de atualização do Windows, parece que nunca será capaz de desligar. Meu único remédio parece estar sendo reinicializado para voltar ao ponto em que posso dizer ao Windows Update para verificar se há novas atualizações.

A última verificação bem-sucedida de atualizações diz 20 de março.

A última vez que as atualizações foram instaladas diz 17 de março (falha).

O histórico de atualizações mostra que uma atualização falhou em 17 de março, uma atualização do driver da impressora, mas o histórico mostra 13 atualizações com falha para o dia 17 de fevereiro.

Não tenho certeza do que mais tentar.

    
por Scot 31.08.2014 / 18:30

7 respostas

17

Duas das minhas três máquinas 2012R2 exibiram esse comportamento em abril passado. Eles iriam pendurar na verificação de atualizações ... para sempre.

Eu nunca soube exatamente o que causou o problema, mas resolvi o problema fazendo o seguinte:

  1. Pare o serviço do Windows Update.

    net stop wuauserv
    
  2. Exclua o diretório de cache do Windows Update C:\Windows\SoftwareDistribution .

    Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution
    
  3. Reinicie o computador. (Em uma máquina, é necessário várias reinicializações para obter tudo excluído desse diretório, portanto, continue tentando, se necessário.)

  4. Execute o Windows Update manualmente novamente. Ele falhará quase instantaneamente e oferecerá a execução de uma ferramenta de diagnóstico. Faça o download da ferramenta e permita que ela seja executada.

  5. A ferramenta encontrará e corrigirá alguns problemas. Neste ponto, execute o Windows Update manualmente novamente. O Windows Update funcionou bem neste momento.

por 03.09.2014 / 23:13
7

Encontrei esta excelente resposta aqui e funcionou muito bem para mim. Só quero compartilhar caso alguém esteja pesquisando:

Try this at an elevated command-prompt:

netsh winhttp import proxy source=ie

and reboot

outra solução que funcionou para mim também foi definir o modo de atualização para "Nunca verificar se há atualizações"

    
por 05.03.2015 / 19:53
0

Eu usei a System Update Readiness Tool e o DISM. Isso funcionou para mim. Você pode obtê-lo aqui: link

    
por 19.12.2014 / 01:17
0

Eu estava brincando com uma VM de 2012 e tive esse problema. Minha solução (rápida, insegura, etc) foi desabilitar a segurança do IE Enhanced no servidor e ela começou a conversar com o MS Windows Update. Não é uma solução para um servidor real, mas é um servidor de desenvolvimento de brinquedos e estou bem com isso.

Presumivelmente, o site de atualização do Windows precisa ser adicionado a alguns sites confiáveis em algum lugar para uma solução real?

    
por 03.04.2016 / 04:45
0

Minha correção em um recém-instalado no Windows Server 2012 R2 no Citrix 6.5 VM, e como Marcus Greasly postou, desative o IE Enchanced Security ... funcionou imediatamente ...

To disable IE enhanced security in windows server 2012 R2, launch the Server Manager, on the left hand side click on Local Server. On the right hand side click on the On link next to IE Enhanced Security Configuration. You will now see the Internet Explorer Enhanced Security Configuration box.

link

    
por 19.04.2017 / 16:46
0

Recentemente, tenho os mesmos problemas no meu Servidor 2012 e tudo o que fiz foi desativar o Serviço Malwarebytes e as atualizações baixadas imediatamente. Tente desativar qualquer malware ou software antivírus que você tenha, pois isso pode ser a raiz causada.

    
por 16.05.2017 / 19:51
0

Visão geral

Tivemos esse problema em alguns servidores virtuais migrados de um provedor "em nuvem" de volta para nosso data center interno. A causa raiz foi permissões para a pasta %SystemRoot%\System32\catroot2 . Havia várias diferenças entre as permissões nessa pasta em um servidor íntegro e as do servidor migrado. Eu acredito que a chave foi que TrustedInstaller não tinha full access .

Sintomas adicionais

Olhando para o log do aplicativo no visualizador de eventos, vimos vários erros:

Source: CAPI2
EventId: 257
Text: The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.

Source: ESENT
EventId: 490
Text: Catalog Database (416) Catalog Database: An attempt to open the file "C:\Windows\system32\CatRoot2\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\catdb" for read / write access failed with system error 5 (0x00000005): "Access is denied. ".  The open file operation will fail with error -1032 (0xfffffbf8).

A pista está no texto do erro ESENT; ou seja, emissão de permissões acessando um arquivo sob a pasta catroot2.

Resolução

Conceda à conta do Instalador Confiável um controle total para a pasta catroot2 e seus filhos.

Caso isso não seja suficiente, para comparação, a execução de icacls %systemroot%\system32\catroot2 em um servidor saudável fornece isso:

C:\Windows\system32\catroot2 NT SERVICE\CryptSvc:(F)
                         NT SERVICE\CryptSvc:(OI)(CI)(IO)(F)
                         NT SERVICE\TrustedInstaller:(I)(F)
                         NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                         NT AUTHORITY\SYSTEM:(I)(F)
                         NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Administrators:(I)(F)
                         BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Users:(I)(RX)
                         BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                         CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)

NB: Para adicionar o Trusted Installer, você precisará procurar nas contas do computador local nt service\trustedinstaller .

Após substituir as permissões em catroot2 , certifique-se de clicar na caixa de seleção replace permissions on child objects & containers para garantir que os itens filhos também tenham suas permissões resolvidas.

Nenhuma reinicialização é necessária para a correção em si (embora, obviamente, quando as atualizações começarem a funcionar novamente, é provável que você precise reinicializá-las).

    
por 31.05.2017 / 19:40