msdeploy(Web部署)因401 auth问题而失败 [英] msdeploy (Web Deploy) failing with 401 auth issues

查看:215
本文介绍了msdeploy(Web部署)因401 auth问题而失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试安装和设置 msdeploy 。我在Web服务器上安装了远程服务,但我的所有测试都给了我 401未经授权的错误。服务器是Windows 2008 R2。



我正在测试一个非常简单的msdeploy命令:

  msdeploy -verb:dump -source:contentPath = c:\inetpub \wwwroot \ MyApp,computerName =< IP HERE> ;,userName = Domain\msdeploy,password = MyPassword 

错误:

 错误:对象键入'contentPath'并且无法创建路径'c:\inetpub \wwwroot \ MediaApp'。 
错误:无法联系远程代理(URL http://< IP HERE> / MSDEPLOYAGENTSERVICE)。确保在目标计算机上安装并启动了远程代理服务。
错误:收到了不支持的响应。响应头'MSDeploy.Response'是''但是'v1'是预期的。
错误:远程服务器返回错误:(401)未经授权。
错误计数:1。

我创建了一个名为msdeploy的用户,我将其添加到服务器上的本地管理员组。



我已经检查过:




  • 服务安装正确且我开始了它

  • 不使用用户名域名部分的各种组合,并添加authType = Basic

  • 赋予每个人对该文件夹的完全权限

  • 在IIS中允许远程连接

  • 为contentPath和iisApp的msdeploy用户添加了管理服务委派规则(松散地基于读取(WayBackMachine链接因为原始内容不再可用)



    I'm trying to get msdeploy installed and set up. I've installed the remote service on the web server, but all my tests are giving me a 401 unauthorised error. The server is Windows 2008 R2.

    I'm testing a very simple msdeploy command:

    msdeploy -verb:dump -source:contentPath=c:\inetpub\wwwroot\MyApp,computerName=<IP HERE>,userName=Domain\msdeploy,password=MyPassword
    

    And the error:

    Error: Object of type 'contentPath' and path 'c:\inetpub\wwwroot\MonApp' cannot be created.
    Error: Remote agent (URL http://<IP HERE>/MSDEPLOYAGENTSERVICE) could not be contacted.  Make sure the remote agent service is installed and started on the target computer.
    Error: An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected.
    Error: The remote server returned an error: (401) Unauthorized.
    Error count: 1.
    

    I created a user called msdeploy and I added it to the local admins group on the server.

    I've checked:

    • That the service installed properly and I started it
    • Various combinations of not using the domain part of the username, and adding authType=Basic
    • Given full permissions to that folder to everyone
    • In IIS allow remote connections
    • Added Management Service Delegation rules for my "msdeploy" user for contentPath and iisApp (loosely based on reading this)
    • Tried with a different admin account I use for RDC to the server...
    • Tried with different contentPaths and different msdeploy commands
    • Created a specific account, and added that account to the IIS_Users. Added that user to my web site "IIS Manager Permissions", and setup "Management Service Delegation" for all providers.

    解决方案

    I'm assuming you've configured your server correctly for WebDeploy 2.0 as per this article:

    Configure Web Deploy (IIS.NET)

    Note: MS have released a refresh of Web Deploy 2.0 and the original link isn't really valid any more. I've updated this but I think it'll be a moving target over time.

    You also need to install Web Deploy 2.0 on your development/build/CI machine.

    If you're still using 1.0 then I recommend upgrading, there are some huge improvements in 2.0.

    Using Visual Studio 2010's Publish Feature:

    Visual Studio can publish a site by right clicking on the site and selecting "Publish". This brings up the following dialogue:

    There are a couple of gotcha's with Visual Studio 2010 and WebDeploy 2.0. The first is that VS2010 isn't WebDeploy/MSDeploy 2.0 aware. So if you try to publish you will get an error such as the following:

    Error 1 Web deployment task failed.((04/02/2011 12:30:40) An error occurred when the request was processed on the remote computer.)

    You'll also see the following error in the Failed Request Tracing for the web management service on the server in C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 assuming you have this turned on:

    AspNetModuleDiagErrorEvent
    Uri /msdeploy.axd
    eventData Tracing deployment agent exception. Request ID ''. Request Timestamp: '02/04/2011
    System.UnauthorizedAccessException: Access to the path 'D:\' is denied.

    The drive letter will vary according to which drive your IIS site is located on.

    Out of the box, the in-GUI Publish mechanism defaults to using the wrong version of MSDeploy (1.0). We want to tell VS2010 to use MSDeploy 2.0. You can do this by editing Visual Studio 2010's devenv.exe.config file which is located in (assuming you did a default c:\ drive install):

    For 64 bit systems: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE For 32 bit systems: c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

    Open up devenv.exe.config in your favourite XML editor (I just used Visual Studio 2010 itself) and copy the following xml:

    <dependentAssembly>
      <assemblyIdentity 
        name="Microsoft.Web.Deployment" 
        publicKeyToken="31bf3856ad364e35" culture="neutral"/>
      <bindingRedirect oldVersion="7.1.0.0" newVersion="8.0.0.0"/>
    </dependentAssembly>
    

    Add this to the /configuration/runtime/assemblyBinding section:

    Once you've done this close all instances of Visual Studio 2010 to allow this change to take effect. Restart VS2010, open a web project and then try to publish again. This time it should be successful.

    Publishing using a Build Package:

    Visual Studio can produce a Build Package that can be executed from the command line. This is generated using Project -> Build Deployment Package. Handy for continuous integration and the like (the package can also be generated using msbuild with the /t:Package switch).

    The output folder for the package usually defaults to obj\Package.

    Unfortunately Visual Studio 2010 gets this a bit wrong and generates a msdeploy wrapper batch script targetting 1.0 and targetting deployment at the server rather than site level.

    There's no quick fix for this other than to craft your own msdeploy.exe command line. I've split this across several lines to make this a bit more readable.:

    "C:\Program Files\IIS\Microsoft Web Deploy v2\\msdeploy.exe"
      -source:archiveDir='d:\sites\DemoApp\obj\Package\Archive' 
      -dest:
           auto,
           computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename',
           userName='demosite',
           password='somepassword',
           authtype='basic',
           includeAcls='False' 
      -verb:sync 
      -disableLink:AppPoolExtension 
      -disableLink:ContentExtension 
      -disableLink:CertificateExtension 
      -setParamFile:"d:\sites\DemoApp\obj\Package\Archive.SetParameters.xml"   
      -allowuntrusted
    

    The first thing to note is the path to msdeploy.exe. Visual Studio generates a path to version 1.0. I've changed this to use 2.0.

    Notable parameters:

    -source:archiveDir= tells msdeploy we're deploying a package and provides the local location

    computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' - this tells MSDEPLOY to deploy to a specific site on IIS7. yoursitename should exactly match the name of the site in IIS.

    userName and password are is the name of the delegated manager user for the site. This is configured using the "IIS Manager Permissions" feature at the site level. The account needs to be a local Windows user account.

    -authtype='basic' - this forces basic authentication otherwise NTLM authentication is attempted.

    -allowuntrusted - this ignores any SSL certificate errors if you use the built-in self signed SSL cert.

    If you use that command line then you should be able to deploy to a remote IIS7 server with success.

    Publishing Raw Content:

    Sometimes we want to just publish some static content (or maybe even a Classic ASP or PHP site) directly from a local folder. We can do this using the following msdeploy.exe command line:

    "C:\Program Files\IIS\Microsoft Web Deploy v2\\msdeploy.exe" 
      -source:contentPath='d:\websites\mysite' 
      -dest:
         contentPath='yoursitename',
         computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename',
         userName='demosite',
         password='somepassword',
         authtype='basic',
         includeAcls='False' 
    -verb:sync 
    -allowuntrusted 
    

    Again the same rules apply as before for -dest:contentPath and computerName.

    I believe the MSDeploy version issues will be resolved in SP1 (which I haven't had a chance to look at yet).

    One Final VS2010 Gotcha:

    When publishing using Visual Studio 2010, the "Publish" build package causes the ACL's of the site's anonymous account to change to Read Only for all files and folders with the exception of the App_Data folder which is changed to Read and Write.

    This can be worked around by adding the following setting to the .csproj file under each <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">:

    <IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>
    

    Or if you're using msbuild:

    msbuild.exe myproject.csproj /t:Package /p:IncludeSetAclProviderOnDestination=False
    

    I found that useful nugget from here:

    Skipping setting an ACL in a Visual Studio 2010 deployment package (WayBackMachine link because the original content is no longer available)

    这篇关于msdeploy(Web部署)因401 auth问题而失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆