Azure App Service deploy started failing with Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-"

[noellelc]

Note

Issues in this repo are for tracking bugs, feature requests and questions for the tasks in this repo

For a list:
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

If you have an issue or request for the Azure Pipelines service, use developer community instead:

https://developercommunity.visualstudio.com/spaces/21/index.html )

Required Information

Entering this information will route you directly to the right team and expedite traction.

Question, Bug, or Feature?
Type: bug

Enter Task Name: Azure App Service deploy

list here (V# not needed): 4.216.2 https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

Environment

• Server - Azure Pipelines or TFS on-premises?

  • If using TFS on-premises, provide the version:

  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number: account name: DevDiv, Project name: DevDiv, Release id: 103259

• Agent - Hosted or Private:

  • If using Hosted agent, provide agent queue name: private

  • If using private agent, provide the OS of the machine running the agent and the agent version:

Issue Description

We are running this task in a release pipeline in Azure DevOps. Last successful run was yesterday on version 4.214.0. It looks like this task just recently started failing, with version 4.216.2. Error message: Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-".

The argument in question is the command itself: "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe"; it looks like it's not honoring the quotations and is parsing this string as individual arguments, hence the callout of "Files\IIS\Microsoft"

Task logs

[Enable debug logging and please provide the zip file containing all the logs for a speedy resolution]

Troubleshooting

Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting

Error logs

[Insert error from the logs here for a quick overview]

[sfrsm]

Here I have installed the Microsoft Web Deploy 4.0. I think the problem is in some library that handle the command line, because if you copy and run it manually it works, in powershell and the command terminal.

I solved here the problem adding a new Task in my pipeline to execute the command line script. I added the line that was failling in this script and it works fine.

[DarkChocoholicDev]

We have reverted the affected tasks to previous versions in ADO, while we working on hotfixes:

• AzureRmWebAppDeployment - 4.216.2 -> 4.214.0
• IISWebAppDeploymentOnMachineGroup -0.216.0 -> 0.215.0

Sorry for the inconvenience.

I'm seeing this issue even today. Was the above supposed to somehow prevent 0.216.0 from continuing to be pulled down by agents? I keep deleting the directory, but it keeps coming back. If I clone 0.215.0 and rename 0.216.0, it seems to get modified during my job run, resulting in the same failure. None of the given work-arounds I've tried seem to be working. I'm not prepared to uninstall Microsoft Web Deploy from my public-facing systems, since I don't have a good understanding of the likely side effects.

Any further work-around ideas for this issue?

[sfrsm]

Are you running it on premise, did you tried to run it manually?

If it is on premise, try add a new task in your pipeline, Command Line Script, and insert the line with the webdeploy.exe in the script.

[DarkChocoholicDev]

It doesn't seem that we can do that because the filename keeps changing, perhaps because we're doing various forms of config-file transformation via the deployment task. Here are excerpts from the command lines produced by the last three runs.

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\azagent\A1\_work\r1\a\temp_web_package_3922506065380085.zip' ...

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\azagent\A1\_work\r1\a\temp_web_package_7567551291335439.zip' ...

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\azagent\A1\_work\r1\a\temp_web_package_1927501900671098.zip'...

[mselley]

having the same issue here what a nightmare. Tried deleting all 216 files and folders and it just downloads it all again and fails

[sfrsm]

It doesn't seem that we can do that because the filename keeps changing, perhaps because we're doing various forms of config-file transformation via the deployment task. Here are excerpts from the command lines produced by the last three runs.

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\azagent\A1\_work\r1\a\temp_web_package_3922506065380085.zip' ...

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\azagent\A1\_work\r1\a\temp_web_package_7567551291335439.zip' ...

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\azagent\A1\_work\r1\a\temp_web_package_1927501900671098.zip'...

In my case, I changed in the build pipeline to generate a .zip file with fixed name like WebApp.zip. I forgot to mention that. In the Release pipeline, in the IIS Web App Deploy I flagged the Control Options to Continue on error. This workaround works here.

[SteGriff]

I had this problem when building with the Microsoft hosted agent (default) and deploying onto on-premises IIS servers.

My workaround

On the machine in the deployment group, I went to the IISWebAppDeploymentOnMachineGroup task directory, at: C:\azagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba

I backed up the content of the 0.216.0 directory onto the desktop.

I deleted the content of the 0.216.0 directory

I copied the content of the 0.215.0 directory into 0.216.0

This prevents the build agent from trying to re-download 0.216, and when it uses 0.216, it gets the 0.215 implementation instead, because that's what is in the folder now.

Hope it helps.

[arezn]

I had this problem when building with the Microsoft hosted agent (default) and deploying onto on-premises IIS servers.

My workaround

On the machine in the deployment group, I went to the IISWebAppDeploymentOnMachineGroup task directory, at: C:\azagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba

I backed up the content of the 0.216.0 directory onto the desktop.

I deleted the content of the 0.216.0 directory

I copied the content of the 0.215.0 directory into 0.216.0

This prevents the build agent from trying to re-download 0.216, and when it uses 0.216, it gets the 0.215 implementation instead, because that's what is in the folder now.

Hope it helps.

It works

[DarkChocoholicDev]

Ok, yes, indeed, it works! There was a subtlety, though, that I didn't realize, which made all the difference. We couldn't just delete 0.216.0, clone 0.215.0, and rename the clone to 0.216.0. Rather, we truly had to delete the contents of the existing 0.216.0 and then copy in the contents of 0.215.0. It seemed like they'd be equivalent, but it appears to not be. Maybe there is some type of directory timestamp checking going on or something. Or maybe it had to do with us also deleting the 0.216.0.xxx files in the root of C:\azagent\A2_work_tasks\IISWebAppDeploymentOnMachineGroup_xxx. Not sure. But once I truly followed the work-around directions, it worked.

Thank you very much!

[SteGriff]

Or maybe it had to do with us also deleting the 0.216.0.xxx files in the root of C:\azagent\A2_work_tasks\IISWebAppDeploymentOnMachineGroup_xxx. Not sure. But once I truly followed the work-around directions, it worked.

I think you would have gotten away with doing it your way if you had not also deleted the .completed and .node6 files, which appears to be a signal to DevOps agent that the version installed correctly at a given datetime. I'm guessing that if they're absent, it reinstalls the version.

Glad it worked! 😀

[AlexisMateo]

I had this problem when building with the Microsoft hosted agent (default) and deploying onto on-premises IIS servers.

My workaround

On the machine in the deployment group, I went to the IISWebAppDeploymentOnMachineGroup task directory, at: C:\azagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba

I backed up the content of the 0.216.0 directory onto the desktop.

I deleted the content of the 0.216.0 directory

I copied the content of the 0.215.0 directory into 0.216.0

This prevents the build agent from trying to re-download 0.216, and when it uses 0.216, it gets the 0.215 implementation instead, because that's what is in the folder now.

Hope it helps.

Its works for me

[jxsierra]

I had this problem when building with the Microsoft hosted agent (default) and deploying onto on-premises IIS servers.

My workaround

On the machine in the deployment group, I went to the IISWebAppDeploymentOnMachineGroup task directory, at: C:\azagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba

I backed up the content of the 0.216.0 directory onto the desktop.

I deleted the content of the 0.216.0 directory

I copied the content of the 0.215.0 directory into 0.216.0

This prevents the build agent from trying to re-download 0.216, and when it uses 0.216, it gets the 0.215 implementation instead, because that's what is in the folder now.

Hope it helps.

Thank you very much! Its works for me

[zulfiqarali310]

We have reverted the affected tasks to previous versions in ADO, while we working on hotfixes:

• AzureRmWebAppDeployment - 4.216.2 -> 4.214.0
• IISWebAppDeploymentOnMachineGroup -0.216.0 -> 0.215.0

Sorry for the inconvenience.

Hello vmapetr, still facing the issue neither of the above solutions works for me, it's still pointing to 0.216.0 instead of 0.215.0, please let me know if got any solutions to this fix. Thanks

[DarkChocoholicDev]

zulfiqarali310, have you done the following steps exactly? It only worked for me when I did.

1. After a failure, bring up the folder ...\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba.
2. Without deleting the 0.216.0 folder itself, delete all contents of the 0.216.0 folder (files and subfolders).
3. Copy all of the contents of the 0.215.0 folder into the 0.216.0 folder.
4. Leave the files 0.216.0.completed and 0.216.0.node6 as-is.
5. Retry your deployment stage (or create a new release).

[zulfiqarali310]

zulfiqarali310, have you done the following steps exactly? It only worked for me when I did.

1. After a failure, bring up the folder ...\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba.
2. Without deleting the 0.216.0 folder itself, delete all contents of the 0.216.0 folder (files and subfolders).
3. Copy all of the contents of the 0.215.0 folder into the 0.216.0 folder.
4. Leave the files 0.216.0.completed and 0.216.0.node6 as-is.
5. Retry your deployment stage (or create a new release).

DarkChocoholicDev Thanks for your reply,

Actually, i did create new release pipeline its getting failed, the old one is also falling, non of the above solutions work for me.

Actually, i am using cloud base server and deploying applications using Deploy IIS Website/App

Does anybody have solutions to it.? Thanks

[johnkamau]

Same issue as the other users above. Switching contents of the directory 0.216 with those of 0.215 on the target server resolved the existing release, not sure if a new release will work if I re-run it.

[zulfiqarali310]

Same issue as the other users above. Switching contents of the directory 0.216 with those of 0.215 on the target server resolved the existing release, not sure if a new release will work if I re-run it.

not working for the new release, and i need it for a new release.

[johnkamau]

@zulfiqarali310 I tihnk they mean that you copy the files after the release has failed. Then re-deploy the release, the published version will be your latest release.

[zulfiqarali310]

zulfiqarali310, have you done the following steps exactly? It only worked for me when I did.

1. After a failure, bring up the folder ...\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba.
2. Without deleting the 0.216.0 folder itself, delete all contents of the 0.216.0 folder (files and subfolders).
3. Copy all of the contents of the 0.215.0 folder into the 0.216.0 folder.
4. Leave the files 0.216.0.completed and 0.216.0.node6 as-is.
5. Retry your deployment stage (or create a new release).

Thanks, everyone somehow it did work by doing this way.. thanks for your comments.

[amantcs]

Uninstalled the web deploy 3.6 from the web server as we are doing deployment through pipelines only, resolved our issue. I am using Cloud-based Azure DevOps services and deploying into VM which hosts IIS, using IIS Web App Deploy task.

[Kablekarnage]

Same issue but with the 'IIS Web App Deploy' task. We were able to fix this by uninstalling web deploy from the machine and clearing out the locally cached 'tasks' folder in the agent directory, e.g. 'C:\azagent\A4_work_tasks'.

[enginhorzum]

I have the same problem. Unrecognized argument 'Pipeline'. All arguments must begin with "-". It started after IISWebAppDeploymentOnMachineGroup task updated to version 0.216.0 But this error only occurs on our on-premise servers with a Pipeline Agent version 2.213.2 installed. The servers, which have Pipeline Agent version 2.193.0 installed, work without any error with IISWebAppDeploymentOnMachineGroup task version 0.216.0

[esuyg]

Had the same issue. Uninstalling Web Deploy did fix the IISWebAppDeploymentOnMachineGroup task, but we need Web Deploy installed for the earlier MSBuild task so had to use @SteGriff's workaround for now - thanks!

[pablosguajardo]

the same problem in version: 0.216.0

[pablosguajardo]

zulfiqarali310, have you done the following steps exactly? It only worked for me when I did.

1. After a failure, bring up the folder ...\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba.
2. Without deleting the 0.216.0 folder itself, delete all contents of the 0.216.0 folder (files and subfolders).
3. Copy all of the contents of the 0.215.0 folder into the 0.216.0 folder.
4. Leave the files 0.216.0.completed and 0.216.0.node6 as-is.
5. Retry your deployment stage (or create a new release).

thanks with this work around was able to make it work!!!

[soc-martin]

The fix is related to commit 3193cff2fd6c5754cadb8b4dc1b0e0cc96f46350.

[aneudyac]

Thank you so much, this help me fix this issue

[etaxi341]

Thank you, uninstalling Web Deploy and deleting the "_work" folders fixed it for me. The issue just started happening today. Yesterday everything was still working.

[Faiyaz-Aboobaker]

Thank you, uninstalling Web Deploy (V4) resolved the issue

[alexkads]

Thank you, uninstalling Web Deploy (V4) resolved the issue

I just uninstalled it and WebDeploy worked. Thank you very much, because yesterday I didn't even sleep.

[paulahlers]

Was working yesterday for us, failed today.. removed webdeploy and it worked

[travis-morita]

Same here, uninstalling Web Deploy did the trick, without the need to delete any folders

[Kev8144]

The above temp solution of removing 0.216 contents worked for me except a couple things: 1 - I didn't have version 0.215 to replace 0.216 contents so I used version 0.208 2 - the path for me was C:\azagent\A3_work_tasks\IISWebAppDeploymentOnMachineGroup

[SAPHemlock]

I had this problem when building with the Microsoft hosted agent (default) and deploying onto on-premises IIS servers.

My workaround

On the machine in the deployment group, I went to the IISWebAppDeploymentOnMachineGroup task directory, at: C:\azagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba

I backed up the content of the 0.216.0 directory onto the desktop.

I deleted the content of the 0.216.0 directory

I copied the content of the 0.215.0 directory into 0.216.0

This prevents the build agent from trying to re-download 0.216, and when it uses 0.216, it gets the 0.215 implementation instead, because that's what is in the folder now.

Hope it helps.

Thank you so much. This workaround really fixed the problem.

[ozdreamer]

I had this problem when building with the Microsoft hosted agent (default) and deploying onto on-premises IIS servers.

My workaround

On the machine in the deployment group, I went to the IISWebAppDeploymentOnMachineGroup task directory, at: C:\azagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba

I backed up the content of the 0.216.0 directory onto the desktop.

I deleted the content of the 0.216.0 directory

I copied the content of the 0.215.0 directory into 0.216.0

This prevents the build agent from trying to re-download 0.216, and when it uses 0.216, it gets the 0.215 implementation instead, because that's what is in the folder now.

Hope it helps.

You are a true champ bro. This trick saved my life in the middle of a deployment.

[Afshalkhan]

I had this problem when building with the Microsoft hosted agent (default) and deploying onto on-premises IIS servers.

My workaround

On the machine in the deployment group, I went to the IISWebAppDeploymentOnMachineGroup task directory, at: C:\azagent\A2\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba

I backed up the content of the 0.216.0 directory onto the desktop.

I deleted the content of the 0.216.0 directory

I copied the content of the 0.215.0 directory into 0.216.0

This prevents the build agent from trying to re-download 0.216, and when it uses 0.216, it gets the 0.215 implementation instead, because that's what is in the folder now.

Hope it helps.

Thanks.

[MarkusPopp]

If you are using Agents with TaskZips you have to go into ${AZAGENT}_work_taskzips look for IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba_0.216.0.zip delete (or rename) it and copy IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba_0.215.0.zip to IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba_0.216.0.zip

[patmoe]

The workaround worked.. :-) Thanks...

It looks like a classic bug.. read parameters and split on hyphen ( - )
...but forgetting to skip content inside string deliiters.. My sitename had a hyphen in it - other logs shown in this issue also have paramvalues with hyphen inside.. jm2c

[patrice-sc]

Same here (likely when deploying to folders with a - character). I saw the workaround but it really needs to be fixed please...

[sundar85]

same here, the workaround worked.

[MattJeanes]

The workaround has also worked for us too, although I am wondering why this is still an issue if it has supposedly rolled back? Is it due to us already having the latest version of the task installed already?

[daleua]

Same here ...someone forgot to put those quotes around the msdeploy command :(

[Schwitzd]

same here, any news?

[ruzena-kavanova]

Unistalling Web deploy fixed the issue for me. Thanks for help

[c0shea]

@Pranshu-Negi PR #17247 has broken IIS deployments. Any update on when this will be fixed?

[edgariscoding]

Same issue here with the IISWebAppDeploymentOnMachineGroup task.

On-prem with agent version 2.214.1

Considering this is a task that deploys releases I feel like this should be a very high priority bug, can't believe it's been an issue for two weeks.

[ngiessel]

Same here. Uninstalling Web Deploy from our server fixed it.

[SKO85]

We are using the IISWebAppDeploymentOnMachineGroup task that deploys the application to an Windows machine to an IIS setup. I can confirm that uninstalling Web Deploy v4 from the server via Apps & Features worked in our case. Tested this on our testing machine. I assume the agent got updated and that this does not work well if Web Deploy was previously installed on the machine.

[kapilsharma749]

Uninstalling Web Deploy worked for me .

It is now Deploying the files at the location I needed with correct files from the package created(WebApp.zip)

We know the reason but the Question is why Web Deploy install was creating issue ??

[caco0516]

Uninstalled the web deploy 3.6 from the web server as we are doing deployment through pipelines only, resolved our issue. I am using Cloud-based Azure DevOps services and deploying into VM which hosts IIS, using IIS Web App Deploy task.

Thanks !!! this worked for me . Im using web deploy in a pipeline release stage.