Área de tecnologia principal: Windows Server
Áreas de tecnologia adicionais: Datacenter
Dados do autor: https://linktr.ee/edupopov

Introdução

A administração de servidores Windows tradicionalmente exige que os profissionais de infraestrutura localizem instaladores, validem versões, identifiquem parâmetros de instalação silenciosa e desenvolvam métodos próprios para atualizar aplicações. Embora ferramentas corporativas como o Microsoft Configuration Manager permitam centralizar esse processo, a preparação dos pacotes continua demandando planejamento, testes e manutenção constante.

Com o Windows Server 2025, a Microsoft passou a incluir nativamente o Windows Package Manager, acessado pela ferramenta de linha de comando winget. Essa mudança aproxima a administração do Windows Server de modelos de gerenciamento de software há muito utilizados em sistemas Linux, nos quais aplicações podem ser localizadas, instaladas, atualizadas e removidas diretamente por meio de um gerenciador de pacotes.

No Windows Server 2025, o WinGet está disponível por padrão nas instalações com Desktop Experience. O recurso não está disponível nativamente no Windows Server 2022 e em versões anteriores, nem deve ser considerado uma solução padrão para instalações Server Core.

A presença do WinGet no sistema operacional não elimina a necessidade de plataformas como o Configuration Manager. Na prática, ele acrescenta uma nova camada de automação que pode ser utilizada por scripts, tarefas agendadas, pipelines de implantação e ferramentas de gerenciamento corporativo.

O que é um gerenciador de pacotes?

Um gerenciador de pacotes é uma solução responsável por organizar o ciclo de vida de aplicações instaladas em um sistema operacional. Em vez de o administrador acessar manualmente o site de cada fabricante, baixar um instalador e executar parâmetros específicos, o gerenciador utiliza informações previamente estruturadas para localizar e processar o software.

No Windows Package Manager, essas informações são armazenadas em manifestos. Um manifesto descreve elementos como:

nome e identificação do aplicativo;
fabricante;
versão disponível;
arquitetura suportada;
endereço do instalador;
hash de integridade;
tipo de instalador;
parâmetros de instalação silenciosa;
requisitos e dependências.

O WinGet atua como cliente do Windows Package Manager. Por meio dele, o administrador pode pesquisar, instalar, listar, atualizar, reparar, remover, importar e exportar aplicações. A ferramenta suporta diferentes formatos de instaladores, incluindo MSI, EXE, MSIX, APPX, ZIP, Inno Setup, Nullsoft e WiX.

Essa abordagem reduz a dependência de procedimentos manuais, mas não elimina a responsabilidade administrativa. Antes de utilizar um pacote em produção, a organização ainda deve avaliar o fabricante, a origem, o comportamento do instalador, os impactos da nova versão e a compatibilidade com os serviços executados no servidor.

A importância do WinGet no Windows Server 2025

Servidores também utilizam aplicações que não fazem parte diretamente do sistema operacional. Entre os exemplos estão agentes de monitoramento, ferramentas de compactação, módulos administrativos, componentes de linha de comando, runtimes, clientes de banco de dados e utilitários de diagnóstico.

Sem um mecanismo padronizado, cada aplicativo pode exigir um processo diferente de atualização. Um fabricante distribui um arquivo MSI, outro utiliza um instalador EXE e um terceiro publica uma versão compactada. Essa diversidade dificulta a criação de um modelo uniforme de manutenção.

O WinGet oferece uma interface comum para trabalhar com esses diferentes formatos. O comando utilizado pelo administrador permanece praticamente o mesmo, enquanto o manifesto do pacote informa ao Windows Package Manager como o instalador deve ser processado.

Isso permite que o Windows Server 2025 seja integrado a processos de automação mais amplos, como:

instalação inicial de ferramentas administrativas;
preparação de servidores de laboratório;
atualização controlada de aplicações;
criação de imagens de referência;
padronização de servidores com a mesma função;
execução de scripts pelo Configuration Manager;
validação periódica de versões instaladas;
recuperação de ambientes de teste.

Essa capacidade é particularmente relevante em organizações que precisam manter dezenas ou centenas de servidores com conjuntos semelhantes de ferramentas.

Comandos fundamentais do WinGet

A primeira validação deve confirmar se o WinGet está disponível:

winget --version

Para visualizar informações sobre a instalação, os diretórios de log e as políticas aplicadas:

winget --info

Para consultar as fontes configuradas:

winget source list

A pesquisa de um aplicativo pode ser realizada pelo nome:

winget search PowerShell

Entretanto, em scripts corporativos, é mais seguro utilizar o identificador exato do pacote:

winget search --id Microsoft.PowerShell --exact

A instalação do PowerShell pode ser realizada da seguinte maneira:

winget install `
    --id Microsoft.PowerShell `
    --exact `
    --source winget `
    --scope machine `
    --silent `
    --accept-source-agreements `
    --accept-package-agreements `
    --disable-interactivity

O uso de --id e --exact reduz o risco de o WinGet selecionar um pacote com nome semelhante. Os parâmetros de aceitação de contratos e desativação da interatividade são importantes em execuções automatizadas, nas quais não existe um usuário disponível para responder às perguntas do instalador.

Para visualizar aplicações que possuem atualizações disponíveis:

winget list --upgrade-available

Para atualizar uma aplicação específica:

winget upgrade `
    --id Microsoft.PowerShell `
    --exact `
    --source winget `
    --scope machine `
    --silent `
    --accept-source-agreements `
    --accept-package-agreements `
    --disable-interactivity

Também é possível atualizar todas as aplicações reconhecidas:

winget upgrade --all

Embora seja conveniente, o comando upgrade --all não deve ser aplicado indiscriminadamente em servidores de produção. Uma atualização coletiva pode modificar diferentes aplicações na mesma janela, dificultar a análise de falhas e provocar impactos simultâneos em serviços distintos. O comando é mais apropriado para laboratórios, estações administrativas ou ambientes previamente avaliados. A documentação do WinGet recomenda executar inicialmente winget upgrade sem argumentos para revisar quais aplicações serão alteradas.

Script para atualização controlada de aplicações

O exemplo a seguir recebe o identificador de um pacote e solicita sua atualização. O script procura o executável do WinGet mesmo quando a execução ocorre em contexto de sistema, situação comum no Configuration Manager e no Microsoft Intune.

param(
    [Parameter(Mandatory = $true)]
    [string]$PackageId,

    [ValidateSet("machine", "user")]
    [string]$Scope = "machine"
)

$ErrorActionPreference = "Stop"

$LogDirectory = "C:\ProgramData\Empresa\Logs"
$LogFile = Join-Path $LogDirectory "WinGet-Update.log"

if (-not (Test-Path $LogDirectory)) {
    New-Item -Path $LogDirectory -ItemType Directory -Force | Out-Null
}

function Write-Log {
    param(
        [string]$Message
    )

    $Date = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    Add-Content -Path $LogFile -Value "$Date - $Message"
}

function Get-WinGetPath {

    $Command = Get-Command "winget.exe" -ErrorAction SilentlyContinue

    if ($Command) {
        return $Command.Source
    }

    $AppInstaller = Get-AppxPackage `
        -AllUsers `
        -Name "Microsoft.DesktopAppInstaller" |
        Sort-Object { [version]$_.Version } -Descending |
        Select-Object -First 1

    if ($AppInstaller) {

        $Candidate = Join-Path $AppInstaller.InstallLocation "winget.exe"

        if (Test-Path $Candidate) {
            return $Candidate
        }
    }

    throw "O executável winget.exe não foi localizado."
}

try {

    $WinGetPath = Get-WinGetPath

    Write-Log "Iniciando atualização do pacote $PackageId."
    Write-Log "Executável utilizado: $WinGetPath"

    $Arguments = @(
        "upgrade"
        "--id", $PackageId
        "--exact"
        "--source", "winget"
        "--scope", $Scope
        "--silent"
        "--accept-source-agreements"
        "--accept-package-agreements"
        "--disable-interactivity"
    )

    $Result = & $WinGetPath @Arguments 2>&1
    $ExitCode = $LASTEXITCODE

    $Result | ForEach-Object {
        Write-Log $_
    }

    if ($ExitCode -ne 0) {
        throw "O WinGet retornou o código de saída $ExitCode."
    }

    Write-Log "Processo concluído para o pacote $PackageId."
    exit 0
}
catch {

    Write-Log "Falha: $($_.Exception.Message)"
    exit 1
}

A execução para atualização do PowerShell seria:

.\Atualizar-AplicativoWinGet.ps1 `
    -PackageId "Microsoft.PowerShell"

Em um ambiente corporativo, recomenda-se manter uma lista explícita de identificadores aprovados. Essa prática impede que um administrador ou processo automatizado atualize aplicações que ainda não passaram por homologação.

Utilização com o Microsoft Configuration Manager

O Microsoft Configuration Manager, ainda frequentemente chamado de SCCM, continua sendo uma das soluções mais adequadas para gerenciamento de servidores Windows em ambientes locais.

O Windows Server 2025 é suportado como sistema operacional cliente a partir do Configuration Manager versão 2409. O suporte abrange as edições Standard, Datacenter, Datacenter: Azure Edition e Server Core, embora o Software Center não seja suportado nas instalações Server Core.

A integração entre WinGet e Configuration Manager pode seguir dois modelos principais.

Modelo de atualização direta

Nesse modelo, o Configuration Manager distribui apenas o script PowerShell. Quando executado, o script solicita que o WinGet consulte a fonte configurada e obtenha o instalador diretamente.

A linha de instalação do tipo de implantação pode ser:

powershell.exe -NoProfile `
    -ExecutionPolicy Bypass `
    -File ".\Atualizar-AplicativoWinGet.ps1" `
    -PackageId "Microsoft.PowerShell"

Esse modelo reduz a necessidade de armazenar cada instalador nos pontos de distribuição, mas cria dependência de conectividade externa, proxy, disponibilidade da fonte e comportamento do instalador publicado.

Ele é mais apropriado para:

laboratórios;
servidores de desenvolvimento;
ferramentas de baixo impacto;
aplicações que não exigem uma versão rigidamente controlada;
ambientes com acesso autorizado às fontes do WinGet.

Modelo com conteúdo controlado

Em servidores de produção, pode ser preferível utilizar o WinGet apenas para localizar e baixar o instalador. Depois disso, o arquivo é armazenado na biblioteca de conteúdo do Configuration Manager e distribuído pelos pontos de distribuição.

Exemplo:

winget download `
    --id Microsoft.PowerShell `
    --exact `
    --source winget `
    --architecture x64 `
    --installer-type wix `
    --download-directory "D:\SCCMSource\PowerShell" `
    --accept-source-agreements `
    --accept-package-agreements

O Configuration Manager passa a controlar o conteúdo, a versão, os limites de rede, as janelas de manutenção e o processo de implantação. A documentação do PowerShell considera o MSI uma alternativa adequada para servidores e cenários corporativos, especialmente quando é necessário integrar a instalação com WSUS, Microsoft Update ou Configuration Manager.

Esse modelo oferece maior previsibilidade porque a aplicação testada é exatamente a mesma que será distribuída aos servidores.

Método de detecção no Configuration Manager

No modelo de aplicações do Configuration Manager, o método de detecção deve verificar se a versão desejada está instalada.

O exemplo abaixo pesquisa o PowerShell nas áreas de desinstalação do Registro:

$MinimumVersion = [version]"7.6.0"

$RegistryPaths = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*"
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
)

$Application = Get-ItemProperty `
    -Path $RegistryPaths `
    -ErrorAction SilentlyContinue |
    Where-Object {
        $_.DisplayName -like "PowerShell 7*"
    } |
    Sort-Object {
        try {
            [version](($_.DisplayVersion -replace "[^\d\.].*$", ""))
        }
        catch {
            [version]"0.0"
        }
    } -Descending |
    Select-Object -First 1

if ($Application) {

    try {
        $InstalledVersion = [version](
            $Application.DisplayVersion -replace "[^\d\.].*$", ""
        )

        if ($InstalledVersion -ge $MinimumVersion) {
            Write-Output "Aplicação detectada."
        }
    }
    catch {
        # Não produz saída quando a versão não pode ser validada.
    }
}

exit 0

Nos métodos personalizados de detecção do Configuration Manager, a existência de uma saída no fluxo padrão indica que a aplicação foi detectada. Quando a condição não for atendida, o script deve encerrar sem produzir texto.

A versão mínima deve ser alterada a cada nova revisão aprovada. Dessa forma, o Configuration Manager consegue identificar quais servidores ainda precisam receber a atualização.

Execução como script administrativo pelo Configuration Manager

Outra possibilidade consiste em utilizar o recurso Run Scripts para executar a atualização em uma coleção de dispositivos.

Nesse cenário, o administrador pode:

criar uma coleção piloto;
executar o script somente nessa coleção;
revisar os códigos de saída;
validar os serviços afetados;
ampliar gradualmente a execução;
aplicar o script na coleção de produção.

O Configuration Manager permite executar scripts PowerShell diretamente em coleções de dispositivos, inclusive por meio dos cmdlets Invoke-CMScript e Get-CMCollection.

Essa abordagem é útil para uma atualização emergencial, mas não substitui o modelo de aplicação quando a organização precisa de detecção permanente, histórico de conformidade e reinstalação automática.

Utilização com o Microsoft Intune

O Microsoft Intune deve ser contextualizado de forma diferente. As plataformas Windows diretamente suportadas para gerenciamento incluem principalmente as edições do Windows 11 e dispositivos Windows 365. O Windows Server não aparece na relação de sistemas Windows com suporte para inscrição e gerenciamento MDM pelo Intune. Portanto, o exemplo desta seção deve ser aplicado às estações Windows 10 ou Windows 11 que fazem parte do mesmo ambiente corporativo, e não diretamente aos servidores Windows Server 2025.

Em um modelo híbrido, a organização pode utilizar:

Configuration Manager para o Windows Server 2025;
Intune para notebooks e estações Windows 11;
WinGet como interface de automação comum;
grupos de homologação separados para servidores e endpoints.

Para aplicações Win32, o Intune também oferece mecanismos nativos de substituição de versões por meio de Supersedence. Aplicações obtidas pelo Microsoft Store podem ser mantidas atualizadas automaticamente, enquanto o Enterprise App Catalog possui seu próprio mecanismo de distribuição pela Intune Management Extension e não utiliza diretamente o WinGet.

Ainda assim, o WinGet pode ser utilizado em scripts de Remediações quando a organização precisa controlar aplicações que não estão adequadamente representadas nos modelos nativos.

Script de detecção para Remediações do Intune

O script de detecção verifica se existe uma atualização disponível para um pacote específico.

$PackageId = "Microsoft.PowerShell"

function Get-WinGetPath {

    $Command = Get-Command "winget.exe" -ErrorAction SilentlyContinue

    if ($Command) {
        return $Command.Source
    }

    $AppInstaller = Get-AppxPackage `
        -AllUsers `
        -Name "Microsoft.DesktopAppInstaller" |
        Sort-Object { [version]$_.Version } -Descending |
        Select-Object -First 1

    if ($AppInstaller) {

        $Candidate = Join-Path $AppInstaller.InstallLocation "winget.exe"

        if (Test-Path $Candidate) {
            return $Candidate
        }
    }

    return $null
}

$WinGetPath = Get-WinGetPath

if (-not $WinGetPath) {
    Write-Output "WinGet não localizado."
    exit 1
}

$Result = & $WinGetPath `
    list `
    --id $PackageId `
    --exact `
    --upgrade-available `
    --accept-source-agreements `
    --disable-interactivity 2>&1 |
    Out-String

if ($Result -match [regex]::Escape($PackageId)) {
    Write-Output "Atualização disponível para $PackageId."
    exit 1
}

Write-Output "Nenhuma atualização necessária."
exit 0

Nas Remediações do Intune, o script corretivo somente é executado quando o script de detecção retorna exit 1. Os scripts devem ser armazenados em UTF-8, e a Microsoft recomenda que comandos de reinicialização não sejam incorporados diretamente aos scripts de detecção ou correção.

Script de correção para Remediações do Intune

$PackageId = "Microsoft.PowerShell"

function Get-WinGetPath {

    $Command = Get-Command "winget.exe" -ErrorAction SilentlyContinue

    if ($Command) {
        return $Command.Source
    }

    $AppInstaller = Get-AppxPackage `
        -AllUsers `
        -Name "Microsoft.DesktopAppInstaller" |
        Sort-Object { [version]$_.Version } -Descending |
        Select-Object -First 1

    if ($AppInstaller) {

        $Candidate = Join-Path $AppInstaller.InstallLocation "winget.exe"

        if (Test-Path $Candidate) {
            return $Candidate
        }
    }

    throw "WinGet não localizado."
}

try {

    $WinGetPath = Get-WinGetPath

    $Result = & $WinGetPath `
        upgrade `
        --id $PackageId `
        --exact `
        --source winget `
        --scope machine `
        --silent `
        --accept-source-agreements `
        --accept-package-agreements `
        --disable-interactivity 2>&1

    $ExitCode = $LASTEXITCODE

    $Result | ForEach-Object {
        Write-Output $_
    }

    if ($ExitCode -ne 0) {
        throw "O WinGet retornou o código $ExitCode."
    }

    Write-Output "Atualização concluída."
    exit 0
}
catch {

    Write-Output "Falha na atualização: $($_.Exception.Message)"
    exit 1
}

No Intune, o pacote pode ser configurado para executar semanalmente ou em outro intervalo compatível com a política de manutenção da empresa. Aplicações críticas devem ser direcionadas inicialmente a grupos de teste.

Segurança e governança

A facilidade de instalação não deve transformar o WinGet em um mecanismo irrestrito dentro da organização. Um gerenciador de pacotes amplia a capacidade de automação, mas também exige regras de governança.

Utilizar identificadores exatos

Scripts devem empregar --id e --exact. Pesquisas baseadas somente no nome podem retornar diferentes aplicações ou fabricantes.

Manter uma lista de aplicações autorizadas

A organização deve definir quais pacotes podem ser instalados ou atualizados. A aprovação pode considerar:

criticidade do servidor;
reputação do fabricante;
licenciamento;
necessidade operacional;
impacto sobre serviços;
dependências;
necessidade de reinicialização;
compatibilidade com soluções de segurança.

Não ignorar a validação de hash

O parâmetro --ignore-security-hash não deve ser adotado para contornar falhas. Uma divergência de hash pode indicar que o instalador foi alterado, substituído ou publicado incorretamente.

Utilizar anéis de implantação

Uma estratégia recomendada é dividir os dispositivos em grupos:

laboratório;
equipe de tecnologia;
homologação;
produção não crítica;
produção crítica.

O mesmo conceito pode ser implementado com coleções no Configuration Manager e grupos do Microsoft Entra ID no Intune.

Controlar versões com pinning

O comando winget pin permite limitar a atualização de um pacote ou impedir que ele seja atualizado pelo WinGet. Esse recurso pode ser útil quando uma aplicação precisa permanecer temporariamente em uma versão homologada. O bloqueio realizado pelo WinGet, entretanto, não impede que o próprio aplicativo ou outra ferramenta de gerenciamento faça a atualização.

Gerenciar fontes

Organizações que não desejam permitir acesso irrestrito ao repositório comunitário podem controlar as fontes por Política de Grupo, restringir a inclusão de novos repositórios ou implementar uma fonte privada baseada em REST.

A Microsoft disponibiliza modelos administrativos ADMX e ADML específicos para o Windows Package Manager. Eles podem ser adicionados ao repositório central de políticas do Active Directory para controlar o comportamento do WinGet nos dispositivos do domínio.

Manter registros de execução

O WinGet produz logs próprios, e o diretório pode ser localizado com:

winget --info

Também é possível habilitar informações mais detalhadas com:

winget upgrade `
    --id Microsoft.PowerShell `
    --exact `
    --verbose-logs

Os logs auxiliam na identificação de problemas relacionados a fontes, CDN, argumentos, instaladores e códigos de saída.

A trilha do Microsoft Learn

Para profissionais que desejam compreender o funcionamento da solução antes de utilizá-la em produção, a Microsoft disponibiliza o módulo Explorar a ferramenta Gerenciador de Pacotes do Windows.

O conteúdo é classificado como introdutório e possui dez unidades. Entre os assuntos apresentados estão:

finalidade do Windows Package Manager;
instalação e remoção de aplicações;
atualização de software;
funcionamento do repositório;
contribuição de novos pacotes;
criação de repositórios privados;
controle do WinGet por Política de Grupo;
avaliação de conhecimentos.

Ao concluir o módulo, o profissional deve ser capaz de utilizar o Windows Package Manager para instalar, remover e atualizar aplicações, avaliar a utilização de fontes comunitárias ou privadas e controlar a ferramenta dentro de uma organização.

A trilha é especialmente relevante para administradores de servidores, profissionais de suporte, engenheiros de redes, arquitetos de soluções e equipes responsáveis pela gestão de endpoints.

URL: Explorar a ferramenta Gerenciador de Pacotes do Windows - Training | Microsoft Learn

Considerações finais

A inclusão do WinGet no Windows Server 2025 representa uma evolução no gerenciamento de aplicações no ecossistema Windows. A ferramenta oferece uma interface padronizada para operações que anteriormente dependiam de processos manuais e instaladores com comportamentos distintos.

Entretanto, seu maior valor não está apenas na possibilidade de executar um comando de instalação. O benefício mais significativo surge quando o WinGet é incorporado a processos controlados de automação, homologação e conformidade.

No Windows Server 2025, o Configuration Manager pode utilizar o WinGet para executar atualizações específicas ou auxiliar na obtenção de instaladores. Nos endpoints Windows 11, o Microsoft Intune pode utilizar Remediações, aplicações Win32, Microsoft Store ou recursos do Enterprise App Management, conforme o nível de controle necessário.

O WinGet não substitui essas plataformas. Ele funciona como uma camada adicional de automação que pode simplificar a administração, reduzir tarefas repetitivas e ampliar a padronização do ambiente.

Sua adoção deve ser acompanhada por políticas de segurança, listas de aplicações autorizadas, grupos de homologação, controle de versões, registros de execução e procedimentos de reversão. Quando implementado dessa forma, o Windows Package Manager torna-se um componente relevante para a modernização da administração do Windows Server 2025.

Eduardo Popovici

Gerenciador de Pacotes do Windows no Windows Server 2025: automação de aplicações com WinGet, Configuration Manager e Microsoft Intune