C# Process start powershell and execute command, doesn't have admin permission

First of all, the commands that i want to execute are get-vm and start-vm, which are need admin permission.
In my app , i will check the hyper-v vm state to see it Running or Off. thus , i need to invoke get-vm {vmName} the get the state. after got the vm state , if the state is Off, then i will invoke start-vm {vmName} to start the vm.

secondly, i use Process to start PowerShell with UserName and Password.
the code is below:

        var tmp = CShortPath.GetShortPath(System.IO.Path.Combine(System.IO.Path.GetTempPath(), System.IO.Path.GetRandomFileName()));

        var processInfo = new ProcessStartInfo
        {
            Verb = "runas",
            LoadUserProfile = true,
            CreateNoWindow = true,

            FileName = "powershell.exe",
            //Arguments = "Start-VM -name 'win11-Lite'",
            Arguments = $"get-VM 'win11-Lite' >{tmp}",
            RedirectStandardOutput = false,
            UseShellExecute = false,
            UserName = "{AdminUserName}",
            Password = MakePwd("AdminPwd")

        };
        Process.Start(processInfo);

as you see, when executed , the output file {tmp} is empty, and there will not display UAC Permission dialog.
what should do ?

First of all, you need to check the powershell commands/scripts first.

Then you need to know that the admin permissions are not mandatory to control vms. You can grant any user or group the required rights to control vms.

Then you can redirect the standard output instead of using an intermediate file (Microsoft sample below):

      p.StartInfo.UseShellExecute = false;  
      p.StartInfo.RedirectStandardOutput = true;  
      p.StartInfo.FileName = "Write500Lines.exe";  
      p.Start();  

      // To avoid deadlocks, always read the output stream first and then wait.  
      string output = p.StandardOutput.ReadToEnd();  
      p.WaitForExit();

Note:

• If the intent behind the unsupported attempt to supply credentials programmatically via .UserName and .Password in combination with creating an elevated process (.Verb = "RunAs") is to bypass UAC, i.e. to avoid an interactive confirmation/authorization prompt, this fundamentally won't work, for security reasons.¹

• Launching an elevated process may not even be necessary if you have the option to modify permissions to also allow non-administrators to control Hyper-V VMs - see rotabor's answer.

When using a ProcessStartInfo instance to launch a process:

• .Verb = "RunAs" (starting a process with elevation (elevated privileges, as administrator) requires .UseShellExecute = true
• However, .UseShellExecute = true cannot be combined with .UserName and .Password

This means:

• You can only launch an elevated process (.Verb = "RunAs", combined with .UseShellExecute = true) as the current user.

  • To launch an elevated process as a different user, you need nested processes:

    • A non-elevated helper process that you launch with the desired credentials. That is, omit .Verb = "RunAs".

    • A nested, elevated process created in the context of the non-elevated process' user identity. Since you're calling PowerShell, you can use Start-Process -Verb RunAs in your PowerShell CLI call.^[2]

• However, you will ultimately invariably get a UAC dialog.

  • That is, by design you can never bypass UAC programmatically, even if you supply an administrator's credentials.

    • Given that a SecureString instance must be used to supply the password (.Password) programmatically and given the limited security this type provides and that its use is not recommended in new code, using password-based credentials programmatically is best avoided.

  • If you still decide to specify administrator credentials programmatically, the only thing you gain is that the unavoidable UAC prompt becomes a mere confirmation prompt rather than having to provide an administrator's (username and) password when prompted.

^{1 It is technically possible to disable UAC, but doing is strongly advised against, as it would leave your system highly vulnerable.}

^{[2] Start-Process builds on the .NET ProcessStartInfo class, so it is subject to the same fundamental limitation: -Verb RunAs cannot be combined with -Credential.}