Sådan konfigureres Windows til at arbejde med PowerShell Scripts mere nemt

Windows og PowerShell har indbyggede sikkerhedsfunktioner og standardkonfigurationer, der har til formål at forhindre, at slutbrugerne ved et uheld lancerer scripts i løbet af deres daglige aktiviteter. Men hvis dine daglige aktiviteter rutinemæssigt involverer at skrive og køre dine egne PowerShell-scripts, kan det være mere af en gener end en fordel. Her viser vi dig, hvordan du arbejder rundt om disse funktioner uden helt at gå på kompromis med sikkerheden.

Hvordan og hvorfor Windows & PowerShell forhindrer scriptudførelse.

PowerShell er effektivt kommando shell og scripting sprog, der skal erstatte CMD og batch scripts på Windows-systemer. Som sådan kan et PowerShell-script stort set konfigureres til at gøre alt, hvad du kan gøre manuelt fra kommandolinjen. Det svarer til at gøre næsten enhver ændring mulig på dit system, op til begrænsningerne på plads på din brugerkonto. Så hvis du bare kunne dobbeltklikke på et PowerShell-script og køre det med fulde administratorrettigheder, kunne en simpel en-liner som denne virkelig ødelægge din dag:

Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyContinue | Fjern-Item -Force -Recurse -ErrorAction SilentlyContinue

Kør IKKE ovenstående kommando!

Det går simpelthen gennem filsystemet og sletter, hvad det kan. Interessant nok kan dette ikke gøre systemet ubrudt så hurtigt som du måske tror - selvom du kører fra en forhøjet session. Men hvis nogen kalder dig efter at have kørt dette script, fordi de pludselig ikke kan finde deres filer eller køre nogle programmer, "slukker og slukker det igen" vil sandsynligvis bare føre dem til Windows Startup Repair, hvor de bliver fortalt, er der intet der kan gøres for at løse problemet. Hvad der kunne være værre er, at i stedet for at få et script, der bare ødelægger deres filsystem, kan din ven blive narret til at køre en, der henter og installerer en keylogger eller fjernadgangstjeneste. Så i stedet for at stille dig spørgsmål om Startup Repair, kan de ende med at spørge politiet nogle spørgsmål om bank bedrageri!

Nu skal det være indlysende, hvorfor visse ting er nødvendige for at beskytte slutbrugerne fra sig selv, så at sige. Men strømforbrugere, systemadministratorer og andre geeks er generelt (selvom der er undtagelser) lidt mere forsigtige med disse trusler, ved at vide, hvordan man kan få øje på og nemt undgå dem, og vil bare fortsætte med at få deres arbejde udført. For at gøre dette skal de enten deaktivere eller arbejde omkring et par vejblokke:

PowerShell tillader ikke ekstern scriptudførelse som standard.
Execution Policy-indstillingen i PowerShell forhindrer udførelse af eksterne scripts som standard i alle versioner af Windows. I nogle Windows-versioner tillader det overhovedet ikke at udføre scriptudførelse. Vi viste dig, hvordan du ændrer denne indstilling i Sådan tillader du udførelse af PowerShell Scripts på Windows 7, men vi dækker det også på nogle få niveauer her.
PowerShell er ikke tilknyttet .PS1 filtypen som standard.
Vi bragte det først op i vores PowerShell Geek School-serie. Windows angiver standard handling for .PS1-filer for at åbne dem i Notesblok, i stedet for at sende dem til PowerShell-kommandotolken. Dette er at direkte forhindre utilsigtet udførelse af ondsindede scripts, når de simpelthen dobbeltklikkes.
Nogle PowerShell-scripts virker ikke uden administratorrettigheder.
Selv med at køre med en administrator-konto, skal du stadig gennemgå brugerkontrolkontrol (UAC) for at udføre bestemte handlinger. For kommandolinjeværktøjer kan det være lidt besværligt at sige mildt. Vi ønsker ikke at deaktivere UAC, men det er stadig godt, når vi kan gøre det lidt lettere at håndtere.

Disse samme problemer er opdraget i Sådan bruger du en batchfil, der gør PowerShell Scripts nemmere at køre, hvor vi går igennem ved at skrive en batchfil for midlertidigt at komme rundt om dem. Nu skal vi vise dig, hvordan du sætter dit system op med en mere langsigtet løsning. Husk på, at du generelt ikke skal foretage disse ændringer på systemer, der ikke udelukkende bruges af dig - ellers stiller du andre brugere i højere risiko for at løbe ind i de samme problemer, som disse funktioner har til formål at forhindre.

Ændring af .PS1-filforeningen.

Den første og måske mest irritation for at komme rundt er standardforeningen for .PS1-filer. Tilknytning af disse filer til andet end PowerShell.exe giver mening for at forhindre utilsigtet udførelse af uønskede scripts. Men i betragtning af at PowerShell leveres med et integreret scriptingmiljø (ISE), som er specielt designet til redigering af PowerShell-scripts, hvorfor vil vi gerne åbne .PS1-filer i Notesblok som standard? Selvom du ikke er klar til at skifte fuldt ud til at aktivere dobbeltklik-til-kør-funktionalitet, vil du nok gerne tilpasse disse indstillinger.

Du kan ændre .PS1-filforeningen til det program du vil have med kontrolpanelet Standardprogrammer, men at grave direkte ind i registreringsdatabasen giver dig lidt mere kontrol over, hvordan filerne åbnes. Dette giver dig også mulighed for at indstille eller ændre yderligere muligheder, som er tilgængelige i kontekstmenuen for .PS1-filer. Glem ikke at lave en sikkerhedskopi af registreringsdatabasen, før du gør dette!

Registreringsindstillingerne, der styrer, hvordan PowerShell-scripts åbnes, gemmes på følgende sted:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

For at undersøge disse indstillinger, før vi går om at ændre dem, skal du kigge på den nøgle og dens undernøgler med Regedit. Shell-nøglen skal kun have en værdi, "(Standard)", som er indstillet til "Åbn". Dette er en pointer til standardhandlingen for at dobbeltklikke på filen, som vi vil se i undernøglerne.

Udvid Shell-tasten, og du vil se tre undernøgler. Hver af disse repræsenterer en handling, du kan udføre, som er specifik for PowerShell-scripts.

Du kan udvide hver nøgle til at udforske værdierne indenfor, men de svarer i det væsentlige til følgende standardindstillinger:

0 - Kør med PowerShell. "Kør med PowerShell" er faktisk navnet på en mulighed allerede i kontekstmenuen til PowerShell-scripts. Teksten er kun trukket fra et andet sted i stedet for at bruge nøglenavnet som de andre. Og det er stadig ikke standard dobbelt klik handling.
Rediger - Åbn i PowerShell ISE. Dette giver meget mere mening end Notesblok, men du skal stadig højreklikke på .PS1 filen for at gøre det som standard.
Åben - Åbn i notesblok. Bemærk at dette nøgle navn også er den streng, der er gemt i "(Standard)" -værdien af Shell-nøglen. Dette betyder at dobbeltklikke på filen vil "Åbne" den, og denne handling er normalt indstillet til at bruge Notesblok.

Hvis du vil holde fast ved de allerede indbyggede kommandostreng, kan du bare ændre værdien "(Standard)" i Shell-tasten for at matche navnet på den nøgle, der matcher det, du vil have et dobbeltklik med at gøre. Dette kan nemt gøres indenfor Regedit, eller du kan bruge erfaringer fra vores vejledning om udforskning af registreringsdatabasen med PowerShell (plus en lille PSDrive-tweak) for at begynde at opbygge et genbrugeligt script, der kan konfigurere dine systemer til dig. De nedenstående kommandoer skal køres fra en forhøjet PowerShell-session, som ligner at køre CMD som administrator.

For det første vil du konfigurere en PSDrive til HKEY_CLASSES_ROOT, da dette ikke er konfigureret som standard. Kommandoen til dette er:

Ny PSDrive HKCR Registry HKEY_CLASSES_ROOT

Nu kan du navigere og redigere registreringsnøgler og værdier i HKEY_CLASSES_ROOT ligesom du ville i de almindelige HKCU og HKLM PSDrives.

For at konfigurere dobbeltklik for at starte PowerShell-scripts direkte:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Standard)' 0

Sådan konfigureres dobbeltklik for at åbne PowerShell-scripts i PowerShell ISE:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Standard) "Rediger"

For at gendanne standardværdien (sæt dobbeltklik for at åbne PowerShell-scripts i Notesblok):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Standard) "Åbn"

Det er bare det grundlæggende at ændre standard dobbeltklikke handling. Vi går nærmere ind på at tilpasse, hvordan PowerShell-scripts håndteres, når de åbnes i PowerShell fra Explorer i næste afsnit. Husk, at scoping forhindrer PSDrives i at fortsætte på tværs af sessioner. Så du vil sandsynligvis gerne medtage New-PSDrive-linjen ved starten af et konfigurationsskript, du opbygger til dette formål, eller tilføjer det til din PowerShell-profil. Ellers skal du køre den pågældende bit manuelt, før du forsøger at foretage ændringer på denne måde.

Ændring af PowerShell ExecutionPolicy-indstillingen.

PowerShell's ExecutionPolicy er et andet lag af beskyttelse mod udførelse af ondsindede scripts. Der er flere muligheder for dette, og et par forskellige måder, det kan indstilles. Fra de fleste til mindst sikre er de tilgængelige muligheder:

Begrænset - Ingen scripts må løbe. (Standardindstilling for de fleste systemer.) Dette vil endda forhindre, at dit profil script bliver kørt.
AllSigned - Alle scripts skal signeres digitalt af en pålidelig udgiver, der skal køre uden at anmode brugeren om det. Scripts underskrevet af udgivere, der udtrykkeligt er defineret som usikre, eller scripts, der ikke er signeret digitalt, vil ikke blive kørt. PowerShell vil bede brugeren om bekræftelse, hvis et script er underskrevet af en udgiver, der endnu ikke er defineret som betroet eller usikker. Hvis du ikke digitalt har underskrevet dit profil script og etableret tillid til den signatur, vil den ikke kunne køre. Pas på, hvilke udgivere du stoler på, da du stadig kan ende med at køre ondsindede scripts, hvis du stoler på den forkerte.
RemoteSigned - For scripts hentet fra internettet er dette faktisk det samme som "AllSigned". Skrifter, der er oprettet lokalt eller importeret fra andre kilder end internettet, må dog køre uden nogen bekræftelsesprompning. Her skal du også være forsigtig med hvilke digitale signaturer du stoler på, men selv være mere forsigtig med de ikke-underskrevne scripts, du vælger at køre. Dette er det højeste sikkerhedsniveau, hvor du kan have et arbejdsprofil script uden at skulle signere det digitalt.
Ubegrænset - Alle scripts må køre, men der kræves en bekræftelsesprompt for scripts fra internettet. Fra dette punkt er det helt op til dig at undgå at køre uværdige scripts.
Bypass - Alt går uden advarsel. Pas på med denne.
Udefineret - Ingen politik er defineret i det nuværende anvendelsesområde. Dette bruges til at tillade tilbagekaldelse af politikker defineret i lavere scopes (flere detaljer nedenfor) eller til standardindstillingerne for OS.

Som foreslået af beskrivelsen af Udefineret, kan ovennævnte politikker indstilles i en eller flere af flere anvendelsesområder. Du kan bruge Get-ExecutionPolicy, med -List parameteren, for at se alle scopes og deres nuværende konfiguration.

Omfangene er angivet i forrangsordre, med det øverste definerede anvendelsesområde, der overholder alle andre. Hvis der ikke er defineret nogen politikker, falder systemet tilbage til standardindstillingen (i de fleste tilfælde er dette begrænset).

MachinePolicy repræsenterer en koncernpolitik i kraft på computerniveau. Dette gælder generelt kun i et domæne, men det kan også gøres lokalt.
UserPolicy repræsenterer en koncernpolitik, der er gældende for brugeren. Dette bruges også kun i virksomhedsmiljøer.
Proces er et anvendelsesområde, der er specifikt for dette eksempel på PowerShell. Ændringer i politikken i dette anvendelsesområde vil ikke påvirke andre løbende PowerShell-processer, og det vil være ineffektivt, efter at denne session er afsluttet. Dette kan konfigureres af parameteren -ExecutionPolicy, når PowerShell lanceres, eller det kan indstilles med den korrekte Set-ExecutionPolicy-syntaks fra sessionsperioden.
CurrentUser er et anvendelsesområde, der er konfigureret i det lokale register og gælder for brugerkontoen, der bruges til at starte PowerShell. Dette anvendelsesområde kan ændres med Set-ExecutionPolicy.
LocalMachine er et anvendelsesområde, der er konfigureret i det lokale register og gælder for alle brugere på systemet. Dette er standardomfanget, der ændres, hvis Set-ExecutionPolicy køres uden -Scope-parameteren. Som det gælder for alle brugere på systemet, kan det kun ændres fra en forhøjet session.

Da denne artikel primært handler om at komme rundt om sikkerhed for at gøre brugervenligheden, er vi bare bekymrede over de tre nedre områder. Indstillingerne MachinePolicy og UserPolicy er kun nyttige, hvis du vil håndhæve en restriktiv politik, der ikke er så enkelt omgået. Ved at holde vores ændringer til procesniveauet eller nedenunder kan vi nemt bruge hvilken som helst politikindstilling, som vi finder passende for en given situation til enhver tid.

For at bevare en vis balance mellem sikkerhed og brugervenlighed er den politik, der vises på skærmbilledet, nok bedst. Indstilling af LocalMachine-politikken til Begrænset forhindrer generelt at køre scripts af andre end dig. Selvfølgelig kan dette blive omgået af brugere, som ved, hvad de laver uden stor indsats. Men det bør holde alle ikke-tech-savvy brugere fra et uheld udløse noget katastrofalt i PowerShell. Hvis du har CurrentUser (dvs.: dig) angivet som Ubegrænset, kan du manuelt udføre scripts fra kommandolinjen, men du vil beholde en advarsel om forsigtighed for scripts hentet fra internettet. Indstillingen RemoteSigned på procesniveau skal gøres i en genvej til PowerShell.exe eller (som vi gør nedenfor) i registreringsværdierne, der styrer opførelsen af PowerShell-scripts. Dette vil muliggøre let dobbeltklik-til-kør-funktionalitet for eventuelle scripts, du skriver, samtidig med at du opretter en stærkere barriere mod utilsigtet udførelse af (potentielt skadelige) scripts fra eksterne kilder. Vi vil gerne gøre dette her, da det er meget lettere at ved et uheld dobbeltklikke på et script, end det generelt er at kalde det manuelt fra en interaktiv session.

For at indstille CurrentUser og LocalMachine-politikkerne som i skærmbilledet ovenfor, kør følgende kommandoer fra en forhøjet PowerShell-session:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Ubegrænset -Scope CurrentUser

For at håndhæve RemoteSigned-politikken på scripts kører fra Explorer, skal vi ændre en værdi inde i en af de registreringsnøgler, vi kigger på tidligere. Dette er særligt vigtigt, fordi standardkonfigurationen afhænger af din PowerShell- eller Windows-version kan være at omgå alle ExecutionPolicy-indstillinger undtagen AllSigned. For at se, hvad den nuværende konfiguration er for din computer, kan du køre denne kommando (sørg for, at HKCR PSDrive er kortlagt først):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Vælg-objekt '(standard)'

Din standardkonfiguration vil sandsynligvis være en af følgende to strenge, eller noget, der er ret lignende:

(Set på Windows 7 SP1 x64, med PowerShell 2.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-fil" "% 1"

(Set på Windows 8.1 x64, med PowerShell 4.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "hvis ((Get-ExecutionPolicy) -En AllSigned ') Set-ExecutionPolicy -Scope Process Bypass; &'% 1 '"

Den første er ikke alt for dårlig, da alt det gør er at udføre scriptet under de eksisterende ExecutionPolicy-indstillinger. Det kunne gøres bedre ved at håndhæve strammere begrænsninger for en mere uheldsberettiget handling, men det var ikke oprindeligt beregnet til at blive udløst med et dobbeltklik, alligevel, og standardpolitikken er normalt begrænset. Den anden mulighed er imidlertid en fuld bypass af uanset ExecutionPolicy du sandsynligvis vil have på plads - selv Begrænset. Da bypasset vil blive anvendt i procesomfanget, påvirker det kun de sessioner, der lanceres, når scripts køres fra Explorer. Dette betyder dog, at du kan ende med at starte scripts, som du ellers ville forvente (og vil) have politik til at forbyde.

For at indstille Procesniveau ExecutionPolicy for scripts, der er lanceret fra Explorer, i tråd med skærmbilledet ovenfor, skal du ændre den samme registreringsværdi, som vi lige har forespurgt. Du kan gøre det manuelt i Regedit, ved at ændre det til dette:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-fil" "% 1"

Du kan også ændre indstillingen fra PowerShell, hvis du foretrækker det. Husk at gøre dette fra en forhøjet session, med HKCR PSDrive kortlagt.

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(Standard) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -ExecutionPolicy "" RemoteSigned "" -fil "" % 1" '

Kør PowerShell-scripts som administrator.

Ligesom det er en dårlig ide at deaktivere UAC helt, er det også dårlig sikkerhedspraksis at køre scripts eller programmer med forhøjede rettigheder, medmindre du faktisk har brug for dem til at udføre operationer, der kræver administratoradgang. Så det anbefales ikke at opbygge UAC-prompten i standardhandlingen for PowerShell-scripts. Vi kan dog tilføje en ny kontekstmenu, så vi nemt kan køre scripts i forhøjede sessioner, når vi skal. Dette ligner den metode, der bruges til at tilføje "Åbn med notepad" til kontekstmenuen for alle filer - men her skal vi kun målrette PowerShell-scripts. Vi vil også overføre nogle teknikker, der blev brugt i den forrige artikel, hvor vi brugte en batchfil i stedet for registreringsdatabasen til at starte vores PowerShell script.

For at gøre dette i Regedit, gå tilbage til Shell-tasten på:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Derefter oprettes en ny undernøgle. Kald det "Kør med PowerShell (Admin)". Under det, opret en anden undernøgle kaldet "Command". Indstil derefter "(Standard)" -værdien under kommando til dette:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"' -Verb RunAs "

At gøre det samme i PowerShell vil faktisk have brug for tre linjer denne gang. Én for hver ny nøgle og en for at indstille "(Standard)" værdien for kommando. Glem ikke elevation og HKCR kortlægning.

Nyt element 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kør med PowerShell (Admin)' Nyt element 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kør med PowerShell (Admin) \ Kommando' Set-ItemProperty ' HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kør med PowerShell (Admin) \ Command "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" &  Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs ""

Vær også opmærksom på forskellene mellem den streng, der indsættes via PowerShell, og den faktiske værdi, der går ind i registreringsdatabasen. Især er vi nødt til at indpakke hele sagen i single-citater og fordoble de interne single-citater for at undgå fejl i kommandoparsering.

Nu skal du have en ny kontekst-menupunkt for PowerShell-scripts, kaldet "Kør med PowerShell (Admin)".

Den nye mulighed vil gyde to på hinanden følgende PowerShell-forekomster. Den første er kun en launcher for den anden, der bruger Start-Process med parameteren "-Verb RunAs" for at anmode om højde for den nye session. Derefter skal dit script kunne køre med administratorrettigheder efter at du har klikket på UAC-prompten.

Efterbehandling berører.

Der er kun et par mere tweaks til dette, der kan hjælpe med at gøre livet endnu lettere. For det første, hvad med at slippe af med Notepad-funktionen helt? Kopier simpelthen "(Standard)" -værdien fra kommandotasten under Rediger (nedenfor), til samme sted under Åbn.

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"

Eller du kan bruge denne bit af PowerShell (med Admin & HKCR selvfølgelig):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command '(Standard) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe ""% 1 "'

En yderligere mindre irritation er konsolens vane at forsvinde, når et script er færdigt. Når det sker, har vi ikke nogen chance for at gennemse script-output for fejl eller anden nyttig information. Dette kan tages hånd om ved at sætte en pause i slutningen af hvert af dine scripts, selvfølgelig. Alternativt kan vi ændre "(Standard)" værdierne for vores kommandotaster for at inkludere parameteren "-NoExit". Nedenfor er de modificerede værdier.

(Uden administratoradgang)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-fil" "% 1"

(Med Admin adgang)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ "% 1 \"' - Verb RunAs "

Og selvfølgelig giver vi dem i PowerShell-kommandoer også. Sidste påmindelse: Elevation & HKCR!

(Non-Admin)

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(Standard) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit "" -ExecutionPolicy "" RemoteSigned "" -filen ""% 1 "'

(Admin)

Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Kør med PowerShell (Admin) \ Command "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" Og Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs ""

Tager det til et spin.

For at teste dette ud vil vi bruge et script, som kan vise os Execution Policy-indstillingerne på plads og om scriptet blev lanceret med administratorrettigheder eller ej. Scriptet hedder "MyScript.ps1" og gemmes i "D: \ Script Lab" på vores samplesystem. Koden er nedenfor, som reference.

if (([Sikkerhed.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) Skriv-Output 'Kører som administrator!' ellers Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Brug af "Kør med PowerShell" -handling:

Ved at bruge "Kør med PowerShell (Admin)" handling, efter at du har klikket på UAC:

For at demonstrere ExecutionPolicy i aktion i procesomfanget kan vi få Windows til at tro, at filen kom fra internettet med denne smule PowerShell-kode:

Add-indhold parameteren PATH 'D: \ Script Lab \ MyScript.ps1' -værdi "[ZoneTransfer] 'nZoneId = 3" -Stream 'Zone.Identifier'

Heldigvis havde vi -NoExit aktiveret. Ellers ville den fejl bare have blinket på, og vi ville ikke have kendt!

Zone.Identifier kan fjernes med dette:

Clear-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Stream 'Zone.Identifier'

Nyttige referencer:

Running PowerShell scripts fra en batchfil - Daniel Schroeders Programmeringsblog
Kontrol af administratorrettigheder i PowerShell - Hej, Scripting Guy! Blog