Zadania Harmonogramu nie widzą zmapowanych dysków

Zadania Harmonogramu niewidzące zmapowanych dysków wskazują na mapowanie utworzone w kontekście sesji interaktywnej, niewidoczne dla zadań systemowych.

Zadania Harmonogramu a zmapowane dyski w sesji użytkownika

Problem opisany jako „Zadania Harmonogramu nie widzą zmapowanych dysków” pojawia się wtedy, gdy program uruchamiany przez Harmonogram zadań próbuje odwołać się do litery dysku, która jest dostępna podczas zwykłej pracy przy komputerze, ale nie istnieje w chwili wykonywania zadania. Zmapowany dysk nie jest tym samym co fizyczny dysk zamontowany wewnątrz obudowy. Litera taka jak Z:, Y: albo W: jest zazwyczaj skrótem prowadzącym do udziału sieciowego, czyli folderu udostępnionego przez inny komputer lub urządzenie znajdujące się w tej samej sieci.

Mapowanie jest zapisywane w określonym kontekście logowania. Oznacza to, że może być widoczne dla osoby, która otworzyła Eksplorator plików i zalogowała się do systemu, lecz niewidoczne dla procesu uruchamianego bez aktywnego pulpitu. Harmonogram zadań może działać przy zalogowanym użytkowniku, przy dowolnym zalogowaniu albo bez zalogowania. Każdy z tych wariantów wpływa na dostęp do poświadczeń, zmiennych środowiskowych, profilu użytkownika i wcześniejszych mapowań.

Najczęściej nie oznacza to uszkodzenia udziału sieciowego. Przyczyną jest różnica między interaktywną sesją użytkownika a sesją procesu uruchomionego w tle. Zadanie może poprawnie otwierać pliki zapisane lokalnie, a jednocześnie zgłaszać brak ścieżki wskazanej literą dysku. Podobnie może zachowywać się skrypt, kopia zapasowa, program księgowy, narzędzie synchronizujące dane albo aplikacja przetwarzająca dokumenty.

Zadania Harmonogramu: litera dysku, ścieżka UNC i konto uruchamiające

Podstawowe porównanie dotyczy dwóch sposobów wskazywania zasobu. Litera dysku jest wygodna dla człowieka, ponieważ pozwala korzystać z krótkiej ścieżki, na przykład Z:\projekty\dokumenty. Dla zadania wykonywanego w tle bezpieczniejsza bywa pełna ścieżka sieciowa w formacie UNC, na przykład \\nazwa-komputera\udział\projekty\dokumenty. Taki zapis nie zależy od tego, czy w danej sesji utworzono mapowanie litery Z.

Nie każda zmiana samej ścieżki rozwiąże problem. Proces musi jeszcze posiadać uprawnienia do odczytu i zapisu oraz możliwość uwierzytelnienia się w zasobie. Konto używane przez zadanie może różnić się od konta aktualnie zalogowanego. Jeżeli zadanie jest skonfigurowane tak, aby działało niezależnie od zalogowania, nie należy zakładać, że odziedziczy mapowania wykonane wcześniej w Eksploratorze plików.

Znaczenie ma również moment uruchomienia. Jeżeli komputer dopiero nawiązuje połączenie z siecią, serwer plików lub urządzenie udostępniające folder może nie być jeszcze dostępne. Zadanie uruchomione natychmiast po starcie systemu może więc zakończyć się błędem, mimo że kilka minut później ten sam zasób działa prawidłowo. Warto odróżnić błąd braku litery dysku od błędu odmowy dostępu, niedostępności nazwy komputera oraz chwilowego braku połączenia.

W praktyce przydatne jest sprawdzenie, czy problem dotyczy wyłącznie litery, czy całego udziału. Jeśli ścieżka UNC również nie działa z poziomu tego samego konta, należy zbadać dostęp do sieci, nazwę udziału, poświadczenia i uprawnienia folderu. Jeśli ścieżka UNC działa, a litera dysku nie, przyczyną jest najczęściej kontekst mapowania.

„Nie widzą zmapowanych dysków” – typowe objawy i przyczyny

• Program uruchamiany ręcznie odczytuje pliki z dysku Z, lecz uruchomiony przez Harmonogram zgłasza brak katalogu.
• Skrypt działa po otwarciu okna wiersza polecenia, ale kończy się błędem przy uruchomieniu w tle.
• W historii zadania pojawia się kod błędu związany z nieodnalezieniem ścieżki, mimo że dysk jest widoczny w Eksploratorze.
• Pliki są dostępne po zalogowaniu, ale nie podczas pracy zadania ustawionego na wykonanie bez logowania.
• Zadanie działa po restarcie dopiero po ręcznym otwarciu udziału sieciowego.
• Występują różnice między uruchomieniem zadania z uprawnieniami standardowego użytkownika a uruchomieniem z podwyższonymi uprawnieniami.

Częstą przyczyną jest zapisanie w skrypcie ścieżki względnej albo odwołania do folderu zdefiniowanego tylko w profilu użytkownika. Program może także korzystać z bieżącego katalogu roboczego, który przy uruchomieniu ręcznym jest ustawiony inaczej niż w Harmonogramie. W rezultacie nie znaleziony zostaje nie tylko zmapowany dysk, lecz również plik konfiguracyjny, biblioteka lub katalog wynikowy.

Inny scenariusz występuje przy użyciu innego konta. Mapowanie utworzone dla jednego użytkownika nie musi pojawić się dla drugiego. Dotyczy to także kont lokalnych i kont powiązanych z organizacją. Dostęp do folderu może być przyznany na poziomie udziału, systemu plików albo obu tych warstw jednocześnie. Sama widoczność litery nie potwierdza więc, że zadanie ma prawo wykonać operację na danych.

Warto zwrócić uwagę na zależności zapisane w akcji zadania. Jeżeli wykonywany jest plik wsadowy, należy sprawdzić wszystkie ścieżki wewnątrz tego pliku, a nie tylko pole programu w Harmonogramie. Gdy używany jest skrypt PowerShell, znaczenie mogą mieć bieżący katalog, profil, sposób uruchomienia oraz jawnie ustawione poświadczenia. Przy aplikacjach graficznych dodatkowym czynnikiem może być brak aktywnej sesji pulpitu.

Jak sprawdzić Zadania Harmonogramu i przywrócić dostęp

Najpierw powinno się ustalić, z jakiego konta i w jakim trybie działa zadanie. Należy odczytać ustawienia zabezpieczeń, opcję uruchamiania bez zalogowania, poziom uprawnień oraz warunki wyzwalacza. Następnie warto uruchomić dokładnie tę samą komendę ręcznie w kontekście konta przypisanego do zadania. Test powinien obejmować odczyt pliku, utworzenie pliku tymczasowego i zapis wyniku w docelowym katalogu.

W skrypcie zaleca się zastąpić literę mapowanego dysku pełną ścieżką UNC. Jeżeli program wymaga litery, mapowanie można wykonać w ramach samego skryptu, przed uruchomieniem właściwej aplikacji, a po zakończeniu usunąć. Takie rozwiązanie powinno być używane świadomie, ponieważ wymaga poprawnej obsługi połączenia, uwierzytelnienia i błędów. Dane uwierzytelniające nie powinny być wpisywane wprost do pliku tekstowego ani przechowywane w miejscu dostępnym dla przypadkowych użytkowników.

Dobrym uzupełnieniem jest zapis diagnostyczny. Skrypt może rejestrować nazwę konta, bieżący katalog, wynik sprawdzenia ścieżki, datę wykonania i komunikat błędu. Dzięki temu można odróżnić brak mapowania od chwilowej niedostępności zasobu. Należy jednak unikać zapisywania haseł, tokenów i pełnych sekretów w dzienniku.

Jeżeli zasób jest dostępny dopiero po uruchomieniu sieci, można dodać opóźnienie albo ustawić warunek zależny od dostępności połączenia. Pomocne bywa również ponawianie próby po krótkim czasie, o ile aplikacja i charakter danych pozwalają na takie działanie. W przypadku plików używanych jednocześnie przez kilka procesów należy sprawdzić blokady, konflikty zapisu i ryzyko częściowego wykonania operacji.

Po zmianach należy przetestować wszystkie warianty, które mają znaczenie w rzeczywistym użyciu: ręczne uruchomienie, uruchomienie z poziomu Harmonogramu, działanie po ponownym uruchomieniu komputera oraz pracę bez aktywnego logowania. Samo pojawienie się zielonego statusu zadania nie zawsze potwierdza poprawne przetworzenie plików, dlatego warto zweryfikować także rezultat końcowy.

Kiedy zgłosić problem z „Zadania Harmonogramu nie widzą zmapowanych dysków”

Do serwisu warto zgłosić się wtedy, gdy po zmianie ścieżek i sprawdzeniu konta zadanie nadal nie ma dostępu do zasobu, błędy występują nieregularnie albo problem pojawił się po aktualizacji systemu, zmianie haseł lub przebudowie sieci. Szczególnej uwagi wymaga sytuacja, w której zadanie zapisuje, usuwa lub przenosi ważne pliki, ponieważ błędna konfiguracja może prowadzić do pomijania danych, powstawania niepełnych kopii albo wielokrotnego przetwarzania tych samych dokumentów.

Przed zgłoszeniem pomocne jest przygotowanie nazwy zadania, używanego konta, dokładnej ścieżki, informacji o tym, czy jest to udział sieciowy, oraz komunikatu z historii uruchomień. Nie powinno się przesyłać haseł ani poufnych plików. W Warszawie takie przypadki obsługuje Warszawskie Pogotowie Komputerowe 24/7; naprawy z reguły realizowane są do 3 dni roboczych. Podczas analizy można sprawdzić konfigurację Harmonogramu, dostęp do udziału, ustawienia skryptu i logi, a następnie przygotować rozwiązanie dopasowane do sposobu pracy komputera.