O guia completo da manutenção sup do WSUS e do Configuration Manager

  • Artigo
  • 26 minutos para ler

Este artigo aborda algumas perguntas comuns sobre a manutenção do WSUS para ambientes do Configuration Manager.

Versão original do produto:   Windows Servidores, Windows Server Update Services, Configuration Manager
Número KB original:   4490644

Introdução

As perguntas geralmente estão nas linhas de Como executar corretamente essa manutenção em um ambiente do Configuration Manager ou Com que frequência devo executar essa manutenção. Não é incomum que os administradores conscientes do Configuration Manager não sabem que a manutenção do WSUS deve ser executado. A maioria de nós acabou de configurar servidores WSUS porque é um pré-requisito para um ponto de atualização de software (SUP). Depois que o SUP for definido, fecharemos o console do WSUS e fingiremos que ele não existe. Infelizmente, pode ser problemático para clientes do Configuration Manager e o desempenho geral do servidor WSUS/SUP.

Com o entendimento de que essa manutenção precisa ser feita, você está se perguntando que manutenção você precisa fazer e com que frequência você precisa fazer isso. A resposta é que você deve executar a manutenção mensal. A manutenção é fácil e não demora muito para servidores WSUS que foram bem mantidos desde o início. No entanto, se já passou algum tempo desde que a manutenção do WSUS foi feita, a limpeza pode ser mais difícil ou demorada na primeira vez. Será muito mais fácil ou mais rápido nos meses subsequentes.

Manter o WSUS enquanto suporta o Gerenciador de Configurações atual versão 1906 e versões posteriores

Se você estiver usando o Configuration Manager versão atual da filial 1906 ou versões posteriores, recomendamos que você habilita as opções de Manutenção do WSUS na configuração do ponto de atualização de software no site de nível superior para automatizar os procedimentos de limpeza após cada sincronização. Ele trataria efetivamente todas as operações de limpeza descritas neste artigo, exceto backup e reindexação do banco de dados WSUS. Você ainda deve automatizar o backup do banco de dados WSUS juntamente com a reindexação do banco de dados WSUS em um cronograma.

Captura de tela das opções de Manutenção do WSUS na janela Propriedades de Componentes de Ponto de Atualização de Software.

Para obter mais informações sobre a manutenção de atualização de software no Configuration Manager, consulte Manutenção de atualizações de software.

Considerações importantes

Observação

Se você estiver utilizando os recursos de manutenção que foram adicionados ao Configuration Manager, versão 1906, não será necessário considerar esses itens, pois o Configuration Manager trata da limpeza após cada sincronização.

  1. Antes de iniciar o processo de manutenção, leia todas as informações e instruções neste artigo.

  2. Ao usar o WSUS juntamente com servidores downstream, os servidores WSUS são adicionados da parte superior para baixo, mas devem ser removidos da parte inferior para cima. Ao sincronizar ou adicionar atualizações, eles vão primeiro para o servidor WSUS upstream e replicam para baixo para os servidores downstream. Ao executar uma limpeza e remover itens de servidores WSUS, você deve começar na parte inferior da hierarquia.

  3. A manutenção do WSUS pode ser executada simultaneamente em vários servidores na mesma camada. Ao fazer isso, certifique-se de que uma camada seja feita antes de mover para a próxima. As etapas de limpeza e reindexação descritas abaixo devem ser executados em todos os servidores WSUS, independentemente de serem um servidor WSUS réplica ou não. Para obter mais informações sobre como determinar se um servidor WSUS é uma réplica, consulte Decline superseded updates.

  4. Certifique-se de que os SUPs não sincronizam durante o processo de manutenção, pois isso pode causar uma perda de alguns trabalhos já feitos. Verifique o agendamento de sincronização sup e desarmá-lo temporariamente como manual durante esse processo.

    Captura de tela da configuração Habilitar sincronização em uma agenda.

  5. Se você tiver vários SUPs do site principal ou da administração central (CAS) que não compartilham o SUSDB, considere o servidor WSUS que sincroniza com o primeiro SUP no site como residindo em uma camada abaixo do site. Por exemplo, meu site CAS tem dois SUPs:

    • A chamada Nova sincronização com o Microsoft Update, seria minha camada superior (Tier1).
    • O servidor chamado 2012 sincroniza com New e seria considerado na segunda camada. Ele pode ser limpo ao mesmo tempo que eu faria todos os meus outros servidores Tier2, como o ÚNICO SUP do meu site principal.

    Captura de tela dos dois SUPs de exemplo.

Executar a manutenção do WSUS

As etapas básicas necessárias para a manutenção adequada do WSUS incluem:

  1. Fazer o back up do banco de dados WSUS
  2. Criar índices personalizados
  3. Reindexar o banco de dados WSUS
  4. Recusar atualizações superadas
  5. Executar o Assistente de Limpeza do Servidor WSUS

Fazer o back up do banco de dados WSUS

Fazer o back up do banco de dados WSUS (SUSDB) usando o método desejado. Para obter mais informações, consulte Create a Full Database Backup.

Criar índices personalizados

Esse processo é opcional, mas recomendado, melhora muito o desempenho durante as operações de limpeza subsequentes.

Se você estiver usando o Configuration Manager atual versão 1906 ou uma versão posterior, recomendamos que você use o Configuration Manager para criar os índices. Para criar os índices, configure a opção Adicionar índices não agrupados ao banco de dados WSUS na configuração do ponto de atualização de software para o site mais alto.

Captura de tela da opção Adicionar índices não agrupados à opção banco de dados WSUS na guia Manutenção do WSUS.

Se você usar uma versão mais antiga do Configuration Manager ou servidores WSUS autônomos, siga estas etapas para criar índices personalizados no banco de dados SUSDB. Para cada SUSDB, é um processo único.

  1. Certifique-se de que você tenha um backup do banco de dados SUSDB.

  2. Use SQL Management Studio para se conectar ao banco de dados SUSDB, da mesma forma descrita na seção Reindexar o banco de dados WSUS.

  3. Execute o seguinte script no SUSDB, para criar dois índices personalizados:

    -- Create custom index in tbLocalizedPropertyForRevision
USE [SUSDB]

CREATE NONCLUSTERED INDEX [nclLocalizedPropertyID] ON [dbo].[tbLocalizedPropertyForRevision]
(
     [LocalizedPropertyID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

-- Create custom index in tbRevisionSupersedesUpdate
CREATE NONCLUSTERED INDEX [nclSupercededUpdateID] ON [dbo].[tbRevisionSupersedesUpdate]
(
     [SupersededUpdateID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

    Se índices personalizados foram criados anteriormente, executar o script novamente resulta em um erro semelhante ao seguinte:

    Msg 1913, Nível 16, Estado 1, Linha 4
    A operação falhou porque um índice ou estatísticas com o nome 'nclLocalizedPropertyID' já existe na tabela 'dbo.tbLocalizedPropertyForRevision'.

Reindexar o banco de dados WSUS

Para reindexar o banco de dados WSUS (SUSDB), use o script Reindexar o script T-SQL banco de dados WSUS.

As etapas para se conectar ao SUSDB e executar o reindexa diferem, dependendo se o SUSDB está em execução no SQL Server ou Banco de Dados Interno do Windows (WID). Para determinar onde o SUSDB está sendo executado, SQLServerName verifique o valor da entrada do Registro no servidor WSUS localizado na HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup sub-chave.

Se o valor contiver apenas o nome do servidor ou servidor\instância, o SUSDB será executado em um SQL Server. Se o valor incluir a cadeia de caracteres ##SSEE ou ##WID nele, o SUSDB será executado no WID, conforme mostrado:

Captura de tela do SqlServerName-SSEE.

Captura de tela do SqlServerName-WID.

Se SUSDB foi instalado no WID

Se o SUSDB foi instalado no WID, SQL Server Management Studio Express deve ser instalado localmente para executar o script de reindexação. Aqui está uma maneira fácil de determinar qual versão do SQL Server Management Studio Express instalar:

  • Para Windows Server 2012 ou versões posteriores:

    • Vá até C:\Windows\WID\Log e encontre o log de erros que contém o número da versão.

    • Procure o número da versão em Como determinar o nível de versão, edição e atualização do SQL Server e seus componentes. Esse valor informa qual nível de Service Pack (SP) o WID está executando. Inclua o nível de SP ao pesquisar o Centro de Download da Microsoft para SQL Server Management Studio Express.

  • Para Windows Server 2008 R2 ou versões anteriores:

    • Vá para C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG e abra o último log de erros com Bloco de notas. Na parte superior, haverá um número de versão (por exemplo, 9.00.4035.00 x64). Procure o número da versão em Como determinar o nível de versão, edição e atualização do SQL Server e seus componentes. Este número de versão informa qual nível de Service Pack ele está executando. Inclua o nível de SP ao pesquisar o Centro de Download da Microsoft para SQL Server Management Studio Express.

Depois de instalar SQL Server Management Studio Express, inicia-o e insira o nome do servidor ao que se conectar:

  • Se o sistema operacional estiver Windows Server 2012 ou versões posteriores, use \\.\pipe\MICROSOFT##WID\tsql\query.
  • Se o sistema operacional for mais antigo que Windows Server 2012, digite \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query.

Para WID, se ocorrerem erros semelhantes ao seguinte ao tentar se conectar ao SUSDB usando SQL Server Management Studio (SSMS), tente iniciar SSMS usando a opção Executar como administrador.

Captura de tela do erro Não é possível se conectar ao servidor.

Se SUSDB foi instalado em SQL Server

Se o SUSDB foi instalado em uma SQL Server completa, SQL Server Management Studio e insira o nome do servidor (e a instância, se necessário) quando solicitado.

Dica

Como alternativa, um utilitário chamado sqlcmd pode ser usado para executar o script de reindexação. Para obter mais informações, consulte Reindexar o banco de dados WSUS.

Executando o script

Para executar o script no SQL Server Management Studio ou SQL Server Management Studio Express, selecione Nova Consulta, colar o script na janela e, em seguida, selecione Executar. Quando terminar, uma consulta executada com êxito será exibida na barra de status. E o painel Resultados conterá mensagens relacionadas a quais índices foram reconstruídos.

Captura de tela da execução da instrução SQL.

Captura de tela do log bem-sucedido.

Recusar atualizações superadas

Recusar atualizações superadas no servidor WSUS para ajudar os clientes a examinar com mais eficiência. Antes de rebaixar as atualizações, certifique-se de que as atualizações de supersedação sejam implantadas e que as supersedadas não sejam mais necessárias. O Configuration Manager inclui uma limpeza separada, que permite que ele expire atualizações supersedadas com base em critérios especificados. Para saber mais, confira os seguintes artigos:

A seguinte SQL consulta pode ser executado no banco de dados SUSDB, para determinar rapidamente o número de atualizações superadas. Se o número de atualizações superadas for superior a 1500, poderá causar vários problemas relacionados à atualização de software no servidor e no lado do cliente.

-- Find the number of superseded updates
Select COUNT(UpdateID) from vwMinimalUpdate where IsSuperseded=1 and Declined=0

Se você estiver usando o Configuration Manager versão atual do branch 1906 ou uma versão posterior, recomendamos recusar automaticamente as atualizações supersedadas habilitando as atualizações expiradas de Declínio no WSUS de acordo com a opção de regras de supersedência na configuração do ponto de atualização de software para o site mais top-most.

Captura de tela das atualizações expiradas de Declínio no WSUS de acordo com a opção de regras de supersedência na guia Manutenção do WSUS.

Ao usar essa opção, você pode ver quantas atualizações foram recusadas ao revisar o arquivo WsyncMgr.log após a finalização do processo de sincronização. Se você usar essa opção, não precisará usar o script descrito posteriormente nesta seção (executando-a manualmente ou configurando-a como tarefa para executar em um cronograma).

Se você estiver usando servidores WSUS autônomos ou uma versão mais antiga do Configuration Manager, poderá recusar manualmente as atualizações sobressaladas usando o console do WSUS. Ou você pode executar esse script do PowerShell. Em seguida, copie e salve o script como um arquivoDecline-SupersededUpdatesWithExclusionPeriod.ps1 script.

Observação

Este script é fornecido como está. Ele deve ser totalmente testado em um laboratório antes de usá-lo na produção. A Microsoft não garante o uso desse script de nenhuma maneira. Sempre execute o script com o -SkipDecline parâmetro primeiro, para obter um resumo de quantas atualizações supersedadas serão recusadas.

Se o Configuration Manager estiver definido como Expirar imediatamente atualizações superadas (consulte abaixo), o script do PowerShell poderá ser usado para recusar todas as atualizações supersedadas. Ele deve ser feito em todos os servidores WSUS autônomos na hierarquia do Configuration Manager/WSUS.

Captura de tela das opções de atualizações supersedadas expiradas imediatamente na guia Regras de Supersedência.

Você não precisa executar o script do PowerShell em servidores WSUS definidos como réplicas, como SUPs de site secundários. Para determinar se um servidor WSUS é uma réplica, verifique as configurações de Fonte de Atualização.

Captura de tela da opção Atualizar Origem e Servidor Proxy.

Se as atualizações não estão configuradas para expirar imediatamente no Configuration Manager, o script do PowerShell deve ser executado com um período de exclusão que corresponde à configuração do Configuration Manager por número de dias para expirar as atualizações supersedadas. Nesse caso, seriam 60 dias desde que as propriedades do componente SUP sejam configuradas para aguardar dois meses antes de expirar as atualizações supersedadas:

Captura de tela dos meses a expirar atualizações superadas.

As linhas de comando a seguir ilustram as várias maneiras pelas quais o script do PowerShell pode ser executado (se o script estiver sendo executado no servidor WSUS, LOCALHOST pode ser usado no lugar do real SERVERNAME):

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530 –SkipDecline

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530 –ExclusionPeriod 60

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -Port 8530

Decline-SupersededUpdatesWithExclusionPeriod.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8531

Executar o script com um e -SkipDecline -ExclusionPeriod 60 coletar informações sobre atualizações no servidor WSUS e quantas atualizações podem ser recusadas:

Captura de tela da janela Windows PowerShell executando SkipDecline e ExclusionPeriod 60.

Executando o script com -ExclusionPeriod 60, para recusar atualizações sobressaladas anteriores a 60 dias:

Captura de tela da janela Windows PowerShell com ExclusionPeriod 60 em execução.

Os indicadores de saída e progresso são exibidos enquanto o script está em execução. Observe o SupersededUpdates.csv , que conterá uma lista de todas as atualizações recusadas pelo script:

Captura de tela do indicador de Windows PowerShell de saída e progresso.

Observação

Se ocorrerem problemas ao tentar usar o script acima do PowerShell para recusar atualizações supersedadas, consulte a seção Executando o tempo de execução do script Decline-SupersededUpdatesWithExclusionPeriod.ps1 ao se conectar ao servidor WSUS ou ocorrerá um erro 401 durante a execução para etapas de solução de problemas.

Depois que as atualizações substituídos foram recusadas, para melhor desempenho, o SUSDB deve ser reindexado novamente. Para obter informações relacionadas, consulte Reindexar o banco de dados WSUS.

Executar o Assistente de Limpeza do Servidor WSUS

O WSUS Server Cleanup Wizard fornece opções para limpar os seguintes itens:

  • Atualizações nãousadas e revisões de atualização (também conhecidas como atualizações obsoletas)
  • Computadores que não estão contatando o servidor
  • Arquivos de atualização não-precisas
  • Atualizações expiradas
  • Atualizações supersedadas

Em um ambiente do Configuration Manager, os computadores que não estão contatando o servidor e as opções de arquivos de atualização não são relevantes porque o Configuration Manager gerencia o conteúdo e os dispositivos de atualização de software, a menos que as opções Criar todos os eventos de relatório do WSUS ou Criar apenas eventos de relatório de status do WSUS sejam selecionadas em Software Update Sync Configurações. Se você tiver uma dessas opções configuradas, considere automatizar a Limpeza do Servidor WSUS para executar a limpeza dessas duas opções.

Se você estiver usando o Configuration Manager versão atual do branch 1906 ou uma versão posterior, a habilitação das atualizações expiradas de Declínio no WSUS de acordo com as regras de supersedência tratará do declínio das atualizações expiradas e das atualizações supersedadas com base nas regras de supersedência especificadas no Configuration Manager. A habilitação da opção Remover atualizações obsoletas do banco de dados do WSUS no Configuration Manager versão atual 1906 lida com a limpeza de atualizações e revisões de atualização nãousadas ( atualizações obsoletas). É recomendável habilitar essas opções na configuração do ponto de atualização de software no site de nível superior para permitir que o Configuration Manager limpe o banco de dados WSUS.

Captura de tela da opção Remover atualizações obsoletas do banco de dados WSUS.

Se você nunca limpou atualizações obsoletas do banco de dados WSUS antes, essa tarefa pode ter um tempo de vida. Você pode revisar WsyncMgr.log para obter mais informações e executar manualmente o script SQL especificado em HELP! Meu WSUS está em execução há anos sem nunca ter feito a manutenção e o assistente de limpeza mantém o tempo de execução uma vez, o que permitiria que as tentativas subsequentes do Configuration Manager fosse realizadas com êxito. Para obter mais informações sobre a limpeza e manutenção do WSUS no Configuration Manager, consulte os documentos.

Para servidores WSUS autônomos ou se você estiver usando uma versão mais antiga do Configuration Manager, é recomendável executar periodicamente o assistente de Limpeza do WSUS. Se o Assistente de Limpeza do Servidor WSUS nunca tiver sido executado e o WSUS estiver em produção por um tempo, a limpeza poderá passar do tempo. Nesse caso, reindexe com as etapas 2 e 3 primeiro e execute a limpeza apenas com a opção Atualizações não-usadas e revisões de atualização verificadas .

Se você nunca tiver executado o assistente de Limpeza do WSUS, executar a limpeza com atualizações nãousadas e revisões de atualização pode exigir algumas passagens. Se o tempo passar, execute-o novamente até que ele seja concluído e execute cada uma das outras opções uma de cada vez. Por fim, faça uma passagem completa com todas as opções verificadas. Se os tempos-de-tempo continuarem a ocorrer, consulte a SQL Server alternativa em HELP! Meu WSUS está em execução há anos sem nunca ter feito a manutenção e o assistente de limpeza mantém o tempo de execução. Pode levar várias horas ou dias para o Assistente de Limpeza do Servidor ou SQL para ser executado até a conclusão.

O Assistente de Limpeza do Servidor WSUS é executado no console do WSUS. Ele está localizado em Opções, conforme mostrado aqui:

Captura de tela da página local do Assistente de Limpeza do Servidor WSUS.

Para obter mais informações, consulte Use the Server Cleanup Wizard.

Captura de tela da página inicial do Assistente de Limpeza do Servidor WSUS.

Depois que ele relata o número de itens removidos, a limpeza termina. Se você não vir essas informações retornadas em seu servidor WSUS, é seguro supor que o tempo de limpeza foi desajustado. Nesse caso, você precisará in-locar novamente ou usar a SQL alternativa.

Captura de tela do Assistente de Limpeza do Servidor WSUS quando concluído.

Depois que as atualizações substituídos foram recusadas, para melhor desempenho, o SUSDB deve ser reindexado novamente. Consulte a seção Reindexar o banco de dados WSUS para obter informações relacionadas.

Solução de problemas

AJUDA! Meu WSUS está em execução há anos sem nunca ter feito a manutenção e o assistente de limpeza mantém o tempo de execução

Há duas opções diferentes aqui:

  1. Reinstale o WSUS com um banco de dados novo. Há várias advertências relacionadas a isso, incluindo comprimento da sincronização inicial e verificações completas do cliente em relação ao SUSDB, versus verificações diferenciais.

  2. Verifique se você tem um backup do banco de dados SUSDB e execute uma reindexação. Quando isso for concluído, execute o seguinte script no SQL Server Management Studio ou SQL Server Management Studio Express. Depois de concluir, siga todas as instruções acima para executar a manutenção. Esta última etapa é necessária porque o spDeleteUpdate procedimento armazenado remove apenas atualizações nãousadas e revisões de atualização.

Observação

Antes de executar o script, siga as etapas em O procedimento armazenado spDeleteUpdate é executado lentamente para melhorar o desempenho da execução de spDeleteUpdate.

DECLARE @var1 INT
DECLARE @msg nvarchar(100)

CREATE TABLE #results (Col1 INT)
INSERT INTO #results(Col1) EXEC spGetObsoleteUpdatesToCleanup

DECLARE WC Cursor
FOR
SELECT Col1 FROM #results

OPEN WC
FETCH NEXT FROM WC
INTO @var1
WHILE (@@FETCH_STATUS > -1)
BEGIN SET @msg = 'Deleting' + CONVERT(varchar(10), @var1)
RAISERROR(@msg,0,1) WITH NOWAIT EXEC spDeleteUpdate @localUpdateID=@var1
FETCH NEXT FROM WC INTO @var1 END

CLOSE WC
DEALLOCATE WC

DROP TABLE #results

Executar o script Decline-SupersededUpdatesWithExclusionPeriod.ps1 tempo de execução ao se conectar ao servidor WSUS ou ocorrerá um erro 401 durante a execução

Se ocorrerem erros ao tentar usar o script do PowerShell para recusar atualizações superadas, um script SQL alternativo pode ser executado em relação ao SUDB.

  1. Se o Configuration Manager for usado juntamente com o WSUS, verifique Propriedades do Componente do Ponto de Atualização de SoftwareSupersedence > Rules para ver a velocidade com que as atualizações supersedadas expiram, como imediatamente ou após os meses X. Anote essa configuração.

    Captura de tela das Regras de Supersedência.

  2. Se você não fez o backup do banco de dados SUSDB, faça isso antes de prosseguir.

  3. Use SQL Server Management Studio para se conectar ao SUSDB.

  4. Execute a seguinte consulta. O número 90 DECLARE @thresholdDays INT = 90 na linha que inclui deve corresponder às Regras de Supersedência da etapa 1 deste procedimento e o número correto de dias que se alinha ao número de meses configurado em Regras de Supersedência. Se estiver definido para expirar imediatamente, o valor na SQL consulta deve @thresholdDays ser definido como zero.

    -- Decline superseded updates in SUSDB; alternative to Decline-SupersededUpdatesWithExclusionPeriod.ps1
DECLARE @thresholdDays INT = 90 -- Specify the number of days between today and the release date for which the superseded updates must not be declined (i.e., updates older than 90 days). This should match configuration of supersedence rules in SUP component properties, if ConfigMgr is being used with WSUS.
DECLARE @testRun BIT = 0 -- Set this to 1 to test without declining anything.
-- There shouldn't be any need to modify anything after this line.

DECLARE @uid UNIQUEIDENTIFIER
DECLARE @title NVARCHAR(500)
DECLARE @date DATETIME
DECLARE @userName NVARCHAR(100) = SYSTEM_USER

DECLARE @count INT = 0

DECLARE DU CURSOR FOR
  SELECT MU.UpdateID, U.DefaultTitle, U.CreationDate FROM vwMinimalUpdate MU
  JOIN PUBLIC_VIEWS.vUpdate U ON MU.UpdateID = U.UpdateId
WHERE MU.IsSuperseded = 1 AND MU.Declined = 0 AND MU.IsLatestRevision = 1
  AND MU.CreationDate < DATEADD(dd,-@thresholdDays,GETDATE())
ORDER BY MU.CreationDate

PRINT 'Declining superseded updates older than ' + CONVERT(NVARCHAR(5), @thresholdDays) + ' days.' + CHAR(10)

OPEN DU
FETCH NEXT FROM DU INTO @uid, @title, @date
WHILE (@@FETCH_STATUS > - 1)
BEGIN
  SET @count = @count + 1
  PRINT 'Declining update ' + CONVERT(NVARCHAR(50), @uid) + ' (Creation Date ' + CONVERT(NVARCHAR(50), @date) + ') - ' + @title + ' ...'
  IF @testRun = 0
     EXEC spDeclineUpdate @updateID = @uid, @adminName = @userName, @failIfReplica = 1
  FETCH NEXT FROM DU INTO @uid, @title, @date
END

CLOSE DU
DEALLOCATE DU

PRINT CHAR(10) + 'Attempted to decline ' + CONVERT(NVARCHAR(10), @count) + ' updates.'

  5. Para verificar o andamento, monitore a guia Mensagens no painel Resultados .

E se eu descobrir que precisava de uma das atualizações que eu recusava?

Se você decidir que precisa de uma dessas atualizações recusadas no Configuration Manager, poderá reempresá-la no WSUS clicando com o botão direito do mouse na atualização e selecionando Aprovar. Altere a aprovação para Não Aprovado e ressíncrona o SUP para trazer a atualização de volta.

Captura de tela da tela Aprovar Atualizações do WSUS.

Se a atualização não estiver mais no WSUS, ela poderá ser importada do Catálogo de Atualizações da Microsoft, se não tiver expirado ou removido do catálogo.

Captura de tela mostra como importar atualizações no WSUS.

Automatizando a manutenção do WSUS

Observação

Se você estiver usando o Configuration Manager versão1906 ou uma versão posterior, automatize os procedimentos de limpeza habilitando as opções de Manutenção do WSUS na configuração do ponto de atualização de software do site de nível superior. Essas opções lidam com todas as operações de limpeza executadas pelo Assistente de Limpeza do Servidor WSUS. No entanto, você ainda deve fazer o back-up e reindexar automaticamente o banco de dados WSUS em um cronograma.

As tarefas de manutenção do WSUS podem ser automatizadas, supondo-se que alguns requisitos sejam atendidos primeiro.

  1. Se você nunca tiver executado a limpeza do WSUS, precisará fazer as duas primeiras limpezas manualmente. Sua segunda limpeza manual deve ser executado 30 dias a partir do primeiro, já que leva 30 dias para algumas atualizações e revisões de atualização para o fim. Há motivos específicos para o motivo pelo qual você não deseja automatizar até depois da segunda limpeza. Sua primeira limpeza provavelmente será mais longa do que o normal. Portanto, você não pode avaliar quanto tempo essa manutenção normalmente levará. A segunda limpeza é um indicador muito melhor do que é normal para seus máquinas. Isso é importante porque você precisa descobrir quanto tempo cada etapa leva como uma linha de base (também gosto de adicionar cerca de 30 minutos de espaço de movimento) para que você possa determinar o tempo para sua agenda.

  2. Se você tiver servidores WSUS downstream, você precisará executar a manutenção neles primeiro e, em seguida, fazer os servidores upstream.

  3. Para agendar a reindexação do SUSDB, você precisará de uma versão completa do SQL Server. Banco de Dados Interno do Windows (WID) não tem a capacidade de agendar uma tarefa de manutenção SQL Server Management Studio Express. Dito isso, nos casos em que o WID é usado, você pode usar o Agendador de Tarefas com mencionado SQLCMD anteriormente. Se você seguir essa rota, é importante que você não sincronize seus servidores/SUPs WSUS durante esse período de manutenção! Se fizer isso, é possível que seus servidores downstream terminem resyncing todas as atualizações que você acabou de tentar limpar. Agende isso durante a noite antes da sincronização am, portanto, tenho tempo para verificar antes que a sincronização seja executado.

Links necessários/úteis:

Script de limpeza do WSUS

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")` 
 | out-null 
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer(); 
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope; 
$cleanupScope.DeclineSupersededUpdates = $true        
$cleanupScope.DeclineExpiredUpdates = $true 
$cleanupScope.CleanupObsoleteUpdates = $true 
$cleanupScope.CompressUpdates = $true 
#$cleanupScope.CleanupObsoleteComputers = $true 
$cleanupScope.CleanupUnneededContentFiles = $true 
$cleanupManager = $wsus.GetCleanupManager(); 
$cleanupManager.PerformCleanup($cleanupScope);

Configurando a tarefa de Limpeza do WSUS no Agendador de Tarefas

Observação

Como mencionado anteriormente, se você estiver usando o Configuration Manager atual branch versão 1906 ou uma versão posterior, automatize os procedimentos de limpeza habilitando as opções de Manutenção do WSUS na configuração do ponto de atualização de software do site de nível superior. Para servidores WSUS autônomos ou versões mais antigas do Configuration Manager, você pode continuar a usar as etapas a seguir.

A postagem do blog do Scripter de Fim de Semana mencionada na seção anterior contém instruções básicas e solução de problemas para esta etapa. No entanto, eu o acompanharei durante o processo nas etapas a seguir.

  1. Abra o Agendador de Tarefas e selecione Criar uma Tarefa. Na guia Geral , de definir o nome da tarefa, o usuário que você deseja executar o script do PowerShell como (a maioria das pessoas usa uma conta de serviço). Selecione Executar se um usuário está conectado ou não e adicione uma descrição, se desejar.

    Captura de tela do WSUS Criar uma tela de tarefa.

  2. Na guia Ações , adicione uma nova ação e especifique o programa/script que você deseja executar. Nesse caso, precisamos usar o PowerShell e apontar para o arquivo PS1 que queremos que ele seja executado. Você pode usar o script de Limpeza do WSUS. Esse script executa opções de limpeza que o Configuration Manager versão 1906 atual não faz. Você pode descompactá-los se estiver usando o WSUS autônomo ou uma versão mais antiga do Configuration Manager. Se quiser um log, você pode modificar a última linha do script da seguinte forma:

    [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$cleanupScope = new-object Microsoft.UpdateServices.Administration.CleanupScope;
# $cleanupScope.DeclineSupersededUpdates = $true # Performed by CM1906
# $cleanupScope.DeclineExpiredUpdates    = $true # Performed by CM1906
# $cleanupScope.CleanupObsoleteUpdates   = $true # Performed by CM1906
$cleanupScope.CompressUpdates          = $true
$cleanupScope.CleanupObsoleteComputers = $true
$cleanupScope.CleanupUnneededContentFiles = $true
$cleanupManager = $wsus.GetCleanupManager();
$cleanupManager.PerformCleanup($cleanupScope) | Out-File C:\WSUS\WsusClean.txt;

    Você obterá um FYI/aviso no Agendador de Tarefas ao salvar. Você pode ignorar esse aviso.

    A captura de tela mostra que o WSUS adiciona uma linha de script para iniciar a tarefa.

  3. Na guia Gatilhos , de definir sua agenda para uma vez por mês ou em qualquer agenda que você deseja. Novamente, você deve garantir que não sincronize seu WSUS durante todo o tempo de limpeza e reindexação.

    Captura de tela mostra Definir o Gatilho de Edição do WSUS para a tarefa.

  4. Defina outras condições ou configurações que você também gostaria de ajustar. Ao salvar a tarefa, você pode ser solicitado a solicitar credenciais do usuário Executar como .

  5. Você também pode usar essas etapas para configurar o script Decline-SupersededUpdatesWithExclusionPeriod.ps1 para ser executado a cada três meses. Normalmente, desarmei esse script para ser executado antes das outras etapas de limpeza, mas somente depois de executar manualmente e garantir que ele seja concluído com êxito. Eu corro às 00:00 no primeiro domingo a cada três meses.

Configurando a reindexação SUSDB para WID usando SQLCMD e Agendador de Tarefas

  1. Salve o script reindexar o banco de dados WSUS como um arquivo .sql (por exemplo, SUSDBMaint.sql).

  2. Crie uma tarefa básica e dê um nome a ela:

    Captura de tela da tela Do WSUS Create Basic Task Wizard.

  3. Agende essa tarefa para começar cerca de 30 minutos depois que você espera que a limpeza termine de executar. Minha limpeza está sendo executado às 13:00 todos os primeiros domingos. Leva cerca de 30 minutos para ser executado e eu vou dar a ele mais 30 minutos antes de iniciar minha reindexação. Isso significa que eu agendaria essa tarefa para todo primeiro domingo às 2:00 da manhã, conforme mostrado aqui:

    A captura de tela mostra definir a frequência dessa tarefa no Assistente para Criar Tarefas Básicas.

  4. Selecione a ação para Iniciar um programa. Na caixa Programa/script , digite o seguinte comando. O arquivo especificado após o -i parâmetro é o caminho para o SQL que você salvou na etapa 1. O arquivo especificado após o -o parâmetro é onde você gostaria que o log fosse colocado. Veja um exemplo:

    "C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.exe" -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt

    Captura de tela mostra como o script deve ser exibido no Assistente para Criar Tarefas Básicas.

  5. Você receberá um aviso, semelhante ao que você recebeu ao criar a tarefa de limpeza. Selecione Sim para aceitar os argumentos e selecione Concluir para aplicar:

    Captura de tela da janela pop-up de confirmação do Agendador de Tarefas.

  6. Você pode testar o script forçando-o a executar e revisar o log em busca de erros. Se você tiver problemas, o log dirá o motivo. Normalmente, se falhar, a conta que executa a tarefa não tem permissões apropriadas ou o serviço WID não é iniciado.

Configurando uma tarefa básica de manutenção agendada no SQL para SUSDBs não WID

Observação

Você deve ser um sysadmin no SQL Server para criar ou gerenciar planos de manutenção.

  1. Abra SQL Server Management Studio e conecte-se à sua instância do WSUS. Expanda o Gerenciamento, clique com o botão direito do mouse em Planos de Manutenção e selecione Novo Plano de Manutenção. Dê um nome ao seu plano.

    Captura de tela do nome digitado para seu plano de manutenção do WSUS.

  2. Selecione o subplan1 e verifique se a Caixa de Ferramentas está no contexto:

    Captura de tela para garantir que sua Caixa de Ferramentas está no contexto.

  3. Arraste e solte a tarefa Execute T-SQL Instrução Task:

    Captura de tela da opção Executar Tarefa SQL Instrução T.

  4. Clique com o botão direito do mouse nele e selecione Editar. Copie e colar o script de reindexação do WSUS e selecione OK:

    Captura de tela para Copiar e colar o script de reindexação do WSUS.

  5. Agende essa tarefa para ser executado cerca de 30 minutos depois que você espera que a limpeza termine de executar. Minha limpeza está sendo executado às 13:00 todos os primeiros domingos. Leva cerca de 30 minutos para ser executado e vou dar mais 30 minutos antes de começar a reindexar. Isso significa que eu agendaria essa tarefa para ser executado todo primeiro domingo às 2:00 da manhã.

    Captura de tela da tela Novo Cronograma de Trabalho do WSUS.

  6. Ao criar o plano de manutenção, considere adicionar um backup do SUSDB ao plano também. Geralmente faço o back-up primeiro, depois reindexo. Pode adicionar mais tempo à agenda.

Colocando tudo em um só lugar

Ao ser executado em uma hierarquia, a execução de limpeza do WSUS deve ser feita da parte inferior da hierarquia para cima. No entanto, ao usar o script para recusar atualizações superadas, a executar deve ser feita de cima para baixo. A remoção de atualizações sobressaladas é realmente um tipo de adição a uma atualização em vez de uma remoção. Na verdade, você está adicionando um tipo de aprovação nesse caso.

Como uma sincronização não pode ser feita durante a limpeza real, é sugerido agendar/concluir todas as tarefas durante a noite. Em seguida, verifique sua conclusão por meio do registro em log na manhã seguinte, antes da próxima sincronização agendada. Se algo falhar, a manutenção poderá ser reagendada para a próxima noite, depois que o problema subjacente for identificado e resolvido.

Essas tarefas podem ser executadas mais rápido ou mais lento, dependendo do ambiente, e o tempo da agenda deve refletir isso. Esperamos que eles sejam mais rápidos, pois meu ambiente de laboratório tende a ser um pouco mais lento do que um ambiente de produção normal. Sou um pouco agressivo no momento dos scripts de recusa. Se a Camada2 se sobrepor à Camada3 por alguns minutos, isso não causará um problema porque minha sincronização não está agendada para ser executado.

A não sincronização impede que os declínios fluam acidentalmente para meus servidores WSUS de réplica Tier3 da Camada2. Eu me dei um tempo extra entre o declínio da Camada3 e a limpeza da Camada3, pois quero garantir que o script de recusa termine antes de executar minha limpeza.

Isso traz uma pergunta comum: como não estou sincronizando, por que não devo executar todas as limpezas e reindexações ao mesmo tempo?

A resposta é que você provavelmente poderia, mas eu não. Se meu colega de trabalho em todo o mundo precisar executar uma sincronização, com essa agenda, minimizaria o risco de atualizações órfãs no WSUS. E posso agendar para ser reprisada na próxima noite.

Time Camada Tarefas
12:00 Tier1-Decline
12:15 Tier2-Decline
12:30 Tier3-Decline
13:00 AM Limpeza WSUS tier3
2:00 AM Camada3 Reindex Limpeza WSUS tier2
3:00 AM Tier1-Cleanup Camada2 Reindex
4:00 AM Camada1 Reindex

Observação

Se você estiver usando o Configuration Manager versão atual da filial 1906 ou uma versão posterior para executar a Manutenção do WSUS, o Configuration Manager realizará a limpeza após a sincronização usando a abordagem de cima para baixo. Nesse cenário, você pode agendar os trabalhos de backup e reindexação de banco de dados do WSUS para serem executados antes do agendamento de sincronização configurado sem se preocupar com nenhuma das outras etapas, pois o Configuration Manager tratará de tudo o resto.

Para obter mais informações sobre a manutenção do SUP no Configuration Manager, consulte os seguintes artigos: