сбой msdeploy (веб-развертывания) из-за 401 проблемы с аутентификацией

Question

Я пытаюсь получить msdeploy установлен и настроен.Я установил удаленную службу на веб-сервере, но все мои тесты дают мне 401 unauthorised error.Сервером является Windows 2008 R2.

Я тестирую очень простую команду msdeploy:

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

И ошибка:

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.

Я создал пользователя с именем msdeploy и добавил его в локальную группу администраторов на сервере.

Я проверил:

• Что служба установлена правильно, и я запустил ее
• Различные комбинации отказа от использования доменной части имени пользователя и добавления AuthType=Basic
• Всем предоставлены полные права доступа к этой папке
• В IIS разрешить удаленные подключения
• Добавлены правила делегирования службы управления для моего пользователя "msdeploy" для contentPath и iisApp (свободно основанные на чтении это)
• Пробовал с другой учетной записью администратора, которую я использую для RDC на сервере...
• Пробовал использовать разные пути к контенту и разные команды msdeploy
• Создал конкретную учетную запись и добавил эту учетную запись в IIS_Users.Добавил этого пользователя на мой веб-сайт "Разрешения диспетчера IIS" и настроил "Делегирование службы управления" для всех поставщиков.

Answer 1

Я предполагаю, что вы правильно настроили свой сервер для WebDeploy 2.0 в соответствии с этой статьей:

Настройка веб-развертывания (IIS.NET)

Примечание: MS выпустила обновление Web Deploy 2.0, и исходная ссылка на самом деле больше не действительна.Я обновил это, но я думаю, что со временем это будет движущаяся цель.

Вам также необходимо установить Web Deploy 2.0 на вашем компьютере для разработки / сборки / CI.

Если вы все еще используете 1.0, то я рекомендую обновить, в 2.0 есть несколько огромных улучшений.

Использование функции публикации Visual Studio 2010:

Visual Studio может опубликовать сайт, щелкнув по нему правой кнопкой мыши и выбрав "Опубликовать".Это приводит к следующему диалогу:

Есть пара ошибок с Visual Studio 2010 и WebDeploy 2.0.Во-первых, VS2010 не поддерживает WebDeploy / MSDeploy 2.0.Поэтому, если вы попытаетесь опубликовать, вы получите сообщение об ошибке, подобное следующему:

Ошибка 1 Задача веб-развертывания выполнена с ошибкой.((04/02/2011 12:30:40) При обработке запроса на удаленном компьютере произошла ошибка .)

Вы также увидите следующую ошибку при неудачной трассировке запросов для службы веб-управления на сервере в C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 предполагая, что у вас это включено:

AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
Отслеживание данных о событиях исключение агента развертывания.Идентификатор запроса ".Временная метка запроса:'02/04/2011
Система.Исключение UnauthorizedAccessException:Доступ к пути 'D:\' запрещен.

Буква диска будет варьироваться в зависимости от того, на каком диске расположен ваш сайт IIS.

Из коробки механизм публикации в графическом интерфейсе пользователя по умолчанию использует неправильную версию MSDeploy (1.0).Мы хотим сказать VS2010 использовать MSDeploy 2.0.Вы можете сделать это, отредактировав Visual Studio 2010 devenv.exe.config файл, который находится в (при условии, что вы установили значение по умолчанию c:\ установка привода):

Для 64-битных систем: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE Для 32-разрядных систем: c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

Откройся devenv.exe.config в вашем любимом редакторе XML (я только что использовал саму Visual Studio 2010) и скопируйте следующий xml:

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

Добавьте это к /configuration/runtime/assemblyBinding Раздел:

После того, как вы сделаете это, закройте все экземпляры Visual Studio 2010, чтобы это изменение вступило в силу.Перезапустите VS2010, откройте веб-проект и затем попробуйте опубликовать еще раз.На этот раз все должно пройти успешно.

Публикация с использованием пакета сборки:

Visual Studio может создать пакет сборки, который может быть выполнен из командной строки.Это генерируется с помощью Project -> Build Deployment Package.Удобно для непрерывной интеграции и т.п. (пакет также может быть сгенерирован с помощью msbuild с /t:Package переключатель).

Выходная папка для пакета обычно по умолчанию имеет значение obj\Package.

К сожалению, Visual Studio 2010 немного ошибается и генерирует пакетный скрипт-оболочку msdeploy, предназначенный для версии 1.0 и предназначенный для развертывания на сервере, а не на уровне сайта.

Для этого нет быстрого решения, кроме как создать свою собственную msdeploy.exe командную строку.Я разделил это на несколько строк, чтобы сделать текст немного более читабельным.:

"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

Первое, на что следует обратить внимание, - это путь к msdeploy.exe.Visual Studio генерирует путь к версии 1.0.Я изменил это, чтобы использовать 2.0.

Примечательные параметры:

-source:archiveDir= сообщает msdeploy, что мы развертываем пакет, и указывает локальное расположение

computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' - это указывает MSDEPLOY на развертывание на определенном сайте в IIS7. yoursitename должно точно совпадать с названием сайта в IIS.

userName и password are - это имя делегированного пользователя manager для сайта.Это настраивается с помощью функции "Разрешения диспетчера IIS" на уровне сайта.Учетная запись должна быть локальной учетной записью пользователя Windows.

-authtype='basic' - это принудительно запускает базовую аутентификацию, в противном случае предпринимается попытка аутентификации NTLM.

-allowuntrusted - это игнорирует любые ошибки SSL-сертификата, если вы используете встроенный самозаверяющий SSL-сертификат.

Если вы используете эту командную строку, то сможете успешно выполнить развертывание на удаленном сервере IIS7.

Публикация необработанного контента:

Иногда мы хотим просто опубликовать какой-нибудь статический контент (или, возможно, даже классический сайт на ASP или PHP) непосредственно из локальной папки.Мы можем сделать это, используя следующее msdeploy.exe командная строка:

"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 

Опять же, для -dest:contentPath и computerName.

Я полагаю, что проблемы с версией MSDeploy будут решены в SP1 (на который у меня еще не было возможности взглянуть).

Один Финальный матч ПРОТИВ 2010 Попался:

При публикации с использованием Visual Studio 2010 пакет сборки "Опубликовать" приводит к изменению ACL анонимной учетной записи сайта на доступ только для чтения для всех файлов и папок, за исключением App_Data папка, которая изменена на чтение и запись.

Это можно обойти, добавив следующий параметр в .csproj файл под каждым <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">:

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

Или, если вы используете msbuild:

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

Я нашел этот полезный самородок здесь:

Пропуск настройки списка управления доступом в пакете развертывания Visual Studio 2010 (Ссылка на WayBackMachine, поскольку исходный контент больше недоступен)

Answer 2

Для меня публикация работала в Visual Studio, но она не сработала, когда я запустил .deploy.cmd сценарий.

Установив <UseMsdeployExe>true</UseMsdeployExe> в вашем .csproj, вы можете заставить VS использовать msdeploy.exe вместо задачи MSBuild.Затем, повысив уровень ведения журнала (Инструменты> Параметры> Проекты и решения > Сборка и запуск > Детализация вывода сборки проекта MSBuild), вы можете увидеть командную строку, которую использует VS.

Проблемы с моим .deploy.cmd были:

• У моего пользователя IIS были разрешения только на этот сайт, поэтому мне нужно было ?site=<SITENAME> в computerName.
• Мне нужно было AuthType='Basic' в -dest: параметр.

Answer 3

Мы столкнулись с такой же проблемой, как у вас.

Для этого вам необходимо запустить службу удаленного агента в сервисах.Мы использовали имя компьютера, потому что IP-адрес выдавал ошибку.Поэтому попробуйте использовать имя компьютера, имя пользователя и пароль.

Answer 4

В конце концов, я так и не выяснил, каких разрешений мне не хватало в моей учетной записи пользователя deploy, но обнаружил, что если бы я использовал учетную запись администратора компьютера, развертывание прошло бы успешно.На данный момент я использую учетную запись администратора для выполнения развертывания.

Спасибо Кеву за фантастическое и информативное краткое описание настройки ms deploy 2 :)

Answer 5

Чего бы это ни стоило.Публикация работала у меня, и затем однажды у меня возникла та же проблема (401 несанкционированная ошибка), перезапуск VS2012 решил проблему.Жаль, что я не попробовал это до того, как опробовать любое другое решение.