Restart serwera RDP to zadanie cykliczne usługi SSJob, wykonujące pełny restart systemu operacyjnego serwera terminali o wcześniej ustalonej godzinie, wskazanej parametrem ServerResetHour. Ma sens wyłącznie jako element szerszej, skoordynowanej sekwencji zadań utrzymaniowych serwera RDP.
Czym jest restart serwera RDP
Restart serwera RDP to jedno z zadań SSJob dbających o infrastrukturę, na której działa StudioSystem - w tym przypadku o serwer terminali udostępniający zdalne sesje pulpitu wielu użytkownikom jednocześnie. W odróżnieniu od zadań opisanych wcześniej w tej serii, dotyczących bazy danych czy plików aplikacji, to zadanie oddziałuje bezpośrednio na cały system operacyjny serwera, na którym pracują aktywni użytkownicy.
Mechanizm konfiguracyjny pozostaje ten sam, co przy pozostałych zadaniach SSJob - wiersz w tabeli _jobs z harmonogramem i powiadomieniami - jednak sam efekt działania zadania jest znacznie bardziej odczuwalny dla użytkowników niż w przypadku zadań działających wyłącznie w tle, takich jak odbudowa indeksów czy organizacja bazy danych. O ile te dwa zadania użytkownik odczuwa co najwyżej pośrednio, poprzez szybkość działania zapytań, o tyle restart serwera terminali jest zdarzeniem widocznym wprost - kończy sesję każdego, kto akurat z niej korzysta, dlatego wymaga znacznie ostrożniejszego zaplanowania niż zadania działające całkowicie niezauważalnie w tle.
Dlaczego serwer terminali tego wymaga
Serwery terminali RDP, obsługujące jednocześnie wielu zalogowanych użytkowników przez długi czas bez przerwy, są szczególnie podatne na kilka typowych problemów systemu Windows. Procesy uruchamiane w ramach poszczególnych sesji użytkowników nie zawsze zwalniają zajętą pamięć w pełni poprawnie, co przy dziesiątkach czy setkach zalogowanych w ciągu dnia osób prowadzi do stopniowego wyczerpywania dostępnych zasobów serwera.
Dodatkowym źródłem problemów są sesje osierocone - pozostające formalnie aktywne w systemie mimo utraty rzeczywistego połączenia z komputerem klienckim, na przykład po nagłym zerwaniu sieci. Takie sesje wciąż zajmują pamięć i licencje dostępowe, mimo że nikt aktywnie z nich nie korzysta. Regularny, pełny restart systemu operacyjnego skutecznie usuwa wszystkie te narastające problemy naraz, przywracając serwer do stanu zbliżonego do świeżo uruchomionego.
Do tego dochodzą typowe dla długo działających systemów Windows zjawiska poboczne - rozrastające się pliki tymczasowe poszczególnych profili użytkowników, zawieszone procesy usług drukowania czy stopniowo zapełniający się bufor zdarzeń systemowych. Żaden z tych problemów z osobna zwykle nie jest krytyczny, ale ich suma, narastająca dzień po dniu bez żadnej interwencji, potrafi z czasem zauważalnie obniżyć responsywność całego serwera terminali, wydłużając czas logowania i ogólny czas reakcji aplikacji uruchamianych przez użytkowników.
Konfiguracja w tabeli _jobs
Zadanie restartu serwera RDP korzysta ze znanego zestawu pól tabeli _jobs, uzupełnionego o parametr właściwy 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. dni |
| MAILPOWIADOMIENIE | Adresy e-mail, na które trafią powiadomienia o wykonaniu zadania |
| CONECTIONSTRINGNAME | Łańcuch połączeniowy wskazujący bazę danych StudioSystem |
| PARAMETRY (ServerResetHour) | Godzina doby, o której ma nastąpić restart serwera |
W odróżnieniu od zadań wskazujących nazwaną konfigurację w osobnej tabeli, tak jak eksport XLSX czy synchronizacja HelpDesk, parametr ServerResetHour jest tu jedyną, prostą wartością liczbową - godziną, bez potrzeby odwoływania się do dodatkowych struktur danych.
Świeży serwer każdego dnia
Cykliczny restart serwera terminali eliminuje narastające przez dzień pracy problemy pamięci i osieroconych sesji.
Miejsce w sekwencji zadań RDP
Restart serwera RDP nie działa w oderwaniu od pozostałych zadań utrzymaniowych serwera terminali tej samej serii. Logicznie poprzedza go zadanie wylogowania użytkowników z serwera, a bezpośrednio po nim zwykle następuje zadanie czyszczenia serwera, porządkujące pozostałości po zakończonej sesji roboczej dnia.
Taka trójetapowa sekwencja - wylogowanie, restart, czyszczenie - pozwala przeprowadzić pełną, kontrolowaną konserwację serwera terminali w jednym nocnym oknie czasowym, bez ryzyka, że którykolwiek z etapów zaskoczy użytkownika wciąż aktywnie pracującego w systemie.
Rozdzielenie tej konserwacji na trzy osobne zadania SSJob, każde z własnym wierszem w tabeli _jobs i własnym, precyzyjnie ustawionym momentem uruchomienia, ma istotną zaletę względem jednego, monolitycznego skryptu wykonującego wszystko naraz - administrator może niezależnie zweryfikować powodzenie każdego etapu z osobna, a w razie potrzeby zmienić harmonogram tylko jednego z nich, bez ingerowania w pozostałe dwa.
Dobór godziny restartu
Parametr ServerResetHour powinien być dobrany tak, by przypadał wyraźnie poza godzinami pracy wszystkich użytkowników korzystających z serwera terminali, z odpowiednim zapasem czasowym na wcześniejsze wylogowanie sesji i późniejsze uruchomienie się wszystkich usług po restarcie, zanim pierwsi użytkownicy zaczną logować się rano.
W firmach działających na wiele zmian albo obsługujących użytkowników w różnych strefach czasowych dobór jednej wspólnej godziny bywa trudniejszy niż w typowej firmie pracującej wyłącznie w standardowych godzinach dziennych - podobny problem opisano już przy okazji harmonogramu odbudowy indeksów bazy danych.
W takich przypadkach warto rozważyć wybór godziny przypadającej na najkrótsze, wspólne dla wszystkich zmian okno ciszy operacyjnej - często będzie to środek nocy czasu lokalnego głównej siedziby firmy, nawet jeśli nie jest to idealne rozwiązanie dla każdej pojedynczej lokalizacji. Alternatywą, stosowaną w bardziej rozbudowanych wdrożeniach obejmujących wiele niezależnych serwerów terminali, jest przypisanie każdemu z nich osobnego wiersza w tabeli _jobs z własną, dopasowaną do lokalnej strefy czasowej wartością parametru ServerResetHour.
Ryzyka nieskoordynowanego restartu
Restart systemu operacyjnego bezwarunkowo kończy wszystkie aktywne sesje użytkowników, niezależnie od tego, czy w danym momencie ktoś faktycznie pracuje na serwerze, czy nie. Uruchomienie tego zadania bez wcześniejszego, kontrolowanego wylogowania użytkowników grozi utratą niezapisanej pracy każdej osoby, która akurat korzysta z serwera terminali w chwili restartu.
Z tego powodu zadanie to nigdy nie powinno działać w pełnej izolacji od pozostałych elementów sekwencji - jego bezpieczeństwo operacyjne zależy bezpośrednio od poprawnego skonfigurowania i przetestowania całego łańcucha zadań, a nie tylko samego restartu z osobna.
Praktyczną konsekwencją tej zależności jest to, że każda zmiana harmonogramu jednego z trzech zadań tej sekwencji powinna być weryfikowana pod kątem wpływu na pozostałe dwa. Przesunięcie godziny restartu bez odpowiedniego przesunięcia wcześniejszego wylogowania użytkowników odtwarza dokładnie to samo ryzyko utraty niezapisanej pracy, przed którym cała trójetapowa sekwencja miała pierwotnie chronić.
Dobre praktyki
Kilka zasad pomaga bezpiecznie utrzymać to zadanie niezależnie od skali wdrożenia:
- Zachowanie kolejności zadań - restart powinien następować dopiero po zakończeniu zadania wylogowania użytkowników, nigdy przed nim ani równolegle.
- Odpowiedni margines czasowy - między wylogowaniem a restartem oraz między restartem a startem pracy użytkowników warto zostawić bezpieczny zapas czasu.
- Informowanie użytkowników z wyprzedzeniem - stały, dobrze znany wszystkim harmonogram restartu pozwala pracownikom samodzielnie zadbać o zapisanie pracy przed zamknięciem sesji.
- Weryfikacja powiadomień - pole MAILPOWIADOMIENIE potwierdza, że restart faktycznie się wykonał zgodnie z ustalonym harmonogramem.
Warto też pamiętać, że sam restart nie rozwiązuje problemów wynikających z niedoboru zasobów sprzętowych serwera - jeśli wycieki pamięci czy przeciążenie procesora pojawiają się już w ciągu kilku godzin od restartu, a nie po całym dniu pracy, jest to sygnał, że problem wymaga głębszej diagnozy, a nie tylko coraz częstszych restartów. Częstsze restarty w takiej sytuacji jedynie maskują objaw, zamiast rozwiązywać jego rzeczywistą przyczynę, którą może być na przykład niedoszacowana ilość pamięci RAM w stosunku do liczby jednocześnie pracujących użytkowników.
Podsumowanie
Restart serwera RDP to proste w konfiguracji, ale odczuwalne w skutkach zadanie SSJob, przywracające serwer terminali do stanu wolnego od narosłych w ciągu dnia problemów pamięci i osieroconych sesji. Konfiguruje się je wierszem w tabeli _jobs z parametrem ServerResetHour wskazującym godzinę wykonania.
Pełne bezpieczeństwo tego zadania zapewnia dopiero jego właściwe miejsce w sekwencji z zadaniami wylogowania użytkowników i czyszczenia serwera, opisanymi osobno w kolejnych materiałach tej samej serii poświęconej utrzymaniu serwera terminali RDP. Traktowanie tych trzech zadań jako jednej, spójnej całości, a nie osobnych, niezależnych mechanizmów, jest kluczem do bezpiecznej i przewidywalnej konserwacji serwera terminali w każdym wdrożeniu StudioSystem.