¿Cuáles son las ventajas de usar archivos .msi sobre los archivos setup.exe normales?
Tengo la impresión de que la implementación es más fácil en máquinas donde los usuarios tienen pocos permisos, pero no estoy seguro de los detalles.
¿Qué características tiene msiexec.exe que hacen que la implementación sea más fácil que usar escenarios de setup.exe?
¿Algún consejo o truco al implementar aplicaciones .msi?
Respuestas:
Solo algunos beneficios:
Creo que cuando estoy implementando software en un entorno empresarial: la implementación de software a través de MSI es casi agradable. Por el contrario, casi siempre me encuentro temiendo implementar software cuando está en otro contenedor.
Para obtener información adicional sobre la manipulación de instalaciones de MSI, escriba msiexecen el cuadro de diálogo Ejecutar.
ACTUALIZACIÓN, julio de 2018 : un resumen extremadamente comprimido de la información a continuación está disponible en stackoverflow: Los principales beneficios de MSI ( "executive summary"- de algún tipo).
He trabajado en desarrollo como administrador de versiones , ingeniero de construcción , desarrollador de configuración y como empaquetador de aplicaciones e ingeniero de implementación en grandes corporaciones.
Esta es una revisión de las mejores (y peores) características conceptuales y del mundo real de MSI. Los problemas de diseño más comunes encontrados en los archivos MSI se presentan a continuación como una respuesta separada . No pretender estar completo, en realidad es solo un "tugurio cerebral" desordenado, concebido como "esas cosas que no se pueden encontrar en los libros" (probablemente por una buena razón).
También quiero sugerir este artículo de MSDN como una buena lectura: Windows Installer: beneficios e implementación para administradores de sistemas .
En una palabra, MSI trata sobre la estandarización y sobre cómo lidiar con los " olores de implementación " de las tecnologías de instalador heredadas. Una colección completa de diseños de arquitectura de instalación defectuosos que causaron repetidos problemas de implementación.
En general, MSI proporciona un marco completo y estandarizado para el instalador, que también incluye de manera crucial la desinstalación y las características y opciones integradas para el funcionamiento silencioso con una GUI estandarizada que se puede activar de forma remota .
Estas características por sí solas constituyen una mejora masiva con respecto a las tecnologías de instalación anteriores que trataban la desinstalación y la ejecución silenciosa al azar, quizás las características más importantes para la implementación corporativa junto con la administración confiable de paquetes remotos a través de Active Directory o herramientas de administración remota dedicadas como Microsoft SCCM (anteriormente SMS), IBM Tivoli , CA Unicenter y similares.
Alguien duplicó una versión anterior de esta respuesta . Tal vez una lectura más rápida?
MSI desalienta activamente los olores de implementación heredados por diseño. Estos temas se analizan en las secciones posteriores a continuación, pero como una lista rápida, los problemas más reconocibles con los instaladores heredados y la tecnología de implementación anterior eran:
La lista continúa con muchos otros defectos de implementación cruciales y reconocidos . Obviamente, en el mundo de la implementación corporativa surgieron estos problemas con mayor frecuencia, y ha resultado en el negocio del " reempaquetado de aplicaciones ", donde se captura un instalador heredado con tecnologías de escaneo de disco y registro para crear un archivo MSI que cumpla con los estándares para una implementación confiable.
El reempaquetado de aplicaciones es un trabajo especializado y, en general, genera archivos MSI de excelente calidad si lo hacen personas bien informadas, pero no es posible reempaquetar todas las aplicaciones debido a la compleja lógica de registro que debe ejecutarse de manera interactiva para que ciertas aplicaciones funcionen.
En lenguaje sencillo, los beneficios realmente importantes de MSI son (sin ningún orden en particular):
En el mundo real , he encontrado aspectos menos exitosos para incluir parches (muy complejos), MSI-GUI (características simples, bastante complejas, carece de flexibilidad), resistencia (puede causar problemas difíciles de depurar repitiendo problemas de auto reparación ) y la complejidad general de tratar con la tecnología para principiantes (la alta complejidad de las operaciones básicas a veces, por ejemplo, actualizaciones, GUI y los muchos detalles que interactúan causan resultados inesperados, etc.). La velocidad del proceso de instalación también se ha desacelerado considerablemente debido al aumento de la sobrecarga de MSI. Vea algunos consejos para mejorar la velocidad de instalación de MSI .
El resto del texto trata algunos de estos aspectos de MSI con más detalle.
Un archivo MSI es esencialmente una base de datos SQL-Server despojada almacenada como un archivo de almacenamiento estructurado COM , esencialmente un sistema de archivos en un archivo o una colección de flujos de datos. Este es el tipo de archivo utilizado en los documentos de Microsoft Office , y produce un formato estándar que puede revisarse e inspeccionarse , un gran problema para las grandes corporaciones.
Con la excepción de las acciones personalizadas compiladas, un archivo MSI es un cuadro blanco . Si la configuración cambia algo loco, como la configuración de red de todo el sistema, puede verlo utilizando las herramientas adecuadas . La notable excepción son las acciones personalizadas compiladas , que son recuadros negros . Los requisitos del logotipo de Windows requieren que se anoten acciones personalizadas para explicar lo que están haciendo, pero los desarrolladores de configuración a menudo lo ignoran. Esperemos que la llegada de Wix mejore esto.
Para determinar qué hacen realmente esas acciones personalizadas compiladas en un sentido técnico, es necesaria una captura de configuración . Esto casi nunca se hace en mi experiencia. Es más común ponerse en contacto con el proveedor para obtener información si el software necesita aprobación para la implementación corporativa, y luego podría ser la propia aplicación la que impide su uso, y no solo la configuración.
Un MSI se puede personalizar a través de transformaciones para adaptarse a las necesidades y estándares de una organización y al mismo tiempo permitir la interoperabilidad con las actualizaciones del instalador del proveedor. No cambia el instalador en sí, crea su personalización en un archivo separado específico de la organización llamado transformación (archivo .mst) (un fragmento de base de datos o una transacción de cambio si lo desea). Puede desactivar acciones personalizadas y, en general, cambiar, anular o deshabilitar cualquier cosa en el instalador, e incluso puede agregar cosas nuevas, incluidos archivos. Los archivos de transformación también se utilizan a veces para localizar un archivo MSI a diferentes idiomas. Se pueden aplicar varias transformaciones a un solo MSI, aquí hay una muestra con rutas truncadas :
msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Explicación rápida de parámetros:
/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.
Windows Installer mantiene una base de datos completa de todos los elementos que un producto ha instalado en el registro ( HKEY_CLASSES_ROOT \ Installer , ¡nunca cambie nada aquí directamente! Eso también es válido para los expertos).
Puede determinar de manera confiable si un producto está instalado, qué características se instalaron y qué versiones de archivo se instalaron. Además, puede obtener una lista de los parches que se hayan aplicado al producto base, si corresponde. Puede acceder a esta base de datos a través de las API que admiten Win32, COM o .NET utilizando una variedad de herramientas de scripting, configuración y administración como Microsoft SCCM , IBM Tivoli , CA Unicenter, etc.
MSI también abarca los principios de "derechos elevados" que permiten a un usuario restringido activar la instalación de un producto que requiere la instalación de derechos de administrador. Esto es parte de la " función de publicidad " que permite a un administrador poner a disposición de los usuarios los instaladores sin tener que instalarlos en todas las estaciones de trabajo. El instalador en sí debe estar correctamente creado en varias cuentas principales para que este concepto de derechos elevados funcione correctamente. Los usuarios pueden activar la instalación del producto ellos mismos, o la instalación puede ser controlada por un sistema de implementación dedicado como SCCM, Tivoli, Unicenter (empresas más grandes normalmente). No es necesario meterse con derechos de administrador temporales para que todo funcione que suele ser el caso con los instaladores heredados.
La completa base de datos de instalación también garantiza que tenga una visión general completa de los parches instalados y, por lo tanto, la posibilidad de detectar vulnerabilidades de seguridad a través de herramientas de automatización y administración.
Los archivos MSI pueden verificarse con reglas de validación para garantizar que cumplan con una serie de reglas de coherencia interna (denominado ICE) Las corporaciones pueden crear sus propios controles de ICE para hacer cumplir las normas y requisitos corporativos especiales. Esto ayuda mucho con el control de calidad. La razón por la que es posible la validación se debe a la naturaleza autorreferenciada de las bases de datos relacionales y el esquema de base de datos asociado. La base de datos debe ser internamente coherente y cumplir con su propio esquema con respecto a las claves externas, los tipos de datos, el ancho de campo, la versión del esquema, etc. La validación también va más allá y es capaz de detectar defectos y errores lógicos genuinos en el paquete. , no solo formatear y escribir fallas. Por ejemplo, puede detectar archivos o tipos de archivos que se están implementando en destinos de destino erróneos.
La función de instalación de administrador del instalador de Windows proporciona una forma estándar de extraer los archivos fuente de un MSI ( aquí hay información adicional sobre este tema ). Estos archivos de origen se pueden poner en un recurso compartido y estar disponibles para todas las estaciones de trabajo para su instalación. Esto garantiza que las operaciones de reparación, desinstalación y modificación se completen sin solicitar los medios de instalación en CD o similar. Esto es particularmente importante para las operaciones de actualización y parches que pueden requerir acceso a los archivos fuente de las versiones anteriores en circunstancias especiales.
También hay problemas comunes con esta característica de resistencia. La mayoría de los administradores han experimentado máquinas con ciclos cíclicos de reparación automática que nunca parecen detenerse. Siga el enlace para obtener una larga lista de causas de este problema. Y nuevamente, aquí hay una versión más corta que podría ser más fácil de leer.
La instalación de un archivo MSI normalmente desencadenará la creación de un punto de restauración . Además, todos los archivos y elementos de registro reemplazados o sobrescritos durante la instalación se guardarán y restaurarán si la instalación no se completa, salvo los cambios realizados en acciones personalizadas.
Las acciones personalizadas deben implementar su propio soporte de reversión para el cumplimiento del logotipo de Windows. Esto a menudo se ignora, pero implica crear una segunda acción personalizada para deshacer los cambios realizados por la acción personalizada principal.
La reversión asegura que la estación de trabajo se deje en un estado estable incluso si la instalación fallara. El script de reversión real se almacena en una carpeta oculta directamente en la unidad del sistema, generalmente C: \ Config.MSI , y contiene archivos con las extensiones .RBS y .RBF - Archivos de script de reversión . Como es de esperar, los archivos MSI mal diseñados pueden violar las características integradas de Windows aquí, consulte mi otra publicación en este hilo para obtener más detalles.
Hay formas de deshabilitar la reversión y acelerar la instalación. Generalmente no se recomienda, pero aquí hay detalles sobre la propiedad MSIFASTINSTALL y DISABLEROLLBACK . Esta es una característica complicada, pero aquí hay un resumen rápido de reversión .
Aunque es muy complejo, la aplicación de parches en el instalador de Windows está completamente administrada y registrada en el sistema para que se pueda determinar el estado de seguridad de los sistemas al verificar lo que se ha instalado. Las actualizaciones están estandarizadas para algunas variantes básicas, y esto permite que las actualizaciones se realicen con un mayor grado de certeza siempre que pueda manejar la complejidad involucrada. Los sistemas de implementación podrán informar qué actualizaciones fallaron y por qué.
En una vista subjetiva, el parche funciona bien para 2 usos básicos : 1 ) pequeñas revisiones para productos entregados, y 2 ) parchear un producto instalado para corregir su secuencia de desinstalación defectuosa que impide una desinstalación limpia del producto.
Un parche es solo un mecanismo de entrega para una actualización que ya está funcionando . Como tal, es solo un contenedor que es más complicado y propenso a errores que la configuración original en sí. La regla número uno para un parche es que debe ser más pequeño que el MSI original o no hay ninguna razón obvia para entregar un parche. Un parche puede ser enorme rápidamente si se dirige a múltiples versiones de productos.
Windows Installer proporciona una característica de registro estandarizada que es muy superior a las encarnaciones anteriores, aunque casi excesivamente detallada. Los archivos de registro se pueden descifrar utilizando analizadores de registro , y se pueden usar niveles de registro personalizados para eliminar la generación de archivos de registro demasiado grandes con información innecesaria. Para fines de depuración, el registro detallado es extremadamente útil. Consulte el blog de Rob Mensching para obtener una buena forma manual de leer un archivo de registro de MSI (esencialmente busca el " valor 3 " en el archivo de registro). Aquí hay una línea de comando de muestra que realiza un registro detallado:
msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"
Este artículo de Robert Macdonald del equipo de Windows Installer es muy recomendable como un vistazo práctico al registro de MSI: Cómo interpretar los registros de Windows Installer .
No todo es bueno sobre Windows Installer . Su complejidad puede ser desconcertante a veces, pero para las grandes corporaciones, los archivos MSI son muy superiores a cualquier otra forma de implementación cuando se tiene en cuenta la lista de beneficios anterior.
Para comprender el nuevo " paradigma ", es importante comprender que MSI pretende ser una descripción declarativa de lo que sucederá en el sistema de destino, en lugar de una secuencia fija de eventos. Supongo que puedes pensar en ello como una gran declaración SQL . Por ejemplo, declara elementos que desea agregar o modificar a un archivo INI. A medida que se ejecuta la instalación, los cambios se rastrean y la reversión está disponible para que los cambios se puedan revertir si la instalación falla. Esto realmente funciona como " automágico " y es confiable cuando se hace correctamente.
Es un gran dolor de cabeza para los desarrolladores experimentados de MSI ver que las personas confían en acciones personalizadas complejas y poco confiables para una funcionalidad que se implementa mejor con las funciones integradas de MSI. Una parte significativa de todos los errores de MSI y problemas de reversión son causados por acciones personalizadas erróneas, y la mayoría de los otros errores son causados por el uso erróneo del diseño de MSI (consulte la respuesta por separado para obtener una lista de errores comunes de MSI).
Además de las características integradas de MSI, cada vez hay más funcionalidades personalizadas disponibles a través de un nuevo marco como Wix , la forma XML de compilar archivos MSI, por lo que cada vez se necesita menos lógica de acción personalizada compleja para la mayoría de las operaciones.
MSI ofrece soporte completo para manejar la fusión de configuraciones de archivos ini, fuentes, variables de entorno, claves de registro, información COM, accesos directos, extensiones de archivos, condiciones de inicio, instalación de GAC, ODBC, etc.
WIX va más allá con soporte para características muy avanzadas como extensiones de servidor SQL, instalación y configuración de IIS, contadores de rendimiento, verificación de DirectX y otras tareas relacionadas con el juego, generación de imágenes nativas .NET, COM +, controladores, reglas de firewall, extensiones de PowerShell, cierre de aplicaciones, gestión de usuarios, grupos, acciones y mucho más. Algo complicado de tratar, pero mucho más confiable que sus propias acciones personalizadas.
Para tratar de ponerlo en perspectiva: estas incorporados y soluciones prefabricadas están hechas por el mejor despliegue de expertos disponibles , y son probados por miles, decenas de miles o tal vez incluso millones de usuarios (para una función de cosas en MSI sí mismo). ¿Realmente crees que puedes hacerlo mejor haciendo tus propias acciones personalizadas? El uso de una acción personalizada debería ser un evento raro, y debería ser absolutamente necesario para lograr algo único para el producto que instala . Y también debe escribir el soporte de reversión adecuado, lo cual es bastante complicado.
Escribir una acción personalizada casi siempre es un error , pero hay casos genuinos en los que realmente también necesitas la flexibilidad. Como siempre, es importante elegir bien tus batallas. Al principio puede ser una tarea divertida, pero es probable que enfrente muchos problemas inesperados y pierda mucho tiempo costoso. Me refiero a esto muy en serio. He escrito un conjunto de acciones personalizadas de C ++ para uso corporativo yo mismo (para eliminar acciones personalizadas de VBScript propensas a errores): no es nada fácil, y aunque la codificación puede no ser la más difícil del mundo, la depuración y las pruebas y La conexión a un archivo MSI real es extremadamente complicada. Un poco de tiempo investigando qué opciones listas para usar están disponibles probablemente le ahorrará semanas de trabajo de desarrollo y le brindará una confiabilidad de implementación mucho mayor.
Un punto muy importante es que se debe realizar una gran cantidad de configuraciones de aplicaciones en el inicio de la aplicación cuando tiene un contexto de tiempo de ejecución predecible y un buen manejo de errores disponible, y no en la configuración, que solo se ejecuta una vez y presenta una suplantación , secuenciación , condicionamiento y tiempo de ejecución muy complicados complejidad .
Su configuración no debe configurar la aplicación, debe preparar la aplicación para la configuración en el primer inicio . Específicamente, su configuración debe escribir todas las configuraciones que requieren derechos elevados : escribir en HKLM, registrar servicios, instalar en rutas por máquina y cualquier cosa que una aplicación no pueda escribir por sí sola con derechos de usuario normales.
Si es un desarrollador de configuración, debe ofrecer participar en la codificación de la secuencia de inicio de la aplicación en lugar de escribir acciones personalizadas de configuración . Por lo menos, para evitar parecer que está tratando de "pasar el dinero" a otra persona. En esta secuencia de lanzamiento, puede escribir un código mucho más confiable y comprobable que es más fácil de obtener ayuda del personal de control de calidad para probar (a menudo no entienden las pruebas de implementación y las pruebas de aplicaciones).
El núcleo de la complejidad de la configuración se centra en el hecho de que los errores son acumulativos (está administrando un proceso de entrega, no solo una compilación rápida), los errores son muy difíciles de depurar (no hay acceso a los sistemas donde ocurren los errores) y el sistema de destino Los estados difieren en casi todos los sentidos imaginables . Consulte esta respuesta para una discusión más exhaustiva de esta complejidad y cómo los sistemas de destino pueden desconfiar de una sorprendente cantidad de formas: Windows Installer y la creación de WiX, y La complejidad de la implementación (ver abajo).
Lea esta introducción rápida de WiX para obtener una descripción de la nueva forma basada en XML para compilar archivos MSI. Los archivos de origen basados en texto proporcionan un control de origen mucho mejor que antes. Este es un kit de herramientas gratuito y de código abierto que es muy recomendable .
NB : Vea en otra parte del hilo un resumen rápido de los problemas de diseño comunes con los archivos MSI: está muy incompleto, pero merece la pena leerlo. No quería agregar eso a esta respuesta, ya que no está 100% relacionado, pero para el uso en el mundo real es un tema crucial.
(perdón por la descarada "promoción" - es para facilitar el acceso y la recuperación)
Aquí hay algunos enlaces a temas que pueden ser útiles para los administradores de sistemas en su esfuerzo por controlar la implementación en sus redes:
Temas especiales de procedimientos:
Temas conceptuales / mejores prácticas:
Esta respuesta es en gran medida un trabajo en progreso y un bosquejo aproximado. Adiciones, preguntas y actualizaciones bienvenidas. Esta lista no es de ninguna manera exhaustiva. Agregue un comentario con información sobre paquetes problemáticos.
También debo advertir que muchos archivos MSI contienen errores, a veces graves, pero los empaquetadores de aplicaciones capacitados podrán detectar esto y, en la mayoría de los casos, eliminar el problema. Estoy agregando esto como una respuesta separada, ya que esencialmente responde una pregunta diferente, pero siento que es relevante en el mismo hilo.
Los detalles técnicos involucrados en MSI son muy complicados . En el nivel básico, se trata de descomponer sus archivos y configuraciones de registro en componentes (instalación atómica) y características (partes de aplicación seleccionables por el usuario para instalar, por ejemplo, una función de diccionario). Hay una serie de reglas de mejores prácticas para dividir los componentes, y los errores en los archivos MSI aquí son abundantes. Estos errores generalmente se manejan estandarizando el uso de "actualizaciones importantes".
La instalación real se realiza en varias secuencias de instalación, algunas con derechos elevados . Todas estas cosas se definen en las tablas de la base de datos, y aquí es donde MSI es terriblemente complicado de entender y tratar. La distribución a lo largo de las secuencias de instalación son acciones estándar y personalizadas. Las acciones estándar están diseñadas por Microsoft y deben llevarse a cabo (la secuencia a veces se puede modificar). Las acciones personalizadas están disponibles para que los proveedores realicen una lógica personalizada que MSI no cubre. Estos pueden estar en script o en forma compilada. Las acciones personalizadas pueden ser inmediatas (ejecutarse a la vez, no deberían cambiar el sistema pero a menudo lo hacen) o diferidas (escritas en un script de ejecución que luego se ejecuta como una transacción y, por lo tanto, admite la reversión).
Los errores típicos en un MSI son (sin ningún orden en particular, y se presentan realmente como un verdadero desastre):
Hay una serie de errores más sutiles y varios problemas más grandes y típicos que habré olvidado.
Consulte el artículo sobre las mejores prácticas de Windows Installer de MSDN .
El uso de MSI también facilita la aplicación de parches (archivos MSP) y las actualizaciones. Los MSI utilizan el concepto de códigos únicos de productos y actualizaciones que facilitan todo el proceso.
Algunos sistemas de implementación (CA Unicenter Software Delivery es un ejemplo) también pueden entender los MSI de una manera especial, lo que les permite integrarse mucho mejor en el sistema de implementación. Por ejemplo, puede alimentar un MSI en la biblioteca de software del sistema de implementación y detectará automáticamente las diversas características dentro del producto y permitirá automáticamente acciones personalizadas mucho más granulares (Instalación local, Verificación, Reparación, etc.) y el registro.
La autocuración / reparación también es una ventaja importante para los MSI.
Además, consulte el código abierto de Windows Installer XML , "un conjunto de herramientas que crea paquetes de instalación de Windows a partir del código fuente XML. El conjunto de herramientas admite un entorno de línea de comandos que los desarrolladores pueden integrar en sus procesos de compilación para crear paquetes de configuración MSI y MSM". MS lo utiliza para preparar varios de sus principales paquetes de software.
puede hacer transformaciones; en teoría, puede personalizar mucho, si el proveedor empaquetó el programa correctamente, puede realizar una implementación totalmente automatizada sin ninguna interacción con el usuario final, lo cual es muy útil cuando desea estandarizar su entorno de Windows y tener más de un puñado de computadoras.
para ver qué hacen las personas con msis [o implementación desatendida] visite, por ejemplo, este sitio y sus foros.