Partager via


Nouveautés de Windows PowerShell 5.0

Windows PowerShell 5.0 intègre des fonctionnalités importantes qui prolongent son utilisation, améliorent son ergonomie et vous permettent de contrôler et gérer les environnements Windows de manière plus simple et complète.

Windows PowerShell 5.0 est rétrocompatible. Les cmdlets, fournisseurs, modules, inserts, scripts, fonctions et 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.0 sans modifications.

Installation de Windows PowerShell

Windows PowerShell 5.0 est installé par défaut sur Windows Server 2016 Technical Preview et Windows 10.

Pour installer Windows PowerShell 5.0 sur Windows Server 2012 R2, Windows 8.1 Enterprise ou Windows 8.1 Pro, téléchargez et installez Windows Management Framework 5.0. Assurez-vous de lire les détails du téléchargement et de respecter toutes les exigences système avant d’installer Windows Management Framework 5.0.

Dans cette rubrique

Mises à jour Windows PowerShell 4.0 en novembre 2014 : regroupement des mises à jour (KB 3000850)

De nombreuses mises à jour et améliorations de la configuration d’état désiré (DSC) de Windows PowerShell dans Windows PowerShell 4.0 sont disponibles dans le regroupement de mises à jour de novembre 2014 pour Windows RT 8.1, Windows 8.1 et Windows Server 2012 R2 (KB3000850). Vous pouvez vérifier si KB3000850 est installé sur votre système en l’exécutant Get-Hotfix -Id KB3000850 sous Windows PowerShell.

  • Mises à jour des cmdlets existants dans le module PSDesiredStateConfiguration

  • Nouveaux commandlets dans le module PSDesiredStateConfiguration

  • Améliorations linguistiques

    • DependsOn prend désormais en charge les ressources composites.
    • DependsOn prend désormais en charge les nombres dans les noms des instances de ressources.
    • Les expressions de nœud qui évaluent à vide ne génèrent plus d’erreurs.
    • Une erreur qui survient si une expression de nœud s’évalue à vide a été corrigée.
    • Les configurations appelant les configurations fonctionnent désormais dans la console PowerShell de Windows.
  • Améliorations du mode pull

    • Le mode pull prend désormais en charge tous les fichiers ZIP.
    • AllowModuleOverwrite fonctionne désormais correctement.
  • Améliorations de la résilience

    • Le nouveau DebugMode permet de recharger des modules de ressources.
    • En cas de défaillance de configuration, le fichier pending.mof n’est pas supprimé.
    • Le Gestionnaire de configuration local (LCM) est désormais plus résilient lorsque les paramètres de métaconfiguration sont corrompus.
  • Améliorations des diagnostics

    • Un avertissement s’affiche lorsque le LCM règle le minuteur sur des réglages différents de ceux que vous avez spécifiés.
    • Les fichiers journaux d’erreur contiennent désormais la pile d’appels pour les ressources PowerShell de Windows.
  • Améliorations de flexibilité

    • La ressource LocalConfigurationManager possède une nouvelle propriété, ActionAfterReboot.
      • ContinueConfiguration (valeur par défaut) : Reprend automatiquement une configuration après le redémarrage d’un nœud cible.
      • StopConfiguration : Ne reprenez pas automatiquement une configuration après le redémarrage d’un nœud.
    • Une exécution de cohérence peut désormais se produire plus souvent qu’une opération PULL, ou inversement.
    • Prise en charge du versionnement : DSC peut désormais reconnaître un document généré sur un client plus récent (inclus avec WMF 5.0).
  • Améliorations de la prévention des erreurs

    • La version du module est désormais appliquée avant qu’une configuration ne soit appliquée.
    • DebugPreference est désormais correctement défini pour les appels Get-, Set- ou Test-TargetResource.
  • Améliorations de la gestion des qualifications

    • Un certificat est désormais utilisé, si Certificate et PSDscAllowTextWordPassword sont spécifiés.
    • Les identifiants sont déchiffrés, même pour Get-TargetResource.
    • Les identifiants de métaconfiguration sont chiffrés et déchiffrés.
    • Les PSCredentials sont désormais déchiffrés lorsqu’ils sont dans un objet intégré.
  • Améliorations intégrées des ressources

    • La ressource Package
      • Il n’installe plus le mauvais package (que ce soit à partir de sources locales ou web).
      • Prend désormais en charge HTTPS.
    • Il y a désormais un support pour HTTPS dans la ressource Package.
    • La ressource de l’Archive prend désormais en charge les identifiants.

Nouvelles fonctionnalités de Windows PowerShell 5.0

Nouvelles fonctionnalités de Windows PowerShell

  • À partir de Windows PowerShell 5.0, vous pouvez développer en utilisant des classes, une syntaxe formelle et une sémantique similaires à d’autres langages de programmation orientés objet. Class, Enum et d’autres mots-clés ont été ajoutés au langage PowerShell de Windows pour prendre en charge cette nouvelle fonctionnalité. Pour plus d’informations sur le travail avec les classes, voir about_Classes.

  • Windows PowerShell 5.0 introduit un nouveau flux d’informations structuré que vous pouvez utiliser pour transmettre des données structurées entre un script et ses appelants (ou l’environnement d’hébergement). Vous pouvez maintenant utiliser Write-Host pour émettre des sorties vers le flux d’information. Les flux d’information fonctionnent également pour PowerShell.Streams, tâches, emplois planifiés et workflows. Les fonctionnalités suivantes prennent en charge le flux d’informations.

    • Un nouveau cmdlet Write-Information qui permet de spécifier comment Windows PowerShell gère les données du flux d’informations pour une commande. Write-Host est un wrapper pour Write-Information. Write-Information est également une activité de workflow prise en charge.
    • Deux nouveaux paramètres courants, InformationVariable et InformationAction, permettent de déterminer comment les flux d’informations d’une commande sont affichés. Les valeurs valides pour InformationAction sont SilentlyContinue, Stop, Continue, Inquire, Ignore ou Suspend, SilentlyContinue étant la valeur par défaut. InformationVariable spécifie une chaîne comme nom d’une variable à laquelle vous souhaitez sauvegarder les données Write-Host d’une commande.
    • Une nouvelle variable de préférence, InformationPreference, spécifie votre préférence par défaut pour les données du flux d’information dans une session PowerShell de Windows. La valeur par défaut est SilentlyContinue.
    • Deux nouveaux paramètres communs de flux de travail, PSInformation et InformationAction, ont été ajoutés.
    • Lorsque vous utilisez la commande Format-Table, les colonnes de tableau sont désormais formatées automatiquement en évaluant les 300 ms de données qui passent dans le flux.
  • En collaboration avec Microsoft Research, un nouveau cmdlet, ConvertFrom-String, a été ajouté. ConvertFrom-String permet d’extraire et d’analyser des objets structurés à partir du contenu des chaînes de texte. Pour plus d’informations, voir ConvertFrom-String.

  • Un nouveau cmdlet Convert-String formate automatiquement le texte en fonction d’un exemple que vous fournissez dans un paramètre -Example.

  • Un nouveau module, Microsoft.PowerShell.Archive, inclut des cmdlets qui vous permettent de compresser des fichiers et dossiers en fichiers d’archive (également appelés ZIP), d’extraire des fichiers à partir de fichiers ZIP existants, et de mettre à jour les fichiers ZIP avec des versions plus récentes des fichiers compressés à leur intérieur.

  • Un nouveau module, PackageManagement, vous permet de découvrir et d’installer des logiciels sur Internet. Le module PackageManagement (anciennement connu sous le nom de OneGet) est un gestionnaire ou multiplexeur des gestionnaires de paquets existants (également appelés fournisseurs de paquets) visant à unifier la gestion de paquets Windows avec une seule interface PowerShell Windows.

  • Un nouveau module, PowerShellGet, vous permet de trouver, installer, publier et mettre à jour des modules et des ressources DSC sur la galerie PowerShell, ou sur un dépôt interne de modules que vous pouvez configurer en exécutant le Register-PSRepository cmdlet.

  • Un nouveau mot-clé linguistique, Hidden, a été ajouté pour spécifier qu’un membre (une propriété ou une méthode) n’est pas affiché par défaut dans Get-Member résultats (sauf si vous ajoutez le paramètre -Force). Les propriétés ou méthodes marquées comme cachées n’apparaissent pas non plus dans les résultats d’IntelliSense, sauf si vous êtes dans un contexte où le membre devrait être visible ; Par exemple, la variable automatique $This devrait afficher des membres cachés lorsqu’elle est dans la méthode de classe.

  • Nouveau-Objet, Retirer-Objet et Get-ChildItem ont été améliorés pour permettre la création et la gestion de liens symboliques. Le paramètre -ItemType pour New-Item accepte une nouvelle valeur, SymbolicLink. Vous pouvez maintenant créer des liens symboliques en une seule ligne en exécutant le New-Item cmdlet.

  • Get-ChildItem a aussi un nouveau paramètre -Depth, que vous utilisez avec le paramètre -Recurse pour limiter la récursion. Par exemple, Get-ChildItem -Recurse -Depth 2 retourne les résultats du dossier courant, de tous les dossiers enfants dans le dossier actuel, et de tous les dossiers dans les dossiers enfants.

  • Copy-Item vous permet désormais de copier des fichiers ou des dossiers d’une session PowerShell Windows à une autre, ce qui signifie que vous pouvez copier des fichiers vers des sessions connectées à des ordinateurs distants (y compris des ordinateurs fonctionnant sous Nano Server, et donc sans autre interface). Pour copier des fichiers, spécifiez les identifiants PSSession comme valeur des nouveaux paramètres -FromSession et -ToSession, et ajoutez -Path et -Destination pour spécifier respectivement le chemin d’origine et la destination. Par exemple, Copy-Item -Path c :\myFile.txt -ToSession $s -Destination d :\destinationFolder.

  • La transcription PowerShell de Windows a été améliorée pour s’appliquer à toutes les applications hébergeantes (comme Windows PowerShell ISE) en plus de l’hôte de la console (powershell.exe). Les options de transcription (y compris l’activation d’une transcription à l’échelle du système) peuvent être configurées en activant le paramètre Activation de la Stratégie de Groupe de Transcription PowerShell , que l’on trouve dans Modèles Administratifs/Composants Windows/Windows PowerShell.

  • Une nouvelle fonctionnalité détaillée de traçage de scripts vous permet d’activer le suivi détaillé et l’analyse de l’utilisation des scripts PowerShell Windows sur un système. Après avoir activé le traçage de script détaillé, Windows PowerShell enregistre tous les blocs de script dans le journal d’événements Event Tracing for Windows (ETW), Microsoft-Windows-PowerShell/Operational.

  • À partir de Windows PowerShell 5.0, les nouveaux cmdlets de syntaxe des messages cryptographiques prennent en charge le chiffrement et le déchiffrement du contenu en utilisant le format standard IETF pour protéger cryptographiquement les messages tels que documentés par RFC5652. Les cmdlets Get-CmsMessage, Protect-CmsMessage et Unprotect-CmsMessage ont été ajoutés au module Microsoft.PowerShell.Security .

  • Les nouveaux cmdlets dans le module Microsoft.PowerShell.Utilitaire , Get-Runspace, Debug-Runspace, Get-RunspaceDebug, Enable-RunspaceDebug et Disable-RunspaceDebug, vous permettent de définir des options de débogage sur un espace d’exécution, et de commencer et d’arrêter le débogage sur un espace. Pour déboger des espaces d’exécution arbitraires (c’est-à-dire des espaces d’exécution qui ne sont pas l’espace d’exécution par défaut pour une console Windows PowerShell ou une session ISE Windows PowerShell), Windows PowerShell vous permet de définir des points d’arrêt dans un script, et d’ajouter des points d’arrêt empêchent le script d’exécuter jusqu’à ce que vous puissiez attacher un débogueur pour déboguer le script d’espace d’exécution. Le support du débogage imbriqué pour les espaces d’exécution arbitraires a été ajouté au script débogueur Windows PowerShell pour les espaces d’exécution.

  • Un nouveau cmdlet Format-Hex a été ajouté au module Microsoft.PowerShell.Utility . Format-Hex permet de voir du texte ou des données binaires au format hexadécimal.

  • Get-Clipboard et Set-Clipboard cmdlets ont été ajoutés au module Microsoft.PowerShell.Utility ; elles facilitent le transfert de contenu vers et depuis une session PowerShell Windows. Les commandets Presse-papiers prennent en charge les images, fichiers audio, listes de fichiers et texte.

  • Un nouveau cmdlet, Clear-RecycleBin, a été ajouté au module Microsoft.PowerShell.Management ; ce cmdlet vide la corbeille pour un disque fixe, qui inclut les disques externes. Par défaut, il vous est demandé de confirmer une commande Clear-RecycleBin, car la propriété ConfirmImpact du cmdlet est définie sur ConfirmImpact.High.

  • Un nouveau cmdlet, New-TemporaryFile, vous permet de créer un fichier temporaire dans le cadre du scripting. Par défaut, le nouveau fichier temporaire est créé dans C:\Users\<user name>\AppData\Local\Temp.

  • Les cmdlets Out-File, Add-Content et Set-Content disposent désormais d’un nouveau paramètre -NoNewline, qui omet une nouvelle ligne après la sortie.

  • Le cmdlet New-Guid utilise la classe Guid .NET Framework pour générer un GUID, utile lorsque vous écrivez des scripts ou des ressources DSC.

  • Comme les informations sur les versions du fichier peuvent être trompeuses, notamment après la correction d’un fichier, de nouvelles propriétés de script FileVersionRaw et ProductVersionRaw sont disponibles pour les objets FileInfo. Par exemple, vous pouvez exécuter la commande suivante pour afficher les valeurs de ces propriétés pour powershell.exe, où $pid contient l’ID du processus pour une session en cours de Windows PowerShell : Get-Process -Id $pid -FileVersionInfo | Format-List *version* -Force

  • Les nouveaux commandlets Enter-PSHostProcess et Exit-PSHostProcess permettent de déboguer des scripts Windows PowerShell dans des processus séparés de celui qui tourne actuellement sur la console PowerShell de Windows. Exécutez Enter-PSHostProcess pour entrer ou attacher un identifiant de processus spécifique, puis exécutez Get-Runspace pour retourner les espaces d’exécution actifs au sein du processus. Exécutez Exit-PSHostProcess pour vous détacher du processus une fois que vous avez fini de déboguer le script dans le processus.

  • Un nouveau cmdlet Wait-Debugger a été ajouté au module Microsoft.PowerShell.Utility . Vous pouvez exécuter Wait-Debugger pour arrêter un script dans le débogueur avant d’exécuter l’instruction suivante du script.

  • Le débogueur de workflow Windows PowerShell prend désormais en charge la complétion de commandes ou d’onglets, et vous pouvez déboguer des fonctions de workflow imbriquées. Vous pouvez désormais appuyer sur Ctrl+Break pour entrer le débogueur dans un script en cours, aussi bien en sessions locales que distantes, ainsi que dans un script de workflow.

  • Un Debug-Job cmdlet a été ajouté au module Microsoft.PowerShell.Core pour déboguer les scripts de tâches exécutant pour le flux de travail Windows PowerShell, l’arrière-plan et les tâches exécutées en sessions distantes.

  • Un nouvel état, AtBreakpoint, a été ajouté pour les tâches PowerShell de Windows. L’état AtBreakpoint s’applique lorsqu’un travail exécute un script incluant des points d’arrêt définis, et que le script a atteint un point d’arrêt. Lorsqu’un travail est arrêté à un point d’arrêt de débogage, vous devez le déboguer en exécutant le cmdlet Debug-Job.

  • Windows PowerShell 5.0 implémente la prise en charge de plusieurs versions d’un même module Windows PowerShell dans le même dossier dans $PSModulePath. Une propriété RequiredVersion a été ajoutée à la classe ModuleSpecification pour vous aider à obtenir la version souhaitée d’un module ; cette propriété est mutuellement exclusive avec la propriété ModuleVersion. RequiredVersion est désormais pris en charge comme partie intégrante de la valeur du paramètre FullyQualifiedName des cmdlets Get-Module, Import-Module et Remove-Module.

  • Vous pouvez désormais effectuer la validation des versions du module en exécutant le cmdlet Test-ModuleManifest.

  • Les résultats du Get-Command cmdlet affichent désormais une colonne Version ; une nouvelle propriété Version a été ajoutée à la classe CommandInfo. Get-Command affiche des commandes provenant de plusieurs versions du même module. La propriété Version fait également partie des classes dérivées de CmdletInfo : CmdletInfo et ApplicationInfo.

  • Get-Command dispose d’un nouveau paramètre, -ShowCommandInfo, qui renvoie les informations ShowCommand sous forme de PSObjects. C’est une fonctionnalité particulièrement utile lorsque Show-Command est exécuté dans Windows PowerShell ISE en utilisant Windows PowerShell à distance. Le paramètre -ShowCommandInfo remplace la fonction Get-SerializedCommand existante dans le module Microsoft.PowerShell.Utilitaire, mais le script Get-SerializedCommand reste disponible pour supporter le script downlevel.

  • Un nouveau cmdlet Get-ItemPropertyValue permet d’obtenir la valeur d’une propriété sans utiliser la notation en points. Par exemple, dans les versions antérieures de Windows PowerShell, vous pouvez exécuter la commande suivante pour obtenir la valeur de la propriété Application Base de la clé de registre PowerShellEngine : (Get-ItemProperty -Path HKLM :\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine -Name ApplicationBase). ApplicationBase. À partir de Windows PowerShell 5.0, vous pouvez exécuterGet-ItemPropertyValue -Path HKLM :\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine -Name ApplicationBase.

  • La console PowerShell de Windows utilise désormais la coloration syntaxique, tout comme dans Windows PowerShell ISE.

  • Un nouveau module NetworkSwitch contient des commandets permettant d’appliquer la configuration du commutateur, du LAN virtuel (VLAN) et des ports réseau de base de couche 2 aux commutateurs réseau certifiés par le logo Windows Server 2012 R2.

  • Le paramètre FullyQualifiedName a été ajouté aux cmdlets Import-Module et Remove-Module, afin de supporter le stockage de plusieurs versions d’un même module.

  • Save-Help, Update-Help, Import-PSSession, Export-PSSession, et Get-Command ont un nouveau paramètre, FullQualifiedModule, de type ModuleSpecification. Ajoutez ce paramètre pour spécifier un module par son nom entièrement qualifié.

  • La valeur de $PSVersionTable.PSVersion a été mise à jour à la version 5.0.

  • WMF 5.0 (PowerShell 5.0) inclut le module Pester . Pester est un cadre de tests unitaires pour PowerShell. Il propose quelques mots-clés simples à utiliser qui vous permettent de créer des tests pour vos scripts.

Nouvelles fonctionnalités dans la configuration de l’état désiré de Windows PowerShell

  • Les améliorations du langage Windows PowerShell permettent de définir les ressources de configuration d’état désiré (DSC) de Windows PowerShell à l’aide de classes. Import-DscResource est désormais un véritable mot-clé dynamique ; Windows PowerShell analyse le module racine du module spécifié, en recherchant les classes contenant l’attribut DscResource. Vous pouvez désormais utiliser des classes pour définir des ressources DSC, dans lesquelles ni un fichier MOF ni un sous-dossier DSCResource dans le dossier module ne sont requis. Un fichier de module Windows PowerShell peut contenir plusieurs classes de ressources DSC.
  • Un nouveau paramètre, ThrottleLimit, a été ajouté aux commandlets suivants dans le module PSDesiredStateConfiguration. Ajoutez le paramètre ThrottleLimit pour spécifier le nombre d’ordinateurs ou d’appareils ciblés sur lesquels vous souhaitez que la commande fonctionne en même temps.
    • Get-DscConfiguration
    • Get-DscConfigurationStatus
    • Get-DscLocalConfigurationManager
    • Restore-DscConfiguration
    • Test-DscConfiguration
    • Compare-DscConfiguration
    • Publish-DscConfiguration
    • Set-DscLocalConfigurationManager
    • Start-DscConfiguration
    • Update-DscConfiguration
  • Avec le rapport centralisé des erreurs DSC, les informations riches sur les erreurs sont non seulement enregistrées dans le journal des événements, mais peuvent être envoyées à un emplacement central pour une analyse ultérieure. Vous pouvez utiliser cet emplacement central pour stocker des erreurs de configuration DSC survenues sur n’importe quel serveur dans leur environnement. Après la définition du serveur de rapports dans la méta-configuration, toutes les erreurs sont envoyées au serveur de rapports, puis stockées dans une base de données. Vous pouvez configurer cette fonctionnalité que le nœud cible soit configuré ou non pour extraire des configurations d’un serveur de tirage.
  • Les améliorations de Windows PowerShell ISE facilitent l’authoring des ressources DSC. Vous pouvez maintenant faire ce qui suit.
    • Listez toutes les ressources DSC au sein d’un bloc de configuration ou de nœud en saisissant Ctrl+Espace sur une ligne vierge dans le bloc.
    • Complétion automatique des propriétés de ressources du type d’énumération .
    • Complétion automatique sur la propriété DependsOn des ressources DSC, basée sur d’autres instances de ressources dans la configuration.
    • Amélioration de la complétion par tabulation des valeurs des propriétés des ressources.
  • Un utilisateur peut désormais exécuter une ressource sous un ensemble spécifié d’identifiants en ajoutant l’attribut PSDscRunAsCredential à un bloc de nœud. Par exemple, PSDscRunAsCredential = Get-Credential Contoso\DscUser. Cette fonctionnalité est utile pour créer des configurations qui exécutent Windows Installer et des installateurs exécutables, accèdent à la ruche du registre par utilisateur, ou effectuent d’autres tâches en dehors du contexte utilisateur actuel.
  • Le support 32 bits (basé sur x86) a été ajouté pour le mot-clé Configuration .
  • Windows PowerShell inclut désormais la prise en charge de l’aide personnalisée pour les configurations DSC, définie par l’ajout de [CmdletBinding()] à la fonction de configuration générée.
  • Un nouvel attribut DscLocalConfigurationManager désigne un bloc de configuration comme une méta-configuration, utilisée pour configurer le DSC Local Configuration Manager. Cet attribut limite une configuration à ne contenir que les éléments qui configurent le Gestionnaire de Configuration Locale DSC. Lors du traitement, cette configuration génère un fichier *.meta.mof qui est ensuite envoyé aux nœuds cibles appropriés en exécutant le cmdlet Set-DscLocalConfigurationManager.
  • Les configurations partielles sont désormais autorisées dans Windows PowerShell 5.0. Vous pouvez livrer des documents de configuration à un nœud en fragments. Pour qu’un nœud reçoive plusieurs fragments d’un document de configuration, le gestionnaire de configuration local du nœud doit d’abord être configuré pour spécifier les fragments attendus
  • La synchronisation inter-ordinateurs est nouvelle dans DSC sous Windows PowerShell 5.0. en utilisant les ressources WaitFor* intégrées (WaitForAll, WaitForAny et WaitForSome), vous pouvez désormais spécifier des dépendances entre ordinateurs lors des exécutions de configuration, sans orchestrations externes. Ces ressources permettent une synchronisation nœud à nœud grâce à des connexions CIM via le protocole WS-Man. Une configuration peut attendre que l’état spécifique des ressources d’un autre ordinateur change.
  • Just Enough Administration (JEA), une nouvelle fonctionnalité de sécurité de délégation, exploite les espaces d’exécution limités DSC et Windows PowerShell pour aider à protéger les entreprises contre la perte ou la compromission de données par les employés, qu’elles soient intentionnelles ou non. Pour plus d’informations sur JEA, y compris où télécharger la ressource xJEA DSC, voir Just Enough Administration.
  • Les nouveaux cmdlets suivants ont été ajoutés au module PSDesiredStateConfiguration.
    • Un nouveau cmdlet Get-DscConfigurationStatus obtient des informations de haut niveau sur l’état de configuration d’un nœud cible. Vous pouvez obtenir le statut du dernier, ou de toutes les configurations.
    • Un nouveau cmdlet Compare-DscConfiguration compare une configuration spécifiée à l’état réel d’un ou plusieurs nœuds cibles.
    • Un nouveau cmdlet Publish-DscConfiguration copie un fichier MOF de configuration vers un nœud cible, mais n’applique pas la configuration. La configuration est appliquée lors du passage suivant de cohérence, ou lorsque vous exécutez le cmdlet Update-DscConfiguration.
    • Un nouveau cmdlet Test-DscConfiguration vous permet de vérifier qu’une configuration résultante correspond à la configuration souhaitée, en retournant soit True si la configuration correspond à la configuration souhaitée, soit False si la configuration réelle ne correspond pas à la configuration souhaitée.
    • Un nouveau cmdlet Update-DscConfiguration force le traitement d’une configuration. Si le gestionnaire de configuration local est en mode pull, le cmdlet obtient la configuration du serveur pull avant de l’appliquer.

Nouvelles fonctionnalités de Windows PowerShell ISE

  • Vous pouvez désormais modifier des scripts et fichiers Windows PowerShell à distance dans une copie locale de Windows PowerShell ISE, en lançant Enter-PSSession pour lancer une session distante sur l’ordinateur qui stocke les fichiers que vous souhaitez modifier, puis en exécutant le chemin et le nom du fichier PSEdit <sur l’ordinateur> distant. Cette fonctionnalité facilite l’édition des fichiers PowerShell Windows stockés sur l’option d’installation Server Core de Windows Server, où Windows PowerShell ISE ne peut pas fonctionner.
  • Le cmdlet Start-Transcript est désormais pris en charge dans Windows PowerShell ISE.
  • Vous pouvez désormais déboguer des scripts à distance dans Windows PowerShell ISE.
  • Une nouvelle commande de menu, Break All (Ctrl+B), intervient dans le débogueur pour les scripts locaux et à distance.

Nouvelles fonctionnalités dans Windows PowerShell Web Services (Extension Management OData IIS)

  • À partir de Windows PowerShell 5.0, vous pouvez générer un ensemble de cmdlets Windows PowerShell basés sur la fonctionnalité exposée par un point de terminaison OData donné, en exécutant le cmdlet Export-ODataEndpointProxy, que l’on trouve dans le nouveau module Microsoft.PowerShell.OdataUtils .

Corrections notables de bugs dans Windows PowerShell 5.0

  • Windows PowerShell 5.0 inclut une nouvelle implémentation COM, qui offre des améliorations significatives de performance lorsque vous travaillez avec des objets COM.
  • Des améliorations significatives de performance ont été apportées à la première terminaison d’onglet lors d’une session Windows PowerShell, réduisant le temps de complétion des tabulations de près de 500 ms.

Nouvelles fonctionnalités de Windows PowerShell 4.0

Windows PowerShell 4.0 est rétrocompatible. Les cmdlets, fournisseurs, modules, inserts, scripts, fonctions et profils conçus pour Windows PowerShell 3.0 et Windows PowerShell 2.0 fonctionnent dans Windows PowerShell 4.0 sans modification.

Windows PowerShell 4.0 est installé par défaut sur Windows 8.1 et Windows Server 2012 R2. Pour installer Windows PowerShell 4.0 sur Windows 7 avec SP1, ou Windows Server 2008 R2, téléchargez et installez Windows Management Framework 4.0. Assurez-vous de lire les détails du téléchargement et de respecter toutes les exigences système avant d’installer Windows Management Framework 4.0.

Windows PowerShell 4.0 intègre les nouvelles fonctionnalités suivantes.

Nouvelles fonctionnalités de Windows PowerShell

  • La configuration à état désiré (DSC) de Windows PowerShell est un nouveau système de gestion sous Windows PowerShell 4.0 qui permet le déploiement et la gestion des données de configuration pour les services logiciels et l’environnement dans lequel ces services s’exécutent. Pour plus d’informations sur DSC, voir Démarrer avec la configuration d’état désiré de Windows PowerShell.
  • Save-Help vous permet maintenant de sauvegarder l’aide pour des modules installés sur des ordinateurs à distance. Vous pouvez utiliser Save-Help pour télécharger le module Aide depuis un client connecté à Internet (sur lequel tous les modules pour lesquels vous souhaitez de l’aide ne sont pas nécessairement installés), puis copier l’Aide enregistrée dans un dossier partagé distant ou sur un ordinateur distant qui n’a pas accès à Internet.
  • Le débogueur Windows PowerShell a été amélioré pour permettre le débogage des flux de travail PowerShell de Windows, ainsi que des scripts exécutés sur des ordinateurs distants. Les flux de travail Windows PowerShell peuvent désormais être débogés au niveau du script soit depuis la ligne de commande Windows PowerShell, soit depuis Windows PowerShell ISE. Les scripts PowerShell Windows, y compris les flux de travail de scripts, peuvent désormais être débogués via des sessions à distance. Les sessions de débogage à distance sont préservées sur les sessions distantes PowerShell de Windows qui sont déconnectées puis reconnectées par la suite.
  • Un paramètre RunNow pour Register-ScheduledJob et Set-ScheduledJob élimine le besoin de définir une date et une heure de début immédiates pour les tâches en utilisant le paramètre Trigger .
  • Invoke-RestMethod et Invoke-WebRequest vous permettent désormais de définir tous les en-têtes en utilisant le paramètre Headers. Bien que ce paramètre ait toujours existé, il faisait partie des nombreux paramètres des cmdlets web qui entraînaient des exceptions ou des erreurs.
  • Get-Module possède un nouveau paramètre, FullQualifiedName, du type ModuleSpecification[]. Le paramètre FullyQualifiedName de Get-Module vous permet désormais de spécifier un module en utilisant le nom, la version et, en option, son GUID.
  • Le paramètre de politique d’exécution par défaut sur Windows Server 2012 R2 est RemoteSigned. Sur Windows 8.1, il n’y a aucun changement dans les paramètres par défaut.
  • À partir de Windows PowerShell 4.0, l’invocation de méthodes utilisant des noms de méthode dynamique est prise en charge. Vous pouvez utiliser une variable pour stocker un nom de méthode, puis invoquer dynamiquement la méthode en appelant la variable.
  • Les tâches de workflow asynchrones ne sont plus supprimées lorsque la période de délai spécifiée par le paramètre commun du workflow PSElapsedTimeoutSec est écoulée.
  • Un nouveau paramètre, RepeatIndefinitely, a été ajouté aux commandets New-JobTrigger et Set-JobTrigger . Cela élimine la nécessité de spécifier une valeur TimeSpan.MaxValue pour le paramètre RerepeatDuration afin d’exécuter un travail planifié de manière répétée pendant une période indéfinie.
  • Un paramètre Passthru a été ajouté aux commandlets Enable-JobTrigger et Disable-JobTrigger . Le paramètre Passthru affiche tous les objets créés ou modifiés par votre commande.
  • Les noms des paramètres pour spécifier un groupe de travail dans les cmdlets Add-Computer et Remove-Computer sont désormais cohérents. Les deux cmdlets utilisent désormais le paramètre WorkgroupName.
  • Un nouveau paramètre commun, PipelineVariable, a été ajouté. PipelineVariable vous permet d’enregistrer les résultats d’une commande en canal (ou d’une partie d’une commande en canalisation) sous forme de variable pouvant être transmise dans le reste du pipeline.
  • Le filtrage des collections utilisant une syntaxe de méthode est désormais pris en charge. Cela signifie que vous pouvez désormais filtrer une collection d’objets en utilisant une syntaxe simplifiée, similaire à celle de Where() ou Where-Object, formatée comme un appel de méthode. Voici un exemple : (Get-Process).where({$_. Nom -match 'powershell'})
  • Le cmdlet Get-Process possède un nouveau paramètre de commutateur, IncludeUserName.
  • Un nouveau cmdlet, Get-FileHash, qui renvoie un hachage de fichier dans l’un des formats suivants pour un fichier spécifié, a été ajouté.
  • Dans Windows PowerShell 4.0, si un module utilise la clé DefaultCommandPrefix dans son manifeste, ou si l’utilisateur importe un module avec le paramètre Prefix , la propriété ExportedCommands du module affiche les commandes du module avec le préfixe. Lorsque vous exécutez les commandes en utilisant la syntaxe qualifiée module, ModuleName\CommandName, les noms des commandes doivent inclure le préfixe.
  • La valeur de $PSVersionTable.PSVersion a été mise à jour à la version 4.0.
  • Où() le comportement de l’opérateur a changé. Collection.Where('property -match name') l’acceptation d’une expression de chaîne dans ce format "Property -CompareOperator Value" n’est plus prise en charge. Cependant, l’opérateur Where() accepte des expressions de chaînes au format d’un bloc de script ; Cela est toujours pris en charge.

Nouvelles fonctionnalités dans l’Environnement de Scripting Intégré Windows PowerShell (ISE)

  • Windows PowerShell ISE prend en charge à la fois le débogage du flux de travail Windows PowerShell et le débogage de scripts à distance.
  • La prise en charge d’IntelliSense a été ajoutée pour les configurations et les fournisseurs de configuration d’état souhaité Windows PowerShell.

Nouvelles fonctionnalités du flux de travail PowerShell de Windows

  • Le support a été ajouté pour un nouveau paramètre commun PipelineVariable dans le contexte des pipelines itératifs, tels que ceux utilisés par System Center Orchestrator ; c’est-à-dire des pipelines qui exécutent des commandes simplement de gauche à droite, contrairement à des exécutions intercalées via le streaming.
  • La liaison de paramètres a été considérablement améliorée pour fonctionner en dehors des scénarios de complétion d’onglets, comme avec des commandes qui n’existent pas dans l’espace d’exécution actuel.
  • Le support des activités personnalisées pour conteneurs a été ajouté au flux de travail Windows PowerShell. Si un paramètre d’activité est du type Activity, Activity[] (ou est une collection générique d’activités) et que l’utilisateur a fourni un bloc de script comme argument, alors le flux de travail Windows PowerShell convertit le bloc de script en XAML, comme pour la compilation classique de script-to-workflow de Windows PowerShell.
  • Après un plantage, le flux de travail Windows PowerShell se reconnecte automatiquement aux nœuds gérés.
  • Vous pouvez maintenant limiter les instructions d’activité Foreach -Parallel en utilisant la propriété ThrottleLimit .
  • Le paramètre commun ErrorAction a une nouvelle valeur valide, Suspend, qui est exclusivement destinée aux workflows.
  • Un point de terminaison de workflow se ferme automatiquement s’il n’y a pas de sessions actives, pas de jobs en cours et pas de jobs en attente. Cette fonctionnalité permet d’économiser les ressources sur l’ordinateur qui agit comme serveur de workflow, lorsque les conditions de fermeture automatique sont remplies.

Nouvelles fonctionnalités dans Windows PowerShell Web Services

  • Lorsqu’une erreur survient dans Windows PowerShell Web Services (PSWS, également appelé extension Management OData IIS), pendant qu’un cmdlet est en cours, des messages d’erreur plus détaillés sont renvoyés à l’appelant. De plus, les codes d’erreur suivent les directives de code d’erreur de l’API REST de Windows.
  • Un point de terminaison peut désormais définir la version de l’API, ainsi que faire respecter l’utilisation d’une version spécifique de l’API. Chaque fois que des incompatibilités de version surviennent entre le client et le serveur, des erreurs sont affichées à la fois au client et au serveur.
  • La gestion du schéma de dispatch a été simplifiée en générant automatiquement des valeurs pour les champs manquants dans le schéma. La génération a lieu, comme point de départ utile, même si le schéma de dispatch n’existe pas.
  • La gestion des types dans PSWS a été améliorée pour prendre en charge les types utilisant un constructeur différent de celui par défaut, en se comportant de manière similaire au PSTypeConverter dans Windows PowerShell. Cela permet d’utiliser des types complexes avec PSWS.
  • PSWS permet désormais d’étendre une instance associée lors de l’exécution d’une requête. Pour les contenus binaires plus importants (comme les images, l’audio ou la vidéo), le coût de transfert est important, et il est préférable de transférer des données binaires sans encodage. PSWS utilise des flux de ressources nommés pour transférer sans encodage. Le flux de ressources nommé est une propriété d’une entité de type Edm.Stream . Chaque flux de ressources nommé possède un URI distinct pour les opérations GET ou UPDATE.
  • Les actions OData fournissent désormais un mécanisme pour invoquer des méthodes non-CRUD (Créer, Lire, Mettre à jour et Supprimer) sur une ressource. Vous pouvez invoquer une action en envoyant une requête HTTP POST à l’URI définie pour l’action. Les paramètres de l’action sont définis dans le corps de la requête POST.
  • Pour être cohérent avec les directives de Windows Azure, toutes les URL doivent être simplifiées. Un changement inclus dans Key As Segment permet de représenter des clés uniques sous forme de segments. Notez que les références utilisant plusieurs valeurs de clé nécessitent des valeurs séparées par virgules en notation entre parenthèses, comme précédemment.
  • Avant cette version du PSWS, la seule façon d’effectuer des opérations de création, mise à jour ou suppression était d’invoquer Publier, mettre ou supprimer sur une ressource de premier niveau. Nouveauté dans cette version de PSWS, les opérations de ressource contenue permettent aux utilisateurs d’obtenir les mêmes résultats tout en atteignant la même ressource de façon moins directe, en s’approchant comme si ces ressources étaient contenues.

Nouvelles fonctionnalités de Windows PowerShell Web Access

  • Vous pouvez vous déconnecter et reconnecter des sessions existantes dans la console web PowerShell Web Access. Un bouton Enregistrer dans la console web vous permet de vous déconnecter d’une session sans la supprimer et de vous reconnecter à la session une autre fois.
  • Les paramètres par défaut peuvent être affichés sur la page de connexion. Pour afficher les paramètres par défaut, configurez les valeurs de tous les paramètres affichés dans la section Paramètres de connexion optionnels de la page de connexion dans un fichier nommé web.config. Vous pouvez utiliser le fichier web.config pour configurer tous les paramètres de connexion optionnels sauf un second ou un autre ensemble d’identifiants.
  • Dans Windows Server 2012 R2, vous pouvez gérer à distance les règles d’autorisation pour Windows PowerShell Web Access. Les commandements Add-PswaAuthorizationRule et Test-PswaAuthorizationRule incluent désormais un paramètre de crédential qui permet aux administrateurs de gérer les règles d’autorisation depuis un ordinateur distant ou lors d’une session Windows PowerShell Web Access.
  • Vous pouvez désormais avoir plusieurs sessions Windows PowerShell Web Access dans une même session de navigateur en utilisant un nouvel onglet navigateur pour chaque session. Vous n’avez plus besoin d’ouvrir une nouvelle session de navigateur pour vous connecter à une nouvelle session sur la console web Windows PowerShell.

Corrections de bugs notables dans Windows PowerShell 4.0

  • Get-Counter peut désormais retourner des pions contenant un caractère apostrophe dans les éditions françaises de Windows.
  • Vous pouvez désormais consulter la méthode GetType sur les objets désérialisés.
  • #Requires instructions permettent désormais aux utilisateurs d’avoir des droits d’accès administrateurs, si nécessaire.
  • Le cmdlet Import-Csv ignore désormais les lignes blanches.
  • Un problème où Windows PowerShell ISE utilise trop de mémoire lors de l’exécution d’une commande Invoke-WebRequest a été corrigé.
  • Get-Module affiche désormais les versions des modules dans une colonne Version .
  • Remove-Item -Recurse supprime désormais les éléments des sous-dossiers comme prévu.
  • Une propriété Nom d’utilisateur a été ajoutée aux objets de sortie Get-Process.
  • Le cmdlet Invoke-RestMethod renvoie désormais tous les résultats disponibles.
  • Add-Member prend désormais effet sur les tables de hachage, même si ces tables n’ont pas encore été consultées.
  • Select-Object - L’expansion ne fait plus défaut ni ne génère d’exception si la valeur de la propriété est nulle ou vide.
  • Get-Process peut désormais être utilisé dans un pipeline avec d’autres commandes qui obtiennent la propriété Nom de l’ordinateur à partir des objets.
  • ConvertTo-Json et ConvertFrom-Json peuvent désormais accepter des termes entre guillemets doubles, et leurs messages d’erreur sont désormais localisables.
  • Get-Job renvoie désormais tous les travaux planifiés terminés, même lors de nouvelles sessions.
  • Les problèmes liés au montage et au démontage des VHD via le fournisseur FileSystem dans Windows PowerShell 4.0 ont été résolus. Windows PowerShell est désormais capable de détecter de nouveaux disques lorsqu’ils sont montés dans la même session.
  • Vous n’avez plus besoin de charger explicitement des modules ScheduledJob ou Workflow pour travailler avec leurs types de postes.
  • Des améliorations de performance ont été apportées au processus d’importation des flux de travail qui définissent les flux de travail imbriqués ; Ce processus est désormais plus rapide.

Nouvelles fonctionnalités de Windows PowerShell 3.0

Windows PowerShell 3.0 inclut les nouvelles fonctionnalités suivantes.

Flux de travail PowerShell de Windows

Le flux de travail Windows PowerShell apporte la puissance de Windows Workflow Foundation à Windows PowerShell. Vous pouvez écrire des flux de travail en XAML ou dans le langage PowerShell Windows et les exécuter comme vous le feriez avec un cmdlet. Le Get-Command cmdlet reçoit des commandes de workflow et le Get-Help cmdlet reçoit de l’aide pour les workflows.

Les flux de travail sont des séquences d’activités de gestion multi-ordinateurs qui sont de longue durée, reproductibles, fréquentes, parallélisables, interrompues, suspendibles et redémarrables. Les flux de travail peuvent être repris à la suite d’une interruption intentionnelle ou accidentelle, telle qu’une panne de réseau, un redémarrage de Windows ou une panne de courant.

Les flux de travail sont également portables ; ils peuvent être exportés ou importés à partir de fichiers XAML. Vous pouvez écrire des configurations de session personnalisées qui permettent d’exécuter des flux de travail ou des activités dans un flux de travail par des utilisateurs délégués ou subordonnés.

Voici les avantages du flux de travail Windows PowerShell

  • Automatisation de tâches séquencées et de longue durée.
  • Surveillance à distance de tâches de longue durée. Le statut et l’avancement des activités sont visibles à tout moment.
  • Gestion multi-ordinateurs. Exécutez simultanément des tâches sous forme de flux de travail sur des centaines de nœuds gérés. Le flux de travail Windows PowerShell inclut une bibliothèque intégrée de paramètres de gestion courants, tels que PSComputerName, qui permettent des scénarios de gestion multi-ordinateurs.
  • Exécution à tâche unique de processus complexes. Vous pouvez combiner des scripts associés qui implémentent un scénario complet de bout en bas en un seul flux de travail.
  • Persistance : un flux de travail est sauvegardé (ou check-point) à des points spécifiques définis par son auteur afin que vous puissiez reprendre le workflow depuis la dernière tâche persistée (ou checkpoint), au lieu de recommencer le workflow depuis le début.
  • Robustesse. Récupération automatisée des pannes. Les flux de travail survivent aux redémarrages planifiés ou non planifiés. Vous pouvez suspendre l’exécution du workflow puis reprendre le workflow depuis le dernier point de persistance. Les auteurs de workflows peuvent désigner des activités spécifiques à relancer en cas de défaillance sur un ou plusieurs nœuds gérés.
  • Possibilité de se déconnecter, se reconnecter et exécuter lors de sessions déconnectées. Les utilisateurs peuvent se connecter et se déconnecter du serveur de workflow, mais le workflow s’exécute en continu. Vous pouvez vous déconnecter de l’ordinateur client ou le redémarrer et surveiller l’exécution du flux de travail depuis un autre ordinateur sans interrompre le flux de travail.
  • Planification. Les tâches de workflow peuvent être planifiées comme n’importe quel cmdlet ou script Windows PowerShell.
  • Limitation du flux de travail et des connexions. L’exécution du flux de travail et les connexions aux nœuds peuvent être limitées, permettant ainsi des scénarios de grande scalabilité et de haute disponibilité.

Windows PowerShell Accès Web

Windows PowerShell Web Access est une fonctionnalité de Windows Server 2012 qui permet aux utilisateurs d’exécuter des commandes et scripts Windows PowerShell dans une console web. Les appareils utilisant la console web ne nécessitent pas Windows PowerShell, ni logiciel de gestion à distance, ni installation de plug-ins navigateur. Tout ce qui est nécessaire est une passerelle Windows PowerShell Web Access correctement configurée et un navigateur client qui prenne en charge JavaScript et accepte les cookies.

Pour plus d’informations, voir Déploiement de Windows PowerShell Web Access.

Nouvelles fonctionnalités ISE de Windows PowerShell

Pour Windows PowerShell 3.0, l’Environnement de Scripting Intégré (ISE) Windows PowerShell propose de nombreuses nouveautés, notamment IntelliSense, Show-Command fenêtre, un panneau console unifié, des extraits, l’appariement des crochets, des sections d’extension-relaps, la sauvegarde automatique, la liste des éléments récents, la copie enrichie, la copie par blocs, et la prise en charge complète de l’écriture de workflows de scripts Windows PowerShell. Pour plus d’informations, voir about_Windows_PowerShell_ISE.

Prise en charge de Microsoft .NET Framework 4

Windows PowerShell est conçu selon le Common Language Runtime 4.0. Les auteurs de cmdlets, scripts et workflows peuvent utiliser les nouvelles classes Microsoft .NET Framework 4 dans Windows PowerShell, avec des fonctionnalités telles que la compatibilité et le déploiement des applications, le Managed Extensability Framework, le Parallel Computing, le réseau, Windows Communication Foundation et Windows Workflow Foundation.

Prise en charge de l’environnement de préinstallation Windows

Windows PowerShell 3.0 est un composant optionnel de l’environnement de préinstallation Windows (Windows PE) 4.0 pour Windows 8. Windows PE est un système d’exploitation minimal qui démarre un ordinateur sans système d’exploitation et le prépare à l’installation sous Windows. Windows PE peut être utilisé pour partitionner et formater des disques durs, copier des images de disque sur un ordinateur et initier la configuration de Windows depuis un partage réseau. Windows PowerShell 3.0 peut être utilisé sur Windows PE pour gérer les scénarios de déploiement, de diagnostic et de récupération.

Sessions déconnectées

À partir de Windows PowerShell 3.0, les sessions gérées par l’utilisateur persistantes (« PSSessions ») que vous créez à l’aide du cmdlet New-PSSession sont sauvegardées sur l’ordinateur distant. Ils ne dépendent plus de la session lors de laquelle ils ont été créés.

Vous pouvez désormais vous déconnecter d’une session sans perturber les commandes qui s’exécutent dans la session. Vous pouvez fermer la session et éteindre votre ordinateur. Plus tard, vous pouvez vous reconnecter à la session depuis une autre session sur le même ordinateur ou sur un autre ordinateur.

Le paramètre ComputerName du Get-PSSession cmdlet reçoit désormais toutes les sessions de l’utilisateur qui se connectent à l’ordinateur, même si elles ont été lancées dans une session différente sur un autre ordinateur. Vous pouvez vous connecter aux sessions, obtenir les résultats des commandes, lancer de nouvelles commandes, puis vous déconnecter de la session.

De nouveaux cmdlets ont été ajoutés pour prendre en charge la fonctionnalité Disconnected Sessions, notamment Disconnect-PSSession, Connect-PSSession, et Receive-PSSession, et de nouveaux paramètres ont été ajoutés aux cmdlets qui gèrent les PSSessions, tels que le paramètre InDisconnectedSession du Invoke-Command cmdlet.

La fonctionnalité Sessions Déconnectées n’est prise en charge que lorsque les ordinateurs situés à la fois au niveau d’origine (« client ») et de terminaison (« serveur ») de la connexion exécutent Windows PowerShell 3.0.

Connectivité robuste en session

Windows PowerShell 3.0 détecte des pertes inattendues de connectivité entre le client et le serveur et tente de rétablir la connectivité et de reprendre l’exécution automatiquement. Si la connexion client-serveur ne peut être rétablie dans le temps imparti, l’utilisateur est informé et la session est déconnectée. Lors de la tentative de reconnexion, Windows PowerShell fournit un retour continu à l’utilisateur.

Si la session déconnectée a été lancée via InvokeCommand, Windows PowerShell crée un travail pour la session déconnectée afin de faciliter la reconnexion et la reprise de l’exécution.

Ces fonctionnalités offrent une expérience de télécommande plus fiable et récupérable et permettent aux utilisateurs d’effectuer des tâches de longue durée nécessitant des sessions robustes, telles que des flux de travail.

Système d’aide à mise à jour

Vous pouvez désormais télécharger des fichiers d’aide mis à jour pour les cmdlets dans vos modules. Le Update-Help cmdlet identifie les fichiers d’aide les plus récents, les télécharge depuis Internet, les décompacte, les valide et les installe dans le répertoire spécifique au bon langage pour le module.

Pour utiliser les fichiers d’aide mis à jour, il suffit de taper Get-Help. Vous n’avez pas besoin de redémarrer Windows ou Windows PowerShell. Pour mettre à jour l’aide aux modules dans le répertoire $pshome, lancez Windows PowerShell avec l’option « Exécuter en tant qu’administrateur ».

Pour soutenir les utilisateurs n’ayant pas accès à Internet et ceux derrière des pare-feux, le nouveau Save-Help cmdlet télécharge les fichiers d’aide dans un répertoire du système de fichiers, tel qu’un partage de fichiers. Les utilisateurs peuvent alors utiliser le Update-Help cmdlet pour obtenir des fichiers d’aide mis à jour depuis le partage de fichiers.

Vous pouvez utiliser le Update-Help cmdlet pour mettre à jour les fichiers d’aide pour tous ou certains modules dans toutes les cultures d’interface supportées. Vous pouvez même mettre une Update-Help commande dans votre profil PowerShell de Windows. Par défaut, Windows PowerShell télécharge les fichiers d’aide d’un module au maximum une fois par jour.

Les modules Windows 8 et Windows Server 2012 n’incluent pas de fichiers d’aide. Pour télécharger les derniers fichiers d’aide, tapez Update-Help. Pour plus d’informations, tapez Get-Help (sans paramètres) ou consultez about_Updatable_Help.

Lorsque les fichiers d’aide d’un cmdlet ne sont pas installés sur l’ordinateur, le Get-Help cmdlet affiche désormais l’aide générée automatiquement. L’aide générée automatiquement inclut la syntaxe des commandes et les instructions pour utiliser le Update-Help cmdlet afin de télécharger les fichiers d’aide.

Tout auteur de module peut prendre en charge l’aide à mise à jour pour son module. Vous pouvez inclure des fichiers d’aide dans le module et utiliser Updatable Help pour les mettre à jour ou omettre les fichiers d’aide et utiliser Updatable Help pour les installer. Pour plus d’informations sur le soutien à l’aide à mise à jour, consultez Aide à l’aide mise à jour.

Aide en ligne améliorée

L’aide en ligne Windows PowerShell est une ressource précieuse pour tous les utilisateurs, mais elle est particulièrement importante pour ceux qui n’installent pas ou ne peuvent pas installer les fichiers d’aide mis à jour.

Pour obtenir de l’aide en ligne pour tout commandlet PowerShell Windows, tapez :

Get-Help <cmdlet-name> -Online

Windows PowerShell ouvre la version en ligne du sujet d’aide dans votre navigateur Internet par défaut.

La fonction Get-Help -Online dans Windows PowerShell 3.0 est désormais encore plus puissante car elle fonctionne même lorsque les fichiers d’aide du cmdlet ne sont pas installés sur l’ordinateur. La fonctionnalité Get-Help -Online obtient l’URI pour le sujet d’aide en ligne à partir de la propriété HelpUri des cmdlets et fonctions avancées.

PS C:\>(Get-Command Get-ScheduledJob).HelpUri
https://go.microsoft.com/fwlink/?LinkID=223923

À partir de Windows PowerShell 3.0, les auteurs de cmdlets C# peuvent remplir la propriété HelpUri en créant un attribut HelpUri sur la classe cmdlet. Les auteurs de fonctions avancées peuvent définir une propriété HelpUri sur l’attribut CmdletBinding . La valeur de la propriété HelpUri doit commencer par « http » ou « https ».

Vous pouvez également inclure une valeur HelpUri dans le premier lien lié d’un fichier d’aide cmdlet basé sur XML ou dans le fichier . Directive de lien pour l’aide basée sur les commentaires dans une fonction.

Pour plus d’informations sur le soutien à l’aide en ligne, consultez Soutien en ligne.

Intégration CIM

Windows PowerShell 3.0 inclut la prise en charge du Common Information Model (CIM), qui fournit des définitions communes des informations de gestion pour les systèmes, réseaux, applications et services, permettant ainsi l’échange d’informations de gestion entre systèmes hétérogènes. Le support de CIM dans Windows PowerShell 3.0, y compris la possibilité de créer des cmdlets Windows PowerShell basés sur des classes CIM nouvelles ou existantes, des commandes basées sur des fichiers XML définis par cmdlets, et la prise en charge de CIM .NET Framework. API, cmdlets de gestion CIM et fournisseurs WMI 2.0.

Fichiers de configuration de session

À partir de Windows PowerShell 3.0, vous pouvez concevoir une configuration de session personnalisée à l’aide d’un fichier. Le nouveau fichier de configuration de session vous permet de déterminer l’environnement des sessions qui utilisent la configuration de session, y compris quels modules, scripts et fichiers de format sont chargés dans les sessions, quels cmdlets et éléments de langage les utilisateurs peuvent utiliser, quels modules et scripts ils peuvent exécuter, et quelles variables ils peuvent voir.

Vous pouvez concevoir une session dans laquelle les utilisateurs ne peuvent exécuter les cmdlets que d’un module particulier, ou une session où les utilisateurs ont un langage complet, accès à tous les modules, et accès à des scripts qui effectuent des tâches avancées.

Dans les versions précédentes de Windows PowerShell, le contrôle à ce niveau n’était accessible qu’à ceux qui pouvaient écrire un programme C# ou un script de démarrage complexe. Désormais, tout membre du groupe Administrateurs sur l’ordinateur peut personnaliser une configuration de session à l’aide d’un fichier de configuration.

Pour créer un fichier de configuration de session, utilisez l’applet de commande New-PSSessionConfigurationFile. Pour appliquer le fichier de configuration de session à une configuration de session, utilisez les Register-PSSessionConfiguration cmdlets ou 'Set-PSSessionConfiguration.

Pour plus d’informations, voir about_Session_Configuration_Files et New-PSSessionConfigurationFile.

Tâches planifiées et intégration du planificateur de tâches

Vous pouvez désormais planifier les tâches en arrière-plan de Windows PowerShell et les gérer dans Windows PowerShell et dans l’ordonnanceur des tâches.

Les tâches planifiées PowerShell de Windows sont un hybride utile entre les tâches en arrière-plan de Windows PowerShell et les tâches du planificateur des tâches.

Comme les tâches en arrière-plan de Windows PowerShell, les tâches planifiées s’exécutent de façon asynchrone en arrière-plan. Les instances de tâches planifiées qui ont été terminées peuvent être gérées à l’aide des cmdlets de tâches, telles que Start-Job et Get-Job.

Comme les tâches du planificateur de tâches, vous pouvez exécuter des tâches planifiées selon un emploi du temps ponctuel ou récurrent, ou en réponse à une action ou un événement. Vous pouvez visualiser et gérer les tâches planifiées dans le planificateur des tâches, les activer et les désactiver selon les besoins, les exécuter ou les utiliser comme modèles, et définir les conditions dans lesquelles les tâches commencent.

De plus, les tâches planifiées sont accompagnées d’un ensemble personnalisé de commandes pour les gérer. Les cmdlets vous permettent de créer, modifier, gérer, désactiver et réactiver les tâches planifiées, de créer des déclencheurs de tâches planifiées et de définir des options de tâches planifiées.

Pour plus d’informations sur les emplois programmés, voir about_Scheduled_Jobs.

Améliorations du langage PowerShell Windows

Windows PowerShell 3.0 inclut de nombreuses fonctionnalités conçues pour simplifier son langage, faciliter l’utilisation et éviter les erreurs courantes. Les améliorations incluent l’énumération des propriétés, les propriétés de comptage et de longueur sur les objets scalaires, de nouveaux opérateurs de redirection, le modificateur de portée $Using, la variable automatique PSItem, la mise en forme flexible des scripts, les attributs des variables, des arguments d’attributs simplifiés, les noms de commandes numériques, l’opérateur Stop-Parsing, l’amélioration du splatting des tableaux, de nouveaux opérateurs de bits, des dictionnaires ordonnés, le casting PSCustomObject, et une aide améliorée basée sur les commentaires.

Nouveaux Commandlets de Noyau

De nouveaux commandlets ont été ajoutés à l’installation Windows PowerShell, incluant des cmdlets pour gérer les tâches planifiées, les sessions déconnectées, l’intégration CIM et le système d’aide Updatable.

  • CimCmdlets
    • Get-CimAssociatedInstance
    • Get-CimClass
    • Get-CimInstance
    • Get-CimSession
    • Invoke-CimMethod
    • New-CimInstance
    • New-CimSession
    • New-CimSessionOption
    • Register-CimIndicationEvent
    • Remove-CimInstance
    • Remove-CimSession
    • Set-CimInstance
  • Microsoft.PowerShell.Core
    • Connect-PSSession
    • Disconnect-PSSession
    • New-PSSessionConfigurationFile
    • New-PSTransportOption
    • Receive-PSSession
    • Resume-Job
    • Save-Help
    • Suspend-Job
    • Test-PSSessionConfigurationFile
    • Update-Help
  • Microsoft.PowerShell.Diagnostics
    • New-WinEvent
  • Microsoft.PowerShell.Management
    • Get-ControlPanelItem
    • Rename-Computer
    • Show-ControlPanelItem
  • Microsoft.PowerShell.Utility
    • ConvertFrom-Json
    • ConvertTo-Json
    • Get-TypeData
    • Invoke-RestMethod
    • Invoke-WebRequest
    • Remove-TypeData
    • Show-Command
    • Unblock-File
  • PSScheduledJob
    • Add-JobTrigger
    • Disable-JobTrigger
    • Disable-ScheduledJob
    • Enable-JobTrigger
    • Enable-ScheduledJob
    • Get-JobTrigger
    • Get-ScheduledJob
    • Get-ScheduledJobOption
    • New-JobTrigger
    • New-ScheduledJobOption
    • Register-ScheduledJob
    • Set-JobTrigger
    • Set-ScheduledJob
    • Set-ScheduledJobOption
    • Unregister-ScheduledJob
  • PSWorkflow
    • New-PSWorkflowExecutionOption
    • New-PSWorkflowSession
  • PSWorkflowUtility
    • Invoke-AsWorkflow
  • ISE
    • Get-IseSnippet
    • Import-IseSnippet
    • New-IseSnippet

Améliorations des Cmdlets et Fournisseurs Core existants

Windows PowerShell 3.0 inclut de nouvelles fonctionnalités pour les cmdlets existants, notamment la syntaxe simplifiée, ainsi que de nouveaux paramètres pour les cmdlets suivants : commandets ordinateur, cmdlets CSV, Get-ChildItem, Get-Command, Get-Content, Get-History, Measure-Object, commandlets de sécurité, Select-Object, Select-String, Split-Path, Start-Process, Tee-Object, Test-Connection, Add-Member et WMI cmdlets.

Les fournisseurs Windows PowerShell ont également été considérablement améliorés, notamment le support des fournisseurs de certificats pour la gestion des certificats Secure Socket Layer (SSL) pour l’hébergement web, la prise en charge des identifiants, les disques réseau persistants et les flux de données alternatifs dans les disques du système de fichiers.

Importation et découverte de modules à distance

Windows PowerShell 3.0 étend les capacités de découverte, d’importation et de télécommande implicite de modules sur les ordinateurs distants. Les commandlets de module reçoivent des modules sur des ordinateurs distants et importent les modules sur l’ordinateur distant ou local via Windows PowerShell à distance. Le nouveau support des sessions CIM permet d’utiliser CIM et WMI pour gérer des ordinateurs non-Windows en important des commandes sur l’ordinateur local qui s’exécutent implicitement sur l’ordinateur distant.

Pour plus d’informations, consultez les sujets d’aide pour les Get-Module cmdlets et Import-Module et (et cmdlets).

Complétion améliorée des onglets

La complétion d’onglet dans la console PowerShell Windows complète désormais les noms des cmdlets, paramètres, valeurs de paramètres, énumérations, types de .NET Frameworks, objets COM, répertoires cachés, et plus encore. La fonction de complétion d’onglet est entièrement réécrite grâce à un nouvel analyseur syntaxique et un arbre de syntaxe abstraite pour prendre en charge davantage de scénarios, y compris les arbres d’analyse en mémoire et la complétion de tabulation à mi-ligne.

Chargement automatique des modules

Le Get-Command cmdlet reçoit désormais tous les cmdlets et fonctions de tous les modules installés sur l’ordinateur, même si le module n’est pas importé dans la session courante.

Quand vous obtenez le cmdlet dont vous avez besoin, vous pouvez l’utiliser immédiatement sans importer de modules. Les modules PowerShell Windows sont désormais importés automatiquement lorsque vous utilisez n’importe quel cmdlet dans le module. Vous n’avez plus besoin de chercher le module et de l’importer pour utiliser ses cmdlets.

L’importation automatique de modules est déclenchée en utilisant le cmdlet dans une commande, en exécutant Get-Command pour un cmdlet sans jokers, ou en Get-Help exécutant pour un cmdlet sans jokers.

Vous pouvez activer, désactiver et configurer l’importation automatique de modules en utilisant la variable de préférence $PSModuleAutoLoadingPreference .

Pour plus d’informations, voir about_Modules, about_Preference_Variables et les sujets d’aide pour les Get-Command cmdlets et Import-Module et .

Améliorations de l’expérience des modules

Windows PowerShell 3.0 apporte un support avancé de fonctionnalités aux modules, y compris les nouveautés suivantes.

  1. Journalisation des modules individuels (LogPipelineExecutionDetails) et le nouveau paramètre « Activer la journalisation des modules »
  2. Objets modules étendus qui exposent les valeurs du manifeste du module
  3. Nouvelle propriété ExportedCommands des modules, y compris les modules imbriqués, qui combine toutes sortes de commandes
  4. Découverte améliorée des modules disponibles (non importés), y compris la possibilité d’autoriser les paramètres Path et ListAvailable dans la même commande
  5. Nouvelle clé DefaultCommandPrefix dans les manifestes du module qui évite les conflits de noms sans changer le code du module.
  6. Exigences améliorées des modules, incluant des modules obligatoires entièrement qualifiés avec version et GUID ainsi que l’importation automatique des modules requis
  7. Fonctionnement plus calme et rationalisé du New-ModuleManifest commandant.
  8. Nouveau paramètre de module pour #Requires
  9. Cmdlet amélioré Import-Module avec les paramètres MinimumVersion et RequiredVersion .

Découverte simplifiée des commandes

Vous n’avez plus besoin d’importer tous les modules pour découvrir les commandes disponibles pour votre session. Dans Windows PowerShell 3.0, le Get-Command cmdlet reçoit toutes les commandes de tous les modules installés. Et, si vous utilisez une commande, le module qui exporte la commande est automatiquement importé dans votre session.

Le nouveau Show-Command cmdlet est spécialement conçu pour les débutants. Vous pouvez chercher des commandes dans une fenêtre. Vous pouvez voir toutes les commandes ou filtrer par module, importer un module en cliquant sur un bouton, utiliser des boîtes de texte et des listes déroulantes pour construire une commande valide, puis copier ou exécuter la commande sans jamais quitter la fenêtre.

Amélioration de la journalisation, du diagnostic et du support des politiques de groupe

Windows PowerShell 3.0 améliore la prise en charge de la journalisation et de la traçabilité pour les commandes et modules grâce à la prise en charge des journaux Event Tracing in Windows (ETW), une propriété éditable LogPipelineExecutionDetails des modules, et le paramètre de politique de groupe « Activer la journalisation des modules ». Vous pouvez désormais obtenir des valeurs de paramètres à partir des détails du journal en affichant les propriétés du journal.

Mise en forme et améliorations de sortie

De nouvelles améliorations de mise en forme et de sortie améliorent l’efficacité de tous les utilisateurs de Windows PowerShell. Les améliorations incluent la redirection de sortie pour tous les flux, un cmdlet Update-Type amélioré qui ajoute des types dynamiquement sans fichiers Format.ps1xml, un encapsulement de mots en sortie, des propriétés de formatage par défaut des objets personnalisés, le type PSCustomObject , une mise en forme améliorée pour les objets WMI et hétérogènes, ainsi que la prise en charge de la découverte des surcharges de méthodes.

Expérience hôte console améliorée

Le programme hôte de la console Windows PowerShell propose de nouvelles fonctionnalités dans Windows PowerShell 3.0, notamment un appartement monothread par défaut. La nouvelle option « Exécuter avec PowerShell » dans l’Explorateur de fichiers vous permet d’exécuter des scripts en session sans restriction simplement en cliquant droit. La nouvelle logique de lancement de l’hôte console démarre Windows PowerShell plus rapidement et de nouvelles polices vous permettent de personnaliser l’expérience familière de la fenêtre console.

Nouveau cmdlet et API d’hébergement

La nouvelle API Cmdlet et l’API d’hébergement incluent des API publiques à arbres de syntaxe avancée (AST), ainsi que des API pour le paginage de pipelines, les pipelines imbriqués, la complétion des onglets des pools d’espace exécutif, Windows RT, l’attribut cmdlet Obsolete, ainsi que les propriétés Verbe et nom de l’objet FunctionInfo.

Améliorations des performances

Des améliorations significatives de performance dans Windows PowerShell proviennent du nouveau parseur du langage, construit sur le Dynamic Runtime Language (DLR) dans .NET Framework 4, ainsi que de la compilation de scripts à l’exécution, des améliorations de fiabilité du moteur et des modifications de l’algorithme Get-ChildItem qui améliorent ses performances, notamment lors de la recherche de partages réseau.

RunAs et support des hôtes partagés

Windows PowerShell 3.0 inclut la prise en charge des fonctionnalités RunAs et Shared Host.

La fonctionnalité RunAs , conçue pour le flux de travail PowerShell de Windows, permet aux utilisateurs d’une configuration de session de créer des sessions qui s’exécutent avec la permission d’un compte utilisateur partagé. Cela permet aux utilisateurs moins privilégiés d’exécuter certaines commandes et scripts avec des permissions d’administrateur, et réduit la nécessité d’ajouter des utilisateurs moins expérimentés au groupe Administrateurs.

La fonctionnalité SharedHost permet à plusieurs utilisateurs sur plusieurs ordinateurs de se connecter simultanément à une session de workflow et de suivre l’évolution de ce workflow. Les utilisateurs peuvent lancer un flux de travail sur un ordinateur puis se connecter à la session de workflow sur un autre ordinateur sans déconnecter la session de l’ordinateur d’origine. Les utilisateurs doivent avoir les mêmes permissions et utiliser la même configuration de session. Pour plus d’informations, consultez « Exécuter un flux de travail Windows PowerShell » dans Démarrer avec le flux de travail Windows PowerShell.

Améliorations spéciales de la gestion des personnages

Pour améliorer la capacité de Windows PowerShell 3.0 à interpréter et gérer correctement les caractères spéciaux, le paramètre LiteralPath , qui gère les caractères spéciaux dans les chemins, est valable sur presque tous les cmdlets possédant un paramètre Path , y compris les nouveaux Update-Help et Save-Help cmdlets. L’analyseur inclut également une logique spéciale pour améliorer la gestion du caractère rétrotick (`) et des crochets dans les noms et chemins des fichiers.

Voir aussi