Tenemos muchos clientes ligeros que ejecutan Windows Embedded Standard 7 y un servidor SCCM 2012 R2 para administrarlos. Los thin clients tienen sus filtros de escritura habilitados (FBWF) para que los cambios de la máquina no sean persistentes. En la rara ocasión en que tenemos que actualizar algo en ellos, simplemente lo implementamos a través de SCCM y automáticamente se encarga de apagar y volver a encender los filtros de escritura para confirmar los cambios.
Esto es lo que debería suceder: el
cliente SCCM avisa al usuario y realiza una cuenta regresiva de 30 minutos para guardar su trabajo y salir del sistema. Luego, el Thin Client se reinicia y deshabilita el filtro de escritura. La pantalla de inicio de sesión muestra un candado y observa que la unidad está siendo reparada, y no permitirá que los usuarios normales (que no sean administradores) inicien sesión mientras SCCM está haciendo lo suyo. Cuando finaliza SCCM, vuelve a habilitar el filtro de escritura, se reinicia y luego los usuarios pueden iniciar sesión nuevamente.
El problema que tengo es que usamos lectores de tarjetas de proximidad para iniciar sesión en el sistema. Los empleados no escriben contraseñas. Simplemente tocan su placa. Este sistema es bueno, pero el software que lo ejecuta rompe la automatización del filtro de escritura con Windows Embedded.
Esto es lo que sucede en realidad : el
cliente SCCM avisa normalmente con 15 minutos de anticipación antes de reiniciar con el filtro de escritura desactivado. Cuando se reinicia, se muestra la pantalla de inicio de sesión normal . Los usuarios pueden iniciar sesión en el sistema y usarlo mientras SCCM está instalando software. Y debido a que una sesión de usuario está activa, nuevamente da otro aviso de 30 minutos antes de reiniciar con el filtro de escritura nuevamente.
En este escenario, no solo agrega 30 minutos adicionales al tiempo de implementación, sino que también brinda a los usuarios comunes un tiempo sólido de 30-60 minutos sin protección en los clientes livianos, con los cambios que realicen que se convierten permanentemente en la imagen cuando el filtro de escritura se vuelve a encender.
El problema surge del hecho de que Windows Embedded 7 utiliza un proveedor de credenciales diferente (también conocido como GINA) que Windows 7 normal, pero el producto SSO debe reemplazar al proveedor de credenciales de Windows para funcionar. Me he puesto en contacto con el proveedor al respecto, pero solo dicen que es un problema conocido y que no hay una solución o solución para ello.
Así que aquí está mi pregunta:
¿cómo puedo simular el comportamiento deseado de otra manera? Sé que hay una configuración de directiva de grupo donde puede negar el inicio de sesión local a grupos de usuarios específicos. Estaba pensando que podría cambiar la configuración de registro correspondiente antes y después de la instalación, pero estoy abierto a otras ideas.
No estoy por encima de las instalaciones de secuencias de comandos si es necesario. Domino los scripts, PowerShell, VBScript, etc. Me pregunto si alguien tiene alguna idea brillante sobre cómo resolver esto.
Actualización:
no mencioné que estos dispositivos se están utilizando en un entorno hospitalario para que el personal pueda registrar a sus pacientes. Deben estar disponibles las 24 horas del día, por lo que no podemos restringir las horas de inicio de sesión ni configurar ventanas de mantenimiento. Gestionamos el tiempo de inactividad notificando por adelantado a los supervisores de turno, pero cualquier cosa que tarde más de una hora se convierte en un problema de cumplimiento legal y requiere que se apliquen los procedimientos oficiales de tiempo de inactividad.