In TFS 2017 Update 2 Release Management, what advantages does the "PowerShell on Remote Machines" task provide over PSRemote PowerShell scripts executed from the deployment agent machine?
As part of our release process, we use PowerShell scripts to validate and configure the servers being deployed to (e.g. install SSL certs, .NET version, etc.). We've historically used PowerShell remoting (New-PSSession/Invoke-Command) with CredSSP to execute scripts from the deployment agent to configure the destination machines.
The PowerShell on Remote Machines task appears to involve copying your ps1 to the destination machine and then executing it from that machine's context. Compared to the PSRemote method, it looks like all we gain is simpler syntax. Also, it looks harder to trace and troubleshoot from RM if we copy script files to a collection of servers and then let those boxes execute the scripts while we wait for the result. Given the popularity of websites referencing using this task, I feel I must be missing something.
The PowerShell on Target Machinestask makes the deployment more convenient and effective.
This task can run both PowerShell scripts and PowerShell-DSC scripts. It can execute PowerShell scripts on remote machines with a comma-separated list of machine FQDNs or IP addresses, optionally including the port number. Also pass other arguments easily.
Refer Deploy: PowerShell on Target Machines to know the details.
And this article for PSRemote : How to Run PowerShell Commands on Remote Computers
You can compare with them.