Pau pra toda obra: Aplicando patches em VMs inativas

Usar a Microsoft Offline Virtual Machine Servicing Tool para aplicar patches em VMs inativas é uma boa maneira de garantir que elas fiquem prontas para serem ativadas, além de evitar problemas com patches desatualizados.

Por Greg Shields

Você odeia os patches? Eu certamente sim. A aplicação de patches sempre me pareceu uma tarefa ingrata, que se torna ainda mais insignificante pelo fato de que não há nenhum valor comercial nela. Pelo menos, nenhum valor comercial a não ser o conhecimento de que você provavelmente está evitando alguma catástrofe desconhecida lá na frente.

Não, aplicar patches há muito passou a ser o trabalho braçal no mundo de TI. A principal fonte de noites em claro e trabalho depois do expediente, ligações para dizer "Sinto muito, querida, não vou conseguir chegar a tempo para o jantar", a aplicação de patches e o seu gerenciamento são atividades que todos nós amamos odiar.

Atualmente, no entanto, o gerenciamento de patches não anda tão ruim como antes. Não faz muito tempo, para manter os patches em ordem, era necessária uma planilha imensa, vinculando cada patch ao seu número “MS” e número “q” e ligando a importância na Microsoft com a nossa prioridade corporativa. Para manter o controle de quais patches substituíam outros, consumia-se pelo menos metade de um dia todos os meses.

Uma boa parte disso mudou com o lançamento do Windows Server Update Services (WSUS). Essa ferramenta de economia de tempo simples, mas fantástica, eliminou a maior parte do trabalho manual de aplicação de patches. Combinando o WSUS com um pequeno script, você pode até instruí-la a aplicar um patch a um computador imediatamente, sem aguardar até o próximo ciclo agendado. (Eu ainda tenho esse script. Visite concentratedtech.com se quiser obter uma cópia.)

A única limitação do WSUS é que seus mecanismos automatizados de aplicação de patches só funcionavam quando o servidor ou a área de trabalho que precisava do patch estava realmente ativa. Os computadores que, por algum motivo, precisavam estar desligados eram um problema para o WSUS. Era necessário um ciclo de patches imediatamente depois que o computador era ligado novamente na manhã seguinte, ou o trabalho extra do administrador para localizá-lo e ligá-lo na noite anterior.

Agora, todos nós sabemos que essa limitação do WSUS não é grande coisa. Se os usuários deixarem seus computadores desligados durante o ciclo de patches à noite, eles receberão um aviso em um balão na manhã seguinte, logo após ligarem o computador, e a instalação dos patches será iniciada. Mesmo hoje, os servidores geralmente ficam ligados o tempo todo. Isso significa que estão sempre ativos e disponíveis para receber instruções do seu superior de aplicação de patches: o WSUS.

Alterando a combinação

Este ambiente agradável e estático é alterado mais uma vez quando nossos data centers passam para a virtualização. Uma vez virtualizados, nossos servidores provavelmente ainda continuarão ligados constantemente. No entanto, esses servidores virtuais precisam vir de algum lugar. Para a maioria de nós, esse “lugar” é através da clonagem de um modelo de servidor.

Os modelos de servidor são ótimos, pois nos ajudam a fazer com que um novo servidor entre em operação rapidamente e fique online com o mínimo de esforço. Eles também asseguram que cada servidor inicie sua vida com a mesma configuração principal. Os modelos de servidor também têm seu lado negro. Embora esses computadores sejam excelentes para gerar um novo servidor, nossos modelos por si só não se destinam a ter vida própria.

Um modelo de servidor existe como um arquivo VHD em um compartilhamento de arquivo em algum lugar. Desligado, esse arquivo fica efetivamente inativo. Ele não é diferente de um arquivo do Word ou uma planilha do Excel realmente grande. Ativado, esse arquivo inativo se torna um servidor totalmente funcional, que pode processar cargas de trabalho regulares ou as cargas de trabalho desprezíveis dos malwares e outros exploradores atuais.

Resumindo, se esses modelos inativos não receberem os patches, eles poderão se tornar a fonte de um novo surto de malware — tudo porque simplesmente foram ligados.

Consegui sua atenção? Ótimo, pois esse é o tema central da Microsoft Offline Virtual Machine Servicing Tool, atualmente na versão 2.1. Esse acelerador de solução gratuito instala um conjunto de automações destinadas a manter os modelos de VM (máquina virtual), que de outra maneira estariam inativos, atualizados com o WSUS.

Figure 1 The three major components of offline VM servicing

Figura 1  Os três principais componentes da manutenção de VMs offline.

Para chegar à essência de como isso funciona, veja a Figura 1. Você pode ver como o servidor que hospeda o System Center Virtual Machine Manager (VMM) interage com um dos seus compartilhamentos de biblioteca, um host Hyper-V e o servidor de gerenciamento de atualizações de software. Esse servidor de gerenciamento de atualizações pode ser um servidor WSUS ou um servidor System Center Configuration Manager (SCCM) disponível. Para qualquer um deles, os processos são praticamente iguais.

A Offline VM Servicing Tool utiliza os chamados trabalhos de manutenção para gerenciar a implantação de atualizações em VMs na biblioteca do VMM. Esses trabalhos de manutenção são essencialmente tarefas tratadas pelo Agendador de Tarefas do Windows, que são iniciadas em horários predeterminados.

Quando um trabalho de manutenção está pronto para ser ativado, ele começa primeiro “acordando” a VM em seu local de modelo. O processo de acordar envolve a implantação da VM em um host Hyper-V e a sua ativação. Com a VM ativada, o Windows Update Agent (WUA) da VM configurado internamente é instruído para iniciar um ciclo de atualização de software.

A configuração do WUA da VM é definida da mesma maneira como você costuma defini-lo em todos os computadores. Pode ser por meio da aplicação de Diretiva de Grupo ou manualmente, com a configuração na VM. É necessário definir todas as configurações típicas do WSUS para que esse processo funcione, como o local do serviço de atualização, os grupos de computadores do WSUS, bem como outras características específicas definidas pela sua diretiva de segurança.

Após você ter atualizado com êxito a VM, o trabalho de manutenção a desliga e a retorna para a biblioteca. Esse processo automatizado garante que as VMs — e o resto da sua infraestrutura — sejam atualizadas com os patches corretos. A Offline VM Servicing Tool não adiciona nenhuma das suas próprias configurações de gerenciamento de atualizações, mas apoia-se nas configurações existentes que você já definiu para o WSUS ou o SCCM.

Na realidade, a instalação da Offline VM Servicing Tool requer algumas etapas que não serão imediatamente óbvias se você não tiver lido o guia do Solution Accelerator associado. Embora esteja na versão 2.1, essa ferramenta ainda parece uma versão inicial. A sua instalação requer um download de console do site da Microsoft. A sua execução requer uma etapa extra, que é baixar e copiar os binários do PSExec — psexec.exe e pdh.dll — para a pasta bin da ferramenta, encontrada em C:\Arquivos de Programas\Microsoft Offline Virtual Machine Servicing Tool\bin. Também requer que a diretiva de execução do Windows PowerShell seja configurada para RemoteSigned.

Figure 2  The Offline VM Servicing Tool console

Figura 2  O console da Offline VM Servicing Tool.

Uma vez instalado, esse console (mostrado na Figura 2) realmente só identifica grupos de máquinas virtuais para determinar quais computadores recebem patches, e quando. Ele também identifica trabalhos de manutenção, que contêm as características das tarefas de atualização. A ferramenta de manutenção também só funciona com as VMs contidas na Biblioteca do VMM. Isso significa que as VMs desligadas que já foram implantadas em um host Hyper-V não funcionarão com a ferramenta.

Ela funcionará com as VMs que não são especificamente modelos, como as VMs de espera ativas que estão prontas para ficar online após uma falha ou quando você precisar de servidores adicionais. Nesses casos, a ferramenta sugere usar uma NIC em servidores de espera ativos juntamente com a implantação em uma rede isolada. Isso ajuda a garantir que a espera ativa não se torne acidentalmente operacional quando você só pretende aplicar os patches atuais.

A Microsoft Offline Virtual Machine Servicing Tool pode não ser uma solução completa para todas as suas necessidades de aplicação de patches offline, mas seu preço acessível e seus recursos limitados ajudarão nas situações em que você só deseja manter algumas VMs inativas atualizadas. Considerando o trabalho necessário para fazer isso manualmente e o impacto de um patch faltando, dá para perceber a importância fundamental de controlar todas as suas VMs inativas, mas potencialmente perigosas.

Greg Shields

Greg Shields*, MVP, é parceiro da Concentrated Technology. Obtenha mais dicas e truques de Shields em ConcentratedTech.com.*

 

Conteúdo relacionado