Narzędzia systemowe – cz. I
Dziennik zdarzeń i logi systemowe
Niniejszy tekst jest pierwszym z serii artykułów na temat narzędzi systemowych występujących w systemach Windows. Dzisiejszy artykuł prezentuje wbudowane narzędzia systemowe, dzięki którym praca z dziennikiem zdarzeń staje się łatwiejsza. Któż z nas, w codziennej pracy, nie korzysta z logów systemowych w celu wyszukiwania błędów, prób łamania haseł i tym podobnych zdarzeń. Dzisiaj skupię się na trzech programach: „Eventquery”, „Eventtriggers” oraz „Eventcreate”. Dodatkowo na końcu opisany będzie program „Msg”, który w połączeniu z „Eventtriggers” w znaczny sposób przyspieszy naszą reakcję na błędy.
Zawartość strony
Eventquery - Przeglądanie zdarzeń systemowych
Najczęściej administratorzy chcący przejrzeć zawartość dziennika zdarzeń posługują się narzędziem „Event Viewer” lub „Computer Management”. Oba programy umożliwiają przeglądanie zdarzeń nie tylko z lokalnego komputera, ale również ze zdalnego komputera, poprzez podpięcie się do niego. Odpowiednikiem narzędzia „Event Viewer” jest „Eventquery.vbs”. Skrypt ten napisany jest w języku Visual Basic Script i jest on dostępny począwszy od systemu Windows XP. Dzięki niemu możemy przejrzeć zdarzenia systemowe i eksportować je do pliku w łatwy sposób. Uruchomienie „Eventquery” bez dodatkowego parametru zwróci wszystkie zdarzenia z logu aplikacyjnego do okna linii komend. Oczywiście stosując przekierowanie do pliku, mamy możliwość przeglądania danych w pliku tekstowym. Poniżej znajduje się przykład przekierowania komendy do pliku tekstowego.
UWAGA. Przed pierwszym uruchomieniem dobrze byłoby zdefiniować, który program ma domyślnie uruchamiać skrypty napisane w Visual Basic Script. Aby to uczynić powinniśmy wykonać poniższą operację:
Cscript //h:cscript /s
Dzięki temu nie będziemy musieli przed każdym wywołaniem „Eventquery” wpisywać polecenia „Cscript”. Oto przykład operacji przed wykonaniem polecenia „Cscript //h:cscript /s”:
Cscript c:\windows\system32\eventquery.vbs > c:\Zdarzenia.txt
Ten przykład pokazuje, jak bardzo zmienia się sposób otwierania skryptu po wykonaniu polecenia „Cscript //h:cscript /s”:
EventQuery > c:\Zdarzenia.txt
Zastosowane zostało tutaj przekierowanie wyników do pliku tekstowego przy użyciu pojedynczego znaku „>”. Można przekierować dane do pliku tekstowego przy pomocy dwóch znaków „>>”. Oto ten sposób:
EventQuery >> c:\Zdarzenia.txt
Czym różnią się te przekierowania od siebie? Jeśli plik istnieje, to pojedynczy znak („>”) nadpisze nam ten plik - w związku z powyższym zobaczymy w pliku rezultat ostatniej komendy. Jeśli użyjemy podwójnego znaku („>>”), to wynik polecenia zostanie dopisany do pliku na jego końcu. W przypadku, gdy plik nie istnieje oba przekierowania utworzą go. UWAGA: przekierowanie do pliku może być używane z każdą komendą działającą w trybie tekstowym.
Czasami plik wynikowy może być bardzo nieczytelny. Aby plik ten był sformatowany zgodnie z naszymi potrzebami, możemy posłużyć się parametrem „/FO”. Opcja ta przekształca wynik działania na typ wskazany przez nas. Mamy tutaj trzy możliwości. „Table”, „List” oraz „CSV”:
| • | EVENTQUERY /FO Table – wyświetlanie wartości w tabeli. Przy dużej ilość kolumn format ten staje się mało przejrzysty. |
| • | EVENTQUERY /FO List – wyświetlanie wartości jedna pod drugą, przez co plik jest bardziej czytelny. |
| • | EVENTQUERY /FO CSV – formatuje dane w postaci zgodnej z plikiem CSV. Dane są rozdzielone przecinkiem a nie średnikiem. |
Używając parametru „/FO” z opcją „Table” lub „CSV”, zobaczymy nagłówki z opisem dla każdej kolumny. Jeśli nie chcemy oglądać tych informacji można posłużyć się opcją „/NH”.
No dobrze, ale co w przypadku, gdy chcemy zobaczyć zdarzenia z logu „Security” a nie z logu „Aplikacyjnego”? Możemy uruchomić polecenie z parametrem „/L nazwa_logu”. Przykład taki znajduje się poniżej:
EventQuery /L „System” > c:\Zdarzenia.txt
Dostępne są następujące logi systemowe:
| • | Application |
| • | Directory Service |
| • | DNS Server |
| • | File Replication Service |
| • | Security |
| • | System |
Dodatkowo możemy stosować znaki specjalne, takie jak „*”. Na przykład - chcąc wyświetlić wszystkie zdarzenia ze wszystkich logów, możemy wykonać następujące polecenie:
EventQuery /L * > c:\Zdarzenia.txt
„EventQuery” bez dodatkowych parametrów pokazuje nam następujące wartości:
| • | Type – dla wszystkich logów, z wyjątkiem logu „Security”, mamy trzy typy: ERROR, INFORMATION oraz WARNING. W logu „Security” posiadamy dwa typy zdarzeń: SUCCESSAUDIT i FAILUREAUDIT. |
| • | Event – numer identyfikujący dane zdarzenie. |
| • | Date Time – data oraz godzina wystąpienia zdarzenia. Pole to posiada następujący format danych: rrrr-MM-dd gg:mm:ss, gdzie „r” oznacza rok, „M” miesiąc, „d” dzień, „g” godzinę, „m” minutę, a „s” sekundę. Oto przykład 2006-11-27 13:05:34. Uwaga: sposób wyświetlania danych dla tej wartości jest uzależniony od ustawień regionalnych. |
| • | Source – źródło zdarzenia. |
| • | ComputerName – nazwa komputera, z którego otrzymaliśmy wynik działania. |
Jeśli powyższe dane są dla nas niewystarczające, możemy poszerzyć wyświetlane informacje o dodatkowe wartości przy pomocy przełącznika „/V”. Parametr ten dodaje następujące kolumny:
| • | Category – zwraca nam informację o kategorii zdarzenia. Jest ona ściśle powiązana z polem „Source”. |
| • | User – jeśli zdarzenie zostało wywołane przez konkretnego użytkownika, to zostanie tutaj pokazany jego login. Jeśli operacja wywołująca zdarzenie była uruchomiona w kontekście kont systemowych, to zobaczymy tam takie wartości, jak „System” lub „N/A”. |
| • | Description – widzimy tutaj szczegółowe informacje na temat danego zdarzenia. |
No dobrze, ale co w przypadku, gdy chcemy zobaczyć dane od dnia 27-11-2006 i od godziny 01:10:00? Możemy posłużyć się parametrem „/FI”. Dzięki niemu jesteśmy w stanie filtrować zdarzenia zgodnie z naszymi potrzebami. Oto nasz przykład:
Eventquery /v /l * /fi „datetime gt 11/27/06,01:10:00AM” > c:\Zdarzenia.txt
Poniżej znajduje się tabelka z polami, po których możemy filtrować oraz opis warunków filtracji.
Warunki filtracji:
| • | Eq – Równy |
| • | Ne – Różny od |
| • | Gt – Większy od |
| • | Lt – Mniejszy od |
| • | Ge – Większy równy od |
| • | Le – Mniejszy równy od |
| Pole filtrowania | Warunek filtru | Wartość |
DATETIME | eq, ne, ge, le, gt, lt | Wartość filtra powinna mieć taki format: mm/dd/yy(yyyy), hh:mm:ssAM(PM). Możemy tutaj zastosować wartość filtracji „OdDaty-DoDaty”, ale działać to będzie tylko z warunkiem „eq” |
TYPE | eq, ne | ERROR, INFORMATION, WARNING, SUCCESSAUDIT, FAILUREAUDIT |
ID | eq, ne, ge, le, gt, lt | ID zdarzenia |
USER | eq, ne | Login użytkownika |
COMPUTER | eq, ne | Nazwa komputera |
SOURCE | eq, ne | Źródło danych |
CATEGORY | eq, ne | Kategoria zdarzenia |
Istnieje możliwość łączenia kilku warunków w jednym zapytaniu. Załóżmy, że chcielibyśmy otrzymać wszystkie zdarzenia o ID większym od 1000 i mniejszym od 2000:
Eventquery /V /L * /FI „id gt 1000” /fi „id lt 2000”
Poniższy przykład pokaże zdarzenia, które były uruchamiane w kontekście użytkownika „Administrator” z ID zdarzenia większym od 100:
Eventquery /v /l * /fi „id gt 100” /fi „user eq NazwaKomputera_NazwaDomeny\Administrator”
UWAGA! Proszę zwrócić uwagę na nazwę użytkownika. Nie można wpisać samego słowa Administrator. Użytkownik musi mieć nazwę poprzedzoną nazwą komputera (użytkownik lokalny) lub nazwą domeny (użytkownik domenowy).
Teraz ćwiczonko dla Państwa. Czy według Państwa będzie jakaś różnica w wynikach poniższych poleceń? Pokażą te same informacje? Czy może będą zawierały inne dane?
Eventquery /v /l * /fi “id eq 1000 or id eq 1001” Eventquery /v /l * /fi “id eq 1000” /fi “id eq 1001”
Odpowiedź brzmi: Wyniki będą inne. Dlaczego? Otóż w przypadku pierwszego polecenia zostało użyte słowo kluczowe „Or”, co oznacza, że zobaczymy zdarzenia o ID=1000 lub ID=1001 (czyli oba). W drugim przypadku można powiedzieć, że pomiędzy „/fi” znajduje się „wirtualne” słowo kluczowe „And”, a co za tym idzie, nie ma możliwości, aby jedno zdarzenie posiadało równocześnie ID 1000 i 1001.
Możemy również zobaczyć listę 10 zdarzeń posortowaną od najbardziej aktualnego. Aby to uczynić musimy posłużyć się parametrem „/R”. Oto przykład:
Eventquery /v /l * /r 10 > c:\Zdarzenia.txt
Poniższy przykład wyświetla 10 najstarszych zdarzeń:
Eventquery /v /l * /r -10” > c:\Zdarzenia.txt”
Parametr „/R” umożliwia pokazanie zdarzeń z zakresu od 10 zdarzenia do 15 zdarzenia:
Eventquery /v /l * /r 10-15 > c:\Zdarzenia.txt
Na samym początku wspomniałem, iż „EventQuery” jest podobny do narzędzia „Event Manager”. Napisałem również, iż „Event Manager” umożliwia pobieranie danych na temat zdarzeń z innych komputerów. Polecenie „Eventquery” również udostępnia nam taką funkcjonalność. W celu podpięcia się do innego komputera posługujemy się parametrem „/S Komputer”, gdzie komputer może być nazwą FQDN, NetBIOS lub adresem IP. Oto przykład uruchomienia „Eventquery” dla komputera o nazwie „test”:
Eventquery /l * /s test
Powyższe polecenie uda nam się tylko w przypadku, gdy aktualnie zalogowany użytkownik jest w grupie administratorów lokalnych na zdalnym komputerze. Jeśli nie jest, to trzeba będzie posłużyć się parametrem „/U [Domena\]Użytkownik”. Jeśli nie sprecyzujemy hasła dla tego użytkownika, to zostaniemy o nie poproszeni po uruchomieniu polecenia. Jeśli chcielibyśmy wykorzystywać polecenie „Eventquery” w skryptach, to będziemy musieli podać tam hasło. Możemy to uczynić przy pomocy opcji „/P HASŁO”.
Eventtriggers - Monitorowanie zdarzeń
No dobrze, ale co w przypadku, gdy posiadamy w firmie co najmniej kilkanaście serwerów i każdy z nich musimy monitorować na bieżąco pod względem prób włamania, problemów z usługami sieciowymi takimi jak DNS, DHCP, itp. Najlepszym rozwiązaniem jest zastosowanie takiego produktu, jak serwer MOM 2005. Zdając sobie sprawę z tego, iż nie każda firma posiada fundusze na taki produkt, firma Microsoft udostępniła narzędzie, dzięki któremu jesteśmy w stanie reagować na pojawiające się zdarzenia w czasie rzeczywistym. Takim narzędziem jest „Eventtriggers.exe”. Program ten umożliwia zdefiniowanie zdarzeń systemowych oraz reakcji na nie. Załóżmy, że chcielibyśmy być natychmiast powiadamiani o pojawieniu się informacji o próbie łamania hasła naszego użytkownika. W takiej sytuacji powinniśmy monitorować zdarzenia o numerze ID:
| • | 529 – wystąpiła próba logowania z nieznaną nazwą użytkownika lub ze złym hasłem. |
| • | 539 – ten ID informuje o próbie zalogowania się użytkownika na już zablokowanym koncie. |
| • | 642 i 642 – te zdarzenia występują po sobie i informują nas o przekroczeniu przez użytkownika licznika błędnych prób logowania. Oznaczają one zablokowanie (lockout) konta. |
Znając numery ID można byłoby już uruchomić monitorowanie tych zdarzeń i powiadamianie nas o ich wystąpieniu. W jaki sposób korzystać z polecenia „Eventtriggers”? Samo uruchomienie go bez żadnego parametru pokazuje nam aktualnie zdefiniowane reguły monitorowania. Po uruchomieniu „Eventtriggers /?” pojawi się informacja, iż aplikacja ta ma dostępne trzy przełączniki:
| • | „/Create” – umożliwia tworzenie nowych reguł monitorowania zdarzeń. |
| • | „/Delete” – kasuje istniejące reguły monitorowania zdarzeń. |
| • | „/Query” – pokazuje jakie reguły monitorowania są ustawione. |
Eventtriggers /Create - Tworzenie reguł monitorowania
Na początku naszym zadaniem jest ustawienie reguły monitorowania na nasze zdarzenia. Aby włączyć regułę monitorowania zdarzeń, trzeba będzie użyć co najmniej trzech przełączników. Pierwszym z nich jest zdefiniowanie nazwy reguły. Parametrem odpowiadającym za to jest przełącznik „/TR „Powiadomienie o zablokowaniu konta”. Drugim wymaganym argumentem jest ustawienie reakcji na wystąpienie konkretnego zdarzenia. W tym celu posłużymy się przełącznikiem „/TK „msg /w /server:192.168.1.100 * ‘Uwaga. Konto zostało zablokowane!’” ”. Trzeci wymagany argument możemy wybrać z trzech. Oto one:
| • | „/EID” – po numerze ID zdarzenia. |
| • | „/T” – po typie zdarzenia: “ERROR”, “INFORMATION”, “WARNING”, “SUCCESSAUDIT” lub “FAILUREAUDIT”. |
| • | „/SO” – po źródle zdarzenia. |
W naszym przypadku polecenie będzie wyglądało tak:
Eventtriggers /create /tr „Powiadomienie o zablokowaniu konta” /EID 642 /tk „msg /w /server:10.1.1.11 administrator ‘Uwaga. Konto zostało zablokowane!’”
Dodatkowo narzędzie „Eventtriggers” umożliwia dodanie opisu do reguły monitorowania. Odpowiedzialny jest za to parametr „/D”. Dzięki niemy możemy bardziej szczegółowo opisać działanie reguły.
Reguła monitorowania zdarzeń została utworzona i będzie działała póki jej nie usuniemy. Po wyłączeniu komputera i włączeniu go ponownie, reguła NIE znika. Proszę zwrócić uwagę na fakt, iż nie podałem konkretnego logu systemowego w składni. System monitoruje wszystkie logi w poszukiwaniu zdarzenia o numerze ID 642. Zostało tam jeszcze użyte polecenie „MSG”. Działanie tego polecenia zostanie opisane na końcu niniejszego artykułu. Gorąco polecam.
Kolejne zadanie. Jesteśmy bardzo czujnymi administratorami serwerów. Chcemy być powiadamiani o każdym zdarzeniu o typie „Error” w logu systemowym. Jak to zrobić? Oto nasze polecenie:
Eventtriggers /create /tr „Powiadomienie na każdy błąd” /L System /t error /tk „msg /w /server:10.1.1.11 administrator ‘Wystąpił błąd o typie error w logu systemowym’”
W powyższym przykładzie posłużyliśmy się dwoma nowymi przełącznikami. Pierwszym z nich jest „/L NazwaLogu”. Odpowiada on za zdefiniowanie logu systemowego, który to zamierzamy monitorować. Do dyspozycji mamy następujące logi systemowe:
| • | Application |
| • | Directory Service |
| • | DNS Server |
| • | File Replication Service |
| • | Security |
| • | System |
Drugim parametrem był „/T typ_zdarzenia”. Oto dostępne typy zdarzeń:
| • | ERROR – występuje we wszystkich logach z wyjątkiem logu Security |
| • | INFORMATION – występuje we wszystkich logach z wyjątkiem logu Security |
| • | WARNING – występuje we wszystkich logach z wyjątkiem logu Security |
| • | SUCCESSAUDIT – występuje tylko w logu Security |
| • | FAILUREAUDIT – występuje tylko w logu Security |
W powyższych przykładach wszystkie polecenia wykonywane są na użytkowniku, który je wygenerował. Istnieje możliwość uruchomienia zadania w kontekście innego użytkownika. Do tego celu służą parametry „/RU” i „/RP”. Parametr „/RU” umożliwia zdefiniowanie nazwy użytkownika. Jeśli wpiszemy pustą wartość („”), to aplikacja będzie uruchamiana w kontekście konta systemowego. Dzięki „/RP” możemy podać hasło użytkownika, na którym będzie uruchamiana aplikacja. Jeśli w parametrze „/RU” użyliśmy konta systemowego, to parametr „/RP” będzie ignorowany. Jeśli użyjemy tutaj znaku „*”, to przed każdym uruchomieniem będziemy poproszeni o podanie hasła użytkownika.
Eventtriggers /create /tr „Powiadomienie na każdy błąd” /L System /t error /ru „domena\uzytkownik” /rp „Hasło” /tk „msg /w /server:10.1.1.11 administrator ‘Wystąpił błąd o typie error’ w logu systemowym’”
No dobrze, ale co w przypadku, gdy nasza firma posiada co najmniej kilkanaście serwerów. Na szczęście przy pomocy „Eventtriggers” można łączyć się z innymi komputerami zdalnie, tworząc tam reguły monitorowania zdarzeń. Do tego celu będziemy potrzebowali przełącznika „/S NazwaKomputera_lub_IP”. Jeśli ten komputer nie jest w naszej domenie, to możemy posłużyć się dodatkowo przełącznikiem „/U Nazwa_admina_lokalnego” i parametrem „/P hasło”.
Eventtriggers /Query - Wyświetlenie reguł monitorowania
Dobrze było by raz na jakiś czas zobaczyć, jakie reguły posiadamy i co one monitorują. Tu przyda nam się polecenie „Eventtriggers /Query”. Samo polecenie pokaże podstawowe informacje, takie jak unikatowy numer identyfikujący ID wyzwalacza (Trigger ID), nazwa reguły (Trigger Name) oraz program, który będziemy uruchamiany (Task). Dodatkowo istnieje możliwość pokazania zaawansowanych właściwości. Umożliwia nam to przełącznik „/V”. Do powyższych kolumn wyświetlane są jeszcze takie informacje, jak nazwa komputera (Hostname), dokładna definicja reguły (Query), opis (Description) oraz konto użytkownika, na którym będzie uruchamiane zadanie (Run as User).
Do dyspozycji mamy jeszcze kilka przełączników, które zostały omówione szczegółowo już wcześniej. Są to:
| • | /FO – format eksportu danych. Do dyspozycji mamy: „TABLE”, „LIST”, „CSV”. |
| • | /NH – blokowanie wyświetlania nazw kolumn. |
| • | /S – sprawdza, jakie reguły wyzwalaczy ustawione są na zdalnych komputerach. |
| • | /U – działa w połączeniu z parametrem „/S”. Umożliwia pokazanie wyzwalaczy na innym komputerze, poprzez podłączenie się do niego w kontekście innego niż użytkownika. |
| • | /P – występuje w połączeniu z parametrem „/S” i „/U”. Ten parametr służy do podania hasła dla innego użytkownika. |
Eventtriggers /Delete - Kasowanie reguł monitorowania
Przed chwilą byliśmy w stanie zobaczyć, jakie reguły są ustawione na naszym komputerze, ale co w przypadku gdy po upływie kilku tygodni zdecydowaliśmy się na kupno serwera MOM 2005. Wszystkie nasze reguły monitorowania nie będą już nam potrzebne. Znając już ich numer identyfikacyjny (Trigger ID), możemy przystąpić do usuwania reguł. W tym celu uruchomimy polecenie:
Eventtriggers /Delete /TID 12
Powyższy przykład usunie regułę o numerze ID 12. W przypadku, gdy chcemy usunąć kilka reguł na raz (ale nie wszystkie), możemy posłużyć się taką składnią:
Eventtriggers /Delete /TID 12 /TID 10 /TID 8
Jeśli jednak skusiliśmy się na serwer MOM 2005 i chcemy usunąć wszystkie reguły, to możemy w tym celu uruchomić następujące polecenie:
Eventtriggers /Delete *
Dodatkowo mamy możliwość usuwania naszych reguł ze zdalnych komputerów, używając przy tym takich przełączników, jak „/S”, „/U” i „/P”.
Eventcreate - Testowanie naszych reguł
Trudno jest wyobrazić sobie sytuację, w której będziemy czekali na problem lub, co gorsze, będziemy próbowali go sami wywołać w celu sprawdzenia poprawności naszych reguł monitorowania. W tym celu posłużę się programem „Eventcreate”. Aby wygenerować nowy wpis do logów systemowych musimy zdefiniować co najmniej trzy wartości. Numer ID zdarzenia jest pierwszym parametrem. Wpisujemy go po przełączniku „/ID”. „Eventcreate” posiada tutaj pewne ograniczenie. Może on tworzyć ID w zakresie od 1 do 1000. Drugim parametrem jest typ zdarzenia, który wpisujemy przy pomocy „/T”. Ostatnim wymaganym parametrem jest „/D”, czyli opis zdarzenia. Tak więc najprostsze wygenerowanie nowego eventu wygląda następująco:
Eventcreate /ID 642 /T Error /D “To jest testowe zdarzenie”
Domyślnie informacja ta generowana jest w logu aplikacyjnym. Istnieje jednak możliwość tworzenia nowych zdarzeń w innych logach przy pomocy parametru „/L nazwa_logu”. Posiadamy również możliwość zdefiniowania źródła wiadomości dzięki przełącznikowi „/SO źródło”. Wydaje mi się, że nie zaskoczę nikogo, jeśli wspomnę jeszcze o trzech oczywistych przełącznikach „/S”, „/U” i „/P”, które wiadomo do czego służą. Oto przykład rozbudowanego polecenia:
Eventcreate /ID 642 /T Error /D “To jest testowe zdarzenie” /L Security /SO Security
MSG – Wysyłanie wiadomości tekstowych
Czy ktoś z Państwa pamięta jeszcze polecenie „Net send”? Narzędzie umożliwiało nam wysyłanie komunikatów do użytkowników lub komputerów. Narzędzie to wykorzystywało usługę „Posłaniec” (Messenger). Ze względów bezpieczeństwa usługa ta została wyłączona w systemach począwszy od Windows XP. Ze względu na ten fakt, polecenie „Net send” stało się kompletnie bezużyteczne. Nie każdy wie jednak, iż firma Microsoft nie pozostawiła nas na lodzie. W zamian zostało dodane narzędzie „Msg”. Działa bardzo podobnie do „Net send”, ale posiada pewne rozbudowane mechanizmy, ale o tym za chwilkę. Na początku skupmy się na banalnym zadaniu, czyli na wysłaniu komunikatu do użytkownika o loginie Marcin. Użytkownik pracuje na lokalnym komputerze. Nasze polecenie będzie wyglądało tak:
Msg „Marcin” „To jest wiadomość testowa”
Przy pomocy „Msg” możemy wysyłać komunikaty do sesji terminalowych (podając ich numer). Na przykład chcemy wysłać komunikat do użytkownika pracującego na sesji o numerze 2:
Msg 2 „To jest wiadomość do użytkownika pracującego w sesji terminalowej o nr 2”
Istnieje jeszcze możliwość wysyłania wiadomości po nazwie sesji:
Msg RDP-TCP#1 „To jest wiadomość wysłana do sesji terminalowej po jej nazwie”
Domyślnie wiadomość widoczna jest przez 60 sekund. Po upływie tego czasu wiadomość znika. Istnieje możliwość zdefiniowania czasu wyświetlania wiadomości. Wyobraźmy sobie sytuację, w której musimy wyłączyć serwer produkcyjny na 10 minut. Wysyłamy powiadomienie do użytkowników w tej sprawie, prosząc ich o nie wykonywanie żadnych zadań na danym serwerze w tym czasie. „Net send” pokazywał wiadomość dopóki jej ktoś nie zamknął. Wykorzystując parametr „/Time:il.sekund” można wysłać ten komunikat z ustawionym czasem wyświetlania komunikatu, np. przez 720 sekund (12 minut). Jeśli osoba przyjdzie po upływie tego czasu, to nie zobaczy komunikatu, bo on już zniknie. Oto przykład komendy:
Msg * /Time:720 „Proszę zamknąć aplikację, gdyż serwer będzie wyłączony na 10 minut.”
Wiadomość ta zostanie wysłana do wszystkich użytkowników pracujących w sesjach terminalowych i w sesji interaktywnej. Wiadomość zamknie się sama po upływie 720 sekund. Wszystkie wiadomości były wysyłane do lokalnego komputera. Niestety wiadomość nie doszłaby do osób, które mają otwarty u nas tylko zasób sieciowy.
Można jeszcze korzystać z pliku, w celu wysłania informacji do kilku użytkowników, numerów identyfikujących sesje terminalowe i do nazw sesji terminalowych. W tym celu tworzymy nowy plik. Załóżmy, że plik ten nazywać się będzie „Wysylka.txt” i znajduje się w katalogu „C:\”. Nasze polecenie będzie wyglądało następująco:
Msg @c:\wysylka.txt „To jest grupowe wysyłanie wiadomości.”
No dobrze, ale co w przypadku gdy chcemy wysłać komunikat do innego komputera? Tutaj z pomocą przychodzi nam parametr „/Server:Nazwa_lubIP”. Niestety nie możemy pobierać listy komputerów z pliku. Trzeba by stworzyć skrypcik w tym celu.
Msg /Server:192.168.1.10 * „Wiadomość do komputera o adresie IP 192.168.1.10.”
UWAGA! Jeśli podczas wysyłania powyższej wiadomości żaden z użytkowników nie będzie zalogowany lub konsola będzie zablokowana, to okno mimo wszystko pojawi się.
Pozostały nam jeszcze dwie bardzo ciekawe opcje do omówienia. Pierwsza z nich pokazuje zaawansowane informacje na temat wysyłania wiadomości. Mówię tutaj o opcji „/V”. Drugim bardzo przydatnym przełącznikiem jest „/W”, który nie kończy działania na wysłaniu wiadomości, ale oczekuje na potwierdzenie naciśnięcia przycisku „OK” przez odbiorcę. Parametr ten ma sens tylko w przypadku używania go z długim czasem oczekiwania, gdyż domyślnie aplikacja czeka tylko (aż – jak kto woli) 60 sekund. Przełączniki „/V” oraz „/W” bardzo dobrze uzupełniają się podczas pracy. Polecam używanie ich razem.
Podsumowanie
Niniejszy tekst jest końcem pierwszej części dokumentacji na temat obsługi dziennika zdarzeń i logów systemowych. W kolejnej części omawiane będą inne narzędzia. Dodatkowo zapraszam do dalszych artykułów na temat programów występujących w systemach Windows.
| • |
 | Marcin Krawczyk (MCSE + Security, MCDST, MCT) |