The problem is not with the host file or build agent, but rather with the server certificate on the TARGET machine. For me, I used VSTS to deploy to Azure VM when I ran into a problem, but the solution remains the same for onsite machines.
For an Azure VM deployment, a problem occurs when you create a virtual machine without a DNS name for a public IP address, and then add it (something like example.centralus.cloudapp.azure.com ). This can also happen if you change the DNS name label.
Question
You want to check how you connect to the car. It used to work fine using the Azure VM IP address. Now VSTS has started using example.centralus.cloudapp.azure.com:5986 since I recently added a DNS name label. We will call this the address of the target machine .
On the target machine, open PowerShell or Command Prompt as an administrator and enter the command " winrm e winrm/config/listener ". It should return two listeners, one for HTTP and one for HTTPS (if it is not in HTTPS, don’t worry, we will add it later). Pay particular attention to the Hostname for the HTTPS listener. If this does not match the address of the target machine that we discovered earlier, this causes an error. CertificateThumbprint corresponds to the server certificate on the computer.
To view these certificates, from PowerShell or the command line, type mmc and press enter. Go to File> Add / Remove Snap-in .... Select "Certificates" and click Add . In the dialog box, select "Computer Account" and click Next , then Finish . In the "Certificates"> "Personal"> "Certificates" section, you will see the certificate used by the WinRM configuration. The certificates here, which are self-signed, are considered Test Certificates because they are not protected by an official certification authority. We will need to create one that represents the address of the target machine that you want to use.
You can also view certificates in IIS under Server Certificates .
Decision
Make sure you know which address you want to use to connect to the machine. This is the address of the target machine .
On the target machine, open PowerShell as an administrator. Enter the following command.
New-SelfSignedCertificate -DnsName WhateverTargetMachineAddressYouNeed -CertStoreLocation Cert:\LocalMachine\My
This creates a new server certificate for your destination address with an expiration date.
Then we want to recreate the WinRM listener for the HTTPS transport types to use the new certificate. Open IIS and see Server Certificates for your web server. You should see the one you just created. Right-click on it and select "View ...". On the Details tab, copy the Thumbprint for the certificate. You can also do this with mmc if you want.
Type the following commands one at a time in PowerShell.
winrm delete winrm/config/listener?Address=*+Transport=HTTPS
Then:
winrm create winrm/config/listener?Address=*+Transport=HTTPS '@{Hostname="WhateverTargetMachineAddressYouNeed";CertificateThumbprint="TheThumbprintYouCopied";port="5986"}'
Done! If you enter winrm e winrm/config/listener in PowerShell, you should now see the HTTPS transport using the new certificate.
If anything in your release or deployment determination scenarios uses the old address (Azure VM IP address for me), be sure to update them to use the new destination machine address (for me, Azure VM DNS name label) With port number. In VSTS, make sure you select the check box to use Test Certificate . Good luck
For more information, you can go here:
http://www.dotnetcurry.com/windows-azure/1289/configure-winrm-execute-powershell-remote-azure-with-arm