WebDeploy (401) Unauthorized error
Asked Answered
V

10

30

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)

Virginity answered 26/1, 2011 at 16:27 Comment(3)
Exactly the same problem hereHeptangular
Note to others: if your error message does NOT include the 'v1' error, then it's a different cause. In my case, it was a UAC-related thing, as described and fixed here: networkprogramming.wordpress.com/2010/10/29/…Truck
A registry hack that fixes administrative shares also fixes this, and seems to be a UAC token issue. Use this MS fix: support.microsoft.com/en-gb/kb/947232Solange
C
56

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.

Churchwoman answered 29/1, 2011 at 0:15 Comment(5)
Adding this registry setting seems to have fixed the issue. Can you explain a little about what this setting is or point me to MSDN?Virginity
You can also configure this option from the UI. If you go to the "Management Service" in InetMgr.exe and check "Windows Credentials", that registry value will be set to 1 and RequiresWindowsCredentials will be set to 0. If you will check "Windows credentials or IIS Managert credentials", then both values will be set to 1.Churchwoman
Basically, before going through Web Management Service (WmSvc) with Web Deploy, you need to make sure it is properly configured on the server. Using UI is the best way to go about this.Churchwoman
Just a note for anyone adding this reg key manually - learn from the 3 hours I've just wasted troubleshooting a deployment and make sure you don't accidentally paste a trailing space into the key name! Gah.Impedimenta
You are the BEST!! I just spent HOURS trying to figure out the stupid 401 authorization error.Goodtempered
M
5

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.

Macarthur answered 28/7, 2011 at 21:15 Comment(1)
MSDeploy does use administrative shares when using the tempAgent (aka "Web Deploy on Demand") feature: technet.microsoft.com/en-us/library/ee517345(v=ws.10).aspxGrimbald
M
4

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.

Mingle answered 19/11, 2014 at 23:47 Comment(0)
T
3

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.

Traditional answered 27/1, 2011 at 23:19 Comment(0)
L
2

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.

Lohengrin answered 27/12, 2011 at 21:56 Comment(0)
F
1

If your user is an admin, but you still get

ERROR_USER_IS_NOT_ADMIN

make sure that you are using the fully qualified user name.

MyMachineName\MyWebDeployUser

Frowsy answered 27/4, 2012 at 15:33 Comment(1)
Or DomainName\MyWebDeployUser.Libre
C
1

Yesterday i was able to deploy just fine, today had this exact same error message. After an hour or two of troubleshooting I ended up removing the domain from my username. Where before it was DOMAIN\username, I changed it to just [username], lo' and behold, it started working again. I know this isn't a great answer, but maybe it will help someone else who runs across it.

Callicrates answered 17/10, 2014 at 15:36 Comment(1)
For me it was just the opposite... I had to add my domain name in front of my username, like this: DOMAIN\usernameQuad
B
0

My problem was that the Network Services was the Logon Account in the Web Deploy Agent Service and it Account hasn't sufficient permissions to change or read IIS Files...

To solve your problem just do the following steps:

Open the Services Panel (services.msc)
Find the Web Deploy Agent Service and Double click to open the Web Deploy Agent Service properties... At Log On tab change the "Log on as" to a Administrator Account...

Boltrope answered 28/3, 2013 at 20:32 Comment(0)
L
0

Web Deploy stopped working for us yesterday when using the current Windows user's identity (it worked with explicit credentials) after installing the patches for MS15-025 and MS15-027 on one of our domain controllers that is running Windows Server 2003.

We checked all recommendations for Web Deploy and could not resolve the HTTP 401.2 error.

Now, Microsoft reissued the patches for both bulletins specifically for Windows Server 2003 (KB3033395-v2 and KB3002657-v2). After installing the updated patches and booting the domain controller, it worked again immediately. We didn't even had to restart any service on the Web server.

There were no Event Log entries pointing to this, it only became obvious because of the temporal relation.

Landis answered 17/3, 2015 at 0:36 Comment(0)
R
0

There's another possibility: your account has been locked out due to too many failed attempts to deploy with web deploy. Reset your account or have your system administrator do that for you. Very frustrating.

Recognition answered 2/11, 2017 at 3:21 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.