What you’re seeing
- A red error stating that the file "cannot be loaded because running scripts is disabled on this system".
- A security warning asking whether to run a script because it came from the internet and may harm your computer.
- A message saying the file is not digitally signed and cannot run on this system.
- A script works for one person but is blocked on another user's PC or on a newly built server.
- Scripts downloaded from a vendor portal or email attachment are refused, while scripts written locally run normally.
Common causes
Every environment is different, but these are the causes our engineers find most often:
- The PowerShell execution policy is still at the Windows client default, which does not allow script files to run at all.
- A Group Policy setting enforces a stricter execution policy than the one configured on the machine itself.
- Windows marked the downloaded file with a "mark of the web" flag, so PowerShell treats it as untrusted remote content.
- The execution policy requires scripts from the internet to be signed, and the vendor's script carries no signature or an untrusted one.
- Different execution policies apply at user, machine and process level, and the most restrictive applicable one is winning.
Why it matters
Execution policy is often the first thing that stands between an office and a tool it needs, such as a vendor's setup script, a migration helper or an onboarding routine. The delay itself is costly, but the bigger risk is how people react: loosening the policy across every machine, or running unknown downloaded code with no review. Either can open a path for malicious scripts delivered by phishing. Getting the policy right means approved scripts run smoothly while untrusted downloads still face a sensible check.
How AskTechGurus fixes it
Skip the trial and error. A certified engineer works on your actual system, finds the root cause, and fixes it properly.
Tell us what’s happening
Submit a ticket in about two minutes. Paste the error, describe what changed, and pick your tier. No charge to submit.
A certified engineer diagnoses it
A vetted, US-based systems engineer claims your ticket, usually within minutes during business hours, and investigates over a secure remote session you can watch and end at any time.
Fixed and verified with you
The engineer resolves the root cause and confirms with you that it’s working. You don’t just get a workaround, and you get a plain-English summary of what was wrong.
Pay only when it’s resolved
Fixed price from $99, invoiced only after you approve the fix. If it isn’t resolved, you don’t pay.
Frequently asked questions
Is the execution policy actually a security feature?
It is a safety net rather than a hard security boundary. It helps stop people running scripts by accident, so it is worth keeping set sensibly instead of switching it off everywhere.
Is it safe to run the script a vendor sent us?
Usually, but it deserves a look before anyone allows it. An engineer can review what the script does and confirm where it came from before it is permitted to run.
Why does it work on my PC and not on the new server?
Servers and workstations often have different defaults, and Group Policy can apply different rules to each. We confirm which setting is in effect on that machine before changing anything.