WebDeploy (401) Unauthorized error

Question

I'm getting an unauthorized error from MsDeploy using NTLM authentication when trying to remotely deploy an application using a windows user who is not a local admin on the destination server. I have setup rules in the Management Service Delegation on the destination box with all providers checked. Under this rule I have added 2 users with allow permissions ('*', and my windows user that is doing the remote deploy). Additionally, I have given the windows user permission on the site I'm trying to deploy. If I make the windows user a local admin on the destination box and set 'Allow administrators to bypass rules', the deploy works correctly. If the windows user is not a local administrator I get the following error:

Web deployment task failed.(Remote agent (URL http://xxxxxxxx/MSDEPLOYAGENTSERVICE) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator. Error details: Remote agent (URL http://xxxxx/MSDEPLOYAGENTSERVICE) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was 'V1' but 'v1' was expected. The remote server returned an error: (401) Unauthorized. in Microsoft.Web.Publishing.targets(3588, 5)

Solution 1

If you configure delegation to "Allow administrators to bypass rules" and msdeploy command succeeds, then you are going through WMSvc and it is letting you through. Otherwise, from the response it seems that WMSvc is rejecting you and you are falling back to Web Deloy agent.

Set/add the following reg value to WMSvc reg key:

reg add HKLM\Software\Microsoft\WebManagement\Server /v WindowsAuthenticationEnabled /t REG_DWORD /d 1

Recycle WMSvc:

net stop wmsvc & net start wmsvc

Try again. If it doesn't succeed, can you post your msdeploy command line.

Solution 2

We have a machine that we have been deploying to as part of our build process. For no obvious reason, deploys stopped working and we could no longer remotely access any of the administrative shares (C$, ADMIN$, etc.). We found a fix for the administrative shares which also fixed the deployment problems.

We followed the step in this KB article to re-enable the administrative shares (still no idea why they suddenly stopped working).

http://support.microsoft.com/kb/947232

After we did that, msdeploy all of a sudden started working again as well. I didn't think msdeploy used administrative shares at all. I'm not even positive the two are related at all, but I thought I'd throw it out there in case it solves anyone else's problem.

Solution 3

I was finally able to get my automated build and deploy running using NTLM. I just wanted to summarize what it took to get it going in case it is helpful to anyone. This is with IIS 7.5.

1. Set the registry setting and restart Web Management Service (WMSVC):

   reg add HKLM\Software\Microsoft\WebManagement\Server /v WindowsAuthenticationEnabled /t REG_DWORD /d 1

2. Give the user running the TFS build service permission in the web site directory.

3. Here are the MSBuild arguments that I used. Replace the various names with your names. I was using DEV and Any CPU. I also needed to allow an untrusted certificate.

   /m /p:PublishProfile=DEV /p:Configuration=DEV /p:Platform="Any CPU" /p:DeployOnBuild=true /p:AllowUntrustedCertificate=true /p:authType=NTLM

4. In IIS Manager with the destination web site selected, open IIS Manager Permissions and allow the user running the TFS build service.

Tracing was very helpful in diagnosing the problems. You can turn on tracing in Management Service Delegation in IIS Manager. Initially I couldn't see Management Service Delegation in IIS Manager. To get to show I had to 'change' Web Deploy from Add Programs so that Management Service Delegation was installed. It looked like it was installed, but I reset the dropdown to install to my computer and completed the install. Then it appeared in IIS Manager.

Solution 4

Not sure on the exact cause, but may be able to help ya find your way.

WebDeploy uses two entry points based on the configuration of the remote server, namely whether its running IIS6 or IIS7.

IIS 7 uses the IIS deployment handler, which is managed by the Web Management Service and allows msdeploy to directly provision IIS. All the "management service delegation", etc settings relate to this setup.

IIS 6, however, doesn't have the web management service so the handler will not work. For IIS6 targets, a service called the MS Deploy Agent Service is used.

Whats odd is that your setup suggests your are using IIS 7, as you were able to set delgation settings, etc. However, that url, "/MSDEPLOYAGENTSERVICE" suggests that your machine is attempting to use the service ... almost as if it thinks its IIS 6. The service requires admin access, which is why you are getting that error.

Based on the error it looks like you are invoking this from MSbuild, likely directly from Visual Studio. You may want to look around the settings you are given and see if anything in there is causing this path and/or server selection.

Also make sure the Web Management Service is running on the remote machine.

Basically you're wanting to see it make deploy calls to a different url, http://<>/msdeploy.axd (if I remember correctly) to properly invoke the handler.

Solution 5

This ate up way too many hours of my time. I already had Web Deploy working for my other sites. I decided to add a new website to my server, and tried to deploy to it (but accidentally left the same "Site/application" name due to an overzealous copy/paste error). The publish succeeded, but when I realized I published to the wrong site (instead of the new site), I changed the site name and tried re-deploying but I kept getting this error. I tried everything on the IIS end of things. Finally, I just shut down my Visual Studio 2010 instance entirely. Opened it back up, tried the publish again and it worked!

When in doubt, ask yourself, "Have you tried turning it off and turning it on again?"
I realize this advice won't help everyone with this ambiguous error - just a select few.

View more solutions