Notes de publication de Windows Management Framework (WMF) 5.x

  • Article

Modifications de WMF 5.0

  • Ajout d’un nouveau flux d’informations structuré dans PowerShell 5.0
  • Amélioration de DSC, notamment quatre nouvelles ressources DSC :
    • WindowsFeatureSet
    • WindowsOptionalFeatureSet
    • ServiceSet
    • ProcessSet
  • Ajout de Just Enough Administration pour permettre une administration basée sur des rôles par la communication à distance PowerShell
  • Extension du langage aux énumérations et aux classes définies par l’utilisateur dans PowerShell 5.0
  • Amélioration des fonctionnalités de débogage dans PowerShell ISE et ajout du débogage à distance
  • Ajout des modules PowerShellGet et PackageManagement
  • Amélioration de la transcription et de la journalisation des scripts PowerShell
  • Ajout des cmdlets CMS (Cryptographic Message Syntax)
  • Ajout du module NetworkSwitchManager pour Windows dans WMF 5.0
  • Ajout du module Microsoft.PowerShell.ODataUtils
  • Ajout de la prise en charge de la Journalisation de l’inventaire logiciel (SIL)
  • Plusieurs ajouts ou mises à jour de cmdlets en réponse aux problèmes et demandes des utilisateurs

Modifications de WMF 5.1

WMF 5.1 comprend les composants PowerShell, WMI, WinRM et SIL (Journalisation de l’inventaire logiciel) qui ont été publiés avec Windows Server 2016. WMF 5.1, qui peut être installé sur Windows 7, Windows 8.1, Windows Server 2008 R2, 2012 et 2012 R2, comporte plusieurs améliorations par rapport à WMF 5.0 :

  • Nouvelles applets de commande
  • 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

Important

Avant d’installer WMF 5.1 sur Windows Server 2008 ou Windows 7, confirmez que WMF 3.0 n’est pas installé. Pour plus d’informations, consultez Prérequis de WMF 5.1 pour Windows Server 2008 R2 SP1 et Windows 7 SP1.

Éditions de PowerShell

À compter de la version 5.1, PowerShell est disponible dans différentes éditions qui affichent une compatibilité distincte avec les plateformes et des ensembles de fonctionnalités variables.

  • Édition Desktop : repose sur le .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 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

Cache d’analyse de module

À compter de la version 5.1, PowerShell fournit le contrôle suivant sur le fichier utilisé pour mettre en cache les données relatives à 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, aucune erreur n’est retournée, mais vous pouvez observer la présence d’une erreur signalée à l’aide d’un suivi :

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 que le cache ne devienne volumineux inutilement. Parfois, ces contrôles ne sont pas souhaitables, auquel cas vous pouvez les désactiver en définissant ce qui suit :

$env:PSDisableModuleAnalysisCacheCleanup = 1

Cette variable d’environnement prend effet immédiatement dans le processus actif.

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. Si plusieurs versions étaient présentes, une erreur se produisait.

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 (même comportement que Import-Module et Import-DscResource).

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. Cette mise à jour améliore le comportement de Pester sur Nano Server.

Pour voir les changements de Pester, consultez le CHANGELOG dans le dépôt GitHub.