Ich verwende Windows PowerShell 2.0 unter 64-Bit Windows 7 Professional . Auf meinem Desktop befindet sich ein Skript, das den folgenden Fehler verursacht, wenn ich versuche, es auszuführen:
File C:\Users\UserName\Desktop\Script.ps1 cannot be loaded. The file C:\Users\UserName\Desktop\Script.ps1 is not digitally signed. The script will not execute on the system. Please see "get-help about_signing" for more details..
At line:1 char:54
+ C:\Users\UserName\Desktop\TestGetWindowsUpdateLog.ps1 <<<<
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrorId : RuntimeException
Ich bin sowohl ein Domänenadministrator als auch ein lokaler Administrator. Wenn Sie Get-ExecutionPolicy -List
ausführen, kann ich feststellen, dass der Group Policy Object
, den ich zur Konfiguration von PowerShell
erstellt habe, die Ausführungsrichtlinie RemoteSigned
auf Computerebene korrekt anwendet:
Scope ExecutionPolicy
----- ---------------
MachinePolicy RemoteSigned
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
Ich habe das Skript selbst in Notepad erstellt und das Dienstprogramm Sysinternals ' streams und die Datei Properties
verwendet, um zu bestätigen, dass das Skript nicht als aus dem Internet stammend behandelt wird. Wenn ich das Skript in eine Netzwerkfreigabe auf einem Domänenserver kopiere, darf es ausgeführt werden. Wenn ich Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine
starte, darf das lokale Skript immer noch nicht ausgeführt werden, was sinnvoll ist, da die Ausführungsrichtlinie im Bereich MachinePolicy
Vorrang hat.
Wie durch about_Execution_Policies
dokumentiert, bedeutet die RemoteSigned
-Richtlinie:
Skripte können ausgeführt werden.
Erfordert eine digitale Signatur eines vertrauenswürdigen Herausgebers für aus dem Internet heruntergeladene Skripts und Konfigurationsdateien (einschließlich E-Mail- und Instant Messaging-Programmen).
Erfordert keine digitalen Signaturen für ausgeführte Skripts, die Sie auf dem lokalen Computer geschrieben haben (nicht aus dem Internet heruntergeladen).
Risiken beim Ausführen von nicht signierten Skripts aus anderen Quellen als dem Internet und signierten, aber böswilligen Skripts.
Mein Skript ist nicht signiert, aber da es lokal erstellt und ausgeführt wird, sollte es den dritten Punkt oben erfüllen. Warum darf es nicht laufen? Warum beanstandet PowerShell, dass mein Skript "nicht digital signiert" ist, wenn diese Anforderung nur für Dateien aus dem Internet gelten sollte? Und warum kümmert es nicht mehr, dass das Skript nicht signiert wird, wenn es von einer Netzwerkfreigabe ausgeführt wird?
Ich habe es endlich aufgespürt . NET Code Access Security . Ich habe einige intern entwickelte Binärmodule, die auf einer Netzwerkfreigabe gespeichert und von dieser ausgeführt werden. Damit .NET 2.0/PowerShell 2.0 sie lädt, habe ich der Codegruppe Intranet
eine URL-Regel hinzugefügt, um diesem Verzeichnis zu vertrauen:
PS C:\Users\UserName> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -listgroups
Microsoft (R) .NET Framework CasPol 2.0.50727.5420
Copyright (c) Microsoft Corporation. All rights reserved.
Security is ON
Execution checking is ON
Policy change Prompt is ON
Level = Machine
Code Groups:
1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
1.1.1. StrongName - ...: FullTrust
1.1.2. StrongName - ...: FullTrust
1.2. Zone - Intranet: LocalIntranet
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.2.3. Url - file://Server/Share/Directory/WindowsPowerShell/Modules/*: FullTrust
1.3. Zone - Internet: Internet
1.3.1. All code: Same site Web
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.5.1. All code: Same site Web
Beachten Sie, dass je nachdem, welche .NET-Versionen installiert sind und ob es sich um 32- oder 64-Bit-Windows handelt, caspol.exe
an den folgenden Speicherorten mit jeweils eigener Sicherheitskonfiguration (security.config
) vorhanden sein kann:
$Env:SystemRoot\Microsoft.NET\Framework\v2.0.50727\
$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\
$Env:SystemRoot\Microsoft.NET\Framework\v4.0.30319\
$Env:SystemRoot\Microsoft.NET\Framework64\v4.0.30319\
Nachdem Sie die Gruppe 1.2.3
gelöscht haben (wobei ich die Standardkonfiguration für CAS beibehalten habe), funktionieren die lokalen Skripts jetzt wieder. Es ist schon eine Weile her, dass ich an CAS herumgebastelt habe, und ich bin mir nicht sicher, warum meine Regel diejenigen zu beeinträchtigen scheint, die FullTrust
bis MyComputer
gewähren, aber seit CAS ist veraltet als von .NET 4. (auf dem PowerShell 3.0 basiert), ich denke, es ist jetzt ein strittiger Punkt.
Wird die Datei gesperrt? Ich hatte das gleiche Problem und konnte dieses Problem beheben, indem Sie mit der rechten Maustaste auf die .PS1-Datei, Eigenschaften, klicken und die Option Blockierung aufheben.
Einige Dinge zu überprüfen:
Kannst du uneingeschränkt wechseln?
Set-ExecutionPolicy Unrestricted
Ist die Gruppenrichtlinie festgelegt?
Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell
User Configuration\Administrative Templates\Windows Components\Windows PowerShell
Wie rufen Sie Script.ps1 auf?
Lässt es das laufen?
powershell.exe -executionpolicy bypass -file .\Script.ps1
Wenn die Datei von einem Netzwerkspeicherort, dh einem anderen Computer, kopiert wird, hat Windows diese Datei möglicherweise blockiert. Klicken Sie mit der rechten Maustaste auf die Datei und klicken Sie auf die Schaltfläche zum Entsperren, um zu sehen, ob sie funktioniert.
Dies ist eine Ausgabe von IDE. Ändern Sie die Einstellung in der PowerShell-Benutzeroberfläche. Gehen Sie zur Registerkarte Tools und wählen Sie Optionen und dann Debugging-Optionen . Aktivieren Sie dann das Kontrollkästchen Deaktivieren Sie die Signatur von Skripts . Erledigt.
Führen Sie die Powershell-Benutzeroberfläche als Administrator aus
Beim Ausführen einer PS1-Datei für ein zugeordnetes Laufwerk in Dropbox habe ich festgestellt, dass diese Fehlermeldung immer angezeigt wird. Beim Öffnen von Eigenschaften für die PS1 gibt es kein "Unblock".
Das einzige, was für mich funktioniert, ist
powershell.exe -executionpolicy umgeht die -Datei.\Script.ps1