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

Vairāku iemeslu dēļ, galvenokārt ar drošību saistīti, PowerShell skripti nav tik viegli pārnēsājami un lietojami, jo var būt partijas skripti. Tomēr mēs varam iesaiņot partijas skriptu, izmantojot mūsu PowerShell skriptus, lai risinātu šos jautājumus. Šeit mēs parādīsim dažas no šīm problēmu zonām un to, kā izveidot partijas skriptu, lai tos apietu.

Kāpēc es nevaru vienkārši kopēt savu .PS1 failu citam datoram un palaist to?

Ja vien mērķa sistēma nav iepriekš konfigurēta, lai ļautu patvaļīgiem skriptiem darboties ar nepieciešamajām privilēģijām un pareizo iestatījumu izmantošanu, iespējams, ka jūs mēģināt to izdarīt, rodas dažas problēmas.

1. Pēc noklusējuma PowerShell nav saistīts ar .PS1 faila paplašinājumu.
   Mēs to sākotnēji radījām PowerShell Geek skolu sērijās. Windows piesaista .PS1 failus Notepad pēc noklusējuma, nevis nosūta tos PowerShell komandu interpretatoram. Tas ir, lai novērstu nejaušu ļaunprātīgu skriptu izpildi, vienkārši dubultklikšķinot uz tiem. Ir veidi, kā jūs varat mainīt šo uzvedību, taču tas, iespējams, nav kaut kas, ko vēlaties darīt katrā datorā, uz kuru veicat savus skriptus, it īpaši, ja daži no šiem datoriem nav jūsu pašu.
2. PowerShell pēc noklusējuma neļauj ārējai skripta izpildei.
   PowerShell iestatījums ExecutionPolicy novērš ārējo skriptu izpildi pēc noklusējuma visās Windows versijās. Dažās Windows versijās noklusējums neļauj izpildīt skriptu vispār. Mēs parādījām, kā mainīt šo iestatījumu sadaļā Iespējot 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ļaujām.
   Pat darbojoties ar administratora līmeņa kontu, jums ir nepieciešams, lai veiktu noteiktas darbības, izmantojot lietotāja konta kontroli (UAC). Mēs nevēlamies to atspējot, bet tas joprojām ir jauki, ja mēs varam to nedaudz atvieglot.
4. Dažiem lietotājiem var būt pielāgota PowerShell vide.
   Jūs, iespējams, neradīsies šajā bieži, bet, kad jūs to darīsit, tas var darboties un jūsu skripti ir nedaudz satraucoši. Par laimi, mēs varam to apiet, neveicot nekādas pastāvīgas izmaiņas.

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

Sāksim ar pirmās problēmas risināšanu - .PS1 failu apvienības. Jūs nevarat dubultklikšķi, lai palaistu .PS1 failus, bet jūs to varat izpildīt .BAT failā. Tātad, mēs rakstīsim sērijveida failu, lai izsauktu PowerShell skriptu no mūsu komandrindas.

Tāpēc mums nav jāpārraksta katra skripta sērijveida fails, vai arī katru reizi, kad mēs virzīsim skriptu, tā izmantos pašreģistrējošo mainīgo, lai izveidotu PowerShell skripta faila ceļu. Lai veiktu šo darbu, sērijveida fails tiks ievietots tajā pašā mapē kā PowerShell skripts un tam ir vienāds faila nosaukums. Tātad, ja jūsu PowerShell skriptu sauc par "MyScript.ps1", jūs vēlaties nosaukt savu sērijveida failu "MyScript.bat" un pārliecināties, ka tas ir tajā pašā mapē. Tad ievietojiet šīs līnijas partijas skriptā:

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

Ja tas nenotiktu citiem drošības ierobežojumiem, tas tiešām būtu viss, kas vajadzīgs, lai palaistu PowerShell skriptu no sērijveida faila. Faktiski pirmā un pēdējā rindas galvenokārt ir tikai priekšrocības - tā ir otrā līnija, kas patiešām veic darbu. Lūk, iedalījums:

@ECHO OFF izslēdz komandu atbalsi. Tas tikai saglabā jūsu citas komandas rādīt ekrānā, kad sērijveida fails darbojas. Šī līnija tiek paslēpta, izmantojot simbolu (@) priekšā.

PowerShell.exe -Command "&"% ~ dpn0.ps1 "" faktiski palaiž PowerShell skriptu. Protams, PowerShell.exe var tikt izsaukts no jebkura CMD loga vai sērijveida faila, lai PowerShell palaistu kā parasti. Varat to arī izmantot, lai palaistu komandas tieši no sērijveida faila, iekļaujot -Command parametru un atbilstošos argumentus. Tas, kā to izmanto, lai mērķētu mūsu .PS1 failu, ir ar īpašu% ~ dpn0 mainīgo. Palaidiet no sērijveida faila% ~ dpn0 vērtē sērijveida faila diska burtu, mapes ceļu un faila nosaukumu (bez paplašinājuma). Tā kā sērijveida un PowerShell skripts būs vienā mapē un tiem ir viens nosaukums,% ~ dpn0.ps1 tiks tulkots uz PowerShell skripta pilnu faila ceļu.

PAUSE tikai pārtrauc partijas izpildi un gaida lietotāja ievadi. Tas parasti ir noderīgi, lai jūsu sērijveida faili būtu beigušies, lai jums būtu iespēja pārskatīt komandas izvadi pirms loga pazušanas. Kad mēs pārietu uz katra posma pārbaudi, šī lietderība kļūs acīmredzama.

Tātad, tiek iestatīts pamata sērijveida fails. Demonstrācijas nolūkos šis fails tiek saglabāts kā "D: \ Script Lab \ MyScript.bat" un tajā pašā mapē ir "MyScript.ps1". Apskatīsim, kas notiek, veicot dubultklikšķi uz MyScript.bat.

Acīmredzot PowerShell skripts nedarbojās, bet tas ir sagaidāms - galu galā mēs pievērsāmies tikai pirmajai no četrām problēmām. Tomēr šeit ir daži svarīgi biti:

1. Loga nosaukums rāda, ka partijas skripts ir veiksmīgi startējis PowerShell.
2. Pirmā izvades rinda rāda, ka tiek izmantots pielāgots PowerShell profils. Šī ir potenciālā problēma # 4, kas uzskaitīta iepriekš.
3. Kļūdas ziņojums parāda ExecutionPolicy ierobežojumus spēkā. Tā ir mūsu 2. problēma.
4. Apstiprinātā kļūdas ziņojuma daļa (kas tiek veikta, izmantojot PowerShell kļūdas izvadi) norāda, ka partijas skripts tika pareizi novirzīts uz paredzēto PowerShell skriptu (D: \ Script Lab \ MyScript.ps1). Tātad mēs vismaz zinām, ka daudz strādā pareizi.

Šajā gadījumā profils ir vienkāršs vienas rindas skripts, ko izmanto šajā demonstrācijā, lai ģenerētu produkciju ikreiz, kad profils ir aktīvs. Lai to paveiktu, varat arī pielāgot savu PowerShell profilu, ja vēlaties pats pārbaudīt šos skriptus. Savā profila skriptā vienkārši pievienojiet šādu rindu:

Rakstura izeja 'Pielāgots PowerShell profils!'

Izmēģinājuma sistēmas ExecutionPolicy šeit ir iestatīta kā RemoteSigned. Tas ļauj veikt lokāli izveidotus skriptus (piemēram, profila skriptu), bet bloķē skriptus no ārējiem avotiem, ja vien tos nav parakstījusi uzticama iestāde. Demonstrācijas nolūkā MyScript.ps1 tika izmantota šāda komanda: no ārēja avota:

Add-Content -Path 'D: \ Scenāriju laboratorija \ MyScript.ps1' -Vērtība '[ZoneTransfer]' nZoneId = 3 '-Stream' Zone.Identifier '

Tas nosaka Zone.Identifier rezerves 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: \ Script Lab \ MyScript.ps1' -Stream 'Zone.Identifier'

2. darbība: Apmācības izpildes politika.

Pārvietošanās ar ExecutionPolicy iestatījumu, sākot no CMD vai partijas skripta, patiesībā ir diezgan viegli. Mēs vienkārši modificējam skripta otro rindu, lai pievienotu vēl vienu parametru komandai PowerShell.exe.

PowerShell.exe -ExecutionPolicy apvedceļš -Command "& '% ~ dpn0.ps1'"

Parametru -ExecutionPolicy var izmantot, lai pārveidotu ExecutionPolicy, kas tiek izmantots, kad jūs ģenerējat jaunu PowerShell sesiju. Tas nenotiks ilgāk par šo sesiju, tādēļ mēs varēsim palaist PowerShell to, kad vien mums būs vajadzīgs, nepalielinot sistēmas vispārējo drošības stāvokli. Tagad, kad esam to izlabojuši, paliksim vēl vienu:

Tagad, kad skripts ir pareizi izpildīts, mēs varam redzēt, kas tas patiesībā ir. Tas informē mūs, ka mēs izmantojam skriptu kā ierobežotu lietotāju. Skriptu patiesībā pārvalda konts ar Administratora atļaujām, bet lietotāja konta kontrole notiek ceļā. Lai gan informācija par to, kā skripts pārbauda piekļuvi administratoram, neattiecas uz šo rakstu, šeit ir kods, ko izmanto demonstrēšanai:

ja (([Security.Principal.WindowsPrincipal]] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) (Write-Output "darbojas kā administrators! Write-Output 'Running Limited!' Pauze

Jūs arī pamanīsit, ka skripta izvadei tagad ir divas darbības "Pauze" - viena no PowerShell skripta un viena no sērijveida failiem. Šī iemesla dēļ būs skaidrāks nākošais solis.

3. darbība: piekļuve administratoram.

Ja jūsu skriptā netiek rādītas kādas komandas, kurām ir nepieciešama paaugstināšana, un jūs esat diezgan pārliecināts, ka jums nebūs jāuztraucas par to, kā kāds pielāgotos profilus nokļūst ceļā, jūs varat izlaist pārējo. Ja jūs izmantojat dažas administratora līmeņa cmdlet, jums tā būs nepieciešama.

Diemžēl nav iespējams aktivizēt UAC paaugstināšanos no sērijveida vai CMD sesijas. Tomēr PowerShell ļauj mums to izdarīt ar sākuma procesu. Izmantojot ar argumentiem "-Verb RunAs", Start-Process mēģinās palaist lietojumprogrammu ar administratora atļaujām. Ja PowerShell sesija vēl nav paaugstināta, tas aktivizēs UAC uzvedni. Lai to izmantotu sērijveida failā, lai palaistu mūsu skriptu, mēs beigsim nārstot divus PowerShell procesus - vienu, lai palaistu sākuma procesu, un otru, kuru palaiž Start-Process, lai palaistu skriptu. Sērijveida faila otrā rindiņa ir jāmaina uz šo:

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

Kad sērijveida fails tiek palaists, pirmā izvades rinda, ko mēs redzēsim, ir no PowerShell profila skripta. Pēc tam sākas UAC uzvedne, kad Start-Process mēģina palaist MyScript.ps1.

Pēc noklikšķināšanas, izmantojot UAC uzvedni, parādīsies jauns PowerShell piemērs. Tā kā tas ir jauns gadījums, protams, mēs atkal redzēsim profila skripta paziņojumu. Tad MyScript.ps1 palaiž, un mēs redzam, ka mēs patiešām ir paaugstināta sesija.

Un tur ir iemesls, ka mums šeit ir divas pauzes. Ja tas nav paredzēts PowerShell skriptā, mēs nekad neredzētu skripta izvadi - PowerShell logs tikko pop-up un pazūd, tiklīdz skripts tiek izpildīts. Un bez partijas faila pauzes mēs nevarētu redzēt, vai vispirms bija problēmas ar PowerShell palaišanu.

4. solis: Pielāgojiet pielāgotos PowerShell profilus.

Vai mēs tagad atbrīvosim šo viltīgo pielāgoto profila paziņojumu? Šeit gandrīz nav neērtības, taču, ja lietotāja PowerShell profils maina noklusējuma iestatījumus, mainīgos vai funkcijas, ko jūs, iespējams, neparedzējāt ar savu skriptu, tie var būt patiešām apgrūtinoši. Tas ir daudz vienkāršāk palaist jūsu skriptu bez profila pilnīgi, tāpēc jums nav jāuztraucas par to. Lai to izdarītu, mums vēlreiz jāmaina partijas faila otrā rindiņa:

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

Parametrs -NoProfile pievienošana abiem PowerShell gadījumiem, kurus palaiž skripts, nozīmē, ka abās pakāpēs lietotāja profila skripts tiks pilnībā apiets, un mūsu PowerShell skripts darbosies diezgan paredzamā noklusējuma vidē. Šeit varat redzēt, ka nevienā no radītajiem čaumaliem nav neviena pielāgota profila paziņojuma.

Ja PowerShell skriptā nav nepieciešamas administratora tiesības un esat izlaida 3. darbību, jūs varat iztikt bez otrā PowerShell instancē, un jūsu sērijveida faila otrajai rindai jābūt šādai:

PowerShell.exe -NoProfile -ExecutionPolicy apvedceļš -Command "& '% ~ dpn0.ps1'"

Izlaide būs šāda:

(Protams, ne-administratora skriptiem, šajā laikā varat arī bez PowerShell skripta beigt skripta pārtraukšanu, jo viss ir notverts tajā pašā konsoles logā un tur tur tur ar pagaidu beigām jebkurā gadījumā sērijveida.)

Pabeigtie partijas faili.

Atkarībā no tā, vai jums ir nepieciešamas administratora atļaujas jūsu PowerShell skriptam (un jūs patiešām to nevajadzētu pieprasīt, ja jums tas nav), pēdējam sērijveida failam vajadzētu būt vienam no abiem.

Bez administratora piekļuves:

@ECHO OFF PowerShell.exe -NoProfile -ExecutionPolicy bypass -Command "& '% ~ dpn0.ps1'" PAUZE

Ar administratora piekļuvi:

@ECHO OFF PowerShell.exe -NoProfile -Command "& Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy apvedceļa -File" "% ~ dpn0.ps1" "" -Verb RunAs "PAUZE

Atcerieties ievietot sērijveida failu tajā pašā mapē kā PowerShell skripts, kuru vēlaties to izmantot, un piešķiriet tam tādu pašu nosaukumu. Tad neatkarīgi no sistēmas, kurā izmantojat šos failus, jūs varēsiet palaist savu PowerShell skriptu, neizmantojot nevienu no sistēmas drošības iestatījumiem. Jūs noteikti varētu veikt šīs izmaiņas manuāli katru reizi, bet tas ietaupa jums šo nepatikšanu, un jums nebūs jāuztraucas par izmaiņu atjaunošanu vēlāk.

Atsauces:

• Darbojas PowerShell skripti no sērijveida faila - Daniela Šrīdera programmēšanas emuārs
• Pārbaude administratora atļaujām PowerShell - Hei, skriptu puisis! Emuārs