Użytkownik loguje się w domu, łączy z VPN i czeka na mapowanie dysku, które w biurze pojawiało się samo. Tunel się podnosi, domena odpowiada, a nic się nie mapuje. Nic nie jest zepsute: skrypt logowania działa przy logowaniu, a tunel otwarty dwadzieścia minut po rozpoczęciu sesji nie jest logowaniem. Czytanie obu jako tego samego zdarzenia wysyła ludzi na poszukiwanie awarii VPN, której nie ma.

Cztery decyzje zamieniają niespodziankę w przepływ pracy, który zachowuje się poprawnie, a pierwsza to po prostu wiedza, na jakich zdarzeniach opiera się skrypt.

Skrypty opierają się na zdarzeniach cyklu życia, których nie można odtworzyć

Zasady po stronie komputera są stosowane przy starcie maszyny, a zasady po stronie użytkownika przy logowaniu, podczas gdy odświeżanie w tle przechodzi te same ustawienia bez ponownego uruchamiania czegokolwiek. To odświeżanie przetwarza rozszerzenie skryptów, ale nie uruchamia ponownie poszczególnych skryptów, które wyzwalają się tylko przy starcie, zamknięciu, logowaniu lub wylogowaniu. Dlatego gpupdate /force może zgłosić sukces, choć mapowania wciąż brakuje, a czyste odświeżenie nie jest dowodem, że skrypt coś zrobił.

Dokumentacja Microsoftu dotycząca przetwarzania zasad wyznacza dokładnie tę granicę między przetwarzaniem rozszerzenia a uruchamianiem jego zawartości, i to jest strona, na którą się powołuje, gdy ktoś upiera się, że odświeżenie powinno było odtworzyć skrypt.

Nie każdy skrypt zawodzi też bez sieci. Ten, który czyta tylko lokalne lub buforowane materiały, mógł częściowo się udać, podczas gdy ten, który sięga do udziału, zawodzi cicho i nie zostawia wyraźnego śladu. Sprawdź rzeczywistą ścieżkę skryptu i to, do czego dociera, zanim obwinisz sieć. Ta sama kontrola należy się każdemu twierdzeniu, że skrypt nie działa przy logowaniu, bo zaplanowane zadanie lub akcja klienta może wykonywać pracę tam, gdzie nikt nie patrzy.

Przypnij pracę do połączenia, nie do logowania

Za określeniem skrypt logowania kryją się trzy różne zadania: mapowanie dysku po połączeniu użytkownika, stosowanie konfiguracji maszyny przed czyimkolwiek logowaniem i pobieranie zaktualizowanych zasad. Mają różne terminy, a tylko drugie naprawdę potrzebuje łączności przed logowaniem. Zapisz wymaganie jako zdanie z terminem, na przykład: to mapowanie musi istnieć w ciągu minuty od podniesienia tunelu.

Do pracy, która musi nastąpić po połączeniu, użyj zadania wyzwalanego połączeniem lub akcji połączenia obsługiwanej przez klienta. Sprawdź, które zdarzenie klient faktycznie emituje, bo zdarzenie podnoszone przez natywnego klienta VPN systemu Windows nie jest podnoszone przez klienta innej firmy. Dla konfiguracji maszyny, która musi poprzedzać logowanie, obsługiwaną odpowiedzią jest tunel urządzenia lub inny projekt przed logowaniem, a nie zadanie wyzwalane pojawieniem się pulpitu. Wykonuj pracę w tożsamości i sesji, które jej potrzebują, ponieważ mapowanie utworzone jako SYSTEM trafia do sesji, której użytkownik nigdy nie widzi.

Sprawdź gotowość przed działaniem i zawiedź głośno

Zdarzenie połączenia może nadejść, zanim DNS lub serwer plików będą użyteczne, więc zadanie powinno sprawdzać, czego potrzebuje, zamiast zakładać. Rozwiąż konkretną nazwę, spróbuj konkretnego połączenia i ponów z ograniczeniem i opóźnieniem: Resolve-DnsName files.corp.example w krótkiej pętli oddziela jeszcze-nie od nigdy. Po ostatniej próbie zgłoś konkretny błąd, z nazwą i błędem w środku.

Nieskończona pętla bez logu jest nieodróżnialna od zadania, które nigdy się nie zaczęło, i ukrywa różnicę między nieaktualnym poświadczeniem a regułą zapory.

Zweryfikuj cztery rzeczy, a potem uczyń to powtarzalnym

Podczas pilotażu zapisuj cztery obserwacje zamiast jednej: zdarzenie połączenia wystąpiło, zadanie się rozpoczęło, zasób odpowiedział, a żądana zmiana faktycznie się zastosowała. Jeśli log zatrzymuje się na zadanie rozpoczęte, prawdziwa awaria pozostaje niewidoczna, ile byś nie czekał. Następnie uruchom gpresult /scope user /v, aby zobaczyć, jakie zasady sesja uważa za swoje, i porównaj to z oczekiwanym ustawieniem. Raport wymieniający GPO jako zastosowane nadal nic nie mówi o mapowaniu.

Uczyń pracę bezpieczną do powtórzenia, zanim ją rozszerzysz, bo klient łączy się ponownie i zadanie znów się wyzwala. Przed utworzeniem sprawdź, czy mapowanie lub konfiguracja już istnieje, i zanotuj, co znalazłeś. Powielona praca po każdym chwilowym ponownym połączeniu to droga, na której pomocne zadanie staje się incydentem.

Tam, gdzie automatyczny wyzwalacz nie jest odpowiedni, zatwierdzona akcja użytkownika uruchamiająca ten sam podpisany skrypt jest uzasadnionym rozwiązaniem. Czyni ona moment jawnym zamiast udawać, że wystąpiło zdarzenie logowania.

Powiązane artykuły