We have a lot of thin clients running Windows Embedded Standard 7 and an SCCM 2012 R2 server to manage them. The thin clients have their write filters enabled (FBWF) so machine changes are not persistent. On the rare occasion we have to update something on them, we just deploy it via SCCM and it automatically takes care of turning the write filters off and back on to commit changes.
Here's what should happen:
SCCM client gives notice to the user and a 30-minute countdown to save their work and get off the system. The thin client then reboots and disables the write filter. The log-on screen displays a padlock and notice that the unit is being serviced, and will not allow normal (non-admin) users to log on while SCCM is doing it's thing. When SCCM is done, it re-enables the write filter, reboots, and then users can log in again.
The problem I'm having is that we use proximity card readers to log into the system. Employees do not type passwords. They just tap their badge. This system is nice, but the software that runs it breaks the write filter automation with Windows Embedded.
Here's what actually happens:
SCCM client gives the usual 15-minute notice before rebooting with the write filter off. When it reboots, the normal login screen is displayed. Users can log into the system and use it while SCCM is installing software. And because a user session is active, it again gives another 30-minute notice before rebooting with the write filter back on.
In this scenario, not only does it add an extra 30 minutes to the deployment time, but it also gives ordinary users a solid 30-60 minutes of unprotected time on the thin clients with whatever changes they make becoming permanently baked into the image when the write filter gets turned back on.
The issue stems from the fact that Windows Embedded 7 uses a different credential provider (a.k.a GINA) than regular Windows 7 does, but the SSO product must replace the Windows credential provider in order to function. I've contacted the vendor about it, but they just say it's a known issue and there is no fix or workaround for it.
So here's my question:
How can I simulate the desired behavior another way? I know that there is a group policy setting where you can deny local logon to specific user groups. I was thinking I could flip the corresponding registry setting before and after the install, but I am open to other ideas.
I'm not above scripting installs if I have to. I am fluent with scripting, PowerShell, VBScript, etc. I just wonder if anyone has any bright ideas on how to solve this.
I neglected to mention that these devices are being used in a hospital environment for staff to chart on their patients. They must be available 24 hours a day, so we can't restrict logon hours or configure maintenance windows. We manage downtime by giving advance notice to shift supervisors, but anything that takes more than an hour becomes a legal compliance issue and requires official downtime procedures to be put into effect.