I have a batch file that calls powershell script and runs it.
Powershell.exe -ExecutionPolicy RemoteSigned -File %1
%1 argument is the file_name.ps1
When i run it from my local drive, the script runs fine.
however, I moved the scripts to run on a shared drive, and when i try running it from there, it gives this kind of prompt before proceeding:
The problem with this is autosys has to bypass this prompt, otherwise its giving error.
But why is this even an issue in the shared drive when if i run the script on local drive it doesn't prompt this? and what should i do to resolve it?
I tried passing in the Unblock-File -Path some_path in powershell but its apparently not recognized cmdlet.
Ok, so after being unable to load the zone identification for the file, I tried ByPass policy instead as follows:
Powershell.exe -ExecutionPolicy ByPass -File %1
THAT made it work....instead of RemoteSigned/Unrestricted...
Based on MSDN article here: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-6
RemoteSigned: Scripts can run.
Requires a digital signature from a trusted publisher on scripts and
configuration files that are downloaded from the Internet (including
e-mail and instant messaging programs).
Does not require digital signatures on scripts that you have written
on the local computer (not downloaded from the Internet).
Runs scripts that are downloaded from the Internet and not signed, if
the scripts are unblocked, such as by using the Unblock-File cmdlet.
Unrestricted: Unsigned scripts can run. (This risks running malicious
scripts.)
Warns the user before running scripts and configuration files that are
downloaded from the Internet.
but my script was copied locally there from one drive to another, its not downloaded from the internet...and in the file properties, there was no "Unblock" button, and Unblock cmdlet wouldnt work for me anyways.
So to avoid the warning, the only thing that worked is ByPass
Bypass: Nothing is blocked and there are no warnings or prompts.
In Internet Information Services Manager, for each app pool, there is an option to set path to a Shutdown Executable, and any parameters under Rapid-Fail Protection in advanced settings.
I have several app pools (a couple hundred) and would like to use a PowerShell script to automate setting
the shutdown field of each one to a program I created.
Does such a PowerShell command exist? I have pored through the appropriate documentation but with no results.
Short answer? I cant figure it out in Powershell specifically, However.. using "appcmd.exe" I was able to make this happen. I wrote a script that tried to restart the app pool and emails me the result. This script gets kicked off by the rapid fail protection. I can share this script too if you like...
However, I really didnt want to manually set every app pool as you mention, so I came up with the following.. Its not as pretty or elegant as some, but, it works:
$poolList = (Get-ItemProperty -Path "IIS:\AppPools\*").name
ForEach($pool in $poolList) {
C:\Windows\System32\inetsrv\appcmd.exe set apppool "$pool" /Failure.autoshutdownParams:"D:\_Scripts\CheckPools.ps1 -PoolName $pool"
C:\Windows\System32\inetsrv\appcmd.exe set apppool "$pool" /Failure.autoshutdownexe:"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
Get-ItemProperty -Path "IIS:\AppPools\$pool" -name Failure.autoshutdownexe|select *
}
I can confirm for me, with Windows 2016, this script sets the Shutdown Executable, and the Shutdown Executable Parameter. The Executable is set to launch powershell, and the parameters calls a powershell script and passes it the app pool name.
I am trying to run a specific command line function in my PowerShell script. The catch is the command needs elevated permissions to be able to execute.
Here is a condensed example:
# PowerShell code...
query session /server:"SERVERNAME" #NEEDS ELEVATED PERMISSIONS
# More PowerShell code
The query command needs to be run under elevated permissions.
I have tried the following:
Invoke-Command -ScriptBlock {
query session /server:"SERVERNAME"
} -Credential get-credential
But this doesn't work because the -ComputerName parameter needs to be present when using a -Credential parameter. I want to be able to run this without using a remote server.
I know I can get around it by having the users start up PowerShell under their elevated account credentials, but I'd rather just prompt for credentials while the script runs and just run that single command under their administrator account credentials. Everything else the script does is fine under normal credentials.
There are some add-ins for PowerShell, but I actually found the simplest way was to:
Sysinternals in regular command line
With the PSexec process, you can pass IP address, usermame, and password
Fiddle with it to a point you're happy
Create a batch file to then run from PowerShell if that is the desired deploy to environment
When creating the method, have it consume parameters if you want the call out to be dynamic and consume different usernames/passwords/IP addresses to log into
If the exec will always run on "computerA" using "loginA" and "pwA" then there is obviously no need to parameterize
*Sysinternals cannot be used to outright hack a terminal. The user of a remote exec must first have the same Sysinternals tools installed to the system that is to accept remote executables, that tool must be opened once and given GUI-based approval to allow run on said system must be physically addressed.
Note: Any remote PSexec's using credentials will execute with the same level of permissions that the provided username/password is granted on that system.
Here is the link: (PsExec v2.2). Although I recommend going a level or two up and downloading the entire toolbox.
I'm trying to have powershell create a folder for me and it works fine when I type it into the console. However, when I run the same command as a script, no folder is created and no error messages are supplied.
This is the line of code I am using.
new-item - path c:\test\ -name testfolder -itemtype directory
edit: I am on Windows 7
This should be a comment, but I cannot comment. There is definitely nothing wrong with that line of code. It runs on my machine, either from the terminal window or as a script. Because the code works for you at the terminal window but not when executing as a script my first guess is that your system may be configured to disallow powershell scripts. This is the default setting, and it will prevent a script file from executing but will not prevent commands typed at the prompt from working. Open a powershell session and type get-executionpolicy. If it returns "restricted" then you have found the culprit. This setting can be changed by opening an elevated powershell session (run as admin) and typing set-executionpolicy -executionpolicy RemoteSigned. Of course you should read about what those settings mean before changing them to determine what is best for your situation. For example the remotesigned option means that scripts originating from your machine will execute without a trusted signature, but external scripts will require a signature.
Since this question continues to attract responses that are either
refuted by the question body or don't address the actual problem,
please read this simple summary of what you need to know:
This is not a "Why won't my default installation of PowerShell run scripts?" question.
This is not a "Why won't my installation of PowerShell run scripts downloaded from the internet?" question.
The question is why the RemoteSigned execution policy is preventing script execution when it shouldn't.
RemoteSigned is the only execution policy I want to use. I am aware that other, less-restrictive policies are available. If
those policies were acceptable substitutes I would have just used them
instead and this question wouldn't exist.
The execution policy is already set to RemoteSigned. Changing it from RemoteSigned to RemoteSigned is not a solution.
The script file is created and stored locally.
The script file is not blocked. The script file was never blocked (see previous point).
The script file cannot be unblocked because there is nothing to unblock (see previous point).
The script file is (attempted to be) executed by an administrator.
Windows PowerShell is the only application involved. Not Windows PowerShell ISE nor Command Prompt nor any other tools or
editors are relevant.
The cause of the problem has already been identified (see accepted answer). After nearly 8 years, I think all other obvious
explanations, whether applicable or not, have been posted, too. If
you think otherwise then please read the question and existing
answers in their entirety before adding yours.
I am using Windows PowerShell 2.0 on 64-bit Windows 7 Professional. I have a script on my Desktop that causes the following error when I try to run it:
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
I am both a domain administrator and a local administrator, and if I run Get-ExecutionPolicy -List, I can see that the Group Policy Object I created to configure PowerShell is correctly applying the RemoteSigned execution policy at the machine level:
Scope ExecutionPolicy
----- ---------------
MachinePolicy RemoteSigned
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
I created the script myself in Notepad, and used the Sysinternals' streams utility and the file Properties dialog to confirm that the script is not being treated as having come from the internet. If I copy the script to a network share on a domain server, then it's allowed to execute. If I run Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine then the local script is still not allowed to execute, which makes sense since the execution policy at the MachinePolicy scope will take precedence.
As documented by about_Execution_Policies(current; at time of question), the RemoteSigned policy means:
Scripts can run.
Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the Internet
(including e-mail and instant messaging programs).
Does not require digital signatures on scripts that you have run and that you have written on the local computer (not downloaded from
the Internet).
Risks running unsigned scripts from sources other than the Internet and signed, but malicious, scripts.
My script is not signed, but since it is both created and executed locally, it should satisfy the third bullet point above. Therefore...
Why is my script not being allowed to run?
Why does PowerShell complain that my script "is not digitally signed" when that requirement should only apply to files from the Internet?
Why does PowerShell no longer care about the script not being signed when it's run from a network share?
Some things to check:
Can you change to unrestricted?
Set-ExecutionPolicy Unrestricted
Is the group policy set?
Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell
User Configuration\Administrative Templates\Windows Components\Windows PowerShell
Also, how are you calling Script.ps1?
Does this allow it to run?
powershell.exe -executionpolicy bypass -file .\Script.ps1
Is the file being blocked? I had the same issue and was able to resolve it by right clicking the .PS1 file, Properties and choosing Unblock.
When you run a .ps1 PowerShell script you might get the message saying “.ps1 is not digitally signed. The script will not execute on the system.”
To fix it you have to run the command below to run Set-ExecutionPolicy and change the Execution Policy setting.
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
I have found out when running a PS1 file for a Mapped drive to Dropbox that I'm always getting this error. When opening up properties for the PS1 there is no "Unblock".
The only thing that work for me is
powershell.exe -executionpolicy bypass -file .\Script.ps1
I finally tracked this down to .NET Code Access Security. I have some internally-developed binary modules that are stored on and executed from a network share. To get .NET 2.0/PowerShell 2.0 to load them, I had added a URL rule to the Intranet code group to trust that directory:
PS> & "$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
Note that, depending on which versions of .NET are installed and whether it's 32- or 64-bit Windows, caspol.exe can exist in the following locations, each with their own security configuration (security.config):
$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\
After deleting group 1.2.3....
PS> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -remgroup 1.2.3.
Microsoft (R) .NET Framework CasPol 2.0.50727.9136
Copyright (c) Microsoft Corporation. All rights reserved.
The operation you are performing will alter security policy.
Are you sure you want to perform this operation? (yes/no)
yes
Removed code group from the Machine level.
Success
...I am left with the default CAS configuration and local scripts now work again. It's been a while since I've tinkered with CAS, and I'm not sure why my rule would seem to interfere with those granting FullTrust to MyComputer, but since CAS is deprecated as of .NET 4.0 (on which PowerShell 3.0 is based), I guess it's a moot point now.
If the file is copied from a network location, that is, another computer, Windows might have blocked that file. Right click on the file and click on the unblock button and see if it works.
What works for me was right-click on the .ps1 file and then properties. Click the "UNBLOCK" button. Works great fir me after spending hours trying to change the policies.
Select your terminal Command prompt instead of Power shell. That should work.
This is an IDE issue. Change the setting in the PowerShell GUI. Go to the Tools tab and select Options, and then Debugging options. Then check the box Turn off requirement for scripts to be signed. Done.
Please make a backup for the script.bs1 file
What works for me was deleting the script.bs1 file and running the execution command.
I was having the same issue and fixed it by changing the default program to open .ps1 files to PowerShell. It was set to Notepad.
Try running the Powershell GUI as Administrator
This occurs due to Powershell execution policy is set to restricted by default which prevents execution PowerShell scripts and protects from running malicious scripts.
You can change execution scope for specific scope by running the following command
Set-ExecutionPolicy -Scope Process
Run below 2 commands in PowerShell window
Set-ExecutionPolicy unrestricted
Unblock-File -Path D:\PowerShell\Script.ps1