I’m using Release Manager in Visual Studio Team Services (i.e. the one in the cloud) to deploy to my On Premises backend servers. Release Manager does this by using an agent in the environment within which you want to deploy. You can deploy and configure the agent through Release Manager and instructions are at https://blogs.msdn.microsoft.com/visualstudioalm/2016/04/05/deploy-artifacts-from-onprem-tfs-server-with-release-management-service/
However this requires remote PowerShell configuring on the target machine to work correctly. This you may think is really easy to do.
Run PowerShell as admin then type
Once configured I had to allow the machine with the agent on to access the target machine
Set-Item wsman:localhost\client\trustedhosts *.<domain name>
And also set up to allow for remote scripts using:
Testing this I used:
Enter-PSSession <SERVER NAME>
On all my local VMs this worked fine but as soon as I tried it on my UAT and Production servers I got a generic error which listed a lot of possible problems:
Connecting to remote server <SERVER NAME> failed with the following error message: WinRM cannot process the request.
The following error with errorcode 0x80090322 occurred while using Negotiate authentication: An unknown security error occurred.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
Searching for the error returned a lot of similar results including:
A conflict between ports
Sites to help with troubleshooting
None of them fixed the problem. I managed to get Remote Powershell to work by setting the SPN to specific ports but this then broke Reporting Services so I reverted my changes.
You know you are struggling when all the searches you do yield results you have already read, but in one web site that didn’t appear to be relevant I found this little nugget of information
“Remote PowerShell requires port 80 to be available on the Default Web Site”
Looking at my web server there was no default website and nothing using port 80 so I added one and remote PowerShell started to work!
I can now deploy from the cloud on to my back end servers without opening any firewall portsJ