Existe um jeito arriscado de aplicar patches em apps de terceiros.
Abrir um terminal. Rodar tudo. Torcer para nada quebrar.
Isso nao e gerenciamento de patches. E aposta.
WinGet ajuda muito, mas dentro de uma operacao RMM ele ainda precisa de disciplina: inventario, mapeamento de catalogo, exclusoes, janelas de manutencao, evidencia de resultado e acompanhamento quando algo falha.
1) Separe patches de terceiros do Windows Update
Quando alguem busca gerenciamento de patches de terceiros, normalmente nao esta falando de Windows Update. Esta falando de Chrome, 7-Zip, Zoom, leitores PDF, runtimes, ferramentas remotas e outros aplicativos instalados fora do sistema operacional.
Esse fluxo precisa de mais controle do que um comando em massa. Mesmo que voce ja use Intune, SCCM ou outro console para patches do Windows, aplicativos externos ainda precisam de inventario confiavel, mapeamento de catalogo, exclusoes, janelas de manutencao e verificacao posterior.
A diferenca importante e esta: Windows Update cobre o sistema operacional e componentes relacionados. Um fluxo de apps de terceiros dentro de um RMM deve mostrar qual software existe, qual fornecedor pode atualiza-lo, em quais endpoints esta instalado e qual versao ficou depois.
Dica pratica: separe relatorios de sistema operacional e aplicativos de terceiros. Se misturar tudo, voce nao sabe se o dispositivo esta exposto por causa do Windows ou por causa de um app externo.
2) Comece pelo inventario, nao por winget upgrade --all
Antes de atualizar, voce precisa saber o que realmente existe.
Nao basta dizer "tem Chrome, 7-Zip, Zoom ou algum runtime instalado". Voce precisa de nome, versao, fabricante, dispositivo e contexto operacional. Sem isso, voce aplica patches no escuro.
A pergunta certa e:
quais apps de terceiros estao instalados, em qual versao e em quais endpoints?
WinGet pode ajudar a listar aplicativos instalados e mostrar atualizacoes disponiveis. Mas em operacao MSP isso nao basta: voce precisa relacionar esse dado com cliente, site, criticidade, usuario, janela de manutencao e risco.
Esse inventario e a ponte entre inventario de software e gerenciamento de patches. Sem essa ponte, o WinGet pode encontrar atualizacoes, mas sua operacao nao sabe qual importa primeiro.
Dica pratica: separe apps por impacto. Navegadores, leitores PDF, ferramentas remotas e runtimes comuns normalmente merecem mais atencao do que utilitarios pouco usados.
3) Mapeie contra o catalogo correto
WinGet trabalha com fontes de pacotes. A Microsoft documenta WinGet como ferramenta para descobrir, instalar, atualizar, remover e configurar aplicativos no Windows. A Microsoft tambem documenta que as fontes do WinGet devem ser seguras e confiaveis.
Isso importa porque o nome instalado no Windows nem sempre combina perfeitamente com o identificador do pacote.
Voce vai encontrar casos como:
- nome comercial diferente do package ID;
- apps instalados por MSI, EXE ou Microsoft Store;
- versoes reportadas de forma incompleta;
- pacotes que exigem aceite de acordos;
- apps fixados, bloqueados ou excluidos de atualizacao.
Um mapeamento serio guarda a relacao entre software detectado e pacote candidato. Nao deveria depender de "o nome parece parecido".
Dica pratica: use o ID exato do pacote sempre que puder, especialmente com filtros exatos. Se o match for ambiguo, deixe em revisao em vez de mandar para producao.
4) Defina exclusoes antes de automatizar
Nem toda atualizacao deve rodar automaticamente.
Apps de contabilidade, CAD, ERP, drivers, plugins ou ferramentas de negocio especializadas podem quebrar fluxos se a versao mudar sem validacao. Nesses casos, uma exclusao nao e preguica. E controle operacional.
WinGet tem mecanismos para limitar ou bloquear atualizacoes de pacotes com pins. Em um fluxo RMM, essa ideia deve virar politica visivel:
- apps permitidos para atualizacao automatica;
- apps que exigem piloto;
- apps bloqueados ate aprovacao;
- versoes maximas ou faixas aceitas;
- excecoes por cliente ou endpoint.
Dica pratica: antes da primeira janela ampla, documente uma lista de "nao mexer sem validar". Essa lista evita um problema criado pela propria operacao.
5) Teste antes de abrir a janela de manutencao
Uma atualizacao de terceiros pode falhar por permissao, instalador interativo, apps abertos, idioma, arquitetura, dependencias ou uma versao que nao substitui limpo.
Um fluxo saudavel:
1. Detecta apps instalados. 2. Mapeia o pacote WinGet. 3. Marca exclusoes e apps em revisao. 4. Testa em um grupo pequeno. 5. Revisa resultado, reinicios e erros. 6. Abre a janela de manutencao. 7. Verifica a versao final instalada.
O NIST trata gerenciamento de patches como manutencao preventiva, nao como reacao improvisada. Essa mentalidade encaixa bem aqui: primeiro planeja, depois executa, depois comprova.
Dica pratica: defina um grupo piloto por cliente ou por tipo de endpoint. Se algo falhar ali, ainda da tempo de ajustar antes de tocar a frota inteira.
6) Nao confunda "executado" com "resolvido"
O erro classico e fechar o trabalho quando o comando termina.
Mas um comando finalizado pode significar muita coisa:
- atualizou corretamente;
- nao encontrou o pacote;
- encontrou pacote ambiguo;
- pediu interacao;
- o instalador falhou;
- o app ja estava atualizado;
- precisa de reinicio;
- a versao instalada nao pode ser lida.
A verificacao posterior e onde o RMM ganha valor. Voce le o inventario de novo, compara versao esperada com versao real e separa endpoints atualizados dos pendentes.
Dica pratica: meca dois numeros separados: execucoes concluidas e endpoints realmente atualizados. Se voce medir so o primeiro, o relatorio pode ficar bonito enquanto a exposicao continua.
7) Conecte patches de terceiros com vulnerabilidades
Nem toda atualizacao pendente tem a mesma urgencia.
Se uma atualizacao corrige uma vulnerabilidade explorada ativamente, ela sobe de prioridade. Se e um ajuste menor em um app pouco usado, pode esperar a proxima janela.
Aqui o fluxo deve se conectar com a gestao de vulnerabilidades em RMM: inventario, CVEs, CISA KEV, EPSS, criticidade do endpoint e status de patch precisam conversar.
Tambem vale usar uma revisao semanal do console RMM para que pendencias nao sumam em uma lista eterna.
Dica pratica: crie tres filas: critico hoje, manutencao programada e acompanhamento. Isso evita que tudo pareca urgente enquanto o importante fica enterrado.
8) Como isso deveria aparecer dentro de um RMM
Um bom fluxo de patches de terceiros nao deveria obrigar voce a pular entre console, terminal, planilha e ticket.
Ele deveria responder rapido:
- quais apps tem atualizacao disponivel;
- qual pacote WinGet sera usado;
- quais endpoints serao alvo;
- qual exclusao ou pin se aplica;
- qual janela se aplica;
- o que falhou e por que;
- qual versao ficou instalada depois.
A meta nao e "rodar WinGet". A meta e controle operacional: saber o que mudou, onde mudou, o que ainda esta pendente e qual evidencia voce pode mostrar.
Para avaliar o fluxo completo, veja gerenciamento de patches, inventario, monitoramento de dispositivos e relatorios RMM.
Dica pratica: se voce nao consegue explicar quais endpoints foram atualizados e quais continuam pendentes, ainda nao tem gerenciamento de patches. Tem execucao remota com sorte.
