You can’t run it with -Verb RunAsand-NoNewWindow. They’re different parameter sets. There’s no way to elevate within a currently-running process; you have to start it as elevated, so PS can’t escape that restriction and must also create a new window and a separate process instead.
It might be helpfull to see the full error message and to know what exactly is in $problemChild … did you try to run it with an explicitly provided computername?
Joel, noticed that when reading Start-Process. When removed the program doesn’t start on the remote machine. But I run that directly on the remote machine and it works just fine.
No need to apologize. … but I think Joel is right. Actually you have to have administrative rights to remote into another computer - so you don’t need the parameter -RunAs for “the inside” of your script block because it should already run as admin.
Gotcha. Im new to Powershell, I thought it was for Verbose face palm. I am running this as a domain admin and also included in the local computers “administrators” group. Even with launching PS console as domain admin, do I still have to run Invoke-Command with -Credential of domain admin?
I’ve done quite a bit of similar tasks and I’d like to point out a couple things here in this scenario that I’ve learned from my experience just for the sake of clarity.
As correctly stated, Invoke-Command requires local admin privileges on the remote machine to be able to connect. One thing to note is the context of the session that is created on the remote computer. In a domain environment, by default, when using Invoke-Command, the command is executed in an elevated context on the remote machine. This means that using the “-verb RunAs” in the Start-Process command is redundant, and (not 100% certain on this) could even cause a problem as it may force the process to prompt for elevation, although I think it’s unlikely as it may just be ignored since the command is already running in an elevated context.
My reference to “elevated context” has to do with UAC. Normal user context doesn’t have rights to modify the system, hence why you’d need to ‘Run As Administrator’ to install something on a machine. Again, this is redundant since execution context is automatically elevated when running a command against a remote machine with Invoke-Command.
TL;DR - The “-Verb RunAs” on Start-Process requests to run in an elevated context. Admin rights are required to execute commands on a remote machine with Invoke-Command. Invoke-Command executes commands on the remote machine in an elevated context by default (in a domain environment).
To speak to the issue, personally I’ve experienced issues with files/installers downloaded from the internet and the bit in the filestream that identifies the file as coming from the internet (right-click > properties and you’re told that the file is unsafe and you can check a box to unblock it) to Windows and UAC automatically prompts to confirm the execution of an “untrusted” application. That will cause the process to fail when executing via remoting as you can’t respond to the prompt. Windows 7 does not have the Unblock-File cmdlet, but you can simply manually unblock the file from the file properties before copying it to the remote machine to run.
May have been mildly off-topic but thought it was worth pointing out.
… but I think Joel is right. Actually you have to have administrative rights to remote into another computer - so you don’t need the parameter -RunAs for “the inside” of your script block because it should already run as admin.