2011-01-26 13 views
27

estoy recibiendo un error no autorizado desde MSDeploy mediante la autenticación NTLM cuando se trata de desplegar de forma remota una aplicación que utiliza un usuario de Windows que no es un administrador local en el servidor de destino. Tengo reglas de configuración en la delegación del servicio de administración en la casilla de destino con todos los proveedores marcados. Bajo esta regla, he agregado 2 usuarios con permisos de permiso ('*' y mi usuario de Windows que está realizando la implementación remota). Además, le he dado permiso al usuario de Windows en el sitio que estoy tratando de implementar. Si hago que el usuario de Windows sea un administrador local en el cuadro de destino y configuro 'Permitir a los administradores omitir reglas', la implementación funciona correctamente. Si el usuario de Windows no es un administrador local me sale el siguiente error:WebDeploy (401) de error no autorizado

Web deployment task failed.(Remote agent (URL http://xxxxxxxx/MSDEPLOYAGENTSERVICE) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator. Error details: Remote agent (URL http://xxxxx/MSDEPLOYAGENTSERVICE) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was 'V1' but 'v1' was expected. The remote server returned an error: (401) Unauthorized. in Microsoft.Web.Publishing.targets(3588, 5)

+0

Exactamente el mismo problema aquí –

+7

Nota para otros: si su mensaje de error NO incluye el error 'v1', entonces es una causa diferente. En mi caso, era algo relacionado con el UAC, como se describe y soluciona aquí: http://networkprogramming.wordpress.com/2010/10/29/401-not-authorized-for-msdeploy%E2%80%8F- msdeployagentservice/ –

+0

Un hack de registro que corrige los recursos compartidos administrativos también corrige esto, y parece ser un problema de token UAC. Use esta reparación de MS: https://support.microsoft.com/en-gb/kb/947232 –

Respuesta

48

Si configura delegación a "permitir a los administradores de pasar por alto las reglas" y el comando MSDeploy tiene éxito, entonces usted está pasando por WMSVC y que le está dejando pasar. De lo contrario, a partir de la respuesta, parece que WMSvc te está rechazando y te estás volviendo al agente de Web Deloy.

Set/agregue el siguiente valor de registro a WMSVC reg clave:

reg add HKLM\Software\Microsoft\WebManagement\Server /v WindowsAuthenticationEnabled /t REG_DWORD /d 1

reciclaje WMSVC:

net stop wmsvc & net start wmsvc

vuelve a intentarlo. Si no tiene éxito, puede publicar su línea de comando msdeploy.

+1

Agregar esta configuración de registro parece haber solucionado el problema. ¿Puedes explicarme un poco sobre qué es esta configuración o dirigirme a MSDN? – cfbarbero

+9

También puede configurar esta opción desde la IU. Si va al "Management Service" en InetMgr.exe y marca "Windows Credentials", ese valor de registro se establecerá en 1 y RequiresWindowsCredentials se establecerá en 0.Si marca "Credenciales de Windows o credenciales de administración de IIS", ambos valores se establecerán en 1. – kateroh

+1

Básicamente, antes de pasar por el Servicio de administración web (WmSvc) con Web Deploy, debe asegurarse de que esté configurado correctamente en el servidor . Usar la IU es la mejor manera de hacerlo. – kateroh

3

No está seguro de la causa exacta, pero puede ser capaz de ayudar ya encontrar su camino.

WebDeploy utiliza dos puntos de entrada en base a la configuración del servidor remoto, es decir si su IIS6 correr o IIS7.

IIS 7 usa el controlador de despliegue IIS , que es administrado por el Servicio de administración web y permite que msdeploy suministre directamente IIS. Todos los ajustes de "delegación de servicio de administración", etc. se relacionan con esta configuración.

IIS 6, sin embargo, no tiene el servicio de administración web para que el manejador no va a funcionar. Para destinos IIS6, se utiliza un servicio llamado MS Deploy Agent Service.

Lo que es extraño es que su configuración sugiere que esté utilizando IIS 7, ya que fue capaz de establecer la configuración de delgación, etc. Sin embargo, esa url, "/ MSDEPLOYAGENTSERVICE" sugiere que su máquina está intentando usar el servicio ... casi como si pensara que es IIS 6. El servicio requiere acceso de administrador, por lo que está obteniendo ese error.

Con base en el error parece que se está invocando esto desde MSBUILD, probablemente directamente desde Visual Studio. Es posible que desee mirar alrededor de la configuración que se le da y ver si hay algo allí que está causando esta selección de ruta y/o servidor.

También asegúrese de que el Web Management Service se esté ejecutando en la máquina remota.

Básicamente, desea verlo realizar llamadas a una URL diferente, http: // <> /msdeploy.axd (si no recuerdo mal) para invocar correctamente el controlador.

5

tenemos una máquina que hemos estado implementando como parte de nuestro proceso de construcción. Sin ninguna razón obvia, la implementación dejó de funcionar y ya no podíamos acceder remotamente a ninguna de las acciones administrativas (C $, ADMIN $, etc.).Encontramos una solución para las acciones administrativas que también solucionó los problemas de implementación.

Seguimos el paso en este artículo de KB para volver a habilitar las acciones administrativas (todavía no tengo idea de por qué de repente dejaron de funcionar).

http://support.microsoft.com/kb/947232

Después de que hicimos eso, MSDeploy, de repente, empezó a trabajar de nuevo también. No pensé que msdeploy usara recursos administrativos en absoluto. Ni siquiera estoy seguro de que los dos estén relacionados en absoluto, pero pensé que lo tiraría allí en caso de que resuelva el problema de alguien más.

+1

MSDeploy utiliza recursos compartidos administrativos cuando se usa la función tempAgent (también conocida como "Web Deploy on Demand"): http://technet.microsoft.com/en-us/library/ee517345(v=ws.10).aspx –

2

Esto consumió demasiadas horas de mi tiempo. Ya tenía Web Deploy trabajando para mis otros sitios. Decidí agregar un nuevo sitio web a mi servidor e intenté implementarlo (pero dejé accidentalmente el mismo nombre "Sitio/aplicación" debido a un error excesivo de copiar/pegar). La publicación tuvo éxito, pero cuando me di cuenta de que publiqué en el sitio equivocado (en lugar del nuevo), cambié el nombre del sitio e intenté volver a implementarlo, pero seguí recibiendo este error. Intenté todo en el final de IIS. Finalmente, cerré mi instancia de Visual Studio 2010 por completo. Lo abrí de nuevo, intenté publicar de nuevo y ¡funcionó!

En caso de duda, pregúntese: "¿Ha intentado apagarlo y volverlo a encender?"
Me doy cuenta de que este consejo no ayudará a todos con este error ambiguo, solo unos pocos.

0

Si el usuario es un administrador, pero aún así obtener

ERROR_USER_IS_NOT_ADMIN

asegurarse de que está utilizando el nombre de usuario completo.

MyMachineName\MyWebDeployUser

0

Creo que su problema es realmente sencilla ... que tenía el mismo problema que usted ...

De hecho, mi problema era que los servicios de red fue la cuenta de conexión en el Distribuir agente Web servicio y cuenta tiene no suficientes permisos para cambiar o leer archivos de IIS ...

para resolver su problema simplemente hacer los pasos siguientes:

Abra la Painel Servicios (services.msc)
Encuentra la Web Implementar Servicio Agente y doble clic para abrir los Web Implementar Servicio Agente propiedades ... En la ficha Iniciar sesión cambiar el "Iniciar sesión como" a una cuenta de administrador ...

Espero ayuda

0

Ayer pude desplegar muy bien, hoy tuve exactamente el mismo mensaje de error. Después de una o dos horas de resolución de problemas, terminé eliminando el dominio de mi nombre de usuario. Donde antes estaba [domain]/[username], lo cambié a simplemente [username], lo 'y he aquí, comenzó a funcionar nuevamente. Sé que esta no es una gran respuesta, pero tal vez ayude a alguien más a encontrarla.

4

Finalmente pude obtener mi compilación automatizada e implementar en ejecución usando NTLM. Solo quería resumir lo que se necesitó para ponerlo en marcha en caso de que sea útil para cualquiera. Esto es con IIS 7.5.

  1. Establecer la configuración del Registro y reinicie Servicio de administración web (WMSVC):

    reg add HKLM \ Software \ Microsoft \ WebManagement \ Server/v WindowsAuthenticationEnabled/t REG_DWORD/d 1

  2. Dar el usuario que ejecuta el permiso de servicio de compilación TFS en el directorio del sitio web.

  3. Aquí están los argumentos de MSBuild que utilicé. Reemplace los diferentes nombres con sus nombres. Estaba usando DEV y Any CPU. También necesitaba permitir un certificado que no sea de confianza.

    /m/p: PublishProfile = DEV/p: Configuración = DEV/p: Plataforma = "Cualquier CPU"/p: DeployOnBuild = true/p: AllowUntrustedCertificate = true/p: authType = NTLM

  4. En el Administrador de IIS con el sitio web de destino seleccionado, abra Permisos del Administrador IIS y permita que el usuario ejecute el servicio de compilación TFS.

El seguimiento fue muy útil en el diagnóstico de los problemas. Puede activar el rastreo en Delegación del servicio de administración en el Administrador de IIS. Inicialmente no pude ver la Delegación del Servicio de Gestión en el Administrador de IIS. Para llegar a mostrar, tuve que 'cambiar' Web Deploy desde Agregar Programas para que se instalara la Delegación del Servicio de Administración. Parecía que estaba instalado, pero restablecí el menú desplegable para instalar en mi computadora y completé la instalación. Luego apareció en el Administrador de IIS.

0

Web Implementar dejó de funcionar para nosotros ayer cuando se utiliza la identidad del actual usuario de Windows (que trabajó con credenciales explícitas) después de instalar los parches para MS15-025 y MS15-027 en uno de nuestros controladores de dominio que ejecuta Windows Server 2003.

Verificamos todas las recomendaciones para Web Deploy y no pudimos resolver el error HTTP 401.2.

Ahora, Microsoft volvió a emitir los parches para ambos boletines específicamente para Windows Server 2003 (KB3033395-v2 y KB3002657-v2). Después de instalar los parches actualizados y arrancar el controlador de dominio, funcionó nuevamente de inmediato. Ni siquiera tuvimos que reiniciar ningún servicio en el servidor web.

No hubo entradas del Registro de eventos que señalaran esto, solo se hizo obvio debido a la relación temporal.

0

Hay otra posibilidad: su cuenta se ha bloqueado debido a demasiados intentos fallidos para implementar con la implementación web. Restablezca su cuenta o pida a su administrador de sistema que haga eso por usted. Muy frustrante.

Cuestiones relacionadas