WinGet su Windows Server 2025: Guida all'automazione e alla configurazione di PowerShell

1. Padroneggiare l'ambiente WinGet

Windows Server 2025 viene fornito con WinGet, ma padroneggiarlo significa comprenderne le interfacce e bloccarlo per l'uso aziendale. Tratteremo la verifica, la scelta cruciale tra la CLI e il modulo PowerShell e il controllo centralizzato con Criteri di gruppo.

Verifica e configurazione iniziali

A differenza delle versioni precedenti, Windows Server 2025 include WinGet pronto all'uso. Tuttavia, il primo passo è sempre la verifica. Utilizza questi comandi per verificare che WinGet funzioni e per ottenere un'istantanea della sua configurazione, utile per la risoluzione dei problemi.

# Check the installed version of the WinGet client
winget --version

# Display detailed information, including log locations and configured sources
winget --info
                    

In alcuni scenari di distribuzione automatizzata, il comando "winget" potrebbe non essere immediatamente disponibile. In tal caso, puoi attivarne manualmente la registrazione con il comando seguente in un prompt di PowerShell con privilegi elevati:

# Manually register the App Installer package family to make winget.exe available
Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
                    

Modulo CLI e PowerShell: una scelta strategica

La scelta dello strumento giusto per il lavoro è fondamentale. La CLI "winget.exe" è ottima per attività rapide e interattive, ma per qualsiasi automazione seria, il modulo PowerShell "Microsoft.WinGet.Client" è l'unica opzione affidabile.

Controllo centralizzato con criteri di gruppo

Per gli ambienti aziendali, la gestione centralizzata non è negoziabile. I modelli di criteri di gruppo di WinGet ti consentono di applicare sicurezza e configurazione all'intero parco server, trasformandolo in una piattaforma gestibile e sicura.

• Abilita le origini consentite del programma di installazione dell'app

  La politica di sicurezza più critica. Usalo per creare una whitelist di repository interni approvati, bloccando efficacemente l'accesso a tutte le fonti pubbliche e impedendo installazioni di software non controllate.

• Disabilita le origini predefinite e Microsoft Store

  Negli ambienti server, l'accesso agli archivi pubblici è spesso indesiderabile. Disabilita esplicitamente il repository della comunità `winget` predefinito e il sorgente `msstore` per rafforzare la sicurezza.

• Imposta l'intervallo di aggiornamento automatico della sorgente

  Controlla la frequenza con cui i client aggiornano la cache dei metadati del pacchetto. Negli ambienti di grandi dimensioni, l'aumento di questo intervallo rispetto ai 5 minuti predefiniti può ridurre significativamente il traffico di rete verso il repository interno.

2. Architettura di distribuzioni offline e air-gapped

Molti ambienti server hanno accesso limitato a Internet. WinGet fornisce un potente flusso di lavoro per questi scenari, da una semplice cache del programma di installazione a un repository REST privato completo di funzionalità. La scelta tra loro è una decisione architettonica fondamentale per qualsiasi ambiente offline.

Modelli di distribuzione offline

Livello 1: cache dei pacchetti locali

Utilizza `winget download` su una macchina di gestione temporanea per creare una condivisione di file di programmi di installazione. Funzionalità semplici da configurare ma limitate sui client offline.

Livello 2: origine REST privata

Ospita il tuo repository. Ciò fornisce funzionalità complete di "ricerca", "installazione" e "aggiornamento" per un'esperienza offline realmente gestita.

Scripting di installazioni offline

La modalità di installazione del software sul server offline dipende dal modello scelto. Un'origine REST privata consente comandi WinGet nativi ed eleganti, mentre una cache di file richiede più script manuali.

Da origine REST privata (consigliato)
Dalla cache dei file

Installa-da-REST-Source.ps1

# First, ensure the private source is added (typically done once via GPO or script)
# winget source add --name "InternalRepo" -a "https://internal-repo.corp.local/api"

# List of application IDs to install from the internal repository
$packagesToInstall = @("7zip.7zip", "Internal.App.LegacyWrapper")

foreach ($packageId in $packagesToInstall) {
    Write-Host "Installing package: $packageId from InternalRepo..."
    # Use standard winget install, but specify the internal source
    Install-WinGetPackage -Id $packageId -Source "InternalRepo" -AcceptPackageAgreements -Scope Machine
}
                            

Installa-da-file-Cache.ps1

$cachePath = "FileServer01WinGetCache"
$appsToInstall = @{ "Notepad++.Notepad++" = "Notepad++.Notepad++.8.6.5.exe" }

foreach ($app in $appsToInstall.GetEnumerator()) {
    $installerFile = Join-Path -Path $cachePath -ChildPath $app.Value
    if (Test-Path $installerFile) {
        # Silent switches vary by installer and must be known in advance
        $arguments = "/S" 
        Start-Process -FilePath $installerFile -ArgumentList $arguments -Wait
    }
}
                            

3. Automatizzazione del ciclo di vita del software

È qui che WinGet brilla. Esploreremo gli script idempotenti per le build di server di base, creeremo una soluzione di aggiornamento solida e intelligente e pianificheremo il tutto per la manutenzione non presidiata.

Flusso di lavoro di aggiornamento intelligente

1. Trova pacchetti

"Get-WinGetPackage".

→

2. Controlla gli aggiornamenti

`Where-Object { $_.IsUpdateAvailable }`

→

3. Filtra le esclusioni

`Where-Object { $_.Id -notin $exclusionList }`

→

4. Applica aggiornamento

"Aggiornamento-WinGetPackage".

Script interattivi di PowerShell

Filtra gli script seguenti per trovare l'automazione giusta per la tua attività. Fare clic su un pulsante per visualizzare lo snippet di codice pertinente.

Tutti gli script
Costruzione di base
Aggiornamenti automatici
Attività pianificata

Lettura consigliata:PowerShell Code Signing 2025: Guida a timestamp, CA e Set-AuthenticodeSignature

Install-Baseline.ps1

# Import the PowerShell module for robust automation
Import-Module Microsoft.WinGet.Client -ErrorAction SilentlyContinue

# Path to the CSV file defining the software baseline
$baselineFile = "C:ScriptsServerBaseline.csv"

if (-not (Test-Path $baselineFile)) {
    Write-Error "Baseline definition file not found at $baselineFile"
    return
}

# Import the list of applications from the CSV
$appsToInstall = Import-Csv -Path $baselineFile

# Loop through each application defined in the baseline
foreach ($app in $appsToInstall) {
    # Idempotency Check: Verify if the package is already installed
    $installedPackage = Get-WinGetPackage -Id $app.PackageId -ErrorAction SilentlyContinue
    if ($installedPackage) {
        Write-Host "$($app.PackageId) is already installed. Skipping." -ForegroundColor Yellow
        continue
    }

    # Install the package
    Install-WinGetPackage -Id $app.PackageId -Source $app.Source -Scope Machine -AcceptPackageAgreements
}
                            

Perform-WinGet-Updates.ps1

# Import the PowerShell module
Import-Module Microsoft.WinGet.Client -ErrorAction SilentlyContinue

# Define a list of package IDs to exclude from automatic updates
$exclusionList = @(
    "Oracle.MySQL",
    "Microsoft.DotNet.SDK.6"
)

# Find all installed packages that have an update available and are not in the exclusion list
$updatablePackages = Get-WinGetPackage | Where-Object { 
    $_.IsUpdateAvailable -and $_.Id -notin $exclusionList 
}

if ($updatablePackages) {
    # Loop through the filtered list and apply updates
    foreach ($package in $updatablePackages) {
        $package | Update-WinGetPackage -AcceptPackageAgreements -Scope Machine
    }
}
                            

Crea-Aggiornamento-Task.ps1

# --- Task Configuration ---
$taskName = "Weekly WinGet Application Update"
$scriptPath = "C:ScriptsPerform-WinGet-Updates.ps1"
$principal = "NT AUTHORITYSYSTEM"

# --- Create the Task Action ---
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$scriptPath`""

# --- Create the Task Trigger ---
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 3am

# --- Create the Task Principal ---
$taskPrincipal = New-ScheduledTaskPrincipal -UserId $principal -LogonType ServiceAccount -RunLevel Highest

# --- Register the Scheduled Task ---
Register-ScheduledTask -TaskName $taskName `
    -Action $action `
    -Trigger $trigger `
    -Principal $taskPrincipal
                            

4. Il futuro: configurazione dichiarativa con `winget configure`

Andare oltre gli script imperativi verso un modello dichiarativo. Definisci lo *stato desiderato* del tuo server in un file YAML e lascia che WinGet e PowerShell DSC gestiscano il resto. Questa è l'essenza dell'Infrastructure as Code (IaC).

Flusso di configurazione dichiarativa

1. Definisci lo stato in YAML

`configuration.dsc.yaml`

→

2. Eseguire `winget configure`

Esecuzione di un singolo comando

→

3. Il sistema è conforme

Idempotente e ripetibile

Esempio: `configuration.dsc.yaml`

Questo file YAML definisce lo stato desiderato per un server web. Afferma la versione del sistema operativo, garantisce che siano installati pacchetti WinGet specifici e abilita la funzionalità Windows IIS utilizzando PowerShell DSC. Applicarlo è semplice come eseguire `winget configure -f C:PathToFile.yaml`.

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
properties:
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      directives:
        description: Install Microsoft PowerShell 7.
      settings:
        id: Microsoft.PowerShell
        source: winget
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      directives:
        description: Install Visual Studio Code.
      settings:
        id: Microsoft.VisualStudioCode
        source: winget
    - resource: PSDscResources/WindowsFeature
      directives:
        description: Ensure the IIS Web Server role is installed.
      settings:
        Name: Web-Server
        Ensure: Present
configurationVersion: 0.2.0
                    

5. Registrazione avanzata e risoluzione dei problemi

In un ambiente aziendale, una registrazione affidabile e un'efficace risoluzione dei problemi sono essenziali per la sicurezza, la conformità e la stabilità operativa. WinGet fornisce un framework di registrazione completo che consente il passaggio dalla risoluzione reattiva dei problemi alla risoluzione proattiva e automatizzata.

Decodifica dei log diagnostici

WinGet crea un file di registro dettagliato per ogni operazione, che è la tua principale fonte di verità per diagnosticare gli errori. Puoi aprire rapidamente la directory dei log dopo qualsiasi comando aggiungendo l'opzione `–logs`.

# Run an installation and immediately open the log directory to view the results.
winget install Microsoft.VisualStudioCode --logs --accept-package-agreements

# For deeper issues, enable verbose logging to see every detail.
winget install Microsoft.PowerShell --verbose-logs --accept-package-agreements
                    

Gestione degli errori programmatici

Il vero potere dell'automazione risiede nella gestione degli errori in fase di runtime. Il modulo PowerShell restituisce oggetti con codici di stato e di errore, consentendo agli script di reagire in modo intelligente a specifiche condizioni di errore, una capacità impossibile con la semplice analisi del testo.

$installResult = Install-WinGetPackage -Id "Some.App" -ErrorAction SilentlyContinue

if ($installResult.Status -ne 'Ok') {
    $errorCode = $installResult.InstallerErrorCode
    Write-Warning "Install failed with code: $errorCode"
    
    # React to specific, known error codes
    switch ($errorCode) {
        # Reboot required
        3010 { Write-Host "Flagging system for a required reboot." }
        # Another install is running
        1618 { 
            Write-Host "Another installation is in progress. Retrying in 5 minutes."
            Start-Sleep -Seconds 300
            # Add retry logic here
        }
        default { Write-Error "Unhandled error. Alerting administrators." }
    }
}
                    

Raccolta di registri centralizzata

Il controllo manuale dei log sui singoli server non è scalabile. Un'attività pianificata su ciascun server può eseguire uno script per raccogliere i registri WinGet recenti e copiarli in una condivisione file centrale per un controllo semplificato e un'analisi a livello di flotta.

# Script to be run as a scheduled task on each server
$centralLogShare = "LogServer01WinGetLogs"
$serverName = $env:COMPUTERNAME
$destinationPath = Join-Path -Path $centralLogShare -ChildPath $serverName

# Find the WinGet log directory dynamically
$logDirectory = (winget --info | Select-String -Pattern "Logs").ToString().Split(' : ')[1].Trim()

# Find logs from the last 24 hours and copy them to the central share
Get-ChildItem -Path $logDirectory -Filter "*.log" | 
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-1) } |
    Copy-Item -Destination $destinationPath -Force
                    

6. Conclusione: una strategia di gestione olistica

L'integrazione di WinGet in Windows Server 2025 rappresenta uno sviluppo trasformativo. Per padroneggiarlo è necessario un approccio strategico basato sulle migliori pratiche di automazione, sicurezza e resilienza operativa. Un'implementazione di successo dipende dalla standardizzazione del modulo PowerShell per l'automazione, dall'utilizzo di Criteri di gruppo per la sicurezza, dall'implementazione di una strategia offline a più livelli e dalla creazione di script intelligenti e idempotenti.

In definitiva, questo framework di automazione basato su WinGet non è una soluzione isolata. È un potente motore che può essere integrato in una strategia di gestione dei server più ampia, tramite Azure Arc, Microsoft Configuration Manager (SCCM) o strumenti RMM di terze parti. Adottando questi strumenti, gli amministratori possono ridurre significativamente il lavoro manuale, migliorare il proprio livello di sicurezza e creare un'infrastruttura server più resiliente, coerente e preparata per le sfide del futuro.