Powershell Replacing CMD

Question

How can PowerShell replace CMD when, as a default, execution policy is restricted (which is for a good reason though), but, for example, with many commercial software systems around that require batch processing during & after installations, how is that possible with PS? For example, most software packages and games, during installations, do come and run a couple of cmd files for various tasks. If CMD goes out completely, how will powershell help in this regard, since powershell is set as restricted by default (and even opens with notepad as a default). Will powershell require users to manually set-Execution Policy to ‘signed’ or ‘unrestricted’ for every third party software been installed? Or during software installations, will a product prompt the user to manually copy and past .ps1 codes into powershell prompt to get a job done?

Answer 1

I sourced much of my answer from reading Microsoft's Powershell Execution Policy documentation.

Execution policies affect PowerShell script execution, as opposed to preventing the PowerShell terminal from executing batch files, or launching executables, etc.

Think of it as: PowerShell the shell environment has ExecutionPolicies to prevent unintended execution of code (as stated in that documentation). These ExecutionPolicies govern PowerShell scripts, but won't apply to non-PowerShell-scripts.

As .bat / .cmd files are still supported in PowerShell, software can still rely on batch files to run PowerShell commands, as referenced in Option 3 of this answer to a question on bypassing ExecutionPolicy

Answer 2

The execution policy can be overridden via the -ExecutionPolicy parameter when invoking a script

powershell.exe -ExecutionPolicy Bypass -File "C:\path\to\your.ps1"

provided that the execution policy is not defined in a local or group policy (that would take precedence over the -ExecutionPolicy parameter).

You can also define the execution policy on a per-system, per-user, or per-process basis:

# set execution policy to "Unrestricted" for the current PowerShell process
Set-ExecutionPolicy -Scope Process -Policy Unrestricted

# set execution policy to "RemoteSigned" for the currently logged-in user
Set-ExecutionPolicy -Scope CurrentUser -Policy RemoteSigned

# set execution policy to "RemoteSigned" system-wide
Set-ExecutionPolicy -Scope LocalMachine -Policy RemoteSigned

The first of the above examples affects only the current PowerShell process as long as that is running, the other two are persistent settings, i.e. they need to be set only once.

You can also define the execution policy with a local policy or group policy, either per-user (scope UserPolicy) or per-system (scope MachinePolicy).

Note that the execution policy scopes have a strict hierarchy: MachinePolicy supersedes UserPolicy supersedes Process supersedes CurrentUser supersedes LocalMachine. Meaning that a per-process execution policy can override the default LocalMachine setting, but cannot override a local/group policy-enforced setting.

You can see the currently set execution policies via Get-ExecutionPolicy -List:

PS C:\> Get-ExecutionPolicy -List

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine          Signed

My usual recommendation is to change the execution policy to RemoteSigned, either by running Set-ExecutionPolicy -Scope LocalMachine -Policy RemoteSigned during system setup, or by defining it in a per-machine local/group policy.

See here for more information.

Answer 3

I don't know why your question was downvoted, probably for the tone.

The answers already provided cover most of the ways PowerShell can function even when the default Execution Policy is Restricted.

While not specifically what you asked, being a completionist, I would add to the provided answers the following.

Even when running within a Restricted PowerShell process/scope, as long as you have the ability to run Invoke-Expression you can execute code stored in a file. It's not exactly as running scripts, as the code mustn't reference any other script while Restricted, but it's a simple way of bypassing the Execution-Policy.

Example:

The script file named Test-ExecutinoPolicyRestrictions.ps1 contains the following code:

Write-Host -ForegroundColor Green '### Nothing can stop me'

Then running the following code in a Restricted PowerShell process:

"### $(Get-ExecutionPolicy)"
### Restricted
.\Test-ExecutinoPolicyRestrictions.ps1

Will produces an error output similar to the following:

.\Test-ExecutinoPolicyRestrictions.ps1 : File <...>\Test-ExecutinoPolicyRestrictions.ps1 cannot be loaded
because running scripts is disabled on this system. For more information, see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\Test-ExecutinoPolicyRestrictions.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

However, running the following will work:

Get-Content Test-ExecutinoPolicyRestrictions.ps1 | Invoke-Expression
### Nothing can stop me