Windows Machine File Copy task

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 — TFS 2015

Use this task to copy application files and other artifacts such as PowerShell scripts and PowerShell-DSC modules that are required to install the application on Windows Machines. It uses RoboCopy, the command-line utility built for fast copying of data.

In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.

YAML snippet

Arguments

Argument	Description
Source	The path to the files to copy. Can be a local physical path such as c:\files or a UNC path such as \\myserver\fileshare\files . You can use pre-defined system variables such as $(Build.Repository.LocalPath) (the working folder on the agent computer), which makes it easy to specify the location of the build artifacts on the computer that hosts the automation agent.
Machines	A comma-separated list of machine FQDNs or IP addresses, optionally including the port number. Can be: — The name of an Azure Resource Group. — A comma-delimited list of machine names. Example: dbserver.fabrikam.com, dbserver_int.fabrikam.com:5986,192.168.34:5986 — An output variable from a previous task.
Admin Login	The username of either a domain or a local administrative account on the target host(s). — Formats such as domain\username, username, and machine-name\username are supported. — UPN formats such as username@domain.com and built-in system accounts such as NT Authority\System are not supported.
Password	The password for the administrative account specified above. Consider using a secret variable global to the build or release pipeline to hide the password. Example: $(passwordVariable)
Destination Folder	The folder on the Windows machine(s) to which the files will be copied. Example: C:\FabrikamFibre\Web
Advanced — Clean Target	Set this option to delete all the files in the destination folder before copying the new files to it.
Advanced — Copy Files in Parallel	Set this option to copy files to all the target machines in parallel, which can speed up the copying process.
Advanced — Additional Arguments	Arguments to pass to the RoboCopy process. Example: /min:33553332 /l
Select Machines By	Depending on how you want to specify the machines in the group when using the Filter Criteria parameter, choose Machine Names or Tags.
Filter Criteria	Optional. A list of machine names or tag names that identifies the machines that the task will target. The filter criteria can be: — The name of an Azure Resource Group. — An output variable from a previous task. — A comma-delimited list of tag names or machine names. Format when using machine names is a comma-separated list of the machine FQDNs or IP addresses. Specify tag names for a filter as : Example: Role:DB;OS:Win8.1
Control options	See Control options

Open source

This task is open source on GitHub. Feedback and contributions are welcome.

I get a system error 53 when using this task. Why?

Typically this occurs when the specified path cannot be located. This may be due to a firewall blocking the necessary ports for file and printer sharing, or an invalid path specification. For more details, see Error 53 on TechNet.

Do I need an agent?

You need at least one agent to run your build or release.

I’m having problems. How can I troubleshoot them?

I can’t select a default agent pool and I can’t queue my build or release. How do I fix this?

My NuGet push task is failing with the following error: «Error: unable to get local issuer certificate». How can I fix this?

This can be fixed by adding a trusted root certificate. You can either add the NODE_EXTRA_CA_CERTS=file environment variable to your build agent, or you can add the NODE.EXTRA.CA.CERTS=file task variable in your pipeline. See Environment variables for more details.

I use TFS on-premises and I don’t see some of these features. Why not?

Some of these features are available only on Azure Pipelines and not yet available on-premises. Some features are available on-premises if you have upgraded to the latest version of TFS.

Windows machine file copy

Windows Machine File Copy Task (WinRM)

The task is used to copy application files and other artifacts that are required to install the application on Windows Machines like PowerShell scripts, PowerShell-DSC modules etc. The task provides the ability to copy files to Windows Machines. The tasks uses WinRM for the data transfer.

This task defers from the original task that ships with VSTS/TFS by the fact that this implementation uses WinRM for the file transfer instead of robocopy on which the original task is based on. In certain situations, due to the network restrictions, mounting the drive and using the necessary protocols is not possible. Thus, for such scenarios, where WinRM is enabled, this task will solve the issue.

The only requirement is PowerShell V5 installed both on the build server and on the machine on which you are trying to copy the files to.

The different parameters of the task are explained below

• Source: The source of the files. As described above using pre-defined system variables like $(Build.Repository.LocalPath) make it easy to specify the location of the build on the Build Automation Agent machine. The variables resolve to the working folder on the agent machine, when the task is run on it. Wild cards like **\*.zip are not supported. Probably you are going to copy something from your artifacts folder that was generated in previous steps of your build/release, at example ‘$(System.ArtifactsDirectory)\Something’.
• Machines: Specify comma separated list of machine FQDNs/ip addresses along with port(optional). For example dbserver.fabrikam.com, dbserver_int.fabrikam.com:5988,192.168.34:5933.
• Admin Login: Domain/Local administrator of the target host. Format: \ .
• Password: Password for the admin login. It can accept variable defined in Build/Release definitions as ‘$(passwordVariable)’. You may mark variable type as ‘secret’ to secure it.
• Destination Folder: The folder in the Windows machines where the files will be copied to. An example of the destination folder is c:\FabrikamFibre\Web.
• Use SSL: In case you are using secure WinRM, HTTPS for transport, this is the setting you will need to flag.
• Using Test Certificate Available only if Use SSL is selected. If this option is selected, client skips the validation that the server certificate is signed by a trusted certificate authority (CA) when connecting over Hypertext Transfer Protocol over Secure Socket Layer (HTTPS).
• Clean Target: Checking this option will clean the destination folder prior to copying the files to it.
• Copy Files in Parallel: Checking this option will copy files to all the target machines in parallel, which can speed up the copying process.

Task version history

• 2.0.7 — A bug has been addressed that will not ignore certs in case of parallel copy (#11)
• 2.0.7 — Solved the issue where task can’t resolve reverse DNS for IP addresses (#4)
• 2.0.6 — «minimumAgentVersion» set to «1.95.0» in order to ensure the compatibility with TFS 2015 Update 2 (#5)
• 2.0.5 — Solved the issues introduced with v2.0.2 where reverse lookup data in DNS is not present
• 2.0.2 — Resolve CNAME before creating a WinRM session (#2)
• 2.0.1 — Implements the Skip CA Check for HTTPS with a self signed certificate (#1)

Feel free to notify any issue in the issues section of this GitHub repository. In order to build this task, you will need Node.js and gulp installed. Once cloned the repository, just run ‘npm install’ then ‘gulp package’ and in the newly created folder called _packages you will find a new version of the extension.

About

Windows Machine File Copy Build-Release task for VSTS/TFS based on WinRM

How to copy a file from one windows machine to other windows machine?

How to copy a file from one Windows machine to other Windows machine? so that i can write a batch script can run that from Hudson machine. My requirement is , I like to deploy war in tomcat server located remotely in another windows machine through Hudson (war will be generated in this machine) which is located in another windows machine. FYI, Both windows are on the same network or intranet.One more thing to Linux deployment we are using plink. Is there any alternative for Windows deployment?

Thanks in advance

2 Answers 2

Depends on what you actually want to do and what the security requirements are. There are several options. The easiest one is to use the copy command with UNC path for the remote computer \\hostname\sharename\directory\actual.file . Important is, that the remote computer has the share defined and permits write access (on file and share level) for the user hudson is running under. This also means that you can’t run hudson under the local_system account. (default option if you run Hudson as a service)

Actually I would prefer robocopy over copy . I think microsoft offers robocopy for free. Study the documentation (help) of robocopy, it is a program for administrators who are supposed to know what they are doing. Robocopy is not only robust, if used with the wrong switches, it can also ‘unintentionally’ delete files.

Other options would include SCP and FTP, Master\Slave configurations where the slave downloads the artifacts from Hudson using http/https protocoll.

EDIT:

comment from vishu

Thanks for your prompt response. As your answer explains that you have good knowledge in Hudson, I would like to give my requirement in detail. My requirement is , I like to deploy war in tomcat server located remotely in another windows machine through Hudson (war will be generated in this machine) which is located in another windows machine. FYI, Both windows are on the same network or intranet.One more thing to Linux deployment we are using plink. Is there any alternative for Windows deployment?

I usually deploy to Websphere Application Server. So i needed to read a little bit on how to deploy to tomcat. It looks like you just need to drop the wat-files into the right directory and you are done or change the configuration files that are currently used by tomcat and it will pick it up automatically (provided everything is configured correctly).

Since the deployment scenario and your setup is very simple I would consider two options. My preferred on is to install a ssh service on the target Windows machine and reuse your plink scripts that you already have (for this or other projects). The idea is here to stick to one technology. The other option is to use windows shares. In this case make sure that Hudson uses a ‘real’ account so that Hudson does not explicitly need to map the share (can be scripted, but passwords might be stored unencrypted). Create a share on the target system with write permission for Hudson. Than the rest is nothing else than a copy. For the copy you should have a look at robocopy, since it is far superior for this kind of jobs than the copy command. My assumption here is that the build job does the deployment.

In case you have two jobs, the first one creates the artifacts and the other one deploys the artifacts. I currently prefer the use of wget to retrieve the artifacts from job1. This implies that job1 archives its artifacts. The second job gets the artifacts from the first one (using wget and the run URL for job1). In this case you can run a Hudson slave on the target machine and you can deploy locally. You can use similar scripts for windows and Linux. You can get wget for windows with cygwin (at least I think so). With cygwin you might even be able to use your linux script on windows. The advantage is, that you don’t need shares and no separate artifact repository. If you run the slave as a service, you don’t even need to install an ssh server on the target machine.

If you trigger your deployment manually, you can use the batch task plugin. Than it is practically one job and you don’t need to worry to move artifacts between jobs. The disadvantage is, that you can only deploy from the most recent job run, since it depends on the workspace of the job. Deployment of older versions (if your project is broken right now or if you need to downgrade because of a major bug in your app) is not possible.

If you already have an artifact repository, use the master slave setup and check the artifacts out of your repository from the target machine.

Windows Machine File Copy task without using admin credentials

I want to copy build artifacts from $(System.ArtifactsDirectory) to shared folder on remote Windows Server 2016. I am using «Windows Machine File Copy» task for this. It works when I use this-

Admin credential parameters AdminUserName and AdminPassword are optional. But I remove them copy task fails. So my requirement is- we do not want to use username and password. Instead we want to use Azure Service Principal. Is there a way I can achieve copying files using Service Principal instead of username and password?

1 Answer 1

So my question is- how do I copy files without using any credentials?

If you want copy files without using any credentials, that means you need to set the permissions of your target folder that anyone can access.

Obviously this is unsafe, we do not recommend you to do this. If you have a reason to insist on doing this and you can ensure information security, you can refer to the following way.

You could share the folder to everyone in the remote machine:

Then, we could just use the copy task to to copy build artifacts from $(System.ArtifactsDirectory) to shared folder on remote Windows Server 2016 :

I test it with remote Windows Server 2012, and it works fine.