Сбой msdeploy (Web Deploy) с проблемами аутентификации 401
Я пытаюсь получить 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 на сервер...
- Пробовал с разными contentPaths и разными командами msdeploy
- Создал конкретную учетную запись и добавил эту учетную запись в IIS_Users. Добавил этого пользователя на мой веб-сайт "Разрешения диспетчера IIS" и настроил "Делегирование службы управления" для всех поставщиков.
5 ответов
Я предполагаю, что вы правильно настроили свой сервер для WebDeploy 2.0 согласно этой статье:
Примечание: 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 Задача веб-развертывания завершилась неудачно.((02.04.2011, 12:30:40) Произошла ошибка при обработке запроса на удаленном компьютере.)
Вы также увидите следующую ошибку в Трассировке невыполненных запросов для службы веб-управления на сервере в C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1
при условии, что у вас это включено:
AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
eventData Исключение агента развертывания трассировки. Запросить идентификатор ''. Отметка времени запроса: '02 / 04/2011
System.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:\ сайтов \DemoApp\ OBJ \ Пакет \ Архив' -dest: авто, имя_компьютер ='https://yoursite.com:8172/msdeploy.axd сайт =yoursitename', Имя пользователя ='demosite', пароль ='somepassword', AuthType='основной', includeAcls='False' -verb: синхронизация -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"D:\ сайтов \DemoApp\ OBJ \ Пакет \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 - это имя делегированного менеджера пользователя для сайта. Это настраивается с помощью функции "Разрешения диспетчера 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: \ сайтов \ MySite' -dest: contentPath='yoursitename', имя_компьютер ='https://yoursite.com:8172/msdeploy.axd сайт =yoursitename', Имя пользователя ='demosite', пароль ='somepassword', AuthType='основной', includeAcls = 'False' -verb: синхронизация -allowuntrusted
Опять те же правила применяются, как и раньше для -dest:contentPath
а также computerName
,
Я полагаю, что проблемы с версией MSDeploy будут решены в SP1 (на который у меня еще не было возможности взглянуть).
Один финал VS2010
При публикации с использованием 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, поскольку исходное содержимое больше не доступно)
Для меня публикация работала в Visual Studio, но она не работала, когда я запускал .deploy.cmd
скрипт.
Установив <UseMsdeployExe>true</UseMsdeployExe>
в вашем .csproj
, вы можете заставить VS использовать msdeploy.exe вместо задачи MSBuild. Затем, подняв уровень ведения журнала (Инструменты> Параметры> Проекты и решения> Построить и запустить> Детализация вывода сборки проекта MSBuild), вы увидите командную строку, которую использует VS.
Проблемы с моим .deploy.cmd
мы:
- У моего пользователя IIS были только разрешения на этом сайте, поэтому мне нужно было
?site=<SITENAME>
вcomputerName
, - мне было нужно
AuthType='Basic'
в-dest:
параметр.
Мы столкнулись с той же проблемой, что и вы.
Для этого вам нужно запустить службу удаленного агента в сервисах. Мы использовали имя ПК, потому что IP-адрес выдавал ошибку. Поэтому попробуйте использовать имя компьютера, имя пользователя и пароль.
В конце концов, я так и не выяснил, какие разрешения мне не хватало в моей учетной записи развертывания, но обнаружил, что, если я использую учетную запись администратора компьютера, развертывание будет успешным. Сейчас я использую учетную запись администратора для развертывания.
Престижность Kev для фантастического и информативного резюме настройки ms deploy 2:)
Для чего это стоит. Публикация работала для меня, и однажды у меня возникла та же проблема (401 несанкционированная ошибка). Перезапуск VS2012 решил эту проблему. Жаль, что я попробовал это прежде, чем попробовать любое другое решение.