Uruchamianie zadania po połączeniu z VPN: zdarzenie, odpytywanie czy dane logowania?

Skrypt logowania, który mapuje dysk lub uruchamia zadanie synchronizacji, działa, zanim tunel otrzyma adres, więc po cichu zawodzi, a użytkownik co rano naprawia go ręcznie. Windows nie oferuje większości klientów wywołania zwrotnego przy połączeniu dla każdego VPN, ale rejestruje zmianę sieci, a ten zapis może uruchomić pracę w odpowiednim momencie. Wybór jest między reakcją na ten zapis, odpytywaniem zasobu i usunięciem monitu, który uwidocznił błąd.

Porównywanie trzech mechanizmów według tego, co gwarantują, jest lepsze niż szeregowanie ich według elegancji. Każdy zawodzi inaczej, a sposób awarii jest tym, z czym potem żyjesz.

Dlaczego logowanie startuje zbyt wcześnie

Logowanie i uruchamianie odbywają się, zanim adapter VPN otrzyma swój adres, więc mapowanie dysku, wewnętrzny URL lub połączenie z bazą danych próbowane w tym momencie nie mają ani trasy, ani resolvera. Żądanie zawodzi, a sesja pozostaje w stanie, który użytkownik musi naprawić ręcznie. Przeniesienie tego samego skryptu do folderu autostartu nic nie zmienia, bo problem kolejności wędruje razem z nim. Wyzwalaczem musi być zmiana sieci, a nie zdarzenie sesji.

Zaplanowane zadanie przy logowaniu z dowolnym opóźnieniem wygląda jak poprawka, a w rzeczywistości jest zgadywaniem. Działa na szybkim łączu i zawodzi na wolnym, co jest najmniej użytecznym rodzajem niezawodności.

Trzy haki w porównaniu

Mechanizmy różnią się tym, co obserwują, jak szybko reagują i co robią przy ponownym połączeniu później w ciągu dnia. Tabela porównuje je pod tymi trzema względami, a nie pod tym, jak mądrze każdy brzmi.

Czytaj tabelę wiersz po wierszu. Hak zdarzenia jest najszybszy i najbardziej hałaśliwy, ponieważ Windows rejestruje każdą sieć, w tym Wi-Fi w kawiarni, więc akcja musi zweryfikować zasób, zanim cokolwiek zrobi. Odpytywanie jest wolniejsze i dokładniejsze, bo udaje się dokładnie wtedy, gdy odpowiada udział lub nazwa hosta, i nie musi wiedzieć, który klient jest zainstalowany. Zapisane dane logowania wcale nie są konkurencyjną opcją: usuwają monit o hasło, co jest drugim i niezależnym powodem, dla którego mapowanie przy logowaniu zawodzi.

Wybór między pierwszymi dwoma zależy od tego, czy na kliencie istnieje użyteczne zdarzenie. Tam, gdzie istnieje, zdarzenie plus sprawdzenie zasobu jest lepszym ustawieniem domyślnym.

Zbuduj wyzwalacz zdarzenia poprawnie

Zapis znajduje się w dzienniku Microsoft-Windows-NetworkProfile/Operational, a ID 10001 oznacza sieć, która właśnie się połączyła. Utwórz zadanie z wyzwalaczem Przy zdarzeniu skierowanym na ten dziennik, tę nazwę dostawcy i ten identyfikator. Każda sieć, do której dołączy maszyna, go uruchomi, więc akcja potrzebuje klauzuli strażniczej, a nie założenia, i powinna działać tylko wtedy, gdy użytkownik jest zalogowany, jeśli praca dotyczy zmapowanych dysków.

Klauzula strażnicza powinna sprawdzać to, czego zadanie naprawdę potrzebuje, na przykład ścieżkę udziału lub port usługi, i po cichu kończyć, gdy jest to nieosiągalne. Sprawdzanie nazwy adaptera nie wystarcza, ponieważ klient może ponownie użyć jednego adaptera w kilku profilach. Ciche zakończenie utrzymuje czytelność dziennika i zapobiega burzy ponownych prób wobec sieci, która nigdy nie obsłuży zasobu.

Sprawdź, czy zadanie uruchamia się w odpowiednim momencie

Udowodnij moment, a nie konfigurację. Poniższe polecenia pokazują definicję zadania, ostatnie zdarzenia profilu sieciowego i to, czy zasób jest osiągalny z konta, pod którym działa zadanie. Uruchom je po prawdziwym ponownym połączeniu, a nie po ręcznym starcie.

schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami

Wpis w historii zadań, który istnieje, gdy nie pasuje żadne zdarzenie sieciowe, oznacza, że błędny jest wyzwalacz, a nie akcja. Jeśli zdarzenia się pojawiają, a zadanie nie uruchamia się, zadanie może działać pod kontem, które nie widzi zasobu, a dane wyjściowe konta są wskazówką. Sprawdzenie zasobu, które przechodzi, gdy mapowanie wciąż brakuje, wskazuje na kontekst sesji, a nie na łączność. Każda z tych trzech obserwacji prowadzi do innej poprawki.

Zapisuj jedną linię dziennika na każde uruchomienie z adresem, wynikiem zasobu i rezultatem. Następna awaria pokaże wtedy, czy zadanie uruchomiło się wcześnie, uruchomiło się w złej sieci, czy nie uruchomiło się wcale.