Czyszczenie serwera RDP to zadanie cykliczne usługi SSJob, usuwające zawartość zdefiniowanych folderów tymczasowych każdego użytkownika serwera terminali. Zamyka trójetapową sekwencję konserwacji, następując po wylogowaniu nieaktywnych użytkowników i restarcie serwera.
Czym jest czyszczenie serwera RDP
Czyszczenie serwera RDP to trzecie i ostatnie zadanie w sekwencji konserwacji serwera terminali StudioSystem. Podczas gdy restart porządkuje pamięć i procesy systemowe, a wylogowanie kończy zapomniane sesje, to zadanie zajmuje się czymś innym - miejscem na dysku zajmowanym przez pliki tymczasowe gromadzące się w profilach poszczególnych użytkowników w trakcie codziennej pracy.
Każda aplikacja uruchamiana w ramach sesji RDP zostawia po sobie pewien ślad na dysku - pliki cache, dane robocze, tymczasowe kopie dokumentów. Przy wielu użytkownikach korzystających z tego samego serwera terminali przez dłuższy czas te pozornie niewielkie ilości danych potrafią się sumować do zauważalnej wielkości, zajmując miejsce, które lepiej wykorzystać na rzeczywiste potrzeby systemu.
Mechanizm ten uzupełnia pozostałe zadania serii poświęconej infrastrukturze serwerowej, obok synchronizacji HelpDesk czy eksportu XLSX pokazując, że ten sam, uniwersalny mechanizm konfiguracyjny tabeli _jobs potrafi obsłużyć zadania równie odległe od siebie jak import wiadomości e-mail, generowanie arkuszy danych czy porządkowanie systemu plików serwera terminali.
Mechanizm znacznika [USERNAME]
Kluczowym elementem konfiguracji jest parametr Paths, w którym zamiast osobno wypisywać ścieżkę folderu tymczasowego dla każdego konta z osobna, wykorzystuje się jeden uniwersalny wzorzec zawierający znacznik [USERNAME]. W trakcie wykonania zadania znacznik ten jest automatycznie podmieniany na rzeczywistą nazwę konta, osobno dla każdego profilu użytkownika obecnego na danym serwerze.
Takie podejście eliminuje konieczność ręcznego aktualizowania konfiguracji za każdym razem, gdy w firmie pojawia się nowy pracownik korzystający z serwera terminali - jeden wzorzec ścieżki z znacznikiem [USERNAME] automatycznie obejmuje wszystkie istniejące, jak i przyszłe konta użytkowników, bez potrzeby jakiejkolwiek dodatkowej interwencji administratora.
Ten sam wzorzec projektowy - jedna definicja obsługująca dowolną liczbę rzeczywistych obiektów dzięki podmienianemu znacznikowi - pojawia się w informatyce bardzo często, właśnie ze względu na tę własność samoobsługowego skalowania się wraz ze wzrostem liczby użytkowników czy zasobów, bez potrzeby proporcjonalnego rozrostu samej konfiguracji.
Konfiguracja w tabeli _jobs
Zadanie czyszczenia serwera korzysta ze znanego zestawu pól tabeli _jobs, uzupełnionego o dwa 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. dni |
| MAILPOWIADOMIENIE | Adresy e-mail, na które trafią powiadomienia o wykonaniu zadania |
| CONECTIONSTRINGNAME | Łańcuch połączeniowy wskazujący bazę danych StudioSystem |
| PARAMETRY: ActiveServers | Lista serwerów objętych czyszczeniem, rozdzielona znakiem @ |
| PARAMETRY: Paths | Lista wzorców ścieżek folderów tymczasowych ze znacznikiem [USERNAME] |
Ten sam parametr ActiveServers co przy wylogowaniu użytkowników pozwala konsekwentnie stosować identyczną listę docelowych serwerów we wszystkich trzech zadaniach tej sekwencji, ograniczając ryzyko rozjazdu konfiguracji między poszczególnymi etapami. Taka spójność ma znaczenie praktyczne - gdyby lista serwerów w każdym z trzech zadań była utrzymywana osobno, łatwo o sytuację, w której nowo dodany serwer zostanie uwzględniony w jednym zadaniu, a przeoczony w pozostałych dwóch, prowadząc do niespójnego stanu konserwacji w obrębie tej samej infrastruktury.
Odzyskana przestrzeń bez ingerencji ręcznej
Cykliczne czyszczenie folderów tymczasowych zapobiega niepostrzeżenie narastającemu zapełnianiu dysku serwera terminali.
Czyszczenie wielu serwerów naraz
Podobnie jak przy wylogowaniu użytkowników, jedno zadanie może objąć swoim działaniem więcej niż jeden serwer terminali dzięki liście w parametrze ActiveServers. Ma to szczególne znaczenie w większych wdrożeniach, gdzie różne grupy użytkowników - na przykład dział handlowy i dział magazynowy - korzystają z osobnych, dedykowanych im serwerów RDP, a mimo to podlegają tej samej, spójnej polityce utrzymania czystości dysku.
Parametr Paths może przy tym zawierać więcej niż jeden wzorzec ścieżki jednocześnie, obejmując kilka różnych folderów tymczasowych właściwych różnym typom aplikacji uruchamianych przez użytkowników - od standardowych folderów tymczasowych systemu Windows po dedykowane katalogi cache konkretnych programów wykorzystywanych w danym wdrożeniu.
Taka elastyczność pozwala z czasem rozbudowywać zakres czyszczenia w miarę poznawania, które aplikacje najbardziej przyczyniają się do narastania zajmowanej przestrzeni dyskowej, bez konieczności tworzenia osobnego zadania SSJob dla każdego kolejnego typu pliku tymczasowego wartego regularnego usuwania.
Dlaczego po restarcie serwera
Wykonywanie czyszczenia jako ostatniego etapu sekwencji, już po restarcie serwera, ma istotne uzasadnienie techniczne. Po pełnym restarcie systemu operacyjnego żaden proces nie trzyma już otwartych uchwytów do plików znajdujących się w folderach tymczasowych poszczególnych profili - wszystkie aplikacje, które mogłyby blokować dostęp do tych plików, zostały zamknięte wraz z zakończeniem poprzednich sesji.
Dzięki temu operacja usuwania plików przebiega bezproblemowo, bez błędów wynikających z prób skasowania pliku wciąż używanego przez działający proces. Próba wykonania tego samego czyszczenia w trakcie aktywnej pracy użytkowników byłaby znacznie bardziej ryzykowna i mogłaby zakończyć się częściowym niepowodzeniem operacji dla części plików.
Kolejność ta ma też znaczenie z punktu widzenia spójności całej sekwencji - gdyby czyszczenie wykonywało się przed restartem, część plików tymczasowych należących do sesji zakończonych dopiero w trakcie samego wylogowania mogłaby zostać pominięta, ponieważ proces, który je utworzył, wciąż formalnie by działał. Wykonanie czyszczenia jako ostatniego kroku gwarantuje, że w momencie jego uruchomienia serwer znajduje się już w stanie w pełni ustabilizowanym po poprzednich dwóch etapach.
Ryzyka błędnej konfiguracji ścieżek
Parametr Paths, mimo swojej prostoty, wymaga szczególnej ostrożności przy konfiguracji. Błędnie wskazana ścieżka - zbyt ogólna albo wskazująca niewłaściwy katalog - może doprowadzić do usunięcia danych spoza właściwego folderu tymczasowego, w tym potencjalnie plików roboczych użytkownika, które wcale nie powinny zostać skasowane.
Z tego powodu każdą nową ścieżkę dodawaną do parametru Paths warto najpierw przetestować na pojedynczym koncie testowym, zanim zostanie zastosowana do wszystkich profili na produkcyjnym serwerze terminali. Ostrożność ta jest tym bardziej uzasadniona, że mechanizm znacznika [USERNAME] automatycznie rozszerza działanie zadania na każdego użytkownika serwera - błąd w jednej ścieżce natychmiast dotyka wszystkich kont naraz, a nie tylko pojedynczego przypadku.
Ta sama własność, która czyni znacznik [USERNAME] tak wygodnym w codziennym utrzymaniu - automatyczne objęcie każdego istniejącego konta bez ręcznej interwencji - staje się źródłem ryzyka w chwili, gdy ścieżka zostanie skonfigurowana nieprawidłowo. Zamiast błędu ograniczonego do jednego konta testowego, administrator otrzymuje wtedy błąd powielony jednocześnie na wszystkich profilach obecnych na danym serwerze, co czyni fazę testową znacznie ważniejszą niż przy typowej, jednorazowej operacji na pojedynczym folderze.
Dobre praktyki
Kilka zasad pomaga bezpiecznie utrzymać to zadanie niezależnie od skali wdrożenia:
- Testowanie nowych ścieżek - każda zmiana w parametrze Paths powinna zostać najpierw dokładnie zweryfikowana na koncie testowym, zanim trafi na środowisko produkcyjne.
- Zachowanie kolejności w sekwencji - czyszczenie powinno uruchamiać się dopiero po pełnym zakończeniu restartu, nigdy przed nim ani równolegle z nim.
- Spójna lista ActiveServers - warto utrzymywać identyczną listę serwerów we wszystkich trzech zadaniach tej sekwencji, by uniknąć rozjazdu konfiguracji.
- Weryfikacja powiadomień - pole MAILPOWIADOMIENIE potwierdza, że czyszczenie faktycznie się wykonało zgodnie z harmonogramem.
Warto też pamiętać, że to zadanie, podobnie jak pozostałe elementy sekwencji, działa najskuteczniej jako regularna, cykliczna praktyka, a nie jednorazowa interwencja podejmowana dopiero wtedy, gdy brak miejsca na dysku serwera staje się realnym problemem operacyjnym. Podobnie jak przy planowaniu odbudowy indeksów bazy danych, regularność działania jest tu ważniejsza niż jednorazowa, dokładna interwencja wykonana pod presją brakującej przestrzeni dyskowej.
Podsumowanie
Czyszczenie serwera RDP to ostatni, zamykający element trójetapowej sekwencji konserwacji serwera terminali StudioSystem, odzyskujący przestrzeń dyskową zajmowaną przez pliki tymczasowe poszczególnych profili użytkowników. Konfiguruje się je wierszem w tabeli _jobs z dwoma dodatkowymi parametrami - listą obsługiwanych serwerów i listą wzorców ścieżek wykorzystujących znacznik [USERNAME].
Razem z wylogowaniem nieaktywnych użytkowników i restartem serwera, to zadanie domyka pełny, spójny cykl utrzymania serwera terminali w dobrej kondycji, bez konieczności codziennej, ręcznej interwencji administratora.