O guia completo para a manutenção do Microsoft WSUS e Configuration Manager SUP
Este artigo aborda algumas perguntas comuns sobre a manutenção do WSUS Configuration Manager ambientes.
Versão original do produto: Windows Servers, Windows Server Update Services, Configuration Manager
Número original do KB: 4490644
Introdução
As perguntas geralmente estão ao longo das linhas de Como devo executar corretamente essa manutenção em um ambiente de Configuration Manager ou com que frequência devo executar essa manutenção. Não é incomum para administradores Configuration Manager conscientes não saberem que a manutenção do WSUS deve ser executada. A maioria de nós apenas configura servidores do WSUS porque é um pré-requisito para um SUP (ponto de atualização de software). Depois que o SUP estiver configurado, fecharemos o console do WSUS e fingiremos que ele não existe. Infelizmente, isso pode ser problemático para Configuration Manager clientes e o desempenho geral do servidor WSUS/SUP.
Com a compreensão de que essa manutenção precisa ser feita, você está se perguntando qual manutenção precisa fazer e com que frequência 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.
Para obter mais informações sobre etapas concisas e scripts automáticos, consulte Manutenção manual e automática do banco de dados do WSUS.
Manter o WSUS enquanto dá suporte Configuration Manager branch atual versão 1906 e versões posteriores
Se você estiver usando o Configuration Manager branch atual versão 1906 ou posterior, recomendamos habilitar 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 lidaria efetivamente com todas as operações de limpeza descritas neste artigo, exceto backup e reindexação do banco de dados do WSUS. Você ainda deve automatizar o backup do banco de dados do WSUS junto com a reindexação do banco de dados do WSUS em um agendamento.
Para obter mais informações sobre a manutenção de atualização de software 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 Configuration Manager lida com a limpeza após cada sincronização.
Antes de iniciar o processo de manutenção, leia todas as informações e instruções neste artigo.
Ao usar o WSUS juntamente com servidores downstream, os servidores do WSUS são adicionados de cima para baixo, mas devem ser removidos de baixo para cima. Ao sincronizar ou adicionar atualizações, eles vão primeiro para o servidor upstream do WSUS e, em seguida, replicam para os servidores downstream. Ao executar uma limpeza e remover itens de servidores WSUS, você deve começar na parte inferior da hierarquia.
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 passar para a próxima. As etapas de limpeza e reindexação descritas abaixo devem ser executadas em todos os servidores do WSUS, independentemente de serem um servidor WSUS de réplica ou não. Para obter mais informações sobre como determinar se um servidor do WSUS é uma réplica, consulte Recusar atualizações substituídas.
Verifique se os SUPs não são sincronizados durante o processo de manutenção, pois isso pode causar uma perda de algum trabalho já feito. Verifique o agendamento de sincronização sup e defina-o temporariamente como manual durante esse processo.
Se você tiver vários SUPs do site primário ou cas (administração central) que não compartilham o SUSDB, considere o servidor do 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 (Camada1).
- O servidor chamado "2012" sincroniza com "Novo" e seria considerado no segundo nível. Ele pode ser limpo ao mesmo tempo em que eu faria todos os meus outros servidores Tier2, como o ÚNICO SUP do meu site primário.
Executar a manutenção do WSUS
As etapas básicas necessárias para a manutenção adequada do WSUS incluem:
- Fazer backup do banco de dados do WSUS
- Criar índices de campo personalizado
- Reindexar o banco de dados do WSUS
- Recusar atualizações substituídas e executar manutenção
- O Assistente de Limpeza do Servidor WSUS.
Fazer backup do banco de dados do WSUS
Faça backup do banco de dados do WSUS (SUSDB) usando o método desejado. Para saber mais, confira Criar um backup completo de banco de dados.
Criar índices de campo personalizado
Esse processo é opcional, mas recomendado, melhora muito o desempenho durante as operações de limpeza subsequentes.
Se você estiver usando Configuration Manager branch atual versão 1906 ou posterior, recomendamos que você use Configuration Manager para criar os índices. Para criar os índices, configure a opção Adicionar índices não clusterizados à opção de banco de dados do WSUS na configuração do ponto de atualização de software para o site mais alto.
Se você usar uma versão mais antiga de 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.
Verifique se você tem um backup do banco de dados SUSDB.
Use o SQL Management Studio para se conectar ao banco de dados SUSDB, da mesma maneira que descrito na seção Reindexar o banco de dados do WSUS .
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 os índices personalizados tiverem sido criados anteriormente, executar o script novamente resultará em um erro semelhante ao seguinte:
Mensagem 1913, Nível 16, Estado 1, Linha 1
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 do WSUS
Para reindexar o banco de dados do WSUS (SUSDB), use a reindexação do script T-SQL do Banco de Dados do WSUS.
As etapas para se conectar ao SUSDB e executar o reindexamento 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á em execução, SQLServerName
verifique o valor da entrada do Registro no servidor do WSUS localizado na HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup
subchave.
Se o valor contiver apenas o nome do servidor ou server\instance, o SUSDB estará em execução em um SQL Server. Se o valor incluir a cadeia de caracteres ##SSEE
ou ##WID
nela, o SUSDB estará em execução no WID, conforme mostrado:
Se o SUSDB foi instalado no WID
Se o SUSDB tiver sido instalado no WID, SQL Server Management Studio Express deverá 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:
Windows Server 2012 e versões posteriores
Acesse e
C:\Windows\WID\Log
localize o log de erros que contém o número de versão.Como determinar a versão, a edição e o nível de atualização do SQL Server e seus componentes Esse valor informa qual nível de SERVICE Pack (SP) o WID está em execução. Inclua o nível de SP ao pesquisar o Centro de Download da Microsoft SQL Server Management Studio Express.
para Windows Server 2008 R2 (KB3138865)
- Acesse e
C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG
abra o último log de erros com o Bloco de Notas. Na parte superior, haverá um número de versão (por exemplo, 9.00.4035.00 x64). Como determinar a versão, a edição e o nível de atualização do SQL Server e seus componentes Esse número de versão informa o nível do Service Pack em execução. Inclua o nível de SP ao pesquisar o Centro de Download da Microsoft SQL Server Management Studio Express.
- Acesse e
Depois de instalar SQL Server Management Studio Express, inicie-o e insira o nome do servidor ao qual se conectar:
- Se o sistema operacional for Windows Server 2012 ou versões posteriores, use
\\.\pipe\MICROSOFT##WID\tsql\query
. - Se o sistema operacional for mais antigo que Windows Server 2012, insira
\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
.
Para WID, se ocorrerem erros semelhantes ao seguinte ao tentar se conectar ao SUSDB usando o SQL Server Management Studio (SSMS), tente iniciar o SSMS usando a opção Executar como administrador.
Se o SUSDB foi instalado no SQL Server
Se o SUSDB tiver sido instalado no SQL Server, inicie o SQL Server Management Studio e insira o nome do servidor (e da 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 as Notas de versão.
Executar o script
Para executar o script no SQL Server Management Studio ou SQL Server Management Studio Express, selecione Nova Consulta, cole o script na janela e selecione Executar. Quando terminar, uma mensagem de consulta executada com êxito será exibida na barra de status. E o painel Resultados conterá mensagens relacionadas a quais índices foram recriados.
Recusar atualizações substituídas e executar manutenção
Recuse as atualizações substituídas no servidor do WSUS para ajudar os clientes a verificar com mais eficiência. Antes de declinar as atualizações, verifique se as atualizações substituídas estão implantadas e se as substituídas não são mais necessárias. Configuration Manager inclui uma limpeza separada, que permite que ela expire atualizações substituídas com base nos critérios especificados. Para obter mais informações, consulte os seguintes artigos:
A consulta SQL a seguir pode ser executada no banco de dados SUSDB para determinar rapidamente o número de atualizações substituídas. Se o número de atualizações substituídas for maior que 1500, isso poderá causar vários problemas relacionados à atualização de software nos lados do servidor e 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 branch atual versão 1906 ou posterior, recomendamos que você recuse automaticamente as atualizações substituídas habilitando a opção Recusar atualizações expiradas no WSUS de acordo com a opção de regras de substituição na configuração do ponto de atualização de software para o site mais alto.
Ao usar essa opção, você pode ver quantas atualizações foram recusadas examinando o arquivo WsyncMgr.log após a conclusão do processo de sincronização. Se você usar essa opção, não precisará usar o script descrito posteriormente nesta seção (executando-o manualmente ou configurando como tarefa para executá-lo em um agendamento).
Se você estiver usando servidores WSUS autônomos ou uma versão mais antiga do Configuration Manager, poderá recusar manualmente as atualizações substituídas usando o console do WSUS. Ou você pode executar esse script do PowerShell. Em seguida, copie e salve o script como um Decline-SupersededUpdatesWithExclusionPeriod.ps1 de script.
Observação
Esse script é fornecido como está. Ele deve ser totalmente testado em um laboratório antes de usá-lo em 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 substituídas serão recusadas.
Se Configuration Manager definido como Expirar imediatamente as atualizações substituídas (veja abaixo), o script do PowerShell poderá ser usado para recusar todas as atualizações substituídas. Isso deve ser feito em todos os servidores autônomos do WSUS na hierarquia Configuration Manager/WSUS.
Você não precisa executar o script do PowerShell em servidores WSUS definidos como réplicas, como SUPs de site secundário. Para determinar se um servidor do WSUS é uma réplica, verifique as configurações da Fonte de Atualização.
Se as atualizações não forem configuradas para expirar imediatamente no Configuration Manager, o script do PowerShell deverá ser executado com um período de exclusão que corresponda à configuração de Configuration Manager do número de dias para expirar as atualizações substituídas. Nesse caso, seriam 60 dias desde que as propriedades do componente SUP estejam configuradas para aguardar dois meses antes da expiração das atualizações substituídas:
As linhas de comando a seguir ilustram as várias maneiras pelas quais o script do PowerShell pode ser executado:
Observação
Ao executar o script no servidor WSUS, use LOCALHOST
em vez do .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 do WSUS e quantas atualizações podem ser recusadas:
Executar o script com -ExclusionPeriod 60 para recusar atualizações substituídas com mais de 60 dias:
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:
Observação
Se ocorrerem problemas ao tentar usar o script do PowerShell acima para recusar atualizações substituídas, consulte a seção Executando o script Decline-SupersededUpdatesWithExclusionPeriod.ps1 atinge o tempo limite ao se conectar ao servidor do WSUS ou ocorre um erro 401 durante a execução de etapas de solução de problemas.
Depois que as atualizações substituídas tiverem sido recusadas, para obter o melhor desempenho, o SUSDB deverá ser reindexado novamente. Para obter informações relacionadas, consulte Reindexar o banco de dados do WSUS.
O Assistente de Limpeza do Servidor WSUS.
O Assistente de Limpeza de Servidor do WSUS fornece opções para limpar os seguintes itens:
- Atualizações não utilizadas 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 desnecessários
- Atualizações expiradas
- Atualizações substituídas
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 desnecessários 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 estejam selecionadas em Configurações de sincronização de atualização de software. Se você tiver uma dessas opções configuradas, considere automatizar a Limpeza de Servidor do WSUS para executar a limpeza dessas duas opções.
Se você estiver usando um branch atual versão 1906 ou posterior, habilitar as atualizações expiradas de Recusa no WSUS de acordo com a opção de regras de substituição tratará o declínio de atualizações expiradas e as atualizações substituídas com base nas regras de substituição especificadas no Configuration Manager. Configuration Manager Habilitar a opção Remover atualizações obsoletas da opção de banco de dados do WS Configuration Manager US na versão 1906 do branch atual lida com a limpeza de atualizações não utilizadas e revisões de atualização (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 Configuration Manager limpe o banco de dados do WSUS.
Se você nunca tiver limpo atualizações obsoletas do banco de dados do WSUS antes, essa tarefa poderá expirar. Você pode examinar wsyncMgr.log para obter mais informações e executar manualmente o script SQL especificado na AJUDA! Meu WSUS está em execução há anos sem nunca ter feito a manutenção e o assistente de limpeza continua atingindo o tempo limite uma vez, o que permitiria que as tentativas subsequentes Configuration Manager sejam executadas com êxito. Para obter mais informações sobre a limpeza e a manutenção do WSUS Configuration Manager, consulte os documentos.
Para servidores autônomos do WSUS ou se você estiver usando uma versão mais antiga do Configuration Manager, é recomendável executar o assistente de Limpeza do WSUS periodicamente. Se o Assistente de Limpeza de Servidor do WSUS nunca tiver sido executado e o WSUS estiver em produção há algum tempo, a limpeza poderá expirar. Nesse caso, reindexe primeiro com as etapas 2 e 3 e, em seguida, execute a limpeza apenas com a opção de atualizações não utilizadas e revisões de atualização marcada.
Se você nunca tiver executado o assistente de Limpeza do WSUS, executar a limpeza com atualizações não utilizadas e revisões de atualização poderá exigir algumas passagens. Se ele expirar, 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 marcadas. Se os tempos limite continuarem a ocorrer, consulte a SQL Server alternativa na AJUDA! Meu WSUS está em execução há anos sem nunca ter feito a manutenção e o assistente de limpeza continua atingindo o tempo limite. Pode levar várias horas ou dias para que o Assistente de Limpeza do Servidor ou a alternativa do SQL sejam executados até a conclusão.
O Assistente de Limpeza de Servidor do WSUS é executado no console do WSUS. Ele está localizado em Opções, conforme mostrado aqui:
Para obter mais informações, consulte Visualizar um log de erros do SQL Server.
Depois de relatar o número de itens removidos, a limpeza é concluída. Se você não vir essas informações retornadas no servidor do WSUS, é seguro supor que a limpeza tenha tempo limite. Nesse caso, você precisará in start-lo novamente ou usar a alternativa do SQL.
Depois que as atualizações substituídas tiverem sido recusadas, para obter o melhor desempenho, o SUSDB deverá ser reindexado novamente. Consulte a seção Reindexar o banco de dados do 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 continua atingindo o tempo limite
Há duas opções diferentes aqui:
Reinstale o WSUS com um novo banco de dados. Há várias limitações relacionadas a isso, incluindo o comprimento da sincronização inicial e verificações completas do cliente em relação ao SUSDB, versus verificações diferenciais.
Verifique se você tem um backup do banco de dados SUSDB e execute uma reindexação. Quando isso for concluído, execute o script a seguir no SQL Server Management Studio ou SQL Server Management Studio Express. Após a conclusão, 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ão utilizadas e revisões de atualização.
Observação
Antes de executar o script, siga as etapas no 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
A execução Decline-SupersededUpdatesWithExclusionPeriod.ps1 script atinge o tempo limite ao se conectar ao servidor do WSUS ou ocorre um erro 401 durante a execução
Se ocorrerem erros quando você tentar usar o script do PowerShell para recusar atualizações substituídas, um script SQL alternativo poderá ser executado no SUDB.
Se o Configuration Manager for usado junto com o WSUS, verifique as Regras de Substituição de Propriedades>do Componente do Ponto de Atualização de Software para ver a rapidez com que as atualizações substituídas expiram, como imediatamente ou após X meses. Anote esse nome.
Se você ainda não fez backup do banco de dados SUSDB, faça isso antes de continuar.
Use o SQL Server Management Studio Express.
Execute a consulta a seguir. O número 90
DECLARE @thresholdDays INT = 90
na linha que inclui deve corresponder às Regras de Substituição da etapa 1 deste procedimento e ao número correto de dias que se alinha com o número de meses configurado nas Regras de Substituição. Se isso for definido para expirar imediatamente, o valor na consulta SQL@thresholdDays
deverá 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.'
Para verificar o progresso, 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á obtê-la novamente 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, em seguida, ressincronize o SUP para trazer a atualização de volta.
Se a atualização não estiver mais no WSUS, ela poderá ser importada do Catálogo do Microsoft Update, se não tiver expirado ou removido do catálogo.
Automatizando a manutenção do WSUS
Observação
Se você estiver usando Configuration Manager versão1906 ou 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 de Servidor do WSUS. No entanto, você ainda deve fazer backup e reindexar automaticamente o banco de dados do WSUS em um agendamento.
As tarefas de manutenção do WSUS podem ser automatizadas, supondo que alguns requisitos sejam atendidos primeiro.
Se você nunca tiver executado a limpeza do WSUS, precisará fazer as duas primeiras limpezas manualmente. Sua segunda limpeza manual deve ser executada 30 dias a partir do primeiro, pois leva 30 dias para que algumas atualizações e revisões de atualização se estimem. Há motivos específicos para o motivo pelo qual você não deseja automatizar até após a segunda limpeza. Sua primeira limpeza provavelmente será mais longa do que o normal. Então você não pode julgar quanto tempo essa manutenção normalmente levará. A segunda limpeza é um indicador muito melhor do que é normal para seus computadores. 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.
Se você tiver servidores WSUS downstream, precisará executar a manutenção neles primeiro e, em seguida, fazer os servidores upstream.
Para agendar a reindexação do SUSDB, você precisará de uma versão completa 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 não sincronizar seus servidores/SUPs do WSUS durante esse período de manutenção! Se você fizer isso, é possível que seus servidores downstream acabarão ressindo todas as atualizações que você acabou de tentar limpar. Eu agendo isso durante a noite antes da sincronização am, então tenho tempo para verificar antes que a sincronização seja executada.
Links necessários/úteis:
- Reindexar o banco de dados do WSUS
- Opção de configuração de servidor XPs do Agente
- Scripter de fim de semana: usar o Agendador de Tarefas do Windows para executar um Windows PowerShell script
Script de limpeza do WSUS
Observação
Ao executar o script no servidor WSUS, use LOCALHOST
em vez do .SERVERNAME
Além disso, substitua PORT
pelo usado.
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")`
| out-null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("SERVERNAME",$true,PORT);
$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 limpeza do WSUS no Agendador de Tarefas
Observação
Conforme mencionado anteriormente Configuration Manager, se você estiver usando um branch atual versão 1906 ou 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 autônomos do WSUS ou versões mais antigas do Configuration Manager, você pode continuar a usar as etapas a seguir.
A postagem no blog do Weekend Scripter mencionada na seção anterior contém instruções básicas e solução de problemas para esta etapa. No entanto, explicarei o processo nas etapas a seguir.
Abra o Agendador de Tarefas e selecione Criar uma Tarefa. Na guia Geral , defina 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.
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 desejamos que ele seja executado. Você pode usar o script de Limpeza do WSUS. Esse script executa opções de limpeza que Configuration Manager versão 1906 do branch atual não funciona. Você poderá desmenti-los se estiver usando o WSUS autônomo ou uma versão mais antiga do Configuration Manager. Se você quiser um log, poderá modificar a última linha do script da seguinte maneira:
Observação
Ao executar o script no servidor WSUS, use
LOCALHOST
em vez do .SERVERNAME
Além disso, substituaPORT
pelo usado.[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer("SERVERNAME",$true,PORT); $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ê receberá um FYI/aviso no Agendador de Tarefas ao salvar. Você pode ignorar esse aviso.
Na guia Gatilhos , defina sua agenda para uma vez por mês ou em qualquer agenda que desejar. Novamente, você deve garantir que não sincronize o WSUS durante todo o tempo de limpeza e reindexação.
Defina outras condições ou configurações que você também gostaria de ajustar. Ao salvar a tarefa, você pode ser solicitado a fornecer as credenciais do usuário Executar como .
Você também pode usar essas etapas para configurar o script Decline-SupersededUpdatesWithExclusionPeriod.ps1 para ser executado a cada três meses. Geralmente, defina esse script para ser executado antes das outras etapas de limpeza, mas somente depois de o executar manualmente e garantir que ele seja concluído com êxito. Eu vou às 00:00 no primeiro domingo a cada três meses.
Configurando a reindexação SUSDB para WID usando o SQLCMD e o Agendador de Tarefas
Salve o script reindexar o banco de dados do WSUS como um arquivo .sql (por exemplo, SUSDBMaint.sql).
Crie uma tarefa básica e dê a ela um nome:
Agende essa tarefa para iniciar cerca de 30 minutos depois que você espera que a limpeza termine de ser executada. Minha limpeza está sendo executada à 1:00 da manhã todo primeiro domingo. Leva cerca de 30 minutos para ser executado e eu vou dar-lhe mais 30 minutos antes de iniciar minha reindexação. Isso significa que eu agendaria essa tarefa para cada primeiro domingo às 2:00, conforme mostrado aqui:
Selecione a ação para iniciar um programa. Na caixa Programa/script , digite o comando a seguir. O arquivo especificado após o parâmetro
-i
é o caminho para o script SQL salvo na etapa 1. O arquivo especificado após o parâmetro-o
é onde você deseja que o log seja 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
Você receberá um aviso, semelhante ao que você recebeu ao criar a tarefa de limpeza. Selecione Sim para aceitar os argumentos e, em seguida, selecione Concluir para aplicar:
Você pode testar o script forçando-o a executar e examinando o log em caso de erros. Se você tiver problemas, o log informará o motivo. Normalmente, se falhar, a conta que executa a tarefa não terá as permissões apropriadas ou o serviço WID não será 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.
Abra SQL Server Management Studio e conecte-se à instância do WSUS. Expanda 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.
Selecione o subplano1 e verifique se a Caixa de Ferramentas está no contexto:
Arraste e solte a tarefa Executar Tarefa de Instrução T-SQL.
Clique com o botão direito do mouse em Windows.edb e selecione Propriedades. Copie e cole o script de reindexação do WSUS e clique em OK.
Agende essa tarefa para ser executada cerca de 30 minutos depois que você espera que a limpeza termine a execução. Minha limpeza está sendo executada à 1:00 da manhã todo primeiro domingo. Leva cerca de 30 minutos para ser executado, e vou dar a ele mais 30 minutos antes de começar a reindexar. Isso significa que eu agendaria essa tarefa para ser executada todo primeiro domingo às 2:00 da manhã.
Ao criar o plano de manutenção, considere adicionar um backup do SUSDB ao plano também. Eu geralmente faço backup primeiro, depois reindexo. Ele pode adicionar mais tempo ao agendamento.
Juntando as peças
Ao executá-lo em uma hierarquia, a execução de limpeza do WSUS deve ser feita na parte inferior da hierarquia para cima. No entanto, ao usar o script para recusar atualizações substituídas, a execução deve ser feita de cima para baixo. O declínio de atualizações substituídas é 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, é recomendável 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 do agendamento 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 com o tempo dos scripts de recusa. Se a Camada 2 se sobrepor à Camada3 por alguns minutos, isso não causará um problema porque minha sincronização não está agendada para ser executada.
A não sincronização impede que os declínios fluam acidentalmente para meus servidores WSUS de réplica de Camada3 da Camada 2. Eu me dei um tempo extra entre o declínio da Camada 3 e a limpeza da Camada 3, pois definitivamente quero garantir que o script de recusa seja concluído 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ção ao mesmo tempo?
A resposta é que você provavelmente poderia, mas eu não faria. Se meu colega de trabalho em todo o mundo precisar executar uma sincronização, com esse agendamento, minimizaria o risco de atualizações órfãs no WSUS. E eu posso agendar para executar novamente para a conclusão na noite seguinte.
Hora | Camada | Tarefas |
---|---|---|
12h00 | Tier1 -Decline | |
00:15 | Tier2 -Decline | |
00:30 | Tier3 -Decline | |
01:00:00 | Limpeza do WSUS da Camada3 | |
2h | Reindexação de Camada3 | Limpeza do WSUS da Camada 2 |
03h00 | Tier1-Cleanup | Reindexação de Camada 2 |
4:00 | Reindexação de Camada1 |
Observação
Se você estiver usando Configuration Manager versão 1906 ou posterior do branch atual para executar a Manutenção do WSUS, o Configuration Manager executará 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, porque Configuration Manager lidará com todo o resto.
Para obter mais informações sobre um namespace desarticulado, veja os seguintes artigos: