Crear carpeta y archivo en Perfil de usuario actual, desde Perfil de administrador

Nuestro cliente solo permite la instalación de aplicaciones cuando inicia sesión como administrador. La aplicación que debe instalarse debe instalarse para el usuario actual de la máquina. La aplicación se instala bien, mi problema aparece cuando necesito soltar un archivo de configuración en la carpeta del perfil de usuario / appdata del usuario. Como es donde lo quieren, actualmente la configuración se descarta en el perfil de administrador durante la instalación. ¿Cómo puedo superar esto? ¿Hay alguna forma de verificar la instalación si hay otros perfiles y tal vez escribirles, pero esto se siente sucio?

No cree el archivo de configuración en la instalación, compruebe y vea si existe en la ejecución del progtwig; si no, créelo en la carpeta de perfil de usuario en ejecución. Si existe, entonces use los datos en él y continúe.

Voy a resumir lo que otros han mencionado básicamente, pulir las cosas un poco tratando de hacer una “pequeña referencia”.

Tal vez eche un vistazo a la mención de la función de protección de Win10 ransomware a continuación para un dato importante sobre cómo este cambio de Windows puede afectar la implementación de los archivos de perfil de usuario .

ENFOQUES COMUNES

  • Hay muchas maneras de obtener archivos implementados para cada usuario en una computadora, pero hay muchos inconvenientes y problemas con la mayoría de los enfoques. Honestamente, hay problemas con todos los enfoques, de una forma u otra.

  • A continuación se muestra una lista de algunos enfoques de implementación comunes primero, y luego una mención de algunos “enfoques basados ​​en la nube”. En el futuro, esta discusión puede volverse irrelevante ya que las configuraciones están completamente basadas en la nube y se sincronizan sobre la marcha y la implementación puede cambiar completamente de una implementación por máquina a una basada en el usuario. Tendremos que esperar y ver cómo resulta.

    • 1: Plantilla por máquina

      • Instale el archivo de configuración en una ubicación por máquina que sea legible para todos los usuarios, luego copie el archivo desde allí y colóquelo en el perfil de usuario al iniciar la aplicación utilizando la aplicación para hacer el trabajo de copia una vez por usuario.
      • Este es el enfoque recomendado. Incluso puede actualizar su aplicación con lógica para imponer actualizaciones por usuario si necesita usar un enfoque como este: http://forum.installsite.net/index.php?showtopic=21552 .
      • Siempre se ejecutará en el contexto de usuario correcto cuando se realice la copia, y no tendrá que preocuparse por la compleja suplantación de MSI, el acondicionamiento y la secuencia de complejidades.
      • Una buena ventaja de este enfoque es que funcionará incluso si falta la fuente de instalación (MSI) en el momento del lanzamiento de la aplicación.
    • 2: Crear archivo al iniciar – “Valores predeterminados internos”

      • Como sugiere gilliduck, simplemente cree el archivo de configuración en el inicio utilizando los valores predeterminados internos de la aplicación y no instale el archivo en absoluto . Ocurre una vez por usuario, a partir de ese momento utiliza el archivo que está allí. Mantener dicho archivo fuera de su instalador significa que elimina el riesgo de que el instalador lo sobrescriba accidentalmente o lo desinstale.
      • La pregunta obvia es por qué necesitarías ese tipo de archivo, si puedes crearlo a partir de los valores predeterminados internos. La respuesta es, obviamente, que es posible que desee aplicar algunos valores específicos que son únicos para el entorno del usuario una vez que se crea el archivo. Sin embargo, configuraciones como estas podrían guardarse en el registro.
      • Puede establecer las configuraciones personalizadas en cuestión en la sección HKLM del registro a través de PROPIEDADES PÚBLICAS durante la instalación (configurables por el usuario en la línea de comando o mediante una transformación; consulte: Cómo hacer un mejor uso de los archivos MSI para obtener información sobre esto), y hacerlos cumplir para todos los usuarios en el lanzamiento de la aplicación; en otras palabras, escríbalos en HKCU. ¿O podría simplemente mantener la configuración “solo lectura” en HKLM y hacerla cumplir para todos los usuarios de esa manera en su aplicación? (Configuraciones no configurables por el usuario, como un nombre de servidor de red o similar).
      • Todavía puede utilizar el método desde el enlace de arriba para imponer actualizaciones a los archivos de configuración existentes en el inicio de la aplicación haciendo que su configuración escriba una bandera en HKLM para notificar que una implementación ha “sucedido” desde el último lanzamiento.
      • O, como se dijo, alternativamente use el registro para mantener la configuración.
    • 3: auto reparación de MSI

      • Coloque el archivo de configuración en su lugar por usuario utilizando la reparación automática de MSI . Esto ocurre al invocar un punto de entrada anunciado , como un acceso directo publicitado utilizado para iniciar la aplicación.
      • Requiere acceso a la fuente de instalación en el momento en que ocurre la reparación. Asegúrese de guardar en caché su archivo MSI en la caja.
      • La reparación automática puede no funcionar en los servidores de terminales (función desactivada). Han pasado años desde la última vez que probé esto. No estoy seguro de cómo los servidores están configurados de fábrica en estos días.
      • A menos que esté configurado para no hacerlo, la desinstalación puede desinstalar el archivo de configuración para el usuario que ejecuta la desinstalación real o, críticamente, esto puede suceder durante una actualización importante (que realmente es una desinstalación y reinstalación de su producto). En otras palabras: establezca el componente como permanente (y nunca sobrescriba), o su archivo puede aparecer sobreescrito durante la actualización (pero realmente se desinstala y reinstala).
      • Para la configuración de registro de HKCU, no necesariamente necesita tener la fuente de instalación disponible. Verifique la explicación de Stefan Kruger : http://www.msifaq.com/a/1011.htm . El procedimiento es el mismo para activar la instalación de archivos de perfil de usuario (pero luego se necesita la fuente de instalación). Una discusión asociada, en caso de que sea útil .
      • Aunque no lo haya probado, he considerado establecer un valor de ruta de clave de registro para: HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] para hacer que el valor de la ruta de la clave sea un “objective en movimiento” para que la auto reparación sea se activa de manera confiable cuando el usuario inicia sesión en una computadora nueva (a pesar de que los perfiles itinerantes incorporan la configuración HKCU existente).
      • Como dije, no se ha probado ya que prácticamente he abandonado este enfoque, ya que es menos confiable depender de cada nueva actualización de Windows. Algo extraño cambia cada vez, con resultados impredecibles.
      • Aunque no está 100% relacionado, puedo mencionar la nueva característica de protección de ransomware en Windows 10 como un ejemplo: parece causar errores de tiempo de ejecución intermitentes para cualquier MSI que intente escribir en carpetas de datos de usuario. Queda por ver cuántos problemas de implementación se producirán (si bien hasta ahora vemos resultados intermitentes), qué ocurrirá si activan la función de manera predeterminada y si lo hacen de manera predeterminada.
      • Y, en la misma línea anterior, el software de seguridad de terceros también presenta obstáculos para la implementación al bloquear cierta actividad del sistema de archivos y poner en cuarentena archivos que están marcados por algún motivo (incluidos los falsos positivos), lo que provoca una reparación automática que nunca se puede completar pero mantiene corriendo en vano
        • Vea el número 7 aquí sobre software de seguridad y reparación automática y malware : ¿Cómo evito activar la autorreparación de MSI con mi paquete de WiX / MSI?
        • Un resumen de la complejidad del despliegue en general: ¿Cuál es el beneficio y el verdadero propósito de la instalación del progtwig? y hacia la parte inferior aquí: Windows Installer y la creación de WiX .
      • Así que a modo de resumen , estas son algunas de las razones por las cuales se vuelve cada vez más útil evitar el despliegue de archivos de perfiles de usuario a través de la reparación automática:
        • Complicaciones de perfil móvil .
        • Interferencia de la característica de protección Ransomware .
        • Interferencia de software de seguridad (especialmente falsos positivos de malware).
        • Restricciones del servidor de la terminal en la reparación automática .
        • Restablecimiento de datos o problemas de desinstalación de configuraciones durante la actualización principal .
        • Quizás tengas la misma sensación que tengo: hay más y continuará empeorando.
        • Mis dos centavos : hable inmediatamente con su gerente acerca de una mejor gestión de archivos de datos para su aplicación y abandone todos los bashs de ser “inteligente” durante la implementación. Implemente por archivo de máquina solo con MSI, si es posible.
        • En el futuro, es probable que esta preferencia cambie a medida que la tecnología de implementación cambie y las instalaciones se realicen solo por usuario (tal vez).
        • Una descripción más larga del problema escrito anteriormente: ¿Por qué es una buena idea limitar el despliegue de archivos al perfil de usuario o HKCU cuando se usa MSI?
        • Y una charla desordenada sobre los problemas de implementación en general : ¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI?
    • 4: Configuración activa

      • Coloque el archivo de configuración en su lugar usando Active Setup . Esto ocurre al iniciar sesión en el usuario (que luego requiere que se cierre la sesión y se inicie sesión a menos que se asegure de que el archivo también se instale en el perfil de usuario actual durante la instalación).
      • En realidad, esta es una variación del enfoque 1. Debe instalar el archivo de configuración en una ubicación por máquina, que pueda leer todo el usuario.
      • Luego registra una tarea en el registro para ejecutar “algo ejecutable” una vez por usuario. Puede ejecutar cualquier cosa como un archivo de proceso por lotes, ejecutable, script o mi enfoque preferido de reparación de MSI que logrará poner en su lugar el archivo de perfil de usuario (en este caso, no necesita un archivo en una ubicación por equipo, pero acceda a la fuente de instalación cuando se ejecuta la instalación activa).
      • Tenga cuidado de no sobrescribir un archivo de configuración instalado durante la instalación para el usuario actual. O desactive la instalación activa para que se ejecute para este usuario escribiendo la clave HKCU que se escribe después de que la Configuración activa se haya ejecutado para el usuario en cuestión (consulte el enlace a continuación).
      • El procedimiento se intentó explicar en mi respuesta aquí: actualizar el registro de cada perfil en Windows Server 2003 . Todo se basa en una clave HKLM que se ejecuta una vez por usuario. Compruebe la respuesta vinculada para más detalles, y hay algunos enlaces externos que proporcionan muchos más detalles.
      • ACTUALIZACIÓN : Al instalar en Terminal Server pone el servidor en “modo de instalación” y luego las entradas de registro por usuario se escriben en HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install y luego se escriben en la sección HKCU de cada usuario cuando inician sesión. Esto puede entrar en conflicto con ActiveSetup, por lo que sé. Nunca tuve la oportunidad de probarlo. El empaquetado de Terminal Server normalmente lo realiza un equipo de servidores especializados y especializados.
    • 5: MsiProvideComponent

      • El MsiProvideComponent de Phil es interesante, nunca lo he usado. Yo debería.

ENFOQUES DE ESTILO NUBE

  • Con el almacenamiento de datos aparentemente moviéndose a la nube, los enfoques comunes para la implementación de archivos de datos pueden volverse obsoletos rápidamente.

    • 6: Descargar el archivo de configuración

      • Descargue el archivo de configuración , una vez para cada usuario en el inicio de la aplicación, desde una base de datos de red local / compartir o desde Internet en su lugar, si esta es una opción.
      • El administrador puede actualizar el archivo remoto para actualizar los valores si hay nuevos valores predeterminados o si es necesario eliminar algo.
      • Los mecanismos de configuración en el archivo de configuración que entiende su aplicación podrían imponer nuevos valores “forzados” para que se apliquen a todos los usuarios.
      • Permitir la configuración de una lista de servidores en HKLM? Configurable en el MSI a través de PROPIEDADES PÚBLICAS
      • O establezca una sola URL en su configuración durante la instalación y mantenga una lista de servidores a través de esa URL (redirecciona a qué servidor apunta a través de DNS, entonces la configuración es una tarea sysadmin sin necesidad de volver a implementarla). Presente la selección establecida en HKCU.
    • 7: Configuración de lectura / escritura de la base de datos remota

      • En su lugar, lee / escribe configuraciones directamente a / desde una base de datos AD local o Internet continuamente.
      • ¿No hay ningún archivo de configuración local, o una copia de solo lectura en caché para cuando no se puede alcanzar el servidor? ¿O simplemente ejecutar con los valores predeterminados de la aplicación interna si no se puede acceder al servidor? No hay archivo para administrar en el último enfoque.
      • Puede escribir una lista de servidores (URL) para usar en HKLM (incluso por política de grupo?), E incluso mantener el servidor seleccionado actualmente en HKCU para cada usuario. Entonces el rest sucede en línea.
      • Generalmente se usa en aplicaciones corporativas de cliente / servidor hasta el momento, pero las plataformas basadas en la nube cambiarán la implementación para siempre, especialmente para usuarios domésticos. Hemos visto que los navegadores conservan la configuración a través de Internet durante mucho tiempo (Chrome, Opera, Firefox, etc.).
      • El almacenamiento remoto de la base de datos significa que puede mantener la configuración del usuario como una tarea de administración de bases de datos e incluso puede versionar los datos del usuario en la base de datos e implementar fácilmente nuevos valores predeterminados o forzar la actualización de valores existentes para todos los usuarios como una tarea DBO centralizada .
        • No más problemas de perfil itinerante molesto.
        • No más implementación fallida de archivos de perfil de usuario.
        • En resumen: no hay configuración de usuario para implementar, y los datos nunca se ejecutarán fuera de sincronización en máquinas diferentes.
        • Cortafuegos / Proxy y problemas de conectividad de red?

Resumen

Ya no me gusta la opción 3 (Autorreparación) y la opción 4 (Configuración activa), aunque las he usado muchas veces, y funcionan cuando se hacen bien. Sin embargo, no son inmunes a los problemas de perfil itinerante (los archivos no se copian en todos los sistemas en los que el usuario inicia sesión) y carecen de acceso al origen de instalación de MSI cuando se ejecuta la reparación, lo que puede causar problemas de implementación. También hay complicaciones frecuentes durante las actualizaciones importantes con la configuración de restablecimiento, y la auto reparación falla en los servidores de la terminal. La reparación automática podría fallar para la instalación en el perfil del usuario debido a la protección del ransomware o la interferencia del software de seguridad. La línea de comando especificada en la opción 4 (Configuración activa) podría tener errores y borrar datos (por ejemplo, habilita el indicador incorrecto para la reparación de msiexec.exe y fuerza a sobreescribir el archivo de configuración por accidente; esto a menudo no se descubre hasta que sea demasiado tarde y el daño está hecho). Y hay más problemas que me escapan en este momento. Ambos enfoques tienen limitaciones similares, pero ligeramente diferentes.

Cada vez más prefiero los enfoques basados ​​en la nube para hacer que los archivos de configuración de usuario locales (y aislados) sean cosa del pasado, pero rara vez he podido implementar las cosas de esta manera. Sin embargo, estos enfoques de nube pueden enfrentar problemas con cortafuegos / proxy y problemas de conectividad de red , y probablemente varias otras cosas de las que aún no soy consciente (ahora los desarrolladores pelearán con DBO en lugar de especialistas en implementación, etc … ;-)). La informática distribuida tiene sus falacias: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing . Además: en los enfoques basados ​​en la nube, puede ser una buena idea que las aplicaciones permitan la copia de seguridad de la configuración en el disco, por lo que aún es necesaria cierta administración de archivos, ¿o solo exporta un par de tablas de la base de datos? Además: si instala una versión de prueba de su aplicación, es posible que desee que funcione sin conectividad de red, en caso de que el usuario esté detrás de un firewall muy ajustado. Es un error muy caro hacer que no se permita que el usuario pruebe las funciones de su aplicación debido a un inconveniente técnico.

El gran beneficio de las opciones 1 y 2 es que funcionarán incluso si falta el medio de instalación original cuando se activa la reparación. Esto es particularmente importante para la implementación en el hogar y la oficina pequeña, donde la implementación puede ocurrir de forma desordenada sin un paquete compartido centralizado. Puede evitar este problema (MSI fuente faltante) mediante el uso de métodos de almacenamiento en caché para almacenar en caché todo el MSI en el sistema durante la instalación (disponible en Installshield, no he comprobado WiX o Advanced Installer).

Puede hacer que esto funcione con la función de reparación. El outlook general es que el archivo se instaló para un usuario en el momento de la instalación en una ubicación de perfil de usuario, y en una instalación por sistema que significa que el archivo faltará cuando otro usuario inicie sesión para usar la aplicación. Depende de la estructura de los componentes, las funciones y los accesos directos de MSI, pero iniciar la aplicación con un acceso directo publicitado puede hacer que el archivo que falta se instale con una reparación automática. Obviamente, esto requiere que la fuente MSI permanezca disponible.

Sin embargo, la forma más segura de instalar el archivo para cualquier nuevo usuario es llamar explícitamente a MsiProvideComponent pasando el ProductCode de la MSI, el nombre de la función, el ID del componente, etc., como se describe en la documentación. Como dicen los documentos, esto instalará el componente si falta, requiriendo nuevamente que el MSI de origen esté disponible.

Esta funcionalidad se ocupa del caso en el que hay cuentas de usuario que aún no se han creado, por lo que obviamente aún no puede colocar archivos en sus carpetas de perfil.

Si es el mejor enfoque en comparación con otros dependerá de los detalles específicos de la aplicación.