about_Windows_Powershell_5.1

Description courte

Décrit les nouvelles fonctionnalités incluses dans Windows PowerShell 5.1.

Description longue

Windows PowerShell 5.1 inclut de nouvelles fonctionnalités significatives qui étendent son utilisation, améliorent sa facilité d’utilisation et vous permettent de contrôler et de gérer les environnements Windows plus facilement et plus complètement.

Windows PowerShell 5.1 est rétrocompatible. Les applets de commande, les fournisseurs, les modules, les composants logiciels enfichables, les scripts, les fonctions et les profils conçus pour Windows PowerShell 4.0, Windows PowerShell 3.0 et Windows PowerShell 2.0 fonctionnent généralement dans Windows PowerShell 5.1 sans modification.

• Nouvelles applets de commande : groupes et utilisateurs locaux ; Get-ComputerInfo
• Améliorations de PowerShellGet avec l’utilisation imposée de modules signés et l’installation de modules JEA
• Ajout de la prise en charge de PackageManagement pour les conteneurs, l’installation de CBS, l’installation basée sur des fichiers .exe et les packages CAB
• Améliorations du débogage pour les classes DSC et PowerShell
• Améliorations de la sécurité, notamment l’utilisation imposée de modules signés par le catalogue provenant du serveur collecteur et lors de l’utilisation des applets de commande PowerShellGet
• Réponses à plusieurs demandes et problèmes des utilisateurs

Windows PowerShell 5.1 est installé par défaut sur Windows Server version 2016 et versions ultérieures et client Windows version 10 et ultérieure.

Pour installer Windows PowerShell 5.1 sur les versions antérieures de Windows, consultez Installer et configurer WMF 5.1. Veillez à lire les détails du téléchargement et à répondre à toutes les exigences système avant d’installer Windows Management Framework 5.1.

Vous pouvez également lire les modifications apportées à Windows PowerShell 5.1 dans What’s New in Windows PowerShell.

Éditions de PowerShell

À compter de la version 5.1, PowerShell est disponible dans plusieurs éditions, dont les ensembles de fonctionnalités et la compatibilité de plateforme diffèrent.

• Édition Desktop : repose sur .NET Framework et offre une compatibilité avec les scripts et les modules ciblant les versions de PowerShell exécutées sur les éditions complètes de Windows, telles que Server Core et le Bureau Windows.
• Core Edition : basée sur .NET Core, elle fournit la compatibilité avec les scripts et les modules qui ciblent des versions de PowerShell exécutées sur des éditions réduites de Windows telles que Nano Server et Windows IoT.

En savoir plus sur l’utilisation des éditions de PowerShell

• Déterminer la version en cours d’exécution de PowerShell à l’aide de $PSVersionTable
• Filtrer les résultats de Get-Module par CompatiblePSEditions à l’aide du paramètre PSEdition
• Empêcher l’exécution des scripts, sauf en cas d’exécution sur une édition compatible de PowerShell
• Déclarer la compatibilité d’un module avec des versions spécifiques de PowerShell

Applets de commande de catalogue

Deux nouvelles applets de commande ont été ajoutées dans le module Microsoft.PowerShell.Security . Ces applets de commande génèrent et valident les fichiers catalogue Windows.

New-FileCatalog

New-FileCatalog crée un fichier catalogue Windows pour l’ensemble de dossiers et de fichiers. Ce fichier catalogue contient des hachages pour tous les fichiers dans les chemins spécifiés. Les utilisateurs peuvent distribuer l’ensemble des dossiers ainsi que le fichier catalogue correspondant représentant ces dossiers. Ces informations sont utiles pour vérifier si des modifications ont été apportées aux dossiers depuis l’heure de création du catalogue.

New-FileCatalog [-CatalogFilePath] <string> [[-Path] <string[]>]
 [-CatalogVersion <int>] [-WhatIf] [-Confirm] [<CommonParameters>]

Les versions de catalogues 1 et 2 sont prises en charge. La version 1 utilise l’algorithme de hachage SHA1 pour créer des fichiers à hacher et la version 2 utilise SHA256. Vous devez utiliser le catalogue version 2.

Pour vérifier l’intégrité du fichier catalogue (Pester.cat dans l’exemple ci-dessus), signez-le à l’aide de l’applet de commande Set-AuthenticodeSignature.

Test-FileCatalog

Test-FileCatalog valide le catalogue représentant un ensemble de dossiers.

Test-FileCatalog [-Detailed] [-FilesToSkip <String[]>]
 [-CatalogFilePath] <String> [[-Path] <String[]>]
 [-WhatIf] [-Confirm] [<CommonParameters>]

Cette applet de commande compare tous les hachages de fichiers et leurs chemins relatifs trouvés dans un catalogue avec des fichiers sur le disque. S’il détecte une incompatibilité entre les hachages de fichier et les chemins d’accès, il retourne l’état en tant que ValidationFailed. Les utilisateurs peuvent récupérer toutes ces informations à l’aide du paramètre Détaillé . Il affiche également l’état de signature du catalogue dans la propriété Signature , qui équivaut à appeler l’applet de commande Get-AuthenticodeSignature sur le fichier catalogue. Les utilisateurs peuvent également ignorer n’importe quel fichier lors de la validation à l’aide du paramètre FilesToSkip .

Cache d’analyse de module

À compter de WMF 5.1, PowerShell fournit un contrôle sur le fichier utilisé pour mettre en cache des données sur un module, comme les commandes qu’il exporte.

Par défaut, ce cache est stocké dans le fichier ${env:LOCALAPPDATA}\Microsoft\Windows\PowerShell\ModuleAnalysisCache. Le cache est normalement lu au démarrage lors de la recherche d’une commande, et les données y sont écrites sur un thread d’arrière-plan après l’importation d’un module.

Pour modifier l’emplacement par défaut du cache, définissez la variable d’environnement $env:PSModuleAnalysisCachePath avant de démarrer PowerShell. Les modifications apportées à cette variable d’environnement affectent uniquement les processus enfants. La valeur doit nommer un chemin complet (y compris le nom de fichier) où PowerShell est autorisé à créer et à écrire des fichiers. Pour désactiver le cache de fichiers, vous pouvez affecter à cette valeur un emplacement non valide, par exemple :

$env:PSModuleAnalysisCachePath = 'nul'

Cela définit un appareil non valide comme chemin. Si PowerShell ne peut pas écrire dans le chemin d’accès, aucune erreur n’est retournée, mais vous pouvez voir le rapport d’erreurs à l’aide d’un traceur :

Trace-Command -PSHost -Name Modules -Expression {
  Import-Module Microsoft.PowerShell.Management -Force
}

Lors de l’écriture du cache, PowerShell recherche les modules qui n’existent plus pour éviter un cache inutilement volumineux. Vous pouvez désactiver les vérifications à l’aide du paramètre suivant :

$env:PSDisableModuleAnalysisCacheCleanup = 1

La définition de cette variable d’environnement prend effet immédiatement dans le processus actuel.

Spécification de la version de module

Dans WMF 5.1, using module se comporte de la même façon que les autres constructions liées aux modules dans PowerShell. Auparavant, vous n’aviez aucun moyen de spécifier une version de module particulière. S’il y avait plusieurs versions présentes, cela a entraîné une erreur.

Dans WMF 5.1 :

• Vous pouvez utiliser ModuleSpecification Constructor (Hashtable). Cette table de hachage a le même format que Get-Module -FullyQualifiedName.

  Exemple : using module @{ModuleName = 'PSReadLine'; RequiredVersion = '1.1'}

• S’il existe plusieurs versions du module, PowerShell utilise la même logique de résolution que Import-Module et ne retourne pas d’erreur.

Améliorations apportées à Pester

Dans WMF 5.1, la version de Pester fournie avec PowerShell a été mise à jour de la version 3.3.5 à la version 3.4.0. Vous pouvez passer en revue les modifications apportées aux versions 3.3.5 à 3.4.0 en inspectant changeLOG dans le référentiel GitHub.

MOTS-CLÉS

Nouveautés de Windows PowerShell 5.1