So you decide to use PowerShell for the first time, and when you run a PowerShell script, you get a security warning or maybe you see some error messages and then the PowerShell window disappears. Here are some simple tips for your first PowerShell experience to be a success.
Make sure you are using the latest version of PowerShell:
About Execution Policies
Open your PowerShell console
Always open it in elevated mode (If possible), with the title “Administrator: Windows PowerShell”. Then you try to execute a command, script or even import a module as in my example below.
This issue occurs because PowerShell starts with the execution of scripts disabled, obviously this happens for security reasons, after all, your environment can be seriously affected by a malicious script.
In the screen below, you can see that I ran the Get-ExecutionPolicy command and the response was Restricted
There are 5 scopes of Execution Policy, and it depends on your need, but it is important that you know how to manipulate each scope and why.
- MachinePolicy: Set by a Group Policy for all users of the computer.
- UserPolicy: Set by a Group Policy for the current user of the computer.
- Process: The Process scope only affects the current PowerShell session. The execution policy is saved in the environment variable $env:PSExecutionPolicyPreference, rather than the registry. When the PowerShell session is closed, the variable and value are deleted.
- CurrentUser: The execution policy affects only the current user. It’s stored in the HKEY_CURRENT_USER registry subkey.
- LocalMachine: The execution policy affects all users on the current computer. It’s stored in the HKEY_LOCAL_MACHINE registry subkey.
It is also important to know how to manipulate policies and which is the most suitable for your needs. I will list the policies that you can configure to use in your environment
- Scripts can run.
- Requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer.
- Prompts you before running scripts from publishers that you haven’t yet classified as trusted or untrusted.
- Risks running signed, but malicious, scripts.
- Nothing is blocked and there are no warnings or prompts.
- This execution policy is designed for configurations in which a PowerShell script is built in to a larger application or for configurations in which PowerShell is the foundation for a program that has its own security model.
- Sets the default execution policy.
- Restricted for Windows clients.
- RemoteSigned for Windows servers.
- The default execution policy for Windows server computers.
- Scripts can run.
- Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the internet which includes email and instant messaging programs.
- Doesn’t require digital signatures on scripts that are written on the local computer and 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.
- Risks running unsigned scripts from sources other than the internet and signed scripts that could be malicious.
- The default execution policy for Windows client computers.
- Permits individual commands, but does not allow scripts.
- Prevents running of all script files, including formatting and configuration files (.ps1xml), module script files (.psm1), and PowerShell profiles (.ps1).
- There is no execution policy set in the current scope.
- If the execution policy in all scopes is Undefined, the effective execution policy is Restricted for Windows clients and RemoteSigned for Windows Server.
- The default execution policy for non-Windows computers and cannot be changed.
- Unsigned scripts can run. There is a risk of running malicious scripts.
- Warns the user before running scripts and configuration files that are not from the Local intranet zone.
And finally, right after changing the execution policy in my example below to Unrestricted, it was possible to import the Azure module into the PowerShell.
Example 1: Set-ExecutionPolicy Unrestricted -force
Example 2: Set-ExecutionPolicy RemoteSigned -force
Note: The Parameter –Force is used only to prevent warnings from appearing, and then it is not necessary to make confirmations.
I do not recommend leaving the policy set to Unrestricted, this was just for example. You must adapt to your need and if it is necessary to apply the Unrestricted policy do not forget to change when you finish your task. At the beginning of the article, I also left a link to Microsoft Docs where you can learn more about the subject, I will stop here and see you later!