Wylogowanie użytkowników RDP to zadanie cykliczne usługi SSJob, kończące sesje wyłącznie tych użytkowników, którzy pozostają bezczynni dłużej niż ustalony próg czasowy. Obsługuje wiele serwerów jednocześnie i pozwala na bieżąco wykluczyć wybrane konta z automatycznego wylogowania.
Czym jest wylogowanie użytkowników RDP
Wylogowanie użytkowników RDP to zadanie SSJob poprzedzające w sekwencji zadań utrzymaniowych restart serwera terminali. Jego głównym celem jest łagodne, kontrolowane zamknięcie sesji użytkowników, którzy faktycznie zakończyli pracę, ale z różnych powodów - zapomnienia, zerwanego połączenia, zamkniętego bez wylogowania laptopa - pozostawili swoją sesję formalnie otwartą na serwerze.
Mechanizm konfiguracyjny opiera się na znanym z pozostałych zadań SSJob wierszu w tabeli _jobs, uzupełnionym o zestaw parametrów właściwych wyłącznie temu zadaniu, pozwalających precyzyjnie określić, kogo, kiedy i na jakich serwerach dotyczy automatyczne wylogowanie. Podobnie jak przy eksporcie XLSX czy synchronizacji HelpDesk, zadanie to pokazuje, jak elastyczny w praktyce jest jeden, wspólny mechanizm tabeli _jobs - ta sama struktura obsługuje zarówno operacje na danych, jak i akcje wykonywane bezpośrednio na systemie operacyjnym serwera.
Mechanizm oparty na bezczynności
Kluczową cechą tego zadania jest to, że nie wylogowuje ono wszystkich użytkowników bez wyjątku, tylko selektywnie te sesje, które pozostają bezczynne dłużej niż wartość wskazana parametrem UserLogOffIDLETIMEminutes. Sesja użytkownika aktywnie pracującego w danym momencie - niezależnie od pory doby - pozostaje nietknięta, podczas gdy sesja pozostawiona bez żadnej interakcji dłużej niż ustalony próg zostaje zakończona.
Uzupełnieniem progu bezczynności jest parametr UserLogOffHour, określający godzinę, od której zadanie w ogóle zaczyna sprawdzać i egzekwować ten warunek. Dzięki temu administrator może na przykład ustawić sprawdzanie bezczynności dopiero od późnych godzin wieczornych, unikając sytuacji, w której krótka przerwa użytkownika w ciągu dnia roboczego zostałaby błędnie potraktowana jako zakończenie pracy.
Oba te parametry działają razem, a nie osobno - dopiero ich połączenie daje pełny obraz warunku wyzwalającego wylogowanie. Sama godzina bez progu bezczynności wylogowałaby wszystkich bez wyjątku, a sam próg bezczynności bez ograniczenia godzinowego mógłby niepotrzebnie kończyć krótkie przerwy w pracy w ciągu dnia. Dopiero razem, jako iloczyn dwóch niezależnych warunków, dają zachowanie zgodne z rzeczywistą intencją tego zadania.
Konfiguracja w tabeli _jobs
Sam wiersz zadania w tabeli _jobs korzysta ze znanego zestawu pól, uzupełnionego o cztery parametry właściwe wyłącznie temu typowi zadania:
| Pole | Znaczenie |
|---|---|
| OSTATNIOWYKONANO | Data ostatniego poprawnego wykonania zadania |
| CYKLICZNOSC | Liczbowy interwał, co jaki zadanie jest uruchamiane |
| CYKLICZNOSCTYPE | Jednostka interwału - np. minuty, godziny |
| MAILPOWIADOMIENIE | Adresy e-mail, na które trafią powiadomienia o wykonaniu zadania |
| CONECTIONSTRINGNAME | Łańcuch połączeniowy wskazujący bazę danych StudioSystem |
| PARAMETRY: UserLogOffHour | Godzina, od której zadanie zaczyna sprawdzać bezczynność sesji |
| PARAMETRY: UserLogOffIDLETIMEminutes | Liczba minut bezczynności uznawana za zakończenie pracy |
| PARAMETRY: ActiveServers | Lista serwerów objętych zadaniem, rozdzielona znakiem @ |
| PARAMETRY: SuperAdminUsers | Lista użytkowników wykluczonych z wylogowania, rozdzielona znakiem @ |
Porządek bez przeszkadzania pracującym
Selektywne wylogowanie sprząta zapomniane sesje, nie ingerując w pracę osób faktycznie aktywnych w systemie.
Wiele serwerów i wykluczenia
Parametr ActiveServers pozwala jednym zadaniem objąć nie jeden, a wiele serwerów terminali jednocześnie - ich nazwy wpisuje się rozdzielone znakiem @. Rozwiązanie to ma praktyczne znaczenie we wdrożeniach obejmujących kilka niezależnych serwerów RDP obsługujących różne grupy użytkowników czy oddziały firmy, gdzie zamiast konfigurować osobne zadanie dla każdego serwera z osobna, wystarczy jeden wiersz w tabeli _jobs z rozszerzoną listą docelowych maszyn.
Drugi parametr specyficzny dla tego zadania, SuperAdminUsers, działa w odwrotnym kierunku - definiuje listę kont, również rozdzielonych znakiem @, które nigdy nie zostaną wylogowane automatycznie, niezależnie od czasu ich bezczynności. Mechanizm ten chroni konta administracyjne wykorzystywane na przykład do stałego monitoringu systemu albo do sesji serwisowych, które z założenia mogą pozostawać otwarte znacznie dłużej niż typowa sesja zwykłego użytkownika.
Warto zauważyć, że oba te parametry - lista serwerów i lista wykluczonych kont - są od siebie niezależne. Wykluczenie danego użytkownika z listy SuperAdminUsers obowiązuje na wszystkich serwerach wskazanych w ActiveServers jednocześnie, bez możliwości różnicowania wykluczeń w zależności od konkretnej maszyny. W większości praktycznych wdrożeń nie stanowi to ograniczenia, ponieważ konta wymagające takiej ochrony zwykle mają dostęp do wielu serwerów naraz.
Miejsce w sekwencji zadań RDP
Wylogowanie użytkowników pełni rolę pierwszego, najłagodniejszego etapu trójetapowej sekwencji konserwacji serwera terminali, opisanej szerzej przy okazji restartu serwera RDP. Po nim następuje sam restart systemu operacyjnego, a na końcu czyszczenie serwera porządkujące pozostałości po zakończonej sesji roboczej.
Taki podział ma sens tylko wtedy, gdy poszczególne etapy są odpowiednio od siebie odsunięte w czasie - wylogowanie musi zdążyć zakończyć sesje nieaktywnych użytkowników, zanim rozpocznie się restart, inaczej cała korzyść z łagodnego, selektywnego podejścia tego zadania zostaje zniwelowana przez bezwarunkowe działanie restartu następującego zbyt szybko po nim.
Dlaczego bezczynność, a nie wszyscy naraz
Alternatywnym, znacznie prostszym podejściem byłoby wylogowanie wszystkich użytkowników bez wyjątku o ustalonej porze, niezależnie od tego, czy w danym momencie faktycznie pracują. Takie rozwiązanie byłoby jednak dotkliwe dla osób pracujących w nietypowych godzinach, na przykład podczas zamknięcia miesiąca w księgowości czy w trakcie zmiany nocnej w magazynie - ich praca zostałaby przerwana mimo braku żadnej rzeczywistej potrzeby konserwacji w tym konkretnym momencie.
Mechanizm oparty na rzeczywistej bezczynności sesji, uzupełniony wykluczeniami z SuperAdminUsers, pozwala pogodzić dwa pozornie sprzeczne cele - regularne porządkowanie serwera terminali z jednej strony i minimalne zakłócenie pracy rzeczywiście aktywnych użytkowników z drugiej, niezależnie od tego, o jakiej porze doby ta aktywność akurat przypada.
To podejście odzwierciedla szerszą filozofię widoczną w wielu zadaniach SSJob opisanych w tej serii - tam, gdzie to możliwe, mechanizm stara się działać selektywnie i minimalnie inwazyjnie, zamiast stosować proste, ale brutalne rozwiązanie obejmujące wszystko bez wyjątku. Podobne podejście widać choćby w rozróżnieniu między pełną odbudową a lżejszą reorganizacją indeksów bazy danych - w obu przypadkach dostępna jest zarówno opcja radykalna, jak i łagodniejsza alternatywa dopasowana do rzeczywistej skali problemu.
Dobre praktyki
Kilka zasad pomaga skutecznie skonfigurować i utrzymać to zadanie:
- Rozsądny próg bezczynności - zbyt krótki czas w UserLogOffIDLETIMEminutes ryzykuje niepotrzebne wylogowanie użytkownika, który tylko na chwilę odszedł od stanowiska.
- Aktualna lista SuperAdminUsers - odejście pracownika z zespołu administracyjnego powinno zawsze wiązać się z przeglądem i aktualizacją tej listy.
- Zgodność z harmonogramem restartu - UserLogOffHour powinno pozostawiać wystarczający margines czasowy przed zaplanowanym ServerResetHour, tak by proces wylogowania zdążył się w pełni zakończyć.
- Weryfikacja listy ActiveServers - dodanie nowego serwera terminali do infrastruktury wymaga ręcznego, pamiętanego o czasie uzupełnienia tej listy, inaczej zadanie go całkowicie pominie.
Warto też pamiętać, że to zadanie samo w sobie nie zabezpiecza przed utratą niezapisanej pracy - dba wyłącznie o sesje rzeczywiście bezczynne. Za ostateczne, bezwarunkowe domknięcie wszystkich pozostałych sesji odpowiada dopiero następujący po nim restart serwera. Podobnie jak przy planowaniu odbudowy indeksów bazy danych, kluczowe znaczenie ma tu nie tyle sam mechanizm, co rozsądnie dobrane wartości parametrów - dobrze skonfigurowane zadanie działa niezauważalnie dla większości użytkowników, a źle skonfigurowane potrafi wywołać frustrację znacznie większą niż korzyść z samej automatyzacji.
Podsumowanie
Wylogowanie użytkowników RDP to selektywne, oparte na rzeczywistej bezczynności zadanie SSJob, otwierające trójetapową sekwencję konserwacji serwera terminali. Konfiguruje się je wierszem w tabeli _jobs z czterema dodatkowymi parametrami - godziną startu, progiem bezczynności, listą obsługiwanych serwerów i listą kont wykluczonych z automatycznego wylogowania.
Właściwe dobranie tych parametrów, we współpracy z następującym po nim restartem serwera RDP, pozwala utrzymać serwer terminali w dobrej kondycji bez ryzyka niepotrzebnego przerywania pracy rzeczywiście aktywnych użytkowników, niezależnie od pory dnia czy specyfiki harmonogramu danej firmy.