Zmienna nie przechodzi do sesji RDP

Zmienna nieprzechodząca do sesji RDP wskazuje na osobne środowisko sesji zdalnej, niedziedziczące zmiennych z sesji lokalnej.

Zmienna nie przechodzi do sesji RDP – co oznacza ten komunikat

Określenie „Zmienna nie przechodzi do sesji RDP” odnosi się do sytuacji, w której program uruchomiony w połączeniu pulpitu zdalnego nie widzi wartości ustawionej wcześniej na komputerze, z którego nawiązano połączenie. Może chodzić o zmienną środowiskową, parametr konfiguracyjny, ścieżkę do katalogu, nazwę użytkownika, lokalizację pliku albo wartość przekazaną przez skrypt. Nie oznacza to zazwyczaj uszkodzenia samego programu. Częściej wskazuje na rozdzielenie dwóch środowisk: lokalnego oraz tego, które działa wewnątrz sesji RDP.

Połączenie RDP nie przenosi całego stanu komputera użytkownika do zdalnego systemu. Otwierana jest odrębna sesja z własnym pulpitem, procesami, ustawieniami użytkownika oraz zestawem zmiennych środowiskowych. Wartość dostępna w wierszu polecenia na komputerze lokalnym może więc nie istnieć po zalogowaniu do systemu zdalnego. Podobny efekt występuje, gdy sesja została uruchomiona z innym kontem, za pomocą innego mechanizmu logowania lub przy odmiennych uprawnieniach.

W praktyce problem może objawiać się komunikatem o nieznanej zmiennej, pustą wartością zwracaną przez skrypt, błędem ścieżki albo uruchomieniem niewłaściwej wersji programu. Czasami aplikacja działa poprawnie po uruchomieniu lokalnie, lecz przestaje reagować po otwarciu jej w sesji zdalnej. Warto wtedy przyjąć, że środowisko RDP jest niezależnym miejscem wykonywania poleceń i wymaga osobnej konfiguracji.

Zmienna w RDP a granica między sesją lokalną i zdalną

Najważniejszą różnicą jest zakres obowiązywania ustawienia. Zmienna ustawiona tymczasowo w jednym oknie wiersza polecenia obowiązuje tylko w procesie, który ją otrzymał, oraz w procesach uruchomionych z tego miejsca. Po zamknięciu okna może zniknąć. Z kolei wartość zapisana w profilu użytkownika jest dostępna dopiero dla procesów uruchomionych po ponownym odczytaniu profilu. Ustawienie zapisane dla całego systemu może być widoczne dla innych użytkowników, ale jego użycie nadal zależy od sposobu uruchomienia programu.

Sesja RDP może korzystać z innego profilu niż sesja lokalna. Dotyczy to szczególnie sytuacji, w której połączenie odbywa się przy użyciu konta domenowego, konta technicznego albo użytkownika o podobnej nazwie, lecz z innym identyfikatorem. W takim przypadku zmienna zapisana w jednym profilu nie pojawi się automatycznie w drugim. Różnice mogą dotyczyć również katalogu domowego, mapowanych dysków, bieżącego katalogu roboczego i listy folderów przeszukiwanych podczas uruchamiania programów.

Znaczenie ma także sposób startu aplikacji. Program uruchomiony z menu systemowego może otrzymać inny zestaw ustawień niż skrypt uruchomiony z harmonogramu, usługi lub zdalnej konsoli. Niektóre mechanizmy odczytują wartości podczas logowania, inne dopiero podczas startu procesu. Z tego powodu sama obecność zmiennej w ustawieniach systemu nie przesądza jeszcze o tym, że będzie ona dostępna w działającej aplikacji.

Przy porównywaniu środowisk warto rozróżnić trzy elementy: miejsce, w którym zmienna została zapisana, konto, które uruchamia program, oraz moment, w którym program odczytuje wartość. Jeśli którykolwiek z tych elementów jest inny, zachowanie w sesji zdalnej może odbiegać od zachowania lokalnego. Taka analiza jest bardziej miarodajna niż wielokrotne ponowne logowanie bez sprawdzenia źródła ustawienia.

Typowe przyczyny, przez które zmienna nie przechodzi do sesji RDP

Jedną z częstszych przyczyn jest ustawienie zmiennej wyłącznie w bieżącym oknie terminala. Przykładowo polecenie wykonane w jednej sesji może wpływać na kolejne polecenia uruchomione z tego samego okna, ale nie musi zmieniać profilu użytkownika ani ustawień systemowych. Po połączeniu przez RDP otwierane jest nowe środowisko, które nie zna wartości z poprzedniego procesu.

Innym powodem bywa zapisanie zmiennej w niewłaściwej części konfiguracji. Wartość użytkownika będzie dostępna dla jednego profilu, natomiast wartość systemowa może być potrzebna programowi uruchamianemu z konta używanego przez zadanie automatyczne. Odwrotna sytuacja również jest możliwa: zmienna istnieje na poziomie systemu, lecz aplikacja została skonfigurowana tak, aby korzystać z własnego pliku ustawień i ignorować środowisko procesu.

Problem może wynikać z kolejności uruchamiania. Jeżeli zmienna została dodana po rozpoczęciu sesji RDP, już otwarte programy mogą nadal korzystać ze starego zestawu wartości. Zamknięcie samej aplikacji czasem nie wystarcza, gdy została uruchomiona przez proces nadrzędny, który przechował wcześniejsze środowisko. W takich przypadkach potrzebne bywa pełne wylogowanie z sesji i ponowne zalogowanie.

Nie należy pomijać literówek oraz różnic w zapisie. Nazwy zmiennych mogą być wrażliwe na sposób odczytu przez konkretny program, a dodatkowa spacja, cudzysłów lub znak końca linii może zmienić wartość. Błąd może także dotyczyć ścieżki zawierającej spacje, niedostępnego dysku, innego oznaczenia katalogu albo lokalizacji, która istnieje na komputerze lokalnym, ale nie istnieje w systemie zdalnym.

Warto również sprawdzić ograniczenia wynikające z uprawnień. Program uruchomiony z podwyższonym poziomem uprawnień może otrzymać inny zestaw ustawień niż zwykły proces użytkownika. Znaczenie może mieć także przekierowanie schowka, dysków, portów lub drukarek. Takie przekierowanie nie powoduje automatycznego skopiowania wszystkich zmiennych środowiskowych. Dostęp do zasobu oraz dostęp do wartości konfiguracyjnej są odrębnymi mechanizmami.

Jak sprawdzić zmienną, która nie przechodzi do sesji RDP

Diagnostykę najlepiej rozpocząć od sprawdzenia, czy problem występuje rzeczywiście w samej sesji zdalnej. Po zalogowaniu przez RDP należy otworzyć terminal i odczytać interesującą wartość bezpośrednio w tym środowisku. Następnie można wykonać taki sam odczyt lokalnie, korzystając z tego samego konta, o ile jest to możliwe. Porównanie powinno obejmować nie tylko rezultat, lecz także nazwę użytkownika, katalog roboczy oraz sposób uruchomienia polecenia.

Jeżeli lokalnie widoczna jest pełna ścieżka, a w sesji zdalnej pojawia się pusty wynik, należy ustalić, gdzie została zapisana zmienna. Pomocne jest sprawdzenie ustawień użytkownika i ustawień systemowych, a także ponowne otwarcie terminala po wprowadzeniu zmiany. Gdy wartość jest obecna w terminalu, lecz nie działa w aplikacji, trzeba porównać sposób startu programu. Szczególnej uwagi wymagają skróty, pliki wsadowe, skrypty oraz zadania uruchamiane automatycznie.

Przydatne jest przygotowanie małego testu, który zapisuje do pliku nazwę konta, bieżący katalog, listę dostępnych zmiennych i ścieżkę używaną do wyszukiwania programu. Taki raport pozwala ustalić, czy aplikacja działa w tej samej sesji, w której wykonano test. Należy unikać umieszczania w raporcie haseł, tokenów oraz danych dostępowych. Wartości wrażliwe powinny zostać zastąpione opisem albo usunięte przed przekazaniem pliku do analizy.

Gdy zmienna ma być dostępna stale, trzeba zapisać ją w odpowiednim profilu lub w konfiguracji systemowej, zgodnie z przeznaczeniem. Po zmianie należy ponownie uruchomić proces, a w razie potrzeby wylogować sesję RDP. Jeżeli aplikacja korzysta z własnego pliku konfiguracyjnego, bezpieczniej jest uzupełnić właściwy plik niż polegać na przypadkowym dziedziczeniu środowiska. W przypadku skryptów należy jawnie przekazywać potrzebne parametry albo definiować je na początku skryptu, zamiast zakładać, że pojawią się samoczynnie.

Kiedy zgłosić problem „Zmienna nie przechodzi do sesji RDP”

Do serwisu warto zgłosić się wtedy, gdy połączenie zdalne działa, lecz aplikacja nadal otrzymuje pustą lub nieprawidłową wartość mimo sprawdzenia profilu, konta i sposobu uruchamiania. Pomoc może być potrzebna również wtedy, gdy problem pojawia się tylko dla jednego użytkownika, po zmianie hasła, po aktualizacji systemu albo po modyfikacji zasad logowania. Przed przekazaniem urządzenia lub danych należy przygotować opis kolejnych czynności, komunikat błędu oraz informację, czy ta sama funkcja działa poza sesją RDP.

W Warszawie takie przypadki można skonsultować z firmą Warszawskie Pogotowie Komputerowe 24/7. Przydatne będzie wskazanie, czy chodzi o komputer lokalny, system zdalny, konkretny program oraz konto używane do logowania. W analizie można uwzględnić konfigurację środowiska, profile użytkowników, skrypty startowe, ścieżki dostępu i zależności między procesem uruchamiającym a aplikacją. Pozwala to odróżnić brak zmiennej od problemu z uprawnieniami, ścieżką, profilem albo samym programem.

Nie zaleca się usuwania przypadkowych wpisów z konfiguracji ani kopiowania całego środowiska między komputerami bez wcześniejszego sprawdzenia zależności. Zmiana może wpłynąć na inne aplikacje, skrypty i zadania automatyczne. Bezpieczniejsze jest zapisanie aktualnych ustawień, określenie oczekiwanego zakresu zmiennej i wprowadzenie jednej kontrolowanej korekty. Po wykonaniu zmiany należy ponownie uruchomić sesję RDP, sprawdzić wartość w terminalu oraz potwierdzić działanie programu, który wcześniej zgłaszał problem.