TFS 2017 Build: Cannot Run PowerShell

Question

We are using TFS 2017 and it has several builds configured. A little while ago we started getting an error on the second step, which is to run a PowerShell Script (first step is Get Sources):

2018-06-28T19:58:59.4326443Z ##[command]. 'K:\_work\3\s\BuildScripts\MainPre.ps1' -env "test"
2018-06-28T19:58:59.6236482Z ##[error]Access is denied
2018-06-28T19:58:59.6266488Z ##[section]Finishing: PowerShell Script

A build 4 hours ago worked just fine. No changes were made to the file, or the filesystem. I am waiting to hear from the network team to see if they did anything to the build account.

What could cause this error suddenly and how do I fix it? Note: I have not yet tried to turn it off and on again.

Answer 1

Based on the error message "##[error]Access is denied", seems it's an permission issue.

Just try below items to narrow down the issue:

• Enable Clean option in Get sources step: Set Clean to True and select Sources Directory under Clean options.

• Check if the agent service account has the correct permission to access the script.

• Try to change another account which has the correct permission to
  access the agent _work foler as the service account, then queue build again.

• Deploy a new agent, try it again.

If that still not work, just turn on system.debug in variable tab (set to true) to capture the logs and share here for further troubleshooting.

Answer 2

It looks like the powershell task runs some sort of security check when executing scripts?

I ran the powershell task in DEBUG and you can see the task runs some security work implicitly here.

This does give me access denied when i run it:

##[debug]C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe 

-NoLogo -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command "try { $null = [System.Security.Cryptography.ProtectedData] } catch { Write-Verbose 'Adding assemly: System.Security' ; Add-Type -AssemblyName 'System.Security' ; $null = [System.Security.Cryptography.ProtectedData] ; $Error.Clear() } ; Invoke-Expression -Command ([System.Text.Encoding]::UTF8.GetString([System.Security.Cryptography.ProtectedData]::Unprotect([System.Convert]::FromBase64String('AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAARs9EULLEBU+ppaGEeISmGgAAAAACAAAAAAADZgAAwAAAABAAAABLYbw0iUTABtaCw2PJ5KrrAAAAAASAAACgAAAAEAAAAOg6VMmANxZJSRmKjPWauqRYAAAAqDSQVtB4LtvBaujeTs1GKn4CPFrW484weBNwtJ7aujcJLWV4wBLHD9n+IEVZ6z13oyIpyxUEceTtiMKnfuO8irwX9l5DoHqlMGU6mx1Q5kou2V6ITEcl0BQAAAD1h7qvkyE8+PcdKmVKLHVpqYO4mA=='), [System.Convert]::FromBase64String('8yTvn1ZlLZGC7M3ewDzbLw=='), [System.Security.Cryptography.DataProtectionScope]::CurrentUser))) ; if (!(Test-Path -LiteralPath variable:\LastExitCode)) { Write-Verbose 'Last exit code is not set.' } else { Write-Verbose ('$LastExitCode: {0}' -f $LastExitCode) ; exit $LastExitCode }"
2018-06-30T12:44:57.8488275Z ##

Answer 3

While checking through the server, I noticed that the Event Viewer says Symantec SONAR was blocking the power shell scripts. After our network team added an exception for the build processes, our builds were again working as expected.

Answer 4

For us, MCafee was blocking the powershell. once an exception was added, we were good.