Kaip naudoti paketinį failą, kad „PowerShell“ scenarijai būtų lengviau paleisti

Dėl kelių priežasčių, daugiausia susijusių su saugumu, „PowerShell“ scenarijai yra ne taip lengvai nešiojami ir tinkami naudoti kaip partijos scenarijai. Tačiau mes galime susieti partijos scenarijų su mūsų „PowerShell“ scenarijais, kad galėtume išspręsti šias problemas. Čia parodysime kelias iš šių probleminių sričių ir apie tai, kaip sukurti partijos scenarijų, kad galėtumėte juos supažindinti.

Kodėl negaliu tiesiog nukopijuoti .PS1 failo į kitą kompiuterį ir paleisti jį?

Jei tikslinė sistema nebuvo iš anksto sukonfigūruota leisti naudoti savavališkus scenarijus su reikiamomis privilegijomis ir naudojant tinkamus nustatymus, galite pabandyti įveikti kai kurias problemas, kai bandysite tai padaryti.

1. „PowerShell“ pagal nutylėjimą nėra susieta su .PS1 failo plėtiniu.
   Tai iš pradžių pristatėme mūsų PowerShell Geek mokyklos serijoje. Windows susieja .PS1 failus su Notepad pagal nutylėjimą, o ne siunčia juos į „PowerShell“ komandų interpretatorių. Taip siekiama užkirsti kelią atsitiktiniam kenksmingų scenarijų vykdymui, tiesiog dukart spustelėjus juos. Yra būdų, kaip keisti šį elgesį, tačiau tikriausiai tai nėra kažkas, ką norite daryti kiekviename kompiuteryje, kuriame yra skriptai, ypač jei kai kurie iš šių kompiuterių nėra jūsų.
2. „PowerShell“ neleidžia numatyti išorinio scenarijų vykdymo.
   „PowerShell“ nustatymas „ExecutionPolicy“ neleidžia pagal nutylėjimą atlikti išorinius scenarijus visose „Windows“ versijose. Kai kuriose „Windows“ versijose numatytasis neleidžia scenarijų vykdyti. Mes parodėme, kaip pakeisti šį nustatymą „Kaip leisti„ PowerShell “scenarijų vykdymą„ Windows 7 “sistemoje. Tačiau tai taip pat nenorite daryti bet kuriame kompiuteryje.
3. Kai kurie „PowerShell“ scenarijai neveiks be administratoriaus leidimų.
   Netgi dirbant su administratoriaus lygio paskyra, vis tiek turite atlikti vartotojo abonemento valdymą (UAC), kad atliktumėte tam tikrus veiksmus. Nenorime to išjungti, bet tai vis dar malonu, kai galime padaryti ją šiek tiek lengviau spręsti.
4. Kai kurie vartotojai gali pritaikyti „PowerShell“ aplinkas.
   Jūs tikriausiai negalėsite į tai dažnai patekti, bet kai tai padarysite, jūsų scenarijų paleidimas ir trikčių šalinimas gali šiek tiek varginantis. Laimei, mes galime tai padaryti be jokių nuolatinių pokyčių.

1 veiksmas: dukart spustelėkite norėdami paleisti.

Pradėkime sprendžiant pirmą problemą - .PS1 failų asociacijas. Negalite dukart spustelėti, kad paleistumėte .PS1 failus, tačiau galite atlikti .BAT failą. Taigi, mes parašysime paketinį failą, kad galėtume paskambinti PowerShell scenarijumi iš komandų eilutės.

Taigi nereikia perrašyti partijos failo kiekvienam scenarijui, arba kiekvieną kartą, kai perkeliame scenarijų, jis naudos savarankišką kintamąjį, kad sukurtų „PowerShell“ scenarijaus failo kelią. Kad šis darbas būtų atliktas, paketinis failas turės būti įdėtas į tą patį aplanką kaip ir „PowerShell“ scenarijus ir turėti tą patį failo pavadinimą. Taigi, jei jūsų „PowerShell“ scenarijus vadinamas „MyScript.ps1“, norėsite pavadinti partijos failą „MyScript.bat“ ir įsitikinti, kad jis yra toje pačioje aplanke. Tada įdėkite šias eilutes į partijos scenarijų:

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

Jei nebūtų taikomi kiti saugumo apribojimai, tai tikrai reikštų, kad „PowerShell“ scenarijus būtų paleistas iš paketinio failo. Tiesą sakant, pirmosios ir paskutinės eilutės yra tik pirmenybės klausimas - tai antroji eilutė, kuri tikrai daro darbą. Štai suskirstymas:

@ECHO OFF išjungia komandos atkartojimą. Tai tik padeda kitoms komandoms rodyti ekrane, kai vyksta paketinis failas. Ši linija yra paslėpta naudojant simbolį prie (@) prieš jį.

„PowerShell.exe“ komanda „& '% ~ dpn0.ps1“ iš tikrųjų veikia „PowerShell“ scenarijus. Žinoma, „PowerShell.exe“ gali būti iškviestas iš bet kokio CMD lango arba paketinio failo, kad paleistumėte „PowerShell“ į tuščią konsolę, kaip įprasta. Taip pat galite naudoti ją paleisti komandas tiesiai iš paketinio failo, įtraukdami -Command parametrą ir atitinkamus argumentus. Tai, kaip tai naudojama nukreipti mūsų .PS1 failą, yra specialus kintamasis% ~ dpn0. Paleiskite iš partijos failo,% ~ dpn0 įvertina disko raidę, aplanko kelią ir failo pavadinimą (be plėtinio). Kadangi partijos failas ir „PowerShell“ scenarijus bus tame pačiame aplanke ir turi tą patį pavadinimą,% ~ dpn0.ps1 bus išverstas į visą „PowerShell“ scenarijaus failo kelią.

PAUZĖ tiesiog sustabdo partijos vykdymą ir laukia vartotojo įvesties. Tai paprastai yra naudinga partijos rinkmenų pabaigoje, kad galėtumėte peržiūrėti bet kurią komandų išvestį prieš tai, kai langas dingsta. Bandydami atlikti kiekvieną žingsnį, jo naudingumas taps akivaizdesnis.

Taigi yra nustatytas pagrindinis paketinis failas. Demonstravimo tikslais šis failas įrašomas kaip „D: scenarijų laboratorija MyScript.bat“ ir tame pačiame aplanke yra „MyScript.ps1“. Pažiūrėkime, kas atsitiks, kai du kartus spustelėsime „MyScript.bat“.

Akivaizdu, kad „PowerShell“ scenarijus neveikė, bet tikėtina, kad galiausiai tik kalbėjome apie pirmąją iš mūsų keturių problemų. Tačiau čia yra keletas svarbių bitų:

1. Lango pavadinimas rodo, kad partijos scenarijus sėkmingai pradėjo „PowerShell“.
2. Pirmoji išėjimo eilutė rodo, kad naudojamas individualus „PowerShell“ profilis. Tai potenciali problema Nr. 4, nurodyta pirmiau.
3. Klaidos pranešimas rodo galiojančius vykdymo apribojimus. Tai mūsų problema # 2.
4. Pabrėžta klaidos pranešimo dalis (kuri padaryta natūraliai naudojant „PowerShell“ klaidos išvestį) rodo, kad partijos scenarijus teisingai nukreiptas į numatomą „PowerShell“ scenarijų (D: scenarijų laboratorija MyScript.ps1). Taigi bent jau žinome, kad daug veikia tinkamai.

Šiuo atveju profilis yra paprastas vienos eilutės scenarijus, naudojamas šiam demonstravimui, kad generuotų išvestį, kai profilis yra aktyvus. Taip pat galite pritaikyti savo „PowerShell“ profilį, jei norite patys išbandyti šiuos scenarijus. Tiesiog pridėkite šią eilutę prie savo profilio scenarijaus:

Rašyti išvestį „Pritaikytas„ PowerShell “profilis!“

Bandymo sistemos ExecutionPolicy čia nustatoma kaip RemoteSigned. Tai leidžia atlikti vietoje sukurtus scenarijus (pvz., Profilio scenarijų), blokuodami skriptus iš išorinių šaltinių, nebent juos pasirašė patikima institucija. Demonstravimo tikslais „MyScript.ps1“ kaip išorinio šaltinio žymėjimas buvo naudojamas šioms komandoms:

„Add-Content -Path“ D: scenarijų laboratorija MyScript.ps1 '-Value “[ZoneTransfer]' nZoneId = 3" -Stream "Zone.Identifier"

Tai nustato „Zone.Identifier“ alternatyvų duomenų srautą „MyScript.ps1“, kad „Windows“ manytų, jog failas atėjo iš interneto. Jis gali būti lengvai pakeistas tokia komanda:

„Clear-Content -Path“ D: scenarijų laboratorija MyScript.ps1 '-Stream' Zone.Identifier '

2 žingsnis: Aplankykite vykdymąPolicy.

Išvykimas iš „ExecutionPolicy“ nustatymo iš CMD arba partijos scenarijaus iš tikrųjų yra gana paprasta. Mes tiesiog pakeisime antrą scenarijaus eilutę, kad į „PowerShell.exe“ komandą pridėtume dar vieną parametrą.

„PowerShell.exe“ - vykdymasPolicy apeiti-komanda “&„% ~ dpn0.ps1 '“

Parametrą -ExecutionPolicy galima keisti „ExecutionPolicy“, kuri naudojama, kai nerenkate naujos „PowerShell“ sesijos. Tai nebus tęsiama po tos sesijos, kad galėtume paleisti „PowerShell“ tokį, kai mums reikia, nesumažinus bendros sistemos saugumo padėties. Dabar, kad mes nustatėme, kad galime turėti kitą eiti į jį:

Dabar, kai scenarijus tinkamai įvykdytas, matome, ką jis iš tikrųjų daro. Tai leidžia mums žinoti, kad scenarijus veikia kaip ribotas vartotojas. Scenariją faktiškai tvarko paskyra, kurioje yra administratoriaus teisės, tačiau vartotojo abonemento kontrolė pradeda veikti. Nors informacija apie tai, kaip scenarijus tikrina administratoriaus prieigą, nepatenka į šio straipsnio taikymo sritį, čia yra kodas, kuris naudojamas demonstravimui:

jei (([Security.Principal.WindowsPrincipal]] [Security.Principal.WindowsIdentity] :: GetCurrent ()) IsInRole ([Security.Principal.WindowsBuiltInRole] "Administratorius")) Rašyti išvestį "Veikia kaip administratorius!" Rašyti išvestį „Veikia ribotas!“ Pauzė

Taip pat pastebėsite, kad scenarijų išvestyje yra dvi „Pauzės“ operacijos - viena iš „PowerShell“ scenarijų ir viena iš partijos failo. To priežastis bus aiškesnė kitame etape.

3 veiksmas: administratoriaus prieigos gavimas.

Jei jūsų scenarijus neveikia jokių komandų, kurioms reikalingas aukštis, ir jūs esate tikri, kad jums nereikės nerimauti dėl to, kad kas nors pritaikys savo profilius, galite praleisti likusią dalį. Jei naudojate kai kuriuos administratoriaus lygio cmdlet'us, jums reikės šio kūrinio.

Deja, nėra galimybės paleisti UAC aukštyje iš partijos ar CMD sesijos. Tačiau „PowerShell“ leidžia mums tai padaryti su „Start-Process“. Naudojant su „-Verb RunAs“ savo argumentuose, „Start-Process“ bandys paleisti programą su administratoriaus leidimais. Jei „PowerShell“ sesija dar nėra padidinta, tai sukels UAC užklausą. Jei norite naudoti šią informaciją iš partijos failo, kad paleistumėte mūsų scenarijų, mes baigsime du „PowerShell“ procesus - vieną išjungti „Start-Process“, kitą - „Start-Process“, kad paleistumėte scenarijų. Antroji partijos failo eilutė turi būti pakeista:

„PowerShell.exe“ komanda „& Start-Process PowerShell.exe -Argumentų sąrašas -ExecutionPolicy Bypass -Failas“ "% ~ dpn0.ps1" "" -Verb RunAs "

Paleidus partijos failą, pirmoji išėjimo linija, kurią matysime, yra iš „PowerShell“ profilio scenarijaus. Tada bus UAC eilutė, kai „Start-Process“ bandys paleisti „MyScript.ps1“.

Paspaudus UAC spartą, atsiras naujas „PowerShell“ pavyzdys. Kadangi tai naujas atvejis, žinoma, vėl matysime pranešimą apie profilio scenarijų. Tada „MyScript.ps1“ veikia ir matome, kad iš tiesų esame aukštesnėje sesijoje.

Ir čia yra ir dvi pauzės. Jei ne „PowerShell“ scenarijaus atveju, mes niekada nematysime scenarijaus išvesties - „PowerShell“ langas tiesiog iškyla ir išnyks, kai tik bus atliktas scenarijus. Be partijos failo pauzės negalėtume matyti, ar buvo klaidų, pradedant „PowerShell“..

4 žingsnis. Aplankykite pasirinktinius „PowerShell“ profilius.

Leiskite atsikratyti šio bjauraus pasirinktinio profilio pranešimo dabar, ar mes? Čia vargu ar gali būti nepatogumų, bet jei vartotojo „PowerShell“ profilyje keičiami numatytieji nustatymai, kintamieji arba funkcijos, kurių jūs neturėjote numatyti savo scenarijuje, jie gali būti labai varginantys. Tai yra daug lengviau paleisti scenarijų be profilio, todėl jums nereikės jaudintis. Norėdami tai padaryti, dar kartą reikia pakeisti antrą eilutės failo eilutę:

„PowerShell.exe -NoProfile-Komanda“ & Pradėti procesą „PowerShell.exe -Argumentų sąrašas“ -NoProfilis -ĮvykdymasPolicy Bypass -Failas “"% ~ dpn0.ps1 "" -Verb RunAs "

Įrašant -NoProfile parametrą į abu „PowerShell“ atvejus, kuriuos paleis scenarijus, abu veiksmai bus visiškai apeiti vartotojo profilio scenarijų, o mūsų „PowerShell“ scenarijus bus rodomas gana nuspėjamoje numatytojoje aplinkoje. Čia galite matyti, kad nėra nė vieno priskirto profilio pranešimo nė vienoje iš sugautų lukštų.

Jei jums nereikia administratoriaus teisių „PowerShell“ scenarijuje ir praleidote 3 veiksmą, galite tai padaryti be antrojo „PowerShell“ pavyzdžio ir antroji eilutės failo eilutė turėtų atrodyti taip:

„PowerShell.exe“ -NoProfilis -ĮvykdymasPolicy Bypass -Command “ir„% ~ dpn0.ps1 “

Išvestis tada atrodys taip:

(Be abejo, nesant administratoriaus scenarijų, galėtumėte tai padaryti be „PowerShell“ scenarijaus pertraukos, nes viskas užfiksuota tame pačiame konsolės lange ir bus laikoma toje pačioje pertraukoje. bet kuriuo atveju.)

Baigtos partijos failai.

Priklausomai nuo to, ar jums reikia „PowerShell“ scenarijaus administratoriaus teisių (ir jūs neturėtumėte jų paprašyti, jei to nepadarysite), galutinis paketo failas turėtų atrodyti kaip vienas iš toliau pateiktų.

Be prieigos prie administratoriaus:

@ECHO OFF PowerShell.exe -NoProfilis -ĮvykdymasPolicy Bypass-Komanda "& '% ~ dpn0.ps1'" PAUSE

Su administratoriaus prieiga:

@ECHO OFF PowerShell.exe -NoProfile-Komanda "& Pradėti procesą PowerShell.exe -Argumentų sąrašas -NoProfilis -ĮvykdymasPolicy Bypass -Failas" "% ~ dpn0.ps1" "" -Verb RunAs "PAUSE

Nepamirškite įdėti partijos failą tame pačiame aplanke, kuriame norite naudoti „PowerShell“ scenarijų, ir suteikti jam tą patį pavadinimą. Tada, nepriklausomai nuo to, kokią sistemą naudojate tuose failuose, galėsite paleisti „PowerShell“ scenarijų, nesukeldami jokio sistemos saugumo nustatymo. Jūs tikrai galite atlikti šiuos pakeitimus rankiniu būdu kiekvieną kartą, bet tai taupo jums tokias problemas ir jums nereikės nerimauti dėl pakeitimų pakeitimo vėliau.

Nuorodos:

• „PowerShell“ scenarijų paleidimas iš rinkmenų - Daniel Schroeder programavimo dienoraštis
• Administratoriaus leidimų tikrinimas „PowerShell“ - Hey, Scripting Guy! Dienoraštis