В какой папке хранятся файлы журналов ос windows по умолчанию

В журналах событий Windows хранится полезная информация, которая нужна при анализе состояния служб и приложений в Windows, отладки ошибок и аварийный ситуаций, аудите различных событий безопасности. По умолчанию для журналов Event Viewer в Windows заданы максимальные размеры, при достижении которых новые события начинают перезаписывать более старые. Если на вход Event Viewer попадает слишком большое количество событий, может случится, что в журнал помещаются события лишь за последние несколько часов, что может быть не достаточно.

Чтобы предотвратить перезапись старых событий и всегда иметь под рукой события за достаточно большой промежуток времени, вы можете увеличить максимальный размер журналов Event Viewer.

Получить информацию о журналах событий Windows с помощью PowerShell

Файлы журналы событий Windows хранятся в каталог
%SystemRoot%\System32\Winevt\Logs\
в виде файлов с расширением .EVTX. Обратите внимание, что для каждого журнала используется собственный файл. Соответственно, вы можете управлять размерами только того лога Windows, который вам нужен и оставить остальные значения по-умолчанию.

Картинка с сайта: winitpro.ru

Текущие лимиты на все включенные журналы событий в Windows можно вывести с помощью PowerShell:

Get-Eventlog -List

Картинка с сайта: winitpro.ru

Вы можно вывести размер определенного лога с помощью командлета Get-WinEvent. Например, получим текущий и максимальный размер журнала Security:

Get-WinEvent -ListLog Security| Select MaximumSizeInBytes, FileSize, IsLogFull, OldestRecordNumber, IsEnabled, LogMode

Картинка с сайта: winitpro.ru

Суммарный размер паки с файлами журналов событий можно получить с помощью PowerShell:
«{0:N2} MB» -f ((gci c:\windows\System32\Winevt\Logs\| measure Length -s).sum / 1Mb)

Чтобы увеличить максимальный размер лога, можно использовать утилиту wevtutul (новый размер задается в Кб):

wevtutil sl "Application" /ms:200000

Или с помощью PowerShell:

Limit-Eventlog -Logname Application -MaximumSize 200MB -OverflowAction OverwriteOlder

Изменить размер журнала событий из консоли Event Viewer

Проще всего увеличить максимальный размер журнала прямо из консоли Event Viewer.

1. Откройте
   eventvwr.msc
   ;
2. Найдите в консоли свойства нужного журнала и откройте его свойства (например, Security);
3. Задайте ограничение в разделе Maximum log size (KB) и сохраните изменения;
   

   Картинка с сайта: winitpro.ru

4. Здесь же можно изменить поведение при достижение максимального размера:
   Owerwrite events as needed (oldest events first) – этот режим исопльзуется по умолчанию. Новые события просто перезаписывают более старые.
   Archive the log when full, do not owerwrite events – текущий журнал событий при заполнении архивируется в папке \System32\Winevt\Logs\ и новые события записываются в новый evtx файл. Архивные файлы событий можно открыть через меню Open Saved Log в Event Viewer.
   Do not owerwrite events (Clear log manually) – события никогда не перезатираются. Для записи новых событий нужно очистить журнал.

Увеличить размер журнала событий Windows через GPO

Чтобы централизованно управлять размерами журналов событий на компьютерах или серверах в домене Active Directory, можно использовать групповые политики.

1. Запустите консоль Group Policy Management (
   gpmc.msc
   ), создайте новую GPO и назначьте на OU с компьютерами или серверами, для которых вы хотите изменить настройки Event Viewer (или назначьте GPO на корень домена);
2. Перейдите в раздел GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Log Service. Как вы видите, в этом ветке есть подразделы для управления базовыми журналами Windows:

   Application
   Security
   Setup
   System

3. Чтобы увеличить максимальный размер любого из журналов, откройте параметр Specify the maximum log file size (KB), включите его и задайте нужный вам размер;
   

   Картинка с сайта: winitpro.ru

4. Обновите настройки политики на клиентах и проверьте, что в свойствах журнала теперь указан новый размер, который вы не можете изменить. При попытке задать другой размер появится ошибка:
   

   Картинка с сайта: winitpro.ru

   Event Viewer
   The Maximum Log Size specified is not valid. It is too large or too small. The Maximum Log Size will be set to the following: 61440 KB

Обратите внимание, что в описанном выше разделе GPO отсутствуют настройки для других журналов из раздела Applications and Services Logs -> Microsoft.Если вам нужно увеличить размер любого другого журнала событий (кроме стандартного), это можно сделать через реестр. Настройки журналов событий Windows хранятся в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\<log_name>. Размер журнала задается с помощью параметра MaxSize (тип REG_DWORD). Вы можете распространить нужное вам значение параметра реестра MaxSize на компьютеры домена с помощью Group Policy Preferences.

Подробнее о настройке ключей и параметров реестра через GPO здесь.

В этом примере мы увеличим размер журнала Directory Service на контроллерах домена. Настройки этого лога хранятся в ветке HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Directory Service.

Картинка с сайта: winitpro.ru

1. Откройте GPO и перейдите в раздел Computer Configuration -> Preferences -> Windows Settings -> Registry;
2. Выберите New -> Registry Item;
3. Создайте новый параметр со следующими настройками:

   Hive: HKEY_LOCAL_MACHINE
   Key path: SYSTEM\CurrentControlSet\Services\EventLog\Directory Service
   Value name: MaxSize
   Value type: REG_DWORD
   Value data: 52428800 (значение задается в байтах. В нашем примере это 50 Мб)

   

   Картинка с сайта: winitpro.ru

4. Проверьте, что после обновления GPO на DC увеличится максимальный размер журнала.
   

   Картинка с сайта: winitpro.ru

Например, если вам нужно хранить историю RDP подключений к RDS хосту за продолжительное время, нужно увеличить размер лога Terminal-Services-RemoteConnectionManager.

За счет увеличения размеров журналов событий Windows вы можете получить различную информацию за более длительный промежуток времени. Например, из журналов событий можно получить историю перезагрузок Windows, понять кто удалил файл в сетевой папке или кто изменил NTFS права доступа.

Время на прочтение5 мин

Количество просмотров79K

Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.

Картинка с сайта: habr.com

Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Картинка с сайта: habr.com

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

Logon/Logoff

• Logon;
• Logoff;
• Account Lockout;
• Other Logon/Logoff Events.

Account Management

• User Account Management;
• Security Group Management.

Policy Change

• Audit Policy Change;
• Authentication Policy Change;
• Authorization Policy Change.

Системный монитор (Sysmon)

Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.

Картинка с сайта: habr.com

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Картинка с сайта: habr.com

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Картинка с сайта: habr.com

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

Обратите внимание, что после настройки инструмента сбора и анализа этих событий потребуется дополнительное время на отладку для снижения количества ложных срабатываний.

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.

Отслеживание событий — основа безопасности систем

Когда на компьютере происходит какое-либо значимое событие, операционная система записывает это событие в журнал. Входом в журналы служит Event Viewer (eventvwr.exe). Большинство администраторов открывают Event Viewer, только когда пытаются решить какую-нибудь проблему, и многие знакомые администраторы говорят мне, что используют Event Viewer только на серверах. Оба подхода ошибочны, потому что периодическая проверка системных журналов часто позволяет выявлять неполадки на ранней стадии, до того как они превратятся в серьезную проблему. Уметь пользоваться Event Viewer очень важно, поэтому я хочу предложить читателям краткий обзор по этой теме и представить свои способы работы с Event Viewer.

Общие сведения

Event Viewer открывается через меню Administrative Tools (если это меню добавлено в Programs) или через приложение Administrative Tools панели управления. Консоль программы Event Viewer содержит список доступных журналов. На компьютерах Windows по умолчанию имеются следующие журналы:

• Application (журнал приложе-ний) — содержит события, записываемые программами. Приложение определяет типы записываемых событий и язык сообщения.
• Security (журнал безопасности) — содержит события, относящиеся к безопасности компьютера, такие как попытки регистрации в системе или манипуляции с файлами.
• System (журнал системы) — содержит события, записываемые компонентами Windows.

В системах Windows Server 2003 и Windows 2000 Server в зависимости от роли сервера можно также использовать следующие журналы:

• Directory Service — содержит события, имеющие отношение к Active Directory (AD), и доступен только на контроллерах домена (DC).
• File Replication Service — содержит события, записываемые во время репликации между DC, и доступен только на DC.
• DNS Server — содержит события, относящиеся к разрешению имен DNS, и доступен только на серверах DNS.

Event Viewer отображает типы событий, каждое из которых имеет собственный уровень важности и собственную пиктограмму в журнале. Например:

• Error (ошибка) — сигнализирует об актуальной проблеме, которая может касаться потери функциональности, такой как нарушение корректного запуска служб и драйверов.
• Warning (предупреждение) — указывает на проблему, которая впоследствии может стать серьезной, если не обращать внимания на предупреждение. Предупреждения сугубо информативны и не свидетельствуют о наличии проблемы в настоящем или обязательном ее появлении в будущем.
• Success Audit (аудит успехов) — это событие, имеющее отношение к системе безопасности, которое произошло и записывается потому, что система или администратор включили аудит данного события.
• Failure Audit (аудит отказов) — это событие, имеющее отношение к системе безопасности, которое не произошло, но запись о нем делается потому, что система или администратор включили аудит данного события.

Информация, отображаемая в Event Viewer, включает дату и время, когда произошло событие, источник события (то есть служба, драйвер устройства или приложение, записавшее событие в журнал), категорию события, ID события, имя пользователя, который был зарегистрирован в системе, когда событие произошло (не обязательно) и имя компьютера, на котором произошло событие. Для того чтобы просматривать журнал Security, необходимо иметь права администратора.

Настройка Event Viewer

Системные журналы начинают функционировать автоматически при запуске операционной системы. Размеры журнальных файлов ограничены, и система записывает события, удаляя старые записи в соответствии с выбором параметров журнала. Чтобы просмотреть или изменить конфигурацию, нужно щелкнуть правой кнопкой на имени журнала в списке Event Viewer и выбрать в раскрывающемся меню пункт Properties. Должно появиться соответствующее диалоговое окно свойств, как показано на экране 1.

Менять конфигурацию следует в зависимости от ситуации. Если вы не вносите существенных изменений в конфигурацию журнала или не видите необходимости в аудите событий, то работа настроек по умолчанию должна вас устроить. Настройка по умолчанию для максимального размера файла журнала составляет 512 Кбайт, и когда журнал заполнен, система автоматически заменяет старые записи новыми через 7 дней. Однако, если в систему вносятся существенные изменения или вводится в действие подробный аудит, журналы, скорее всего, начнут заполняться многочисленными записями. Если журнал оказывается заполненным и не содержит записей, хранящихся более 7 дней, утилите Event Viewer будет нечего удалить, чтобы освободить место для новых записей, и система прекратит записывать события. В этой ситуации нужно увеличить размер журнального файла или выполнить настройку журнала на затирание старых записей по мере необходимости (вариант Overwrite events — as needed).

Фильтры

Когда администратор исследует журнал, чтобы решить какую-либо проблему, или проверяет реакцию компьютера на существенное изменение конфигурации, он может ускорить этот процесс, избавившись от не имеющих отношения к делу записей в панели Details. Диалоговое окно Properties каждого журнала имеет вкладку Filter, с помощью которой выбираются типы отображаемых событий. Например, вы не хотите видеть информационные записи от определенных компьютеров или вы хотите видеть только события, произошедшие в течение недели после внесения системных изменений. Следует просто нужным образом выбрать фильтры (или отменить выбор). Помните, что фильтры влияют только на то, что отображается в окне; система продолжает записывать в журнал события тех типов, которые были отфильтрованы. Например, если есть основания полагать, что возникла угроза системе безопасности в виде вторжения извне, можно оставить для отображения события только тех типов, быстрый взгляд на которые позволяет обнаружить аномалии в регистрации, такие как события с ID 675 и 681, соответствующие неудачным попыткам аутентификации, или событие с ID 644, означающее блокировку учетной записи вследствие многократного некорректного ввода пароля.

Сортировка журнала

Погружаясь в решение какой-нибудь проблемы, я предпочитаю сортировать журналы, чтобы иметь возможность находить нужные записи непосредственно по типу события, идентификационному номеру (ID) события или по предполагаемому источнику сообщения. Например, я могла бы задаться целью найти событие Userenv, если проблема касается некоторого пользователя, имеющего проблемы с доступом в сети.

Общее событие Userenv имеет ID 1000 в журнале приложений и его описание гласит, что Windows не смогла определить имя пользователя или компьютера. Это означает, что конфигурация TCP/IP компьютера для обращения к DNS-серверу установлена некорректно. Администраторы сплошь и рядом используют неправильные адреса при настройке DNS на клиентских компьютерах; я часто нахожу IP-адрес шлюза в поле для адреса DNS. Проверку журнала компьютера-«обидчика» со своей рабочей станции обычно выполнить проще, чем идти к клиентскому компьютеру и проверять настройки TCP/IP.

Чтобы сосредоточиться на событиях конкретных типов, нужно выбрать подходящий журнал в консоли, раскрыть его содержимое, затем щелкнуть область заголовка столбца, по которому предстоит выполнить сортировку. По умолчанию журналы отсортированы по дате, а затем по времени.

Очистка журнала

Любой журнал можно очистить, чтобы освободить дополнительное место для записей. Если выбрана настройка Do not overwrite events (clear log manually) —«Не затирать события (очистка журнала вручную)», необходимо периодически чистить журнал.

Чтобы очистить журнал, следует щелкнуть правой кнопкой на названии журнала в списке консоли Event Viewer и выбрать пункт Clear all Events («Стереть все события»). Система спрашивает, нужно ли сохранить журнал перед тем, как очистить его. Если в журнале есть записи, которые могли бы пригодиться в будущем (например, при длительном отслеживании проблемы), можно выполнить архивацию содержимого журнала.

Архивация журнала

Любой журнал можно заархивировать как отдельный файл — это полезно, если в журнале появляются необычные записи и требуется понаблюдать некоторое время за изменением его содержимого. Иногда в журналах появляются события, которые выглядят угрожающе, но пользователь не ощущает никаких проблем. Если проблемы возникнут позже, сотрудникам службы поддержки Microsoft, возможно, будет полезно изучить историю этого события.

Чтобы создать архивную копию журнала, нужно щелкнуть правой кнопкой мыши по названию журнала в консоли и выбрать в меню Save Log File As («Сохранить файл журнала как…»). По умолчанию Windows сохраняет файл в папке Administrative Tools, расположенной в папке C:documentssettingsusernamestart menuprograms. Можно указать другую папку или создать отдельную папку для хранения архивных копий журналов. Я обычно присваиваю журналам имя в формате имя_журнала-дата (например, apps-dec012003). Windows добавляет расширение .evt.

Архивные копии журналов являются отдельными файлами на жестком диске, но открывать их можно только через программу просмотра событий Event Viewer. Для этого следует выбрать пункт Open Log File («Открыть файл журнала») в меню Action (или щелкнуть правой кнопкой по любому объекту в консоли и выбрать Open Log File). В диалоговом окне открытия файла требуется выбрать нужный архив, указать тип журнала (т. е. Application, Security) в меню со списком Log Type, затем щелкнуть Open.

Чтобы удалить архив из консоли, следует щелкнуть правой кнопкой по его названию в списке и выбрать Delete. Это действие не удаляет файл с жесткого диска — только из консоли. Удаление архивной копии журнала с жесткого диска выполняется так же, как и удаление любого другого файла.

Просмотр событий на удаленном компьютере

Чтобы облегчить себе задачу, администратор может со своей рабочей станции просматривать журналы удаленных компьютеров, на которых у него есть административные привилегии. На удаленном компьютере должна быть установлена Windows 2003, Windows XP, Windows 2000 Professional, Windows 2000 Server, Windows NT Server или NT Workstation.

На локальной консоли просмотра событий нужно щелкнуть правой кнопкой Event Viewer (Local) и выбрать Connect to another computer («Подключиться к другому компьютеру»). Следует ввести имя удаленного компьютера, с которым предстоит работать, или щелкнуть Browse, чтобы открыть диалоговое окно, показанное на экране 2, затем выбрать компьютер. Кроме того, если имя удаленного компьютера известно, нет необходимости вводить его в виде имени UNC. Вид консоли Event Viewer меняется таким образом, что отображает имя UNC удаленного компьютера. На удаленном компьютере можно производить те же действия, что и на локальном Event Viewer. Чтобы вернуться на локальный компьютер, следует щелкнуть правой кнопкой Event Viewer (имя компьютера), выбрать Connect to another computer, а затем Local computer.

Что искать при просмотре событий

Большинство реальных и потенциальных проблем проявляют себя посредством записи событий в тот или иной журнал. Когда вы видите запись с пометкой Error или Warning, будьте внимательны. Поищите информацию об этом событии в Microsoft Knowledge Base или на Web-сайте Windows & .NET Magazine. Если медлить с просмотром журналов, вы упустите возможность предотвратить проблему. Приведу пример. Во время периодических просмотров журналов на всех компьютерах своей сети я обнаруживаю запись в системном журнале, которая показана на экране 3. Никаких видимых признаков неполадок на компьютере не было.

Я быстро выполняю резервное копирование данных компьютера и запускаю программу Chkdsk, которая перемещает файлы (это были системные файлы) из испорченной области и помечает ее как испорченную, чтобы предотвратить дальнейшую запись в эту часть диска. Затем я начинаю ежедневно проверять системный журнал в течение нескольких недель и, только убедившись, что никаких новых сообщений об ошибках не появляется, возвращаюсь к еженедельному просмотру Event Viewer. Увидев дополнительные сообщения об ошибках, я бы заменила диск. Если бы я периодически не проверяла журналы компьютера, диск мог бы продолжать разваливаться и резервное копирование оказалось бы бесполезным из-за порчи файлов.

Кстати, когда я проверяю Event Viewer, я выполняю сортировку событий по типу и сначала просматриваю сообщения об ошибках, а затем предупреждения. В этот раз я также обнаружила предупреждение, датированное днем раньше, чем появилось сообщение об ошибке, и в этом предупреждении говорилось, что при записи в файл подкачки Windows обнаружила ошибку на диске. Если бы я проверила системный журнал днем раньше, я бы, возможно, нашла меньшее количество испорченных фрагментов для исправления программой Chkdsk.

Следует также просматривать все события в журнале безопасности. Этот журнал будет оставаться пустым до тех пор, пока вы не установите аудит событий безопасности. Если аудит событий безопасности установлен, ищите значительные события в зависимости от настроек аудита. Журнал безопасности — единственный журнал в Event Viewer, для просмотра которого необходимы административные полномочия. Более подробную информацию об аудите событий безопасности можно найти в статье «Мониторинг событий безопасности» (Windows & .NET Magazine/RE, №7 за 2003 год, и на Web-странице http://www.osp.ru/win2000/2003/07/019.htm).

Как остановить запись нежелательных событий

По умолчанию Windows настраивает компьютеры как принт-серверы, которые записывают все события, относящиеся к печати на принтерах. Кроме того, системный журнал компьютера делает информационные записи при каждой отправке документа на принтер и повторно — когда файл спулера удален после выполнения задания на печать.

Для меня события, относящиеся к печати на принтерах, не имеют значения, но некоторые администраторы хотят знать, были ли ошибки в работе с принтерами и если были, то когда; возможна также запись уведомлений, когда кто-то добавляет или удаляет принтер. Сомневаюсь, что администраторы убеждены в необходимости пополнять журнал уведомлений каждый раз, когда задание на печать отправляется спулеру, а потом удаляется.

Можно изменить выбор событий печати, записываемых в системный журнал, в папке Printers компьютера (в Windows 2003 и XP она называется Printers and Faxes). Выберите File, Server Properties и перейдите на вкладку Advanced, показанную на экране 4. Можно просто отменить выбор событий, которые вы не хотите регистрировать в журнале.

Возьмите за правило

Поместите Event Viewer в свой список задач по обслуживанию и периодически проверяйте сетевые компьютеры. Если вы отвечаете за множество компьютеров, обеспечьте по крайней мере еженедельную проверку серверов (особенно контроллеров доменов), а рабочие станции следует проверять так, чтобы каждая рабочая станция попадала в поле зрения раз в несколько недель. Хотя на первый взгляд может показаться, что эта задача очень трудоемкая, устранение серьезной проблемы отнимает намного больше времени и сил, чем проверка журналов для получения дополнительной информации о текущих неполадках.

Кэти Ивенс (kivens@win2000mag.com) — редактор Windows & .NET Magazine. Является соавтором более 40 книг по компьютерной тематике, включая «Windows 2000: The Complete Reference»