Jak zablokować zwykłych użytkowników (niebędących administratorami) podczas instalacji oprogramowania?

Mamy wielu cienkich klientów z systemem Windows Embedded Standard 7 i serwerem SCCM 2012 R2 do zarządzania nimi. Ciency klienci mają włączone filtry zapisu (FBWF), więc zmiany maszynowe nie są trwałe. W rzadkich przypadkach musimy coś na nich zaktualizować, po prostu wdrażamy to za pomocą SCCM i automatycznie dba o wyłączenie i ponowne włączenie filtrów zapisu w celu zatwierdzenia zmian.

Oto, co powinno się stać:
klient SCCM powiadamia użytkownika i 30-minutowe odliczanie, aby zapisać swoją pracę i wyjść z systemu. Cienki klient następnie uruchamia się ponownie i wyłącza filtr zapisu. Ekran logowania wyświetla kłódkę i zauważa, że ​​urządzenie jest serwisowane i nie pozwoli normalnym użytkownikom (innym niż administrator) zalogować się, gdy SCCM to robi. Po zakończeniu SCCM ponownie włącza filtr zapisu, uruchamia się ponownie, a następnie użytkownicy mogą się ponownie zalogować.

Problemem jest to, że używamy czytników kart zbliżeniowych do logowania się do systemu. Pracownicy nie wpisują haseł. Po prostu stukają w odznakę. Ten system jest fajny, ale oprogramowanie, które go uruchamia, przerywa automatyzację filtra zapisu w systemie Windows Embedded.

Oto, co się właściwie dzieje:
klient SCCM powiadamia zwykle 15 minut przed ponownym uruchomieniem przy wyłączonym filtrze zapisu. Po ponownym uruchomieniu wyświetla się normalny ekran logowania. Użytkownicy mogą zalogować się do systemu i używać go podczas instalowania oprogramowania przez SCCM. Ponieważ sesja użytkownika jest aktywna, ponownie powiadamia o tym 30-minutowe powiadomienie przed ponownym uruchomieniem z ponownie włączonym filtrem zapisu.

W tym scenariuszu nie tylko wydłuża czas wdrażania o dodatkowe 30 minut, ale także zapewnia zwykłym użytkownikom 30-60 minut niezabezpieczonego czasu na cienkich klientach, bez względu na to, jakie zmiany wprowadzą na stałe do obrazu, gdy filtr zapisu zostaje ponownie włączony.

Problem wynika z faktu, że system Windows Embedded 7 używa innego dostawcy poświadczeń (znanego również jako GINA) niż zwykły system Windows 7, ale produkt SSO musi zastąpić dostawcę poświadczeń Windows, aby działał. Skontaktowałem się z dostawcą w tej sprawie, ale mówią, że jest to znany problem i nie można go naprawić ani obejść.

Oto moje pytanie:
jak mogę symulować pożądane zachowanie w inny sposób? Wiem, że istnieje ustawienie zasad grupy, w którym można odmówić lokalnego logowania określonym grupom użytkowników. Myślałem, że mogę przerzucić odpowiednie ustawienia rejestru przed instalacją i po niej, ale jestem otwarty na inne pomysły.

Nie muszę instalować skryptów, jeśli muszę. Biegle posługuję się skryptami, PowerShell, VBScript itp. Zastanawiam się tylko, czy ktoś ma jakieś jasne pomysły na rozwiązanie tego problemu.

Aktualizacja:
Zlekceważyłem wspomnienie, że urządzenia te są używane w środowisku szpitalnym, aby personel mógł sporządzać wykresy dotyczące swoich pacjentów. Muszą być dostępne 24 godziny na dobę, więc nie możemy ograniczać godzin logowania ani konfigurować okien obsługi. Zarządzamy przestojami, powiadamiając osoby nadzorujące zmiany z wyprzedzeniem, ale wszystko, co zajmuje więcej niż godzinę, staje się kwestią zgodności z prawem i wymaga wprowadzenia oficjalnych procedur dotyczących przestojów.

Zanim zaczniemy, chcę zrobić pedantyczny punkt, bardziej na rzecz ogólnego czytelnictwa niż ciebie.

po prostu popychamy go za pomocą SCCM

SCCM to technologia oparta na ciągnięciu. Wiem, co miałeś na myśli, ale stwierdzam, że z moimi chłopakami z poziomu 1 każda okazja, aby podkreślić, że SCCM nie jest technologią opartą na wypychaniu, pomaga im szybciej to zrozumieć.

Skontaktowałem się z dostawcą w tej sprawie, ale mówią, że jest to znany problem i nie można go naprawić ani obejść

To szkoda, ponieważ wydaje się, że przyczyną tego problemu jest program do uwierzytelniania kart osadzonych. Trzymaj się dostawcy, może rzeczywiście naprawią swoje oprogramowanie.

Na prawdziwą odpowiedź - widzę dla ciebie kilka możliwych rozwiązań, żadne z nich nie jest szczególnie dobre.

• Skonfiguruj okno konserwacji dla tych klientów, aby początkowe ponowne uruchomienie w celu usunięcia klientów z ich filtra zapisu, rzeczywista ładowność i wynikowy restart miały miejsce poza godzinami pracy, gdy pracownicy nie są obecni na terminalach. To wydaje się być najmniej bolesną opcją. Nie ma potrzeby, aby SCCM był bardziej skomplikowany niż jest już.
• Utwórz szablon lokalnych zasad grupy, który doda grupę zabezpieczeń do Prawa użytkownika do odmowy logowania, a następnie przypisz / cofnij przypisanie w ramach wdrażania aplikacji.
• Użyj programu PowerShell, aby ustawić Odmowę logowania użytkownika. Wierzę, że rozszerzenia społeczności PowerShell (PSCX) mają polecenia Set/Get-Privilegescmdlet, które pozwalają manipulować przypisaniami praw użytkownika
• Możesz użyć interfejsu API, jeśli chcesz. Oto przykład .

Wydaje się, że nikt nie poruszył możliwości użycia sekwencji zadań do obsługi tego, więc pozwól mi wymienić listę korzyści (zakładając, że tak naprawdę nie znasz ich ogólnie, ale proszę przeczytaj, nawet jeśli tak):

Jeśli wszystko, co instalujesz i konfigurujesz, jest obsługiwane w / SCCM, powinieneś być w stanie użyć sekwencji zadań, aby to osiągnąć. Przede wszystkim w przypadku OSD korzystanie z TS jest nie tylko OSD i może zapewnić następujące korzyści:

Brak logowania do stacji roboczej

TS uruchamia się przed uruchomieniem programu winlogon.exe, więc nie ma możliwości nieumyślnego zalogowania się użytkownika, ponieważ nie ma okna logowania. Co prowadzi mnie do drugiego punktu:

Niestandardowy ekran tła

Możesz wyświetlić ekran powitalny z informacją, że konserwacja jest wykonywana lub cokolwiek chcesz, aby naprawdę powiedzieć.

TS to tak naprawdę chwalebny skrypt, ale ma wiele funkcji i jest tak skonstruowany, aby skrócić czas programowania, i znalazłem przypadki użycia poza OSD.

Wygląda na to, że masz już skrypt do robienia tego, co musisz zrobić, więc powinieneś być w stanie umieścić go w TS przy minimalnym debugowaniu i zacząć.

Nie określono, czy oprogramowanie SSO używa poświadczeń usługi Active Directory, więc rozwiązaniem byłoby skorzystanie z funkcji „Godziny logowania” w usłudze Active Directory. To na poziomie poszczególnych użytkowników, ale można łatwo skryptów w PowerShell ( to jest przykład). Zasadniczo ustaw godziny logowania tak, aby „odmawiały” logowania w oknie aktualizacji SCCM, a użytkownicy nie będą mogli zalogować się do klientów, podczas gdy SCCM to zrobi. Musisz mieć to pierwsze wymuszone ponowne uruchomienie, które wyloguje ich (funkcja godzin logowania nie działa na zalogowanych użytkownikach), ale w przeciwnym razie wdrożenie byłoby bezbolesne.

Może chcesz to przetestować i sprawdzić, czy to działa:

Skrypt na początku działania SCCM, który wykonuje następujące czynności:

• Usuń tożsamość NT AUTHORITY \ Authentified Users z lokalnej grupy użytkowników
• Usuń NT AUTHORITY \ Interactive tożsamość z lokalnej grupy użytkowników
• Usuń grupę użytkowników domeny z lokalnej grupy użytkowników

Na końcu:

Dodaj usunięte zasady zabezpieczeń do lokalnej grupy Użytkownicy

Rzeczywiste grupy, które dodajesz / usuwasz, mogą zależeć od tego, w jaki sposób komputery są obecnie skonfigurowane.

Coś nieco bardziej zaparkowanego na przyczepie, początek aktywności SCCM może skopiować skrót do logoff.exe do menu Start wszystkich użytkowników \ ​​Folder startowy (zazwyczaj C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp). Spowoduje to wylogowanie sesji, gdy tylko się zalogują. Ze względów bezpieczeństwa możesz chcieć mieć skrypt uruchamiania / zamykania, aby usunąć ten skrót. (Uważam, że skróty startowe można ominąć przytrzymując klawisz Shift podczas logowania).