Msdeploy (Web Deploy) с ошибкой 401 auth

Я пытаюсь установить 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 (свободно на основе чтения this)
Пробовал с другой учетной записью администратора, которую я использую для RDC на сервере...
Пробовал с различными contentPaths и разными командами msdeploy
Создал определенную учетную запись и добавил эту учетную запись в IIS_Users. Добавил этого пользователя на мой веб-сайт "Разрешения диспетчера IIS" и установил "Делегирование службы управления" для всех поставщиков.

Ответ 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
Трассировка событий исключение агента развертывания. ID запроса ''. Запросить временную метку: '02/04/2011
System.UnauthorizedAccessException: доступ к пути "D: \" отклоняется.

Буква диска зависит от того, на каком диске находится ваш сайт IIS.

По умолчанию механизм публикации в GUI по умолчанию использует неправильную версию 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 script target 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 - это имя делегированного пользователя менеджера для сайта. Это настраивается с использованием функции "Разрешения диспетчера 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 будут решены в пакете обновления 1 (на который у меня еще не было возможности посмотреть).

Один финальный VS2010 Gotcha:

При публикации с использованием 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

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

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

Ответ 2

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

Установив <UseMsdeployExe>true</UseMsdeployExe> в .csproj, вы можете заставить VS использовать msdeploy.exe вместо задачи MSBuild. Затем, подняв уровень ведения журнала (Tools > Options > Projects and Solutions > Build and Run > MSBuild project build output verbosity), вы можете увидеть командную строку, которую использует VS.

Проблемы с моим .deploy.cmd были следующими:

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

Ответ 3

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

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

Ответ 4

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

Престижность Kev за фантастическое и информативное резюме настройки ms deploy 2:)

Ответ 5

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