Случалось ли так, что вы обнаруживали многократное появление нижеприведенного события в логах в различное время дня и пытались понять, что его вызывает? Если это так, то, возможно, у нас есть довольно простой ответ.
Event Type: Error
Event Source: Microsoft ISA Server Web Proxy
Event Category: None
Event ID: 14197
Date:
Time:
User: N/A
Computer: ISA01
Description:
ISA Server was unable to write content to the cache file.
В качестве одного из примеров решения этой проблемы предлагаем вам обзнакомиться в постом за авторством Suraj Singh.
Mystery of frequent occurrence of Event id 14197 : http://blogs.technet.com/b/sooraj-sec/archive/2011/05/07/mystery-of-frequent-occurence-of-event-id-14197.aspx
Автор:
J.C. Hornbeck | Knowledge Engineer | Management and Security Division
Оригинал:
Загадка появления события с кодом 14197 в ISA Server — Suraj Singh’s ISA server Blog
Проблема:
Не так давно я работал над делом, где в логах ISA Server появлялось следующее событие:
Event Type: Error
Event Source: Microsoft ISA Server Web Proxy
Event Category: None
Event ID: 14197
Date: 04/11/2011
Time: 12:05:03 AM
User: N/A
Computer: ISA01
Description:
ISA Server was unable to write content to the cache file.
Появлялось оно довольно часто, в течение различных периодов дня, не обязательно в часы пик. Все пользователи в качестве клиента использовали web proxy. Кроме появления этого события с ISA Server не было никаких проблем. Тем не менее, администратор хотел знать, почему это происходит.
Исследование проблемы и ее решение:
- На сервере был установлен антивирус, и каталоги ISA Server не были исключены из сканирования. В соответствии со статьей http://technet.microsoft.com/en-us/library/cc707727.aspx, мы исключили эти каталоги из антивирусного сканирования и понаблюдали за системой в течение дня. Событие по-прежнему появлялось в течение разных периодов дня.
-
Следуя указаниям поста Yuri Diogenes http://blogs.technet.com/b/yuridiogenes/archive/2010/01/30/isa-server-triggers-lots-of-14197-events.aspx, мы включили аудит доступа к объектам для файла кэша. Там мы могли посмотреть, какой процесс получал доступ к файлу во время возникновения события. Мы просмотрели логи и обнаружили, что доступ к файлу кэша имели только два процесса – wspsrv (firewall service) и mspadmin (ISA Control Service), как все и должно быть. Природа возникновения события по-прежнему была не ясна.
-
Мы попросили команду, занимающуюся отслеживанием производительности проверить работу жесткого диска, использую Performance Monitor. В графике, отображающем среднюю длину очереди диска, присутствовали пики, но большую часть времени показатель находился на уровне отметки 2. Команда отслеживания производительности сообщила нам, что, хотя диск C достаточно активно используется, тем не менее, всплески активности (в соответствии с показателем средней длины очереди диска) приходятся на моменты времени, отличные от тех, когда появляется упомянутое событие.
-
Тогда я решил еще раз взглянуть на конфигурацию кэша и заметил, что размер кэша был установлен в 1000 МБ. Я спросил заказчика о количестве пользователей, получающих доступ в Интернет через ISA Server, и хотя он не мог назвать точную цифру, выходило примерно 5 тысяч. Я объяснил ему, что кэша размером в 1 GB недостаточно для такого количества пользователей.
-
Администратор спросил меня, каков же подходящий размер кэша. Метод определения размера кэша в зависимости от количества пользователей можно найти в посте по адресу http://blogs.technet.com/b/sooraj-sec/archive/2010/04/12/formula-for-cache-drive-size.aspx. Что касается этого случая, размер кэша должен быть:
0,5*5000 + 10 MB = 2510 MB.
- Мы установили размер кэша, равный 2510 MB и продолжили наблюдение за поведением системы. Событие перестало появляться.
Автор:
Suraj Singh
Оригинал:
Страницы в социальных сетях:
Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell
sergey vasin 