Aus mehreren Gründen sind meist sicherheitsbezogene PowerShell-Skripts nicht so leicht portierbar und verwendbar wie Batch-Skripts. Um diese Probleme zu umgehen, können wir jedoch ein Batch-Skript mit unseren PowerShell-Skripts bündeln. Hier zeigen wir Ihnen einige dieser Problembereiche und wie Sie ein Batch-Skript erstellen, um sie zu umgehen.

Warum kann ich meine .PS1-Datei nicht einfach auf einen anderen Computer kopieren und ausführen?

Wenn das Zielsystem nicht vorkonfiguriert wurde, um die Ausführung beliebiger Skripte mit den erforderlichen Rechten und den richtigen Einstellungen zu ermöglichen, werden Sie wahrscheinlich einige Probleme bekommen, wenn Sie dies versuchen.

1. PowerShell ist Standardmäßig nicht mit der Dateierweiterung .PS1 verknüpft. Wir haben dies zunächst in unserer PowerShell Geek School-Serie vorgestellt. Windows ordnet .PS1-Dateien standardmäßig dem Editor zu, anstatt sie an den PowerShell-Befehlsinterpreter zu senden. Dies soll verhindern, dass bösartige Skripts versehentlich ausgeführt werden, indem Sie einfach auf sie doppelklicken. Es gibt Möglichkeiten, dieses Verhalten zu ändern, aber das ist wahrscheinlich nicht das, was Sie auf jedem Computer tun möchten, mit dem Sie Ihre Skripts herumtragen - vor allem, wenn einige dieser Computer nicht Ihre eigenen sind.
2. PowerShell lässt keine externen zu Skriptausführung standardmäßig. Die ExecutionPolicy-Einstellung in PowerShell verhindert die Ausführung externer Skripts standardmäßig in allen Windows-Versionen. In einigen Windows-Versionen erlaubt der Standard überhaupt keine Skriptausführung. Wir haben Ihnen gezeigt, wie Sie diese Einstellung unter Ausführen von PowerShell-Skripten unter Windows 7 ändern können. Dies ist jedoch auch etwas, das Sie nicht auf einem beliebigen Computer ausführen möchten.
3. Einige PowerShell-Skripts funktionieren nicht ohne Administratorberechtigungen. Selbst wenn Sie mit einem Konto auf Administratorebene arbeiten, müssen Sie die Benutzerkontensteuerung (User Account Control, UAC) durchgehen, um bestimmte Aktionen auszuführen. Wir möchten das nicht deaktivieren, aber es ist immer noch schön, wenn wir es etwas einfacher machen können.
4. Einige Benutzer haben möglicherweise angepasste PowerShell-Umgebungen.
   Sie werden wahrscheinlich nicht oft darauf stoßen, aber Wenn Sie dies tun, kann das Laufen und die Fehlersuche in Ihren Skripten etwas frustrierend sein. Glücklicherweise können wir das umgehen, ohne auch nur dauerhafte Änderungen vorzunehmen.

Schritt 1: Doppelklick zum Ausführen.

Beginnen wir mit dem ersten Problem - .PS1-Dateizuordnungen. Sie können nicht doppelklicken, um .PS1-Dateien auszuführen, aber Sie können eine .BAT-Datei auf diese Weise ausführen. Wir schreiben also eine Batch-Datei, um das PowerShell-Skript über die Befehlszeile für uns aufzurufen.

Also müssen wir die Batch-Datei nicht für jedes Skript neu schreiben, oder jedes Mal, wenn wir ein Skript verschieben, Es wird eine selbstreferenzierende Variable verwendet, um den Dateipfad für das PowerShell-Skript zu erstellen. Damit dies funktioniert, muss die Batch-Datei im selben Ordner wie das PowerShell-Skript gespeichert werden und denselben Dateinamen haben. Wenn Ihr PowerShell-Skript also "MyScript.ps1" heißt, sollten Sie Ihre Batch-Datei "MyScript.bat" benennen und sicherstellen, dass sie sich im selben Ordner befindet. Setzen Sie diese Zeilen dann in das Stapelscript:

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

Wenn die anderen Sicherheitseinschränkungen nicht vorhanden wären, würde dies der Fall sein wirklich alles was Sie brauchen, um ein PowerShell-Skript aus einer Batch-Datei auszuführen. Tatsächlich sind die erste und die letzte Zeile hauptsächlich eine Frage der Präferenz - es ist die zweite Zeile, die wirklich die Arbeit macht. Hier ist die Aufteilung:

@ECHO OFF schaltet das Befehlsechoing aus. Dadurch werden Ihre anderen Befehle nicht mehr auf dem Bildschirm angezeigt, wenn die Stapelverarbeitungsdatei ausgeführt wird. Diese Zeile wird selbst durch das Symbol at (@) davor verborgen.

PowerShell.exe -Command "& '% ~ dpn0.ps1'" führt das PowerShell-Skript aus. PowerShell.exe kann natürlich von jedem CMD-Fenster oder jeder Batch-Datei aus aufgerufen werden, um PowerShell wie üblich auf einer leeren Konsole zu starten. Sie können es auch verwenden, um Befehle direkt aus einer Stapeldatei auszuführen, indem Sie den Parameter -Command und die entsprechenden Argumente einfügen. Die Art, wie dies verwendet wird, um unsere .PS1-Datei zu tarnen, ist mit der speziellen Variable% ~ dpn0. Aus einer Batch-Datei ausgeführt, ermittelt% ~ dpn0 den Laufwerksbuchstaben, den Ordnerpfad und den Dateinamen (ohne Erweiterung) der Batch-Datei. Da sich die Batch-Datei und das PowerShell-Skript im selben Ordner befinden und denselben Namen haben, wird% ~ dpn0.ps1 in den vollständigen Dateipfad des PowerShell-Skripts übersetzt.

PAUSE pausiert nur die Batch-Ausführung und wartet auf Benutzereingaben. Dies ist im Allgemeinen nützlich, um am Ende Ihrer Batch-Dateien zu haben, so dass Sie die Möglichkeit haben, alle Befehlsausgaben zu überprüfen, bevor das Fenster verschwindet. Wenn wir die einzelnen Schritte testen, wird die Nützlichkeit dieser Schritte deutlicher.

Die Basis-Batch-Datei ist also eingerichtet. Zu Demonstrationszwecken wird diese Datei als "D: Script Lab MyScript.bat" gespeichert und es befindet sich ein "MyScript.ps1" im selben Ordner. Mal sehen, was passiert, wenn wir auf MyScript.bat doppelklicken.

Offensichtlich lief das PowerShell-Skript nicht, aber das ist zu erwarten - wir haben schließlich nur das erste unserer vier Probleme angesprochen. Es werden hier jedoch einige wichtige Bits demonstriert:

1. Der Fenstertitel zeigt, dass das Stapelscript PowerShell erfolgreich gestartet hat.
2. Die erste Ausgabezeile zeigt, dass ein benutzerdefiniertes PowerShell-Profil verwendet wird. Dies ist das potenzielle Problem # 4, das oben aufgeführt ist.
3. Die Fehlermeldung zeigt, dass ExecutionPolicy-Einschränkungen wirksam sind. Das ist unser Problem # 2.
4. Der unterstrichene Teil der Fehlermeldung (der nativ von der PowerShell-Fehlerausgabe stammt) zeigt, dass das Batch-Skript das beabsichtigte PowerShell-Skript (D: Script Lab MyScript.ps1) richtig ausgerichtet hat. So wissen wir zumindest, dass viel funktioniert.

Das Profil ist in diesem Fall ein einfaches einzeiliges Skript, das für diese Demonstration verwendet wird, um die Ausgabe zu erzeugen, wenn das Profil aktiv ist. Sie können auch Ihr eigenes PowerShell-Profil anpassen, wenn Sie diese Skripts selbst testen möchten. Fügen Sie Ihrem Profilskript einfach die folgende Zeile hinzu:

Write-Output 'Angepasstes PowerShell-Profil in Kraft!'

Die ExecutionPolicy auf dem Testsystem ist hier auf RemoteSigned gesetzt. Dies ermöglicht die Ausführung von Skripten, die lokal erstellt werden (wie das Profilskript), während Skripts von externen Quellen blockiert werden, sofern sie nicht von einer vertrauenswürdigen Autorität signiert sind. Zu Demonstrationszwecken wurde der folgende Befehl verwendet, um MyScript.ps1 als aus einer externen Quelle zu kennzeichnen:

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

Damit wird der alternative Datenstrom von Zone.Identifier auf MyScript.ps1 gesetzt, sodass Windows glaubt, dass die Datei aus dem Internet stammt. Es kann leicht mit dem folgenden Befehl rückgängig gemacht werden:

Clear-Content -Pfad 'D:  Skriptlab  MyScript.ps1' -Stream 'Zone.Identifier'

Schritt 2: Getting ExecutionPolicy.

Getting um die Einstellung ExecutionPolicy, von CMD oder einem Batch-Skript, ist eigentlich ziemlich einfach. Wir ändern nur die zweite Zeile des Skripts, um dem Befehl PowerShell.exe einen weiteren Parameter hinzuzufügen.

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

Der Parameter "-ExecutionPolicy" kann wird verwendet, um die Ausführungspolicy zu ändern, die beim Erstellen einer neuen PowerShell-Sitzung verwendet wird. Dies wird nicht über diese Sitzung hinaus bestehen bleiben, so dass wir PowerShell jederzeit ausführen können, ohne die allgemeine Sicherheit des Systems zu beeinträchtigen. Nun, da wir das Problem behoben haben, wollen wir es noch einmal versuchen:

Nun, da das Skript ordnungsgemäß ausgeführt wurde, können wir sehen, was es tatsächlich tut. Es teilt uns mit, dass wir das Skript als eingeschränkter Benutzer ausführen. Das Skript wird tatsächlich von einem Konto mit Administratorberechtigungen ausgeführt, aber die Benutzerkontensteuerung stört den Weg. Obwohl Einzelheiten darüber, wie das Skript den Administratorzugriff überprüft, den Rahmen dieses Artikels sprengen würden, hier der Code, der für die Demonstration verwendet wird:

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) {Write-Output 'Wird als Administrator ausgeführt!'} Else {Write-Output 'Running Limited!'} Pause

Sie werden es ebenfalls bemerken Es gibt jetzt zwei "Pause" -Operationen in der Skript-Ausgabe - eine aus dem PowerShell-Skript und eine aus der Batch-Datei. Der Grund dafür wird im nächsten Schritt deutlicher werden.

Schritt 3: Administratorzugriff erhalten

Wenn Ihr Skript keine Befehle ausführt, die eine Erhöhung erfordern, und Sie sind sich ziemlich sicher, dass dies nicht der Fall ist Um sich Sorgen zu machen, dass jemandes benutzerdefinierte Profile in die Quere kommen, können Sie den Rest überspringen. Wenn Sie jedoch Cmdlets auf Administratorebene ausführen, benötigen Sie dieses Stück.

Leider gibt es keine Möglichkeit, die Benutzerkontensteuerung für die Erhöhung innerhalb einer Batchdatei oder CMD-Sitzung zu aktivieren. PowerShell erlaubt uns dies jedoch mit Start-Prozess. Bei Verwendung von "-Verb RunAs" in seinen Argumenten versucht Start-Process, eine Anwendung mit Administratorberechtigungen zu starten. Wenn die PowerShell-Sitzung nicht bereits erhöht ist, wird eine UAC-Eingabeaufforderung ausgelöst. Um dies aus der Batch-Datei zum Starten unseres Skripts zu verwenden, werden am Ende zwei PowerShell-Prozesse generiert - einer zum Starten von Process und ein weiterer, der von Start-Process gestartet wird, um das Skript auszuführen. Die zweite Zeile der Batchdatei muss folgendermaßen geändert werden:

PowerShell.exe - Befehl "& {Start-Process PowerShell.exe -ArgumentList '- ExecutionPolicy Bypass - Datei" "% ~ dpn0.ps1" "' - Verb RunAs} "

Wenn die Stapeldatei ausgeführt wird, stammt die erste Ausgabezeile aus dem PowerShell-Profilskript. Dann wird eine UAC-Eingabeaufforderung angezeigt, wenn Start-Process versucht, MyScript.ps1 zu starten.

Nach dem Klicken auf die UAC-Eingabeaufforderung wird eine neue PowerShell-Instanz generiert. Da es sich um eine neue Instanz handelt, wird die Profilskriptanzeige natürlich erneut angezeigt. Dann läuft MyScript.ps1 und wir sehen, dass wir tatsächlich in einer erhöhten Sitzung sind.

Und es gibt den Grund, warum wir auch hier zwei Pausen haben. Wenn nicht im PowerShell-Skript, würden wir nie die Ausgabe des Skripts sehen - das PowerShell-Fenster würde einfach auftauchen und verschwinden, sobald das Skript fertig ist. Und ohne die Pause in der Batch-Datei könnten wir nicht sehen, ob es überhaupt Fehler beim Start von PowerShell gegeben hat.

Schritt 4: Umgehen Sie benutzerdefinierte PowerShell-Profile.

Lassen Sie uns diese unangenehmen loswerden Kundenprofil jetzt, sollen wir? Hier ist es kaum störend, aber wenn das PowerShell-Profil eines Benutzers die Standardeinstellungen, Variablen oder Funktionen auf eine Weise ändert, die Sie mit Ihrem Skript nicht erwartet haben, können sie sehr problematisch sein. Es ist viel einfacher, das Skript ohne das Profil auszuführen, sodass Sie sich keine Sorgen machen müssen. Dazu müssen wir nur noch die zweite Zeile der Batch-Datei ändern:

PowerShell.exe -NoProfile -Command "& {Start-Prozess PowerShell.exe -ArgumentList '-NoProfile-ExecutionPolicy Bypass -Datei" "% ~ dpn0.ps1" "'-Verb RunAs}"

Das Hinzufügen des Parameters "NoProfile" zu beiden PowerShell-Instanzen, die vom Skript gestartet werden, bedeutet, dass das Profilskript des Benutzers in beiden Schritten und in unserem PowerShell-Skript vollständig umgangen wird wird in einer ziemlich vorhersehbaren Standardumgebung ausgeführt. Hier sehen Sie, dass in keiner der erzeugten Shells eine benutzerdefinierte Profilbenachrichtigung vorhanden ist.

Wenn Sie in Ihrem PowerShell-Skript keine Administratorrechte benötigen und Schritt 3 übersprungen haben, können Sie auf die zweite PowerShell-Instanz und Die zweite Zeile Ihrer Batchdatei sollte folgendermaßen aussehen:

PowerShell.exe -NoProfile -ExecutionPolicy Bypass-Befehl "& '% ~ dpn0.ps1'"

Die Ausgabe sieht dann so aus:

( Natürlich können Sie für Nicht-Administrator-Skripte auch an diesem Punkt auf eine Scriptende-Pause in Ihrem PowerShell-Skript verzichten, da alles im selben Konsolenfenster erfasst wird und dort von der Pause am Ende des Skripts gehalten wird Batch-Datei auf jeden Fall.)

Abgeschlossene Batch-Dateien.

Je nachdem, ob Sie Administrator-Berechtigungen für Ihr PowerShell-Skript benötigen (und Sie sie eigentlich nicht anfordern sollten), sollte die endgültige Batch-Datei aussehen wie eine der beiden folgenden.

Ohne Administratorzugriff:

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

Mit Administratorzugriff:

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

Denken Sie daran, die Batchdatei in den gleichen Ordner wie das PowerShell-Skript zu setzen, für das Sie sie verwenden möchten, und geben Sie denselben Namen ein . Unabhängig davon, auf welchem ​​System Sie diese Dateien verwenden, können Sie Ihr PowerShell-Skript ausführen, ohne sich mit den Sicherheitseinstellungen des Systems herumschlagen zu müssen. Sie können diese Änderungen natürlich jedes Mal manuell vornehmen, aber das erspart Ihnen diese Probleme und Sie müssen sich keine Gedanken darüber machen, die Änderungen später rückgängig zu machen.

Referenzen:

• Ausführen von PowerShell-Skripten aus einer Batch-Datei - Daniel Schroeders Programmier-Blog
• Überprüfen auf Administratorberechtigungen in PowerShell - Hey, Scripting Guy! Blog

Warum kann ich keine Verbindung zu LAN-Spielen in meinem Heimnetzwerk herstellen?

LAN-Spiele sind eine altehrwürdige Tradition, bei der Sie sich mit Personen direkt in Ihrem lokalen Netzwerk verbinden können Multiplayer-Spaß, aber was, wenn die Computer sich weigern miteinander zu kommunizieren? Lies weiter, während wir die LAN-Probleme eines anderen Lesers lösen und ihn zurück ins Spiel bringen.

(how-to)

5 Old School Gaming Systeme, die Sie noch kaufen können

Obwohl ich meine Xbox 360 mit Kinect liebe, fühle ich immer noch einen Hauch von Nostalgie, wenn ich an meinen Nintendo Game Boy oder mein Nintendo NES System oder meine Sega Genesis denke. Das waren klassische Konsolen, als ich aufwuchs. Und wenn du vor ein paar Jahren vor 1980 geboren wurdest, hast du wahrscheinlich auch mit dem Atari 2600 gespielt, obwohl ich das verpasst habe.

(How-to)