I’ve just spent more time that I would have liked diagnosing and resolving an issue with using Release Management in VSTS and releasing into a new environment. The “Windows Machine File Copy” task repeatedly failed with a “System error 1326”.
Using the same credentials that were being rejected in this step, I was able to connect from the agent to the remote server with no problem. I tried putting the credentials directly into the properties fields within the task. I tried configuring the credentials as custom variables, with the password both masked and unmasked. Still no luck.
I then started putting more verbose logging into the “Windows Machine File Copy” task’s PowerShell scripts at “\agent\tasks\WindowsMachineFileCopy\1.0.18”. It was in here within RoboCopyJob.ps1 that I noticed this snippet:
$command = "net use `"$machineShare`""
if($userName)
{
$command += " /user:`"$userName`" `'$password`'"
}
$command += " 2>&1"
In particular, notice how the $password variable is wrapped by escaped single quotes. This reminded me that I had previously had issues with command line syntax when using passwords containing single quotes, and I had had to escape them. As an example, let’s assume my password for the credentials I am trying to use to connect to the remote server is “P29gV”(cMc”. This password contains two single quotes next to each other. I first tried escaping these two single quotes and because they are being passed to the “net use” command, they need to be escaped with DOS syntax, like so: “”P29gV””(cMc”. I.e., each single quote is escaped by a single quote. This worked for the “Windows Machine File Copy” task and my release progressed to the next step. Great! Although not for long…
My next step in the release definition is a “PowerShell on Target Machines” task. This task uses the same credentials as the previous step, however, underneath the covers the credentials are being used differently, to invoke PowerShell remotely. This does not require the single quote to be escaped, and so is using the password as written. It therefore failed with invalid credentials.
One option would have been to have two different password variables for this user account, one with escaped quotes and one without, and use the correct one for the relevant task, but this could get really messy, really quickly. The easiest option would have been to change the password to remove the single quotes, but unfortunately that option was not immediately open to me. So I reset my password variable back to the proper password (rather than an escaped one) and revisited the RoboCopyJob.ps1 referred to above.
As it was a single quote that was causing these issues, I changed the escaped quotes around the $password variable from single quotes to double quotes. This changes the snippet I showed before to this:
$command = "net use `"$machineShare`""
if($userName)
{
$command += " /user:`"$userName`" `"$password`""
}
$command += " 2>&1"
After making this change both my “Windows Machine File Copy” and “PowerShell on Target Machines” tasks executed successfully.
This change is not ideal, as when a new VSTS Build Agent is pushed out it will potentially overwrite the change I’ve made to this PowerShell script and then break my releases. If anyone has a better solution (aside from changing the password!) I would be interested to hear it.