Hoe Windows eenvoudig te configureren om te werken met PowerShell-scripts

Windows en PowerShell hebben ingebouwde beveiligingsfuncties en standaardconfiguraties die bedoeld zijn om te voorkomen dat eindgebruikers per ongeluk scripts starten tijdens hun dagelijkse activiteiten. Als uw dagelijkse activiteiten echter routinematig betrekking hebben op het schrijven en uitvoeren van uw eigen PowerShell-scripts, kan dit eerder hinderlijk zijn dan een voordeel. Hier laten we u zien hoe u deze functies kunt omzeilen zonder de beveiliging volledig in gevaar te brengen.

Hoe en waarom Windows & PowerShell scriptuitvoering voorkomen.

PowerShell is in feite de opdrachtshell en scriptingtaal die bedoeld is om CMD- en batch-scripts op Windows-systemen te vervangen. Als zodanig kan een PowerShell-script vrijwel worden geconfigureerd om alles wat u handmatig kunt doen vanaf de opdrachtregel te doen. Dat komt erop neer dat vrijwel elke wijziging op uw systeem mogelijk is, tot aan de beperkingen die gelden voor uw gebruikersaccount. Dus, als je gewoon zou kunnen dubbelklikken op een PowerShell-script en het zou kunnen uitvoeren met volledige beheerdersrechten, zou een eenvoudige one-liner als deze je dag echt kunnen verwoesten:

Get-ChildItem "$ env: SystemDrive \" -Recurse -ErrorAction SilentlyLees verder | Remove-Item -Force -Recurse -ErrorAction SilentlyLees verder

Voer NIET het bovenstaande commando uit!

Dat gaat gewoon door het bestandssysteem en verwijdert alles wat het kan. Interessant is dat dit het systeem misschien niet zo snel onbruikbaar maakt als je zou denken - zelfs wanneer het uit een verhoogde sessie komt. Maar als iemand je belt na het uitvoeren van dit script, omdat ze plotseling hun bestanden niet kunnen vinden of sommige programma's niet kunnen uitvoeren, zal het "uitschakelen en opnieuw inschakelen" waarschijnlijk leiden naar Windows Startup Repair, waar ze zullen worden verteld dat er niets dat kan worden gedaan om het probleem op te lossen. Wat erger kan zijn, is dat je vriend in plaats van een script te krijgen dat alleen maar zijn bestandssysteem beschadigt, in de val gelopen kan worden om er een te downloaden die een keylogger of RAS-service downloadt en installeert. Dan, in plaats van u vragen te stellen over Startup Repair, kunnen zij de politie vragen stellen over bankfraude!

Het moet nu duidelijk zijn waarom bepaalde dingen nodig zijn om eindgebruikers te beschermen tegen zichzelf, om zo te zeggen. Maar krachtige gebruikers, systeembeheerders en andere geeks zijn over het algemeen (hoewel er uitzonderingen zijn) een beetje meer op hun hoede voor deze bedreigingen, weten hoe ze te herkennen en gemakkelijk te vermijden, en willen gewoon doorgaan met hun werk gedaan krijgen. Om dit te doen, moeten ze een paar blokkades uitschakelen of omzeilen:

PowerShell staat standaard geen externe scriptuitvoering toe.
De ExecutionPolicy-instelling in PowerShell voorkomt dat standaard externe scripts worden uitgevoerd in alle versies van Windows. In sommige Windows-versies staat de standaard helemaal geen uitvoering van scripts toe. We hebben u laten zien hoe u deze instelling kunt wijzigen in Hoe u de uitvoering van PowerShell-scripts in Windows 7 kunt toestaan, maar we behandelen het hier ook op enkele niveaus..
PowerShell is standaard niet gekoppeld aan de extensie .PS1.
We brachten dit eerst naar voren in onze PowerShell Geek School-serie. Windows stelt de standaardactie in voor .PS1-bestanden om ze in Kladblok te openen, in plaats van ze naar de PowerShell-opdrachtinterpreter te verzenden. Dit is om per ongeluk uitvoeren van kwaadwillende scripts direct te voorkomen als er eenvoudig op wordt geklikt.
Sommige PowerShell-scripts werken niet zonder beheerdersmachtigingen.
Zelfs als u met een account op beheerdersniveau werkt, moet u nog steeds Gebruikersaccountbeheer (UAC) doorlopen om bepaalde acties uit te voeren. Voor opdrachtregelprogramma's kan dit op zijn minst een beetje omslachtig zijn. We willen UAC niet uitschakelen, maar het is nog steeds leuk als we het een beetje gemakkelijker kunnen maken om ermee om te gaan.

Deze problemen worden ook besproken in Hoe een batchbestand te gebruiken om PowerShell-scripts gemakkelijker te laten werken, waar we u helpen bij het schrijven van een batchbestand om ze tijdelijk te omzeilen. Nu gaan we u laten zien hoe u uw systeem kunt instellen met een oplossing voor de langere termijn. Houd er rekening mee dat u deze wijzigingen over het algemeen niet mag aanbrengen op systemen die niet uitsluitend door u worden gebruikt - anders stelt u andere gebruikers bloot aan een hoger risico om tegen dezelfde problemen aan te lopen die deze functies moeten voorkomen.

De .PS1-bestandskoppeling wijzigen.

De eerste en misschien vooral ergernis om zich te verplaatsen is de standaard koppeling voor .PS1-bestanden. Het koppelen van deze bestanden aan iets anders dan PowerShell.exe is zinvol om het per ongeluk uitvoeren van ongewenste scripts te voorkomen. Maar aangezien PowerShell wordt geleverd met een geïntegreerde scriptingomgeving (ISE) die speciaal is ontworpen voor het bewerken van PowerShell-scripts, waarom zouden we dan .PS1-bestanden standaard in Kladblok willen openen? Zelfs als u nog niet klaar bent om volledig over te schakelen op het inschakelen van functionaliteit voor dubbelklikken om uit te voeren, wilt u deze instellingen waarschijnlijk aanpassen.

U kunt de associatie van het PS1-bestand naar het gewenste programma wijzigen via het configuratiescherm Standaardprogramma's, maar als u rechtstreeks in het register graaft, heeft u meer controle over hoe de bestanden precies worden geopend. Hiermee kunt u ook aanvullende opties instellen of wijzigen die beschikbaar zijn in het contextmenu voor .PS1-bestanden. Vergeet niet om een back-up van het register te maken voordat u dit doet!

De registerinstellingen die bepalen hoe PowerShell-scripts worden geopend, worden opgeslagen op de volgende locatie:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Als u deze instellingen wilt verkennen voordat we ze gaan wijzigen, bekijkt u die sleutel en de subsleutels met Regedit. De Shell-sleutel moet slechts één waarde hebben: "(standaard)", die is ingesteld op "Open". Dit is een verwijzing naar de standaardactie voor het dubbelklikken op het bestand, die we in de subsleutels zullen zien.

Vouw de Shell-toets uit en u ziet drie subsleutels. Elk hiervan vertegenwoordigt een actie die u kunt uitvoeren en die specifiek is voor PowerShell-scripts.

U kunt elke sleutel uitvouwen om de waarden binnenin te verkennen, maar ze komen in principe overeen met de volgende standaardwaarden:

0 - Uitvoeren met PowerShell. "Uitvoeren met PowerShell" is eigenlijk de naam van een optie die al in het contextmenu voor PowerShell-scripts staat. De tekst wordt net van een andere locatie gehaald in plaats van de sleutelnaam te gebruiken zoals de anderen. En het is nog steeds niet de standaard dubbelklikactie.
Bewerken - Openen in PowerShell ISE. Dit is veel logischer dan Notepad, maar je moet nog steeds met de rechtermuisknop op het .PS1-bestand klikken om dit standaard te doen.
Open - Open in Kladblok. Merk op dat deze sleutelnaam ook de tekenreeks is die is opgeslagen in de "(Standaard)" waarde van de Shell-sleutel. Dit betekent dat u dubbelklikt op het bestand om het te "Openen", en die actie is normaal gesproken ingesteld om Kladblok te gebruiken.

Als u wilt vasthouden aan de reeds bestaande commandostructuren die al beschikbaar zijn, kunt u de waarde "(Standaard)" in de Shell-sleutel wijzigen zodat deze overeenkomt met de naam van de sleutel die overeenkomt met wat u met een dubbelklik wilt doen. Dit kan eenvoudig worden gedaan vanuit Regedit, of u kunt lessen uit onze tutorial gebruiken om het register te verkennen met PowerShell (plus een kleine PSDrive-aanpassing) om een herbruikbaar script te maken dat uw systemen voor u kan configureren. De onderstaande opdrachten moeten worden uitgevoerd vanuit een verhoogde PowerShell-sessie, vergelijkbaar met het uitvoeren van CMD als beheerder.

Allereerst wil je een PSDrive configureren voor HKEY_CLASSES_ROOT omdat dit niet standaard is ingesteld. Het commando hiervoor is:

Nieuw PSDrive HKCR Registry HKEY_CLASSES_ROOT

Nu kunt u registersleutels en waarden in HKEY_CLASSES_ROOT navigeren en bewerken, net zoals u zou doen in de reguliere HKCU en HKLM PSDrives.

Dubbelklikken configureren om PowerShell-scripts rechtstreeks te starten:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(standaard)' 0

Dubbelklikken configureren om PowerShell-scripts te openen in de PowerShell ISE:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(standaard) "Bewerken"

De standaardwaarde herstellen (dubbelklik om PowerShell-scripts te openen in Kladblok):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(standaard) "Open"

Dat is slechts de basis voor het wijzigen van de standaardactie voor dubbelklikken. We zullen meer in detail ingaan op het aanpassen van hoe PowerShell-scripts worden behandeld wanneer ze worden geopend in PowerShell vanuit Explorer in het volgende gedeelte. Houd er rekening mee dat scoping voorkomt dat PSDrives aan elkaar blijven zitten tijdens sessies. U wilt dus waarschijnlijk de regel New-PSDrive opnemen aan het begin van elk configuratiescript dat u voor dit doel hebt gemaakt, of het toevoegen aan uw PowerShell-profiel. Anders moet u dat bit handmatig uitvoeren voordat u op deze manier wijzigingen probeert aan te brengen.

De instelling PowerShell ExecutionPolicy wijzigen.

PowerShell's ExecutionPolicy is een andere laag van bescherming tegen de uitvoering van kwaadwillende scripts. Er zijn meerdere opties voor dit, en een paar verschillende manieren waarop het kan worden ingesteld. Van de meeste tot minst veilig zijn de beschikbare opties:

Beperkt: er mogen geen scripts worden uitgevoerd. (Standaardinstelling voor de meeste systemen.) Hiermee wordt zelfs voorkomen dat uw profielscript wordt uitgevoerd.
AllSigned - Alle scripts moeten digitaal worden ondertekend door een vertrouwde uitgever om te kunnen uitvoeren zonder de gebruiker te hoeven vragen. Scripts die zijn ondertekend door uitgevers die expliciet zijn gedefinieerd als niet-vertrouwd of scripts die helemaal niet digitaal zijn ondertekend, worden niet uitgevoerd. PowerShell zal de gebruiker vragen om te bevestigen of een script is ondertekend door een uitgever die nog niet is gedefinieerd als vertrouwd of niet vertrouwd. Als u uw profielscript niet digitaal hebt ondertekend en vertrouwen hebt gevestigd in die handtekening, kan het niet worden uitgevoerd. Wees voorzichtig met welke uitgevers u vertrouwt, want u kunt alsnog kwaadwillende scripts uitvoeren als u de verkeerde vertrouwt.
RemoteSigned - Voor scripts die van internet zijn gedownload, is dit in feite hetzelfde als "AllSigned". Scripts die lokaal zijn gemaakt of uit andere bronnen dan internet zijn geïmporteerd, mogen echter worden uitgevoerd zonder bevestiging. Hier moet u ook voorzichtig zijn met welke digitale handtekeningen u vertrouwt, maar zelfs nog voorzichtiger zijn met de niet-ondertekende scripts die u wilt uitvoeren. Dit is het hoogste beveiligingsniveau waaronder u een werkend profielscript kunt hebben zonder het digitaal te hoeven ondertekenen.
Onbeperkt - Alle scripts mogen worden uitgevoerd, maar er is een bevestigingsprompt vereist voor scripts van internet. Vanaf dit punt is het helemaal aan jou om te voorkomen dat je onbetrouwbare scripts gebruikt.
Bypass - Alles loopt zonder waarschuwing. Wees voorzichtig met deze.
Niet gedefinieerd - Er is geen beleid gedefinieerd in het huidige bereik. Dit wordt gebruikt om terugval naar het beleid dat in lagere scopes is gedefinieerd (meer details hieronder) of naar de OS-standaardinstellingen toe te staan.

Zoals wordt gesuggereerd door de beschrijving van Niet-gedefinieerd, kunnen bovenstaande beleidsregels worden ingesteld in een of meer van verschillende scopes. U kunt Get-ExecutionPolicy gebruiken met de parameter -List om alle scopes en hun huidige configuratie te bekijken.

De scopes worden weergegeven in prioriteitsvolgorde, waarbij het bovenste gedefinieerde bereik de andere overschrijft. Als er geen beleid is gedefinieerd, valt het systeem terug naar de standaardinstelling (in de meeste gevallen is dit Beperkt).

MachinePolicy vertegenwoordigt een groepsbeleid dat van kracht is op computerniveau. Dit wordt over het algemeen alleen in een domein toegepast, maar kan ook lokaal worden gedaan.
UserPolicy vertegenwoordigt een groepsbeleid dat van toepassing is op de gebruiker. Dit wordt ook meestal alleen gebruikt in bedrijfsomgevingen.
Proces is een scope die specifiek is voor dit exemplaar van PowerShell. Wijzigingen in het beleid in dit bereik hebben geen invloed op andere draaiende PowerShell-processen en zijn niet effectief nadat deze sessie is beëindigd. Dit kan worden geconfigureerd door de parameter -ExecutionPolicy wanneer PowerShell wordt gestart of kan worden ingesteld met de juiste Set-ExecutionPolicy-syntaxis vanuit de sessie.
CurrentUser is een scope die is geconfigureerd in het lokale register en van toepassing is op het gebruikersaccount dat is gebruikt om PowerShell te starten. Dit bereik kan worden gewijzigd met Set-ExecutionPolicy.
LocalMachine is een scope die in het lokale register is geconfigureerd en van toepassing is op alle gebruikers op het systeem. Dit is het standaardbereik dat wordt gewijzigd als Set-ExecutionPolicy wordt uitgevoerd zonder de parameter -Scope. Omdat het van toepassing is op alle gebruikers op het systeem, kan het alleen van een verhoogde sessie worden gewijzigd.

Aangezien dit artikel vooral gaat over het omzeilen van beveiliging om de bruikbaarheid te vergemakkelijken, maken we ons alleen zorgen over de onderste drie scopes. De instellingen MachinePolicy en UserPolicy zijn alleen erg handig als u een beperkend beleid wilt afdwingen dat niet zo eenvoudigweg wordt omzeild. Door onze wijzigingen in het procesniveau of lager te houden, kunnen we eenvoudig elke beleidsinstelling gebruiken die we op een bepaald moment geschikt achten voor een bepaalde situatie.

Om een zeker evenwicht te behouden tussen beveiliging en bruikbaarheid, is het beleid dat in de schermafbeelding wordt getoond waarschijnlijk het beste. Als u het LocalMachine-beleid instelt op Beperkt, voorkomt u meestal dat er scripts worden uitgevoerd door iemand anders dan uzelf. Dit kan natuurlijk worden omzeild door gebruikers die zonder veel moeite weten wat ze doen. Maar het moet ervoor zorgen dat niet-technisch onderlegde gebruikers per ongeluk iets catastrofaals triggeren in PowerShell. Als u de CurrentUser (d.w.z .: u) hebt ingesteld als Onbeperkt, kunt u handmatig scripts uitvoeren vanaf de opdrachtregel, maar houdt u wel een waarschuwing bij voor scripts die u van internet hebt gedownload. De RemoteSigned-instelling op Proces-niveau moet worden uitgevoerd in een snelkoppeling naar PowerShell.exe of (zoals we hieronder zullen doen) in de registerwaarden die het gedrag van PowerShell-scripts bepalen. Hierdoor kunt u gemakkelijk dubbel-klik-en-rennen voor alle scripts die u schrijft, terwijl u een sterkere barrière opwerpt tegen onbedoelde uitvoering van (mogelijk kwaadwillende) scripts van externe bronnen. We willen dit hier doen, omdat het veel gemakkelijker is om per ongeluk op een script te dubbelklikken dan het handmatig te noemen vanuit een interactieve sessie.

Als u het CurrentUser- en LocalMachine-beleid wilt instellen zoals in de bovenstaande schermafbeelding, voert u de volgende opdrachten uit van een verhoogde PowerShell-sessie:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Om het RemoteSigned-beleid voor scripts uit te voeren vanuit Explorer, moeten we een waarde binnen een van de registersleutels wijzigen waarnaar we eerder keken. Dit is met name belangrijk omdat, afhankelijk van uw PowerShell- of Windows-versie, de standaardconfiguratie mogelijk is om alle ExecutionPolicy-instellingen behalve AllSigned te omzeilen. Om te zien wat de huidige configuratie voor uw computer is, kunt u deze opdracht uitvoeren (zorg ervoor dat eerst de HKCR PSDrive wordt toegewezen):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Select-Object '(standaard)'

Uw standaardconfiguratie is waarschijnlijk een van de volgende twee strings, of iets vergelijkbaars:

(Gezien op Windows 7 SP1 x64, met PowerShell 2.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-file" "% 1"

(Gezien op Windows 8.1 x64, met PowerShell 4.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "if ((Get-ExecutionPolicy) -ne 'AllSigned') Set-ExecutionPolicy -Scope Process Bypass; & '% 1 '"

De eerste is niet slecht, omdat het script alleen wordt uitgevoerd onder de bestaande ExecutionPolicy-instellingen. Het zou beter kunnen worden gemaakt door strengere beperkingen op te leggen voor een meer voor ongelukken vatbare actie, maar dit was in eerste instantie niet bedoeld om met een dubbelklik te worden getriggerd, en het standaardbeleid is tenslotte toch Beperkt. De tweede optie is echter een volledige bypass van de ExecutionPolicy die u waarschijnlijk op zijn plaats hebt - zelfs beperkt. Aangezien de bypass wordt toegepast in de procesomvang, heeft deze alleen invloed op de sessies die worden gestart wanneer scripts vanuit Verkenner worden uitgevoerd. Dit betekent echter dat u uiteindelijk scripts kunt starten waarvan u anders zou verwachten (en wilt) dat uw beleid dat verbiedt.

Om de Procession level ExecutionPolicy in te stellen voor scripts die zijn gestart vanuit Verkenner, moet u, in overeenstemming met de bovenstaande schermafbeelding, dezelfde registerwaarde wijzigen die we zojuist hebben ondervraagd. U kunt dit handmatig doen in Regedit, door dit te wijzigen:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

U kunt de instelling ook vanuit PowerShell wijzigen als u dat wilt. Vergeet niet om dit te doen vanuit een verhoogde sessie, met de HKCR PSDrive in kaart gebracht.

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(standaard) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -ExecutionPolicy "" RemoteSigned "" -file "" % 1" '

Voer PowerShell-scripts uit als beheerder.

Net zoals het een slecht idee is om UAC volledig uit te schakelen, is het ook een slechte beveiligingspraktijk om scripts of programma's met verhoogde bevoegdheden uit te voeren, tenzij je ze echt nodig hebt om bewerkingen uit te voeren waarvoor beheerdersrechten nodig zijn. Het wordt daarom afgeraden om de UAC-prompt te bouwen in de standaardactie voor PowerShell-scripts. We kunnen echter een nieuwe contextmenu-optie toevoegen zodat we eenvoudig scripts in verhoogde sessies kunnen uitvoeren wanneer dat nodig is. Dit is vergelijkbaar met de methode die wordt gebruikt om 'Openen met Kladblok' toe te voegen aan het contextmenu van alle bestanden - maar hier gaan we alleen PowerShell-scripts targeten. We gaan ook enkele technieken overnemen die in het vorige artikel zijn gebruikt, waar we een batchbestand gebruikten in plaats van register-hacks om ons PowerShell-script te starten.

Om dit in Regedit te doen, gaat u terug naar de Shell-sleutel, op:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Maak daar een nieuwe subsleutel. Noem het "Run met PowerShell (Admin)". Maak hieronder een andere subsleutel met de naam "Command". Stel vervolgens de "(Standaard)" waarde onder Command in op dit:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"' -Verb RunAs "

Als je hetzelfde doet in PowerShell, heb je deze keer eigenlijk drie lijnen nodig. Eén voor elke nieuwe sleutel en één voor het instellen van de "(Standaard)" -waarde voor Opdracht. Vergeet de elevatie en de HKCR-toewijzing niet.

Nieuw artikel 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Uitvoeren met PowerShell (Admin)' Nieuw artikel 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Uitvoeren met PowerShell (Admin) \ Commando' Set-ItemProperty ' HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run met PowerShell (Admin) \ Command "(standaard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" &  Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs "'

Let ook goed op de verschillen tussen de tekenreeks die wordt ingevoerd via PowerShell en de werkelijke waarde die naar het register gaat. In het bijzonder moeten we het hele ding in enkele aanhalingstekens wikkelen en de interne enkele aanhalingstekens verdubbelen om fouten bij het parseren van opdrachten te voorkomen.

Nu zou u een nieuw context-menu-item voor PowerShell-scripts moeten hebben, genaamd "Run with PowerShell (Admin)".

De nieuwe optie zal twee opeenvolgende PowerShell-instanties genereren. De eerste is slechts een launcher voor de tweede, die Start-Process met de "-Verb RunAs" -parameter gebruikt om hoogte voor de nieuwe sessie aan te vragen. Vanaf dat punt moet uw script kunnen worden uitgevoerd met beheerdersrechten nadat u door de UAC-prompt hebt geklikt.

Afwerking.

Er zijn nog een paar aanpassingen aan dit die kunnen helpen om het leven nog een beetje makkelijker te maken. Ten eerste, hoe zit het met het volledig wegwerken van de Notepad-functie? Kopieer eenvoudig de "(Standaard)" waarde van de Command-toets onder Bewerken (hieronder) naar dezelfde locatie onder Openen.

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"

Of u kunt dit stukje PowerShell gebruiken (uiteraard met Admin & HKCR):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command '(standaard) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe ""% 1 "'

Nog een kleine ergernis is de gewoonte van de console om te verdwijnen zodra een script is voltooid. Wanneer dat gebeurt, hebben we geen enkele kans om de scriptuitvoer te controleren op fouten of andere nuttige informatie. Dit kan worden geregeld door een pauze aan het einde van elk van uw scripts te plaatsen, natuurlijk. Als alternatief kunnen we de "(Default)" -waarden voor onze opdrachttoetsen wijzigen om de parameter "-NoExit" op te nemen. Hieronder staan de aangepaste waarden.

(Zonder beheerdersrechten)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

(Met beheerderstoegang)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ "% 1 \"' - Verb RunAs "

En natuurlijk geven we u die ook in PowerShell-opdrachten. Laatste herinnering: Elevation & HKCR!

(Niet-Admin)

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command '(standaard) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit "" -ExecutionPolicy "" RemoteSigned "" -bestand ""% 1 "'

(Beheerder)

Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Uitvoeren met PowerShell (Admin) \ Command "(standaard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs "'

Neem het voor een spin.

Om dit uit te testen, gaan we een script gebruiken dat ons de ExecutionPolicy-instellingen laat zien en of het script is gelanceerd met beheerdersrechten. Het script wordt "MyScript.ps1" genoemd en wordt opgeslagen in "D: \ Script Lab" op ons voorbeeldsysteem. De code is hieronder, ter referentie.

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

De actie "Uitvoeren met PowerShell" gebruiken:

De actie "Uitvoeren met PowerShell (Admin)" gebruiken, nadat u op UAC hebt geklikt:

Om de ExecutionPolicy in actie bij de Process-scope aan te tonen, kunnen we Windows laten denken dat het bestand afkomstig was van het internet met dit stukje PowerShell-code:

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

Gelukkig hadden we -NoExit ingeschakeld. Anders zou die fout er gewoon door hebben geknipperd en zouden we niet hebben geweten!

De Zone.Identifier kan hiermee worden verwijderd:

Clear-Content -Path 'D: \ Script Lab \ MyScript.ps1' -Stream 'Zone.Identifier'

Handige referenties:

PowerShell-scripts uitvoeren vanuit een batchbestand - het programmeerblog van Daniel Schroeder
Controleren op beheerdersrechten in PowerShell - Hey, Scripting Guy! blog