Kako uporabiti paketno datoteko za lažje izvajanje skriptov PowerShell

Iz več razlogov, večinoma povezanih z varnostjo, skripti PowerShell niso tako preprosto prenosljivi in ​​uporabni, kot so lahko skripti za paket. Vendar pa lahko paketne skripte s skripti PowerShell združimo, da bi odpravili te težave. Tukaj vam bomo pokazali nekaj teh problematičnih področij in kako zgraditi paketni skript, ki jih želite zaobiti.

Zakaj ne morem preprosto kopirati datoteke .PS1 v drug računalnik in jo zagnati?

Razen če ciljni sistem ni bil predhodno konfiguriran, da bi omogočal izvajanje poljubnih skriptov, z zahtevanimi privilegiji in s pravimi nastavitvami, obstaja možnost, da boste pri poskusu tega naleteli na težave..

1. PowerShell privzeto ni povezan s pripono datoteke .PS1.
   To smo najprej predstavili v seriji PowerShell Geek School. Windows po privzetku povezuje datoteke .PS1 z Notepadom, namesto da jih pošilja v ukazni tolmač PowerShell. S tem preprečite nenamerno izvajanje zlonamernih skriptov, tako da jih preprosto dvakrat kliknete. Obstajajo načini, kako lahko spremenite to vedenje, vendar to verjetno ni nekaj, kar bi radi naredili na vsakem računalniku, na katerem nosite svoje skripte - še posebej, če nekateri od teh računalnikov niso vaši.
2. PowerShell privzeto ne dovoljuje zunanje izvedbe skriptov.
   Nastavitev programa ExecutionPolicy v PowerShell onemogoči izvajanje zunanjih skriptov v vseh različicah sistema Windows. V nekaterih različicah operacijskega sistema Windows privzeto sploh ne dovoljuje izvajanja skriptov. Pokazali smo vam, kako spremeniti to nastavitev v poglavju Kako omogočiti izvajanje scenarijev PowerShell v operacijskem sistemu Windows 7. Vendar pa je to tudi nekaj, kar ne želite storiti na katerem koli računalniku.
3. Nekateri skripti PowerShell ne bodo delovali brez dovoljenj skrbnika.
   Tudi če uporabljate račun skrbnika na ravni skrbnika, morate še vedno opraviti nadzor uporabniškega računa (UAC) za izvajanje določenih dejanj. Tega ne želimo onemogočiti, vendar je še vedno lepo, ko se lahko nekoliko lažje ukvarjamo.
4. Nekateri uporabniki imajo morda prilagojena okolja PowerShell.
   Verjetno ne boste pogosto naleteli na to, toda ko to storite, lahko teče in odpravljanje težav skripte nekoliko otežijo. Na srečo se lahko okrog tega lotimo, ne da bi pri tem tudi trajno spremenili.

1. korak: Dvokliknite za zagon.

Začnimo z obravnavanjem prvega problema - združevanja datotek .PS1. Ne morete dvokliknite, da zaženete datoteke .PS1, vendar lahko tako izvedete datoteko .BAT. Torej bomo napisali paketno datoteko, da pokličemo skript PowerShell iz ukazne vrstice za nas.

Torej ni treba ponovno pisati paketne datoteke za vsak skript ali vsakič, ko premaknemo skript okoli njega, bo uporabil spremenljivko, ki se bo sklicevala na samo-sklicevanje za izgradnjo poti datoteke za skript PowerShell. Če želite to opraviti, morate paketno datoteko postaviti v isto mapo kot skript PowerShell in imeti isto ime datoteke. Če se vaš skript PowerShell imenuje »MyScript.ps1«, boste želeli poimenovati paketno datoteko »MyScript.bat« in se prepričati, da je v isti mapi. Nato postavite te vrstice v paketni skript:

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

Če ne bi bilo drugih varnostnih omejitev, bi bilo vse to potrebno za zagon skripta PowerShell iz paketne datoteke. Pravzaprav sta prva in zadnja vrstica v glavnem samo stvar preference - to je druga vrstica, ki res opravlja delo. Tukaj je razčlenitev:

@ECHO OFF izklopi odziv ukazov. To samo ohranja druge ukaze, da se prikažejo na zaslonu, ko se zažene paketna datoteka. Ta vrstica je sama skrita z uporabo simbola at (@) pred njim.

PowerShell.exe -Upravljanje »&«% ~ dpn0.ps1 « dejansko zažene skript PowerShell. PowerShell.exe je seveda mogoče poklicati iz katerega koli CMD okna ali paketne datoteke, da zaženete PowerShell na golo konzolo kot običajno. Uporabite ga lahko tudi za izvajanje ukazov neposredno iz paketne datoteke, tako da vključite parameter -Command in ustrezne argumente. Način, s katerim se ciljamo na našo datoteko .PS1, je s posebno spremenljivko% ~ dpn0. Zaženi iz paketne datoteke,% ~ dpn0 oceni črko pogona, pot mape in ime datoteke (brez pripone) paketne datoteke. Ker batch in PowerShell skript bosta v isti mapi in imata isto ime, se% ~ dpn0.ps1 prevede na celotno pot datoteke PowerShell.

PAVZA samo začasno ustavi izvajanje paketa in počaka na uporabniški vnos. To je na splošno koristno, če imate na koncu vaših paketnih datotek, tako da imate možnost pregledati izpis vseh ukazov, preden okno izgine. Ko bomo preverjali vsak korak, bo uporabnost tega postala bolj očitna.

Osnovna paketna datoteka je tako nastavljena. Za predstavitvene namene se ta datoteka shrani kot »D: Skriptni laboratorij MyScript.bat« in v isti mapi je »MyScript.ps1«. Poglejmo, kaj se zgodi, ko dvokliknemo MyScript.bat.

Očitno scenarij PowerShell ni zagnal, vendar je to pričakovano - navsezadnje smo se lotili samo prvih štirih težav. Vendar pa je tukaj prikazanih nekaj pomembnih bitov:

1. Naslov okna kaže, da je paketni skript uspešno zagnal PowerShell.
2. Prva vrstica izpisa kaže, da je uporabljen prilagojeni profil PowerShell. To je potencialna težava št. 4, ki je navedena zgoraj.
3. Sporočilo o napaki prikazuje omejitve ExecutionPolicy. To je naš problem # 2.
4. Podčrtan del sporočila o napaki (ki ga je prvotno naredil izhod napake PowerShell) kaže, da je paketni skript pravilno ciljal predvideni skript PowerShell (D: Skriptni laboratorij MyScript.ps1). Torej vsaj vemo, da veliko dela pravilno.

Profil je v tem primeru preprost enostranski skript, ki se uporablja za ta prikaz, da ustvari izhod, ko je profil aktiven. Svoj profil PowerShell lahko prilagodite tudi, če želite sami preskusiti te skripte. V svojo skripto profila preprosto dodajte naslednjo vrstico:

Napiši-Output "Custom PowerShell profil v veljavi!"

Tukaj je ExecutionPolicy na testnem sistemu nastavljena na RemoteSigned. To omogoča izvajanje lokalno izdelanih skriptov (kot je skript profila), medtem ko blokirajo skripte od zunanjih virov, razen če jih podpiše zaupni organ. Za predstavitvene namene je bil za označevanje MyScript.ps1 kot zunanjega vira uporabljen naslednji ukaz:

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

S tem nastavite nadomestni tok podatkov Zone.Identifier na MyScript.ps1, tako da bo Windows menil, da je datoteka prišla z interneta. Lahko se preprosto obrne z naslednjim ukazom:

Clear-Content -Path 'D: Skriptni laboratorij MyScript.ps1' -Stream 'Zone.Identifier'

2. korak: Pridobivanje politike ExecutionPolicy.

Pridobivanje nastavitev ExecutionPolicy, iz CMD ali paketnega skripta, je pravzaprav precej enostavno. Druga vrstica skripta spreminjamo tako, da dodamo še en parameter v ukaz PowerShell.exe.

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

Parameter -ExecutionPolicy lahko uporabite za spreminjanje ExecutionPolicy, ki se uporablja, ko ustvarite novo sejo PowerShell. To ne bo trajalo več kot ta seja, tako da lahko PowerShell, kot je ta, zaženemo kadarkoli bomo potrebovali, ne da bi oslabili splošno varnostno držo sistema. Zdaj, ko smo to popravili, dajmo še eno:

Zdaj, ko je skript pravilno izveden, lahko vidimo, kaj dejansko počne. Obveščamo vas, da skript uporabljamo kot uporabnik z omejenim dostopom. Skripta dejansko upravlja račun z dovoljenji skrbnika, vendar nadzor nad uporabniškimi računi ovira. Čeprav podrobnosti o tem, kako skript preverja dostop skrbnika, presegajo področje uporabe tega članka, je tukaj koda, ki se uporablja za predstavitev:

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) Write-Output 'Running as Administrator!' else Write-Output (Izhod za zapisovanje) 'Running Limited!

Opazili boste tudi, da sta v izhodnem skriptu zdaj dve operaciji »Premor« - ena iz skripta PowerShell in ena iz paketne datoteke. Razlog za to bo bolj očiten v naslednjem koraku.

3. korak: Pridobite skrbniški dostop.

Če vaš skript ne izvaja nobenih ukazov, ki zahtevajo višino, in ste prepričani, da vam ne bo treba skrbeti, da bi vam lahko preprečili uporabniške profile, lahko preskočite preostanek tega. Če uporabljate cmdlet na ravni skrbnika, boste potrebovali ta kos.

Na žalost ne moremo sprožiti UAC za dvigovanje znotraj paketne datoteke ali CMD seje. Vendar nam PowerShell to omogoča s programom Start-Process. Ko bo uporabljen z “-Verb RunAs” v svojih argumentih, bo Start-Process poskusil zagnati aplikacijo z dovoljenji skrbnika. Če seja PowerShell še ni povišana, bo to sprožilo ukaz UAC. Če želite uporabiti to iz paketne datoteke za zagon našega skripta, bomo na koncu ustvarili dva procesa PowerShell - enega za zagon Start-Process in drugega, ki ga zažene Start-Process, za zagon skripta. Drugo vrstico paketne datoteke je treba spremeniti v to:

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

Ko je paketna datoteka zagnana, je prva vrstica rezultatov, ki jo bomo videli, iz skripta profila PowerShell. Potem bo prišlo do UAC ukaza, ko Start-Process poskuša zagnati MyScript.ps1.

Ko kliknete ukaz UAC, se bo pojavil nov primerek PowerShell. Ker je to nov primer, bomo seveda spet videli obvestilo o skriptu profila. Nato se MyScript.ps1 zažene in vidimo, da smo res na povišani seji.

In tu je razlog, da imamo tudi tukaj dve premori. Če ne za tisto v skriptu PowerShell, ne bi nikoli videli izpisa skripta - okno PowerShell bi se samo pojavilo in izginilo, ko bi se skript končal. In brez premora v paketni datoteki ne bomo mogli videti, ali je prišlo do napak pri zagonu PowerShell na prvem mestu..

4. korak: Prilagajanje profilov PowerShell po meri.

Zdaj se bomo znebili tistega neobičajnega obvestila o profilu, kajne? Tukaj to sploh ni neprijetno, če pa profil uporabnika PowerShell spremeni privzete nastavitve, spremenljivke ali funkcije na načine, ki jih morda niste predvideli s svojim scenarijem, so lahko res problematični. Bolj preprosto je, če skripta ne izvajate brez profila, zato vam ni treba skrbeti. Da bi to naredili, moramo samo še enkrat spremeniti drugo vrstico paketne datoteke:

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

Dodajanje parametra -NoProfile v obe primerki programa PowerShell, ki jih zažene skript, pomeni, da bo skript uporabnikovega profila popolnoma premostjen v obeh korakih in naš PowerShell skript se bo izvajal v precej predvidljivem, privzetem okolju. Tukaj lahko vidite, da v nobeni od lupin, ki so se pojavile, ni nobenega opozorila po meri.

Če v skriptu PowerShell ne potrebujete skrbniških pravic in ste preskočili 3. korak, lahko to storite brez drugega primerka PowerShell, druga vrstica paketne datoteke pa mora izgledati takole:

PowerShell.exe -NoProfil -IzvajanjePolitični obvod -Upravljanje "&"% ~ dpn0.ps1 ""

Izhod bo izgledal takole:

(Seveda, za ne-skrbniške skripte lahko to storite tudi brez prekinitve skripta v skriptu PowerShell na tej točki, ker je vse zajeto v istem oknu ukazne mize in bi se tam zadržalo s premorom na koncu paketno datoteko.)

Dokončane paketne datoteke.

Odvisno od tega, ali potrebujete skrbniška dovoljenja za vaš scenarij PowerShell (in jih res ne bi smeli zahtevati, če tega ne storite), mora končna paketna datoteka izgledati kot ena od dveh spodaj.

Brez skrbniškega dostopa:

@ECHO OFF PowerShell.exe -NoProfil -IzvajanjePolitični obhod -Upravljanje "&"% ~ dpn0.ps1 "PAUSE

S skrbniškim dostopom:

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

Ne pozabite paketne datoteke namestiti v isto mapo kot skript PowerShell, za katerega ga želite uporabiti, in mu dati isto ime. Potem, ne glede na to, v kateri sistem boste vzeli te datoteke, boste lahko zagnali svoj scenarij PowerShell, ne da bi morali uporabiti varnostne nastavitve v sistemu. Vsekakor lahko vsakič ročno izvedete te spremembe, vendar vam to prihrani te težave in vam ne bo treba skrbeti, da bodo spremembe kasneje spremenjene..

---

Reference:

• Zagon skriptov PowerShell iz paketne datoteke - Blog programerja Daniela Schroederja
• Preverjanje skrbniških dovoljenj v PowerShell - Hej, Scripting Guy! Blog