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 a PowerShell jelenlegi állapotának és a Windows PowerShelltől való eltérésének bemutatása. 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.6 – .NET 10.0-ra (LTS) épül
  • PowerShell 7.5 – A .NET 9.0-ra épül
  • PowerShell 7.4 – .NET 8.0-ra (LTS) épül
  • PowerShell 7.3 – A .NET 7.0-ra épül
  • PowerShell 7.2 – .NET 6.0-ra (LTS) épül
  • PowerShell 7.1 – .NET 5.0-s verzióra épül
  • PowerShell 7.0 – .NET Core 3.1 -ra (LTS) épül
  • 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 a SOAP protokoll használatához nyújt szolgáltatásokat. 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-Help 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 pwsh(.exe)powershell.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 pwsh foo.ps1megadása nélkül futtathat olyan parancsokat, mint pwsh fooScript vagy -File. 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 -ImportSystemModules-PSConsoleFile és pwsh.exe 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 válasszon a Microsoft Update vagy a WSUS segítségével történő frissítés mellett
  • 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

A Unix rendszeren az a szokás, hogy a rendszerhéjak elfogadják az interaktív üzemmódot -i esetén, és sok eszköz feltételezi ezt a viselkedést (script például, amikor a PowerShellt alapértelmezett rendszerhéjként állítják be), és a -i kapcsolóval hívja meg a rendszerhéjat. 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 beépülő modulok olyan PowerShell-modulok elődjei, amelyek nem rendelkeznek széles körű bevezetéssel 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 módosítási kérelem megváltoztatja az al-folyamatok (...), a részexpressziók $(...) és a tömbkifejezések fordítási módját, hogy $? 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, amikor a natív parancs ír a következőre stderr: $false. Gyakran előfordul, hogy a natív parancsok stderr írnak anélkül, hogy ezzel hibát kívánnának jelezni. $? 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 stderr-ra írnak anélkül, hogy hibát kívánnának jelezni. 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 $DebugPreferencehelyett a Folytatás .

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.

A változtatással a splattingból származó névvel ellátott paraméterek a paraméterlista végére kerülnek, így azok csak az összes explicit módon megadott elnevezett paraméter kötése után kerülnek kötésre. Az egyszerű függvények paraméterkötése nem jelez 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 nincs kötve a -Path, mert ez az argumentumlista harmadik argumentuma. 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. A MyPath lesz a lista első argumentuma, ezért a következőhöz -Pathvan kötve: .

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 a változónevek körül kell használni {} , például ${a} amikor ? a változó nevének ${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 változónév szintaxisa ${<name>} nem tévesztendő össze az $() 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 Remove-Service parancsmag

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ében, ha a hiba nem szkriptből vagy elemzőből származik, akkor az egyetlen soros hibaüzenet jelent:

Get-ChildItem -Path C:\NotReal

Get-ChildItem: Can't find path 'C:\NotReal' because it doesn't 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ínes escape sequence-eket (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

A párhuzamos végrehajtás hozzáadva lett 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 megadja azt a szkriptblokkot, amely párhuzamosan fut minden bemeneti napló számára.

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 -Protocol paraméter a következő parancsmagokból lett eltávolítva:

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

A DCOM már nem támogatott távoli eléréshez. A parancsmagok csak a WSMAN távoli elérést támogatják.

Távolítsa el a -ComputerName elemet a *-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. A `Invoke-Command` parancsot használja a parancsmagok távoli számítógépeken történő futtatásához.

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 most már nem tesz semmit. A Format-Hex parancsmag a számok valódi ábrázolását jeleníti meg, amely a típusához tartozó összes bájtot tartalmazza. Ezt tette a -Raw paraméter a módosítás előtt.

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

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

Az elérhető kivonatoló algoritmusok módosítása

A .NET-ből a következő kivonatoló algoritmusok lettek eltávolítva:

  • MACTripleDES
  • RIPEMD160

Ez a módosítás hatással van a Get-FileHash parancsmagra.

É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 Export-Csv és a TypeInformation segítségével exportált objektumok, amelyek ConvertFrom-Csv-val/-vel lettek importálva, nem őrizték meg a típusinformációt. 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-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.

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, ez a módosítás érzékenyen érintheti, ha az első csoportra vágyik. Ú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 a 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 a 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 ClrVersion tulajdonság $PSVersionTable 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 Windows-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 csak munkafolyamat-hibakereséshez használt absztrakt osztály SetParent túlterhelését.
  • Távolítsa el a SetParent azonos túlterhelését a származtatott RemotingJobDebuggerosztályból.

Ne helyezze a visszatérési eredményt PSObject-ba, amikor a ScriptBlock-t delegálttá alakítja.

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 használó PowerShell-remoting (PSRP) nem támogatott a nem Windows-platformokon. A PowerShell Remote Management (PSRP) használatával WinRM-en keresztül csatlakozhat Windows rendszerről más Windows-gépekhez. A PowerShell emellett támogatja az SSH távoli kapcsolatot 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 pwsh.exe környezeti változóban elérhető PATH-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.

  • Last updated on