visual-studio-2010 - como - how to update visual studio code

msdeploy(Web Deploy) falla con 401 problemas de autenticación (5)

Estoy tratando de instalar y configurar msdeploy . 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 comando msdeploy muy simple:

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.

Creé un usuario llamado msdeploy y lo agregué al grupo de administradores locales en el servidor.

He comprobado:

Que el servicio se instaló correctamente y lo comencé
Varias combinaciones de no usar el dominio parte del nombre de usuario y agregar authType = Basic
Dado permisos completos a esa carpeta para todos
En IIS permiten conexiones remotas
Se agregaron reglas de delegación del servicio de administración para mi usuario "msdeploy" para contentPath e iisApp (basado en la lectura de this )
Intenté con una cuenta de administrador diferente que uso para RDC en el servidor ...
Probado con diferentes contentPaths y diferentes comandos msdeploy
Creó una cuenta específica y agregó esa cuenta a 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.

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

Felicitaciones a Kev por el fantástico e informativo resumen de la configuración de ms deploy 2 :)

Estábamos enfrentando un problema similar al tuyo.

Para esto, necesita iniciar el servicio de agente remoto en los servicios. Usamos 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.

Para mí, la publicación funcionó en Visual Studio, pero no funcionó cuando ejecuté el script .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 de IIS solo tenía permisos en ese sitio, así que necesitaba ?site=<SITENAME> en computerName .
Necesitaba AuthType=''Basic'' en el parámetro -dest:

Por lo que vale. 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.

Supongo que ha configurado su servidor correctamente para WebDeploy 2.0 según este artículo:

Configurar Web Deploy (IIS.NET)

Nota: MS ha lanzado una actualización de Web Deploy 2.0 y el enlace original ya no es válido. 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 usa 1.0, le recomiendo que actualice, hay algunas mejoras enormes en 2.0.

Uso de la característica de publicación de Visual Studio 2010:

Visual Studio puede publicar un sitio haciendo clic derecho en el sitio y seleccionando "Publicar". Esto abre el siguiente diálogo:

Hay un par de gotcha con Visual Studio 2010 y WebDeploy 2.0. El primero es que VS2010 no es consciente de WebDeploy / MSDeploy 2.0. Por lo tanto, si intenta publicar, obtendrá un error como el siguiente:

Error 1 Error en la tarea de despliegue web. ((02/04/2011 12:30:40) Se produjo un error cuando la solicitud se procesó en la computadora remota.)

También verá el siguiente error en el seguimiento de solicitudes fallidas para el servicio de administración web en el servidor en C:/inetpub/logs/wmsvc/TracingLogFiles/W3SVC1 suponiendo que tiene esto activado:

AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
EventData Tracing deployment agent exception. Solicitud de ID ''''. Fecha y hora de solicitud: ''02 / 04/2011
System.UnauthorizedAccessException: acceso denegado a la ruta ''D: /'.

La letra de la unidad variará según la unidad en la que 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. Puede hacerlo editando el archivo devenv.exe.config Visual Studio 2010 que se encuentra en (suponiendo que haya realizado una instalación predeterminada de c:/ drive):

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

Abre devenv.exe.config en tu editor XML favorito (yo solo uso Visual Studio 2010) y copia el siguiente xml:

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

Agregue 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.

Publicación usando un paquete de compilación:

Visual Studio puede producir un paquete de compilación que se puede ejecutar desde la línea de comandos. Esto se genera utilizando Project -> Build Deployment Package . Útil para la integración continua y similares (el paquete también se puede generar usando msbuild con el modificador /t:Package ).

La carpeta de salida para el paquete generalmente está predeterminada en obj/Package .

Lamentablemente, Visual Studio 2010 se equivoca un poco y genera una secuencia de comandos por lotes de envoltura msdeploy dirigida a 1.0 y apuntar a la implementación en el servidor en lugar de al 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 esto 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

Lo primero a tener en cuenta es la ruta 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= le dice a msdeploy que estamos implementando un paquete y brindamos la ubicación local

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

nombre de usuario y password son el nombre del usuario 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.

- no se puede -allowuntrusted - esto ignora cualquier error de certificado SSL si usa el certificado SSL autofirmado incorporado.

Si usa esa línea de comando, podrá implementarla en un servidor remoto IIS7 con éxito.

Publicación de contenido sin procesar:

A veces queremos simplemente publicar contenido estático (o incluso un sitio ASP clásico o PHP) directamente desde una carpeta local. Podemos hacer esto usando la siguiente línea de comando 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

De nuevo, se aplican las mismas reglas que 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 con Visual Studio 2010, el paquete de compilación "Publicar" hace que las ACL de la cuenta anónima del sitio cambien a Solo 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 .csproj agregando la siguiente configuración al archivo .csproj debajo de cada <PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Debug|AnyCPU'' "> :

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

O si estás usando msbuild:

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

Encontré esa pepita útil de aquí:

Omitir la configuración de una ACL en un paquete de implementación de Visual Studio 2010 (enlace WayBackMachine porque el contenido original ya no está disponible)