## 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
```text
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