Windows Server 2025 / Gérer les erreurs PowerShell et journaliser les exécutions

Une commande exécutée n'est pas nécessairement une tâche administrative réussie. Les blocs PowerShell try, catch, finally, la gestion explicite des erreurs et les journaux par exécution aident à identifier les échecs et montrent quand seule une partie d'une tâche a été terminée.

Rendez les échecs visibles

Cet exercice lit un fichier sans modifier les rôles du serveur. Un véritable script d'installation ou de gestion des comptes doit également enregistrer les modifications laissées par un échec intermédiaire. Entrer dans le bloc catch n'annule pas automatiquement les actions précédentes.

Certaines erreurs PowerShell permettent la poursuite de l'exécution. Mettre simplement une commande dans un try ne rend pas chaque erreur interceptable ; l'option -ErrorAction Stop transforme les erreurs prises en charge en erreurs avec arrêt que catch peut intercepter. Consultez la gestion des erreurs PowerShell pour la distinction.

Préparez un fichier d'entrée et le script complet

Créez d’abord le dossier C:\LabScripts s’il n’existe pas, puis le fichier C:\LabScripts\input.txt contenant une ligne. Enregistrez le code complet ci-dessous sous Read-LabFile.ps1 dans le même dossier en utilisant UTF-8. L'exemple Windows PowerShell 5.1 lit les fichiers et écrit des journaux ; il ne modifie pas les services du serveur ni le réseau.

param(
    [Parameter(Mandatory=$true)]
    [string]$InputPath
)
$logDirectory = 'C:\LabLogs'
New-Item -ItemType Directory -Path $logDirectory -Force -ErrorAction Stop | Out-Null
$runLabel = (Get-Date -Format 'yyyyMMdd-HHmmss') + '-' + ([guid]::NewGuid().ToString('N').Substring(0,6))
$logPath = Join-Path $logDirectory ($runLabel + '.json')
$result = [ordered]@{
    StartedAt = (Get-Date).ToString('o')
    ComputerName = $env:COMPUTERNAME
    InputPath = $InputPath
    Success = $false
    LineCount = $null
    ErrorId = $null
    ErrorMessage = $null
}
$exitStatus = 0
try {
    $lines = @(Get-Content -LiteralPath $InputPath -ErrorAction Stop)
    $result.LineCount = $lines.Count
    $result.Success = $true
}
catch {
    $result.ErrorId = $_.FullyQualifiedErrorId
    $result.ErrorMessage = $_.Exception.Message
    $exitStatus = 1
    Write-Warning $result.ErrorMessage
}
finally {
    $result.FinishedAt = (Get-Date).ToString('o')
    $result | ConvertTo-Json | Set-Content -LiteralPath $logPath -Encoding UTF8 -ErrorAction Stop
}
Write-Output $logPath
exit $exitStatus

Comparez le succès et l'échec dans les mêmes conditions

La première invocation lit le fichier existant. La deuxième utilise missing-input.txt, qui doit réellement être absent. Vous n'avez pas besoin de supprimer le fichier d'entrée ni de modifier un fichier système pour provoquer un échec :

powershell.exe -NoProfile -File 'C:\LabScripts\Read-LabFile.ps1' -InputPath 'C:\LabScripts\input.txt'
$LASTEXITCODE
powershell.exe -NoProfile -File 'C:\LabScripts\Read-LabFile.ps1' -InputPath 'C:\LabScripts\missing-input.txt'
$LASTEXITCODE

Inspectez immédiatement chaque code de sortie. Le cas de succès attendu retourne 0 avec Success=true. Le fichier manquant retourne 1 avec Success=false et les détails de l'erreur. Chaque invocation crée un journal distinct au format JSON (JavaScript Object Notation, un format de données structurées) ; ouvrez les chemins signalés et comparez InputPath et ErrorId.

Si la politique du script bloque l'exécution, suivez la politique et les exigences de signature de l’organisation plutôt que d’affaiblir les paramètres globaux pour cet exemple.

Comprenez chaque section de gestion des erreurs

La référence try, catch et finally de Microsoft explique la gestion des erreurs de terminaison. Un bloc finally ne peut pas garantir un disque de journalisation inscriptible. Une erreur de création du dossier avant le bloc try peut aussi arrêter le script avant que finally puisse s’exécuter. Le stockage complet ou l'accès refusé peut toujours empêcher la sauvegarde, donc les écritures de journal utilisent également -ErrorAction Stop. Ne signalez pas le succès simplement parce qu'aucun journal n'existe.

Les programmes externes renvoient leurs propres codes de sortie. Dans Windows PowerShell 5.1, ne supposez pas qu'une sortie non nulle entre automatiquement dans catch. Inspectez immédiatement $LASTEXITCODE et lancez une exception lorsque cela est approprié ; une autre commande externe peut remplacer cette valeur.

Préparez des relances contrôlées pour les scripts opérationnels

• Enregistrez le serveur, la cible, ainsi que les heures de début et de fin.
• Vérifiez l'état existant pour éviter la création en double ou l'écrasement involontaire.
• Suivez séparément les étapes réussies et échouées.
• Gardez les mots de passe, les jetons et le contenu inutile des fichiers utilisateur hors des journaux.
• Si vous implémentez un retour en arrière, enregistrez sa portée prise en charge et toute défaillance de récupération.

Restaurez le chemin d'entrée valide et exécutez à nouveau pour confirmer un nouveau résultat réussi. Conservez les preuves nécessaires avant de ne supprimer que les fichiers temporaires de ce laboratoire. Ajouter SilentlyContinue partout masque les échecs plutôt que de rendre l'administration fiable.