Mapowanie działa tylko lokalnie – brak przez RDP

Mapowanie działające tylko lokalnie, bez dostępu przez RDP, wskazuje na ograniczenie sesji zdalnej niewidzącej mapowań utworzonych w kontekście lokalnej sesji interaktywnej.

Mapowanie działa tylko lokalnie – na czym polega problem

Mapowanie zasobu sieciowego oznacza przypisanie udziału, folderu albo innej lokalizacji dostępnej w sieci do wybranej litery dysku. Dzięki temu zasób może być otwierany podobnie jak dysk znajdujący się fizycznie w komputerze, a programy mogą korzystać z niego za pomocą stałej ścieżki. Jeżeli takie mapowanie działa podczas pracy przy komputerze, lecz znika albo przestaje odpowiadać po połączeniu przez RDP, zwykle nie oznacza to uszkodzenia samego udziału. Najczęściej widoczne jest rozdzielenie dwóch środowisk logowania: lokalnej sesji interaktywnej oraz sesji uruchomionej zdalnie.

Każda sesja użytkownika może mieć własny kontekst bezpieczeństwa, zestaw poświadczeń, dostępne dyski oraz zmienne środowiskowe. Mapa utworzona w jednym kontekście nie musi być automatycznie przekazywana do drugiego. Zdalny pulpit może więc pokazywać inny zestaw liter dysków niż ten, który jest widoczny przed nawiązaniem połączenia. Podobna sytuacja występuje wtedy, gdy mapowanie zostało wykonane ręcznie w Eksploratorze plików, ale program uruchamiany w sesji zdalnej działa z innymi uprawnieniami lub pod innym kontem.

Warto odróżnić brak widoczności mapowania od braku dostępu do danych. W pierwszym przypadku udział może być osiągalny po wpisaniu pełnej ścieżki UNC, na przykład w formacie \\nazwa-komputera\udział, mimo że przypisana litera dysku nie jest prezentowana. W drugim przypadku pojawia się odmowa dostępu, monit o dane logowania, komunikat o niedostępnej lokalizacji albo błąd połączenia. Rozróżnienie tych objawów ułatwia ustalenie, czy problem dotyczy samego mapowania, przekazywania urządzeń do sesji RDP, poświadczeń, uprawnień NTFS i udziału, czy łączności sieciowej.

Dlaczego lokalna litera dysku może nie być dostępna przez RDP

Najczęstszą przyczyną jest to, że mapowanie zostało utworzone przed połączeniem zdalnym i należy do lokalnej sesji. Po uruchomieniu RDP powstaje odrębne środowisko pracy, które nie zawsze dziedziczy wcześniej przypisane dyski. W praktyce użytkownik może widzieć mapowanie na komputerze fizycznym, ale nie w oknie zdalnego pulpitu. Zależność ta jest szczególnie widoczna przy korzystaniu z kilku kont, logowaniu przy użyciu różnych nazw użytkownika albo uruchamianiu części programów z podwyższonymi uprawnieniami.

Drugim źródłem problemu są ustawienia klienta RDP. Przekierowanie dysków lokalnych i zasobów komputera może być wyłączone w konfiguracji połączenia, ograniczone przez zasady systemowe albo zablokowane po stronie komputera, z którym następuje połączenie. Przekierowanie nie jest tym samym co zwykłe mapowanie udziału sieciowego. W pierwszym wariancie lokalny dysk może zostać udostępniony w sesji zdalnej jako urządzenie przekierowane, natomiast w drugim przypadku tworzona jest ścieżka do udziału dostępnego w sieci. Oba mechanizmy mają inne wymagania i inne komunikaty błędów.

Znaczenie może mieć również kolejność uruchamiania skryptów i aplikacji. Jeżeli skrypt mapujący wykonuje się tylko podczas logowania lokalnego, nie zostanie ponownie uruchomiony po wejściu do sesji RDP. Podobnie może zachować się zadanie zaplanowane wyłącznie dla określonego typu logowania. Należy sprawdzić, czy polecenie net use, skrypt PowerShell albo ustawienie zasad grupy wykonuje się w odpowiednim momencie i w kontekście właściwego użytkownika. Przydatne jest porównanie wyników polecenia net use uruchomionego lokalnie oraz w sesji zdalnej.

Mapowanie może być też ukryte przez różnicę między trybem zwykłym a trybem administratora. System potrafi utrzymywać odrębne widoki mapowanych dysków dla procesów działających z innym poziomem uprawnień. W rezultacie udział widoczny w Eksploratorze może nie pojawić się w aplikacji uruchomionej jako administrator albo odwrotnie. Nie powinno się rozwiązywać tego przez przypadkowe wyłączanie zabezpieczeń. Najpierw trzeba ustalić, który proces tworzy mapowanie, pod jakim kontem działa i czy aplikacja rzeczywiście wymaga podwyższonych uprawnień.

Typowe objawy, błędy i sposób weryfikacji

Objawem charakterystycznym dla tej usterki jest sytuacja, w której litera dysku jest dostępna po zalogowaniu lokalnym, lecz nie występuje w Eksploratorze otwartym przez RDP. Czasem mapa pojawia się, ale po kliknięciu wyświetlany jest komunikat o braku ścieżki. Innym razem dostęp działa przez kilka minut, po czym zostaje utracony po uśpieniu komputera, zmianie sieci, odnowieniu połączenia VPN albo ponownym uwierzytelnieniu. Jeżeli problem występuje wyłącznie w jednej aplikacji, należy dodatkowo sprawdzić jej uprawnienia, sposób zapisywania ścieżek oraz to, czy nie korzysta z własnego mechanizmu dostępu do plików.

Wstępna diagnostyka powinna obejmować kilka prostych porównań:

• sprawdzenie, czy zasób odpowiada po użyciu pełnej ścieżki UNC;
• porównanie listy mapowań w lokalnej sesji i w sesji RDP;
• ustalenie, czy używane jest to samo konto użytkownika;
• weryfikację, czy klient RDP ma włączone właściwe przekierowanie dysków;
• sprawdzenie, czy połączenie z udziałem wymaga ponownego podania poświadczeń;
• porównanie dostępu z poziomu Eksploratora, wiersza polecenia oraz konkretnej aplikacji;
• sprawdzenie, czy skrypt logowania lub zadanie automatyzujące zostało uruchomione w sesji zdalnej.

Warto zwrócić uwagę na dokładną treść komunikatu. Informacja o nieznalezieniu ścieżki może wskazywać na brak mapowania lub niedostępność nazwy urządzenia. Odmowa dostępu kieruje uwagę w stronę uprawnień. Prośba o poświadczenia może oznaczać, że sesja RDP nie korzysta z tych samych danych uwierzytelniających co lokalna praca. Z kolei komunikat o rozłączeniu urządzenia może wiązać się z przekierowaniem zasobów lokalnych, polityką bezpieczeństwa albo zerwaniem połączenia sieciowego.

Nie zaleca się tworzenia wielu mapowań o tej samej literze ani umieszczania haseł bezpośrednio w skryptach. Takie działania mogą utrudnić rozpoznanie przyczyny i zwiększyć ryzyko ujawnienia danych dostępowych. Bezpieczniejsze jest uporządkowanie sposobu logowania, użycie właściwych poświadczeń systemowych oraz ustawienie mapowania w miejscu odpowiadającym rzeczywistemu sposobowi pracy. Jeżeli zasób ma być używany przez konkretny program, trzeba także sprawdzić, czy program akceptuje literę dysku, czy wymaga pełnej ścieżki sieciowej.

Kiedy warto oddać urządzenie do diagnozy - Mapowanie działa tylko lokalnie – brak przez RDP

Zgłoszenie do serwisu jest uzasadnione, gdy mapowanie działa tylko w wybranych sesjach, znika po restarcie, powoduje blokowanie programów albo wymaga każdorazowego ręcznego odtwarzania. Weryfikacji wymaga również sytuacja, w której przez RDP nie są widoczne nie tylko mapowane udziały, lecz także lokalne dyski, drukarki lub inne zasoby przekierowywane do sesji. Taki zestaw objawów może wskazywać na szerszy problem z konfiguracją zdalnego pulpitu, zasadami bezpieczeństwa, profilem użytkownika albo usługami sieciowymi.

Przed przekazaniem urządzenia do sprawdzenia warto zanotować, czy problem występuje na każdym koncie, od kiedy się pojawia, czy dotyczy jednego komputera zdalnego oraz jaki komunikat jest wyświetlany. Przydatne są również informacje o tym, czy dostęp przez pełną ścieżkę UNC działa, czy połączenie odbywa się przez VPN i czy mapa była tworzona ręcznie, skryptem, czy za pomocą zasad systemowych. Takie dane skracają drogę do rozpoznania, ponieważ pozwalają od razu oddzielić problem z widocznością litery od problemu z siecią i uprawnieniami.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić uporządkowanie konfiguracji komputera, profilu użytkownika oraz dostępu zdalnego, a przy zgłoszeniu laptopa dostępna jest darmowa diagnoza LAPTOPA. Podczas sprawdzania analizuje się zależności między sesją lokalną a RDP, sposób tworzenia mapowania, uprawnienia oraz zachowanie aplikacji korzystających z udziału. Dzięki temu rozwiązanie może zostać dobrane do rzeczywistego sposobu pracy, zamiast ograniczać się do ponownego przypisania litery dysku bez usunięcia przyczyny.

Po zakończeniu diagnostyki powinno być jasno określone, czy zasób ma być udostępniany jako przekierowany dysk lokalny, jako udział sieciowy, czy przez skrypt wykonywany podczas logowania do sesji zdalnej. Należy również ustalić, jakie konto ma korzystać z dostępu i czy wymagane jest ponowne uwierzytelnienie. Takie uporządkowanie zmniejsza ryzyko powrotu problemu po restarcie, zmianie hasła, ponownym połączeniu RDP albo aktualizacji ustawień bezpieczeństwa.