Clientes de Windows que utilizan una copia en caché de .Net 4.0 exe ​​ubicada en una unidad compartida de red

Question

Tenemos un ejecutable .Net 4.0 (MiProg.exe) y archivos DLL asociados que se implementan en un recurso compartido de red mediante XCopy. MyProg.exe y sus archivos DLL no están firmados.

Los tenemos instalados en la red compartida para que varios usuarios puedan usar la misma versión del programa y facilitar la actualización del programa. Esto funcionó bien para muchos de nuestros clientes durante muchos años.

Para un cliente reciente, una carpeta en la máquina virtual de Windows Server 2012 se comparte como una carpeta de red. Los usuarios ejecutan el programa desde otro servidor de terminal (Windows Server 2012).

Cuando actualizamos elMiProg.exe(a la versión 2.0 desde 1.0), el servidor terminal no ejecuta el nuevo ejecutable hasta que se reinicia. Continúa cargando la versión 1.0 aunque ese exe ya no esté disponible. Parece estar ejecutando una versión en caché deMyProg.exe V1.0.

1. Los pasos que probé:
   1. Cerrar todas las instancias del programa.
   2. copia lo nuevoMiProg.exea la carpeta y sobrescriba los archivos (versión exe actualizada de 1.0 a 2.0)
   3. Verifique la versión 2.0 delMiProg.exedesde su página Propiedades >> Detalles tanto desde el servidor de archivos como desde el servidor de terminal
   4. Verifique que elMyProg.exe V2.0se ejecuta cuando se ejecuta desde el servidor de archivos usando un archivo de acceso directo (destino:\\Servidor\MiProg\MiProg.exe)
   5. Ejecute el mismo archivo de acceso directo (destino:\\Servidor\MiProg\MiProg.exe) desde el servidor de terminal yMyProg.exe V1.0empieza
   6. Rebautizar\\Servidor\MiProga\\Servidor\MiProg1y confirme que el servidor de terminal no puede ejecutar el acceso directo porque esa carpeta ya no existe.
   7. Cree un nuevo archivo de acceso directo (Traget:\\Servidor\MiProg1\MiProg.exe) y confirme queMyProg.exe V2.0se ejecuta en el cliente
   8. Cambiar el nombre de la carpeta\\Servidor\MiProg1de regreso\\Servidor\MiProgy la ejecución del archivo de acceso directo original continúa cargándoseMyProg.exe V1.0hasta que se reinicie el servidor de terminal.
   9. Verifiqué que los archivos sin conexión están deshabilitados en el servidor terminal
   10. Verifiqué que no puedo sobrescribir el ejecutable MyProg.exe cuando el programa se ejecuta en el servidor Terminal.

¿Qué más puedo comprobar para solucionar el problema de por qué se ejecuta una versión anterior del ejecutable incluso cuando ese archivo ya no existe?

Answer 1

Se contactó con el equipo de soporte técnico de Microsoft. Mencionaron que podría deberse a esta configuración para SMB. Modificamos esta configuración y la mantendremos disponible durante la próxima actualización.

http://technet.microsoft.com/en-us/library/ff686200(v=WS.10).aspx

La configuración del enlace anterior no funcionó.
Más detalles que nos ayudaron a resolver el problema:La computadora cliente es un servidor de terminal de Windows

Este artículo de la base de conocimientos brinda más información al respecto:
https://support.microsoft.com/kb/2536487

Las aplicaciones pueden fallar o dejar de responder si otro usuario cierra la sesión de Escritorio remoto en Windows Server 2008 o Windows Server 2008 R2.

Síntomas:

Cuando se ejecuta una aplicación desde una unidad asignada, la aplicación puede dejar de responder o fallar para un usuario (o varios usuarios) cuando otro usuario cierra la sesión. Por ejemplo:

1. Un servidor es un servidor de archivos y otro es un servidor host de sesión remota (servidor de terminal).
2. Se asigna una carpeta en el servidor de archivos para que la utilicen usuarios remotos que se conectan al servidor RDS.
3. Varios usuarios inician una aplicación en el recurso compartido asignado.
4. Un usuario cierra la sesión y esto hace que los demás usuarios de la aplicación experimenten un bloqueo de la aplicación o no respondan.

Específicamente, el comportamiento se produce cuando el primer usuario o el último usuario de la aplicación cierran sesión, según la versión. Windows Server 2008 experimentará este problema cuando el primer usuario cierre sesión; Windows Server 2008 R2 experimentará este problema cuando el último usuario cierre sesión.

Causa:

Esto ocurre debido a la forma en que el redirector maneja el FCB (File Control Block) del binario en cuestión. En Windows Server 2008, el FCB es propiedad del usuario que abrió el archivo por primera vez y los usuarios posteriores utilizan este FCB. Cuando el primer usuario cierra sesión, el FCB queda huérfano, lo que provocó que los usuarios posteriores de la aplicación fallaran o dejaran de responder. En Windows Server 2008 R2, el FCB es propiedad del último usuario que abrió el archivo y los usuarios anteriores experimentan el problema si el último usuario cierra la sesión.

Solución alterna :

Instale la aplicación localmente en el servidor terminal en lugar de en un recurso compartido de red