Web Deploy IIS Authentication Troubleshooting – Fix ‘User Unauthenticated’ Errors

Problem: Web Deploy works on test server, fails on production

You’ve got a working publish profile. Credentials are correct. It deploys fine to your test IIS box. But hitting production gives you “user unauthenticated” or ERROR_DESTINATION_INVALID. Same password, different server.

This is one of the most common Web Deploy headaches. Let’s walk through exactly why it happens and how to fix it.

How Web Deploy authentication actually works

When your publish profile uses MSDeployPublishMethod=WMSVC (Web Management Service), here’s what happens under the hood:

1. Your machine sends credentials to WMSVC on the IIS server (typically port 8172)
2. WMSVC authenticates you – this is where “user unauthenticated” occurs
3. If auth succeeds, WMSVC impersonates your identity for every operation (writing files, modifying web.config, touching app pools)

This is pass-through impersonation. The app pool identity is irrelevant for deployment – it only matters when the site runs. Your identity flows through to every server-side action.

The error means authentication fails at step 2 – WMSVC rejects your login before impersonation even begins.

Root causes – ranked by likelihood

1. User not in IIS Manager Permissions (most common)

Your domain account must be explicitly granted permission on the site, not just the server.

Check: IIS Manager ? select the site ? IIS Manager Permissions. If your user isn’t listed, click Allow User and add it.

Testing servers often have broader permissions. Production servers are locked down. This is the #1 mismatch.

2. Management Service Delegation rules

Server-level: IIS Manager ? server node ? Management Service Delegation.

Every deployment verb (contentPath, iisApp, setAcl, etc.) needs a delegation rule that covers your user or group. If rules only apply to a specific AD group and you’re not in it, auth fails.

Compare the delegation rules between test and production servers – they often differ.

3. WMSVC authentication type mismatch

WMSVC supports Basic and Windows authentication. If production requires Windows auth but your publish profile sends Basic (or vice versa), it breaks.

Check: IIS Manager ? server ? Management Service ? check which authentication types are enabled. Your pubxml authType (or default) must match.

4. Account-specific restrictions

Production may have:

• Different domain or OU with logon restrictions
• “Allow log on locally” not granted to your account on the server
• Account disabled or password expired in Active Directory
• IP restrictions on the WMSVC binding

Diagnostic checklist

Check WMSVC logs on the server

C:\inetpub\logs\wmsvc\WMSvc.log

Look for your username and the HTTP status code:

• 401 – bad credentials or auth type mismatch
• 403 – authenticated but not authorized (missing IIS Manager Permissions or delegation)
• 500 – server-side error after auth

Windows Security Event Log

Get-WinEvent -LogName Security -MaxEvents 20 | Where-Object { .Message -match "yourUsername" }

Shows exact reason for failed logon attempts.

Compare WMSVC config between servers

Get-WebConfiguration -Filter "system.webServer/management" -PSPath "MACHINE/WEBROOT/APPHOST"

Run on both test and production. Diff the output. Look for differences in authorization and authentication sections.

Test connectivity with msdeploy.exe

msdeploy.exe 
  -verb:dump 
  -source:contentPath="SiteName",computerName="https://SERVER:8172/MSDeploy.axd?site=SiteName",userName="DOMAIN\username",password="password",authType=basic 
  -whatif

Run this from your machine targeting the production server. If it fails, run it on the server targeting localhost to isolate network vs. auth issues.

Quick fix: bypass domain auth with IIS Manager Users

If domain authentication is the bottleneck and you need to deploy now, create a local IIS Manager user on the production server:

# Run on production IIS server as administrator
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Web.Management")
Y29udHJpYnV0b3I6MWtQTyAycGZiIFFrOGMgdFVlSyBVcHZ2IEZ5dWc= = New-Object Microsoft.Web.Management.Server.ManagementAuthentication
Y29udHJpYnV0b3I6MWtQTyAycGZiIFFrOGMgdFVlSyBVcHZ2IEZ5dWc=.CreateUser("deployuser", "StrongPassword123!")

Then:

1. IIS Manager ? select your site ? IIS Manager Permissions ? Allow User ? deployuser
2. Update your pubxml: change <UserName> from DOMAIN\username to just deployuser
3. Enter the password when Visual Studio prompts (or set it in pubxml)

This bypasses domain auth entirely. The local IIS Manager user is managed by WMSVC itself, not Windows or Active Directory.

Production-ready configuration

For a properly configured production environment:

• Use a dedicated AD service account for deployments (not personal accounts)
• Grant that account IIS Manager Permissions on all deployable sites
• Configure delegation rules scoped to the service account
• Enable only Windows authentication on WMSVC (disable Basic if possible)
• Use IP restrictions to limit WMSVC access to build server IPs
• Keep WMSVC logs enabled for audit trails

Quick reference: pubxml settings

<PropertyGroup>
  <WebPublishMethod>MSDeploy</WebPublishMethod>
  <MSDeployServiceURL>yourserver.domain.com</MSDeployServiceURL>
  <DeployIisAppPath>YourSiteName</DeployIisAppPath>
  <MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
  <UserName>DOMAIN\username</UserName>     <!-- or local IIS Manager user -->
  <_SavePWD>true</_SavePWD>               <!-- save encrypted password -->
  <EnableMSDeployBackup>true</EnableMSDeployBackup>
  <EnableMsDeployAppOffline>true</EnableMsDeployAppOffline>
</PropertyGroup>

Summary

When Web Deploy works on test but not production with the same password:

1. Check IIS Manager Permissions on the production site first
2. Compare delegation rules and WMSVC auth config between servers
3. Read the WMSVC log – it tells you exactly why auth failed
4. If stuck, create a local IIS Manager user on production to bypass domain auth

Almost always, it’s a permissions gap – not a password problem.