vermin.eu.org

NOD32 to najlepszy znany mi software AV. Do Symanteca się zraziłem wersją dla osób prywatnych świeższą niż 2001, Kaspersky zabijał wolne komputery poprzez tworzenie skrótów plików, MKS niestety przestał się jakoś w którymś momencie rozwijać, (chociaż czuję do niego ogromny sentyment i przy jego polityce licencjonowania uważam za najlepszy wybór dla pracowni szkolnych), a teraz wyewoluował w ArcaVira, którego nie testowałem w sumie. NOD zresztą sprawdził się - jego technologia ThreatSense (znaczy się ładnie nazwana heurystyka) i bardzo duża częstotliwość aktualizacji już parę razy ochroniły mi cztery litery w momencie, kiedy inne programy AV jeszcze nie wiedziały, że coś się dzieje. Ogólnie jak mogę coś klientowi polecić to wybieram zawsze NODa.

Problemik się pojawił ostatnio, ponieważ po instalacji SBSa, klient chciał rozrzucić NODa pod domenie. Instalacja NODa nie jest szczególnie skomplikowana (next, next, next…), ale w domenie już można się trochę pobawić - chociażby skonfigurowanie kopii dystrybucyjnej na serwerze, zabezpieczeniem konfiguracji hasłem i takie tam. NOD domyślnie ma takie cudo jak Remote Administrator, ale klientowi to nie było potrzebne. Praca instalatora software byłaby dla niego tańsza (-:

SBS jak wiadomo ma wspaniałą zaletę a’la SMS, pozwalającą na publikowanie paczek oprogramowania dla stacji klienckich. W zasadzie używa się dwóch metod - pierwsza z nich to wrzucenie paczki z oprogramowaniem do katalogu ClientApps i dodanie w konsoli Zarządzanie Serwerem nowej paczki wraz z przypisaniem jej do konta komputera. Po zalogowaniu się użytkownika na tej maszynie na jego pulpicie pojawi się skrót do dodanej instalacji, którą użytkownik MOŻE sobie zainstalować. Oczywiście dla oprogramowanai typu AV słowo może jest złym słowem, które powinno zamienić się na słówko MUSI. Na to na szczęście jest metoda - GPO. W zasadach grupy można przypisać aplikację do konta komputera i voila - zainstaluje się sama.

Czym się różnią te dwie metody instalacji? Pierwsza z nich wymaga (moze wymagać) interakcji z użytkownikiem. Ponadto pozwala użytkownikowi na niezainstalowanie oprogramowania no i odbywa się PO zalogowaniu użytkownika na stacji. Druga jest metodą nieiterakcyjną (co oznacza dla większości softu stworzenie plików transformacji (MST) albo innego cuda), która wykona się podczas wyświetlania ekranu logowania i jest wymuszona zasadami GPO. Jak widać - co kto lubi lub co mu jest potrzebne.

Wróćmy jednak do naszego zadania, czyli instalacji NODa. Wiemy juz, że powinno się dodać paczkę tak, aby zainstalowała się sama, bez ingerencji, a najlepiej tak, żeby użyszkodnik nie mógł nic zmienić w konfiguracji. Z pomocą przychodzi narzędzie configuration editor, (jest dostępne po wykonaniu instalacji administracyjnej, czyli z lokalnym mirrorem), które generuje plik w formacie XML opisujący wszystkie parametry konfigurujące oprogramowania - sposóby aktualizacji, metody postępowania z plikiem, adresy pod którymi znajdują się aktualizacje, hasła (oczywiście zakodowane), blokady profili i same profile, etc. Sam plik niestety to niezawiele - jak to uruchomić? Otóż trzeba, (i tak by było trzeba), ściągnąć ze strony NOD aktualną wersję oprogramowania, rozpakować ja (RAR) i dodać plik config.xml wygenerowany w edytorze konfiguracji. Teraz pakujemy to ładnie ponownie do SFXa, ale dodajemy mu miła komendę -

albo publikujemy tą właśnie komendę do wykonania z określonej lokacji. Ważne jest, żeby pamiętać o opcji reboot, ponieważ inaczej nie uruchomi się jądro systemu NOD i de facto nie będzie działać ochrona ciągła, a jedynie na żądanie (do rebootu). Przy deinstalacji, jeśłi byłaby wymagana, używa się parametrów uninstall oraz pwd=hasło. Dzięki temu, po poprawnym skonfigurowaniu raportowania przez klienckie stacje NOD możemy dzięki SBS czuć się (prawie) tak, jakbyśmy posiadali RemoteAdministratora (-: