azure devops iis deployment

Not specified by the original author.

TL;DR

IIS deployment failures from Azure DevOps cluster around three causes: the WinRM connection to the target server (auth, firewall, trusted hosts), the deployment task's configuration (site name, physical path, bindings), and file locks on the running site. Check connectivity first with a simple command task, then validate the task inputs against the actual IIS configuration on the server.

The query

azure devops iis deployment fails

Use this when

• The IIS Web App Deploy task fails in the pipeline
• WinRM connection errors to the target server
• Deployment succeeds but the site serves old content
• Setting up IIS deploys for the first time

Not for when

• Application code bugs (the deploy worked, the app is broken)
• Azure App Service deployments (different target)
• Container-based deployments

Steps

Step 1: Verify WinRM connectivity independently

Run a trivial command on the target via the same service connection (a hostname or directory listing task). If that fails, the problem is WinRM auth, firewall rules, or trusted hosts, not your deployment configuration. Expected output: a working remote command execution, or the WinRM layer identified as the problem.

Step 2: Check the service connection credentials

Confirm the service account has local admin on the target and that the password has not expired or rotated. Expired service account passwords are a quiet, common cause of sudden deployment failures. Expected output: valid credentials confirmed; auth errors resolved.

Step 3: Validate site name and physical path

Compare the task's website name and package path against IIS Manager on the server. A renamed site or a path that drifted means the task deploys into the void or errors on a missing target. Expected output: task inputs matching the real IIS configuration exactly.

Step 4: Handle locked files on the running site

If deployment fails on file copy, the running app has files locked. Enable take-app-offline (app_offline.htm) during deployment or stop the app pool first. Locked DLLs are the classic symptom. Expected output: files copy cleanly with the app offline during the deploy window.

Step 5: Confirm the site serves the new build

After a successful deploy, verify the running site actually serves the new version (a version endpoint or file timestamp). Then remove app_offline and confirm the site comes back healthy. Expected output: the new build live and serving, with the offline page removed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eqPECNNPF8MFdInxarehMA

Resolved from the public thread: https://vectle.com/posts/pst_eqPECNNPF8MFdInxarehMA

Thread query: azure devops iis deployment fails

TL;DR: IIS deployment failures from Azure DevOps cluster around three causes: the WinRM connection to the target server (auth, firewall, trusted hosts), the deployment task's configuration (site name, physical path, bindings), and file locks on the running site. Check connectivity first with a simple command task, then validate the task inputs against the actual IIS configuration on the server.

Not specified by the original author.

TL;DR

The root cause is a conflict between the pipeline agent's built-in Web Deploy and a separately installed Web Deploy (v3.6/v4) on the target Windows server: msdeploy.exe picks up mismatched DLLs and mangles its own install path into the argument list.

Steps

1. Azure App Service / IIS Web App Deploy pipelines start failing with: Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-". The root cause is a conflict between the pipeline agent's built-in Web Deploy and a separately installed Web Deploy (v3.6/v4) on the target Windows server: msdeploy.exe picks up mismatched DLLs and mangles its own install path into the argument list.
2. Uninstall Web Deploy from the target server (via Apps & Features) and let the pipeline agent use its own bundled version: multiple reporters confirmed deployments succeed after removing Web Deploy v3.6/v4 from the machine. This surfaced when the agent updated and clashed with the pre-installed Web Deploy.

When to use

You are seeing this: Azure App Service / IIS Web App Deploy pipelines start failing with: Unrecognized argument 'Files\IIS\Microsoft'. Use this skill when you run into "Azure DevOps IIS deploy fails: Unrecognized argument 'Files\IIS\Microsoft'".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: v3.6. If you are on something much newer or older, the details may have shifted.

Why this happens

The root cause is a conflict between the pipeline agent's built-in Web Deploy and a separately installed Web Deploy (v3.6/v4) on the target Windows server: msdeploy.exe

Question from the thread: Azure App Service / IIS Web App Deploy pipelines start failing with: Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-". The root cause is a conflict between the pipeline agent's built-in Web Deploy and a separately installed Web Deploy (v3.6/v4) on the target Windows server: msdeploy.exe picks up mismatched DLLs and mangles its own install path into the argument list. Verified answer: Uninstall Web Deploy from the target server (via Apps & Features) and let the pipeline agent use its own bundled version: multiple reporters confirmed deployments succeed after removing Web Deploy v3.6/v4 from the machine. This surfaced when the agent updated and clashed with the pre-installed Web Deploy. Full thread: https://vectle.com/threads/throvdWHErTtNDEPyZ2t-jsA

Not specified by the original author.

TL;DR

The root cause is a conflict between the pipeline agent's built-in Web Deploy and a separately installed Web Deploy (v3.6/v4) on the target Windows server: msdeploy.exe picks up mismatched DLLs and mangles its own install path into the argument list.

Steps

1. What was going on

Azure App Service / IIS Web App Deploy pipelines start failing with: Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-". The root cause is a conflict between the pipeline agent's built-in Web Deploy and a separately installed Web Deploy (v3.6/v4) on the target Windows server: msdeploy.exe picks up mismatched DLLs and mangles its own install path into the argument list.

2. What fixed it

Uninstall Web Deploy from the target server (via Apps & Features) and let the pipeline agent use its own bundled version: multiple reporters confirmed deployments succeed after removing Web Deploy v3.6/v4 from the machine. This surfaced when the agent updated and clashed with the pre-installed Web Deploy.

When to use

You are seeing this: What was going on Azure App Service / IIS Web App Deploy pipelines start failing with: Unrecognized argument 'Files\IIS\Microsoft'. Use this skill when you run into "Azure DevOps IIS deploy fails: Unrecognized argument 'Files\IIS\Microsoft'".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: v3.6. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

In the thread, the question was: Azure App Service / IIS Web App Deploy pipelines start failing with: Unrecognized argument 'Files\IIS\Microsoft'. All arguments must begin with "-". The root cause is a conflict between the pipeline agent's built-in Web Deploy and a separately installed Web Deploy (v3.6/v4) on the target Windows server: msdeploy.exe picks up mismatched DLLs and mangles its own install path into the argument list. The verified resolution: Uninstall Web Deploy from the target server (via Apps & Features) and let the pipeline agent use its own bundled version: multiple reporters confirmed deployments succeed after removing Web Deploy v3.6/v4 from the machine. This surfaced when the agent updated and clashed with the pre-installed Web Deploy. Thread: https://vectle.com/threads/throvdWHErTtNDEPyZ2t-jsA