msdeploy (Web Deploy) error con 401 números de autenticación

Question

Estoy tratando de instalar msdeploy y configurarlo. He instalado el servicio remoto en el servidor web, pero todas mis pruebas me dan un 401 unauthorised error. El servidor es Windows 2008 R2.

Estoy probando un simple comando de MSDeploy:

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

Y el 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. 

he creado un usuario llamado MSDeploy y añadí al grupo de administradores locales en el servidor .

He comprobado:

• Que el servicio instalado correctamente y lo empecé
• Varias combinaciones de no utilizar la parte de dominio del nombre de usuario, y la adición de authType = básicas
• Dados los permisos a esa carpeta para todos
• En IIS permitir conexiones remotas
• Reglas de delegación de servicio de administración agregadas para mi usuario "msdeploy" para contentPath e iisApp (basado libremente en rea ding this)
• Probado con una cuenta de administrador diferente utilizo para RDC al servidor ...
• probaron con diferentes contentPaths y diferentes comandos MSDeploy
• crea una cuenta específica, y ha añadido que cuenta para los IIS_Users. Agregué ese usuario a mi sitio web "Permisos del Administrador IIS" y configuré "Delegación del Servicio de Administración" para todos los proveedores.

Answer 1

estoy suponiendo que haya configurado el servidor correctamente para WebDeploy 2.0 de acuerdo con este artículo:

Configure Web Deploy (IIS.NET)

Nota: MS han lanzado una actualización de Web Deploy 2.0 y el enlace original ISN' t realmente valido más. He actualizado esto, pero creo que será un objetivo móvil en el tiempo.

También necesita instalar Web Deploy 2.0 en su máquina de desarrollo/construcción/CI.

Si todavía está utilizando la versión 1.0, le recomiendo que actualice, hay algunas mejoras importantes en la versión 2.0.

El uso de Visual Studio 2010 publica Característica:

Visual Studio puede publicar un sitio haciendo clic derecho en el sitio y seleccionando la opción "Publicar".Esto nos lleva a la siguiente diálogo:

Hay un par de pifias con Visual Studio 2010 y WebDeploy 2.0. El primero es que VS2010 no es consciente de WebDeploy/MSDeploy 2.0. Así que si intenta publicar obtendrá un error como el siguiente:

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

También verá el siguiente error en la solicitud ha fallado seguimiento para el servicio de administración web en el servidor de C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 suponiendo que tiene esta encendido:

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.

La letra de la unidad variará alojamiento a qué unidad se encuentra su sitio IIS.

Fuera de la caja, el mecanismo de publicación en la GUI usa de manera predeterminada la versión incorrecta de MSDeploy (1.0). Queremos decirle a VS2010 que use MSDeploy 2.0. Usted puede hacer esto mediante la edición de Visual Studio archivo de 2010 devenv.exe.config que se encuentra en (suponiendo que hizo un c:\ unidad de instalación por defecto):

para 64 sistemas de bits: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE para 32 sistemas de bits: c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

abren devenv.exe.config en el editor de XML favorito (acabo de utilizar Visual Studio 2010 sí mismo) y copiar el siguiente código XML:

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

añadir esto a la sección /configuration/runtime/assemblyBinding:

Una vez que haya hecho esto, cierre todas las instancias de Visual Studio 2010 para permitir que este cambio surta efecto. Reinicie VS2010, abra un proyecto web y luego intente publicar de nuevo. Esta vez debería ser exitoso.

Publishing utilizando una creación del paquete:

Visual Studio puede producir una creación del paquete que se puede ejecutar desde la línea de comandos. Esto se genera usando Project -> Build Deployment Package. Práctico para la integración continua y similares (el paquete también se puede generar usando msbuild con el interruptor /t:Package).

La carpeta de salida para el paquete suele tener como valor predeterminado obj\Package.

Desafortunadamente, Visual Studio 2010 obtiene esto un poco mal y genera una secuencia de comandos por lotes envoltura msdeploy objetivo 1.0 y la implementación de destino en el servidor en lugar de nivel del sitio.

No hay una solución rápida para esto aparte de crear su propia línea de comando msdeploy.exe. He dividido esta en varias líneas para hacer esto un poco más legible .:

 
"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 

La primera cosa a destacar es el camino a msdeploy.exe. Visual Studio genera una ruta a la versión 1.0. Cambié esto para usar 2.0.

parámetros notables:

-source:archiveDir= brinda información sobre MSDeploy estamos implementación de un paquete y proporciona la ubicación local

computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' - dice esto MSDeploy para desplegar a un sitio específico en IIS7. yoursitename debe coincidir exactamente con el nombre del sitio en IIS.

userName y password son el nombre del usuario de administrador delegado para el sitio. Esto se configura mediante la función "Permisos del Administrador IIS" en el nivel del sitio. La cuenta debe ser una cuenta de usuario de Windows local.

-authtype='basic' - esto fuerza la autenticación básica, de lo contrario se intenta la autenticación NTLM.

-allowuntrusted - esto ignora cualquier error de certificado SSL si utiliza el certificado SSL autofirmado incorporado.

Si usa esa línea de comando, entonces debería ser capaz de implementar en un servidor remoto IIS7 con éxito.

Publishing Raw Contenido:

A veces queremos publicar sólo algunas de contenido estático (o tal vez incluso un ASP clásico o sitio PHP) directamente desde una carpeta local. Podemos hacer esto utilizando la línea de comandos msdeploy.exe siguiente:

 
"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 

Una vez más las mismas reglas se aplican como antes para -dest:contentPath y computerName.

Creo que los problemas de la versión de MSDeploy se resolverán en SP1 (que aún no he podido ver).

Una final VS2010 Gotcha:

Al publicar utilizando Visual Studio 2010, el "Publicar" construir el paquete hace que el ACL de la cuenta anónima del sitio para cambiar a sólo lectura para todos los archivos y carpetas con la excepción de la carpeta App_Data que se cambia a Lectura y escritura.

Esto se puede evitar mediante la adición de la siguiente configuración en el fichero de .csproj en cada <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">:

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination> 

O si está usando msbuild:

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

encontré esa pepita útil a partir de aquí:

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

Answer 2

Nos enfrentamos a un problema similar al suyo.

Para esto, necesita iniciar el servicio de agente remoto en los servicios. Utilizamos el nombre de la PC porque la dirección IP estaba dando un error. Intente utilizar el nombre de la computadora, el nombre de usuario y la contraseña.

Answer 3

Al final, nunca sospeché qué p faltan permisos con mi cuenta de usuario de implementación, pero descubrí que si utilizaba la cuenta de administración de máquina, la implementación tendría éxito. Por ahora estoy usando la cuenta de administrador para hacer la implementación.

Felicitaciones a Kev para el fantástico e informativo resumen de la configuración de MS despliegan 2 :)

Answer 4

Para mí, la edición trabajaron en Visual Studio, pero no funcionó cuando me encontré con el guión .deploy.cmd.

Al establecer <UseMsdeployExe>true</UseMsdeployExe> en su .csproj, puede forzar a VS a usar msdeploy.exe en lugar de una tarea de MSBuild. Luego, al subir el nivel de registro (Herramientas> Opciones> Proyectos y soluciones> Compilar y ejecutar> nivel de detalle de la salida de compilación del proyecto MSBuild), puede ver la línea de comando que VS usa.

Los problemas con mi .deploy.cmd fueron:

• Mi usuario IIS sólo tenía permisos en ese sitio, así que necesitaba ?site=<SITENAME> en el computerName.
• Necesité AuthType='Basic' en el parámetro -dest:.

Answer 5

Por lo que vale la pena. La publicación me funcionaba y un día tuve el mismo problema (401 error no autorizado). El reinicio de VS2012 resolvió el problema. Ojalá lo hubiera intentado antes de probar cualquier otra solución.