If you’ve worked with PowerShell for any length of time, chances are you’ve come across this dreaded error:
.\SetCalendarPermissions.ps1 : File C:\ms_tmp\Scripts\SetCalendarPermissions.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
+ .\SetCalendarPermissions.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : SecurityError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnauthorizedAccess This message often appears when trying to execute a PowerShell script (.ps1 file), and it can stop even the simplest automation dead in its tracks. But what exactly does it mean? Why does it happen? And how can you fix it safely?
Why This Error Happens
This error is caused by PowerShell’s Execution Policy, a built-in security feature designed to prevent unauthorized and potentially malicious scripts from running on your system.
By default, Windows sets the execution policy to Restricted, which allows interactive commands but blocks script execution. This is especially common on:
New Windows installations
Standard user profiles (without administrative privileges)
Corporate environments where group policies enforce strict security settings
When you try to run a script in this context, PowerShell protects you by refusing to execute it.
Check Your Execution Policy
The first step in troubleshooting this issue is to check your execution policy:
Get-ExecutionPolicyTypical responses include:
Restricted– No scripts can run.AllSigned– Only signed scripts from trusted publishers can run.RemoteSigned– Local scripts can run, but downloaded scripts must be signed.Unrestricted– All scripts can run (with a warning for downloaded ones).
How to Fix the Error
There are several ways to resolve this, depending on your needs and your organization’s security policies.
1. Change the Execution Policy Temporarily
If you just need to run a single script and don’t want to change system-wide settings:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy BypassThis allows scripts to run only for the current PowerShell session. When you close the session, the restriction returns.
2. Change the Execution Policy Permanently for Your User
To adjust the policy for your user account:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -ForceThis is less intrusive than system-wide changes and is often acceptable in environments where users need to run their own scripts.
3. Change the Execution Policy Permanently for the Whole System
For administrators needing scripts to run across all accounts:
Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned -Force⚠️ Warning: This affects all users on the machine. Only use this if you understand the security implications. Administrative privileges are required to set this.
4. Run Scripts Without Changing Policy
You can also bypass the execution policy just for a single script run:
powershell.exe -ExecutionPolicy Bypass -File .\yourscript.ps1This doesn’t change any settings and avoids potential conflicts with organizational policies.
Don’t Suffocate Your Helpdesk With PowerShell
For IT admins managing Microsoft Entra ID (Azure AD) and Exchange Online (EXO), dealing with PowerShell scripts is often part of the job.
Typical tasks involve automated user onboarding and offboarding. Even (what should be) simple tasks like configuring Outlook auto-mapping, calendar delegation, or mailbox localization require PowerShell.
This is exactly where EasyEntra saves the day:
Instead of having your first-line support wrestling with PowerShell and worrying about execution policies, EasyEntra gives you:
✅ A modern UI for all the common Entra ID and EXO tasks.
✅ No need for PowerShell scripting or elevated system privileges to manage users and mailboxes.
✅ Faster ticket resolution – even by junior IT staff.
✅ Protect costly senior IT resources from first-level support tasks.
In environments where strict execution policies block scripts, EasyEntra eliminates the need to modify them at all. EasyEntra is a safe, compliant, and user-friendly alternative to using PowerShell for ad-hoc first-line support.
“One of the best products I’ve used.” – CIO, Mirick Law, United States
“We really love working with EasyEntra.” – Head of IT, IKN GmbH, Germany
“EasyEntra has significantly streamlined our workflow, simplifying everything. It feels almost like a revolution.” – IT Manager, Arjeplog Kommun, Sweden
Final Thoughts
The “running scripts is disabled on this system” error can be frustrating, but it’s simply PowerShell’s way of protecting your system. With the right approach, you can work around it safely – or better yet, avoid the need for scripts entirely with tools like EasyEntra.
