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.
Update:
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.
Before we get going I want to make a pedantic point, more for the benefit of the general readership than yourself.
SCCM is a pull-based technology. I know what you meant but I find that with my tier-1 guys, every opportunity I get to emphasize that SCCM is not a push-based technology helps them understand it quicker.
That is too bad as it sounds like the cause of this issue is the embedded card authentication program. Keep on the vendor, maybe they will actually fix their software.
On to a real answer - I see a few possible solutions for you, none of them particularly good.
Set/Get-Privilegescmdlets which will let you manipulate User Rights AssignmentsIt seems no one touched on the possibility of using a task sequence to handle this, so allow me to list the benefits (assuming you're not really familiar with them in general, but please read even if you are):
If everything you install and configured is handled w/ SCCM, you should be able to use a task sequence to accomplish this. Primarily for OSD, using a TS is not only for OSD and can provide the following benefits:
A TS executes before winlogon.exe runs, so there is no possibility of a user inadvertently logging on, as there is no log on window. Which brings me to my second point:
You can provide a splash screen that says maintenance is being performed, or whatever you want it to say really.
A TS is really just a glorified script, but it has a lot of functionality and is put together in a way as to decrease development time, and I've found use cases beyond OSD.
It sounds like you already have a script to do what you need done, so you should be able to put that into a TS with minimal debugging and get going.
You haven't specified if the SSO software uses Active Directory credentials, so a solution would be to make use of Active Directory's "Logon Hours" function. It's at a per-user level, but can easily be scripted in Powershell (this being an example). Basically, set the logon hours to "deny" logon at your SCCM update window and the users will be unable to log into the clients while SCCM does its thing. You'll need to have that first forced reboot which will log them out (the logon hours function doesn't work on logged-in users), but it would otherwise be painless to implement.
May want to test this and see if it works:
A script at the beginning of the SCCM activity to do the following:
At the end:
Add the security principals that you removed back into the local Users group
The actual groups you add/remove may depend on how your computers are currently configured.
Something a bit more trailer-parky, the beginning of the SCCM activity could copy a shortcut to logoff.exe to the All Users Start Menu\Startup folder (typically C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp). This would have the effect of logging off a session as soon as they logon. To be safe, you may want to have a startup/shutdown script to delete that shortcut. (I believe that Startup shortcuts may be bypassed by holding the shift key during logon).