Task Scheduler uruchamia PowerShell bez efektu

Task Scheduler uruchamiający PowerShell bez efektu wskazuje na politykę Execution Policy blokującą wykonanie skryptu w kontekście zaplanowanego zadania.

Czym jest sytuacja, w której Task Scheduler uruchamia PowerShell bez efektu

Komunikat, że Harmonogram zadań uruchamia PowerShell, lecz nie powoduje widocznego działania, oznacza zwykle różnicę między ręcznym uruchomieniem skryptu a jego wykonaniem w tle. Zadanie może zostać oznaczone jako uruchomione, a mimo to skrypt nie wykonać poleceń, zakończyć się przedwcześnie albo działać w innym środowisku niż to, które jest dostępne po otwarciu konsoli przez użytkownika. Sam brak okna PowerShell nie musi oznaczać awarii, ponieważ zadanie może być skonfigurowane jako niewidoczne. Jeżeli jednak nie powstaje oczekiwany plik, nie zostaje wykonana kopia, nie uruchamia się program lub nie zmienia się wskazana konfiguracja, należy przeanalizować warunki wykonania.

Istotne znaczenie ma kontekst konta, w którym działa zadanie, oraz sposób przekazania polecenia. PowerShell uruchomiony ręcznie korzysta z profilu użytkownika, jego zmiennych środowiskowych, mapowanych dysków i uprawnień. Task Scheduler może natomiast działać bez profilu, z innym katalogiem roboczym i z ograniczonym dostępem do zasobów. Dodatkową przyczyną bywa polityka wykonywania skryptów, która pozwala otworzyć konsolę, ale blokuje uruchomienie pliku z rozszerzeniem .ps1.

Kontekst techniczny i porównanie uruchomienia ręcznego z zadaniem zaplanowanym

Przy uruchomieniu ręcznym często wpisywana jest pełna komenda w konsoli znajdującej się już w odpowiednim katalogu. W zadaniu zaplanowanym należy rozdzielić program, argumenty oraz katalog rozpoczęcia pracy. Jako program powinien zostać wskazany właściwy plik wykonywalny PowerShell, natomiast ścieżka do skryptu powinna zostać przekazana w polu argumentów. Przydatne bywa użycie pełnych ścieżek do pliku skryptu, programów pomocniczych, katalogów zapisu oraz plików wejściowych. Odwołanie względne, takie jak .\dane.txt, może wskazywać inne miejsce niż oczekiwane, ponieważ zadanie nie zawsze rozpoczyna pracę w folderze zawierającym skrypt.

W ustawieniach zadania należy sprawdzić, czy wybrano właściwe konto, czy zaznaczono uruchamianie niezależnie od zalogowania oraz czy opcja podwyższonych uprawnień jest potrzebna do realizacji poleceń. Nie powinno się jednak nadawać szerszych uprawnień bez uzasadnienia. Warto również porównać wersję używanego środowiska PowerShell z tą, w której skrypt działał poprawnie ręcznie. Na części systemów dostępne są różne interpretery, a skrypt może odwoływać się do modułów lub składni obsługiwanych tylko przez jeden z nich.

Execution Policy należy traktować jako jeden z elementów diagnostyki, a nie jako jedyne możliwe wyjaśnienie. Polityka może różnić się dla zakresu bieżącego procesu, użytkownika i całego komputera. Z tego powodu sprawdzenie ustawień w konsoli uruchomionej ręcznie nie zawsze odzwierciedla warunki zadania. Bezpieczniej jest ustalić, jaki zakres blokuje skrypt, sprawdzić podpis lub źródło pliku i dobrać ograniczone rozwiązanie zamiast trwale obniżać zabezpieczenia systemu.

Typowe problemy i błędy powodujące brak efektu - Task Scheduler uruchamia PowerShell bez efektu

Jednym z częstych błędów jest wskazanie PowerShell jako programu, ale pominięcie parametrów wymaganych do uruchomienia konkretnego skryptu. Innym jest umieszczenie całej komendy w niewłaściwym polu albo brak cudzysłowów przy ścieżce zawierającej spacje. Problemy mogą powodować także:

• odwołania do dysków sieciowych mapowanych wyłącznie w sesji użytkownika;
• brak praw zapisu w katalogu docelowym;
• niedostępne zmienne środowiskowe lub profile użytkownika;
• zatrzymanie skryptu na pytaniu wymagającym odpowiedzi;
• błąd modułu, zależności albo niezgodność wersji PowerShell;
• blokada pliku pobranego z internetu;
• uruchamianie zadania z warunkiem dotyczącym zasilania, sieci lub bezczynności;
• ustawienie wyzwalacza w taki sposób, że zadanie uruchamia się później albo tylko po spełnieniu dodatkowego warunku.

Brak komunikatu na ekranie nie oznacza, że nie wystąpił błąd. Jeżeli skrypt jest uruchamiany bez interfejsu, komunikat może zostać zamknięty razem z procesem. Pomocne jest kierowanie komunikatów i wyników do kontrolowanego pliku logu, rejestrowanie początku oraz końca działania, a także zwracanie kodu zakończenia. Należy przy tym zadbać, aby log nie zawierał haseł, tokenów ani innych danych uwierzytelniających.

W Podglądzie zdarzeń oraz w historii zadania można sprawdzić, czy wystąpiła próba uruchomienia, jaki kod zakończenia został zwrócony i czy system zarejestrował błąd warunków wykonania. Warto wykonać test z prostym, nieszkodliwym poleceniem zapisującym znacznik czasu do pliku. Jeżeli taki test działa, problem leży najpewniej w samym skrypcie, jego uprawnieniach, ścieżkach lub zależnościach. Jeżeli nie działa, należy wrócić do konfiguracji programu, argumentów, konta i wyzwalacza.

Kiedy najlepiej umówić wizytę serwisową - Task Scheduler uruchamia PowerShell bez efektu

Zgłoszenie do serwisu jest uzasadnione, gdy zadanie działa niestabilnie, błędy pojawiają się dopiero po wylogowaniu, skrypt wymaga dostępu do zasobów sieciowych albo ręczne próby zmiany polityk i uprawnień nie przynoszą rezultatu. Szczególnej ostrożności wymaga sytuacja, w której PowerShell ma modyfikować konfigurację systemu, pliki użytkowników lub ustawienia zabezpieczeń. Przed zmianami powinno się zachować kopię skryptu, jego bieżącą konfigurację oraz informacje z historii zadania, aby możliwe było odtworzenie przyczyny problemu.

W Warszawie analizę takiej usterki można zlecić serwisowi działającemu pod nazwą Serwis laptopów i komputerów PC - Warszawa, gdzie weryfikacja może objąć konfigurację Harmonogramu zadań, ścieżki PowerShell, konto wykonujące, logi oraz zależności skryptu. Naprawy są z reguły realizowane w czasie do trzech dni roboczych, zależnie od zakresu diagnostyki i stanu komputera. Po zakończeniu sprawdzenia warto potwierdzić działanie zadania w kilku warunkach: po restarcie, po wylogowaniu, bez otwartej konsoli oraz przy braku aktywnej sesji użytkownika. Dzięki temu można odróżnić jednorazowe ręczne powodzenie od poprawnie skonfigurowanej automatyzacji.