Kā izmantot partijas failu, lai padarītu PowerShell skriptus vieglāk palaist

Vairāku iemeslu dēļ, kas galvenokārt saistīti ar drošību, PowerShell skripti nav tik vienkārši pārnēsājami un izmantojami kā partijas skripti. Tomēr mēs varam sasaistīt partijas skriptu ar mūsu PowerShell skriptiem, lai strādātu pie šiem jautājumiem. Šeit mēs parādīsim dažas no šīm problemātiskajām jomām un to, kā veidot partijas skriptu, lai tos apietu.

Kāpēc es nevaru vienkārši kopēt .PS1 failu uz citu datoru un palaist to?

Ja vien mērķa sistēma nav iepriekš konfigurēta, lai ļautu izmantot patvaļīgus skriptus ar nepieciešamajām privilēģijām un izmantojot pareizos iestatījumus, iespējams, ka jūs mēģināsiet rasties dažas problēmas, mēģinot to darīt.

1. PowerShell nav pievienots .PS1 faila paplašinājumam pēc noklusējuma.
   Mēs to sākotnēji parādījām mūsu PowerShell Geek skolas sērijā. Windows pēc noklusējuma piesaista .PS1 failus pie Notepad, nevis nosūta tos uz PowerShell komandu tulku. Tas ir, lai novērstu nejaušu ļaunprātīgu skriptu izpildi, vienkārši uzklikšķinot uz tiem. Ir veidi, kā jūs varat mainīt šo uzvedību, bet tas, iespējams, nav kaut kas, ko vēlaties darīt katrā datorā, kurā ir skripti, it īpaši, ja daži no šiem datoriem nav jūsu pašu.
2. PowerShell nepieļauj ārējo skriptu izpildi pēc noklusējuma.
   Iestatījums ExecutionPolicy programmā PowerShell novērš ārējo skriptu izpildi pēc noklusējuma visās Windows versijās. Dažās Windows versijās noklusējums neļauj vispār veikt skriptu izpildi. Mēs parādījām, kā mainīt šo iestatījumu sadaļā Kā atļaut PowerShell skriptu izpildi sistēmā Windows 7. Tomēr tas ir arī tas, ko nevēlaties darīt tikai ar jebkuru datoru.
3. Daži PowerShell skripti nedarbosies bez administratora atļaujas.
   Pat darbojoties ar administratora līmeņa kontu, jums joprojām ir jāiziet lietotāja konta kontrole (UAC), lai veiktu noteiktas darbības. Mēs to nevēlamies atspējot, bet tas joprojām ir jauki, ja varam to mazliet vieglāk risināt.
4. Dažiem lietotājiem var būt pielāgotas PowerShell vides.
   Iespējams, ka tas neradīsies bieži, bet, kad to izdarīsiet, skriptu palaišana un traucējummeklēšana ir nedaudz nomākta. Par laimi, mēs varam to apiet bez pastāvīgām izmaiņām.

1. darbība: veiciet dubultklikšķi, lai palaistu.

Sāksim ar pirmo problēmu - .PS1 failu asociācijām. Jūs nevarat divreiz noklikšķināt, lai palaistu .PS1 failus, bet jūs varat izpildīt .BAT failu. Tātad, mēs uzrakstīsim partijas failu, lai no mūsu komandrindas izsauktu PowerShell skriptu.

Tāpēc mums nav jāpārraksta partijas fails katram skriptam, vai ikreiz, kad pārvietojam skriptu, tas izmantos pašreferences mainīgo, lai izveidotu PowerShell skripta faila ceļu. Lai veiktu šo darbu, sērijveida fails būs jāievieto tajā pašā mapē kā jūsu PowerShell skripts, un tam ir jābūt vienādam faila nosaukumam. Tātad, ja jūsu PowerShell skripts tiek saukts par "MyScript.ps1", jūs vēlaties nosaukt savu partijas failu "MyScript.bat" un pārliecinieties, vai tas ir tajā pašā mapē. Pēc tam ievietojiet šīs rindas partijas skriptu:

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

Ja nebūtu citu drošības ierobežojumu, tas tiešām būtu viss, kas nepieciešams, lai palaistu PowerShell skriptu no partijas faila. Faktiski pirmās un pēdējās rindas galvenokārt ir tikai priekšroka - tā ir otrā līnija, kas patiešām veic darbu. Šeit ir sadalījums:

@ECHO OFF izslēdz komandu atbalss. Tas tikai pasargā jūsu citas komandas uz ekrāna, kad tiek veikts partijas fails. Šī līnija pati par sevi ir paslēpta, izmantojot simbolu at (@).

PowerShell.exe -Command “& '% ~ dpn0.ps1'” faktiski vada PowerShell skriptu. PowerShell.exe, protams, var tikt izsaukts no jebkura CMD loga vai partijas faila, lai palaistu PowerShell uz tukšo konsoli, kā parasti. Varat arī to izmantot, lai palaistu komandas tieši no partijas faila, iekļaujot parametru -Command un atbilstošus argumentus. Veids, kādā to izmanto, lai mērķētu mūsu .PS1 failu, ir ar īpašo% ~ dpn0 mainīgo. Palaist no partijas faila,% ~ dpn0 novērtē sērijveida diska burtu, mapes ceļu un faila nosaukumu (bez paplašinājuma). Tā kā sērijveida un PowerShell skripts būs vienā un tajā pašā mapē un tam ir tāds pats nosaukums,% ~ dpn0.ps1 pārtulkos uz pilnu PowerShell skripta faila ceļu..

PAUSE vienkārši aptur partijas izpildi un gaida lietotāja ievadi. Tas parasti ir noderīgi partiju failu beigās, lai jums būtu iespēja pārskatīt jebkuru komandu izeju, pirms logs pazūd. Tā kā mēs pārbaudām katru soli, tā lietderīgums kļūs skaidrāks.

Tātad, ir izveidots pamata sērijas fails. Demonstrācijas nolūkos šis fails tiek saglabāts kā “D: Skriptu laboratorija MyScript.bat” un tajā pašā mapē ir “MyScript.ps1”. Redzēsim, kas notiek, kad mēs veicam dubultklikšķi uz MyScript.bat.

Acīmredzot PowerShell skripts nedarbojās, bet tas ir sagaidāms - mēs galu galā esam pievērsušies tikai pirmajai no četrām problēmām. Tomēr šeit ir norādīti daži svarīgi punkti:

1. Loga nosaukums rāda, ka partijas skripts ir veiksmīgi palaists PowerShell.
2. Pirmā izvades līnija parāda, ka tiek izmantots pielāgots PowerShell profils. Šī ir iespējamā problēma # 4, kas uzskaitīta iepriekš.
3. Kļūdas ziņojums parāda spēkā esošos izpildes ierobežojumus. Tā ir mūsu problēma # 2.
4. Kļūdas ziņojuma pasvītrotā daļa (kas tiek veikta pēc PowerShell kļūdas izejas) parāda, ka partijas skripts bija pareizi mērķēts uz paredzēto PowerShell skriptu (D: Skripts Lab MyScript.ps1). Tāpēc mēs vismaz zinām, ka daudz strādā pareizi.

Šādā gadījumā profils ir vienkāršs vienas rindas skripts, ko izmanto šīs demonstrācijas veikšanai, lai ģenerētu izeju, kad profils ir aktīvs. Jūs varat arī pielāgot savu PowerShell profilu, lai to izdarītu arī tad, ja vēlaties paši pārbaudīt šos skriptus. Vienkārši pievienojiet šādu rindu savam profila skriptam:

Rakstīt-Output 'Custom PowerShell profils spēkā!'

Testa sistēmas ExecutionPolicy šeit ir iestatīts uz RemoteSigned. Tas ļauj izpildīt lokāli izveidotus skriptus (piemēram, profila skriptu), bloķējot skriptus no ārējiem avotiem, ja vien tos nav parakstījusi uzticama iestāde. Demonstrācijas nolūkos, lai atzīmētu MyScript.ps1 kā ārēja avota, tika izmantota šāda komanda:

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

Tas iestatīs Zone.Identifier alternatīvo datu plūsmu MyScript.ps1, lai Windows domātu, ka fails nāk no interneta. To var viegli mainīt ar šādu komandu:

Clear-Content -Path D: Skriptu laboratorija MyScript.ps1 '-Stream' Zone.Identifier '

2. solis: Pārvietošanās ExecutionPolicy.

Apmeklējot ExecutionPolicy iestatījumu no CMD vai partijas skripta, tiešām ir diezgan viegli. Mēs vienkārši pārveidojam skripta otro rindu, lai pievienotu vēl vienu parametru PowerShell.exe komandai.

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

-ExecutionPolicy parametrs var tikt izmantots, lai modificētu ExecutionPolicy, kas tiek izmantota, kad jūs veidojat jaunu PowerShell sesiju. Tas nebūs ilgāks par šo sesiju, tāpēc mēs varam palaist PowerShell līdzīgu, kad vien nepieciešams, nesamazinot sistēmas vispārējo drošības pozu. Tagad, kad mēs esam nostiprinājuši to, pieņemsim vēl vienu iet pie tā:

Tagad, kad skripts ir pareizi izpildīts, mēs varam redzēt, ko tas faktiski dara. Tas ļauj mums zināt, ka skripts darbojas kā ierobežots lietotājs. Skriptu patiešām vada konts, kurā ir administratora atļaujas, bet lietotāja konta kontrole sāk darboties. Lai gan informācija par to, kā skripts pārbauda administratora piekļuvi, ir ārpus šī panta darbības jomas, šeit ir kods, ko izmanto demonstrēšanai:

ja (([Security.Principal.WindowsPrincipal] [Drošība.Principal.WindowsIdentity] :: GetCurrent ()) IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrators")) Rakstīt-Output "Running kā administrators! Rakstīt izeja “Running Limited!

Jūs arī pamanīsiet, ka skripta izvadā tagad ir divas „Pauzes” operācijas - viena no PowerShell skripta un viena no partijas faila. Tā iemesls būs skaidrāks nākamajā solī.

3. solis: administratora piekļuves iegūšana.

Ja jūsu skripts nedarbina nevienu komandu, kas prasa paaugstinājumu, un jūs esat pārliecināts, ka jums nebūs jāuztraucas par to, ka kāds būs pielāgots profils, lai to varētu aizkavēt. Ja jums ir dažas administratora līmeņa cmdlets, jums būs nepieciešams šis gabals.

Diemžēl UAC nevar aktivizēt pacelšanai no sērijveida vai CMD sesijas. Tomēr PowerShell ļauj mums to darīt ar Start-Process. Lietojot ar “-Verb RunAs” savos argumentos, Start-Process mēģinās sākt lietotni ar administratora atļaujām. Ja PowerShell sesija vēl nav paaugstināta, tas aktivizēs UAC. Lai to izmantotu no partijas faila, lai palaistu mūsu skriptu, mēs galu galā nāksīsim divus PowerShell procesus - vienu, lai izslēgtu Start-Process un otru, ko uzsāka Start-Process, lai palaistu skriptu. Partijas faila otrā rinda ir jāmaina uz šo:

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

Kad sērijveida fails tiek palaists, pirmā izejas līnija, ko mēs redzēsim, ir no PowerShell profila skripta. Pēc tam, kad Start-Process mēģinās sākt MyScript.ps1, būs UAC uzvedne.

Pēc tam, kad noklikšķināsiet uz UAC uzvednes, tiks izveidots jauns PowerShell piemērs. Tā kā šis ir jauns gadījums, protams, mēs atkal redzēsim profila skripta paziņojumu. Tad MyScript.ps1 darbojas, un mēs redzam, ka mēs patiešām esam paaugstinātā sesijā.

Un tur ir arī iemesls, kāpēc mums ir divi pauzes. Ja ne par vienu no PowerShell skripta, mēs nekad neredzētu skripta izeju - PowerShell logs vienkārši parādīsies un pazudīs, tiklīdz skripts būs izpildīts. Un, ja nebūs pauze sērijveida failā, mēs nevarētu redzēt, vai ir kādas kļūdas, uzsākot PowerShell pirmajā vietā.

4. solis: iepazīšanās ar pielāgotiem PowerShell profiliem.

Atbrīvosimies no šī šķebinošā profila paziņojuma tagad, vai mēs? Lūk, tas ir gandrīz neērtības, bet, ja lietotāja PowerShell profils maina noklusējuma iestatījumus, mainīgos lielumus vai funkcijas tādā veidā, kā jūs, iespējams, neesat paredzējis ar savu skriptu, tie var būt patiešām apgrūtinoši. Ir daudz vienkāršāk skriptu palaist bez profila, lai jums par to nebūtu jāuztraucas. Lai to izdarītu, vēlreiz ir jāmaina partijas faila otrā rinda:

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

Parametra pievienošana -NoProfile abiem PowerShell gadījumiem, ko uzsāk skripts, nozīmē, ka lietotāja profila skripts tiks pilnībā apiets abos soļos, un mūsu PowerShell skripts darbosies diezgan paredzamā, noklusējuma vidē. Šeit jūs varat redzēt, ka nevienā no nārstotajiem čaulām nav paziņojuma par pielāgotu profilu.

Ja jums nav nepieciešamas administratora tiesības jūsu PowerShell skriptā, un esat izlaidis 3. soli, varat to darīt bez otrā PowerShell gadījuma, un partijas faila otrajai rindai vajadzētu izskatīties šādi:

PowerShell.exe -NoProfile-IzpildePolicy Bypass-Komanda "& '% ~ dpn0.ps1'"

Pēc tam izeja izskatīsies šādi:

(Protams, arī tad, ja skripti, kas nav administratori, varētu tikt veikti bez skripta pārtraukuma jūsu PowerShell skriptu šajā brīdī, jo viss ir notverts tajā pašā konsoles logā, un to tur turētu pauzes beigās. partijas failu.)

Pabeigti sērijveida faili.

Atkarībā no tā, vai jums ir nepieciešamas administratora atļaujas jūsu PowerShell skriptam (un jums nevajadzētu tos pieprasīt, ja jums tā nav), pēdējam partijas failam vajadzētu izskatīties kā vienam no tālāk minētajiem.

Bez Admin piekļuves:

@ECHO OFF PowerShell.exe -NoProfile -IzpildePolicy Bypass-Komanda "&"% ~ dpn0.ps1 "" PAUSE

Ar administratora piekļuvi:

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

Neaizmirstiet ievietot sērijveida failu tajā pašā mapē kā PowerShell skripts, kuru vēlaties izmantot, un piešķiriet tai tādu pašu nosaukumu. Tad neatkarīgi no tā, kādu sistēmu jūs lietojat, jūs varēsiet palaist savu PowerShell skriptu, neizmantojot nevienu sistēmas drošības iestatījumu. Jūs noteikti varat veikt šīs izmaiņas manuāli katru reizi, bet tas ietaupa jums šīs problēmas un jums nebūs jāuztraucas par izmaiņu atjaunošanu vēlāk.

---

Atsauces:

• PowerShell skriptu palaišana no partijas faila - Daniel Schroeder Programmēšanas emuārs
• Administratora atļauju pārbaude PowerShell - Hey, Scripting Guy! Blogs