Multiple Commands In Succession (Involving Keystrokes) .ps1 .bat

I’m currectly creating a set of .bat, .reg, .ps1 scripts to ease initial configurations when installing a fresh copy of Windows.

I’m having trouble executing multiple commands in succession in PowerShell.

Below is what I’m trying to achieve within a .ps1-file:

start-process powershell -verb runas

Elevated PowerShell opens.

Then I want to perform the following within that newly opened elevated window:

net user administrator /active:yes

net user “administrator” *

{enter}

{enter}

shutdown /l

 

I have tried -argumentlist and -parameter but I am really clueless.

The latter command changes password, hence two keystrokes needed to leave input fields blank.

I know I might not of posted within your forum guidelines, but I’m posting this from an Android device.

I appreciate your knowledge!

These are interactive user keyboard commands. You cannot do this they way you are asking.
You must create a .ps1 and then use …
To do that keyboard stuff, you’ll need to use sendkeys.

If you are already in PowerShell, which you have to be to do this…

start-process powershell -verb runas

Why are you starting PowerShell to call PowerShell, that you can already do in the PowerShell session you are already in.

If you are saying you are not running as admin when you start a PowerShell instance, that makes sense.

Still, you cannot pass interactive user commands…

{enter}

{enter}

… the way you are trying. You can only do that by writing sendkeys code. You need a script to do that.

Start-Process -FilePath PowerShell -ArgumentList 'PathToScriptFile' -Verb RunAs

# In your script file
net user administrator /active:yes
net user "administrator" *

# Send key strokes
[system.reflection.assembly]::loadwithpartialname("System.Windows.Forms")
[System.Windows.Forms.SendKeys]::Sendwait('{enter}{enter}')

shutdown /l

Wow, that’s a ridiculous strange and long command to perform such a simple instruction.

Why would someone invent "Power"Shell when it basically makes no common sense?

I’m sorry, coding and scripting is totally new to me, but those instructions you posted are not logical to what I’m trying to achieve.

I appreciate your help and supplying me with instructions on how to proceed, but I actually ended up just creating three different CMD-shortcuts, targeting my commands.

I found this to be alot easier and with less hassle than using PowerShell.

To answer your questions, I need to elevate PowerShell to perform the net user-commands, otherwise I would not open another instance of PowerShell.

By judging your instructions, it seems like I need to target a scriptfile, this seems rather weak in terms of PowerShell-capabilities.

With CMD, all I need to do is create a batch file and execute a rather unlimited amount of commands.

I’m in no place to tell whats right or wrong, but commands needs to stay logical for one to remember and keep using them, at least for me.

 

How about if I skip the SendKeys requirement and just want the net user-commands to be followed up by each other and input in the elevated PowerShell instance?

Would the input prompts from net user “administrator” * break the script process?

Thanks!

 

Edit: Typos

Things are only complicated when you first come to them.

As one that has been in IT as a Dev, Eng, architect, etc., I have had to deal with everything from mainframe, to mini, to PC, to mobile and cloud. AS well as assembler, bash, batch, wmic, vbscript, python, Perl, etc. Many things I see may or may not make since, but they are what they are.

My philosophy, is never dive in to anything you have not spent time researching / ramping up on, because all you will do is lead yourself to confusion and frustration. There is a great deal of stuff to PowerShell, but you have to be willing to commit to it.

Automation, and user interactive / UI coding are seriously different things, though you can use them together.

Yet, only you can decide what works for you. We all here love PS, which is why we are here. Yet, PS is not always the right answer to everything.

Use, whatever you like, and does the job, but don’t ever expect one language (full or scripting) to be / act like the other. If that were the case, we’d all still be programming in Assembler, JCL, Fortran, Cobol, etc.

My Computer Eg professor always said, if you are not use to or can’t handle change, don’t go into IT. ;-}

This whole sendkeys thing is not a PS thing at all, but it can use it.
Sendkeys is from the VBScript days, and the approach in PS for sendkeys is the same with using WSHScript COM, or .Net as I’ve shown.

https://social.technet.microsoft.com/wiki/contents/articles/5169.vbscript-sendkeys-method.aspx

As for this…

By judging your instructions, it seems like I need to target a scriptfile, this seems rather weak in terms of PowerShell-capabilities.

You cannot pass user interactive commands as command line switches in virtually any language, without writing a script. .bat, .cmd, .vbs, .ps1, etc…

Which is all you did, when you said this…

With CMD, all I need to do is create a batch file and execute a rather unlimited amount of commands.

There has been no improvements to cmd.exe stuff since DOSv6+ days, and never will be. Yet, if that is your thing, them that’s cool.

You can do the same in PS, if you are willing to learn how. Virtually anything you can do on .bat/.cmd, you can do with PS, and there are things you can do with PS that you’d never be able to do with .bat /.cmd. Yet, again, use what works for your use case.

There are tons for no cost eBooks and video training in the free resource section of this site or stuff discussed / shown here: Reddit - Dive into anything), that can be used to get your head around this.

If you are really planning an IT career, especially with the MS stack, learning and master PowerShell is an absolute must. All of MS products (Exchange, SharePoint, Skype, Hyper-V, etc.) use / rely on it and when it comes to MS cloud, PowerShell or the GUI is the only options.

BTW, tons of other vendors have invested as great deal into supporting PS for there stack as well. I.e., VMWare, AWS. etc…

So, just say’in…

As for this…

How about if I skip the SendKeys requirement and just want the net user-commands to be followed up by each other and input in the elevated PowerShell instance?

… I was really unsure why you were doing that {enter} thing anyway. Yet, you had it, so I addressed out., Yet no, there was no reason, I can see by what you were doing, that you needed those, and thus no sendkeys, but you’d still need a script, just as you needed a .CMD to do this.

BTW, the Start-Process cmdlet, allows for multiple arguments to be pass in that argument list switch, see the documentation for directions.

# get function / cmdlet details
(Get-Command -Name Start-Process).Parameters
Get-help -Name Start-Process -Examples
Get-help -Name Start-Process -Full
Get-help -Name Start-Process -Online

It’s as simple as just doing something like this…

Start-Process powershell -Verb runas -ArgumentList 'cd c:\','dir'

Yet, you are not just running commands, you are running executables in a command string. Hence the need for a .CMD or .PS1 to do it.
Start-Process, will run only one shell at a time and since you are passing executables and thinking they are commands, then you do this script block approach…

Start-Process powershell.exe -ArgumentList "-NoExit","-Command  `"&{net User; nslookup}`"" -Wait

# Your use case.
Start-Process powershell.exe -ArgumentList "-NoExit","-Command  `"&{net user administrator /active:yes; net user administrator *; shutdown /l}`"" -Wait

PowerShell offer multiple ways to do things, you just have to know where and why to use X or approach.

https://social.technet.microsoft.com/wiki/contents/articles/7703.powershell-running-executables.aspx

If that executable and switches, you pass those in the argument list.

Lastly, you could have just written this as a .ps1 file, and set it to auto elevate (there are many articles on how to do this), then just run PowerShell as normal calling the script directly, just as you would call that .bat/.cmd file.

This issue has been resolved, topic can be closed.