Dela via

about_Windows_PowerShell_5.1

Kort beskrivning

Beskriver nya funktioner som ingår i Windows PowerShell 5.1.

Lång beskrivning

Windows PowerShell 5.1 innehåller viktiga nya funktioner som utökar dess användning, förbättrar dess användbarhet och gör det möjligt att styra och hantera Windows-baserade miljöer enklare och mer omfattande.

Windows PowerShell 5.1 är bakåtkompatibelt. Cmdletar, leverantörer, moduler, snapin-moduler, skript, funktioner och profiler som har utformats för Windows PowerShell 4.0, Windows PowerShell 3.0 och Windows PowerShell 2.0 fungerar vanligtvis i Windows PowerShell 5.1 utan ändringar.

  • Nya cmdletar: lokala användare och grupper; Get-ComputerInfo
  • PowerShellGet-förbättringarna omfattar att framtvinga signerade moduler och installera JEA-moduler
  • PackageManagement har lagt till stöd för containrar, CBS-installation, EXE-baserad installation, CAB-paket
  • Felsökningsförbättringar för DSC- och PowerShell-klasser
  • Säkerhetsförbättringar, inklusive framtvingning av katalogsignerade moduler som kommer från Pull-servern och när du använder PowerShellGet-cmdletar
  • Svar på ett antal förfrågningar och problem från användare

Windows PowerShell 5.1 installeras som standard på Windows Server version 2016 och senare och Windows-klientversion 10 och senare.

Du kan också läsa om ändringar i Windows PowerShell 5.1 i Nyheter i Windows PowerShell.

PowerShell-utgåvor

Från och med version 5.1 finns PowerShell i olika utgåvor som anger olika funktionsuppsättningar och plattformskompatibilitet.

  • Desktop Edition: Bygger på .NET Framework och ger kompatibilitet med skript och moduler som är inriktade på versioner av PowerShell som körs på fullständiga fotavtrycksversioner av Windows, till exempel Server Core och Windows Desktop.
  • Core Edition: Bygger på .NET Core och ger kompatibilitet med skript och moduler som är inriktade på versioner av PowerShell som körs på mindre fotavtrycksversioner av Windows, till exempel Nano Server och Windows IoT.

Läs mer om hur du använder PowerShell-utgåvor

Katalog-cmdletar

Två nya cmdletar har lagts till i modulen Microsoft.PowerShell.Security . Dessa cmdletar genererar och validerar Windows-katalogfiler.

New-FileCatalog

New-FileCatalog skapar en Windows-katalogfil för uppsättning mappar och filer. Den här katalogfilen innehåller hashvärden för alla filer i angivna sökvägar. Användare kan distribuera uppsättningen mappar tillsammans med motsvarande katalogfil som representerar dessa mappar. Den här informationen är användbar för att kontrollera om några ändringar har gjorts i mapparna sedan katalogen skapades.

New-FileCatalog [-CatalogFilePath] <string> [[-Path] <string[]>]
 [-CatalogVersion <int>] [-WhatIf] [-Confirm] [<CommonParameters>]

Katalogversionerna 1 och 2 stöds. Version 1 använder SHA1-hashalgoritmen för att skapa filhashvärden. version 2 använder SHA256. Du bör använda katalogversion 2.

Om du vill verifiera integriteten för katalogfilen (Pester.cat i exemplet ovan) signerar du den med cmdleten Set-AuthenticodeSignature .

Test-FileCatalog

Test-FileCatalog verifierar katalogen som representerar en uppsättning mappar.

Test-FileCatalog [-Detailed] [-FilesToSkip <String[]>]
 [-CatalogFilePath] <String> [[-Path] <String[]>]
 [-WhatIf] [-Confirm] [<CommonParameters>]

Den här cmdleten jämför alla fil-hashar och deras relativa sökvägar som finns i en katalog med filer på disk. Om den identifierar ett matchningsfel mellan filhasharna och sökvägarna returneras statusen som ValidationFailed. Användare kan hämta all den här informationen med hjälp av parametern Detaljerad . Den visar också signeringsstatus för katalogen i egenskapen Signatur , vilket motsvarar att anropa cmdleten Get-AuthenticodeSignature i katalogfilen. Användare kan också hoppa över valfri fil under valideringen med hjälp av parametern FilesToSkip .

Cache för modulanalys

Från och med WMF 5.1 ger PowerShell kontroll över filen som används för att cachelagrar data om en modul, till exempel de kommandon som exporteras.

Som standard lagras den här cachen i filen ${env:LOCALAPPDATA}\Microsoft\Windows\PowerShell\ModuleAnalysisCache. Cacheminnet läss vanligtvis vid start när du söker efter ett kommando och skrivs i en bakgrundstråd någon gång efter att en modul har importerats.

Om du vill ändra standardplatsen för cacheminnet anger du $env:PSModuleAnalysisCachePath miljövariabeln innan du startar PowerShell. Ändringar i den här miljövariabeln påverkar endast barnprocesser. Värdet ska namnge en fullständig sökväg (inklusive filnamn) som PowerShell har behörighet att skapa och skriva filer. Om du vill inaktivera filcachen anger du det här värdet till en ogiltig plats, till exempel:

$Env:PSModuleAnalysisCachePath = 'nul'

Detta anger sökvägen till en ogiltig enhet. Om PowerShell inte kan skriva till sökvägen returneras inget fel, men du kan se felrapportering med hjälp av en spårning:

Trace-Command -PSHost -Name Modules -Expression {
  Import-Module Microsoft.PowerShell.Management -Force
}

När du skriver ut cacheminnet söker PowerShell efter moduler som inte längre finns för att undvika en onödigt stor cache. Du kan inaktivera kontrollerna med hjälp av följande inställning:

$Env:PSDisableModuleAnalysisCacheCleanup = 1

Inställningen av den här miljövariabeln börjar gälla omedelbart i den aktuella processen.

Ange modulversion

I WMF 5.1 using module fungerar på samma sätt som andra modulrelaterade konstruktioner i PowerShell. Tidigare hade du inget sätt att ange en viss modulversion. Om det fanns flera versioner resulterade detta i ett fel.

I WMF 5.1:

  • Du kan använda ModuleSpecification Constructor (Hashtable). Den här hash-tabellen har samma format som Get-Module -FullyQualifiedName.

    Exempel: using module @{ModuleName = 'PSReadLine'; RequiredVersion = '1.1'}

  • Om det finns flera versioner av modulen använder PowerShell samma lösningslogik som Import-Module och returnerar inte något fel.

Förbättringar av Pester

WMF 5.1 levereras med Pester v3.4.0. Mer information om den här versionen finns i CHANGELOG på GitHub-lagringsplatsen.