Slik konfigurerer du Windows for å arbeide med PowerShell-skript lettere

Windows og PowerShell har innebygde sikkerhetsfunksjoner og standardkonfigurasjoner som skal forhindre at sluttbrukerne ved et uhell lanserer skript i løpet av deres daglige aktiviteter. Men hvis dine daglige aktiviteter rutinemessig involverer å skrive og kjøre egne PowerShell-skript, kan dette være mer av en plage enn en fordel. Her viser vi deg hvordan du arbeider rundt disse funksjonene uten å fullstendig ødelegge sikkerheten.

Hvordan og hvorfor Windows og PowerShell forhindrer utføring av skript.

PowerShell er effektivt kommandoskallet og skriptspråk som er ment å erstatte CMD- og batchskript på Windows-systemer. Som et slikt, kan et PowerShell-skript ganske mye bli konfigurert til å gjøre alt du kan gjøre manuelt fra kommandolinjen. Det tilsvarer å gjøre praktisk talt enhver endring mulig på systemet ditt, opp til restriksjonene på plass på din brukerkonto. Så hvis du bare kan dobbeltklikke på et PowerShell-skript og kjøre det med full administratorrettigheter, kan en enkel en-liner som dette virkelig ødelegge dagen din:

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

Kjør IKKE kommandoen ovenfor!

Det går ganske enkelt gjennom filsystemet og sletter alt det kan. Interessant, dette kan ikke gjøre systemet ubrukbart så fort du kanskje tror - selv når du kjører fra en forhøyet økt. Men hvis noen ringer deg etter at du har kjørt dette skriptet, fordi de plutselig ikke kan finne sine filer eller kjøre noen programmer, "slår den av og på igjen", vil trolig bare lede dem til Windows Startup Repair hvor de skal bli fortalt det er ingenting som kan gjøres for å fikse problemet. Hva som kan bli verre er, i stedet for å få et skript som bare ødelegger filsystemet, kan vennen din bli lurt på å kjøre en som laster ned og installerer en keylogger eller ekstern tilgangstjeneste. Deretter, i stedet for å stille deg spørsmål om Startup Repair, kan de ende opp med å spørre politiet noen spørsmål om bank svindel!

Nå skal det være åpenbart hvorfor visse ting er nødvendig for å beskytte sluttbrukere fra seg selv, så å si. Men strømforbrukere, systemadministratorer og andre geeks er generelt (selv om det er unntak) litt mer skeptisk til disse truslene, å vite hvordan de kan få øye på og enkelt unngå dem, og vil bare fortsette å få sitt arbeid gjort. For å gjøre dette må de enten deaktivere eller jobbe rundt noen få blokkeringer:

PowerShell tillater ikke ekstern scriptutførelse som standard.
Innstillingen Execution Policy i PowerShell forhindrer utførelse av eksterne skript som standard i alle versjoner av Windows. I enkelte Windows-versjoner tillater ikke standard i det hele tatt script-utførelse. Vi viste deg hvordan du endrer denne innstillingen i Slik tillater du å utføre PowerShell-skript på Windows 7, men vi vil dekke det på noen få nivåer her også.
PowerShell er ikke knyttet til .PS1 filutvidelsen som standard.
Vi tok opp dette opprinnelig i vår PowerShell Geek School-serie. Windows angir standardhandling for .PS1-filer for å åpne dem i Notisblokk, i stedet for å sende dem til PowerShell-kommandotolken. Dette er å forhindre utilsiktet utførelse av ondsinnede skript når de bare er dobbeltklikket.
Noen PowerShell-skript fungerer ikke uten administratorrettigheter.
Selv å kjøre med en Administrator-nivå-konto, trenger du fortsatt å gå gjennom User Account Control (UAC) for å utføre bestemte handlinger. For kommandolinjeverktøy kan dette være litt tungvint å si mildt. Vi ønsker ikke å deaktivere UAC, men det er fortsatt fint når vi kan gjøre det litt lettere å håndtere.

Disse samme problemene blir tatt opp i Hvordan bruke en batchfil for å gjøre PowerShell-skript enklere å kjøre, der vi går deg gjennom å skrive en batchfil for midlertidig å komme seg rundt dem. Nå skal vi vise deg hvordan du setter opp systemet med en mer langsiktig løsning. Husk at du ikke generelt bør gjøre disse endringene på systemer som ikke utelukkende brukes av deg - ellers setter du andre brukere i større risiko for å løpe inn i de samme problemene disse funksjonene er ment å forhindre.

Endre .PS1 filforening.

Den første, og kanskje først, irritasjonen for å komme seg rundt, er standardforeningen for .PS1-filer. Å knytte disse filene til noe annet enn PowerShell.exe, gir mening for å forhindre utilsiktet utførelse av uønskede skript. Men når vi vurderer at PowerShell kommer med et integrert skriptmiljø (ISE) som er spesielt utviklet for redigering av PowerShell-skript, hvorfor vil vi åpne .PS1-filer i Notisblokk som standard? Selv om du ikke er klar til å bytte fullstendig til å aktivere funksjonen for dobbeltklikk for å kjøre, vil du sannsynligvis tilpasse disse innstillingene.

Du kan endre .PS1-filforeningen til hvilket program du vil bruke med kontrollpanelet Standardprogrammer, men å grave direkte inn i registret gir deg litt mer kontroll over nøyaktig hvordan filene skal åpnes. Dette lar deg også sette inn eller endre tilleggsalternativer som er tilgjengelige i kontekstmenyen for .PS1-filer. Ikke glem å sikkerhetskopiere registeret før du gjør dette!

Registerinnstillingene som kontrollerer hvordan PowerShell-skript åpnes lagres på følgende sted:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

For å utforske disse innstillingene før vi går om å endre dem, ta en titt på den nøkkelen og dens undernøkler med Regedit. Shell-nøkkelen skal bare ha en verdi, "(Standard)", som er satt til "Åpne". Dette er en peker til standardhandling for å dobbeltklikke på filen, som vi ser i undernøklene.

Utvid Shell-nøkkelen, og du vil se tre undernøkler. Hver av disse representerer en handling du kan utføre som er spesifikk for PowerShell-skript.

Du kan utvide hver nøkkel for å utforske verdiene i, men de baserer seg i utgangspunktet på følgende standardverdier:

0 - Kjør med PowerShell. "Kjør med PowerShell" er faktisk navnet på et alternativ allerede i kontekstmenyen for PowerShell-skript. Teksten er bare trukket fra et annet sted i stedet for å bruke nøkkelnavnet som de andre. Og det er fortsatt ikke standard dobbeltklikk handling.
Rediger - Åpne i PowerShell ISE. Dette gir mye mer mening enn Notisblokk, men du må fortsatt høyreklikke .PS1-filen for å gjøre det som standard.
Åpne - Åpne i Notisblokk. Merk at dette nøkkelnavnet også er strengen som er lagret i "(Standard)" -verdien av Shell-nøkkelen. Dette betyr at dobbeltklikk på filen vil "Åpne" den, og at handlingen normalt settes til Notepad.

Hvis du vil holde fast med de forhåndsbygde kommandostrengene som allerede er tilgjengelige, kan du bare endre "(Standard)" -verdien i Shell-tasten for å matche navnet på nøkkelen som samsvarer med det du vil ha et dobbeltklikk for å gjøre. Dette kan enkelt gjøres fra Regedit, eller du kan bruke erfaringer fra vår veiledning om å utforske registeret med PowerShell (pluss en liten PSDrive-tweak) for å begynne å bygge et gjenbrukbart skript som kan konfigurere systemene dine for deg. Kommandoene nedenfor må kjøres fra en forhøyet PowerShell-økt, som ligner på å kjøre CMD som administrator.

Først vil du konfigurere en PSDrive for HKEY_CLASSES_ROOT siden dette ikke er konfigurert som standard. Kommandoen for dette er:

Ny PSDrive HKCR-register HKEY_CLASSES_ROOT

Nå kan du navigere og redigere registernøkler og verdier i HKEY_CLASSES_ROOT akkurat som du ville i de vanlige HKCU og HKLM PSDrives.

For å konfigurere dobbeltklikk for å starte PowerShell-skript direkte:

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

For å konfigurere dobbeltklikk for å åpne PowerShell-skript i PowerShell ISE:

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

For å gjenopprette standardverdien (sett dobbeltklikk for å åpne PowerShell-skript i Notisblokk):

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

Det er bare grunnleggende om å endre standard dobbeltklikk handling. Vi vil gå nærmere på hvordan du tilpasser hvordan PowerShell-skript håndteres når de åpnes i PowerShell fra Explorer i neste avsnitt. Husk at scoping hindrer PSDrives fra å fortsette på tvers av sesjoner. Så vil du sannsynligvis inkludere New-PSDrive-linjen ved starten av et konfigurasjonsskript du bygger for dette formålet, eller legg det til i PowerShell-profilen din. Ellers må du kjøre den bit manuelt før du prøver å gjøre endringer på denne måten.

Endre PowerShell ExecutionPolicy-innstillingen.

PowerShells ExecutionPolicy er et annet lag av beskyttelse mot utførelse av ondsinnede skript. Det er flere alternativer for dette, og et par forskjellige måter det kan settes på. Fra de fleste til minst sikre er tilgjengelige alternativer:

Begrenset - Ingen skript får lov til å kjøre. (Standardinnstilling for de fleste systemer.) Dette vil til og med forhindre at profilskriptet ditt kjører.
AllSigned - Alle skript må være digitalt signert av en klarert utgiver for å kjøre uten å spørre brukeren. Skript signert av utgivere som er uttrykkelig definert som usikre, eller skript som ikke er digitalt signert i det hele tatt, vil ikke kjøre. PowerShell vil spørre brukeren om bekreftelse dersom et skript er signert av en utgiver som ennå ikke er definert som pålitelig eller usikker. Hvis du ikke digitalt har signert profilskriptet ditt, og etablert tillit til den signaturen, vil den ikke kunne kjøre. Vær forsiktig med hvilke utgivere du stoler på, siden du fortsatt kan ende opp med å kjøre ondsinnede skript hvis du stoler på den gale.
RemoteSigned - For skript som er lastet ned fra Internett, er dette effektivt det samme som "AllSigned". Skript som er opprettet lokalt eller importert fra andre kilder enn Internett, kan imidlertid kjøre uten noen spørsmål om bekreftelse. Her må du også være forsiktig med hvilke digitale signaturer du stoler på, men til og med være mer forsiktig med de ikke-signerte skriptene du velger å kjøre. Dette er det høyeste sikkerhetsnivået under hvilket du kan ha et fungerende profilskript uten å måtte signere det digitalt.
Ubegrenset - Alle skript har lov til å kjøre, men en bekreftelsespørsmål vil bli krevd for skript fra Internett. Fra dette punktet er det helt opp til deg å unngå å kjøre uverdige skript.
Bypass - Alt går uten advarsel. Vær forsiktig med denne.
Udefinert - Ingen policy er definert i det nåværende omfanget. Dette brukes til å tillate tilbakebetaling til politikk definert i lavere rekkevidde (flere detaljer nedenfor) eller til OS-standardene.

Som foreslått av beskrivelsen av Udefinert, kan ovennevnte retningslinjer settes i en eller flere av flere områder. Du kan bruke Get-ExecutionPolicy, med -List parameter, for å se alle rekkevidde og deres nåværende konfigurasjon.

Omfangene er oppført i forrangsordre, med det øverste definerte omfanget som overstyrer alle andre. Hvis ingen retningslinjer er definert, faller systemet tilbake til standardinnstillingen (i de fleste tilfeller er dette begrenset).

MachinePolicy representerer en konsernpolitikk som er i kraft på datamaskinnivå. Dette gjelder vanligvis bare i et domene, men kan også gjøres lokalt.
UserPolicy representerer en konsernpolitikk som er i kraft på brukeren. Dette brukes også bare i bedriftsmiljøer.
Prosess er et omfang som er spesifikt for denne forekomsten av PowerShell. Endringer i retningslinjene i dette omfanget vil ikke påvirke andre kjørende PowerShell-prosesser, og vil være ineffektive etter at denne økten er avsluttet. Dette kan konfigureres av parameteren -ExecutionPolicy når PowerShell er lansert, eller det kan settes med riktig Sett-ExecutionPolicy-syntaks fra sangen.
CurrentUser er et omfang som er konfigurert i det lokale registeret og gjelder for brukerkontoen som ble brukt til å starte PowerShell. Dette omfanget kan endres med Set-ExecutionPolicy.
LocalMachine er et omfang som er konfigurert i det lokale registeret og gjelder for alle brukere på systemet. Dette er standardomfanget som endres hvis Set-ExecutionPolicy kjøres uten -Scope-parameteren. Som det gjelder for alle brukere på systemet, kan det bare endres fra en forhøyet økt.

Siden denne artikkelen hovedsakelig handler om å bevege seg rundt for å lette brukervennlighet, er vi bare opptatt av de tre nedre delene. Innstillingene MachinePolicy og UserPolicy er bare nyttige hvis du vil håndheve en restriktiv politikk som ikke er så enkelt omgått. Ved å holde våre endringer på prosessnivå eller under, kan vi til enhver tid enkelt bruke hvilken politikkinnstilling som vi anser passende for en gitt situasjon.

For å opprettholde en viss balanse mellom sikkerhet og brukervennlighet, er politikken som vises i skjermbildet trolig best. Innstilling av LocalMachine-politikken til Begrenset forhindrer generelt kjøreskript av noen andre enn deg. Selvfølgelig kan dette bli omgått av brukere som vet hva de gjør uten mye innsats. Men det bør holde alle ikke-teknologiske kunnskapsrike brukere fra et uhell utløse noe katastrofalt i PowerShell. Å ha CurrentUser (ie.e .: you) sett som Ubegrenset gjør det mulig å manuelt utføre skript fra kommandolinjen uansett, men beholder en påminnelse om forsiktighet for skript lastet ned fra Internett. Innstillingen RemoteSigned på prosessnivået må gjøres i en snarvei til PowerShell.exe eller (som vi gjør nedenfor) i registretverdiene som styrer oppførselen til PowerShell-skript. Dette vil tillate enkel dobbeltklikk til å kjøre funksjonalitet for eventuelle skript du skriver, mens du setter opp en sterkere barriere mot utilsiktet utførelse av (potensielt skadelig) skript fra eksterne kilder. Vi vil gjøre dette her, siden det er mye lettere å ved et uhell dobbeltklikke på et skript enn det vanligvis er å kalle det manuelt fra en interaktiv sesjon.

For å angi CurrentUser og LocalMachine-retningslinjene som i skjermbildet ovenfor, kjør følgende kommandoer fra en forhøyet PowerShell-økt:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Ubegrenset -Scope CurrentUser

For å håndheve RemoteSigned-politikken på skript som kjører fra Explorer, må vi endre en verdi inne i en av registernøklene vi så på tidligere. Dette er spesielt viktig fordi standardkonfigurasjonen, avhengig av PowerShell- eller Windows-versjonen, kan være å omgå alle Execution Policy-innstillinger, bortsett fra AllSigned. For å se hva den nåværende konfigurasjonen er for datamaskinen din, kan du kjøre denne kommandoen (sørg for at HKCR PSDrive er kartlagt først):

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

Standardkonfigurasjonen din vil sannsynligvis være en av følgende to strenger, eller noe som er ganske like:

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

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

(Se 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 så ille, da alt det gjør er å utføre skriptet under de eksisterende Execution Policy-innstillingene. Det kan gjøres bedre, ved å håndheve strammere begrensninger for en mer ulykkesbenlig handling, men dette var ikke opprinnelig ment å bli utløst med et dobbeltklikk uansett, og standardpolitikken er vanligvis begrenset etter alle. Det andre alternativet er imidlertid en full bypass av hva ExecutionPolicy du sannsynligvis har på plass - selv Begrenset. Siden bypasset blir brukt i prosessomfanget, påvirker det bare øktene som lanseres når skript kjøres fra Explorer. Dette betyr imidlertid at du kan ende opp med å starte skript som du ellers forventer (og vil) at politikken din skal forby.

For å angi prosessnivå ExecutionPolicy for skript som er lansert fra Explorer, i tråd med skjermbildet ovenfor, må du endre den samme registerverdien vi nettopp har spurt. Du kan gjøre det manuelt i Regedit, ved å endre det til dette:

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

Du kan også endre innstillingen fra PowerShell hvis du foretrekker det. Husk å gjøre dette fra en forhøyet økt, med HKCR PSDrive kartlagt.

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

Kjør PowerShell-skript som administrator.

Akkurat som det er en dårlig ide å deaktivere UAC helt, er det også dårlig sikkerhetspraksis å kjøre skript eller programmer med forhøyede rettigheter, med mindre du faktisk trenger dem til å utføre operasjoner som krever administratortilgang. Så det anbefales ikke å bygge UAC-ledeteksten i standardhandling for PowerShell-skript. Vi kan imidlertid legge til et nytt kontekstmenyalternativ for å tillate oss å enkelt kjøre skript i forhøyede økter når vi trenger det. Dette ligner på metoden som brukes til å legge til "Åpne med Notisblokk" i kontekstmenyen for alle filer - men her skal vi bare målrette mot PowerShell-skript. Vi skal også bære over noen teknikker som ble brukt i den forrige artikkelen, der vi brukte en batchfil i stedet for registerhack for å starte vårt PowerShell-skript.

For å gjøre dette i Regedit, gå tilbake til Shell-nøkkelen, på:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Der oppretter du en ny undernøkkel. Kaller det "Kjør med PowerShell (Admin)". Under det, opprett en annen undernøkkel som heter "Command". Deretter angir du "(Standard)" -verdien under Kommando til dette:

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

Å gjøre det samme i PowerShell vil faktisk trenge tre linjer denne gangen. En for hver ny nøkkel, og en for å angi "(Standard)" verdien for kommando. Ikke glem elevasjon og HKCR kartlegging.

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

Vær også oppmerksom på forskjellene mellom strengen som legges inn gjennom PowerShell og den faktiske verdien som går inn i registret. Spesielt må vi pakke inn hele saken i enkle anførselstegn, og dobbeltklikke på de interne single-sitatene, for å unngå feil i kommandoparsering.

Nå bør du ha en ny kontekst-menyoppføring for PowerShell-skript, kalt "Kjør med PowerShell (Admin)".

Det nye alternativet vil gyte to påfølgende PowerShell-forekomster. Den første er bare en launcher for den andre, som bruker Start-Process med parameteren "-Verb RunAs" for å be om høyde for den nye økten. Derfra skal skriptet ditt kunne kjøres med administratorrettigheter etter at du har klikket på UAC-spørringen.

Finpuss.

Det er bare et par tilpasninger til dette som kan bidra til å gjøre livet enda enklere. For en, hva med å kvitte seg med Notisblokkfunksjonen helt? Kopier bare "(Standard)" -verdien fra kommandotasten under Rediger (under), til samme sted under Åpne.

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

Du kan også bruke denne biten av 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 enda mindre irritasjon er konsollen sin vane å forsvinne når et skript er fullført. Når det skjer, har vi ingen sjanse til å gjennomgå skriptutgangen for feil eller annen nyttig informasjon. Dette kan tas vare på ved å sette en pause på slutten av hvert av skriptene dine selvfølgelig. Alternativt kan vi endre "(Standard)" -verdiene for våre kommandoknapper for å inkludere parameteren "-NoExit". Nedenfor er de endrede verdiene.

(Uten Admin tilgang)

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

(Med Admin tilgang)

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

Og selvfølgelig vil vi gi deg de i PowerShell-kommandoer også. Siste påminnelse: 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 \ Kjør med PowerShell (Admin) \ Command "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" Og Start-prosess PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs ""

Tar det for en tur.

For å teste dette ut, skal vi bruke et skript som kan vise oss Execution Policy-innstillingene på plass og om skriptet ble lansert med administratorrettigheter eller ikke. Skriptet vil bli kalt "MyScript.ps1" og bli lagret i "D: \ Script Lab" på vårt utvalgssystem. Koden er under, for referanse.

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

Ved hjelp av "Kjør med PowerShell" -handling:

Ved å bruke "Kjør med PowerShell (Admin)" -aksjonen, etter å ha klikket gjennom UAC:

For å demonstrere ExecutionPolicy i handling ved Prosessomfanget, kan vi få Windows til å tro at filen kom fra Internett med denne delen av PowerShell-koden:

Add-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Value "[ZoneTransfer] 'nZoneId = 3" -Stream' Zone.Identifier '

Heldigvis hadde vi -NoExit aktivert. Ellers ville den feilen bare ha blinket på, og vi ville ikke ha kjent det!

Zone.Identifier kan fjernes med dette:

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

Nyttige referanser:

Kjører PowerShell-skript fra en batchfil - Daniel Schroeders programmeringsblogg
Sjekker etter administratorrettigheter i PowerShell - Hei, Scripting Guy! bloggen