VSTS Windows Machine file copy robocopy not found

2
votes

So we're setting up a release where we want to copy some artifacts to a target server in order to start a deploy. unfortunately when the task starts it errors out on the actual copy with the following error:

The term 'robocopy' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

However when checking both source and target machine the robocopy command (both from Powershell and CMD.exe run perfectly and presents the default robocopy starting screen.

We're using a private build agent running windows server 2016.

I've checked PATH variables and C:\Windows\System32 is in the list and running a search on both systems gives back robocopy.exe in the same directory.

running the task on a hosted agent makes it run fine. So it definitely is a local issue, just don't see where this might be coming from.

results of echo %PATH% and robocopy on the build agent: Echo

Results of the Release with the failing task:

Release

As requested by Shayki the task definition:

TaskDef

1
azure-devopsrobocopyazure-pipelines-release-pipeline
If you log in to that agent machine as the user account which the build agent service is running as - is it able to find robocopy? – Yan Sklyarenko
it's running under the default NT AUTHORITY\NetworkService as suggested by VSTS itself. I'll try reconfiguring it and see what it does when i have the agent run on another account (a local admin account) – Tsteenbakkers
Can you upload the Task definition? – Shayki Abramczyk
You do know that you can copy/paste text content from a command window much easier (and readably) than posting an image? – Ken White
@ShaykiAbramczyk: see edit :) – Tsteenbakkers

1 Answers

2
votes

for some unknown reason the %PATH% variable would show C:\Windows\System32 when doing echo %PATH% however when going through the environment variables inside control panel there was no entry for it inside the PATH environment variable.

Added the C:\Windows\System32 folder back into PATH system environment Variables (and putting it on top) fixed it for us.