So konfigurieren Sie Windows für das Arbeiten mit PowerShell-Skripts

Windows und PowerShell verfügen über integrierte Sicherheitsfunktionen und Standardkonfigurationen, die verhindern sollen, dass Endbenutzer versehentlich Skripts während ihrer täglichen Aktivitäten starten. Wenn Ihre täglichen Aktivitäten jedoch routinemäßig das Schreiben und Ausführen eigener PowerShell-Skripts umfassen, kann dies eher ein Ärgernis als ein Vorteil sein. Hier zeigen wir Ihnen, wie Sie diese Funktionen umgehen können, ohne die Sicherheit zu beeinträchtigen.

Wie und warum Windows und PowerShell die Skriptausführung verhindern.

PowerShell ist effektiv die Befehlsshell und Skriptsprache, die CMD- und Batch-Skripts auf Windows-Systemen ersetzen soll. Daher kann ein PowerShell-Skript so konfiguriert werden, dass es alle Aufgaben ausführt, die Sie manuell über die Befehlszeile ausführen können. Dies bedeutet, dass Sie praktisch alle Änderungen an Ihrem System vornehmen können, bis zu den Einschränkungen für Ihr Benutzerkonto. Wenn Sie also einfach auf ein PowerShell-Skript doppelklicken und es mit vollständigen Administratorrechten ausführen können, könnte ein einfacher Einzeiler wie dieser Ihren Tag ruinieren:

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

Führen Sie den obigen Befehl NICHT aus!

Das geht einfach durch das Dateisystem und löscht, was es kann. Interessanterweise wird das System dadurch möglicherweise nicht so schnell funktionsunfähig, wie Sie vielleicht denken - selbst wenn Sie von einer Sitzung mit erhöhter Kapazität ausgehen. Wenn Sie jedoch nach dem Ausführen dieses Skripts von jemandem angerufen wird, weil er seine Dateien plötzlich nicht finden oder Programme ausführen kann, führt das "Ausschalten und Wiedereinschalten" wahrscheinlich dazu, dass Windows-Startreparatur ausgeführt wird nichts, was getan werden kann, um das Problem zu beheben. Schlimmer noch: Statt ein Skript zu erhalten, das nur das Dateisystem in den Papierkorb bringt, könnte Ihr Freund dazu verleitet werden, eines auszuführen, das einen Keylogger oder einen Fernzugriffsdienst herunterlädt und installiert. Anstatt Ihnen Fragen zu Startup Repair zu stellen, stellen sie der Polizei möglicherweise ein paar Fragen zu Bankbetrug!

Inzwischen sollte klar sein, warum bestimmte Dinge erforderlich sind, um die Endbenutzer sozusagen vor sich selbst zu schützen. Power User, Systemadministratoren und andere Freaks sind jedoch im Allgemeinen (obwohl es Ausnahmen gibt) etwas vorsichtiger gegenüber diesen Bedrohungen, wissen, wie man sie erkennt und sie leicht meidet, und wollen einfach nur ihre Arbeit erledigen. Dazu müssen sie einige Straßensperren deaktivieren oder umgehen:

PowerShell lässt standardmäßig keine externe Skriptausführung zu.
Die Einstellung ExecutionPolicy in PowerShell verhindert standardmäßig die Ausführung externer Skripts in allen Windows-Versionen. In einigen Windows-Versionen erlaubt die Standardeinstellung überhaupt keine Skriptausführung. Wir haben Ihnen gezeigt, wie Sie diese Einstellung in So ändern Sie die Ausführung von PowerShell-Skripts unter Windows 7 ändern können, aber wir werden es hier auch auf ein paar Ebenen behandeln.
PowerShell ist standardmäßig nicht der .PS1-Dateierweiterung zugeordnet.
Wir haben dies anfangs in unserer PowerShell Geek School-Serie angesprochen. Windows legt die Standardaktion für .PS1-Dateien fest, um sie in Notepad zu öffnen, anstatt sie an den PowerShell-Befehlsinterpreter zu senden. Dies dient dazu, die versehentliche Ausführung böswilliger Skripten durch Doppelklick direkt zu verhindern.
Einige PowerShell-Skripts funktionieren nicht ohne Administratorberechtigungen.
Selbst wenn Sie mit einem Konto auf Administratorebene arbeiten, müssen Sie immer noch die Benutzerkontensteuerung (UAC) verwenden, um bestimmte Aktionen auszuführen. Für Befehlszeilentools kann dies, um es gelinde auszudrücken, etwas umständlich sein. Wir möchten die Benutzerkontensteuerung nicht deaktivieren, aber es ist immer noch schön, wenn wir den Umgang damit etwas einfacher machen können.

Dieselben Probleme werden in So machen Sie das Ausführen von PowerShell-Skripts mithilfe einer Stapeldatei erleichtert. Hier werden Sie durch das Schreiben einer Stapeldatei geführt, um sie vorübergehend zu umgehen. Jetzt zeigen wir Ihnen, wie Sie Ihr System mit einer langfristigeren Lösung einrichten. Beachten Sie, dass Sie diese Änderungen im Allgemeinen nicht auf Systemen vornehmen sollten, die nicht ausschließlich von Ihnen verwendet werden. Andernfalls besteht für Sie die Gefahr, dass andere Benutzer denselben Problemen ausgesetzt sind, die diese Funktionen verhindern sollen.

Ändern der .PS1-Dateizuordnung.

Die erste und vor allem ärgerliche Art, um herumzukommen, ist die Standardzuordnung für .PS1-Dateien. Das Verknüpfen dieser Dateien mit einem anderen Element als PowerShell.exe ist sinnvoll, um die versehentliche Ausführung unerwünschter Skripts zu verhindern. Aber wenn man bedenkt, dass PowerShell über eine Integrated Scripting Environment (ISE) verfügt, die speziell für die Bearbeitung von PowerShell-Skripts entwickelt wurde, warum sollten wir .PS1-Dateien standardmäßig in Notepad öffnen? Selbst wenn Sie nicht bereit sind, die Doppelklick-zu-Ausführungs-Funktion vollständig zu aktivieren, sollten Sie diese Einstellungen wahrscheinlich optimieren.

Sie können die .PS1-Dateizuordnung mit dem Kontrollfeld "Standardprogramme" in ein beliebiges Programm ändern. Wenn Sie jedoch direkt in die Registrierung gehen, haben Sie ein wenig mehr Kontrolle darüber, wie die Dateien genau geöffnet werden. Auf diese Weise können Sie auch zusätzliche Optionen festlegen oder ändern, die im Kontextmenü für .PS1-Dateien verfügbar sind. Vergessen Sie nicht, eine Sicherungskopie der Registrierung zu erstellen, bevor Sie dies tun!

Die Registrierungseinstellungen, die steuern, wie PowerShell-Skripts geöffnet werden, werden an folgendem Speicherort gespeichert:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Um diese Einstellungen zu erkunden, bevor wir sie ändern, sehen Sie sich diesen Schlüssel und seine Unterschlüssel mit Regedit an. Der Shell-Schlüssel sollte nur einen Wert haben ("Standard"), der auf "Öffnen" gesetzt ist. Dies ist ein Zeiger auf die Standardaktion zum Doppelklicken auf die Datei, die in den Unterschlüsseln angezeigt wird.

Erweitern Sie den Shell-Schlüssel, und Sie sehen drei Unterschlüssel. Jede dieser Aktionen stellt eine Aktion dar, die Sie ausführen können, die für PowerShell-Skripts spezifisch ist.

Sie können jeden Schlüssel erweitern, um die darin enthaltenen Werte zu untersuchen, sie entsprechen jedoch im Wesentlichen den folgenden Standardwerten:

0 - Führen Sie mit PowerShell aus. „Mit PowerShell ausführen“ ist eigentlich der Name einer Option, die sich bereits im Kontextmenü für PowerShell-Skripts befindet. Der Text wird einfach von einem anderen Ort abgerufen, anstatt den Tastennamen wie die anderen zu verwenden. Und es ist immer noch nicht die standardmäßige Doppelklickaktion.
Bearbeiten - In PowerShell ISE öffnen. Das macht viel mehr Sinn als Notepad, aber Sie müssen immer noch mit der rechten Maustaste auf die .PS1-Datei klicken, um dies standardmäßig zu tun.
Öffnen - Im Editor öffnen. Beachten Sie, dass dieser Schlüsselname auch die Zeichenfolge ist, die im Wert "(Standard)" des Shell-Schlüssels gespeichert ist. Das bedeutet, wenn Sie auf die Datei doppelklicken, wird sie geöffnet, und normalerweise wird Notepad verwendet.

Wenn Sie die bereits vorhandenen Befehlszeichenfolgen beibehalten möchten, können Sie einfach den Wert (Standard) im Shell-Schlüssel so ändern, dass er mit dem Namen des Schlüssels übereinstimmt, der dem entspricht, was Sie mit einem Doppelklick ausführen möchten. Dies kann leicht in Regedit erledigt werden. Sie können auch die Lektionen verwenden, die Sie in unserem Tutorial zur Erkundung der Registrierung bei PowerShell (plus einem kleinen PSDrive-Tweak) gelernt haben, um mit dem Erstellen eines wiederverwendbaren Skripts zu beginnen, das Ihre Systeme für Sie konfigurieren kann. Die folgenden Befehle müssen in einer erweiterten PowerShell-Sitzung ausgeführt werden, ähnlich wie CMD als Administrator ausgeführt wird.

Zunächst müssen Sie ein PSDrive für HKEY_CLASSES_ROOT konfigurieren, da dieses nicht standardmäßig eingerichtet ist. Der Befehl dafür lautet:

New-PSDrive HKCR Registry HKEY_CLASSES_ROOT

Jetzt können Sie Registrierungsschlüssel und -werte in HKEY_CLASSES_ROOT wie in den regulären HKCU- und HKLM-PSDrives navigieren und bearbeiten.

So konfigurieren Sie das Doppelklicken zum direkten Starten von PowerShell-Skripts:

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

So konfigurieren Sie das Doppelklicken zum Öffnen von PowerShell-Skripts in der PowerShell-ISE:

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Standard) "Bearbeiten"

So stellen Sie den Standardwert wieder her (legt doppelt fest, um PowerShell-Skripts in Notepad zu öffnen):

Set-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(Standard) "Öffnen"

Das sind nur die Grundlagen zum Ändern der Standard-Doppelklickaktion. Wir werden ausführlicher auf die Anpassung der Verarbeitung von PowerShell-Skripts eingehen, wenn sie in PowerShell im nächsten Abschnitt in Explorer geöffnet werden. Beachten Sie, dass das Scoping verhindert, dass PSDrives über Sitzungen hinweg bestehen bleiben. Daher möchten Sie wahrscheinlich die New-PSDrive-Zeile zu Beginn eines Konfigurationsskripts hinzufügen, das Sie zu diesem Zweck erstellen, oder es Ihrem PowerShell-Profil hinzufügen. Andernfalls müssen Sie dieses Bit manuell ausführen, bevor Sie versuchen, auf diese Weise Änderungen vorzunehmen.

Ändern der PowerShell ExecutionPolicy-Einstellung.

Die ExecutionPolicy von PowerShell ist eine weitere Schutzschicht gegen die Ausführung bösartiger Skripts. Hierfür gibt es mehrere Optionen, und es gibt verschiedene Möglichkeiten, es einzustellen. Die meisten Optionen sind am wenigsten sicher:

Eingeschränkt - Es dürfen keine Skripts ausgeführt werden. (Standardeinstellung für die meisten Systeme.) Dadurch wird sogar die Ausführung Ihres Profilskripts verhindert.
AllSigned - Alle Skripts müssen von einem vertrauenswürdigen Herausgeber digital signiert werden, damit sie ohne Aufforderung des Benutzers ausgeführt werden können. Skripts, die von Herausgebern signiert wurden, die ausdrücklich als nicht vertrauenswürdig definiert sind, oder Skripts, die überhaupt nicht digital signiert sind, werden nicht ausgeführt. PowerShell fordert den Benutzer zur Bestätigung auf, wenn ein Skript von einem Herausgeber signiert wurde, der noch nicht als vertrauenswürdig oder nicht vertrauenswürdig definiert ist. Wenn Sie Ihr Profilskript nicht digital signiert und Vertrauen in diese Signatur hergestellt haben, kann es nicht ausgeführt werden. Seien Sie vorsichtig, welchen Herausgebern Sie vertrauen, da Sie trotzdem bösartige Skripts ausführen können, wenn Sie dem falschen vertrauen.
RemoteSigned - Für aus dem Internet heruntergeladene Skripts entspricht dies praktisch "AllSigned". Skripts, die lokal erstellt oder aus anderen Quellen als dem Internet importiert wurden, können jedoch ohne Sicherheitsabfrage ausgeführt werden. Hier müssen Sie auch auf die digitalen Signaturen achten, denen Sie vertrauen, aber auch auf die nicht signierten Skripts achten, die Sie ausführen möchten. Dies ist die höchste Sicherheitsstufe, unter der Sie ein Arbeitsprofilskript erstellen können, ohne es digital signieren zu müssen.
Uneingeschränkt - Alle Skripts können ausgeführt werden, für Skripts aus dem Internet ist jedoch eine Bestätigungsaufforderung erforderlich. Von diesem Punkt an liegt es ganz an Ihnen, nicht vertrauenswürdige Skripts auszuführen.
Bypass - Alles läuft ohne Warnung. Seien Sie vorsichtig mit diesem.
Nicht definiert - Im aktuellen Bereich ist keine Richtlinie definiert. Dies wird verwendet, um einen Rückfall auf Richtlinien zu ermöglichen, die in niedrigeren Bereichen definiert sind (weitere Einzelheiten unten) oder auf die Standardeinstellungen des Betriebssystems.

Wie in der Beschreibung von Undefined vorgeschlagen, können die obigen Richtlinien in einem oder mehreren von mehreren Bereichen festgelegt werden. Sie können Get-ExecutionPolicy mit dem Parameter -List verwenden, um alle Bereiche und ihre aktuelle Konfiguration anzuzeigen.

Die Bereiche werden in der Rangfolge aufgeführt, wobei der oberste definierte Bereich alle anderen überschreibt. Wenn keine Richtlinien definiert sind, wird das System auf seine Standardeinstellung zurückgesetzt (in den meisten Fällen ist dies "Eingeschränkt")..

MachinePolicy repräsentiert eine auf Computerebene gültige Gruppenrichtlinie. Dies wird im Allgemeinen nur in einer Domäne angewendet, kann aber auch lokal erfolgen.
UserPolicy stellt eine für den Benutzer geltende Gruppenrichtlinie dar. Dies wird normalerweise auch nur in Unternehmensumgebungen verwendet.
Der Prozess ist ein für diese Instanz von PowerShell spezifischer Bereich. Änderungen an der Richtlinie in diesem Bereich wirken sich nicht auf andere ausgeführte PowerShell-Prozesse aus und sind nach dem Beenden dieser Sitzung unwirksam. Dies kann durch den Parameter -ExecutionPolicy konfiguriert werden, wenn PowerShell gestartet wird, oder es kann innerhalb der Sitzung mit der entsprechenden Set-ExecutionPolicy-Syntax festgelegt werden.
CurrentUser ist ein Bereich, der in der lokalen Registrierung konfiguriert ist und für das Benutzerkonto gilt, das zum Starten von PowerShell verwendet wird. Dieser Bereich kann mit Set-ExecutionPolicy geändert werden.
LocalMachine ist ein in der lokalen Registrierung konfigurierter Bereich, der für alle Benutzer des Systems gilt. Dies ist der Standardbereich, der geändert wird, wenn Set-ExecutionPolicy ohne den Parameter -Scope ausgeführt wird. Da es für alle Benutzer des Systems gilt, kann es nur von einer erhöhten Sitzung aus geändert werden.

Da es in diesem Artikel hauptsächlich darum geht, die Sicherheit zu verbessern, um die Benutzerfreundlichkeit zu erleichtern, sind uns nur die unteren drei Bereiche ein Problem. Die Einstellungen für MachinePolicy und UserPolicy sind nur dann wirklich nützlich, wenn Sie eine restriktive Richtlinie durchsetzen möchten, die nicht so einfach umgangen wird. Indem wir unsere Änderungen auf der Prozessebene oder darunter beibehalten, können wir jederzeit die von uns für die jeweilige Situation angemessenen Richtlinieneinstellungen verwenden.

Um ein gewisses Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit zu erhalten, ist die in der Abbildung dargestellte Richtlinie wahrscheinlich die beste. Wenn Sie die LocalMachine-Richtlinie auf "Restricted" setzen, wird im Allgemeinen verhindert, dass Skripts von anderen Personen als Ihnen ausgeführt werden. Natürlich kann dies von Benutzern umgangen werden, die ohne viel Aufwand wissen, was sie tun. Es sollte jedoch verhindern, dass Nicht-Tech-versierte Benutzer versehentlich eine Katastrophe in PowerShell auslösen. Wenn Sie den CurrentUser (d. H .: Sie) als "Nicht eingeschränkt" festlegen, können Sie Skripts manuell über die Befehlszeile ausführen, wie Sie möchten, aber er erinnert an Vorsicht, wenn Skripts aus dem Internet heruntergeladen werden. Die RemoteSigned-Einstellung auf der Prozessebene muss in einer Verknüpfung zu PowerShell.exe oder (wie unten beschrieben) in den Registrierungswerten erfolgen, die das Verhalten von PowerShell-Skripts steuern. Dies ermöglicht eine einfache Doppelklick-Funktion für alle Skripts, die Sie schreiben, und bietet eine stärkere Barriere gegen die unbeabsichtigte Ausführung von (potenziell böswilligen) Skripts aus externen Quellen. Wir möchten dies hier tun, da ein versehentliches Doppelklicken auf ein Skript viel einfacher ist, als es normalerweise von einer interaktiven Sitzung aus manuell aufgerufen zu werden.

Führen Sie die folgenden Befehle aus einer erweiterten PowerShell-Sitzung aus, um die CurrentUser- und LocalMachine-Richtlinien wie im obigen Screenshot festzulegen:

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Um die RemoteSigned-Richtlinie für Skripts zu erzwingen, die vom Explorer ausgeführt werden, müssen wir einen Wert in einem der Registrierungsschlüssel ändern, den wir zuvor angesehen haben. Dies ist besonders wichtig, da die Standardkonfiguration je nach PowerShell- oder Windows-Version möglicherweise darin besteht, alle ExecutionPolicy-Einstellungen außer AllSigned zu umgehen. Um die aktuelle Konfiguration für Ihren Computer anzuzeigen, können Sie diesen Befehl ausführen (wobei sicherzustellen ist, dass zuerst das HKCR-PSD-Laufwerk zugeordnet ist):

Get-ItemProperty HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Auswahlobjekt '(Standardeinstellung)'

Ihre Standardkonfiguration wird wahrscheinlich eine der folgenden zwei Zeichenfolgen sein oder etwas ähnliches:

(Gesehen unter Windows 7 SP1 x64 mit PowerShell 2.0)

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

(Gesehen unter Windows 8.1 x64 mit PowerShell 4.0)

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

Die erste ist nicht so schlimm, da das Skript lediglich mit den vorhandenen ExecutionPolicy-Einstellungen ausgeführt wird. Es könnte verbessert werden, indem strengere Einschränkungen für eine unfallanfälligere Aktion erzwungen werden, aber ursprünglich nicht dazu gedacht war, durch einen Doppelklick ausgelöst zu werden, und die Standardrichtlinie ist in der Regel nach wie vor eingeschränkt. Die zweite Option ist jedoch eine vollständige Umgehung aller möglichen ExecutionPolicy, die Sie wahrscheinlich einsetzen werden - auch eingeschränkt. Da der Bypass im Prozessbereich angewendet wird, wirkt er sich nur auf die Sitzungen aus, die gestartet werden, wenn Skripts vom Explorer ausgeführt werden. Dies bedeutet jedoch, dass Sie am Ende Skripts starten können, die Sie andernfalls erwarten (und möchten), dass Ihre Richtlinie verbietet.

Um die ExecutionPolicy auf Prozessebene für vom Explorer gestartete Skripts entsprechend dem obigen Screenshot festzulegen, müssen Sie denselben Registrierungswert ändern, den Sie gerade abgefragt haben. Sie können es manuell in Regedit tun, indem Sie es wie folgt ändern:

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

Sie können die Einstellung auch in PowerShell ändern, wenn Sie möchten. Denken Sie daran, dies aus einer erhöhten Sitzung zu tun, wobei das HKCR-PSDrive zugeordnet ist.

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

Führen Sie PowerShell-Skripts als Administrator aus.

Eine UAC-Deaktivierung der Benutzerkontensteuerung ist in jedem Fall eine schlechte Idee. Es ist auch eine schlechte Sicherheitsmethode, Skripts oder Programme mit erhöhten Berechtigungen auszuführen, es sei denn, Sie benötigen sie tatsächlich für Vorgänge, die Administratorzugriff erfordern. Es wird daher nicht empfohlen, die UAC-Eingabeaufforderung in die Standardaktion für PowerShell-Skripts zu integrieren. Wir können jedoch eine neue Kontextmenüoption hinzufügen, die es uns ermöglicht, Skripts bei Bedarf problemlos in erweiterten Sitzungen auszuführen. Diese Methode ähnelt der Methode, die zum Hinzufügen von „Mit Editor öffnen“ zum Kontextmenü aller Dateien verwendet wird. Hier werden jedoch nur PowerShell-Skripts als Ziel angegeben. Wir werden auch einige Techniken einführen, die im vorigen Artikel verwendet wurden, bei denen wir eine Batchdatei anstelle von Registrierungshacks verwendeten, um unser PowerShell-Skript zu starten.

Um dies in Regedit zu tun, gehen Sie zurück in den Shell-Schlüssel unter:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

Dort erstellen Sie einen neuen Unterschlüssel. Nennen Sie es "Mit PowerShell (Admin) ausführen". Erstellen Sie darunter einen weiteren Unterschlüssel namens "Befehl". Legen Sie dann unter "Befehl" den Wert "(Standard)" fest:

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

Wenn Sie dasselbe in PowerShell tun, werden diesmal tatsächlich drei Zeilen benötigt. Einer für jeden neuen Schlüssel und einer, um den Wert ((Standard) für Command festzulegen. Vergessen Sie nicht die Elevation und die HKCR-Zuordnung.

Neues Element 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run with PowerShell (Admin)' Neues Element 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Ausführen mit PowerShell (Admin) \ Befehl' Set-ItemProperty ' HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Ausführen mit PowerShell (Admin) \ Befehl "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "- Befehl" "" &  Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \"% 1 \ "" - Verb RunAs "'

Achten Sie auch auf die Unterschiede zwischen der über PowerShell eingegebenen Zeichenfolge und dem tatsächlichen Wert, der in die Registry eingegeben wird. Insbesondere müssen wir das Ganze in einfache Anführungszeichen packen und die internen einfachen Anführungszeichen verdoppeln, um Fehler beim Parsen von Befehlen zu vermeiden.

Jetzt sollten Sie einen neuen Kontextmenüeintrag für PowerShell-Skripts mit der Bezeichnung "Mit PowerShell (Admin) ausführen" erstellen..

Mit der neuen Option werden zwei aufeinander folgende PowerShell-Instanzen erzeugt. Der erste ist nur ein Starter für den zweiten, der Start-Process mit dem Parameter "-Verb RunAs" verwendet, um die Erhöhung für die neue Sitzung anzufordern. Von dort sollte Ihr Skript mit Administratorrechten ausgeführt werden können, nachdem Sie auf die UAC-Eingabeaufforderung geklickt haben.

Feinschliff.

Es gibt nur ein paar weitere Verbesserungen, die das Leben noch ein bisschen leichter machen können. Wie wäre es, wenn Sie die Notepad-Funktion vollständig loswerden würden? Kopieren Sie einfach den Wert "(Standard)" von der Befehlstaste unter Bearbeiten (unten) an dieselbe Stelle unter Öffnen.

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

Oder Sie können dieses bisschen PowerShell verwenden (natürlich mit Admin & HKCR):

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

Ein weiterer kleiner Ärger ist die Gewohnheit der Konsole, nach Abschluss eines Skripts zu verschwinden. In diesem Fall haben wir keine Möglichkeit, die Skriptausgabe auf Fehler oder andere nützliche Informationen zu überprüfen. Dies kann durch eine Pause am Ende jedes Skripts natürlich behoben werden. Alternativ können wir die Werte für ("Standard") für unsere Befehlstasten ändern, um den Parameter "-NoExit" einzuschließen. Nachfolgend sind die geänderten Werte aufgeführt.

(Ohne Admin-Zugriff)

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

(Mit Administratorzugriff)

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

Und natürlich geben wir Ihnen diese auch in PowerShell-Befehlen. Letzte Erinnerung: Elevation & HKCR!

(Nicht-Admin)

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

(Administrator)

Set-ItemProperty 'HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Mit PowerShell (Admin) ausführen \ Befehl "(Standard)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Befehl" "" & Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned-Datei \"% 1 \ "" - Verb RunAs "'

Nehmen Sie es für eine Drehung.

Um dies zu testen, verwenden wir ein Skript, das uns zeigt, welche Einstellungen für ExecutionPolicy vorhanden sind und ob das Skript mit Administratorberechtigungen gestartet wurde oder nicht. Das Skript heißt "MyScript.ps1" und wird in unserem Beispielsystem unter "D: \ Script Lab" gespeichert. Der Code ist unten als Referenz.

if (([[Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()).. IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) Schreib-Ausgabe als Administrator ausgeführt! Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Verwenden der Aktion "Mit PowerShell ausführen":

Verwenden der Aktion "Mit PowerShell (Admin) ausführen" nach dem Klicken durch die Benutzerkontensteuerung:

Um die ExecutionPolicy im Prozessbereich in Aktion zu demonstrieren, können wir Windows mit diesem PowerShell-Code denken lassen, dass die Datei aus dem Internet stammt:

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

Zum Glück hatten wir -NoExit aktiviert. Andernfalls wäre dieser Fehler nur durchgeblendet und wir hätten es nicht gewusst!

Der Zone.Identifier kann damit entfernt werden:

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

Nützliche Referenzen:

Ausführen von PowerShell-Skripts aus einer Batchdatei - Daniel Schroeders Programmierblog
Überprüfen auf Administratorberechtigungen in PowerShell - Hey, Scripting Guy! Blog