I ran across this when many of the above answers were at one time working and then suddenly stopped and felt there was a need here to help understand why. This change was caused by a Microsoft security update. Using -ExecutionPolicy bypass "anything" within a script actually gives a PowerShell error indicating scripts are disabled and it cannot run. You have to run your powershell with -noexit or within the Windows PowerShell ISE utility to see it.

Now correct me if I'm wrong please, but as I understand it, the reason for this is an update from Microsoft that changed the default security settings for PowerShell to be defaulted as Restricted in the default LocalMachine, which takes precedence, and not allow scripts to elevate themselves with -ExecutionPolicy bypass "anything"... you now must now set the execution policy prior to running the script, such as in an elevated .bat file that can set the execution policy and then also call the powershell script, and that's IF it's NOT completely blocked by a group policy setting.

Read more here: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.5&viewFallbackFrom=powershell-7.1

and also read more here:

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.5&viewFallbackFrom=powershell-7.1

So while you CAN preemptively change the execution policy (although not recommended to set as unrestricted), the change in security defaults that Microsoft has set into play are for a good reason, so I would stick with the answer by @TechyMac and @DTM gave but mixed together. For security reasons the answer from @DTM is actually partially better practice as it only changes it while that one script runs with "-scope process", then goes back to normal defaults. I would upvote their answers, but I have a level 13 profile, and upvoting requires a level 15.

Also keep in mind that any external scripts from the internet or a usb drive will be considered Blocked. Use the Unblock-File cmdlet to unblock the scripts so that you can run them in PowerShell.

In my findings for best security practices, you don't want to change the default execution policy for a workstation to "unrestricted" or completely bypass it when you're just running a one-off script, change it only for your script that one time to RemoteSigned. Remote signed allows "local" scripts to run and also remote signed. "Local" includes mapped drives or UNC paths if a computer is part of the same domain, and scripts stored locally on the %systemdrive%.

Start with (PowerShell set-executionpolicy -executionpolicy remotesigned -scope process) from an elevated command prompt or batch script that way you're not lowering the security level of a pc and end up allowing users to run scripts that can potentially cause havoc:

Here's an example of a .bat file that can do this:

`:::::::::::::::::::::::::::::::::::::::::

:: Automatically check & get admin rights :::::::::::::::::::::::::::::::::::::::::

ECHO Running Admin shell :checkPrivileges NET FILE 1>NUL 2>NUL if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges )

:getPrivileges if '%1'=='ELEV' (shift & goto gotPrivileges)
ECHO. ECHO ************************************** ECHO Invoking UAC for Privilege Escalation ECHO **************************************

setlocal DisableDelayedExpansion set "batchPath=%~0" setlocal EnableDelayedExpansion ECHO Set UAC = CreateObject^("Shell.Application"^) > %temp%\OEgetPrivileges.vbs" ECHO UAC.ShellExecute "!batchPath!", "ELEV", "", "runas", 1 >> "%temp%\OEgetPrivileges.vbs" "%temp%\OEgetPrivileges.vbs" exit /B

:gotPrivileges ::::::::::::::::::::::::::::

::Change Powershell execution policy prior to running a script

powershell -Command "Set-ExecutionPolicy RemoteSigned

::call said script now that policy will allow it to run

powershell -noexit "& ""C:\my_path\yada_yada\run_import_script.ps1"""

::end of batch file `

Reference: How to run a PowerShell script