El objetivo aquí es iniciar una aplicación .NET simple que escribí y que captura algunas variables de entorno (hora, nombre de usuario, nombre de computadora, etc.) al iniciar sesión. Esta aplicación .NET se suscribe al evento "Cierre de sesión de usuario" de Windows.
Al iniciarse, la aplicación captura las variables anteriores y crea un registro en mi base de datos; al cerrar sesión (que estoy capturando), actualizo otro campo en el mismo registro, con la hora de cierre de sesión.
Lo anterior funciona exactamente como me gustaría, cuando inicio el binario, realiza su entrada de registro inicial, luego espera el evento de cierre de sesión y actualiza el mismo registro.
Restricciones, el binario .NET debería poder vivir en un punto compartido (\server\share\myapp\v1) para poder actualizar la aplicación a (\server\share\myapp\v2) y simplemente actualizar el script GPO/Logon .
Mi idea inicial fue utilizar el directorio \domaincontroller\sysvol\ para almacenar el binario y luego actualizar todas las cuentas de usuario para incluir una llamada a mi aplicación. ¿Puedes ver algún defecto en este enfoque?
Mi pregunta es la siguiente: Primero, ¿hay algún problema con mi idea anterior? En segundo lugar, si es así, ¿cuál es la mejor manera (a través de una política de grupo o de otro modo) de garantizar que esta aplicación se inicie cada vez que se inicia una sesión en un servidor?
Respuesta1
Para iniciar cada vez que se inicia una sesión, será suficiente utilizar un script de inicio de sesión basado en una política de grupo. La única advertencia que hemos encontrado es que dichos scripts especificados en un GPO de usuario parecen ejecutarse DOS VECES si el "procesamiento de bucle invertido" está activado para cualquier GPO de objeto de computadora que corresponda. Como resultado, hemos tenido que modificar nuestros scripts de inicio de sesión para manejar este caso.
No estoy familiarizado con las suscripciones a eventos .NET, por lo que no sé si eso significa que el archivo de la aplicación se mantiene abierto durante toda la sesión. Si ese es el caso, actualizar la aplicación será muy difícil debido al problema del bloqueo abierto. Si 50 estaciones están conectadas, entonces la aplicación tendrá 50 bloqueos de denegación de escritura, y eso dificulta la actualización de la aplicación. Este es un caso en el que mantener la aplicación en sysvol (en realidad, en el propio GPO) puede ayudar, ya que maneja mejor ese caso.
Sin embargo, eso solo significa que se vuelve a activar al cerrar sesión y mantenerlo compartido debería estar bien.
Respuesta2
No hay nada terriblemente malo en ejecutarlo desde sysvol.
Y la creación de un script de inicio de sesión gpo haría exactamente eso de forma predeterminada y también garantizaría su ejecución. Normalmente, los servidores de terminal tienen varios gpo y uno de ellos ejecutará su script de inicio de sesión y especificará el modo de procesamiento de bucle invertido de la política de grupo.