Megosztás a következőn keresztül:

Az Windows PowerShell 5.1 és a PowerShell 7.x közötti különbségek

A Windows PowerShell 5.1 a .NET-keretrendszer 4.5-ös verziójára épül. A PowerShell 6.0 kiadásával a PowerShell nyílt forráskódú projektté vált, amely a .NET Core 2.0-ra épül. A .NET-keretrendszerről a .NET Core-ra való áttérés lehetővé tette, hogy a PowerShell platformfüggetlen megoldássá váljon. A PowerShell Windows, macOS és Linux rendszeren fut.

A PowerShell nyelvében kevés különbség van a Windows PowerShell és a PowerShell között. A legfontosabb különbségek a PowerShell-parancsmagok Rendelkezésre állása és viselkedése a Windows és a nem Windows platformok között, valamint a .NET-keretrendszer és a .NET Core közötti különbségekből eredő változások.

Ez a cikk a Windows PowerShell és a PowerShell jelenlegi verziója közötti jelentős különbségeket és kompatibilitástörő változásokat foglalja össze. Ez az összefoglalás nem tartalmaz új szolgáltatásokat vagy parancsmagokat, amelyeket hozzáadtak. Ez a cikk azt sem ismerteti, hogy mi változott a verziók között. A cikk célja, hogy bemutassuk a PowerShell jelenlegi állapotát, és azt, hogy miben különbözik a Windows PowerShelltől. A verziók közötti változások és az új funkciók hozzáadásának részletes ismertetését az egyes verziók Újdonságok cikkekben találja.

.NET-keretrendszer és .NET Core

A Linuxon és macOS-en futó PowerShell .NET core-t használ, amely a Microsoft Windows teljes .NET-keretrendszerének egy részhalmaza. Ez azért jelentős, mert a PowerShell közvetlen hozzáférést biztosít az alapul szolgáló keretrendszertípusokhoz és metódusokhoz. Ennek eredményeképpen előfordulhat, hogy a Windowson futó szkriptek nem windowsos platformokon futnak a keretrendszerek közötti különbségek miatt. További információ a .NET Core változásairól: .NET-keretrendszerből .NET Core-való migrálás kompatibilitástörő változásai.

A PowerShell minden új kiadása a .NET újabb verziójára épül. A .NET-ben kompatibilitástörő változások lehetnek, amelyek hatással vannak a PowerShellre.

  • PowerShell 7.5 – A .NET 9.0-ra épül
  • PowerShell 7.4 – A .NET 8.0-ra épül
  • PowerShell 7.3 – A .NET 7.0-ra épül
  • PowerShell 7.2 (LTS-current) – .NET 6.0-ra (LTS-current) épül
  • PowerShell 7.1 – .NET 5.0-s verzióra épül
  • PowerShell 7.0 (LTS) – .NET Core 3.1 (LTS) alapú
  • PowerShell 6.2 – .NET Core 2.1-alapú
  • PowerShell 6.1 – .NET Core 2.1-re alapul
  • PowerShell 6.0 – A .NET Core 2.0-ra épül

A .NET Standard 2.0 megjelenésével a PowerShell számos hagyományos Windows PowerShell-modult képes módosítás nélkül betölteni. Emellett a PowerShell 7 tartalmaz egy Windows PowerShell kompatibilitási funkciót is, amely lehetővé teszi a teljes keretrendszert igénylő Windows PowerShell-modulok használatát.

További információk:

Vegye figyelembe a .NET-metódus változásait

Bár a .NET-metódusok módosításai nem a PowerShellre vonatkoznak, hatással lehetnek a szkriptekre, különösen akkor, ha közvetlenül .NET-metódusokat hív meg. Emellett előfordulhat, hogy a konstruktorok túlterheltek. Ez hatással lehet arra, hogyan hozhat létre objektumokat New-Object vagy a [type]::new() metódus használatával.

A .NET például túlterheléseket adott hozzá a [System.String]::Split() metódushoz, amelyek nem érhetők el a .NET-keretrendszer 4.5-ben. Az alábbi lista a Windows PowerShell 5.1-ben elérhető Split() metódus túlterheléseit mutatja be:

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)

Az alábbi lista a PowerShell 7-ben elérhető Split() metódus túlterheléseit mutatja be:

"".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)

A Windows PowerShell 5.1-ben egy karaktertömböt (char[]) adhat át a Split() metódusnak string. A metódus felosztja a célsztringet a tömb egyik karakterének előfordulásakor. A következő parancs felosztja a célsztringet a Windows PowerShell 5.1-ben, a PowerShell 7-ben azonban nem:

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

1111p2222q3333

A megfelelő túlterheléshez való kötéshez a sztringet karaktertömbbe kell beírnia:

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

1111
2222
3333

A PowerShell-lel már nem szállított modulok

Különböző kompatibilitási okokból a következő modulok már nem szerepelnek a PowerShellben.

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

PowerShell-munkafolyamat

PowerShell-munkafolyamat a Windows PowerShell olyan funkciója, amely a Windows Workflow Foundation (WF) alapul, és lehetővé teszi robusztus futtatási könyvek létrehozását a hosszú ideig futó vagy párhuzamos feladatokhoz.

A .NET Core-ban a Windows Workflow Foundation támogatásának hiánya miatt eltávolítottuk a PowerShell-munkafolyamatot a PowerShellből.

A jövőben szeretnénk engedélyezni a natív párhuzamosságot/egyidejűséget a PowerShell-nyelven anélkül, hogy PowerShell-munkafolyamatra lenne szükség.

Ha az operációs rendszer újraindítása után ellenőrzőpontokat kell használni a szkriptek folytatásához, javasoljuk, hogy a Feladatütemezővel futtasson egy szkriptet az operációs rendszer indításakor, de a szkriptnek meg kell őriznie a saját állapotát (például egy fájlban kell megőriznie).

A PowerShellből eltávolított parancsmagok

A PowerShellben található modulok esetében a következő parancsmagok különböző kompatibilitási okokból vagy nem támogatott API-k használata miatt lettek eltávolítva a PowerShellből.

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

WMI v1 parancsmagok

A következő WMI v1-parancsmagok el lettek távolítva a PowerShellből:

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

A CimCmdlets modul (más néven WMI v2) parancsmagok ugyanazt a függvényt hajtják végre, és új funkciókat és újratervezett szintaxist biztosítanak.

New-WebServiceProxy parancsmag el lett távolítva

A .NET Core nem támogatja a Windows kommunikációs keretrendszert, amely szolgáltatásokat nyújt a SOAP protokoll használatához. Ez a parancsmag el lett távolítva, mert SOAP-t igényel.

*-Transaction parancsmagok eltávolítva lettek

Ezek a parancsmagok nagyon korlátozottan voltak használatban. Döntés született a támogatás megszüntetéséről.

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

*-EventLog parancsmagok

A nem támogatott API-k használata miatt a *-EventLog parancsmagok el lettek távolítva a PowerShellből. Get-WinEvent és New-WinEvent érhetők el események lekéréséhez és létrehozásához Windows rendszeren.

A Windows-bemutató keretrendszert (WPF) használó parancsmagok

A .NET Core 3.1 támogatja a WPF-et, ezért a PowerShell 7.0 kiadása a következő Windows-specifikus funkciókat állította vissza:

  • A Show-Command parancsmag
  • A Out-GridView parancsmag
  • A Get-HelpShowWindow paramétere

A PowerShell kívánt állapotkonfigurációjának (DSC) változásai

Invoke-DscResource a PowerShell 7.0 kísérleti funkciójaként lett visszaállítva.

A PowerShell 7.2-től kezdve a PSDesiredStateConfiguration modul el lett távolítva a PowerShellből, és közzé lett téve a PowerShell-katalógusban. További információkért tekintse meg a PowerShell-csapat blogjának bejelentését.

Végrehajtható PowerShell-módosítások

Átnevezve powershell.exe-ról pwsh.exe-ra

A PowerShell bináris neve powershell(.exe)-ről pwsh(.exe)-ra módosult. Ez a módosítás determinisztikus módot biztosít a felhasználók számára a PowerShell gépeken való futtatására, valamint a Windows PowerShell és a PowerShell egymás melletti telepítéseinek támogatására.

A powershell.exepwsh(.exe) további módosításai:

  • Az első pozícióparamétert -Command-ről -File-ra módosította. Ez a módosítás kijavítja a #! (más néven shebang) használatát olyan PowerShell-szkriptekben, amelyeket nem PowerShell-rendszerhéjakból hajtanak végre nem Windows-platformokon. Ez azt is jelenti, hogy -Filemegadása nélkül futtathat olyan parancsokat, mint pwsh foo.ps1 vagy pwsh fooScript. Ehhez a módosításhoz azonban kifejezetten meg kell adnia -c vagy -Command, amikor olyan parancsokat próbál futtatni, mint a pwsh.exe -Command Get-Command.
  • pwsh elfogadja a -i (vagy -Interactive) kapcsolót egy interaktív felület jelzésére. Ez lehetővé teszi, hogy a PowerShell alapértelmezett rendszerhéjként használható legyen a Unix-platformokon.
  • A pwsh.exe-ImportSystemModules és -PSConsoleFile paraméterek el lettek távolítva.
  • A pwsh -Version és a beépített súgó módosítása a pwsh.exe más natív eszközökhöz való igazításához.
  • Érvénytelen argumentum hibaüzenetek -File, -Command és kilépési kódok esetében, amelyek összhangban állnak a Unix szabványaival
  • Hozzáadta -WindowStyle paramétert a Windowson. Hasonlóképpen, a nem Windows-platformok csomagalapú telepítéseinek frissítései helyben frissülnek.

A rövidített név összhangban van a nem Windows-platformokon futó rendszerhéjak elnevezésével is.

PowerShell-szkript futtatásának támogatása bool paraméterrel

Korábban a pwsh.exe használata PowerShell-szkriptek futtatásához -File nem biztosított lehetőséget a $true/$false paraméterértékként való átadására. Támogatást adtak hozzá a $true,/,$false értékekhez, amikor azokat paraméterekként értelmezik. A kapcsolóértékek is támogatottak.

Továbbfejlesztett visszamenőleges kompatibilitás a Windows PowerShell-lel

Windows esetén a rendszer hozzáad egy új kapcsolóparamétert UseWindowsPowerShellImport-Module. Ez a kapcsoló létrehoz egy proxymodult a PowerShell 7-ben, amely egy helyi Windows PowerShell-folyamatot használ a modulban található parancsmagok implicit futtatásához. További információ: Import-Module.

A Microsoft-modulok PowerShell 7.0-val való működéséről további információt a modulkompatibilitási táblázattalál.

A Windows Microsoft Update támogatása

A PowerShell 7.2 támogatja a Microsoft Update-et. Ha engedélyezi ezt a funkciót, a PowerShell 7 legújabb frissítéseit fogja megkapni a hagyományos Windows Update (WU) felügyeleti folyamatában, függetlenül attól, hogy ez a Vállalati Windows Update, a WSUS, az SCCM vagy az interaktív WU párbeszédpanel a Beállításokban.

A PowerShell 7.2 MSI-csomag a következő parancssori beállításokat tartalmazza:

  • USE_MU – Ez a tulajdonság két lehetséges értékkel rendelkezik:
    • 1 (alapértelmezett) – A Microsoft Update vagy a WSUS frissítését választja
    • 0 – Ne iratkozzon fel a frissítésekre a Microsoft Update vagy a WSUS használatával
  • ENABLE_MU
    • 1 (alapértelmezett) – A Microsoft Update automatikus frissítése vagy a Windows Update használata mellett dönt
    • 0 – Ne használja a Microsoft Update automatikus frissítéseit vagy a Windows Update-et

Motorváltozások

Támogassa a PowerShell-t, mint alapértelmezett Unix-rendszerhéjat

Unix alatt szokás, hogy a shell-ek elfogadják a -i-t egy interaktív shell esetében, és sok eszköz erre a viselkedésre számít (példáulscript, amikor a PowerShellt állítják be alapértelmezett shell-ként), és a shell-t a -i kapcsolóval hívják meg. Ez a változás azért okozza a törést, mert a korábban használt -i rövidítésként is megfelelt -InputFormat-nek, amit most -in-re kell cserélni.

Egyéni beépülő modulok

A PowerShell snap-in bővítmények a PowerShell modulok elődjei, amelyek nem váltak népszerűvé a PowerShell közösségben.

A beépülő modulok támogatásának összetettsége és a közösségen belüli használat hiánya miatt többé nem támogatjuk az egyéni beépülő modulokat a PowerShellben.

Kísérleti funkciójelzők

A PowerShell 6.2 támogatja kísérleti funkciók. Ez lehetővé teszi, hogy a PowerShell-fejlesztők új funkciókat nyújtsanak, és visszajelzést kérjenek a tervezés befejezése előtt. Így elkerüljük a kompatibilitási problémákat okozó változtatásokat a kialakítás fejlődésével.

A Get-ExperimentalFeature használatával lekérheti az elérhető kísérleti funkciók listáját. Ezeket a funkciókat engedélyezheti vagy letilthatja Enable-ExperimentalFeature és Disable-ExperimentalFeature.

Szerelvény betöltése a modul alapútvonaláról, mielőtt megpróbálna betöltődni a GAC-ból

Korábban, amikor egy bináris modulnak a GAC-ban volt a szerelvénye, a szerelvényt a GAC-ból töltöttük be, mielőtt megpróbáltuk volna betölteni a modul alapútvonaláról.

Érték típusú elemtípusú gyűjtemények nullelemes ellenőrzésének kihagyása

A Mandatory paraméter, ValidateNotNull és ValidateNotNullOrEmpty attribútumok esetében hagyja ki a null elemet annak ellenőrzéséhez, hogy a gyűjtemény elemtípusa értéktípus-e.

$? megőrzése ParenExpression, SubExpression és ArrayExpression esetében

Ez a pull kérés megváltoztatja az alprogramvonalak (...), a részexpressziók $(...) és a tömbkifejezések @() fordításának módját, úgy hogy a $? ne legyen automatikusan igaz. Ehelyett a $? értéke a végrehajtott folyamat vagy utasítások eredményétől függ.

Javítsa ki $?-t, hogy ne legyen $false, amikor egy natív parancs ír a következőre: stderr

$? nincs beállítva $false-re, amikor a natív parancs stderr-re ír. Gyakori, hogy a natív parancsok a stderr-ra írnak anélkül, hogy szándékukban állna hibára utalni. $? csak akkor van beállítva $false-re, ha a natív parancs nem nulla kilépési kóddal rendelkezik.

Az $ErrorActionPreference ne befolyásolja stderr natív parancsok kimenetét

Gyakran előfordul, hogy a natív parancsok nem szándékosan jeleznek hibát, amikor írnak stderr-ra. Ezzel a módosítással a stderr kimenet továbbra is rögzítve lesz a ErrorRecord objektumokban, de a futtatókörnyezet már nem alkalmazza a $ErrorActionPreference, ha a ErrorRecord natív parancsból származik.

$OutputEncoding módosítása az ASCII helyett UTF-8 NoBOM kódolás használatára

Az előző kódolás, az ASCII (7 bites) bizonyos esetekben helytelenül változtatná meg a kimenetet. A UTF-8 NoBOM alapértelmezettként való beállítása megőrzi a Unicode-kimenetet a legtöbb eszköz és operációs rendszer által támogatott kódolással.

A -Encoding paraméter típusának System.Text.Encoding típusra változtatásával rendelkező parancsmagok egyesítése

A -Encoding érték Byte el lett távolítva a Fájlrendszer-szolgáltató parancsmagjaiból. Egy új paraméter (-AsByteStream) használatával megadhatja, hogy bemenetként bájtfolyamra van-e szükség, vagy hogy a kimenet bájtos adatfolyam legyen.

A New-ModuleManifest kódolását változtassa UTF8NoBOM-re nem Windows-platformokon

Korábban New-ModuleManifestpsd1 jegyzékfájlokat hozott létre az UTF-16-ban a BOM használatával, ami problémát okoz a Linux-eszközök számára. Ez a kompatibilitástörő változás a New-ModuleManifest kódolását UTF -nek (nem BOM- nak) módosítja a nem Windows-platformokon.

AllScope eltávolítása a legtöbb alapértelmezett aliasból

A hatókör létrehozásának felgyorsításához AllScope el lett távolítva a legtöbb alapértelmezett aliasból. Az AllScope fenntartva maradt néhány gyakran használt alias számára, ahol a keresés gyorsabb volt.

-Verbose és -Debug már nem bírálja felül $ErrorActionPreference

Korábban, ha -Verbose vagy -Debug volt megadva, az felülírta a $ErrorActionPreferenceviselkedését. Ezzel a változással -Verbose és -Debug már nem befolyásolják a $ErrorActionPreferenceviselkedését.

A -Debug paraméter Inquirehelyett a Folytatás $DebugPreference.

Törekedjünk arra, hogy a $PSCulture következetesen tükrözze a munkamenet közbeni kultúraváltozásokat.

A Windows PowerShellben gyorsítótárazzák az aktuális kultúraértéket, ami azt eredményezheti, hogy az érték nincsen szinkronban, ha a kultúra a munkamenet indítása után változik meg. Ez a gyorsítótárazási viselkedés a PowerShell Core-ban javítva van.

Az explicit módon megadott megnevezett paraméter felülírja ugyanazt a paramétert a hashtable splatting technikából.

Ezzel a módosítással a névvel ellátott paramétereket a splatting technikával a paraméterlista végére helyezzük, így azok az összes explicit módon megadott elnevezett paraméter után lesznek kötve. Az egyszerű függvények paraméterkötése nem ad hibát, ha egy megadott elnevezett paraméter nem található. Az ismeretlen elnevezett paraméterek az egyszerű függvény $args paraméteréhez vannak kötve. Az argumentumlista végére helyezve a splattinget megváltozik a paraméterek megjelenési sorrendje $args.

Például:

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

Az előző viselkedésben a MyPath nem -Path, mert ez a harmadik argumentum az argumentumlistában. Végül így kerül be a "$args" mezőbe, együtt a Blah = "World"-val.

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

Ezzel a módosítással a @hash argumentumai az argumentumlista végére kerülnek. MyPath lesz az első argumentum a listában, így hozzá lesz rendelve -Path.

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

Nyelvi változások

Null-egyesítési operátor ??

A null-egyesítő operátor ?? a bal oldali operandus értékét adja vissza, ha az nem null. Ellenkező esetben a jobb oldali operandust értékeli ki, és visszaadja az eredményt. A ?? operátor nem értékeli a jobb oldali operandusát, ha a bal oldali operandus értéke nem null.

$x = $null
$x ?? 100

100

Az alábbi példában a jobb oldali operandus nem lesz kiértékelve.

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

1/10/2020

Null-egyesítő hozzárendelő operátor ??=

A null-egyesítő hozzárendelési operátor ??= a jobb oldali operandus értékét csak akkor rendeli hozzá a bal oldali operandushoz, ha a bal oldali operandus értéke null. A ??= operátor nem értékeli a jobb oldali operandusát, ha a bal oldali operandus értéke nem null.

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

100

Az alábbi példában a jobb oldali operandus nem lesz kiértékelve.

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

1/10/2020

Null feltételes operátorok

Megjegyzés

Ezt a funkciót a PowerShell 7.1-ben a kísérleti verzióról a mainstreamre helyezték át.

A null feltételes operátor csak akkor alkalmaz taghozzáférést, ?.vagy elemhozzáférést, ?[], műveletet az operandusra, ha az operandus nem null értékű; ellenkező esetben null értéket ad vissza.

Mivel a PowerShell lehetővé teszi, hogy ? része legyen a változó nevének, a változónév formális specifikációja szükséges ezen operátorok használatához. Ezért {} kell használni az olyan változónevek köré, mint a ${a}, vagy ha ? a változónév ${a?}része.

Az alábbi példában a PropName értéke lesz visszaadva.

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

100

Az alábbi példa null értéket ad vissza, anélkül, hogy megpróbálná elérni a tagok nevét PropName.

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

Hasonlóképpen az elem értékét is visszaadja a rendszer.

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

1

Ha az operandus null értékű, az elem nem érhető el, és a null értéket adja vissza.

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

Megjegyzés

A ${<name>} változónévszintaxisát nem szabad összekeverni a $() alexpressziós operátorral. További információt a about_Variablesváltozónév szakaszában talál.

& operátor hozzáadva a feladatvezérléshez

Ha a & jelet a csővezeték végére helyezi, akkor a csővezeték PowerShell-feladatként fut. Ha egy folyamatláncot háttérbe helyeznek, visszaad egy feladatobjektumot. Ha a folyamat feladatként fut, a feladat kezeléséhez a szabványos *-Job parancsmagok mindegyike használható. A folyamat során használt változók (a folyamatspecifikus változók figyelmen kívül hagyása) automatikusan át lesznek másolva a feladatba, így Copy-Item $foo $bar & egyszerűen működik. A feladat a felhasználó kezdőkönyvtára helyett az aktuális könyvtárban is fut.

Új metódusok/tulajdonságok a PSCustomObject

Új metódusokat és tulajdonságokat adtunk hozzá PSCustomObject. PSCustomObject mostantól egy Count/Length tulajdonságot is tartalmaz, mint más objektumok.

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

$PSCustomObject.Length

1

$PSCustomObject.Count

1

Ez a munka ForEach és Where metódusokat is tartalmaz, amelyek lehetővé teszik PSCustomObject elemek üzemeltetését és szűrését:

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

2

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

foo
---
  1

Konvertálás PSMethodról meghatalmazottra

Átalakíthat egy PSMethod-t delegálttá. Ez lehetővé teszi, hogy például az PSMethod[M]::DoubleStrLen-et delegációs értékként adja át [M]::AggregateString-be:

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)

A sztringek összehasonlítási viselkedése megváltozott a PowerShell 7.1-ben

A PowerShell 7.1 a .NET 5.0-ra épül, amely a következő kompatibilitástörő változást vezette be:

A .NET 5.0-s verziójában a kultúrafüggetlen sztring-összehasonlítások figyelmen kívül hagyják a nem nyomtatható vezérlőkaraktereket.

A következő két karakterlánc például azonosnak tekinthető:

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

True

Új parancsmagok

Új Get-Uptime parancsmag

A Get-Uptime parancsmag az operációs rendszer utolsó indítása óta eltelt időt adja vissza. A parancsmag a PowerShell 6.0-ban lett bevezetve.

Új Remove-Alias parancsmag

Az Remove-Alias parancsmag eltávolít egy aliast az aktuális PowerShell-munkamenetből. A parancsmag a PowerShell 6.0-ban lett bevezetve.

Új parancsmag Remove-Service

A Remove-Service parancsmag eltávolít egy Windows-szolgáltatást a beállításjegyzékben és a szolgáltatásadatbázisban. A Remove-Service parancsmag a PowerShell 6.0-ban lett bevezetve.

Új Markdown-parancsmagok

A Markdown a HTML-ben megjeleníthető egyszerű szöveges dokumentumok egyszerű formázással történő létrehozására szolgáló szabvány.

A Következő parancsmagok lettek hozzáadva a PowerShell 6.1-ben:

  • ConvertFrom-Markdown – Sztring vagy fájl tartalmának átalakítása MarkdownInfo objektummá.
  • Get-MarkdownOption – A Markdown-tartalom konzolon való megjelenítéséhez használt aktuális színeket és stílusokat adja vissza.
  • Set-MarkdownOption – Beállítja a Markdown-tartalom konzolon való megjelenítéséhez használt színeket és stílusokat.
  • Show-Markdown – Markdown-tartalom megjelenítése a konzolon vagy HTML formátumban

Új Test-Json parancsmag

A Test-Json parancsmag ellenőrzi, hogy a sztring érvényes JavaScript Object Notation -dokumentum-e, és opcionálisan ellenőrizheti, hogy a JSON-dokumentum egy megadott sémán van-e.

Ez a parancsmag a PowerShell 6.1-ben lett bevezetve

Új parancsmagok a kísérleti funkciók támogatásához

A PowerShell 6.2-ben a következő parancsmagok lettek hozzáadva a kísérleti funkciók támogatásához.

Új Join-String parancsmag

A Join-String parancsmag egyetlen karakterláncba egyesíti a csővezeték tárgyakat. Ez a parancsmag a PowerShell 6.2-ben lett hozzáadva.

Új nézet ConciseView és parancsmag Get-Error

A PowerShell 7.0 új alapértelmezett nézettel javítja a hibaüzenetek megjelenítését az interaktív és szkripthibák olvashatóságának javítása érdekében, ConciseView. A nézetek a $ErrorViewbeállítási változóval választhatók ki.

A ConciseView esetén, ha egy hiba nem szkriptből vagy elemzési hibából származik, akkor ez egy egysoros hibaüzenet:

Get-ChildItem -Path C:\NotReal

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

Ha a hiba a szkript végrehajtása során vagy elemzési hiba, a PowerShell egy többsoros hibaüzenetet ad vissza, amely tartalmazza a hibát, egy mutatót és egy hibaüzenetet, amely azt jelzi, hogy hol található a hiba az adott sorban. Ha a terminál nem támogatja az ANSI színkioldó sorozatokat (VT100), akkor a színek nem jelennek meg.

A PowerShell 7 alapértelmezett nézete ConciseView. Az előző alapértelmezett nézet NormalView volt, és ezt a beállítási változó $ErrorViewbeállításával választhatja ki.

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

Megjegyzés

Új tulajdonság ErrorAccentColor kerül hozzáadásra a $Host.PrivateData-hoz, hogy támogassa a hibaüzenet jelölőszínének módosítását.

Az új Get-Errorparancsmag részletes áttekintést nyújt a teljesen minősített hibaról, amikor szükséges. Alapértelmezés szerint a parancsmag megjeleníti az utolsó hiba teljes részleteit, beleértve a belső kivételeket is.

A Get-Error parancsmag támogatja a folyamat bemenetét a beépített $Errorváltozó használatával. Get-Error megjeleníti az összes csőhibát.

$Error | Get-Error

A Get-Error parancsmag támogatja a Legújabb paramétert, így megadhatja, hogy hány hiba jelenjen meg az aktuális munkamenetből.

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

További információért lásd: Get-Error.

A parancsmag módosításai

Párhuzamos végrehajtás hozzáadva ForEach-Object

A PowerShell 7.0-tól kezdve a gyűjtemény elemeit iteráló ForEach-Object parancsmag beépített párhuzamot tartalmaz az új Párhuzamos paraméterrel.

A párhuzamos szkriptblokkok alapértelmezés szerint a párhuzamos feladatokat kezdeményező hívó aktuális munkakönyvtárát használják.

Ez a példa 50 000 naplóbejegyzést kér le 5 rendszernaplóból egy helyi Windows-gépen:

$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

A Párhuzamos paraméter az egyes bemeneti naplónevekhez párhuzamosan futó szkriptblokkot adja meg.

Az új ThrottleLimit paraméter korlátozza az adott időpontban párhuzamosan futó szkriptblokkok számát. Az alapértelmezett érték 5.

Használja a $_ változót a szkriptblokk aktuális bemeneti objektumának megjelenítéséhez. A Using: hatókör-módosítóval változóhivatkozásokat adhat át a futó szkriptblokknak.

További információ: ForEach-Object.

A windowsos kompatibilis beépített modulok system32 ellenőrzése

A Windows 10 1809 frissítésében és a Windows Server 2019-ben számos beépített PowerShell-modult frissítettünk, hogy kompatibilisek legyenek a PowerShell-lel.

Amikor a PowerShell elindul, automatikusan tartalmazza a $windir\System32-t a PSModulePath környezeti változó részeként. Azonban csak akkor teszi elérhetővé a modulokat Get-Module és Import-Module, ha CompatiblePSEdition kompatibilisként van megjelölve a Core-al.

Ezt a viselkedést felülbírálhatja az összes modul megjelenítéséhez a -SkipEditionCheck kapcsolóparaméter használatával. Egy PSEdition tulajdonságot is hozzáadtunk a tábla kimenetéhez.

-lp alias az összes -LiteralPath paraméterhez

Létrehoztunk egy standard paraméter aliast -lp az összes beépített PowerShell-parancsmaghoz, amely rendelkezik -LiteralPath paraméterrel.

Javítsa ki Get-Item -LiteralPath a*b-t, ha a*b valójában nem létezik, hogy hibát adjon vissza.

Korábban, ha -LiteralPath-nak adott helyettesítő karakter ugyanúgy kezelték, mint -Path-et, és ha a helyettesítő karakter nem talált fájlokat, akkor észrevétlenül kilépett. A helyes viselkedésnek az kell lennie, hogy a -LiteralPath literálként viselkedjen, ezért ha a fájl nem létezik, akkor hibaüzenetet kell kiadnia. A módosítás a -Literal által használt helyettesítő karaktereket konstansként kezeli.

A munkakönyvtárat állítsuk be az aktuális könyvtárra a Start-Job

A Start-Job parancsmag most az aktuális könyvtárat használja az új feladat munkakönyvtáraként.

Távolítsa el a -Protocol elemet a *-Computer parancsmagokból.

A CoreFX-ben (különösen a nem Windows-platformokon) végzett RPC-újraformálással és a PowerShell konzisztens újraformálási élményének biztosításával kapcsolatos problémák miatt a -Protocol paraméter el lett távolítva a \*-Computer parancsmagokból. A DCOM már nem támogatott távoli eléréshez. A következő parancsmagok csak a WSMAN távoli elérést támogatják:

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

-ComputerName eltávolítása *-Service parancsmagokból

A PSRP konzisztens használatának ösztönzése érdekében a -ComputerName paraméter el lett távolítva *-Service parancsmagokból.

Kijavítottuk Get-Content -Delimiter, hogy ne szerepeljen a határoló a visszaadott sorokban

Korábban a Get-Content -Delimiter használata során a kimenet inkonzisztens és kényelmetlen volt, mivel az adatok további feldolgozására volt szükség a határoló eltávolításához. Ez a módosítás eltávolítja a visszaküldött sorok elválasztójelét.

A Format-Hex módosítása

A -Raw paraméter mostantól "no-op" (mivel semmit sem tesz). Az összes kimenet előrehaladtával a számok valódi ábrázolása jelenik meg, amely a típushoz tartozó összes bájtot tartalmazza. Ezt tette a -Raw paraméter a módosítás előtt.

Elírás javítása Get-ComputerInfo tulajdonságnévben

BiosSerialNumber BiosSeralNumber hibásan lett elírva, és a helyes helyesírásra módosult.

Get-StringHash és Get-FileHash parancsmagok hozzáadása

Ez a változás azt jelzi, hogy egyes kivonatoló algoritmusokat a CoreFX nem támogat, ezért ezek már nem érhetők el:

  • MACTripleDES
  • RIPEMD160

Érvényesítést adjon hozzá a Get-* parancsmagokhoz, amikor $null értéket ad át, hogy hiba helyett az összes objektumot adja vissza.

A $null az alábbiak bármelyikének való átadása hibát jelez:

  • 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

Támogatás hozzáadása a W3C kiterjesztett naplófájlformátumhoz a Import-Csv-ban

Korábban a Import-Csv parancsmag nem használható a naplófájlok W3C kiterjesztett naplófájlformátumban való közvetlen importálására, és további műveletre lenne szükség. Ezzel a módosítással a W3C kiterjesztett naplóformátuma támogatott.

Import-Csv pstypenames alkalmaz az importáláskor, ha a típusadatok megtalálhatók a CSV-ben

Korábban a ConvertFrom-Csv importált TypeInformationExport-Csv használatával exportált objektumok nem őrizték meg a típusadatokat. Ez a módosítás hozzáadja a típusadatokat pstypenames taghoz, ha elérhetők a CSV-fájlból.

-NoTypeInformation az alapértelmezett beállítás Export-Csv-en.

Korábban a Export-Csv parancsmag egy megjegyzést adott ki az objektum típusnevét tartalmazó első sorként. A módosítás alapértelmezés szerint kizárja a típusadatokat, mert a legtöbb CSV-eszköz nem érti. Ez a módosítás az ügyfelek visszajelzésének kezelése érdekében történt.

A -IncludeTypeInformation használatával megtarthatja az előző viselkedést.

* használatát engedélyezni a Remove-Item beállításjegyzék elérési útjában

Korábban, ha -LiteralPath helyettesítő karaktert kapott, ugyanúgy kezelte, mint -Path, és ha a helyettesítő karakter nem talált fájlokat, akkor csendben kilépett. A helyes működésnek az kell lennie, hogy -LiteralPath literál, ezért ha a fájl nem létezik, akkor hibát kell jeleznie. A változás az, hogy a -Literal által használt helyettesítő karaktereket mint konstansokat kezeli.

Group-Object most rendezi a csoportokat

A teljesítményjavítás részeként a Group-Object most a csoportok rendezett listáját adja vissza. Bár nem szabad a sorrendre támaszkodnia, az első csoport használata esetén ez a változás megtörheti. Úgy döntöttünk, hogy ez a teljesítménybeli javulás megéri a változást, mivel a korábbi viselkedéstől való függés hatása alacsony.

Szórás Measure-Object

A Measure-Object kimenete mostantól tartalmaz egy StandardDeviation tulajdonságot.

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 most már rendelkezik a Password paraméterrel, amely SecureString-t fogad. Ez lehetővé teszi, hogy nem interaktív módon használja:

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

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

A more függvény eltávolítása

Korábban a PowerShell egy more nevű függvényt tartalmazott a Windowsban, amely more.com-et burkolt. Ez a függvény most el lett távolítva.

A help függvény megváltozott, hogy Windows rendszeren a more.com-et használja, vagy nem Windows rendszereken a $Env:PAGER által megadott alapértelmezett lapozót.

cd DriveName: most visszaadja a felhasználókat a meghajtó aktuális munkakönyvtárába

Korábban a Set-Location vagy cd használata a felhasználókat az adott PSDrive alapértelmezett helyére küldte vissza. A rendszer a felhasználókat a munkamenet utolsó ismert aktuális munkakönyvtárába küldi.

cd - visszatér az előző könyvtárhoz

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

Vagy Linuxon:

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

Emellett cd és cd --$HOME-vá változnak.

Update-Help nem rendszergazdaként

A népszerű igények szerint a Update-Help már nem kell rendszergazdaként futtatni. Update-Help mostantól alapértelmezés szerint egy felhasználó által hatókörrel rendelkező mappába menti a súgót.

Where-Object -Not

Ha hozzáadja a -Not paramétert a Where-Object-hez, szűrhet egy objektumot a folyamat során a tulajdonság nemlétezésére vagy null/üres tulajdonságértékre.

Ez a parancs például az összes olyan szolgáltatást visszaadja, amely nem rendelkezik függő szolgáltatásokkal:

Get-Service | Where-Object -Not DependentServices

Webes parancsmagok módosítása

A webes parancsmagok mögöttes .NET API-ja meg lett változtatva System.Net.Http.HttpClient-ra. Ez a módosítás számos előnnyel jár. Ez a változás azonban az Internet Explorerrel való együttműködés hiányával együtt számos kompatibilitástörő változást eredményezett Invoke-WebRequest és Invoke-RestMethodbelül.

  • Invoke-WebRequest mostantól csak az alapszintű HTML-elemzést támogatja. Invoke-WebRequest mindig egy BasicHtmlWebResponseObject objektumot ad vissza. A ParsedHtml és Forms tulajdonságok el lettek távolítva.
  • BasicHtmlWebResponseObject.Headers értékek most String[], a Stringhelyett.
  • BasicHtmlWebResponseObject.BaseResponse mostantól System.Net.Http.HttpResponseMessage objektum.
  • A webes parancsmag kivételeinek Response tulajdonsága mostantól System.Net.Http.HttpResponseMessage objektum.
  • A szigorú RFC-fejléc-elemzés mostantól alapértelmezett a -Headers és -UserAgent paraméterhez. Ez megkerülhető, a -SkipHeaderValidationsegítségével.
  • file:// és ftp:// URI-sémák már nem támogatottak.
  • A System.Net.ServicePointManager beállítások már nem érvényesek.
  • Jelenleg nincs elérhető tanúsítványalapú hitelesítés a macOS rendszeren.
  • A -Credential használata egy http:// URI helyett hibát eredményez. Használjon https:// URI-t, vagy adja meg a -AllowUnencryptedAuthentication paramétert a hiba letiltásához.
  • -MaximumRedirection megszűnő hibát eredményez, ha az átirányítási kísérletek túllépik a megadott korlátot ahelyett, hogy az utolsó átirányítás eredményeit adják vissza.
  • A PowerShell 6.2-ben a JSON-válaszok alapértelmezett UTF-8 kódolási beállítása módosult. Ha egy JSON-válaszhoz nem ad meg karakterkészletet, az alapértelmezett kódolásnak UTF-8/RFC 8259-nek kell lennie.
  • Az alapértelmezett kódolás UTF-8 értékre van állítva application-json válaszokhoz
  • Hozzáadott -SkipHeaderValidation paraméter, amely lehetővé teszi Content-Type szabványnak nem megfelelő fejlécek engedélyezését
  • -Form paraméter hozzáadva az egyszerűsített multipart/form-data támogatás támogatására
  • A relációs kulcsok konform, kis- és nagybetűkre érzéketlen kezelése
  • -Resume paraméter hozzáadva a webes parancsmagokhoz

Invoke-RestMethod hasznos adatokat ad vissza, ha nem ad vissza adatot

Amikor egy API csak null-t ad vissza, Invoke-RestMethod sztringgé szerializálta "null"-t, ahelyett hogy $nulllenne. Ez a módosítás kijavítja az Invoke-RestMethod logikáját, hogy megfelelően szerializáljon egy érvényes JSON-értéket null literálként $null.

A webes parancsmagok figyelmeztetnek, ha -Credential-t titkosítatlan kapcsolatokon keresztül küldenek.

HTTP használata esetén a rendszer a jelszavakat is tartalmazó tartalmat világos szövegként küldi el. Ez a módosítás alapértelmezés szerint nem engedélyezi ezt, és hibaüzenetet ad vissza, ha a hitelesítő adatok nem biztonságosan vannak átadva. A felhasználók ezt a -AllowUnencryptedAuthentication kapcsolóval megkerülhetik.

Tegyék a webes parancsmagok -OutFile paraméterét úgy, hogy úgy működjön, mint a -LiteralPath.

A PowerShell 7.1-től kezdve a webes parancsmagok OutFile paramétere úgy működik, mint LiteralPath, és nem dolgoz fel helyettesítő karaktereket.

API-módosítások

AddTypeCommandBase osztály eltávolítása

A AddTypeCommandBase osztály el lett távolítva a Add-Type-ből a teljesítmény javítása érdekében. Ezt az osztályt csak a Add-Type parancsmag használja, és nem befolyásolhatja a felhasználókat.

A VisualBasic el lett távolítva a támogatott nyelvek közül a Add-Type-ben.

Korábban a Visual Basic-kódot a Add-Type parancsmaggal is fordíthatta le. A Visual Basicet ritkán használták Add-Type. Ezt a funkciót eltávolítottuk a PowerShell méretének csökkentése érdekében.

El lett távolítva RunspaceConfiguration támogatás

Korábban, amikor programozott módon hoz létre PowerShell-futtatóteret az API-val, használhatja az örökölt RunspaceConfiguration vagy az újabb InitialSessionState osztályokat. Ez a módosítás eltávolította a RunspaceConfiguration támogatását, és csak a InitialSessionStatetámogatja.

CommandInvocationIntrinsics.InvokeScript argumentumait $input-hez köti $args helyett

Egy paraméter helytelen pozíciója miatt az args bemenetként lett átadva args helyett.

Távolítsa el a ClrVersion és BuildVersion tulajdonságokat a $PSVersionTable-ből.

A $PSVersionTableClrVersion tulajdonsága nem hasznos a CoreCLR-ben. A végfelhasználók nem használhatják ezt az értéket a kompatibilitás meghatározásához.

A BuildVersion tulajdonság a Windows buildverzióhoz volt kötve, amely nem windowsos platformokon érhető el. A GitCommitId tulajdonság használatával kérje le a PowerShell pontos buildverzióját.

Unicode-feloldó elemzés implementálása

`u#### vagy `u{####} a rendszer a megfelelő Unicode-karakterre konvertálja. Konstans `ukimenetéhez lépjen ki a háttérből: ``u.

Paraméterkötési probléma történt a PS-függvényekben ValueFromRemainingArguments-val

ValueFromRemainingArguments mostantól tömbként adja vissza az értékeket egyetlen érték helyett, amely maga is tömb.

A CommandTypes.Workflow és a WorkflowInfoCleaned használatának egyszerűsítése

Tisztítsa meg a CommandTypes.Workflow és WorkflowInfo használatával kapcsolatos kódot a System.Management.Automation-ban.

Ezek a kisebb kompatibilitástörő változások elsősorban a súgószolgáltató kódját érintik.

  • Módosítsa a WorkflowInfo nyilvános konstruktorait belsőre. Már nem támogatjuk a munkafolyamatot, ezért érdemes nem engedélyezni, hogy a felhasználók Workflow példányokat hozzanak létre.
  • Távolítsa el a System.Management.Automation.DebugSource típust, mivel csak munkafolyamat-hibakereséshez használatos.
  • Távolítsa el a SetParent túlterhelését az absztrakt osztályból Hibakereső, amelyet csak munkafolyamat-hibakereséshez használnak.
  • Távolítsa el a SetParent azonos túlterhelését a származtatott RemotingJobDebuggerosztályból.

Ne helyezze keretbe a visszatérési eredményt PSObject, amikor egy ScriptBlock-et delegátra alakít.

Ha egy ScriptBlock delegált típusra van konvertálva, hogy C# környezetben használják, az eredmény PSObject-be való körbevonása felesleges problémákat okoz.

  • Amikor az értéket delegált visszatérési típussá konvertálja, a PSObject lényegében le lesz bontva. Tehát a PSObject szükségtelen.
  • Ha a delegált visszatérési típusa object, akkor egy PSObject-be van csomagolva, ami megnehezíti a munkát a C# kódban.

A módosítás után a visszaadott objektum az alapul szolgáló objektum.

Távsegítség

A WinRM-et Unix platformokon használó PowerShell-vezérléshez (PSRP) NTLM/Tárgyalás vagy alapszintű hitelesítés szükséges a HTTPS-en keresztül. A psRP macOS rendszeren csak az alapszintű hitelesítést támogatja HTTPS-en keresztül. A Kerberos-alapú hitelesítés nem támogatott a windowsos platformokon.

A PowerShell emellett támogatja a PowerShell-remoting (PSRP) használatát SSH-n keresztül minden platformon (Windows, macOS és Linux). További információkért olvassa el a PowerShell SSH-remotingrészt.

A PowerShell Direct for Containers először a "pwsh"-t próbálja használni.

PowerShell Direct a PowerShell és a Hyper-V egyik funkciója, amely lehetővé teszi, hogy hálózati kapcsolat vagy más távfelügyeleti szolgáltatás nélkül csatlakozzon egy Hyper-V virtuális géphez vagy tárolóhoz.

Korábban a PowerShell Direct a tároló beépített Windows PowerShell-példányával csatlakozott. Most a PowerShell Direct először megpróbál kapcsolódni a PATH környezeti változóban elérhető pwsh.exe-t használva. Ha pwsh.exe nem érhető el, a PowerShell Direct visszaesik a powershell.exehasználatára.

Enable-PSRemoting mostantól külön távoli végpontokat hoz létre az előzetes verziókhoz

Enable-PSRemoting most két távoli munkamenet-konfigurációt hoz létre:

  • Egy a PowerShell főverziói közül. Például: PowerShell.6. Ez a végpont, amely az alverzió-frissítések között "rendszerszintű" PowerShell 6-munkamenetkonfigurációként használható
  • Egy verzióspecifikus munkamenet-konfiguráció, például: PowerShell.6.1.0

Ez a viselkedés akkor hasznos, ha több PowerShell 6-verziót szeretne telepíteni és elérni ugyanazon a gépen.

Emellett a PowerShell előzetes verziói a Enable-PSRemoting parancsmag futtatása után saját távoli kapcsolati munkamenet-konfigurációkat kapnak.

C:\WINDOWS\system32> Enable-PSRemoting

A kimenet eltérő lehet, ha még nem állította be a WinRM-et.

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

Ezután külön PowerShell-munkamenetkonfigurációkat láthat a PowerShell 6 előzetes és stabil buildjeihez, valamint az egyes verziókhoz.

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

user@host:port SSH által támogatott szintaxis

Az SSH-ügyfelek általában támogatnak egy kapcsolati sztringet user@host:portformátumban. Az SSH-t protokollként hozzáadtuk a PowerShell távoli hozzáféréséhez, ezzel támogatjuk az alábbi kapcsolati sztring formátumot:

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

A telemetria csak környezeti változóval tiltható le

A PowerShell alapszintű telemetriai adatokat küld a Microsoftnak az indításkor. Az adatok tartalmazzák az operációs rendszer nevét, az operációs rendszer verzióját és a PowerShell-verziót. Ezek az adatok lehetővé teszik a PowerShell használatát lehetővé tévő környezetek jobb megértését, és lehetővé teszik az új funkciók és javítások rangsorolását.

A telemetria kikapcsolásához állítsa a POWERSHELL_TELEMETRY_OPTOUT környezeti változót true, yesvagy 1értékre. A telemetria letiltásához már nem támogatjuk a fájl törlését DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY.