Starting jobs locally and on remote host can not be done with a single command

[zamothh]

Summary of the new feature / enhancement

Problem

In the case I have multiple servers where I want to run a scriptblock, including the server I am connected on, I am forced to write this over explicit code :
Note : the powershell session is running on ServerB

for ($computer in "ServerA", "ServerB", "ServerC") {
    if ($computer -like $env:computername ) {
        # Computer = ServerB
        $Jobs += start-job -ScriptBlock $ScripBlock
    } else {
        # Computer = ServerA or ServerC
        $Jobs += Invoke-Command -ComputerName $computer -AsJob -ScriptBlock $ScripBlock
    }
}

Reason

• Start-job does not allow to run jobs on remote host
• Invoke-Command -ComputerName $env:computername -asjob -ScriptBlock $ScripBlock
  • Requires to be "ran as administrator" to function
    • OR
  • throws an error OpenError: [Hostname] Connecting to remote server Hostname failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
• Invoke-Command -AsJob -ScriptBlock { dir } does not match required parameter set

Conclusion

This is not new to powershell and I have always found complexity into writing scriptblocks that could run on multiple servers, including the local server I am connected on

Proposed technical implementation details (optional)

As start-job does not require to "run as administrator" I feel like there shouldn't be any restrictions into being able to run

• Invoke-Command -AsJob -ScriptBlock { dir } which could be, somehow, an alias of start-job
• Invoke-Command -AsJob -ScriptBlock { dir } -computername $env:computername
  without having to use the 'log on as adaministrator' switch

[kasini3000]

start-job: for local multi-process batch

I have always found complexity into writing scriptblocks that could run on multiple servers

kasini3000 site mirror:(https://github.com/kasini3000/kasini3000)
win,linux devops automation batch script framework.(It is similar to Puppet，Ansible，pipeline)
Open source, free, cross-platform
English manual: https://gitee.com/chuanjiao10/kasini3000/blob/master/docs/kasini3000_manual.xlsx

kasini3000_agent_linux Shell script,one click install powershell on linux,modify sshd_config for PsRemote.

The technology, protocol, or feature keyword supported by "kasini3000":
Offline installation of win, linux, master, node and all libraries.
winrm, ssh, rsync between win and linux, batch telnet, batch sftp, batch ftp-sync, batch sftp-sync, sqlite, remote object transfer,
batch database client, picture alarm, balloon alarm, sound alarm, WeChat alarm , Dingding alarm.
Support from win, linux master sodo login to linux node.
Free support for 1 batch of linux2winrm. Another batch of linux2winrm is supported for a fee.
The remote command line from the master to node supports only bash in the Linux node, but no pwsh is installed. But this is not recommended.

Q: I already have my .py, .sh, .pl, .bat scripts, why use your framework?
A: The framework provides these functions:
Kasini3000 provides multi-process and multi-thread engine; automatic remote transfer of ps1 scripts and code blocks;
timed task engine; remote value transfer of objects; Batch modify win node, linux node password.

linux master to win node:
depened OMI ,this has some little bugs,for none english script name.
two ways :
one free ,use foreach + c:\ProgramData\kasini3000\k_run_ip_port_l2w_user_pwd.ps1
two 20$ , depened 【nodelist.csv】 , batch by sqlite.

[PaulHigin]

The administrator restriction is on the remoting (WinRM) endpoint for security and is set by default. It is possible to remove the admin constraint from the endpoint but not advisable. It is interesting that the credentials used to log onto the remote machines work, but fail for the local machine case. Start-Job does not connect to a WinRM endpoint like Invoke-Command, and instead connects to a local child process with the same user account as the parent process, so there are no security concerns as with WinRM endpoints which can accept off-box connections.

I am not sure it is worth adding the ability to create a local job to Invoke-Command -AsJob. It seems better to create a helper function that makes the decision to start an off-box WinRM job connection or a local job connection.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.