Eu tenho trabalhado no WSUS e no Windows 10 nos últimos dias, seguindo algumas atualizações bastante irritantes para os dispositivos Surface Pro recentemente implantados e, mais importante, um comentário revoltante de um colega de trabalho “não podemos automatizar isso mais?”.

Bem, eu tenho que dizer que foi a última gota. O Windows 10 e o WSUS têm sido uma dor para mim desde que foi lançado.

Com hotfixes, ajustes e danças exigidos e falhando em conseguir o Windows 10 falar e trabalhar com o WSUS de forma consistente, talvez não fosse surpresa que eu tivesse optado por apontar 10 diretamente para a atualização do Windows e apenas controlar o cronograma e tocar , em vez da abordagem granular mais tradicional Tomadas com o Windows 7 e 8.

Então, sim, a resposta é que devemos ser capazes de gerenciar o patch com o Windows 10.

Sim, vamos gerenciá-lo.

O cliente que acabamos de implementar os Superfícies, já tinha o WSUS rodando em torno de 150 desktops e laptops do Windows 7. Além disso, eles agora têm cerca de 30 dispositivos do Windows 10.

Eu também tenho um servidor WSUS que eu aponto servidores de clientes para os quais eu decidi apontar algumas máquinas de laboratório do Windows 10 em.

Nenhum dos quais estava trabalhando para suportar o Windows 10.

Agora, como um lado, o servidor WSUS dos clientes estava quebrado.

Eu não sabia disso até que eu comecei a trabalhar nesta questão, mas o que aconteceu foi … uma série de eventos complicados com os quais não vou aborrecer.

Basta dizer que foi recentemente reinstalado. Regras e grupos configurados para gerenciar as atualizações e deixados para permitir que os clientes preencham e corrigem.

Ao fazer o login para começar a trabalhar no Windows 10, notei que muitos clientes não haviam relatado status.Então pensei que deveria consertar isso antes de continuar.

Os clientes que não informam são novamente outra questão que aflige os administradores do WSUS em todo o mundo com várias correções e ajustes.

Nesse caso, o WSUS claramente não havia sido instalado corretamente porque faltava uma pasta do servidor.

Esta pasta contém um arquivo CAB que qualquer cliente baixa ao se registrar no servidor.

A correção para isso foi fácil e exigiu criar e preencher essa pasta.

CAB Missing

A pasta em questão pode ser encontrada aqui, C: \ Arquivos de Programas \ Update Services \ SelfUpdate \ WSUS3 aqui dentro são 3 pastas uma para cada arquitetura. Certifique-se de que dentro de x86 e x64 você tenha uma pasta Win7SP1 .

Win7

Se você achar que está faltando, você pode pegá-lo da pasta WinSXS , procure uma pasta chamada amd64_updateservices-selfupdate-x64-win7sp1 {guid} aqui estão os arquivos CAB que você precisará.

WinSXS

WinSXS2

Basta substituir essa pasta foi suficiente para que os clientes restantes do Windows 7 falassem com o WSUS, no entanto … devido ao número de atualizações que cada cliente precisa processar e um máximo do valor que podem processar por detecção, você pode encontrar um problema no log , AVISO: SyncServerUpdatesInternal falhou: 0x80244010 , a coisa chave a fazer aqui é aumentar sua freqüência de detecção nos clientes uma vez por hora.

A razão para isso é, não é uma falha permanente, o erro significa que atingiu o número máximo de atualizações que pode processar desta vez. No próximo intervalo de pesquisa, ele continuará.

Pode, em seguida, erro 3 ou 4 vezes mais ou tantas vezes quanto demora até que tenha processado toda a lista de atualizações.

Você quer que este processo seja concluído o mais rápido possível, então, diminuindo a frequência de, digamos, 22 horas, para 1, significa que pode completar em 4 horas, em vez de 4 dias. Isso é bem explicado em uma postagem do blog de volta em 2008!

Se o seu WSUS já estiver em funcionamento, suas máquinas do Windows 10 devem estar registrando, mas provavelmente não mostrarão status para todas as atualizações. Isso novamente está relacionado ao tempo de processamento, mas, simplesmente, reduzir a freqüência não é suficiente devido às diferenças em como o Windows Update Client agora funciona.

Windows 10 No Updates

A primeira coisa que precisamos fazer é certificar-se de que seu servidor está corrigido para suportar o Windows 10.

Você precisará KB3095113 e KB3159706 .

O KB3159706 inclui etapas manuais para completar, que são:

  • Execute o serviço pós-instalação no WSUS,
  • Adicionar ativação HTTP para .NET4
  • Verifique a configuração do arquivo Web.Config para o Serviço Web do Cliente.

Instale ambos os patches e reinicie seu servidor. Abra um CMD elevado e entre:

"C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall /servicing

Em seguida, abra uma janela elevada do PowerShell e entre:

Add-WindowsFeature –Name NET-WCF-HTTP-Activation45

Agora, abra o arquivo Web.Config de C: \ Arquivos de Programas \ Serviços de Atualização \ WebServices \ ClientWebService (você pode precisar se apropriar)

takeown /f web.config /a icacls "C:\Program Files\Update Services\WebServices\ClientWebService\Web.config" /grant administrators:f

Você pode achar que essas mudanças já estão presentes, se não inserir as destacadas e salvar o arquivo.

Código1

Código2

Isso completa a instalação do KB3159706.

Precisamos fazer alguns ajustes no IIS, o que podemos fazer com o PowerShell.

O seguinte será atualizado, o uso da memória do Wsus App Pool (WsusPool) e as configurações da CPU, as configurações do ClientWebService httpRuntime e adicionará um novo tipo MIME. Você pode colá-lo em uma janela elevada do PowerShell ou salvá-lo como um arquivo ps1.

Import-Module WebAdministration
Write-Output "Configure WSUS AppPool CPU & Memory Settings"
$path = "iis:\AppPools\WsusPool"
$cpuSpan = New-TimeSpan -Minutes 15
$pmSpan = New-TimeSpan -Minutes 5
$fSpan = New-TimeSpan -Minutes 15
$cpu = Get-ItemProperty $path CPU
$processModel = Get-ItemProperty $path ProcessModel
$cpu.resetInterval = $cpuSpan
Set-ItemProperty $path CPU $cpu
$processModel.StartupTimeLimit = $pmSpan
Set-ItemProperty $path ProcessModel $processModel
$failure = Get-ItemProperty $path Failure
$failure.loadBalancerCapabilities = "TCPLevel"
$failure.rapidFailProtectionInterval = $fSpan
Set-ItemProperty $path Failure $failure
$rMemory = get-itemproperty $path recycling
$rMemory.periodicrestart.privateMemory = 18342456
Set-ItemProperty $path recycling $rMemory
Write-Output "AppPool Configuration Completed"
Write-Output "Configure ClientWebService Settings"
$eSpan = New-TimeSpan -Hours 2
set-webconfigurationproperty system.web/httpRunTime "iis:\sites\WSUS Administration\ClientWebService" -name maxRequestLength -Value 204800
set-webconfigurationproperty system.web/httpRunTime "iis:\sites\WSUS Administration\ClientWebService" -name executionTimeout -Value $eSpan
Write-Output "ClientWebService Settings Configured"
Write-Output "Add MIME Type"
$mimeName = "application/octet-stream"
$mimeExt = ".esd"
Add-WebConfigurationProperty //staticContent -Name Collection -Value @{fileExtension=$mimeExt; mimeType=$mimeName}
Write-Output"MIME Type Added"

Isso deve ser suficiente para que suas máquinas do Windows 10 conversem com o WSUS, no entanto, existem algumas circunstâncias em que isso não será.

Se você já atualizou atualizações para o WSUS para o Windows 10, antes do Hotfix 3095113 estar sendo liberado, isso pode ser aplicável a você.

A questão é descrita aqui em uma postagem no blog que se concentra no Windows 10 1511, além disso, outro artigo da KB que é para 1607 descreve um problema em que você teve atualizações sincronizadas antes do KB3159706 estar instalado.

Nós precisamos purgar essas atualizações do banco de dados WSUS, o que exige que elas sejam recusadas a excluí-las e removê-las do banco de dados usando Comandos SQL, uma vez que os hotfixes foram instalados, podemos então baixar as atualizações novamente.

Se você não estiver se esta etapa se aplica, você deve garantir que você tenha um backup completo e testado do servidor e depois execute o procedimento. Não demora uma grande quantidade de tempo e você pode ter certeza de que você está em uma boa posição conhecida.

Para executar os comandos SQL, você pode carregar o SQL Management , conectar-se ao WID digitando o seguinte:

ServerName : \\.\pipe\MICROSOFT##WID\tsql\query

SQL WID

No SQL Management Studio você pode expandir o SUSDB e iniciar uma nova consulta.

SQL WID2

SQL WID 3

Cole seus comandos e clique em Executar.

sql

Então você configurou o seu WSUS, suas máquinas do Windows 10 aparecem e informam o status.

Você aprovou algumas atualizações e … nada acontece.

Controles do lado do cliente

No lado do cliente, claro, o Windows 10 mudou a forma como o WindowsUpdate.log é gerado, requer o uso de um cmdlet PowerShell ( Get-WindowsUpdateLog ) para ser executado, que agrupa todos os eventos do Windows Update e gera um registro de sua área de trabalho .

Além disso, você encontrará um arquivo em c: \ windows \ SoftwareDistribution chamado ReportingEvents.log,que mostra um esboço básico do que o cliente do Windows Update está fazendo.

Parece que, mesmo que você tenha configurado a Freqüência de Detecção por hora, o computador cliente não informará seu status por hora.

Na verdade, pode não ser até depois de uma reinicialização do cliente antes que ele relate seu status. Existem comandos que você pode executar para tentar manipular o Windows Update Client, no entanto, não vi nenhum comando que tenha feito magicamente um status de atualização do dispositivo cliente para o WSUS antes que ele estivesse pronto. Isso inclui / resetauthorization e / detectnow switches para a ferramenta WUAUCLT.exe . Além disso, se um cliente tiver atualizações pendentes já pendentes de falar diretamente com o Windows Update, ele precisará finalizar as anteriores antes mesmo de se registrar no WSUS.

Adiar atualizações

Na minha superfície, eu tinha configurado manualmente para adiar atualizações. Como parte da escrita desta publicação, eu configurei a minha Superfície para conversar com o WSUS através da Política de Grupo Local, não alterei a configuração de Atualizar Diferenças no GPO, então minha escolha na GUI ainda era aplicada.

Mesmo que minha superfície esteja executando o 1607 e eu esperava que o WSUS mostra 1703 era necessário, porque eu tinha definido as atualizações de atualização, não estava aparecendo como uma atualização necessária no WSUS.

Levou-me a remover a configuração Defer Upgrades, antes do WSUS mostrar 1703 conforme necessário, independentemente de ter sido aprovado ou não.

Aqui estão dois clientes do Windows 10 no meu servidor WSUS do laboratório.

Windows 10 – 1703 Upgrade Approved

Updates

Este cliente mostra que 1703 falhou, mas ao clicar no status mostra a atualização foi baixada. Ao entrar manualmente no Windows Update no cliente, as atualizações mostram como disponíveis para instalar.

Updates2

Todas as atualizações foram instaladas com sucesso, exceto a Atualização 1703 que falhou com o erro 0x800FFFFF.

error

Parece que o mesmo problema descrito no KB3159706, também foi aplicado ao 1703 no meu servidor. Então, ajustei os passos nesse artigo e os execute novamente.

$s = Get-WsusServer
$1703Updates = $s.SearchUpdates(“version 1703”)
$1703Updates | foreach { $_.Decline() }
$1703Updates | foreach { $s.DeleteUpdate($_.Id.UpdateId) }

Em seguida, no SQL Management,

declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);
insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like '%15063%.esd' except select FileDigest from tbFileForRevision);
delete from tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles);
delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)

Em seguida, volte no PowerShell.

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification

$sub = $s.GetSubscription() $sub.StartSynchronization()

Eu tive que reaprovar o 1703 Upgrade, antes que o cliente o detectasse como uma atualização disponível, mas depois baixou com sucesso e instalou.

1703 -downloading

1703-installing

1703-installing2

creators

Na minha máquina de laboratório, que é uma VM de baixo desempenho, levou quase duas horas para completar a atualização.

Demorou mais 15 minutos antes de atualizar seu status para WSUS, que então apresentou 100% de instalação.

wsus-100

Depois de iniciar sessão no cliente e verificar o Windows Update, foi-me mostrado esta mensagem indicando que o meu dispositivo estava em risco.

risk

Verifiquei as atualizações da Microsoft e começou a baixar várias atualizações que ainda não estavam disponíveis no meu servidor WSUS.

1703-MU

Eu consegui usar o Catálogo WU para importá-los para o WSUS.

WU-Import

Espero seguir a purga das atualizações para 1703 que foram removidas e que elas teriam sido baixadas automaticamente para o WSUS novamente na próxima sincronização.

Nota: Aferir atualizações parece ter sido removido da GUI Em 1703, substituído por “Atualizações de pausa”.

Pausa

Windows 10 – 1703 Não aprovado

1703

Este cliente relata ao WSUS, conforme necessário, apenas o 1703 Upgrade, que não está aprovado.

Surface

O cliente não mostra atualizações disponíveis ao verificar manualmente.

Se você ainda tiver problemas nos clientes, talvez seja necessário redefinir os componentes do Windows Update Client, e a maneira mais fácil de fazer isso é usar o Windows Update Troubleshooter, que você pode baixar a partir daqui .

Anúncios