iis - studio - MsDeploy remoting ejecutándose manifiesto dos veces

web deployment agent service windows 10

Question

Yo tengo:

1. Creado un manifiesto para msdeploy a:
   Detenga, desinstale, copie, instale e inicie un servicio de Windows.
2. Creado un paquete del manifiesto
3. Ejecutamos msdeploy contra el paquete contra un servidor remoto.

Problema: ejecuta el manifiesto completo dos veces.

Intenté: he jugado con el waitInterval y waitAttempts pensando que se estaba agotando y comenzando de nuevo, pero eso no tiene ayuda.

Pregunta: ¿Qué podría estar haciendo que se ejecute dos veces?

El Manifiesto

<sitemanifest>
<runCommand path="net stop TestSvc"
waitInterval="240000"
waitAttempts="1"/>
<runCommand
path="C:/Windows/Microsoft.NET/Framework/v4.0.30319/installutil.exe /u
C:/msdeploy/TestSvc/TestSvc/bin/Debug/TestSvc.exe"
waitInterval="240000"
waitAttempts="1"/>
<dirPath path="C:/msdeploy/TestSvc/TestSvc/bin/Debug" />
<runCommand
path="C:/Windows/Microsoft.NET/Framework/v4.0.30319/installutil.exe
C:/msdeploy/TestSvc/TestSvc/bin/Debug/TestSvc.exe"
waitInterval="240000"
waitAttempts="1"/>
<runCommand path="net start TestSvc"
waitInterval="240000"
waitAttempts="1"/>
</sitemanifest>

El comando emitido para empaquetarlo:

"C:/Program Files/IIS/Microsoft Web Deploy V2/msdeploy"
-verb:sync
-source:manifest=c:/msdeploy/custom.xml
-dest:package=c:/msdeploy/package.zip

El comando emitido para ejecutarlo:

"C:/Program Files/IIS/Microsoft Web Deploy V2/msdeploy"
-verb:sync
-source:package=c:/msdeploy/package.zip
-dest:auto,computername=<computerNameHere>

Me estoy ejecutando como un usuario de dominio que tiene acceso administrativo en el cuadro. También he intentado pasar credenciales, no es un problema de permisos, los comandos están teniendo éxito, solo se ejecutan dos veces.

Editar:

He habilitado -verbose y encontré algunas líneas interesantes en el registro:

Verbose: realizar el pase de sincronización n. ° 1.

...

Verbose: Source filePath (C: / msdeploy / MyTestWindowsService / MyTestWindowsService / bin / Debug / MyTestWindowsService.exe) no coincide con el destino (C: / msdeploy / MyTestWindowsService / MyTestWindowsService / bin / Debug / MyTestWindowsService.exe) que difieren en los atributos (lastWriteTime [ ''11 / 08/2011 23:40:30 '','' 11/08/2011 23:39:52 '']). Actualización pendiente

Verbose: Source filePath (C: / msdeploy / MyTestWindowsService / MyTestWindowsService / bin / Debug / MyTestWindowsService.pdb) no coincide con el destino (C: / msdeploy / MyTestWindowsService / MyTestWindowsService / bin / Debug / MyTestWindowsService.pdb) que difieren en los atributos (lastWriteTime [ ''11 / 08/2011 23:40:30 '','' 11/08/2011 23:39:52 '']). Actualización pendiente

Después de estas líneas, los archivos no se copian la primera vez, sino que se copian por segunda vez

...

Verbose: la comprobación de dependencia ''DependencyCheckInUse'' no encontró problemas.
Verbose: respuesta recibida del agente (estado HTTP ''OK'').
Verbose: al pase de sincronización actual le falta contenido de transmisión para 2 objetos.

Verbose: realizar el pase de sincronización n. ° 2.

...

Nivel alto

Normalmente despliego un paquete recién construido con bits más nuevos que los que están en el servidor.

Durante el pase dos, duplica todo lo que se hizo en el pase uno.

En el paso 1, será:

• Detener, Desinstalar, (eliminar algunos archivos de registro creados por la instalación del servicio), Instalar e Iniciar un servicio de Windows

En el paso 2, será:

• Detener, desinstalar, copiar archivos , instalar e iniciar un servicio de Windows.

No tengo idea de por qué no copia los archivos en el pase 1, o por qué se activa el pase 2.

Si vuelvo a implementar el mismo paquete en lugar de implementar nuevos bits, ejecutará todos los pasos en el pase 1 y no ejecutará el pase 2. Probablemente porque los archivos tienen el mismo sello de tiempo.

Answer 1

No hay suficiente información en la pregunta para reproducir realmente el problema para dar una respuesta específica ... pero hay varias cosas que verificar / cambiar / intentar hacer que esto funcione:

• runCommand necesita privilegios específicos
• waitInterval="240000" y waitAttempt="1" (comillas dobles en lugar de comillas simples)
• permisos para el servicio de despliegue / agente de despliegue con respecto a directorios, etc. en la máquina de destino
• usar la función tempAgent
• trabajar a través de la sección de solución de problemas esp. los registros y prueba las opciones -whatif y -whatif

EDITAR - después de la adición de la salida -verbose :

Veo estas posibilidades:

• Hora
  Ambas máquinas tienen una diferencia en el tiempo (cualquiera de ellas está un poco desconectada o tiene algún problema con la zona horaria ...)
• Sistema de archivos
  Si uno de los sistemas de archivos es FAT, esto podría ocasionar problemas (resolución de la marca de tiempo ...)

EDIT 2 - según los comentarios:

En mi última EDITACIÓN escribí sobre la marca de tiempo porque sospecho que algo va mal cuando se comparan ... que pueden ser, por ejemplo, relojes diferentes entre ambas máquinas (incluso una diferencia de 30 segundos puede tener un impacto) y / o alguna zona horaria cuestiones...

Escribí sobre el sistema de archivos esp. FAT ya que la resolución de la marca de tiempo de FAT es de aproximadamente 2 segundos, mientras que NTFS tiene una resolución mucho mayor, una vez más esto podría tener un impacto al comparar las marcas de tiempo ...

De lo que describes, sugeriría las siguientes soluciones:

• use preSync y postSync para las partes de manejo del servicio (es decir, preSync para detener + desinstalar y postSync para instalar + iniciar) y solo realice la sincronización pura en el manifiesto o la línea de comando
  O
• use una secuencia de comandos para las partes runCommand

EDIT 3 - según el comentario de Merlyn Morgan-Graham el resultado para referencia futura:

Cuando use el proveedor de runCommand , use archivos por lotes. Por alguna razón, esto hizo que dejara de ejecutar dos pases.

El problema con esta solución es que no se puede especificar el directorio de instalación del servicio a través de un archivo SetParameters.xml (lo mismo para dontUseCommandExe / preSync / postSync respecto a SetParameters.xml ).

EDIT 4 - según el comentario de Merlyn Morgan-Graham:

Los parámetros de tiempo de espera se aplican a si matar ese comando específico, no al cierre del Servicio de Windows en sí ... en este caso, parece que el Servicio de Windows tarda bastante en detenerse y, por lo tanto, solo se runCommand los runCommand sin la copia / sincronización y se inicia una nueva prueba para la ejecución completa ...

Answer 2

Tuve el mismo problema, pero no hago el archivo package.zip. Realizo la sincronización directamente en un solo paso. La solución preSync / postSync me ayudó mucho y no es necesario usar archivos de manifiesto. Puede probar el siguiente comando en su caso:

"C:/Program Files/IIS/Microsoft Web Deploy V2/msdeploy"
-verb:sync
-preSync:runCommand="net stop TestSv && C:/Windows/Microsoft.NET/Framework/v4.0.30319/installutil.exe /u
C:/msdeploy/TestSvc/TestSvc/bin/Debug/TestSvc.exe",waitInterval=240000,waitAttempts=1
-source:dirPath="C:/msdeploy/TestSvc/TestSvc/bin/Debug"
-dest:auto,computername=<computerNameHere>
-postSync:runCommand="C:/Windows/Microsoft.NET/Framework/v4.0.30319/installutil.exe
C:/msdeploy/TestSvc/TestSvc/bin/Debug/TestSvc.exe && net start TestSvc",waitInterval=240000,waitAttempts=1

El parámetro "-verb: sync" significa que sincroniza datos entre una fuente y un destino. En su caso, su caso, la primera vez que realiza la sincronización entre la carpeta "C: / msdeploy / TestSvc / TestSvc / bin / Debug" y el "package.zip". Además, está utilizando el archivo de manifiesto, por lo que cuando realiza una segunda sincronización entre el "package.zip" y el destino "nombre de equipo", msbuild usa el manifiesto proporcionado previamente dos veces para el destino y el origen, por lo que cada operación de manifiesto se ejecuta dos veces. Usé el truco && para realizar varios comandos en una línea de comando. Además, en mi caso, tuve que agregar la operación de tiempo de espera para asegurarme de que el servicio se detuvo por completo ("ping -n 30 127.0.0.1> nul").