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

Modifications de WMF 5.0

• PowerShell 5.0 ajoute un nouveau flux d’informations structuré
• Améliorations apportées à DSC, notamment quatre nouvelles ressources DSC :
  • WindowsFeatureSet
  • WindowsOptionalFeatureSet
  • ServiceSet
  • ProcessSet
• Ajout de Just Enough Administration pour activer l’administration basée sur les rôles via la communication à distance PowerShell
• PowerShell 5.0 étend le langage pour inclure des classes et des énumérations définies par l’utilisateur
• Amélioration des fonctionnalités de débogage dans PowerShell ISE et ajout du débogage à distance
• Ajout des modules PowerShellGet et PackageManagement
• Journalisation et transcriptions de script PowerShell améliorées
• Ajouter des applets de commande de syntaxe de message de chiffrement
• WMF 5.0 inclut le module NetworkSwitchManager pour Windows
• Ajout du module Microsoft.PowerShell.ODataUtils
• Ajout de la prise en charge de la journalisation de l’inventaire logiciel (SIL)
• Modifier ou mettre à jour des applets de commande en réponse aux demandes et problèmes de l’utilisateur

Modifications de WMF 5.1

WMF 5.1 inclut les composants PowerShell, WMI, WinRM et SIL (Software Inventory Logging) qui ont été publiés avec Windows Server 2016. WMF 5.1 peut être installé sur Windows 7, Windows 8.1, Windows Server 2008 R2, 2012 et 2012 R2, et offre plusieurs améliorations sur WMF 5.0, notamment :

• Nouvelles applets de commande
• Les améliorations apportées à PowerShellGet incluent l’application des modules signés et l’installation des modules JEA
• PackageManagement a ajouté la prise en charge des conteneurs, du programme d’installation CBS, de l’installation basée sur EXE, des packages CAB
• Améliorations du débogage pour les classes DSC et PowerShell
• Améliorations de la sécurité, notamment l’application des modules signés par catalogue provenant du serveur Pull et lors de l’utilisation des applets de commande PowerShellGet
• Réponses à un certain nombre de demandes et de problèmes utilisateur

Éditions PowerShell

À compter de la version 5.1, PowerShell est disponible dans différentes éditions qui indiquent les différents ensembles de fonctionnalités et la compatibilité de la plateforme.

• Desktop Edition : basé sur .NET Framework et fournit une compatibilité avec les scripts et les modules ciblant les versions de PowerShell s’exécutant sur des éditions complètes de Windows, telles que Server Core et Windows Desktop.
• Core Edition : basé sur .NET Core et fournit une compatibilité avec les scripts et les modules ciblant les versions de PowerShell s’exécutant sur des éditions d’empreinte réduites de Windows, telles que Nano Server et Windows IoT.

En savoir plus sur l’utilisation des éditions PowerShell

• Déterminer l’édition en cours d’exécution de PowerShell à l’aide de $PSVersionTable
• filtre Get-Module résultats par CompatiblePSEditions à l’aide du paramètre PSEdition
• Empêcher l’exécution du script, sauf si elle est exécutée sur une édition compatible de PowerShell
• Déclarer la compatibilité d’un module à des versions PowerShell spécifiques

Cache d’analyse du 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 généralement lu au démarrage lors de la recherche d’une commande et est écrit sur un thread d’arrière-plan parfois 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) que PowerShell a l’autorisation de créer et d’écrire des fichiers. Pour désactiver le cache de fichiers, définissez cette valeur sur un emplacement non valide, par exemple :

$env:PSModuleAnalysisCachePath = 'nul'

Cela définit le chemin d’accès à un appareil non valide. 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. Parfois, ces vérifications ne sont pas souhaitables, auquel cas vous pouvez les désactiver en définissant :

$env:PSDisableModuleAnalysisCacheCleanup = 1

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

Spécification de la version du module

Dans WMF 5.1, using module se comporte de la même façon que d’autres constructions liées au module 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 constructeur ModuleSpecification (Hashtable).

  Ce tableau 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 un comportement d’erreur identique à 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 3.3.5 à 3.4.0. Cette mise à jour permet un meilleur comportement pour Pester sur Nano Server.

Vous pouvez consulter les modifications apportées à Pest en inspectant les changeLOG dans le dépôt GitHub.