For simplicity, let's say the user Administrator is logged in in terminal session 2. Another user Boda is logged in terminal session 3.
Is it possible to runas a program in session 3 from session 2?
For simplicity, let's say I want to start calc.exe in session 3 (in Boda's session). How do I do that? Can it be done with runas?
Like Harry Johnston suggested in a comment you can do this using the psexec tool available on TechNet. I've tried it using a Windows 2008 Server running Terminal Services and managed to start various applications in another users session (although not calc.exe - it started but minimized and the window refused to restore), among them cmd.exe.
The command I used was psexec.exe -i 3 cmd.exe where 3 is the session number (that you can get from qwinsta.exe).
Example: Remote session, logged on as Administrator; using qwinsta to enumerate sessions and psexec to start cmd.exe on another session.
Another session: logged on as Patrick, with the cmd.exe window on the desktop opened by Administrator (which the window title reveals too).
There is a commandline tool and it’s called RunInSession. You need to specify at least the SessionId in which you want to launch the process and which process you want to launch. Optional is servername if you want to launch on a remote server. If you run it without parameters a dialog with possible parameters is shown:
Currently supported OS versions are Windows XP, 2003, Vista and 2008.
The program needs to run in the context of the Localsystem user, therefore it temporarily installs itself as service and start itself. With the WTSQueryUserToken it obtains the Primary User token of the requested Terminal Session. Finally the process is launched with CreateProcessAsUser and the service deletes itself.
More details:
How to launch a process in a Terminal Session
Launching an interactive process from Windows Service in Windows Vista and later
Its kind of an hack, but its very useful to me. Way more faster than psexec.exe in my environment.
Just create a temporary task in a remote computer, for a specific user or group, run it, than delete the task.
I created a powershell script for it:
param (
[string]$Computer = ($env:computername),
[string]$User = "",
[string]$Command,
[string]$Args
)
$script_task =
{
param (
[string]$User = "",
[string]$Command,
[string]$Args
)
#Action
$Action = New-ScheduledTaskAction –Execute $Command
if($Args.Length > 0) { $Action = New-ScheduledTaskAction –Execute $Command -Argument $Args}
#Principal
$P = New-ScheduledTaskPrincipal -UserId $User -LogonType Interactive -ErrorAction Ignore
#Settings
$S = New-ScheduledTaskSettingsSet -MultipleInstances Parallel -Hidden
#Create TEMPTASK
$TASK = New-ScheduledTask -Action $Action -Settings $S -Principal $P
#Unregister old TEMPTASK
Unregister-ScheduledTask -TaskName 'TEMPTASK' -ErrorAction Ignore -Confirm:$false
#Register TEMPTASK
Register-ScheduledTask -InputObject $TASK -TaskPath '\KD\' -TaskName 'TEMPTASK'
#Execute TEMPTASK
Get-ScheduledTask -TaskName 'TEMPTASK' -TaskPath '\KD\' | Start-ScheduledTask
#Unregister TEMPTASK
Unregister-ScheduledTask -TaskName 'TEMPTASK' -ErrorAction Ignore -Confirm:$false
}
#The scriptblock get the same parameters of the .ps1
Invoke-Command -ComputerName $Computer -ScriptBlock $script_task -ArgumentList $User, $Command, $Args
Usage example:
file.ps1 -User USER_NAME -Command notepad.exe -Computer REMOTE_COMPUTER
I don't know of any way you can control another open cmd session. However, you should be able to use runas to run it as another user.
This can be archived using Sysinternals tools from Microsoft. Beside running lists of commands and scripts remotely, they are useful for lot of things. As admin they had been my savior on multiple occasions.
#To run a command on single computer remotly
psexec \\RemoteComputerName Path_Of_Executable_On_Remote_Computer Argument_list
#To run a command on list of computers remotely.
psexec #Remote_Computer_list Path_Of_Executable_On_Remote_Computer Argument_list /AcceptEULA
#To run list of commands on list of remote computer. make sure you copy batch file before you run command below.
psexec #Remote_Computer_List Path_Of_Batch_On_Remote_Computer Argument_list
Related
I've created a pssession on a remote computer and entered that possession. From within that session I use start-process to start notepad. I can confirm that notepad is running with the get-process command, and also with taskmgr in the remote computer. However, the GUI side of the process isn't showing. This is the sequence I've been using:
$server = New-PSSession -ComputerName myserver -Credential mycreds
Enter-PSSession $server
[$server]: PS C:\>Start-Process notepad -Wait -WindowStyle Maximized
The process is running, but while RDP'd to the box, notepad does not open. If I open notepad from the server, a new notepad process begins. I also tried by using the verb parameter like this:
[$server]: PS C:\>Start-Process notepad -Wait -WindowStyle Maximized -Verb Open
Same result tho... Process starts, but no notepad shows. I've tried this while remoted into the box (but issued from my local host) as well as before remoting into the server.
That is because your powershell session on the remote machine does not go to any visible desktop, but to an invisible system desktop. The receiving end of your powershell remote session is a Windows service. The process is started, but nor you nor anyone else can ever see it.
And if you think about it, since multiple users could RDP to the same machine, there is really no reason to assume a remote powershell session would end up showing on any of the users desktops. Actually, in almost all cases you wouldn't want it anyway.
psexec with the -i parameter is able to do what you want, but you have to specify which of the sessions (users) you want it to show up in.
I know this is old, but I came across it looking for the solution myself so I wanted to update it for future poor souls.
A native workaround for this problem is to use a scheduled task. That will use the active session
function Start-Process-Active
{
param
(
[System.Management.Automation.Runspaces.PSSession]$Session,
[string]$Executable,
[string]$Argument,
[string]$WorkingDirectory,
[string]$UserID
)
if (($Session -eq $null) -or ($Session.Availability -ne [System.Management.Automation.Runspaces.RunspaceAvailability]::Available))
{
$Session.Availability
throw [System.Exception] "Session is not availabile"
}
Invoke-Command -Session $Session -ArgumentList $Executable,$Argument,$WorkingDirectory,$UserID -ScriptBlock {
param($Executable, $Argument, $WorkingDirectory, $UserID)
$action = New-ScheduledTaskAction -Execute $Executable -Argument $Argument -WorkingDirectory $WorkingDirectory
$principal = New-ScheduledTaskPrincipal -userid $UserID
$task = New-ScheduledTask -Action $action -Principal $principal
$taskname = "_StartProcessActiveTask"
try
{
$registeredTask = Get-ScheduledTask $taskname -ErrorAction SilentlyContinue
}
catch
{
$registeredTask = $null
}
if ($registeredTask)
{
Unregister-ScheduledTask -InputObject $registeredTask -Confirm:$false
}
$registeredTask = Register-ScheduledTask $taskname -InputObject $task
Start-ScheduledTask -InputObject $registeredTask
Unregister-ScheduledTask -InputObject $registeredTask -Confirm:$false
}
}
When you use New-PSSession and then RDP into that same computer, you're actually using two separate and distinct user login sessions. Therefore, the Notepad.exe process you started in the PSSession isn't visible to your RDP session (except as another running process via Task Manager or get-process).
Once you've RDP'd into the server (after doing what you wrote in your post), start another Notepad instance from there. Then drop to PowerShell & run this: get-process -name notepad |select name,processid
Note that there are two instances, each in a different session.
Now open up Task Manager and look at the user sessions. Your RDP session will probably be listed as session 1.
Now quit Notepad and run get-process again. You'll see one instance, but for session 0. That's the one you created in your remote PSSession.
There are only 2 workarounds that I know of that can make this happen.
Create a task schedule as the logged in user, with no trigger and trigger it manually.
Create a service that starts the process with a duplicated token of the logged in user.
For the task schedule way I will say that new-scheduledtask is only available in Windows 8+. For windows 7 you need to connect to the Schedule Service to create the task like this (this example also starts the task at logon);
$sched = new-object -ComObject("Schedule.Service")
$sched.connect()
$schedpath = $sched.getFolder("\")
$domain = "myDomain"
$user="myuser"
$domuser= "${domain}\${user}"
$task = $sched.newTask(0) # 0 - reserved for future use
$task.RegistrationInfo.Description = "Start My Application"
$task.Settings.DisallowStartIfOnBatteries=$false
$task.Settings.ExecutionTimeLimit="PT0S" # there's no limit
$task.settings.priority=0 # highest
$task.Settings.IdleSettings.StopOnIdleEnd=$false
$task.settings.StopIfGoingOnBatteries=$false
$trigger=$task.Triggers.create(9) # 9 - at logon
$trigger.userid="$domuser" # at logon
$action=$task.actions.create(0) # 0 - execute a command
$action.path="C:\windows\system32\cmd.exe"
$action.arguments='/c "c:\program files\vendor\product\executable.exe"'
$action.WorkingDirectory="c:\program files\vendor\product\"
$task.principal.Id="Author"
$task.principal.UserId="$domuser"
$task.principal.LogonType=3 # 3 - run only when logged on
$task.principal.runlevel=1 # with elevated privs
# 6 - TASK_CREATE_OR_UPDATE
$schedpath.RegisterTaskDefinition("MyApplication",$viztask,6,$null,$null,$null)
Creating a service is way more complicated, so I'll only outline the calls needed to make it happen. The easy way is to use the invoke-asservice script on powershell gallery: https://www.powershellgallery.com/packages/InvokeAsSystem/1.0.0.0/Content/Invoke-AsService.ps1
Use WTSOpenServer and WTSEnumerateSessions to get the list of sessions on the machine. You also need to use WTSQuerySessionInformation on each session to get additional information like username. Remember to free your resources using WTSFreeMemory and WTSCloseServer You'll end up with some data which looks like this (this is from the qwinsta command);
SESSIONNAME USERNAME ID STATE
services 0 Disc
>rdp-tcp#2 mheath 1 Active
console 2 Conn
rdp-tcp 65536 Listen
Here's an SO post about getting this data; How do you retrieve a list of logged-in/connected users in .NET?
This is where you implement your logic to determine which session to target, do you want to display it on the Active desktop regardless of how it's being presented, over RDP or on the local console? And also what will you do if there is no one logged on? (I've setup auto logon and call a lock desktop command at logon so that a logged in user is available.)
You need to find the process id of a process that is running on the desktop as that user. You could go for explorer, but your machine might be Server Core, which explorer isn't running by default. Also not a good idea to target winlogon because it's running as system, or dwm as it's running as an unprivileged user.
The following commands need to run in a service as they require privileges that only system services have. Use OpenProcess to get the process handle, use OpenProcessToken to get the security token of the process, duplicate the token using DuplicateTokenEx then call ``CreateProcessAsUser``` and finally Close your handles.
The second half of this code is implemented in invoke-asservice powershell script.
You can also use the sysinternals tool psexec, I didn't list it as a 3rd way because it just automates the process of creating a service.
I have a script which launches an app on the VM and logs some data for the app. As Powershell script does not allow me to run the app in foreground I decided to schedule a task after 2 mins and then keep polling for the task completion.
I was using this command to register my task
$password= "password" | ConvertTo-SecureString -asPlainText -Force;
$username = "name";
$credential = New-Object System.Management.Automation.PSCredential($username,$password);
Invoke-Command -VMName INSTANCE_ID -Credential $credential -ScriptBlock
{
$gettime = (Get-Date).AddMinutes(2);
$run = $gettime.ToString('HH:mm');
$action = New-ScheduledTaskAction -Execute 'C:\logging.bat';
$trigger = New-ScheduledTaskTrigger -Once -At $run;
$principal = New-ScheduledTaskPrincipal -GroupID "BUILTIN\Administrators" -RunLevel Highest;
Register-ScheduledTask -Action $action -Trigger $trigger -Principal $principal -TaskName "ID_Logging_Task" -Description "my description"
}
It was working fine but it had a problem that it ran well only when the user was logged in. More context - https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/new-scheduledtaskprincipal?view=windowsserver2022-ps (Example 2)
So I looked at the documentation of Register-ScheduledTask and saw that I can provide username and password to the command while registering the task. So I took the username of the account with Administrator privileges and ran the new command:
$password= "password" | ConvertTo-SecureString -asPlainText -Force;
$username = "name";
$credential = New-Object System.Management.Automation.PSCredential($username,$password);
Invoke-Command -VMName INSTANCE_ID -Credential $credential -ScriptBlock
{
$gettime = (Get-Date).AddMinutes(2);
$run = $gettime.ToString('HH:mm');
$action = New-ScheduledTaskAction -Execute 'C:\logging.bat';
$trigger = New-ScheduledTaskTrigger -Once -At $run;
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "ID_Logging_Task" -RunLevel Highest -User "myUser" -Password "myPassword" -Description "my description"
}
"myUser" is an administrator on this machine. This solved the problem of running the task without manually logging in but now my app is getting launched in the background instead of foreground which was the whole point of running these scheduled tasks.
My question is what is the difference between BUILTIN\Administrators and an Administrator account. And how do I solve my problem? I want to run my task with the privilege of -GroupID "BUILTIN\Administrators" without actually logging into the machine.
Difference between the group and account
BuiltIn\Administrators is a group you can be a member of.
Administrator is a default account that comes, normally disabled, on new Windows installations.
There is a way of fixing this problem, maybe easier than it seems.
Achieving what you want
I have a script which launches an app on the VM and logs some data for the app
Let's break doing this into three pieces
Launching the VM
If you want your VM to always be running, you can set it to 'Always Start'. This option is great because it will start the VM with the host, and you can even specify a startup delay, which is great because this lessens the pressure on disk and cpu, as starting a vm will incur a spike to both those resources.
If you do this, this takes care of starting the VM.
Launching the app
For the next piece this is as simple as the syntax you already have for running a scheduled task. If you want to run as a domain account and run as an administrator, just make the domain account a member of the 'Administrators' group on the system.
Running in Foreground
Here is the wrinkle, but I don't understand why this is an issue. Scheduled Tasks will only run in the Foreground when a user is logged into the machine.
This option is there so that you can make an app appear in the user's session when they log onto a computer, for things like Kiosk apps, or Point-Of-sale systems, dashboard displays and that sort of thing.
If you set an app to run whether or not a user is logged in, then it always will run in the background.
Are you sure this matters?
Making an app run in the foreground on boot
If you want an app to run without having to login, it will run in the background.
If you really want it to run in the foreground, then just set the machine to automatically log in. If it automatically log's in, then it will login and show the desktop, and then the scheduled task can be changed to 'Run only when a user is logged in', which will make it run in the foreground.
But why would someone need an App within a VM, which is by nature headless to run in the foreground?
I'm having some trouble getting Clean Manager on Windows 10 to run remotely. I've seen a few different things were you can edit the registry and modify the /sageset or /sagerun to be specific things then run it remotely, but it seems no matter what I do the CleanMgr runs locally on my machine rather than running remotely.
I believe this is the closest I've gotten to get it to run remotely... It seems to still just run locally on my machine though.
Any ideas?
( All variables are set before this portion of the script, this is just a small portion of what's going on that I'm stuck on )
## Starts cleanmgr.exe
Function Start-CleanMGR {
Write-Host "Please provide your A-Account details to continue with this cleanup."
$creds = Get-Credential
Enter-PSSession -ComputerName $computername -Credential $creds
try {
$cleanmgr = Start-Process -Credential $creds -FilePath "C:\Windows\System32\cleanmgr.exe" -ArgumentList '/verylowdisk' -Wait -Verbose
if ($cleanmgr) {
Write-Host "Clean Manager ran successfully! " -NoNewline -ForegroundColor Green
Write-Host "[DONE]" -ForegroundColor Green -BackgroundColor Black
}
}
catch [System.Exception] {
Write-host "Cleanmgr is not installed! To use this portion of the script you must install the following windows features:" -NoNewline -ForegroundColor DarkGray
Write-host "[ERROR]" -ForegroundColor Red -BackgroundColor Black
}
} Start-CleanMGR
PowerShell always runs in the user context of the user who started the session. This is by design.
You can not run a GUI based application remotely using PowerShell. It is a Windows security boundary.
To run GUI apps, someone must be logged on, and you cannot use PowerShell to run code as the logged-on user.
You are also prompting for info, so, someone must be logged on.
If you are expecting a user to prived info, then you need to:
Create the script
Deploy the script to the user's machine or a files share from wich it
can be ran
Tell the user how to do it or create a batch file they would double
click to run the PowerShell script
Or
Set the script to run as a scheduled task at log on or at some point during the day, as the user credentials.
Variables have the scope and you cannot use local variables in a remote context unless they are scoped for that.
About Remote Variables
Using local variables
You can use local variables in remote commands, but the variable must
be defined in the local session.
Beginning in PowerShell 3.0, you can use the Using scope modifier to
identify a local variable in a remote command.
The syntax of Using is as follows:
$Using:<VariableName>
Still, the remote variable is not something you will do in your use case since you cannot do what you are after natively with PowerShell. You'll need a 3rdP tool like MS SysInternals PSExec to run code remotely as the logged-on user.
Using PsExec
Usage: psexec [\computer[,computer2[,...] | #file]][-u user [-p
psswd][-n s][-r servicename][-h][-l][-s|-e][-x][-i [session]][-c
executable [-f|-v]][-w directory][-d][-][-a n,n,...] cmd
[arguments]
-i Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the
process runs in the console session.
-u Specifies optional user name for login to remote computer.
I suggest that you use Invoke-Command
Function Start-CleanMGR ($computername, $creds) {
Invoke-Command -ComputerName $computername -Credential $creds -ScriptBlock {
try {
$cleanmgr = Start-Process -FilePath "C:\Windows\System32\cleanmgr.exe" -ArgumentList '/verylowdisk' -Wait -Verbose
if ($cleanmgr) {
return "Clean Manager ran successfully!"
}
}
catch [System.Exception] {
return "Cleanmgr is not installed! To use this portion of the script you must install the following windows features:"
}
}
}
Start-CleanMGR -computername "remotehost" -creds (Get-Credential)
As long as you execute cleanmgr.exe under a user account that has local admin rights, everything will work. Running cleanmgr.exe under the SYSTEM account, E.G. running from the Run Script Tool in SCCM/MECM will not work unless the script first opens a separate shell (DOS/PS) under a user that has local admin rights...even the cleanmgr.exe /verylowdisk will not run under the SYSTEM account.
So all I want to do is create a shortcut script that when clicked will restart the network adapter. The issue is that it needs to be ran on an account with basically no privileges so I need to have it run elevated and as a different user (admin account).
I cant quite figure out the right way to do this and its driving me nuts. This is what I have so far:
$username = "Domain\User"
$password = "Password"
$credentials = New-Object System.Management.Automation.PSCredential -ArgumentList #($username,(ConvertTo-SecureString -String $password -AsPlainText -Force))
start-process powershell -Credential ($credentials) -ArgumentList '-ExecutionPolicy unrestricted -noprofile -verb runas -inputformat text -command "{restart-netadapter -InterfaceDescription "Dell Wireless 1538 802.11 a/g/n Adapter" -Confirm:$false}"'
It will open a new powershell window but the command fails to run. It works fine on its own in an elevated powershell prompt. I found out at one point that even though I was calling the powershell using an admin account it wasn't an elevated powershell so I added the -verb runas but it still isn't working.
This really shouldn't be that hard, but I am not a powershell guru by any means. Any help is much appreciated. Thanks!
In my opinion, the best way to do this is to create a scheduled task that runs the script as a privileged account. Get rid of the embedded credentials altogether.
The limited account then only needs to be able to start the task.
Since the code to restart the adapter is a one-liner, you don't need even need to put it in a script file, so you don't need to worry about execution policy or anything.
This is the code that I used to get mine to work, I can't take credit for writing it because I found it from Here
# Get the ID and security principal of the current user account
$myWindowsID=[System.Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal=new-object System.Security.Principal.WindowsPrincipal($myWindowsID)
# Get the security principal for the Administrator role
$adminRole=[System.Security.Principal.WindowsBuiltInRole]::Administrator
# Check to see if we are currently running "as Administrator"
if ($myWindowsPrincipal.IsInRole($adminRole))
{
# We are running "as Administrator" - so change the title and background color to indicate this
$Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)"
$Host.UI.RawUI.BackgroundColor = "DarkBlue"
clear-host
}
else
{
# We are not running "as Administrator" - so relaunch as administrator
# Create a new process object that starts PowerShell
$newProcess = new-object System.Diagnostics.ProcessStartInfo "PowerShell";
# Specify the current script path and name as a parameter
$newProcess.Arguments = $myInvocation.MyCommand.Definition;
# Indicate that the process should be elevated
$newProcess.Verb = "runas";
# Start the new process
[System.Diagnostics.Process]::Start($newProcess);
# Exit from the current, unelevated, process
exit
}
# Run your code that needs to be elevated here
Write-Host -NoNewLine "Press any key to continue..."
$null = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")
But this checks to see if it is elevated and then elevates it if it isn't.
For simplicity, let's say the user Administrator is logged in in terminal session 2. Another user Boda is logged in terminal session 3.
Is it possible to runas a program in session 3 from session 2?
For simplicity, let's say I want to start calc.exe in session 3 (in Boda's session). How do I do that? Can it be done with runas?
Like Harry Johnston suggested in a comment you can do this using the psexec tool available on TechNet. I've tried it using a Windows 2008 Server running Terminal Services and managed to start various applications in another users session (although not calc.exe - it started but minimized and the window refused to restore), among them cmd.exe.
The command I used was psexec.exe -i 3 cmd.exe where 3 is the session number (that you can get from qwinsta.exe).
Example: Remote session, logged on as Administrator; using qwinsta to enumerate sessions and psexec to start cmd.exe on another session.
Another session: logged on as Patrick, with the cmd.exe window on the desktop opened by Administrator (which the window title reveals too).
There is a commandline tool and it’s called RunInSession. You need to specify at least the SessionId in which you want to launch the process and which process you want to launch. Optional is servername if you want to launch on a remote server. If you run it without parameters a dialog with possible parameters is shown:
Currently supported OS versions are Windows XP, 2003, Vista and 2008.
The program needs to run in the context of the Localsystem user, therefore it temporarily installs itself as service and start itself. With the WTSQueryUserToken it obtains the Primary User token of the requested Terminal Session. Finally the process is launched with CreateProcessAsUser and the service deletes itself.
More details:
How to launch a process in a Terminal Session
Launching an interactive process from Windows Service in Windows Vista and later
Its kind of an hack, but its very useful to me. Way more faster than psexec.exe in my environment.
Just create a temporary task in a remote computer, for a specific user or group, run it, than delete the task.
I created a powershell script for it:
param (
[string]$Computer = ($env:computername),
[string]$User = "",
[string]$Command,
[string]$Args
)
$script_task =
{
param (
[string]$User = "",
[string]$Command,
[string]$Args
)
#Action
$Action = New-ScheduledTaskAction –Execute $Command
if($Args.Length > 0) { $Action = New-ScheduledTaskAction –Execute $Command -Argument $Args}
#Principal
$P = New-ScheduledTaskPrincipal -UserId $User -LogonType Interactive -ErrorAction Ignore
#Settings
$S = New-ScheduledTaskSettingsSet -MultipleInstances Parallel -Hidden
#Create TEMPTASK
$TASK = New-ScheduledTask -Action $Action -Settings $S -Principal $P
#Unregister old TEMPTASK
Unregister-ScheduledTask -TaskName 'TEMPTASK' -ErrorAction Ignore -Confirm:$false
#Register TEMPTASK
Register-ScheduledTask -InputObject $TASK -TaskPath '\KD\' -TaskName 'TEMPTASK'
#Execute TEMPTASK
Get-ScheduledTask -TaskName 'TEMPTASK' -TaskPath '\KD\' | Start-ScheduledTask
#Unregister TEMPTASK
Unregister-ScheduledTask -TaskName 'TEMPTASK' -ErrorAction Ignore -Confirm:$false
}
#The scriptblock get the same parameters of the .ps1
Invoke-Command -ComputerName $Computer -ScriptBlock $script_task -ArgumentList $User, $Command, $Args
Usage example:
file.ps1 -User USER_NAME -Command notepad.exe -Computer REMOTE_COMPUTER
I don't know of any way you can control another open cmd session. However, you should be able to use runas to run it as another user.
This can be archived using Sysinternals tools from Microsoft. Beside running lists of commands and scripts remotely, they are useful for lot of things. As admin they had been my savior on multiple occasions.
#To run a command on single computer remotly
psexec \\RemoteComputerName Path_Of_Executable_On_Remote_Computer Argument_list
#To run a command on list of computers remotely.
psexec #Remote_Computer_list Path_Of_Executable_On_Remote_Computer Argument_list /AcceptEULA
#To run list of commands on list of remote computer. make sure you copy batch file before you run command below.
psexec #Remote_Computer_List Path_Of_Batch_On_Remote_Computer Argument_list