Windows Event Log Forwarding

Это отчасти зависит от Вашего определения "Нулевого Времени простоя" - разделения-> обновление-> fail-over->, сценарий восстановления может быть выполнен довольно легко путем установки репликации между двумя SQL-серверами, которая также приносит Вам пользу дублирования.
Это работает очень похоже к тому, что Вы описываете выше: Когда Вы делаете обновление, Вы разделяете свой пар репликации и обновляете одного из них (наряду с несколькими серверами приложений), переключаете загрузку в обновленный набор машин, затем обновляете другие и восстанавливаете репликацию. Протест - Вы, должен будет, вероятно, все еще прекратить признавать, что изменения (вставляют/обновляют) во время окна обновления (по крайней мере, пока обновленные серверы не будут работать), иначе Вы будете волновать с мозговым разделением сценарием, где у Вас есть изменения в "старой" системе, которая будет потеряна в "новом".

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


Мое предложение Вам - то, что Вы настаиваете на соответствующих окнах обслуживания для всех изменений/обновлений, для включения времени простоя при необходимости. Очень немного систем должны быть действительно 24x7x365, и если Вы волнуете с неожиданной проблемой, для системы всегда лучше быть в режиме офлайн с достаточным количеством времени для Вас, чтобы решить проблему или вернуться Ваши изменения, чем помчаться через фиксацию с сердитыми пользователями, вдыхающими вниз Вашу шею, потому что они не ожидали отключение электричества...

6
задан 3 February 2012 в 16:52
6 ответов

Для Windows Vista, 7 и 2008:

Служба Windows-Eventcollector (wecsvc) на исходных компьютерах, которая перенаправляет события на компьютеры-сборщики, если вы с использованием подписки, инициированной источником, запускается как учетная запись «Сетевая служба». Но учетная запись сетевой службы не имеет доступа к журналу событий безопасности. Локальная группа «Читатели журнала событий» имеет доступ ко всем журналам. Это означает, что на каждом исходном компьютере вам необходимо добавить учетную запись «Сетевая служба» в локальную группу «Читатели журнала событий», чтобы служба Windows-Eventcollector имела доступ к журналу событий безопасности и могла пересылать его на компьютер-сборщик. (s).

Используя SDDL (язык определения дескрипторов безопасности), вы также можете переопределить разрешения для различных журналов событий с помощью wevtutil,

2
ответ дан 3 December 2019 в 00:13

Возможно, атрибут Path в блоке запроса фильтрует его. Он должен работать и без него:

<QueryList>
  <Query Id="0">
    <Select Path="Application">*</Select>
    <Select Path="Security">*</Select>
    <Select Path="Setup">*</Select>
    <Select Path="System">*</Select>
  </Query>
</QueryList>
2
ответ дан 3 December 2019 в 00:13

Вероятно, проблема с разрешениями в журнале событий безопасности.

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

Обратите внимание, что в Windows 2008 и Windows Vista / 7 есть новая группа «Читатели журнала событий», которая упрощает предоставление такого уровня доступа.

2
ответ дан 3 December 2019 в 00:13

Включено ли ведение журнала безопасности на рабочих станциях? В противном случае пересылать будет нечего.

2
ответ дан 3 December 2019 в 00:13

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

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

1
ответ дан 3 December 2019 в 00:13

We've just followed this guide and like yourselves, we didn't get anywhere, until we added the delegated account for the event logs gathering to the domain admins, and we're no longer in ruins.

Next step, to find a more secure way of doing this!

2
ответ дан 3 December 2019 в 00:13

Теги

Похожие вопросы