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.
Respuestas:
Antes de comenzar, quiero hacer un comentario pedante, más para beneficio de los lectores en general que para ti.
SCCM es una tecnología basada en extracción. Sé lo que querías decir, pero creo que con mis muchachos de nivel 1, cada oportunidad que tengo para enfatizar que SCCM no es una tecnología basada en el empuje les ayuda a entenderlo más rápido.
Eso es una lástima, ya que parece que la causa de este problema es el programa de autenticación de tarjeta integrada. Siga con el vendedor, tal vez realmente arreglarán su software.
A una respuesta real: veo algunas soluciones posibles para usted, ninguna de ellas particularmente buena.
Set/Get-Privilegescmdlets que le permitirán manipular las Asignaciones de derechos de usuariofuente
secedit.exemediante un script. No estoy hablando de usar la directiva de grupo de Active Directory, ya que el tiempo de sondeo aleatorio no funcionará para su ventana de mantenimiento apretada.Parece que nadie tocó la posibilidad de usar una secuencia de tareas para manejar esto, así que permítame enumerar los beneficios (suponiendo que no esté realmente familiarizado con ellos en general, pero lea incluso si lo está):
Si todo lo que instala y configura se maneja con SCCM, debería poder usar una secuencia de tareas para lograr esto. Principalmente para OSD, el uso de un TS no es solo para OSD y puede proporcionar los siguientes beneficios:
Un TS se ejecuta antes de que se ejecute winlogon.exe, por lo que no hay posibilidad de que un usuario inicie sesión inadvertidamente, ya que no hay una ventana de inicio de sesión. Lo que me lleva a mi segundo punto:
Puede proporcionar una pantalla de inicio que indique que se está realizando el mantenimiento, o lo que sea que quiera que realmente diga.
Un TS es realmente solo un script glorificado, pero tiene mucha funcionalidad y se combina de una manera que disminuye el tiempo de desarrollo, y he encontrado casos de uso más allá de OSD.
Parece que ya tiene un script para hacer lo que necesita hacer, por lo que debería poder ponerlo en un TS con una depuración mínima y comenzar.
fuente
No ha especificado si el software SSO utiliza credenciales de Active Directory, por lo que una solución sería utilizar la función "Horas de inicio de sesión" de Active Directory. Está en un nivel por usuario, pero se puede programar fácilmente en Powershell ( esto es un ejemplo). Básicamente, configure las horas de inicio de sesión para "denegar" el inicio de sesión en la ventana de actualización de SCCM y los usuarios no podrán iniciar sesión en los clientes mientras SCCM hace lo suyo. Deberá tener ese primer reinicio forzado que los cerrará sesión (la función de horas de inicio de sesión no funciona en los usuarios conectados), pero de lo contrario sería sencillo implementarla.
fuente
Es posible que desee probar esto y ver si funciona:
Un script al comienzo de la actividad SCCM para hacer lo siguiente:
Al final:
Agregue los principios de seguridad que eliminó nuevamente al grupo de usuarios local
Los grupos reales que agregue / elimine pueden depender de la configuración actual de sus computadoras.
Algo un poco más trailer-parky, el comienzo de la actividad de SCCM podría copiar un acceso directo a logoff.exe a la carpeta Menú de inicio \ Inicio de todos los usuarios (generalmente C: \ ProgramData \ Microsoft \ Windows \ Menú de inicio \ Programas \ StartUp). Esto tendría el efecto de cerrar una sesión tan pronto como inicien sesión. Para estar seguro, es posible que desee tener un script de inicio / apagado para eliminar ese acceso directo. (Creo que los accesos directos de inicio pueden pasarse por alto manteniendo presionada la tecla Mayús durante el inicio de sesión).
fuente