Powershell on target machines from azure pipelines

Question

I have an Azure VM, which i would like to remotely run some powershell command from azure pipelines. I setup winrm on my VM with self signed certificates and open port 5986 on VM azure firewall. I have been able to remotely execute some scripts i put in VM from local machine, but when i execute the same from a Powershell on target machines tasks, i will get an Access Denied error.

I have tried the v2 task as well and tick the Test Certificate and use an admin account i use to rdp to the machine, but got the same error. I wonder what have i missed in setting this?

Answer 1

First test that you can get Powershell to execute remotely on your target from a laptop or other machine.

Use the Powershell script below to test your WinRM connection and self-signed cert and note the -SkipCNCheck -SkipCACheck PSSession options in the test Powershell script. These options are essential if you are using a self-signed cert and you'll also need to provide the same switches in the "Session Options" in the "Run Powershell On Target Machines" template (ver 3).

Note : I'm using a local host IP for example only so as not to accidentally use a real IP

$password = ConvertTo-SecureString 'password goes here' -AsPlainText -Force

$credential = New-Object System.Management.Automation.PSCredential ('yourDomain\yourDomainUserId', $password)

$sessionOptions = New-PSSessionOption -SkipCNCheck -SkipCACheck

$remote_session = new-pssession -computername 127.0.0.1 -UseSSL -credential $credential -SessionOption $sessionOptions

Invoke-Command -session $remote_session -ScriptBlock { Get-Culture }

Also make sure you have setup a WinRM listener to listen on the external IP of the target machine and register the self-signed cert thumbprint with that listener. Use the WinRM command to do that (user your actual external public facing IP), example:

winrm create winrm/config/Listener?Address=IP:127.0.0.1+Transport=HTTPS @{Hostname="some.hostname.outhere.net"; CertificateThumbprint="[YOUR CERT THUMBPRINT]ABCDEF0247283798137030174027"}

One more note, use the machine external public IP in place of an FQDN or DNS name in the "Machines" field of the "Run Powershell On Target Machines" template. You must do this if you are using a self-signed cert.

Once you get the test Powershell script to connect and handshake using the self-signed cert from a remote machine, you are virtually guaranteed success having the "Run Powershell on Target Machines" work too.

Other things to check:

• Make sure you have setup TrustedHosts using a wildcard "*" as the server name or ip. You can go back and fine tune your security after you have the basic connection working.

• You may need a Domain Level GPO to allow the WinRM service to run unhindered depending on whether your target machine is a workstation or a machine joined to a domain.

If all else fails, download and install Wireshark on your target machine and set an ip filter to listen just for the ip of the client server and analyze the traffic, most of the time this will clue you in to what's being rejected and why.

Hope this helps.

Answer 2

To set up WinRM for Microsoft Azure Virtual Machines.

Azure Virtual Machines require WinRM to use the HTTPS protocol. You can use a self-signed Test Certificate. In this case, the automation agent will not validate the authenticity of the certificate as being issued by a trusted certification authority.

According to your description, if you are able to use admin account to rdp to the machine.

The build service account is just running Powershell on target machines task of your pipeline. Suggest you could also use your build service account to remote your Azure VM and run the script. This will narrow down the issue.

If the build service account is also getting access Denied error. You need to assign corresponding permission refer to your admin account for the build service account.

Besides, if your Azure VM do not have public IPs, please refer this similar question here: Use VSTS task 'PowerShell on Target Machines' without public IP in Azure

Answer 3

This may not help you if .Netcore is on your VM but we got around not being able to use elevated Powershell commands by creating a light .Netcore Worker service with http request capability. You can send a Invoke-RestMethod command from a regular Powershell YML task and it will trigger your custom logic on the other end of the ASP controller. We use it to remove Appx packages before re-installing for our Unit tests. The repo is located at, AzureAdmin

Answer 4

We had a similar problem with the azure pipelines. Turns out that the PowerShell context expects the user name to be the fully qualified name (domain\username or machine_name\username).

Once we use the fully qualified name format, we were able to successfully connect to the remote machine via powershell from the pipelines