Différences entre Windows PowerShell 5.1 et PowerShell 7.x

Windows PowerShell 5.1 repose sur .NET Framework v4.5. Avec la sortie de PowerShell 6.0, PowerShell est devenu un projet open source utilisant .NET Core 2.0. Le passage du .NET Framework à .NET Core a permis à PowerShell de devenir une solution multiplateforme. PowerShell s’exécute sur les plateformes Windows, macOS et Linux.

Il y a peu de différences dans le langage PowerShell entre Windows PowerShell et PowerShell. Les différences les plus notables concerne la disponibilité et le comportement des applets de commande PowerShell entre les plateformes Windows et non-Windows, et les changements qui résultent des différences entre le .NET Framework et .NET Core.

Cet article récapitule les différences significatives et les changements cassants entre Windows PowerShell et la version actuelle de PowerShell. Ce récapitulatif ne comprend pas les nouvelles fonctionnalités ou les applets de commande qui ont été ajoutées. Cet article ne traite pas non plus de ce qui a changé entre les versions. L’objectif de cet article est de présenter l’état actuel de PowerShell et en quoi il diffère de Windows PowerShell. Pour une présentation détaillée des changements entre les versions et des nouvelles fonctionnalités ajoutées, consultez les articles Nouveautés de chaque version.

• Nouveautés de PowerShell 7.5
• Nouveautés de PowerShell 7.4
• Nouveautés de PowerShell 7.3
• Nouveautés de PowerShell 7.2
• Nouveautés de PowerShell 7.1
• Nouveautés de PowerShell 7.0
• Nouveautés de PowerShell 6.x

Comparaison entre le .NET Framework et .NET Core

PowerShell sur Linux et macOS utilise .NET Core, qui est un sous-ensemble de la version complète du .NET Framework sur Microsoft Windows. C’est un point important, car PowerShell offre un accès direct aux types et méthodes du framework sous-jacent. Par conséquent, les scripts qui s’exécutent sous Windows risquent de ne pas fonctionner sur les plateformes autres que Windows en raison des différences d’infrastructure. Pour plus d’informations sur les changements de .NET Core, consultez Changements cassants pour la migration du .NET Framework vers .NET Core.

Chaque nouvelle version de PowerShell repose sur une version plus récente de .NET. Il peut y avoir des changements cassants dans .NET qui affectent PowerShell.

• PowerShell 7.5 – Basée sur .NET 9.0
• PowerShell 7.4 – Basée sur .NET 8.0
• PowerShell 7.3 – Basée sur .NET 7.0
• PowerShell 7.2 (LTS-current) – Basée sur .NET 6.0 (LTS-current)
• PowerShell 7.1 – Basée sur .NET 5.0
• PowerShell 7.0 (LTS) – Basée sur .NET Core 3.1 (LTS)
• PowerShell 6.2 – Basée sur .NET Core 2.1
• PowerShell 6.1 – Basée sur .NET Core 2.1
• PowerShell 6.0 – Basée sur .NET Core 2.0

Avec l’avènement de .NET Standard 2.0, PowerShell peut charger de nombreux modules Windows PowerShell traditionnels sans modification. Par ailleurs, PowerShell 7 intègre une fonctionnalité de compatibilité Windows PowerShell vous permettant d’utiliser des modules Windows PowerShell qui ont encore besoin du framework complet.

Pour plus d’informations, consultez les pages suivantes :

• about_Windows_PowerShell_Compatibility
• Compatibilité des modules PowerShell 7

Tenez compte des modifications apportées aux méthodes .NET

Bien que les modifications apportées aux méthodes .NET ne soient pas spécifiques à PowerShell, elles peuvent affecter vos scripts, en particulier si vous appelez directement des méthodes .NET. En outre, il peut y avoir de nouvelles surcharges pour les constructeurs. Cela peut avoir un impact sur la façon dont vous créez des objets à l’aide de la méthode New-Object ou [type]::new().

Par exemple, .NET a ajouté des surcharges à la méthode [System.String]::Split() qui ne sont pas disponibles dans .NET Framework 4.5. La liste suivante présente les surcharges de la méthode Split() disponible dans Windows PowerShell 5.1 :

PS> "".Split

OverloadDefinitions
-------------------
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

La liste suivante présente les surcharges de la méthode Split() disponible dans PowerShell 7 :

"".Split

OverloadDefinitions
-------------------
string[] Split(char separator, System.StringSplitOptions options)
string[] Split(char separator, int count, System.StringSplitOptions options)
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string separator, System.StringSplitOptions options)
string[] Split(string separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

Dans Windows PowerShell 5.1, vous pouvez passer un tableau de caractères (char[]) à la méthode Split() en tant que string. La méthode fractionne la chaîne cible à n’importe quelle occurrence d’un caractère dans le tableau. La commande suivante fractionne la chaîne cible dans Windows PowerShell 5.1, mais pas dans PowerShell 7 :

# PowerShell 7 example
"1111p2222q3333".Split('pq')

1111p2222q3333

Pour lier la surcharge correcte, vous devez convertir la chaîne de caractères en tableau de caractères :

# PowerShell 7 example
"1111p2222q3333".Split([char[]]'pq')

1111
2222
3333

Modules qui ne sont plus fournis avec PowerShell

Pour différentes raisons de compatibilité, les modules suivants ne sont plus fournis dans PowerShell.

• ISE
• Microsoft.PowerShell.LocalAccounts
• Microsoft.PowerShell.ODataUtils
• Microsoft.PowerShell.Operation.Validation
• PSScheduledJob
• PSWorkflow
• PSWorkflowUtility

PowerShell Workflow

PowerShell Workflow est une fonctionnalité de Windows PowerShell qui s’appuie sur Windows Workflow Foundation (WF) et permet de créer des runbooks robustes pour les tâches de longue durée ou parallélisées.

En raison du manque de support pour Windows Workflow Foundation dans .NET Core, nous avons supprimé le workflow PowerShell dans PowerShell.

À l’avenir, nous aimerions activer le parallélisme/la concurrence natif(ve) dans le langage PowerShell sans utiliser PowerShell Workflow.

S’il est nécessaire d’utiliser des points de contrôle pour reprendre un script après le redémarrage du système d’exploitation, nous vous recommandons d’utiliser Planificateur de tâches pour exécuter un script au démarrage du système d’exploitation, mais le script doit conserver son propre état (par exemple, le rendre persistant dans un fichier).

Applets de commande supprimées de PowerShell

Dans les modules fournis avec PowerShell, les applets de commande suivantes ont été supprimées de PowerShell pour différentes raisons de compatibilité ou parce qu’elles utilisent des API non prises en charge.

CimCmdlets

• Export-BinaryMiLog

Microsoft.PowerShell.Core

• Add-PSSnapin
• Export-Console
• Get-PSSnapin
• Remove-PSSnapin
• Resume-Job
• Suspend-Job

Microsoft.PowerShell.Diagnostics

• Export-Counter
• Import-Counter

Microsoft.PowerShell.Management

• Add-Computer
• Checkpoint-Computer
• Clear-EventLog
• Complete-Transaction
• Disable-ComputerRestore
• Enable-ComputerRestore
• Get-ComputerRestorePoint
• Get-ControlPanelItem
• Get-EventLog
• Get-Transaction
• Get-WmiObject
• Invoke-WmiMethod
• Limit-EventLog
• New-EventLog
• New-WebServiceProxy
• Register-WmiEvent
• Remove-Computer
• Remove-EventLog
• Remove-WmiObject
• Reset-ComputerMachinePassword
• Restore-Computer
• Set-WmiInstance
• Show-ControlPanelItem
• Show-EventLog
• Start-Transaction
• Test-ComputerSecureChannel
• Undo-Transaction
• Use-Transaction
• Write-EventLog

Microsoft.PowerShell.Utility

• Convert-String
• ConvertFrom-String

PSDesiredStateConfiguration

• Disable-DscDebug
• Enable-DscDebug
• Get-DscConfiguration
• Get-DscConfigurationStatus
• Get-DscLocalConfigurationManager
• Publish-DscConfiguration
• Remove-DscConfigurationDocument
• Restore-DscConfiguration
• Set-DscLocalConfigurationManager
• Start-DscConfiguration
• Stop-DscConfiguration
• Test-DscConfiguration
• Update-DscConfiguration

Cmdlets WMI v1

Les applets de commande WMI v1 suivantes ont été supprimées de PowerShell :

• Register-WmiEvent
• Set-WmiInstance
• Invoke-WmiMethod
• Get-WmiObject
• Remove-WmiObject

Les applets de commande du module CimCmdlets (ou WMI v2) ont la même fonction, et offrent de nouvelles fonctionnalités et une syntaxe repensée.

Cmdlet New-WebServiceProxy supprimée

.NET Core ne prend pas en charge l’infrastructure de communication Windows, qui fournit des services pour l’utilisation du protocole SOAP. Cette cmdlet a été supprimée, car elle nécessite SOAP.

Cmdlets *-Transaction supprimées

Ces cmdlets ont une utilisation très limitée. Il a été décidé de ne plus les prendre en charge.

• Complete-Transaction
• Get-Transaction
• Start-Transaction
• Undo-Transaction
• Use-Transaction

Cmdlets *-EventLog

En raison de l’utilisation d’API non prises en charge, les applets de commande *-EventLog ont été supprimées de PowerShell. Get-WinEvent et New-WinEvent sont disponibles pour obtenir et créer des événements sur Windows.

Les applets de commande qui utilisent Windows Presentation Framework (WPF)

Comme .NET Core 3.1 prend maintenant en charge WPF, la version de PowerShell 7.0 a restauré les fonctionnalités suivantes propres à Windows :

• L’applet de commande Show-Command
• L’applet de commande Out-GridView
• Le paramètre ShowWindow de Get-Help

Changements de PowerShell Desired State Configuration (DSC)

Invoke-DscResource a été restauré sous forme de fonctionnalité expérimentale dans PowerShell 7.0.

À partir de PowerShell 7.2, le module PSDesiredStateConfiguration est supprimé de PowerShell et publié dans PowerShell Gallery. Pour plus d’informations, consultez l’annonce dans le blog de l’équipe PowerShell.

Modifications de l’exécutable PowerShell

powershell.exe renommé en pwsh.exe

Le nom binaire de PowerShell powershell(.exe) a été remplacé par pwsh(.exe). Ce changement fournit aux utilisateurs un moyen déterministe d’exécuter PowerShell sur les machines, et de prendre en charge les installations de Windows PowerShell et PowerShell côte à côte.

Autres modifications apportées à pwsh(.exe) par rapport à powershell.exe :

• Remplacement du premier paramètre positionnel -Command par -File. Cette modification résout l’utilisation de #! (également appelé shebang) dans les scripts PowerShell qui sont exécutés à partir de shells autres que PowerShell sur des plateformes non-Windows. Cela signifie également que vous pouvez exécuter des commandes telles que pwsh foo.ps1 ou pwsh fooScript sans spécifier -File. Toutefois, cette modification nécessite que vous indiquiez explicitement -c ou -Command quand vous essayez d’exécuter des commandes telles que pwsh.exe -Command Get-Command.
• pwsh accepte le commutateur -i (ou -Interactive) pour indiquer un interpréteur de commandes interactif. Cela permet d’utiliser PowerShell comme interpréteur de commandes par défaut sur les plateformes UNIX.
• Paramètres -ImportSystemModules et -PSConsoleFile supprimés de pwsh.exe.
• Modification de pwsh -version et de l’aide intégrée pour pwsh.exe afin de s’aligner sur les autres outils natifs.
• Messages d’erreur d’argument non valide pour -File et -Command, et codes de sortie conformes aux standards UNIX
• Ajout du paramètre -WindowStyle sur Windows. De même, les mises à jour d’installations à partir de package sur des plateformes non-Windows sont des mises à jour sur place.

Le nom abrégé est également cohérent avec la désignation des shells sur les plateformes non Windows.

Prise en charge de l’exécution d’un script PowerShell avec un paramètre booléen

Auparavant, l’utilisation de pwsh.exe pour exécuter un script PowerShell à l’aide de -File ne fournissait aucun moyen de passer $true/$false comme valeurs de paramètre. La prise en charge de $true/$false comme valeurs analysées des paramètres a été ajoutée. Les valeurs de commutateur sont également prises en charge.

Compatibilité descendante avec Windows PowerShell améliorée

Pour Windows, un nouveau paramètre de commutateur UseWindowsPowerShell est ajouté à Import-Module. Ce commutateur crée un module proxy dans PowerShell 7, qui utilise un processus Windows PowerShell local pour exécuter implicitement toutes les cmdlets contenues dans ce module. Pour plus d’informations, voir Import-Module.

Pour plus d’informations sur les modules Microsoft fonctionnant avec PowerShell 7.0, consultez le tableau de compatibilité des modules.

Prise en charge de Microsoft Update pour Windows

PowerShell 7.2 a ajouté la prise en charge de Microsoft Update. Quand vous activez cette fonctionnalité, vous obtenez les dernières mises à jour de PowerShell 7 dans votre flux de gestion Windows Update (WU) traditionnel, que ce soit avec Windows Update pour Entreprise, WSUS, SCCM ou la boîte de dialogue WU interactive dans Paramètres.

Le package MSI PowerShell 7.2 comprend les options de ligne de commande suivantes :

• USE_MU – cette propriété a deux valeurs possibles :
  • 1 (par défaut) : opte pour la mise à jour par le biais de Microsoft Update ou WSUS
  • 0 - ne pas opter pour la mise à jour via Microsoft Update ou WSUS
• ENABLE_MU
  • 1 (par défaut) : opte pour l’utilisation des mises à jour automatiques Microsoft Update ou Windows Update
  • 0 : n’opte pas pour l’utilisation des mises à jour automatiques Microsoft Update ni Windows Update

Modifications du moteur

Prise en charge de PowerShell comme interpréteur de commandes UNIX par défaut

Sous Unix, une convention stipule que les shells doivent accepter -i pour un shell interactif et de nombreux outils attendent ce comportement (script par exemple, et lorsque PowerShell est défini en tant que shell par défaut), et appelle le shell avec le commutateur -i. Il s’agit d’une modification avec rupture, car -i pouvait auparavant être utilisé en tant que paramètre abrégé pour correspondre à -inputformat, qui doit maintenant être -in.

Composants logiciels enfichables personnalisés

Les composants logiciels enfichables PowerShell sont les prédécesseurs des modules PowerShell qui ne bénéficient pas d’une adoption répandue dans la communauté PowerShell.

En raison de la complexité de la prise en charge des composants logiciels enfichables et leur sous-utilisation au sein de la communauté, nous ne prenons plus en charge les composants logiciels enfichables personnalisés dans PowerShell.

Indicateurs de fonctionnalités expérimentales

PowerShell 6.2 a activé la prise en charge des fonctionnalités expérimentales. Cela permet aux développeurs PowerShell de fournir de nouvelles fonctionnalités et d’obtenir des commentaires avant la fin de la conception. Cela nous évite ainsi d’avoir à apporter d’importantes modifications à mesure que la conception évolue.

Utilisez Get-ExperimentalFeature pour obtenir la liste des fonctionnalités expérimentales disponibles. Vous pouvez activer ou désactiver ces fonctionnalités avec Enable-ExperimentalFeature et Disable-ExperimentalFeature.

Chargement de l’assembly à partir du chemin de base du module avant d’essayer de le charger à partir du GAC

Auparavant, quand un module binaire avait l’assembly de module dans le GAC, nous chargions l’assembly à partir du GAC avant de tenter de le charger à partir du chemin de base du module.

Omission de la vérification d’élément null pour les collections avec un élément de type valeur

Pour le paramètre Mandatory et les attributs ValidateNotNull et ValidateNotNullOrEmpty, ignorer la vérification de l’élément null si le type d’élément de la collection est de type valeur.

Conservation de $? pour ParenExpression, SubExpression et ArrayExpression

Cette demande de tirage modifie la façon dont nous compilons les sous-pipelines (...), les sous-expressions $(...) et les expressions de tableau @() afin que $? ne soit pas automatiquement true. À la place, la valeur de $? dépend du résultat du pipeline ou des instructions exécutées.

Correction de $? pour ne pas être $false quand la commande native écrit dans stderr

$? n’est pas défini sur $false quand la commande native écrit dans stderr. Il est courant que les commandes natives écrivent dans stderr sans avoir à indiquer un échec. $? est défini sur $false uniquement quand la commande native a un code de sortie non nul.

Configuration de $ErrorActionPreference pour ne pas affecter la sortie stderr des commandes natives

Il est courant que les commandes natives écrivent dans stderr sans avoir à indiquer un échec. Avec ce changement, la sortie stderr est toujours capturée dans les objets ErrorRecord, mais le runtime n’applique plus $ErrorActionPreference si le ErrorRecord provient d’une commande native.

Changement de $OutputEncoding pour utiliser l’encodage UTF-8 NoBOM au lieu d’ASCII

L’encodage précédent, ASCII (7 bits) causait une modification incorrecte de la sortie dans certains cas. La définition de UTF-8 NoBOM comme valeur par défaut conserve la sortie Unicode avec un encodage pris en charge par la plupart des outils et systèmes d’exploitation.

Unification des applets de commande avec le paramètre -Encoding de type System.Text.Encoding

-Encoding avec la valeur Byte a été supprimé des cmdlets du fournisseur de système de fichiers. Un nouveau paramètre, -AsByteStream, est désormais utilisé pour spécifier qu’un flux d’octets est requis en tant qu’entrée ou que la sortie est un flux d’octets.

Définition de l’encodage New-ModuleManifest sur UTF8NoBOM pour les plateformes non-Windows

Auparavant, New-ModuleManifest créait les manifestes psd1 en UTF-16 avec marque d’ordre d’octet, ce qui est un problème pour les outils Linux. Cette modification avec rupture modifie l’encodage de New-ModuleManifest sur UTF (sans BOM) pour les plateformes non Windows.

Suppression de AllScope de la plupart des alias par défaut

Pour accélérer la création d’étendue, AllScope a été supprimé de la plupart des alias par défaut. AllScope a été conservé pour quelques alias fréquemment utilisés, où la recherche était plus rapide.

-Verbose et -Debug ne remplacent plus $ErrorActionPreference

Auparavant, si -Verbose ou -Debug était spécifié, il remplaçait le comportement de $ErrorActionPreference. Avec cette modification, -Verbose et -Debug n’affectent plus le comportement de $ErrorActionPreference.

De même, le paramètre -Debug définit $DebugPreference sur Continue au lieu de Inquire.

$PSCulture reflète maintenant les changements de culture dans la session de manière cohérente

Dans Windows PowerShell, la valeur de culture actuelle est mise en cache, ce qui peut autoriser la désynchronisation de la valeur quand la culture est changée après le démarrage de la session. Ce comportement de mise en cache est résolu dans PowerShell Core.

Autorisation pour le paramètre nommé explicitement spécifié de remplacer le même paramètre dans la projection de la table de hachage

Avec ce changement, les paramètres nommés de la projection sont déplacés à la fin de la liste de paramètres afin qu’ils soient liés une fois que tous les paramètres nommés explicitement spécifiés sont liés. La liaison de paramètre pour les fonctions simples ne génère pas d’erreur quand un paramètre nommé spécifié est introuvable. Les paramètres nommés inconnus sont liés au paramètre $args de la fonction simple. Le déplacement de la projection à la fin de la liste d’arguments change l’ordre dans lequel les paramètres apparaissent dans $args.

Par exemple :

function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}

Dans le comportement précédent, MyPath n’est pas lié à -Path , car il s’agit du troisième argument dans la liste d’arguments. # # Donc, il finit par être placé dans « $args » avec Blah = "World"

PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath

Avec ce changement, les arguments de @hash sont déplacés à la fin de la liste d’arguments. MyPath devient le premier argument de la liste, donc il est lié à -Path.

PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World

Modifications linguistiques

Opérateur de coalescence Null ??

L’opérateur de coalescence Null ?? retourne la valeur de son opérande gauche s’il n’est pas Null. Dans le cas contraire, il évalue l’opérande droit et retourne son résultat. L’opérateur ?? n’évalue pas son opérande droit si l’opérande gauche a la valeur non Null.

$x = $null
$x ?? 100

100

Dans l’exemple suivant, l’opérande droit n’est pas évalué.

[string] $todaysDate = '1/10/2020'
$todaysDate ?? (Get-Date).ToShortDateString()

1/10/2020

Opérateur d’affectation de fusion Null ??=

L’opérateur d’assignation de fusion Null ??= assigne la valeur de son opérande droit à son opérande gauche uniquement si l’opérande gauche a la valeur Null. L’opérateur ??= n’évalue pas son opérande droit si l’opérande gauche a la valeur non Null.

$x = $null
$x ??= 100
$x

100

Dans l’exemple suivant, l’opérande droit n’est pas évalué.

[string] $todaysDate = '1/10/2020'
$todaysDate ??= (Get-Date).ToShortDateString()

1/10/2020

Null - Opérateurs conditionnel

Notes

Cette fonctionnalité a été déplacée d’expérimentale à standard dans PowerShell 7.1.

Un opérateur conditionnel Null n’applique une opération d'accès à un membre, ?., ou d'accès à un élément, ?[], à son opérande que si cet opérande a la valeur non Null ; sinon, il retourne la valeur Null.

Étant donné que PowerShell permet à ? de faire partie du nom de la variable, la spécification formelle du nom de la variable est requise pour l’utilisation de ces opérateurs. Il est donc nécessaire d’utiliser {} autour des noms de variables comme ${a} ou lorsque ? fait partie du nom de la variable ${a?}.

Dans l’exemple suivant, la valeur de PropName est retournée.

$a = @{ PropName = 100 }
${a}?.PropName

100

L’exemple suivant retourne la valeur Null, sans essayer d’accéder au nom du membre PropName.

$a = $null
${a}?.PropName

De même, la valeur de l’élément est retournée.

$a = 1..10
${a}?[0]

1

Et lorsque l’opérande a la valeur Null, l’élément n’est pas accessible et la valeur Null est retournée.

$a = $null
${a}?[0]

Notes

La syntaxe du nom de variable de ${<name>} ne doit pas être confondue avec l’opérateur de sous-expression $(). Pour plus d’informations, consultez la section Nom de variable about_Variables.

Ajout de l’opérateur & pour le contrôle de tâche

Le caractère & placé à la fin d’un pipeline entraîne l’exécution du pipeline comme une tâche PowerShell. Quand un pipeline est lancé en arrière-plan, un objet de traitement est retourné. Une fois que le pipeline est exécuté en tant que tâche, toutes les applets de commande *-Job standard peuvent être utilisées pour gérer la tâche. Les variables (en ignorant celles spécifiques au processus) utilisées dans le pipeline étant automatiquement copiées dans la tâche, Copy-Item $foo $bar & fonctionne tout simplement. La tâche est également exécutée dans le répertoire actuel au lieu du répertoire de base de l’utilisateur.

Nouvelles méthodes et propriétés de PSCustomObject

Ajout de nouvelles méthodes et propriétés à PSCustomObject. PSCustomObject inclut désormais une propriété Count/Length, comme les autres objets.

$PSCustomObject = [pscustomobject]@{foo = 1}

$PSCustomObject.Length

1

$PSCustomObject.Count

1

Cela inclut également les méthodes ForEach et Where qui vous permettent d’utiliser et de filtrer les éléments PSCustomObject :

$PSCustomObject.ForEach({$_.foo + 1})

2

$PSCustomObject.Where({$_.foo -gt 0})

foo
---
  1

Conversions de PSMethod en Delegate

Vous pouvez convertir PSMethod en délégué. Vous pouvez ainsi effectuer des opérations comme passer PSMethod[M]::DoubleStrLen en tant que valeur de délégué dans [M]::AggregateString :

class M {
    static [int] DoubleStrLen([string] $value) { return 2 * $value.Length }

    static [long] AggregateString([string[]] $values, [func[string, int]] $selector) {
        [long] $res = 0
        foreach($s in $values){
            $res += $selector.Invoke($s)
        }
        return $res
    }
}

[M]::AggregateString((gci).Name, [M]::DoubleStrLen)

Changement de comportement pour la comparaison de chaînes dans la version 7.1 de PowerShell

PowerShell 7.1 repose sur la version 5.0 de .NET, qui a introduit le changement cassant suivant :

• Changements de comportement lors de la comparaison de chaînes sur .NET 5 et les versions plus récentes

À compter de la version 5.0 de .NET, les comparaisons de chaînes à culture invariante ignorent les caractères de contrôle non imprimables.

Par exemple, les deux chaînes suivantes sont considérées comme identiques :

# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"

True

Nouvelles applets de commande

Nouvelle applet de commande Get-Uptime

L’applet de commande Get-Uptime retourne le temps écoulé depuis le dernier démarrage du système d’exploitation. Cette applet de commande a été introduite dans PowerShell 6.0.

Nouvelle applet de commande Remove-Alias

L’applet de commande Remove-Alias supprime un alias de la session PowerShell active. Cette applet de commande a été introduite dans PowerShell 6.0.

Nouvelle applet de commande Remove-Service

L’applet de commande Remove-Service supprime un service Windows dans le Registre et dans la base de données de service. L’applet de commande Remove-Service a été introduite dans PowerShell 6.0.

Nouvelles applets de commande Markdown

Le standard Markdown permet de créer des documents en texte clair avec une mise en forme de base qui peuvent être affichés en HTML.

Les applets de commande suivantes ont été ajoutées dans PowerShell 6.1 :

• ConvertFrom-Markdown – convertissez le contenu d’une chaîne ou d’un fichier en objet MarkdownInfo .
• Get-MarkdownOption : renvoie les couleurs et styles actuels utilisés pour le rendu du contenu Markdown dans la console.
• Set-MarkdownOption : définit les couleurs et les styles utilisés pour le rendu du contenu Markdown dans la console.
• Show-Markdown – Affiche le contenu Markdown dans la console ou au format HTML

Nouvelle applet de commande Test-Json

L’applet de commande Test-Json teste si une chaîne est un document JSON (JavaScript Object Notation) valide et peut éventuellement vérifier que le document JSON sur un schéma fourni.

L’applet de commande a été introduite dans PowerShell 6.1

Nouvelles applets de commande pour prendre en charge les fonctionnalités expérimentales

Les applets de commande suivantes ont été ajoutées dans PowerShell 6.2 pour prendre en charge les fonctionnalités expérimentales.

• Disable-ExperimentalFeature
• Enable-ExperimentalFeature
• Get-ExperimentalFeature

Nouvelle applet de commande Join-String

L’applet de commande Join-String combine des objets du pipeline en une seule chaîne. Cette applet de commande a été ajoutée dans PowerShell 6.2.

Nouvelle vue ConciseView et cmdlet Get-Error

PowerShell 7.0 optimise l’affichage des messages d’erreur pour améliorer la lisibilité des erreurs de script et interactives avec un nouvel affichage par défaut ConciseView. Les affichages peuvent être sélectionnées par l’utilisateur via la variable de préférence $ErrorView.

Avec ConciseView, si une erreur ne provient pas d’un script ou d’un analyseur, le message d’erreur a une seule ligne :

Get-Childitem -Path c:\NotReal

Get-ChildItem: Cannot find path 'C:\NotReal' because it does not exist

Si l’erreur se produit pendant l’exécution du script ou s’il s’agit d’une erreur d’analyse, PowerShell retourne un message d’erreur de plusieurs lignes contenant l’erreur, un pointeur et un message d’erreur qui indique l’emplacement de l’erreur dans cette ligne. Si le terminal ne prend pas en charge les séquences d’échappement de couleur ANSI (VT100), les couleurs ne sont pas affichées.

L’affichage par défaut dans PowerShell 7 est ConciseView. La vue par défaut précédente était NormalView et vous pouvez la sélectionner en définissant la variable de préférence $ErrorView.

$ErrorView = 'NormalView' # Sets the error view to NormalView
$ErrorView = 'ConciseView' # Sets the error view to ConciseView

Notes

Une nouvelle propriété ErrorAccentColor est ajoutée à $Host.PrivateData pour prendre en charge la modification de la couleur d’accentuation du message d’erreur.

La nouvelle cmdlet Get-Error fournit un affichage détaillé de l’erreur complète si vous le souhaitez. Par défaut, la cmdlet affiche les détails complets, notamment les exceptions internes, de la dernière erreur qui s’est produite.

La cmdlet Get-Error prend en charge l’entrée du pipeline à l’aide de la variable intégrée $Error. Get-Error affiche toutes les erreurs communiquées.

$Error | Get-Error

La cmdlet Get-Error prend en charge le paramètre le plus récent, ce qui vous permet de spécifier le nombre d’erreurs de la session active que vous souhaitez afficher.

Get-Error -Newest 3 # Displays the lst three errors that occurred in the session

Pour plus d’informations, consultez Get-Error.

Modifications apportées aux cmdlets

Exécution parallèle ajoutée à ForEach-Object

À partir de PowerShell 7.0, la cmdlet ForEach-Object, qui itère des éléments dans une collection, dispose maintenant d’un parallélisme intégré avec le nouveau paramètre Parallèle.

Par défaut, les blocs de scripts parallèles utilisent le répertoire de travail actuel de l’appelant qui a démarré les tâches parallèles.

Dans cet exemple, 50 000 entrées de 5 journaux système sont récupérées sur un ordinateur local Windows :

$logNames = 'Security','Application','System','Windows PowerShell','Microsoft-Windows-Store/Operational'

$logEntries = $logNames | ForEach-Object -Parallel {
    Get-WinEvent -LogName $_ -MaxEvents 10000
} -ThrottleLimit 5

$logEntries.Count

50000

Le paramètre Parallèle spécifie le bloc de script exécuté en parallèle pour chaque nom du journal d’entrée.

Le nouveau paramètre ThrottleLimit limite le nombre de blocs de scripts exécutés en parallèle à un moment donné. La valeur par défaut est 5.

Utilisez la variable $_ pour représenter l'objet d’entrée actuel dans le bloc de script. Utilisez l’étendue $using: pour transférer des références de variable vers le bloc de script en cours d’exécution.

Pour plus d’informations, consultez ForEach-Object.

Consulter system32 pour connaître les modules compatibles intégrés à Windows

Dans la mise à jour 1809 de Windows 10 et dans Windows Server 2019, nous avons mis à jour plusieurs des modules PowerShell intégrés, afin de les marquer comme compatibles avec PowerShell.

Quand PowerShell démarre, il ajoute automatiquement $windir\System32 dans la variable d’environnement PSModulePath. Toutefois, il expose uniquement les modules à Get-Module et Import-Module si son CompatiblePSEdition est marqué comme étant compatible avec Core.

Vous pouvez remplacer ce comportement pour afficher tous les modules à l’aide du paramètre de commutateur -SkipEditionCheck. Nous avons également ajouté une propriété PSEdition à la sortie de la table.

Alias -lp pour tous les paramètres -LiteralPath

Nous avons créé un alias de paramètre standard -lp pour toutes les applets de commande PowerShell intégrées qui ont un paramètre -LiteralPath.

Correction de Get-Item -LiteralPath a*b si a*b n’existe pas réellement pour retourner l’erreur

Auparavant, -LiteralPath avec un caractère générique le traitait de la même façon que -Path et si le caractère générique ne trouvait aucun fichier, il s’arrêtait en mode silencieux. Le comportement correct doit être que -LiteralPath est littéral, donc si le fichier n’existe pas, il doit afficher une erreur. La modification consiste à traiter les caractères génériques utilisés avec -Literal en tant qu’éléments littéraux.

Définition du répertoire de travail sur le répertoire actuel Start-Job

L’applet de commande Start-Job utilise désormais le répertoire actuel comme répertoire de travail pour le nouveau travail.

Suppression de -Protocol des applets de commande *-Computer

En raison de problèmes avec l’accès à distance RPC dans CoreFX (en particulier sur les plateformes non Windows) et en vue de garantir une expérience cohérente de la communication à distance dans PowerShell, le paramètre -Protocol a été supprimé des cmdlets \*-Computer. DCOM n’est plus pris en charge pour la communication à distance. Les applets de commande suivantes prennent en charge seulement la communication à distance WSMAN :

• Rename-Computer
• Restart-Computer
• Stop-Computer

Suppression de -ComputerName des applets de commande *-Service

Pour favoriser l’utilisation cohérente de PSRP, le paramètre -ComputerName a été supprimé des cmdlets *-Service.

Correction de Get-Content -Delimiter pour ne pas ajouter le délimiteur dans les lignes retournées

Auparavant, la sortie lors de l’utilisation de Get-Content -Delimiter était incohérente et peu pratique, car elle nécessitait un traitement supplémentaire des données pour supprimer le délimiteur. Cette modification supprime le délimiteur dans les lignes retournées.

Changements de Format-Hex

Le paramètre -Raw est désormais un « no-op » (c’est-à-dire, qu’il ne fait rien). À partir de maintenant toute la sortie s’affiche avec une représentation réelle des nombres qui comprend tous les octets de son type. C’est ce que le paramètre -Raw faisait avant ce changement.

Correction typographique dans le nom de Get-ComputerInfo

BiosSerialNumber était mal orthographié en tant que BiosSeralNumber et a été remplacé par l’orthographe correcte.

Ajout des applets de commande Get-StringHash et Get-FileHash

Cette modification indique que certains algorithmes de hachage ne sont pas pris en charge par CoreFX, donc ils ne sont plus disponibles :

• MACTripleDES
• RIPEMD160

Ajout de la validation sur les applets de commande Get-* où le passage de $null retournait tous les objets au lieu de l’erreur

La transmission de $null à l’un des éléments ci-dessous génère maintenant une erreur :

• Get-Credential -UserName
• Get-Event -SourceIdentifier
• Get-EventSubscriber -SourceIdentifier
• Get-Help -Name
• Get-PSBreakpoint -Script
• Get-PSProvider -PSProvider
• Get-PSSessionConfiguration -Name
• Get-Runspace -Name
• Get-RunspaceDebug -RunspaceName
• Get-Service -Name
• Get-TraceSource -Name
• Get-Variable -Name

Ajout de la prise en charge du format de fichier journal étendu W3C dans Import-Csv

Auparavant, la cmdlet Import-Csv ne pouvait pas être utilisée pour importer directement les fichiers journaux au format de journal étendu W3C et une action supplémentaire était nécessaire. Avec cette modification, le format de journal étendu W3C est pris en charge.

Import-Csv applique PSTypeNames à l’importation quand les informations de type sont présentes dans le CSV

Auparavant, les objets exportés utilisant Export-CSV avec TypeInformation importé avec ConvertFrom-Csv ne conservaient pas les informations de type. Cette modification ajoute des informations de type au membre PSTypeNames s’il est disponible dans le fichier CSV.

-NoTypeInformation est la valeur par défaut sur Export-Csv

Auparavant, l’applet de commande Export-CSV affichait un commentaire en première ligne contenant le nom du type de l’objet. Le changement exclut par défaut les informations de type, car elles ne sont pas comprises par la plupart des outils CSV. Ce changement a été effectué en réponse aux commentaires clients.

Utilisez -IncludeTypeInformation pour conserver le comportement précédent.

Autorisation de l’utilisation de * dans le chemin de Registre pour Remove-Item

Auparavant, -LiteralPath avec un caractère générique le traitait de la même façon que -Path et si le caractère générique ne trouvait aucun fichier, il s’arrêtait en mode silencieux. Le comportement correct doit être que -LiteralPath est littéral, donc si le fichier n’existe pas, il doit afficher une erreur. La modification consiste à traiter les caractères génériques utilisés avec -Literal en tant qu’éléments littéraux.

Group-Object trie désormais les groupes

Dans le cadre de l’amélioration des performances, Group-Object renvoie désormais une liste triée des groupes. Bien que vous ne deviez pas vous fier à l’ordre, vous pouvez être désactivé à cause de cette modification si vous souhaitiez le premier groupe. Nous avons décidé que l’amélioration des performances valait cette modification dans la mesure où l’impact de la dépendance sur le comportement précédent est faible.

Écart type dans Measure-Object

La sortie de Measure-Object contient maintenant une propriété StandardDeviation.

Get-Process | Measure-Object -Property CPU -AllStats

Count             : 308
Average           : 31.3720576298701
Sum               : 9662.59375
Maximum           : 4416.046875
Minimum           :
StandardDeviation : 264.389544720926
Property          : CPU

Get-PfxCertificate -Password

Get-PfxCertificate a désormais le paramètre Password, qui prend un SecureString. Cela vous permet de l’utiliser de manière non interactive :

$certFile = '\\server\share\pwd-protected.pfx'
$certPass = Read-Host -AsSecureString -Prompt 'Enter the password for certificate: '

$certThumbPrint = (Get-PfxCertificate -FilePath $certFile -Password $certPass ).ThumbPrint

Suppression de la fonction more

Auparavant, PowerShell fournissait une fonction appelée more dans Windows qui wrappait more.com. Cette fonction a été supprimée.

En outre, la fonction help utilise désormais more.com dans Windows, ou un récepteur système par défaut spécifié par $env:PAGER sur les plateformes non Windows.

cd DriveName: renvoie désormais les utilisateurs au répertoire de travail actuel du lecteur

Auparavant, l’utilisation de Set-Location ou de cd pour retourner à un PSDrive avait pour effet d’envoyer les utilisateurs à l’emplacement par défaut du lecteur. Les utilisateurs sont désormais envoyés vers le dernier répertoire de travail connu pour cette session.

cd - retourne au répertoire précédent

C:\Windows\System32> cd C:\
C:\> cd -
C:\Windows\System32>

Sur Linux :

PS /etc> cd /usr/bin
PS /usr/bin> cd -
PS /etc>

En outre, cd et cd -- sont remplacés par $HOME.

Update-Help en tant que non administrateur

À la demande générale, il n’est plus obligatoire d’exécuter Update-Help en tant qu’administrateur. Par défaut, Update-Help enregistre l’aide dans un dossier de portée utilisateur.

Where-Object -Not

Avec l’ajout du paramètre -Not à Where-Object, vous pouvez désormais filtrer un objet au niveau du pipeline pour noter l’absence d’une propriété ou la présence d’une valeur de propriété Null ou vide.

Par exemple, cette commande retourne tous les services dans lesquels aucun service dépendant n’est défini :

Get-Service | Where-Object -Not DependentServices

Modifications apportées aux cmdlets web

L’API .NET sous-jacente des cmdlets web a été remplacée par System.Net.Http.HttpClient. Cette modification offre de nombreux avantages. Toutefois, cette modification, ainsi qu’un manque d’interopérabilité avec Internet Explorer, ont causé plusieurs modifications avec rupture dans Invoke-WebRequest et Invoke-RestMethod.

• Invoke-WebRequest prend désormais en charge l’analyse HTML de base uniquement. Invoke-WebRequest retourne toujours un objet BasicHtmlWebResponseObject. Les propriétés ParsedHtml et Forms ont été supprimées.
• Les valeurs BasicHtmlWebResponseObject.Headers sont maintenant String[] au lieu de String.
• BasicHtmlWebResponseObject.BaseResponse est désormais un objet System.Net.Http.HttpResponseMessage.
• La propriété Response sur les exceptions de cmdlet web est désormais un objet System.Net.Http.HttpResponseMessage.
• L’analyse d’en-tête RFC stricte est désormais la valeur par défaut pour les paramètres -Headers et -UserAgent. Vous pouvez contourner ceci avec -SkipHeaderValidation.
• Les schémas d’URI file:// et ftp:// ne sont plus pris en charge.
• Les paramètres System.Net.ServicePointManager ne sont plus respectés.
• Aucune authentification par certificat n’est actuellement disponible sur macOS.
• L’utilisation de -Credential sur un URI http:// génère une erreur. Utilisez un URI https:// ou fournissez le paramètre -AllowUnencryptedAuthentication pour supprimer l’erreur.
• -MaximumRedirection génère désormais une erreur avec fin d’exécution quand les tentatives de redirection dépassent la limite fournie au lieu de retourner les résultats de la dernière redirection.
• Dans PowerShell 6.2, une modification a été apportée pour sélectionner par défaut à le codage UTF-8 pour les réponses JSON. Lorsqu’un jeu de caractères n’est pas fourni pour une réponse JSON, le codage par défaut doit être UTF-8 par RFC 8259.
• Définition de l’encodage par défaut sur UTF-8 pour les réponses application-json
• Ajout du paramètre -SkipHeaderValidation pour autoriser les en-têtes Content-Type qui ne sont pas conformes
• Ajout du paramètre -Form pour la prise en charge simplifiée de multipart/form-data
• Gestion des clés de relation conforme sans respect de la casse
• Ajout du paramètre -Resume pour les applets de commande web

Invoke-RestMethod retourne des informations utiles quand aucune donnée n’est retournée

Quand une API retourne simplement null, Invoke-RestMethod le sérialisait comme la chaîne "null" au lieu de $null. Cette modification résout la logique dans Invoke-RestMethod pour sérialiser correctement une seule valeur JSON valide null de manière littérale en tant que $null.

Les applets de commande web avertissent quand -Credential est envoyé sur des connexions non chiffrées

Lorsque vous utilisez HTTP, le contenu, notamment les mots de passe, est envoyé en texte clair. Cette modification consiste à ne pas autoriser ce comportement par défaut et à retourner une erreur si les informations d’identification sont transmises de manière non sécurisée. Les utilisateurs peuvent contourner cela à l’aide du commutateur -AllowUnencryptedAuthentication.

Modification du paramètre -OutFile dans les applets de commande web pour qu’il fonctionne comme -LiteralPath

À compter de PowerShell 7.1, le paramètre OutFile des applets de commande web fonctionne comme LiteralPath et ne traite pas les caractères génériques.

Modifications d'API

Suppression de la classe AddTypeCommandBase

La classe AddTypeCommandBase a été supprimée de Add-Type pour améliorer les performances. Cette classe est utilisée uniquement par l’applet de commande Add-Type et ne doit pas impacter les utilisateurs.

Suppression de VisualBasic comme langage pris en charge dans Add-Type

Auparavant, vous pouviez compiler du code Visual Basic à l’aide de l’applet de commande Add-Type. Visual Basic était rarement utilisé avec Add-Type. Nous avons supprimé cette fonctionnalité afin de réduire la taille de PowerShell.

Suppression de la prise en charge de RunspaceConfiguration

Auparavant, pour créer une instance d’exécution PowerShell programmatiquement à l’aide de l’API, vous pouviez utiliser la classe RunspaceConfiguration héritée ou les classes InitialSessionState plus récentes. Cette modification supprime la prise en charge de RunspaceConfiguration et prend uniquement en charge InitialSessionState.

CommandInvocationIntrinsics.InvokeScript lie les arguments à $input au lieu de $args

En raison d’une position incorrecte d’un paramètre, les arguments étaient passés en tant qu’entrée au lieu d’arguments.

Suppression des propriétés ClrVersion et BuildVersion de $PSVersionTable

La propriété ClrVersion de $PSVersionTable n’est pas utile avec CoreCLR. Les utilisateurs finaux ne doivent pas utiliser cette valeur pour déterminer la compatibilité.

La propriété BuildVersion a été liée à la version de build Windows, qui n’est pas disponible sur les plateformes non-Windows. Utilisez la propriété GitCommitId pour récupérer la version de build exacte de PowerShell.

Implémentation de l’analyse d’échappement Unicode

`u#### ou `u{####} est converti en caractère Unicode correspondant. Pour générer un `u littéral, appliquer l’échappement au guillemet inversé : ``u.

Problème de liaison de paramètre avec ValueFromRemainingArguments dans les fonctions PS

ValueFromRemainingArguments retourne désormais les valeurs sous forme de tableau au lieu d’une seule valeur qui est elle-même un tableau.

Nettoyage des utilisations de CommandTypes.Workflow et WorkflowInfoCleaned

Nettoyage du code lié aux utilisations de CommandTypes.Workflow et WorkflowInfo dans System.Management.Automation.

Ces petits changements cassants affectent principalement le code du fournisseur d’aide.

• Remplacez les constructeurs publics de WorkflowInfo par des internes. Comme nous ne prenons plus en charge le workflow, il est logique de ne pas autoriser les utilisateurs à créer des instances de Workflow.
• Suppression du type System.Management.Automation.DebugSource, car il est utilisé uniquement pour le débogage de workflow.
• Suppression de la surcharge de SetParent dans la classe abstraite Debugger, qui est uniquement utilisée pour le débogage de workflow.
• Suppression de la même surcharge de SetParent dans la classe dérivée RemotingJobDebugger.

Résultat de retour non wrappé dans PSObject pendant la conversion de ScriptBlock en délégué

Quand un ScriptBlock est converti en type délégué à utiliser dans un contexte C#, le wrapping du résultat dans un PSObject pose des problèmes inutiles :

• Lorsque la valeur est convertie en type de retour délégué, PSObject n’est pas wrappé par essence. Donc PSObject n’est pas nécessaire.
• Lorsque le type de retour délégué est object, il est wrappé dans un PSObject, ce qui rend difficile son utilisation dans le code C#.

Après ce changement, l’objet retourné est l’objet sous-jacent.

Prise en charge de la communication à distance

La communication à distance PowerShell (PSRP) utilisant WinRM sur les plateformes UNIX nécessite une authentification NTLM/Negotiate ou une authentification de base sur HTTPS. PSRP sur macOS prend uniquement en charge l’authentification de base sur HTTPS. L’authentification Kerberos n’est pas prise en charge pour les plateformes non-Windows.

PowerShell prend également en charge la communication à distance PowerShell (PSRP) sur SSH pour toutes les plateformes (Windows, macOS et Linux). Pour plus d’informations, consultez Communication à distance SSH dans PowerShell.

PowerShell Direct pour les conteneurs tente d’abord d’utiliser pwsh

PowerShell Direct est une fonctionnalité PowerShell et Hyper-V, qui vous permet de vous connecter à une machine virtuelle Hyper-V ou à un conteneur sans connectivité réseau ni service de gestion à distance.

Auparavant, PowerShell Direct se connectait à l’aide de l’instance Windows PowerShell intégrée au conteneur. À présent, PowerShell Direct tente d’abord de se connecter à l’aide de l’un des pwsh.exe disponibles dans la variable d’environnement PATH. Si aucun pwsh.exe n’est disponible, PowerShell Direct utilise à nouveau powershell.exe.

À présent, Enable-PSRemoting crée des points de terminaison de communication à distance distincts pour chaque préversion

À présent, Enable-PSRemoting crée deux configurations de session de communication à distance :

• Une pour la version principale de PowerShell. Par exemple : PowerShell.6. Pour les mises à jour de la version secondaire, ce point de terminaison peut correspondre à la configuration de session PowerShell 6 qui est appliquée à l’échelle du système
• Une configuration de session spécifique à une version, par exemple : PowerShell.6.1.0

Ce comportement est utile si vous souhaitez que plusieurs versions de PowerShell 6 soient installées et accessibles sur un même ordinateur.

En outre, les préversions de PowerShell peuvent désormais obtenir leurs propres configurations de session de communication à distance en exécutant l’applet de commande Enable-PSRemoting :

C:\WINDOWS\system32> Enable-PSRemoting

Votre sortie peut être différente si vous n’avez pas configuré WinRM au préalable.

WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.

Ensuite, vous pouvez voir les différentes configurations de session PowerShell pour la préversion et les builds stables de PowerShell 6, ainsi que pour chaque version.

Get-PSSessionConfiguration

Name          : PowerShell.6.2-preview.1
PSVersion     : 6.2
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : PowerShell.6-preview
PSVersion     : 6.2
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : powershell.6
PSVersion     : 6.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : powershell.6.1.0
PSVersion     : 6.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Syntaxe user@host:port prise en charge pour le protocole SSH

Les clients SSH prennent généralement en charge une chaîne de connexion au format user@host:port. Avec l’ajout du protocole SSH pour la communication à distance PowerShell, nous permettons désormais la prise en charge de ce format de chaîne de connexion :

Enter-PSSession -HostName fooUser@ssh.contoso.com:2222

Les données de télémétrie peuvent uniquement être désactivées avec une variable d’environnement

PowerShell envoie des données de télémétrie de base à Microsoft quand il est lancé. Les données incluent le nom du système d’exploitation, la version du système d’exploitation et la version de PowerShell. Ces données nous permettent de mieux comprendre les environnements dans lesquels PowerShell est utilisé, ainsi que de classer par ordre de priorité les correctifs et les nouvelles fonctionnalités.

Pour refuser la collecte de ces données de télémétrie, définissez la variable d’environnement POWERSHELL_TELEMETRY_OPTOUT sur true, yes ou 1. Il n’est plus possible de supprimer le fichier DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY pour désactiver la télémétrie.