12

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.

Wes Sayeed
  • 1,862
  • 6
  • 27
  • 41
  • Great question. I wish I had a better answer. –  May 05 '15 at 17:47
  • good question- hopefully your tale of woe discourages others from buying thin clients- I hate all the baggage these "low maintenance" devices bring – Jim B May 06 '15 at 00:58

4 Answers4

4

Before we get going I want to make a pedantic point, more for the benefit of the general readership than yourself.

we just push it via SCCM

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.


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

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.

  • Configure a Maintenance Window for these clients so your initial reboot to remove the clients from their write filter, your actual payload and the resulting reboot all happen off-hours when employees are not present at the terminals. This seems like the least painful option. No need to make SCCM more complicated than it already is.
  • Create a Local Group Policy template that adds a security group to the Deny Logon User Right and then assign/un-assign it as part of your application deployment.
  • Use PowerShell to set the Deny Logon User Right. I believe the PowerShell Community Extensions (PSCX) has the Set/Get-Privileges cmdlets which will let you manipulate User Rights Assignments
  • You can use the API if you want. Here's an example.
  • Thanks for the response. I updated my question to reflect the environment. It's a 24x7 operation so option 1 isn't viable. Option 2 was what I was thinking, but I don't know of a way to assign/un-assign a GPO on demand. That leaves options 3 and 4 which I will look into. I figured I'd probably have to script my way out of this. Oh and I corrected the terminology :-) – Wes Sayeed May 05 '15 at 19:45
  • @WesSayeed In theory you should be able to create *Local* Group Policy Templates with SecPol.msc, save them as a templates and the apply / un-apply with `secedit.exe` via a script. I'm not talking about using Active Directory Group Policy since the randomized polling time won't work for your tight maintenance window. –  May 05 '15 at 23:01
  • +1, I like this answer and wasn't aware of PSCX. – MDMoore313 May 06 '15 at 04:25
4

It 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:

No logging onto the workstation

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:

Custom background screen

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.

MDMoore313
  • 5,531
  • 6
  • 34
  • 73
  • 1
    +1 I always wondered whether there were real-world uses for non-OSD task sequences. – alx9r Aug 26 '15 at 03:55
  • @BigHomie; I just tried doing a deployment using a Task Sequence rather than a normal application and it did not prevent user logon. The first step in the task sequence is to reboot the computer. Once the computer comes back up it presents a normal logon screen. The task sequence does not resume until about a minute later (because the service is set to delayed start). I can set the service to start immediately with Group Policy so the user would see a progress bar, but that would only discourage logons, not prevent them. Am I missing something? – Wes Sayeed Jan 14 '16 at 16:50
  • @WesSayeed !! Is that TS advertised to the user or the computer? – MDMoore313 Jan 14 '16 at 17:16
  • @BigHomie; AFAIK, Task Sequences can only be advertised to computer collections. – Wes Sayeed Jan 14 '16 at 18:02
  • That's right, I forgot about that. Unfortunately, I took a new job last year and have been out of the sccm game for quite a while. I'll continue to search for the answer though but I thought the same mechanism that allowed software to install during an OSD before the login screen appeared can be used outside of OSD as well. I suppose you're deployment cannot be done if the machine boots to WinPE, correct? – MDMoore313 Jan 14 '16 at 18:07
  • Also @WesSayeed does your TS download all required software before it starts the TS, or does it have to wait for the network connection after reboot? – MDMoore313 Jan 14 '16 at 18:19
2

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.

Nathan C
  • 14,901
  • 4
  • 42
  • 62
  • SSO software does use AD. All it does it match an RFID tag to an AD account and passes the credentials though to Windows to perform the logon. I updated my answer to explain why I can't use logon hours (I neglected to mention the environment), but I'll have a look at the script you referenced. I might be able to do something like that locally. – Wes Sayeed May 05 '15 at 19:49
-1

May want to test this and see if it works:

A script at the beginning of the SCCM activity to do the following:

  • Remove NT AUTHORITY\Authenticated Users identity from local Users group
  • Remove NT AUTHORITY\Interactive identity from local Users group
  • Remove Domain Users group from local Users group

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).

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • I have to -1 this, it would work, but if the script is killed in the middle, from some random error or Murphy's Law, then the user can't login and they are dead in the water until IT can respond. – MDMoore313 May 08 '15 at 14:55