[Solved] How to Resolve Web Deploy Issues Related to Expired Passwords

If you’re using Web Deploy to deploy your web applications, you may encounter an issue where the deployment fails with an error message similar to the one below:

Microsoft.Web.Delegation.DeploymentAuthorizationException: Not able to log on the user '.\WDeployConfigWriter'. ---> System.Runtime.InteropServices.COMException: The password for this account has expired. (Exception from HRESULT: 0x80070532) --- End of inner exception stack trace --- at

This error indicates that the password for the WDeployConfigWriter account has expired, which is a known issue with Web Deploy. The installer creates users with expiring passwords that are used to elevate permissions during deployment.

In this post, we’ll walk you through the steps you can take to resolve this issue and prevent it from happening again in the future.

Step 1: Check the event logs

The first step is to check the event logs on the destination computer to confirm that the issue is related to an expired password. By default, Web Deploy logs to the Event Log under Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> WebDeploy. It’s a great place to start looking for errors on the destination server.

You can also enable logging for successful deployments by opening the properties of the Info log under the Web Deploy folder in the Event Viewer, and checking Enable logging. The next time a deployment is done, you’ll see everything in there. By default, only the Error and ConnectionInfo logs are enabled, and the ConnectionInfo log doesn’t show who did what so it’s not very useful.

Step 2: Update the password settings for the WDeployAdmin and WDeployConfigWriter accounts

Once you’ve confirmed that the issue is related to an expired password, the next step is to update the password settings for the WDeployAdmin and WDeployConfigWriter accounts on the destination computer. Here’s how you can do this:

1. On the destination computer, open Computer Management and navigate to Local Users and Groups > Users.
2. Right-click on WDeployAdmin and select Properties.
3. Uncheck the option User must change password at next logon and check the option Password never expires.
4. Repeat the above steps for the WDeployConfigWriter user.

Step 3: Reset the passwords for Management Service Delegation rules (optional)

The next step is to reset the passwords for any Management Service Delegation rules where the WDeployConfigWriter or WDeployAdmin accounts have been configured to elevate to a specific user. Here’s how you can do this:

1. Open IIS Manager and navigate to Management Service Delegation.
2. Reset the passwords for all rules where the WDeployConfigWriter or WDeployAdmin accounts have been configured to elevate to a specific user.

After completing these steps, try deploying again and see if the issue is resolved.

We hope this guide helps you resolve any issues you may encounter with Web Deploy related to expired passwords. If you have any further questions or need additional assistance, please don’t hesitate to reach out.

Important Note: Ensure the correct Application Pool is used

In our recent site update we encountered an issue because we had updated the site but did not set the correct .NET CLR version for the Application Pool in Internet Information Services (IIS).

To avoid similar problems, please follow these steps:

1. Open IIS Manager.
2. Navigate to Sites → find your site → Right-click the site → Manage → Advanced Settings…
3. In the Advanced Settings dialog, locate the Application Pool entry and check which pool is assigned.
4. If necessary, click the ellipsis (… ) next to the Application Pool entry to select the correct pool.
5. Then navigate to Application Pools in IIS Manager, locate that pool → Right-click → Basic Settings… (or Advanced Settings… depending on your version).
6. Check that the .NET CLR version (or .NET CLR Version / Managed Runtime Version) is set to v4.0 (or equivalent for .NET 4.x frameworks).

In our case, the CLR version was not updated and still pointed to an older setting, so even though the site files were updated to target .NET 4.x, the pool was not correctly set to use CLR v4.0, which caused compatibility / runtime issues.

According to Microsoft documentation, when creating or configuring an application pool you must set the managedRuntimeVersion attribute (for IIS7+ systems) appropriately — e.g., "v4.0" for .NET Framework 4.0/4.5+. Microsoft Learn

Key takeaway: Always confirm that the Site is using the right Application Pool, and that the Pool’s CLR version matches the runtime target of your application. That extra check can save save hours of frustration when something breaks after deployment.