DEV Community

Cover image for Solved: Win11 powershell for hardening new laptop
Darian Vance
Darian Vance

Posted on • Originally published at wp.me

Solved: Win11 powershell for hardening new laptop

🚀 Executive Summary

TL;DR: New Windows 11 laptops often block PowerShell script execution due to the default Restricted Execution Policy. This can be resolved temporarily with Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass or permanently for your user with Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned (as administrator), unless a Group Policy Object is enforced.

🎯 Key Takeaways

  • PowerShell’s Execution Policy is a safety feature, not a security firewall, designed to prevent accidental script execution, with Restricted being the default on Windows 11 clients.
  • The Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass command provides a temporary, session-specific fix for running scripts without requiring administrator privileges.
  • For a permanent user-specific solution, Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned (run as Administrator) is recommended, allowing local scripts to run while requiring signatures for internet-downloaded scripts.
  • When Group Policy Objects (GPOs) are in effect, local Set-ExecutionPolicy changes will not persist, necessitating communication with IT to adjust policies or provide alternatives.

Hitting PowerShell’s “script execution is disabled” error on a new Windows 11 machine? Here are three real-world ways to fix the Execution Policy, from a Senior DevOps Engineer who’s been there.

So, Your New Windows 11 Laptop Won’t Run Your PowerShell Script? Let’s Talk Execution Policy.

I remember it like it was yesterday. 2 AM, a production deployment for a major client goes sideways. The fix was simple: a PowerShell script I’d written to re-sync a configuration database on a freshly provisioned VM, prod-config-db-04. I remoted in, pasted the script path, hit enter, and… saw a wall of red text. ...cannot be loaded because running scripts is disabled on this system. My heart sank. The simplest, most basic thing was blocking a critical fix. We’ve all been there, staring at a brand-new machine that refuses to run the very tools we need to do our jobs. It’s frustrating, but let’s demystify it so it never slows you down again.

The “Why”: What is Execution Policy, Really?

Before we fix it, let’s understand the root cause. PowerShell’s Execution Policy isn’t a security firewall. I need you to get that straight. It’s a safety feature, like the plastic cover over a “launch” button. It’s designed to prevent you from accidentally running scripts you didn’t intend to. On a fresh Windows client OS like Windows 11, the default policy is often Restricted, which means “don’t run any scripts, period.”

Here are the common levels you’ll encounter:

Policy What It Means
Restricted Default on Windows clients. No scripts can be run. You can only use PowerShell interactively.
AllSigned You can run scripts, but they must be digitally signed by a trusted publisher.
RemoteSigned You can run your own local scripts. Scripts downloaded from the internet must be signed by a trusted publisher. This is the sweet spot for most of us.
Unrestricted All scripts can run, but you’ll get a warning for scripts downloaded from the internet.
Bypass Nothing is blocked and no warnings are displayed. All scripts will run.

The Fixes: From a Quick Hack to the Corporate Solution

Okay, enough theory. You’ve got a script to run. Here are three ways to get it done, depending on your situation.

1. The Quick Fix: “I Just Need This to Work NOW”

This is my 2 AM, production-is-down, get-it-done method. It applies a policy that only lasts for your current PowerShell session. As soon as you close the window, it’s gone. It’s safe, temporary, and effective.

Open PowerShell and run this command:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Enter fullscreen mode Exit fullscreen mode

The key here is -Scope Process. It tells PowerShell, “Just for this window, right now, let me do what I need to do.” You don’t even need to be an administrator to run it. This is the perfect tool for running a quick hardening or setup script on a new machine without making permanent changes.

2. The Permanent Fix: “This is MY Machine”

If you’re setting up your own developer laptop, you’re going to be running scripts all day long. You need a more permanent solution. For this, we’ll set the policy just for your user account. The most balanced and secure option for this is RemoteSigned.

First, you must open PowerShell as an Administrator. Right-click the PowerShell icon and select “Run as administrator”. Then, run this command:

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
Enter fullscreen mode Exit fullscreen mode

Now, any script you write on your machine will run without issue. If you download a script from the internet, PowerShell will still protect you by requiring it to be signed (or you’ll have to explicitly unblock the file). This is the setting I use on all my personal workstations.

Pro Tip: If a downloaded script is being blocked, but you trust it, you can unblock it. In File Explorer, right-click the .ps1 file, go to Properties, and at the bottom of the General tab, you’ll see a security message. Just check the “Unblock” box and click OK.

3. The ‘Nuclear’ Option: Dealing with Corporate Handcuffs

What if you try the permanent fix, and it either doesn’t work or reverts itself after a reboot? Welcome to the enterprise, my friend. Your machine is likely being controlled by a Group Policy Object (GPO) set by your IT or Security team.

In this case, no command you run locally will stick. The GPO will always win. Your first step is to confirm this is the case. Open a regular command prompt (or PowerShell) and run:

gpresult /r
Enter fullscreen mode Exit fullscreen mode

Look for a section called “Applied Group Policy Objects”. If you see something in there that sounds like “PowerShellSecurity” or “WorkstationHardening,” you’ve found your culprit. The “fix” here isn’t a command. The fix is to have a conversation with your IT department. Explain what you’re trying to do and why. They may be able to put you in a developer group with a more lenient policy or provide an alternative, like a code-signing certificate.

Fighting a GPO is a losing battle. Working with your team is the only way forward.


Darian Vance

👉 Read the original article on TechResolve.blog


☕ Support my work

If this article helped you, you can buy me a coffee:

👉 https://buymeacoffee.com/darianvance

Top comments (0)