9Sep

Sådan bruges en batchfil til at gøre PowerShell Scripts nemmere at køre

click fraud protection

Af flere årsager er de fleste sikkerhedsrelaterede PowerShell-scripts ikke lige så let bærbare og anvendelige, som batchskripter kan være. Vi kan dog bundtes et batch script med vores PowerShell-scripts til at løse disse problemer. Her vil vi vise dig et par af disse problemområder, og hvordan du opbygger et batch script til at omgå dem.

Hvorfor kan jeg ikke bare kopiere min. PS1-fil til en anden computer og køre den?

Medmindre målsystemet er forudkonfigureret for at tillade, at der køres vilkårlig scripts, med de nødvendige privilegier og ved brug af de rigtige indstillinger, er der chancer for, at du får problemer med, når du forsøger at gøre dette.

  1. PowerShell er ikke tilknyttet. PS1 filtypen som standard.
    Vi bragte dette først op i vores PowerShell Geek School-serie. Windows associerer. PS1-filer til Notesblok som standard, i stedet for at sende dem til PowerShell-kommandotolken. Dette er for at forhindre utilsigtet udførelse af ondsindede scripts ved blot at dobbeltklikke på dem. Der er måder, du kan ændre denne adfærd på, men det er nok ikke noget, du vil gøre på hver computer, du bærer dine scripts rundt til - især hvis nogle af disse computere ikke er dine egne.
    instagram viewer
  2. PowerShell tillader ikke ekstern scriptudførelse som standard.
    Indstillingen ExecutionPolicy 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. Dette er også noget, du ikke vil gøre på bare en hvilken som helst computer.
  3. Nogle PowerShell-scripts virker ikke uden administratorrettigheder.
    Selvom du kører med en administrator-konto, skal du stadig gennemgå brugerkontrolkontrol( UAC) for at udføre visse handlinger. Vi ønsker ikke at deaktivere dette, men det er stadig godt, når vi kan gøre det lidt lettere at håndtere.
  4. Nogle brugere kan have tilpassede PowerShell-miljøer.
    Du vil sandsynligvis ikke løbe ind i dette ofte, men når du gør det, kan det køre og fejle dine scripts lidt frustrerende. Heldigvis kan vi komme rundt herom uden at lave nogen permanente ændringer.

Trin 1: Dobbeltklik for at køre.

Lad os starte med at løse det første problem -. PS1 filforeninger. Du kan ikke dobbeltklikke for at køre. PS1-filer, men du kan udføre en. BAT-fil på den måde. Så vi skriver en batchfil for at ringe til PowerShell-scriptet fra kommandolinjen for os.

Så vi behøver ikke at omskrive batchfilen for hvert script, eller hver gang vi flytter et script rundt, skal det bruge en selvreferencevariabel til at opbygge filstien til PowerShell-scriptet. For at gøre dette arbejde skal batchfilen placeres i samme mappe som dit PowerShell-script og have samme filnavn. Så hvis dit PowerShell script hedder "MyScript.ps1", vil du gerne navngive din batchfil "MyScript.bat" og sørg for, at den er i samme mappe. Sæt derefter disse linjer i batch scriptet:

@ECHO OFF PowerShell.exe -Command "& '% ~ dpn0.ps1'" PAUSE

Hvis det ikke var for de øvrige sikkerhedsrestriktioner på plads, ville det virkelig være altdet kræver at køre et PowerShell-script fra en batchfil. Faktisk er de første og sidste linjer først og fremmest et spørgsmål om præference - det er den anden linje, der virkelig gør arbejdet. Her er opsplitningen:

@ECHO OFF slukker for kommandoekko. Dette holder bare dine andre kommandoer fra at blive vist på skærmen, når batchfilen kører. Denne linje er selv skjult ved brug af at( @) symbolet foran den.

PowerShell.exe -Command "&'% ~ Dpn0.ps1' " kører faktisk PowerShell-scriptet. PowerShell.exe kan naturligvis kaldes fra ethvert CMD-vindue eller batch-fil for at starte PowerShell til en bare konsol som normalt. Du kan også bruge den til at køre kommandoer direkte fra en batchfil ved at inkludere parameteren -Command og relevante argumenter. Sådan bruges dette til at målrette vores. PS1-fil med den specielle% ~ dpn0-variabel. Kør fra en batch-fil, evaluerer% ~ dpn0 til drevbogstav, mappebane og filnavn( uden udvidelse) af batchfilen. Da batchfilen og PowerShell-scriptet vil være i samme mappe og have samme navn, vil% ~ dpn0.ps1 oversætte til den fulde filsti i PowerShell-scriptet.

PAUSE sætter pause i batch-udførelsen og venter på brugerindgang. Dette er generelt nyttigt at have i slutningen af ​​dine batch-filer, så du har mulighed for at gennemgå en kommandoudgang, før vinduet forsvinder. Når vi går gennem test af hvert trin, bliver brugen af ​​dette mere tydelig.

Så den grundlæggende batchfil er oprettet. Til demonstration er denne fil gemt som "D: \ Script Lab \ MyScript.bat" og der er en "MyScript.ps1" i samme mappe. Lad os se, hvad der sker, når vi dobbeltklikker på MyScript.bat.

Selvfølgelig kørte PowerShell-scriptet ikke, men det kan man forvente - vi har jo kun taget fat på det første af vores fire problemer. Der er dog nogle vigtige bits demonstreret her:

  1. Vinduets titel viser, at batch scriptet succesfully lancerede PowerShell.
  2. Den første produktionslinje viser, at en brugerdefineret PowerShell-profil er i brug. Dette er potentielt problem nr. 4, der er anført ovenfor.
  3. Fejlmeddelelsen demonstrerer ExecutionPolicy-begrænsninger i kraft. Det er vores problem nr. 2.
  4. Den understregede del af fejlmeddelelsen( som er lavet indbygget af PowerShells fejludgang) viser, at batch scriptet var rettet mod det ønskede PowerShell script( D: \ Script Lab \ MyScript.ps1).Så vi ved i det mindste, at meget fungerer ordentligt.

Profilen er i dette tilfælde et enkelt one-line script, der bruges til denne demonstration til at generere output, når profilen er aktiv. Du kan tilpasse din egen PowerShell-profil til at gøre det også, hvis du selv vil teste disse scripts. Du skal blot tilføje følgende linje til dit profil script:

Write-Output 'Custom PowerShell-profil i kraft!'

ExecutionPolicy på testsystemet her er indstillet til RemoteSigned. Dette tillader udførelse af scripts oprettet lokalt( som profil script), mens blokering af scripts fra eksterne kilder, medmindre de er underskrevet af en betroet myndighed. Til demonstration blev følgende kommando brugt til at flagge MyScript.ps1 som værende fra en ekstern kilde:

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

Der sættes Zone. Identifier alternativ datastrøm på MyScript.ps1, så Windows vil tro, at filen kom fra internettet. Det kan let vendes med følgende kommando:

Ryd-indhold -Path 'D: \ Script Lab \ MyScript.ps1' -Stream 'Zone. Identifier'

Trin 2: Kom godt i gang med ExecutionPolicy.

Det er faktisk ret nemt at komme ind i ExecutionPolicy-indstillingen, fra CMD eller et batch script. Vi ændrer bare den anden linje i scriptet for at tilføje en yderligere parameter til kommandoen PowerShell.exe.

PowerShell.exe -ExecutionPolicy Bypass-Kommando "& '% ~ dpn0.ps1'"

Parameteren -ExecutionPolicy kan bruges til at ændre ExecutionPolicy, der bruges, når du kaster en ny PowerShell-session. Dette vil ikke vare ud over den session, så vi kan køre PowerShell sådan her, når vi har brug for uden at svække systemets generelle sikkerhedsstilling. Nu da vi har rettet det, lad os få en anden gå på det:

Nu hvor scriptet er korrekt udført, kan vi se, hvad det egentlig gør. Det giver os besked om, at vi kører scriptet som en begrænset bruger. Scriptet kører i virkeligheden af ​​en konto med administratorrettigheder, men brugerkontokontrol er i vejen. Selvom detaljer om, hvordan scriptet kontrollerer Administratoradgang, er uden for denne artikels anvendelsesområde, her er koden, der bruges til demonstration:

hvis( ([Security. Principal. WindowsPrincipal] [Security. Principal. WindowsIdentity]: : GetCurrent)). IsInRole( [Security. Principal. WindowsBuiltInRole] "Administrator")){ Skriv-Output 'Kører som administrator!'} Ellers{ Skriv-Output 'Running Limited!'} Pause

Du vil også bemærke, at der nu er to"Pause" -operationer i script-output - en fra PowerShell-scriptet og en fra batchfilen.Årsagen til dette bliver mere tydelig i næste trin.

Trin 3: Få administratoradgang.

Hvis dit script ikke kører kommandoer, der kræver højde, og du er helt sikker på, at du ikke behøver at bekymre dig om, at andres tilpassede profiler kommer i vejen, kan du springe resten af ​​dette. Hvis du kører nogle cmdlets på Administrator-niveau, skal du bruge dette stykke.

Desværre er der ingen måde at udløse UAC til højde fra en batchfil eller CMD-session. Men PowerShell gør det muligt for os at gøre dette med Start-Process. Når det bruges med "-Verb RunAs" i sine argumenter, vil Start-Process forsøge at starte et program med administratorrettigheder. Hvis PowerShell-sessionen ikke allerede er forhøjet, vil dette udløse en UAC-prompt. For at bruge dette fra batchfilen til at starte vores script, vil vi ende med at gyde to PowerShell-processer - en til at slukke for Start-Process og en anden, startet af Start-Process, for at køre scriptet. Den anden linje i batchfilen skal ændres til dette:

PowerShell.exe -Command "&{ Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy Bypass -File" "% ~ dpn0.ps1" "' -VerbRunAs} "

Når batchfilen køres, er den første linie af output, vi ser, fra PowerShell profil scriptet. Derefter vil der være en UAC prompt, når Start-Process forsøger at starte MyScript.ps1.

Når du har klikket på UAC-prompten, vil en ny PowerShell-instans gyde. Fordi dette er en ny forekomst, vil vi selvfølgelig igen se profilskriftsmeddelelsen. Derefter kører MyScript.ps1, og vi ser, at vi faktisk er i en forhøjet session.

Og der er grunden til, at vi også har to pauser herinde. Hvis ikke for den i PowerShell-scriptet, ville vi aldrig se scriptets output - vinduet PowerShell ville bare komme op og forsvinde, så snart scriptet er færdig med at køre. Og uden pause i batchfilen kunne vi ikke se, om der var fejl, der startede PowerShell i første omgang.

Trin 4: Kom godt i gang med brugerdefinerede PowerShell-profiler.

Lad os slippe af med den ubehagelige brugerdefinerede profilbesked nu, skal vi? Her er det næppe endda en gener, men hvis en brugers PowerShell-profil ændrer standardindstillinger, variabler eller funktioner på måder, du måske ikke har forventet med dit script, kan de være meget besværlige. Det er meget enklere at køre dit script uden profilen helt, så du behøver ikke bekymre dig om dette. For at gøre det behøver vi bare at ændre den anden linje i batchfilen en gang til:

PowerShell.exe -NoProfile -Command "&{ Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File" "% ~ dpn0.ps1 "" '-Verb RunAs} "

Tilføjelse af -NoProfil-parameteren til begge forekomster af PowerShell, der lanceres af scriptet, betyder, at brugerens profil script vil blive fuldstændigt omgået i begge trin, og vores PowerShell script kører iet ret forudsigeligt, standardmiljø.Her kan du se, at der ikke er nogen brugerdefineret profilmeddelelse i nogen af ​​de skødede skaller.

Hvis du ikke har brug for administratorrettigheder i dit PowerShell-script, og du har hoppet over trin 3, kan du undvære den anden PowerShell-forekomst, og den anden linje i din batchfil skal se sådan ud:

PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '%% dpn0.ps1'"

Udgangen vil så se ud som denne:

( Selvfølgelig kan du for ikke-administrator scripts gøre det uden en pause i scriptet i PowerShell scriptetpå dette tidspunkt også alt siden er fanget i samme konsolvindue og ville blive holdt der ved pause i slutningen af ​​batchfilen alligevel.)

Afsluttede batchfiler.

Afhængigt af om du har brug for administratorrettigheder til dit PowerShell-script eller ej, og du ikke bør anmode om dem, hvis du ikke gør det, skal den endelige batchfil ligne en af ​​de to nedenfor.

Uden admin adgang:

@ECHO OFF PowerShell.exe -NoProfile -ExecutionPolicy Bypass-Kommando "& '% ~ dpn0.ps1'" PAUSE

Med Admin adgang:

@ECHO OFF PowerShell.exe -NoProfile -Command "&{Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""% ~ dpn0.ps1 ""'Verb RunAs} "PAUSE

Husk at sætte batchfilen i samme mappe som det PowerShell script, du vil haveat bruge det til og give det samme navn. Så uanset hvilket system du tager disse filer til, kan du køre dit PowerShell-script uden at skulle kaste dig rundt med nogen af ​​sikkerhedsindstillingerne på systemet. Du kan helt sikkert gøre disse ændringer manuelt hver gang, men det sparer dig for problemer, og du behøver ikke bekymre dig om at vende tilbage senere.

Referencer:

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