Gdy Shutdown Event Tracker pojawia się po każdym restarcie…


 

Niedawno podsunąłem Wam sposób na zablokowanie „irytującego” narzędzia Shutdown Event Tracker, ale wspomniałem też, że jego funkcjonalność tak naprawdę ma sens i powinniśmy go blokować tylko po dobrym przemyśleniu np. na serwerach testowych. W tym artykule omówimy sytuację w której S.E.T. działa i po każdym restarcie pyta nas o przyczynę tego zdarzenia, a przecież system był restartowany „na czysto”.

Przypomnijmy: S.E.T. pozwala gromadzić w Dzienniku Zdarzeń nasze komentarze dotyczące wyłączenia lub restartu, a jeśli to zdarzenie było nagłe (na przykład po utracie zasilania), komentarz ten musimy wpisać zaraz po uruchomieniu systemu. Komentarze przechowywane są w Dzienniku Zdarzeń.

Jeśli według nas restart był poprawny (na przykład wykonany przez przez „shutdown -r” albo z menu START), to istnieje prawdopodobieństwo, iż któraś z usług nie zdążyła się wyłączyć i system nie uznał nam „czystego” wyłączenia.

Jak to działa?

W Systemach Windows występują tzw. pliki „heartbeat”. Są to 2 pliki: LastAlive0.dat oraz LastAlive1.dat w katalogu

%systemroot%\ServiceProfiles\LocalService\AppData\Local.

W nich co pewien czas zapisywane są czasy aktywności serwisów. Proces, który zapisuje dane do plików to svchost. System używa tych plików na przemian, a robi to, choćby po to, by wiedzieć kiedy maszyna ma wejść w stan uśpienia, albo wyłączyć dysk. Z tych samych plików korzysta Shutdown Event Tracker przy determinowaniu, czy restart był „czysty” ( przy każdym wyłączeniu systemu pliki są kasowane. Jeśli wyłączenie było nagłe (na przykład straciliśmy zasilanie), to S.E.T przy następnym starcie znajdzie je, odczyta wartość „LASTALIVESTAMP” i oznaczy restart jako nagły i niepoprawny, co oczywiście zmusi nas do wpisania przyczyny tego zdarzenia).

 

„Uparte” usługi

I tu właśnie może tkwić problem. Niektóre usługi mogą niepoprawnie zwalniać wspomniane pliki „heartbeat”. Aby to potwierdzić, powinniście wykonać u siebie mały test:

Przed restartem zatrzymajcie nie-windowsowe usługi. Na przykład:

net stop <nazwa_usługi>

Nie musi to być działanie „na ślepo”. Prawdopodobnie problem pojawił się po jakiejś zmianie na serwerze np. instalacji nowego oprogramowania.

Jeśli po restarcie S.E.T nie pyta o przyczynę, to znacie już źródło problemu. A jak rozwiązać to na dobre? Oto 4 moje propozycje:

Po pierwsze, producent oprogramowania może mieć dla Was rozwiązanie w postaci łatki lub nowszej wersji oprogramowania.

Po drugie, możecie sprawić, aby system nie sprawdzał plików „heartbeat” przy starcie. Podaję to jako opcję, ale nie popieram tego rozwiązania:) Należy w rejestrze odnaleźć klucz

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability

 ..i ustawić TimeStampInterval na „0”. Od tej pory zapisywane będą tylko wartości czasowe dla startu i wyłączenia systemu.

Po czwarte, teoretycznie możecie „zatuszować” problem wyłączając Shutdown Event Tracker, o czym pisałem nie dawno. Ale nie jestem fanem tego rozwiązania :)

Na koniec podam Wam najsensowniejszy pomysł:

 

Shutdown Script w GPO i wyłączanie usług

Dzięki LGP lub GPO możemy zastosować skrypt działający przy każdym wyłączeniu systemu (oczywiście również restartu). W skrypcie możemy umieścić wspomniane wyłączanie „upartej” usługi przez net stop.

Do edycji GPO użyjemy przystawki Group Policy Magement, zaś do edycji LGP użyjemy przystawki Local Group Policy Editor uruchamianej prostym poleceniem:

gpedit.msc

Wybieramy kolejno:

Computer Configuration  >   Windows Settings  >  Scripts (Startup/Shutdown) >  Shutdown

 

Następnie klikając w przycisk „add” tworzymy nowy skrypt. Podajemy ścieżkę do niego (na udziale Netlogon na kontrolerze domeny), albo korzystamy z przycisku „Browse”.

Jeśli użyliśmy GPO, pamiętajmy, aby była ona podlinkowana do kontenera (OU), w którym znajduje się konto naszej maszyny.

Mam nadzieję, że opisane porady, szczególnie ta ostatnia okazały się skuteczne:) Jeśli macie jakieś komentarze, piszcie śmiało.


Podobne Tematy: