I am trying to run a cmd file that calls a PowerShell script from cmd.exe, but I am getting this error:
Management_Install.ps1 cannot be loaded because the execution of scripts is disabled on this system.
I ran this command:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
When I run Get-ExecutionPolicy from PowerShell, it returns Unrestricted.
Get-ExecutionPolicy
Output:
Unrestricted
cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"
powershell .\Management_Install.ps1 1
WARNING: Running x86 PowerShell...
File C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts\Management_Install.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.
At line:1 char:25
.\Management_Install.ps1 <<<< 1
CategoryInfo : NotSpecified: (:) [], PSSecurityException
FullyQualifiedErrorId : RuntimeException
C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts> PAUSE
Press any key to continue . . .
The system is Windows Server 2008 R2.
What am I doing wrong?
If you're using Windows Server 2008 R2 then there is an x64 and x86 version of PowerShell both of which have to have their execution policies set. Did you set the execution policy on both hosts?
As an Administrator, you can set the execution policy by typing this into your PowerShell window:
Set-ExecutionPolicy RemoteSigned
For more information, see Using the Set-ExecutionPolicy Cmdlet.
When you are done, you can set the policy back to its default value with:
Set-ExecutionPolicy Restricted
You may see an error:
Access to the registry key
'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' is denied.
To change the execution policy for the default (LocalMachine) scope,
start Windows PowerShell with the "Run as administrator" option.
To change the execution policy for the current user,
run "Set-ExecutionPolicy -Scope CurrentUser".
So you may need to run the command like this (as seen in comments):
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
You can bypass this policy for a single file by adding -ExecutionPolicy Bypass when running PowerShell
powershell -ExecutionPolicy Bypass -File script.ps1
I had a similar issue and noted that the default cmd on Windows Server 2012, was running the x64 one.
For Windows 11, Windows 10, Windows 7, Windows 8, Windows Server 2008 R2 or Windows Server 2012, run the following commands as Administrator:
x86 (32 bit)
Open C:\Windows\SysWOW64\cmd.exe
Run the command powershell Set-ExecutionPolicy RemoteSigned
x64 (64 bit)
Open C:\Windows\system32\cmd.exe
Run the command powershell Set-ExecutionPolicy RemoteSigned
You can check mode using
In CMD: echo %PROCESSOR_ARCHITECTURE%
In Powershell: [Environment]::Is64BitProcess
References:
MSDN - Windows PowerShell execution policies
Windows - 32bit vs 64bit directory explanation
Most of the existing answers explain the How, but very few explain the Why. And before you go around executing code from strangers on the Internet, especially code that disables security measures, you should understand exactly what you're doing. So here's a little more detail on this problem.
From the TechNet About Execution Policies Page:
Windows PowerShell execution policies let you determine the conditions under which Windows PowerShell loads configuration files and runs scripts.
The benefits of which, as enumerated by PowerShell Basics - Execution Policy and Code Signing, are:
Control of Execution - Control the level of trust for executing scripts.
Command Highjack - Prevent injection of commands in my path.
Identity - Is the script created and signed by a developer I trust and/or a signed with a certificate from a Certificate Authority I trust.
Integrity - Scripts cannot be modified by malware or malicious user.
To check your current execution policy, you can run Get-ExecutionPolicy. But you're probably here because you want to change it.
To do so you'll run the Set-ExecutionPolicy cmdlet.
You'll have two major decisions to make when updating the execution policy.
Execution Policy Type:
Restricted† - No Script either local, remote or downloaded can be executed on the system.
AllSigned - All script that are ran require to be digitally signed.
RemoteSigned - All remote scripts (UNC) or downloaded need to be signed.
Unrestricted - No signature for any type of script is required.
Scope of new Change
LocalMachine† - The execution policy affects all users of the computer.
CurrentUser - The execution policy affects only the current user.
Process - The execution policy affects only the current Windows PowerShell process.
† = Default
For example: if you wanted to change the policy to RemoteSigned for just the CurrentUser, you'd run the following command:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Note: In order to change the Execution policy, you must be running PowerShell As Administrator.
If you are in regular mode and try to change the execution policy, you'll get the following error:
Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell' is denied. To change the execution policy for the default (LocalMachine) scope, start Windows PowerShell with the "Run as administrator" option.
If you want to tighten up the internal restrictions on your own scripts that have not been downloaded from the Internet (or at least don't contain the UNC metadata), you can force the policy to only run signed scripts. To sign your own scripts, you can follow the instructions on Scott Hanselman's article on Signing PowerShell Scripts.
Note: Most people are likely to get this error whenever they open PowerShell because the first thing PowerShell tries to do when it launches is execute your user profile script that sets up your environment however you like it.
The file is typically located in:
%UserProfile%\My Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1
You can find the exact location by running the PowerShell variable
$profile
If there's nothing that you care about in the profile, and don't want to fuss with your security settings, you can just delete it and PowerShell won't find anything that it cannot execute.
We can get the status of current ExecutionPolicy by the command below:
Get-ExecutionPolicy
By default it is Restricted. To allow the execution of PowerShell scripts we need to set this ExecutionPolicy either as Unrestricted or Bypass.
We can set the policy for Current User as Bypass by using any of the below PowerShell commands:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted -Force
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass -Force
Unrestricted policy loads all configuration files and runs all scripts. If you run an unsigned script that was downloaded from the Internet, you are prompted for permission before it runs.
Whereas in Bypass policy, nothing is blocked and there are no warnings or prompts during script execution. Bypass ExecutionPolicy is more relaxed than Unrestricted.
Also running this command before the script also solves the issue:
Set-ExecutionPolicy Unrestricted
If you are in an environment where you are not an administrator, you can set the Execution Policy just for you (CurrentUser), and it will not require administrator.
You can set it to RemoteSigned:
Set-ExecutionPolicy -Scope "CurrentUser" -ExecutionPolicy "RemoteSigned"
or Unrestricted:
Set-ExecutionPolicy -Scope "CurrentUser" -ExecutionPolicy "Unrestricted"
You can read all about Getting and Setting Execution policy in the help entries:
Help Get-ExecutionPolicy -Full
Help Set-ExecutionPolicy -Full
In Windows 7:
Go to Start Menu and search for "Windows PowerShell ISE".
Right click the x86 version and choose "Run as administrator".
In the top part, paste Set-ExecutionPolicy RemoteSigned; run the script. Choose "Yes".
Repeat these steps for the 64-bit version of Powershell ISE too (the non x86 version).
I'm just clarifying the steps that #Chad Miller hinted at. Thanks Chad!
RemoteSigned: all scripts you created yourself will be run, and all scripts downloaded from the Internet will need to be signed by a trusted publisher.
OK, change the policy by simply typing:
Set-ExecutionPolicy RemoteSigned
I'm using Windows 10 and was unable to run any command. The only command that gave me some clues was this:
[x64]
Open C:\Windows\SysWOW64\cmd.exe [as administrator]
Run the command> powershell Set-ExecutionPolicy Unrestricted
But this didn't work. It was limited. Probably new security policies for Windows10. I had this error:
Set-ExecutionPolicy: Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of...
So I found another way (solution):
Open Run Command/Console (Win + R)
Type: gpedit.msc (Group Policy Editor)
Browse to Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Powershell.
Enable "Turn on Script Execution"
Set the policy as needed. I set mine to "Allow all scripts".
Now open PowerShell and enjoy ;)
First, you need to open the PowerShell window and run this command.
set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Then it will ask you to confirm. Type Y and press Enter.
When you run this command, you can see that your system has set all policies for the current user as remotely. It will take a few seconds to complete this process.
The image will be shown like below:
To check if the execution policy has set. Type:
Get-ExecutionPolicy
If it was set, the output would be like this:
Open a Windows PowerShell command window and run the below query to change ExecutionPolicy:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
If it asks for confirming changes, press Y and hit Enter.
You should run this command:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted
Win + R and type copy paste command and press OK:
powershell Set-ExecutionPolicy -Scope "CurrentUser" -ExecutionPolicy "RemoteSigned"
And execute your script.
Then revert changes like:
powershell Set-ExecutionPolicy -Scope "CurrentUser" -ExecutionPolicy "AllSigned"
Open the command prompt in Windows.
If the problem is only with PowerShell, use the following command:
powershell Set-ExecutionPolicy -Scope "CurrentUser" -ExecutionPolicy "RemoteSigned"
Setting the execution policy is environment-specific. If you are trying to execute a script from the running x86 ISE you have to use the x86 PowerShell to set the execution policy. Likewise, if you are running the 64-bit ISE you have to set the policy with the 64-bit PowerShell.
you may try this and select "All" Option
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
Open Run Command/Console ( Win + R )
Type: gpedit. msc (Group Policy Editor)
Browse to Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Powershell.
Enable "Turn on Script Execution"
Set the policy as needed. I set mine to "Allow all scripts".
Now run the run command what ever you are using.. Trust this the app will runs.. Enjoy :)
You can also bypass this by using the following command:
powershell Get-Content .\test.ps1 | Invoke-Expression
You can also read this article by Scott Sutherland that explains 15 different ways to bypass the PowerShell Set-ExecutionPolicy if you don't have administrator privileges:
15 Ways to Bypass the PowerShell Execution Policy
I have also faced a similar issue. Try this.
As I'm using Windows, I followed the steps as given below.
Open a command prompt as an administrator and then go to this path:
C:\Users\%username%\AppData\Roaming\npm\
Look for the file ng.ps1 in this folder (directory)
and then delete it (del ng.ps1).
You can also clear npm cache after this though it should work without this step as well.
If you have Git installed, just use Git Bash.
Set-ExecutionPolicy RemoteSigned
Executing this command in administrator mode in PowerShell will solve the problem.
In Window 10:
If you are not administrator, you can use this:
powershell Set-ExecutionPolicy -Scope CurrentUser
cmdlet Set-ExecutionPolicy at command pipeline position 1
Supply values for the following parameters:
ExecutionPolicy: `RemoteSigned`
It solved my problem like a charm!
In the PowerShell ISE editor I found running the following line first allowed scripts.
Set-ExecutionPolicy RemoteSigned -Scope Process
For Windows 11...
It is indeed very easy. Just open the settings application.
Navigate to Privacy and Security:
Click on For Developers and scroll to the bottom and find the PowerShell option under which check the checkbox stating "Change the execution policy ... remote scripts".
Open PowerShell as Administrator and run Set-ExecutionPolicy -Scope CurrentUser
Provide RemoteSigned and press Enter
Run Set-ExecutionPolicy -Scope CurrentUser
Provide Unrestricted and press Enter
Open PowerShell as a administrator. Run the following command
Set-ExecutionPolicy RemoteSigned
Type Y when asked!
In Windows 10, enable the option under the name: 'Install apps from any source, including loose files.'
It fixed the issue for me.
To fix this issue, we have to set the execution policy, so that the PowerShell script runs on the particular machine. Here is how:
Open PowerShell Console by selecting “Run as Administrator” and set the execution Policy with the command: Set-ExecutionPolicy RemoteSigned
Type “Y” when prompted to proceed
credits:
https://www.sharepointdiary.com/2014/03/fix-for-powershell-script-cannot-be-loaded-because-running-scripts-is-disabled-on-this-system.html
In PowerShell 2.0, the execution policy was set to disabled by default.
From then on, the PowerShell team has made a lot of improvements, and they are confident that users will not break things much while running scripts. So from PowerShell 4.0 onward, it is enabled by default.
In your case, type Set-ExecutionPolicy RemoteSigned from the PowerShell console and say yes.
I'm trying to create a wcf service in a lab using vsts.
I have created a build definition that works using a msbuild task. It then uses robocopy to copy the relevant dlls to a remote directory inside a lab using the Publish Artifacts step.
However, I need the content to be created as a windows service, and started after it has been published. It seems like something is running since I see a created log file about 9 minutes after a successful publish, but i cannot see my service inside the services menu, or in IIS.
When I try to run a bat script (using the run script step) that does an sc create, I get an access denied error even though on the vsts build definition I have given the step permission to modify the environment.
This is the full error:
2018-05-17T13:00:13.7702615Z ##[section]Starting: Run script GloBill/InstallBackEnd.bat
2018-05-17T13:00:13.7705444Z ==============================================================================
2018-05-17T13:00:13.7705561Z Task : Batch Script
2018-05-17T13:00:13.7705655Z Description : Run a windows cmd or bat script and optionally allow it to change the environment
2018-05-17T13:00:13.7705748Z Version : 1.1.3
2018-05-17T13:00:13.7705824Z Author : Microsoft Corporation
2018-05-17T13:00:13.7705924Z Help : [More Information](https://go.microsoft.com/fwlink/?LinkID=613733)
2018-05-17T13:00:13.7706023Z ==============================================================================
2018-05-17T13:00:13.7775377Z ##[command]C:\agent\_work\1\s\GloBill\InstallBackEnd.bat
2018-05-17T13:00:13.8030595Z
2018-05-17T13:00:13.8031049Z C:\agent\_work\1\s>sc create GloBillBackEnd ../Services/GloBill.WS.exe
2018-05-17T13:00:13.8048684Z [SC] OpenSCManager FAILED 5:
2018-05-17T13:00:13.8048781Z
2018-05-17T13:00:13.8048901Z Access is denied.
2018-05-17T13:00:13.8048957Z
2018-05-17T13:00:13.8064609Z ##[error]Process completed with exit code 5.
2018-05-17T13:00:13.8073202Z ##[section]Finishing: Run script GloBill/InstallBackEnd.bat
I'm running out of ideas.
The problem was that I was trying to deploy a release from a hosted agent that resided on another machine.
I had to configure a new agent solely for deploying, then i had to tweak my installation script a little by adding the -executionpolicy bypass command.
Here is the new script:
(%1 is the file path)
Powershell.exe -executionpolicy bypass -File %1 -username Username -password ****** -exepath *exe* -serviceName *svcName*
I have an Azure SQL database which I want to delete. The command should be:
Remove-AzureRmSqlDatabase -ResourceGroupName $dbResourceGroup -ServerName $dbServerName -DatabaseName $dbToDelete -Whatif -Force
The error I keep getting back is
Remove-AzureRmSqlDatabase : Run Login-AzureRmAccount to login.
I tried running Login-AzureRmAccount as myself, then as a service principal I use for unattended scripts, and nothing worked.
I am able to log into the Azure RM portal and delete databases. I am also able to run Invoke-SqlCmd against this database to query and manipulate data.
How can I make this work?
According to this error message, it seems that you have not login Azure whit the right subscription.
We can use this command to get the sql database's information, and check the subscription.
(Get-AzureRmSqlDatabase -DatabaseName jasontest1 -ServerName jasontest -ResourceGroupName jasontest).resourceid
Then we can find the subscription in the powershell output.
PS C:\Users> (Get-AzureRmSqlDatabase -DatabaseName jasontest1 -ServerName jasontest -ResourceGroupName jasontest).resourceid
/subscriptions/5384xxxx-xxxx-xxxx-xxxx-xxxxe29axxxx/resourceGroups/jasontest/providers/Microsoft.Sql/servers/jasontest/databases/jasontest1
To find which subscription, we can use this command Get-AzureRmSubscription to list it:
PS C:\Users> Get-AzureRmSubscription
Name : Visual Studio Ultimate with MSDN
Id : 5384xxxx-xxxx-xxxx-xxxx-xxxxe29axxxx
TenantId : 1fcfxxx-xxxx-xxxx-xxxx9-xxxx8bf8xxxx
State : Enabled
Also we can use this command to select the subscription:
Get-AzureRmSubscription -SubscriptionId 5384xxxx-xxxx-xxxx-xxx-xxxxe29axxxx
My Powershell Azure modules had dependency errors for something. To fix it I (at the behest of Microsoft tech support) ran:
PS C:\> Install-Module AzureRM -Force
This re-installed it and fixed the dependency problems.
Background:
I had installed Azure-PowerShell 1.x via the MSI, and subsequently added some Azure Resource Management modules via the command prompt.
Everything was working fine; then yesterday afternoon the ISE inexplicably disappeared. In an attempt to remedy that, I planned to uninstall the MSI & then reinstall. (I did not know that it is necessary to first unstall the manually-added modules.)
The uninstall appeared to run fine, but it didn't remove the manually-installed modules nor did it warn me about them.
Result: The machine no longer has Azure-PowerShell installed. I cannot Install, Uninstall or Repair the installation because some modules remain:
Azure Modules from the PowerShell Gallery are installed on this
machine. Please remove these modules before installing this MSI.
Is there a way to "fix" this installation? Either manually remove files/cleanup registry, or force the MSI to install over whatever is there?
This is all running on a VM on Azure. I could delete the entire VM & start from scratch if necessary, but would prefer to avoid that if there's a relatively simple fix.
Thanks!
Okay so I tried the above items to remove windows powershell and found that actually it doesn't fully remove powershell.
This is at least on windows 7 it doesn't seem to properly.
If you run uninstall-module Azure or Uninstall-Module AzureRM it will uninstall something, looks like the base module I think.
Then if you do:
Get-Module AzureRM -ListAvailable
it will come back with nothing.
So its done right?
No not really.
If you then do:
Get-Module -ListAvailable AzureRM*
you will find any number of sub modules still sitting there. (For some reason wildcards work with Get-Module but not with Uninstall-Module)
Okay so but then just do Uninstall-Module AzureRm* right?
No not really
Depending on your powershell version (Or maybe not, I'm not sure)
Install-Module just complains that you can't use wildcards in the Uninstall-Module command. (God knows why what's the point of wildcards if not for this?, but then this is windows so I just had to suck it up).
And if you take a look in %System-root%\Program Files\windowspowershell\modules you will still see the modules there.
Why is this? I'm not sure but this is what I had to do to cleanup all the old versions and newer versions of Azure powershell that I had to get back to a clean slate.
So to solve the problem of lack of wildcard support I just used a foreach loop as such:
foreach ($module in (Get-Module -ListAvailable AzureRM*).Name |Get-Unique) {
write-host "Removing Module $module"
Uninstall-module $module
}
Be warned Don't try to run this as Visual Studio code or visual studio for that matter, as depending on your lock you may get errors as it tends to pre-load the modules and lock things open. Put it in a file named Removeold-AzureRM.ps1 and run it from a powershell console window like this:
.\Remove-AzureRM.ps1
Also Make sure to close down Visual Studio Code and Visual studio before attempting it or you may still get a similar error message.
If you run this after you already uninstalled AzureRM you will find that things stop working and you only have one last resort.
Delete all the AzureRM modules in %System-root%\Program Files\windowspowershell\modules
Edit I have re-tested this and the code above still seems to work if you have azurerm 5.0.1 installed and you already removed azurerm so I could be wrong about other versions as well
Now you will at this point for sure have this sorted and you can now reinstall Azure powershell with Install-Module AzureRM.
If you made the mistake of nuking powershellget like me by accident, don't bother trying to reinstall it with WMF 5.1 or 5.0 as that will install fine but you still won't have powershellget, why I'm not sure and again this is windows so lets just suck it up.
Okay so how to fix it then?
Your only recourse is to download the release of powershellget
And and copy the PowerShellGet-1.5.0.0\PowerShellGet to your modules folder.
Then Install-Module will work again.
Yeah I know we are all saying isn't it just safer to re-install?
Yes likely but for those of you like me where that was not an option for one reason or another the above is your best bet. I hope this helps someone as this took me at least 3 days to sort out why I kept getting older modules executing when I was sure I had already removed everything.
To go faster, you can uninstall in parallel:
workflow Uninstall-AzureModules
{
$Modules = (Get-Module -ListAvailable Azure*).Name |Get-Unique
Foreach -parallel ($Module in $Modules)
{
Write-Output ("Uninstalling: $Module")
Uninstall-Module $Module -Force
}
}
Uninstall-AzureModules
Uninstall-AzureModules #second invocation to truly remove everything
It's just a Dev VM. I nuked it and started over. Lesson learned: Uninstall PowerShell Gallery components before uninstalling the MSI.
Try uninstalling the modules via MSI (first) and then cmdline:
# Uninstall the AzureRM component modules
Uninstall-AzureRM
# Uninstall AzureRM module
Uninstall-Module AzureRM
# Uninstall the Azure module
Uninstall-Module Azure
# Or, you can nuke all Azure* modules
# Uninstall-Module Azure* -Force
Reboot the machine after that and then install again via WebPI/MSI. https://azure.microsoft.com/en-us/blog/azps-1-0/
I created this variation on #BlueSky answer to keep one specific version and its dependencies:
workflow Uninstall-AzureModules
{
$skip = Find-Module AzureRM -RequiredVersion 2.1.0
$dependencies = $skip.Dependencies | %{ Get-Module -FullyQualifiedName #{ ModuleName=$_["Name"]; RequiredVersion=$_["RequiredVersion"] } -ListAvailable }
$modules = Get-Module azurerm* -ListAvailable |
where { $_.Version -ne '2.1.0' } |
where { -Not(Compare-Object $dependencies $_ -IncludeEqual -ExcludeDifferent) }
foreach -parallel ($module in $modules)
{
Write-Output ("Uninstalling: $($module.Name) $($module.Version)")
Uninstall-Module -Name $module.Name -RequiredVersion $module.Version -Force -ea SilentlyContinue
}
}
I found the command Get-InstalledModule works better for me for discovering my installed modules.
My latest script looks like this:
# If installed, remove the old AzureRm module
$allModules = Get-InstalledModule
foreach ($module in $allModules)
{
if ($module.Name -match "AzureRM.*")
{
Write-Host "Removing $($module.Name)..."
Uninstall-Module -Name $module.Name -Force -AllVersions
}
}
# If not installed, install the new Az module
$azModule = Get-InstalledModule -Name Az
if (!$azModule)
{
Install-Module -Name Az -Scope CurrentUser -AllowClobber -Force
}
# Enable AzureRm aliases for script compat
Enable-AzureRmAlias -Scope LocalMachine
This did not work in my case. I am on Powershell v7.02 MACOS v10.15.6. What did work was this code:
Function Uninstall-AzureModules
{
$Modules = (Get-Module -ListAvailable Azure*).Name |Get-Unique
Foreach ($Module in $Modules)
{
Write-Output ("Uninstalling: $Module")
Uninstall-Module $Module -Force
}
}
Uninstall-AzureModules
Uninstall-AzureModules
I them verified the AzureRM modules as gone with:
Get-InstalledModule -Name AzureRM*