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 hjælp af de rigtige indstillinger, er det sandsynligt, at du vil løbe ind i nogle problemer, når du forsøger at gøre dette.

1. PowerShell er som ikke er knyttet til .PS1 filudvidelsen som standard. Vi har taget det 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 til - især hvis nogle af disse computere ikke er dine egne.
2. PowerShell tillader ikke ekstern scriptudførelse som standard. Indstillingen Execution Policy 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å en hvilken som helst computer.
3. Nogle PowerShell-scripts virker ikke uden Administrator tilladelser. Selvom du kører med en administrator-konto, skal du stadig gennemgå brugerkontrolkontrol (UAC) for at udføre bestemte handlinger. Vi ønsker ikke at deaktivere dette, men det er stadig godt, når vi kan gøre det lidt nemmere at håndtere.
4. Nogle brugere kan have tilpasset PowerShell-miljøer.
   Du vil sandsynligvis ikke komme ind på 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 foretage permanente ændringer.

Trin 1: Dobbeltklik for at køre.

Lad os begynde 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å skriver vi en batchfil for at kalde PowerShell-scriptet fra kommandolinjen til os.

Så vi behøver ikke at omskrive batchfilen for hvert script, eller hver gang vi flytter et script rundt, det vil gøre brug af en selvrefererende variabel 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. Derefter sæt 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 Det er virkelig alt, hvad der kræves for 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 nedbrydningen:

@ECHO OFF deaktiverer 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 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 stopper bare 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å er den grundlæggende batchfil konfigureret. 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 forventes - vi har jo først taget fat på det første af vores fire problemer. Der vises dog nogle vigtige punkter her:

1. Vinduets titel viser, at batch-scriptet succesfuldt startede PowerShell.
2. Den første produktionslinje viser, at en brugerdefineret PowerShell-profil er i brug. Dette er potentielt problem # 4, der er angivet ovenfor.
3. Fejlmeddelelsen demonstrerer ExecutionPolicy-begrænsninger i kraft. Det er vores problem # 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 korrekt.

Profilen er i dette tilfælde et simpelt enlinjet 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:

Skriv-Output 'Custom PowerShell-profilen 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 demonstrationsformål 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 datastream 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. omkring indstillingen ExecutionPolicy, fra CMD eller et batch script, er faktisk ret nemt. 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å til det:

Nu hvor scriptet er korrekt udført, kan vi se, hvad det rent faktisk 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 har 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.

Der er desværre ingen mulighed for 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. Hvis du vil 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" "'- Verb RunAs} "

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. Så 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 Brugerdefineret profil meddelelse 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" "% 9 dpn0.ps1" "'-Verb RunAs}"

Tilføjelse af parameteren -NoProfile til begge instanser af PowerShell, der lanceres af scriptet, betyder, at brugerens profil script vil blive fuldstændigt omgået i begge trin og vores PowerShell script vil køre i et forholdsvis forudsigeligt, standardmiljø. Her kan du se, at der ikke er nogen brugerdefineret profilbesked i en af ​​de tilstedeværende 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 sådan ud:

( Selvfølgelig, for ikke-administrator scripts, kan du gøre uden en ende-of-script pause i dit PowerShell script på dette tidspunkt også, da alt er fanget i samme konsolvindue og ville blive holdt der ved pause i slutningen af batch-fil alligevel.)

Afsluttede batchfiler.

Afhængigt af om du har brug for administratorrettigheder til dit PowerShell-script eller ej, skal den endelige batchfil se som en af ​​de to nedenfor.

Uden admin adgang:

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

Med Admin adgang:

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

Husk at sætte batchfilen i samme mappe som PowerShell-scriptet, du vil bruge det til, og giv 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 besvær, og du behøver ikke bekymre dig om at vende tilbage senere.

Referencer:

Running PowerShell-scripts fra en batchfil - Daniel Schroeder's programmeringsblog

• Kontrol af administratorrettigheder i PowerShell - Hej, Scripting Guy! Blog

---



Sådan kombineres billeder til en PDF-fil på en Mac

Sig du søger et job, og ansættelsesfirmaet vil have underskrevne dokumenter sendt til dem eller forestille dig at du vil tilføje en Tilsætning til dit hus og entreprenøren ønsker at se billeder. Hvordan gør du det nemt på en Mac? Du kan bare vedhæfte dem alle til en e-mail eller SMS-besked, men den metode er lidt besværlig og kan være noget irriterende for modtageren.

(how-to)



Tilføj en skjult gestus til din Mac, der viser alle Windows til ethvert program

Ville det ikke være køligt, hvis du kunne rulle op på et dock-ikon for hurtigt at se alle dens vinduer sammen med seneste dokumenter? En enkelt kommando tilføjer denne ellers skjulte funktion til din dock. Vi har vist dig, hvordan du bruger din MacBooks pegefeltbevægelser, herunder den nedadgående trefingerspor, der viser, at alle vinduer er åbne med den aktuelle applikation.

(how-to)