Microsoft deprecating use of vbs commonly used to elevate batch script, while also defaulting powershell's execution policy to restricted

So Microsoft is deprecating the use of .vbs by 2027 to elevate batch files such as this (although fully updated windows 10 and 11 machines still run it until 2027):

    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 

Article for reference:

https://techcommunity.microsoft.com/blog/windows-itpro-blog/vbscript-deprecation-timelines-and-next-steps/4148301

Their answer is to "migrate to powershell" However, Microsoft also set the default PowerShell execution policy to restricted, which means using an elevated batch file to change PowerShell executionpolicy and run a PowerShell script that performs administrative functions will also soon stop working unless you manually change the setting.

What working solution has Microsoft given that actually works to run a powershell script with administrative rights? or have any of you found a work around for this upcoming event? I'm talking about right-click "Run with powershell" or executing a powershell script on a batch of computers... simplified options to use in scripts. It feels like they they're just closing doors without providing an exit, or I need to be enlightened by something I don't know.

• In the context of a batch file (*.bat, *.cmd), you can use powershell.exe, the Windows PowerShell CLI for self-elevation (re-invocation with elevation): see this answer.

  • You can also use this technique to set PowerShell's machine-level execution policy to permit script-file execution (e.g., Set-Execution Policy -Scope LocalMachine RemoteSigned -Force; note that to set the current-user execution policy (-Scope CurrentUser), you don't need elevation); see also the bottom section.

• In the context of a PowerShell script (*.ps1):

  • In the simplest case, you can prevent non-elevated execution, by placing a
    #requires -RunAsAdministrator directive (statement) in the file.

  • Alternatively, you can create a self-elevating script, as shown in this answer.

• In the context of PowerShell remoting, which allows targeting multiple remote computers in a single operation, no extra effort is needed:

  • As long as the user account being used is an administrator in principle on a remotely targeted machine, the session is implicitly elevated: see this answer.

As an aside:

Microsoft also set the default PowerShell execution policy to Restricted

• That is true for workstation editions of Windows, whereas server editions default to the RemoteSigned execution policy.

• It is only script files and type-definition and formatting-definition files that are subject to the execution policy, whereas commands, such as ones passed to the -Command (-c) CLI parameter are generally not - except if they're from a module that is implemented in PowerShell (a module whose root module is a *.psm1 files and/or comes bundled with type-definition or formatting-definition files).

  • Aside from the option to persistently change the execution policy via Set-ExecutionPolicy, you can also set (override) it ad hoc, e.g. by passing
    -ExecutionPolicy RemoteSigned to the PowerShell CLI.

  • That said, execution policies controlled via GPOs can not be overridden this way.

  • See this answer for a comprehensive overview of PowerShell's execution policies.