Fixing Running PowerShell Scripts on Windows Server 2008 R2

Troubleshooting PowerShell Script Execution Restrictions

When working with Windows Server 2008 R2, users might encounter an error indicating that the execution of PowerShell scripts is disabled on the system. This issue can arise when attempting to run a script via cmd.exe, even after setting the execution policy to Unrestricted.

Despite confirming that the execution policy is set to Unrestricted, scripts may still fail to execute, causing frustration and hindering progress. This guide will explore the common causes of this issue and provide steps to ensure successful script execution.

Understanding and Implementing Script Execution Policies in PowerShell

The scripts provided aim to address the issue of PowerShell script execution being disabled on Windows Server 2008 R2. The first script sets the execution policy to **Bypass** for the current PowerShell session using **Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force**. This command allows all scripts to run without restriction temporarily. The script then navigates to the directory containing the **Management_Install.ps1** script and executes it using **powershell .\Management_Install.ps1**. This approach ensures that the execution policy change is only temporary and does not affect the system's overall security posture.

The second script, a batch file, also sets the execution policy to **Bypass** but does so from the command line. It uses **powershell -Command "Set-ExecutionPolicy Bypass -Scope Process -Force"** to achieve this. After changing the execution policy, the script navigates to the script directory and runs the PowerShell script using **powershell -File .\Management_Install.ps1**. The batch script ends with a **pause** command to keep the command prompt window open, allowing the user to see any output or error messages. This method is useful for automating the process and integrating it into larger batch processes.

Script Signing and Security in PowerShell

The third script example demonstrates how to sign a PowerShell script to comply with stricter execution policies. First, a self-signed certificate is created using **New-SelfSignedCertificate**. This certificate can then be exported with **Export-Certificate** and imported into trusted certificate stores using **Import-Certificate**. By importing the certificate into the **TrustedPublisher** and **Root** stores, the system will trust scripts signed with this certificate. The script **Management_Install.ps1** is then signed using **Set-AuthenticodeSignature**.

Script signing ensures that only trusted scripts can execute on the system, providing an additional layer of security. This approach is particularly useful in environments with stringent security requirements where execution policies are set to **AllSigned** or **RemoteSigned**. By signing the script, administrators can ensure that the scripts are not tampered with and are from a trusted source, thus mitigating potential security risks. This method combines security with functionality, allowing necessary scripts to run while maintaining system integrity.

# Ensure the script execution policy is set to Bypass
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force

# Navigate to the script directory
cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"

# Execute the PowerShell script
powershell .\Management_Install.ps1

@echo off

:: Set PowerShell execution policy to Bypass
powershell -Command "Set-ExecutionPolicy Bypass -Scope Process -Force"

:: Navigate to the script directory
cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"

:: Run the PowerShell script
powershell -File .\Management_Install.ps1

pause

# Sample script content
Write-Output "Executing Management Install Script"

# Save this script as Management_Install.ps1

# To sign the script, follow these steps:
# 1. Create a self-signed certificate (if you don't have one)
$cert = New-SelfSignedCertificate -DnsName "PowerShellLocalCert" -CertStoreLocation "Cert:\LocalMachine\My"

# 2. Export the certificate to a file
Export-Certificate -Cert $cert -FilePath "C:\PowerShellLocalCert.cer"

# 3. Import the certificate to Trusted Publishers and Trusted Root Certification Authorities
Import-Certificate -FilePath "C:\PowerShellLocalCert.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPublisher"
Import-Certificate -FilePath "C:\PowerShellLocalCert.cer" -CertStoreLocation "Cert:\LocalMachine\Root"

# 4. Sign the script with the certificate
Set-AuthenticodeSignature -FilePath .\Management_Install.ps1 -Certificate $cert

Ensuring Script Execution Policy Compliance and System Security

When managing Windows Server 2008 R2, it is crucial to understand the different execution policies available in PowerShell and how they impact script execution. PowerShell execution policies are designed to prevent the execution of potentially harmful scripts. The four main policies are **Restricted**, **AllSigned**, **RemoteSigned**, and **Unrestricted**. **Restricted** is the default policy and does not allow any scripts to run. **AllSigned** requires all scripts and configuration files to be signed by a trusted publisher. **RemoteSigned** requires that all scripts and configuration files downloaded from the internet be signed by a trusted publisher, but allows locally created scripts to run without a signature.

Understanding these policies helps administrators choose the right level of security for their environment. In scenarios where scripts need to be executed regularly, setting the policy to **Unrestricted** can be risky, as it allows all scripts to run without any restrictions. Instead, administrators should consider using **RemoteSigned** or **AllSigned** to balance security with functionality. By signing scripts and managing certificates, administrators can ensure that only trusted scripts run on their systems, reducing the risk of running malicious code.