Running PS script remotely as admin with no user prompts?

Question

I've got some CMD commands that I need to run in PowerShell as an admin or using my admin account, with no user prompts.

I need to run them in PowerShell because the platform I'm using (defender for endpoint) to deploy the script to the user PC only accepts PowerShell, but the commands are command prompt commands.

The script is to fix a windows activation issue. So far what i have is below, however there is a confirmation box that pops up after every command asking to click OK that i need to get rid of, i also need a way of making it run as admin via the script itself as im not sure that the platform deploying the script will do so.

Invoke-Expression -Command "cmd.exe /c slmgr /upk"
Start-Sleep 3
Invoke-Expression -Command "cmd.exe /c slmgr /cpky"
Start-Sleep 3
Invoke-Expression -Command "cmd.exe /c slmgr /rearm"

I tried adding the following at the top but it hangs:

powershell.exe -NonInteractive

I also tried:

powershell.exe -NonInteractive -ea 0

this no longer hangs but the prompts still display

Is there a way of running this remotely without defender for endpoint as an intermediary?

Answer 1

I don't know if this is the only / true cause of your problem, but it definitely is a potential one:

tl;dr

Assuming that you're already running with elevation, try:

#requires -RunAsAdministrator

# Get the full file path of slmgr.vbs via $env:PATH
$slmgrFullPath = (Get-Command slmgr.vbs).Path

# Use cscript.exe to execute it as a console application:
cscript $slmgrFullPath /upk
Start-Sleep 3
cscript $slmgrFullPath /cpky
Start-Sleep 3
cscript $slmgrFullPath /rearm

See below for a simpler alternative, which, however, involves changing the default WSH host.

---

Background information:

slmgr's full file name is slmgr.vbs, i.e. it is a VBScript to be executed by WSH, the Windows Scripting Host, of which there are two:

• cscript.exe is for running scripts as console applications,
• wscript.exe is for GUI applications.

When you invoke a .vbs file directly, it is the default host that matters, which is wscript.exe by default.

If a script that was designed to be invoked with cscript.exe is invoked with wscript.exe instead, each of its WScript.Echo calls turns into a GUI message box instead of printing to the console. This is what seems to be happening in your case.

If you don't want to rely on the default, use either cscript.exe or wscript.exe explicitly, as needed, but you must then specify the file path of the .vbs file as an argument - just the file name - even though it is discoverable via $env:PATH in the case of slmgr.vbs - is then not enough.

This is the approach demonstrated above, which uses Get-Command to determine slgmr.vbs' full path and passes that to cscript.exe.

However, there is an alternative: If acceptable, you can change the default:
cscript //H:CScript makes cscript.exe the default host, so that invoking slmgr (or slmgr.vbs) alone is then enough.
Note that changing the default host itself requires elevation (running as administrator) too.

Applied to your case:

#requires -RunAsAdministrator

# Make cscript.exe the default WSH host.
cscript //H:CScript

# Now you can call `slmgr` directly, and it will act
# like a console application
# Use cscript.exe to execute it as a console application:
slmgr /upk
Start-Sleep 3
slmgr /cpky
Start-Sleep 3
slmgr /rearm