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.

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