• MDOP DaRT – замена загрузчика восстановления для Windows 7 и Server 2008 R2

    imageПодписчикам программы Microsoft Software Assurance (SA) доступен программный пакет Microsoft Desktop Optimization Pack (MDOP).

    В составе MDOP присутствует набор инструментальных средств для восстановления систем Windows - Diagnostics and Recovery Toolset (DaRT). С помощью DaRT можно подготовить загрузочный образ со средой Windows Recovery Environment (WinRE) наполненной разного рода утилитами восстановления. Стандартный сценарий применения этого образа подразумевает загрузку с какого-то внешнего носителя, типа оптического привода или USB накопителя. Помимо этого в системах Windows 7/2008 R2 в процессе установки на системном томе в специальном скрытом каталоге Recovery размещается загрузочный образ упрощённого экземпляра WinRE. Мы можем воспользоваться процедурой описанной в статье Netanel Ben-Shushan - Replace Default Windows 7/Server 2008 R2 Recovery Environment in Diagnostic and Recovery Toolset Version 6.5 для того чтобы интегрировать набор средств DaRT 6.5 непосредственно в установленный экземпляр Windows. Такая конфигурация может оказаться полезной в организациях, где например политиками безопасности запрещено использовать CD/USB или на компьютерах попросту нет таких девайсов или портов. Далее пошагово описаны нехитрые действия, необходимые для интеграции DaRT в установленную систему Windows 7.

    Читать далее...

  • Установка и первоначальная настройка Microsoft Forefront Protection 2010 for Exchange Server на Exchange Server 2007 с ролью Hub-Transport в среде Windows Server 2008

    Аппаратные требования

    · Компьютер на основе архитектуры x64 (32-разрядные операционные системы не поддерживаются);
    · 2 ГБ ОЗУ, помимо памяти, необходимой для запуска сервера Exchange (для многоролевых серверов Exchange требование к памяти увеличивается на 1,5 ГБ);
    · 2 ГБ свободного места на диске, в дополнение к месту на диске, необходимому для сервера Exchange;
    · Рекомендуется четырехъядерный сервер с процессорами с тактовой частотой 2,0 ГГц или выше. Серверы с более низкой производительностью также поддерживаются, но пропускная способность снижается.

    Программные требования

    · Microsoft Windows Server 2003 с пакетом обновления 2 (SP2), Microsoft Windows Server 2008 или Microsoft Windows Server 2008 R2;
    · Сервер Microsoft Exchange Server 2007 с пакетом обновления 1 (SP1) или Microsoft Exchange Server 2010;
    · Microsoft XML Core Services (MSXML) 6.0 SP1;
    · Microsoft .NET Framework 3.0 SP 1 Windows Communication Foundation или Microsoft .NET Framework 3.5;
    · Элементы управления Microsoft Chart для Microsoft .NET Framework 3.5;
    · Windows PowerShell 1.0

    Общие рекомендации перед установкой.

    Рекомендуется не устанавливать FPE на контроллер домена.

    Длина путей к каталогам данных FPE ограничена 216 символами.
    При изменении папки установки длина ее названия не должна превышать 170 символов.

    Компонент FPE будет установлен и запущен, только если для политики выполнения Windows PowerShell задан параметр "Remote Signed", устанавливаемый сервером Exchange по умолчанию. Компонент FPE не поддерживает применение более строгих параметров, таких как "Restricted" или "AllSigned".
    Получить текущее значение параметра можно командой PowerShell:

    Get-ExecutionPolicy

    Если значение параметра отличается от "Remote Signed", то установить нужное значение можно командой PowerShell:

    Set-ExecutionPolicy RemoteSigned

    При каждом запуске или переключении внутри интерфейса Консоль администрирования Forefront Protection 2010 for Exchange Server осуществляется запись в журнал событий Windows PowerShell. Если настройка журнал PowerShell настроена таким образом, что события по мере заполнения не затираются, то возможны проблемы в работе FPE. Рекомендуется использовать автоматическое переписывание старых записей в журнале, то есть настройки журнала должны выглядеть примерно так:

    image 

    Если используется Exchange Server 2007 с отключенной службой WinHTTP Web Proxy Auto-Discover Service, невозможно запустить службы Microsoft Forefront Server Protection Controller, Microsoft Exchange Transport, Microsoft Exchange Information Store. Перед запуском указанных служб Microsoft Forefront и Microsoft Exchange убедитесь, что для службы WinHTTP Web Proxy Auto-Discover Service тип запуска не установлен в значение “Disabled”.

    При использовании антивирусной программы, выполняющей проверку на файловом уровне, на сервере, содержащем Forefront Protection 2010 for Exchange Server (FPE), во избежание повреждения FPE необходимо убедиться, что указанные ниже папки не проверяются:

    • Папка, в которую установлена программа FPE.
      В конфигурации по умолчанию используются следующие пути:
      Папка программы: C:Program Files (x86)Microsoft Forefront Protection for Exchange Server
      Папка данных: C:Program Files (x86)Microsoft Forefront Protection for Exchange ServerData
      Папка антивирусных ядер: C:Program Files (x86)Microsoft Forefront Protection for Exchange ServerDataEngines
    • Папка, в которую установлена программа Microsoft Exchange Server исходя из рекомендаций, представленных ранее в посте Настройка исключений для антивирусного ПО

    Установка

    Программа установки Microsoft Forefront Protection 2010 for Exchange Server (FPE) имеет встроенную проверку наличия необходимых компонентов, которая запускается одновременно с мастером установки. Если какие-то из компонентов не установлены, то выводится уведомление о том, что перед продолжением процесса установки следует загрузить и установить недостающие компоненты.
    При первом запуске инсталлятора forefrontexchangesetup.exe я получил такое сообщение:

    image 
    Это означало, что требуется внесение изменений в AD на уровне разрешений Enterprise Administrator перед началом установки FPE на данный сервер. Для этого пришлось распаковать дистрибутив forefrontexchangesetup.exe во временный каталог и затем с правами уровня Enterprise Administrator запустить утилиту подготовки сервера FseMachinePrep.exe

    Cd /d C:TempFPE
    forefrontexchangesetup.exe /x:"C:TEMPFPEInstallFiles"
    cd /d C:TEMPFPEInstallFiles
    FseMachinePrep.exe

    image 
    Подобная процедура подготовки должна выполнятся для каждого сервера на который будет производится установка FPE.
    Вообще в моей ситуации требование предварительной подготовки AD выглядело не совсем уместным, так как в документации требование данной процедуры описывается только при установке на сервера с Exchange Server 2010, и тут самое интересным было то, что на этот момент в организации не было серверов Exchange Server 2010 вообще. На ум пришло только то, что недавно был установлен SP2 на Exchange Server 2007. А по информации от надёжных источников именно при установке SP2 схема AD расширялась до уровня Exchange Server 2010.
    Дополнительную информацию о необходимости обновления AD в случае использования Exchange Server 2010 можно найти здесь: Для установки на сервер Exchange Server 2010 требуются учетные данные безопасности

    После вышеописанного действия можно возобновить/продолжить процесс установки.
    В начале процесса нас честно предупреждают о том, что в процессе установки будет перезапущена служба Microsoft Exchange Transport

    image

    Далее указываем каталог для установки исполняемых файлов FRE в поле Program Folder. В поле Data Folder указываем папку, в которой будут размещаться файлы данных, такие как файлы, помещенные на карантин, и архивированные файлы.
    Рекомендуется выбирать диск, на котором имеется достаточное количество свободного места, чтобы хранить большой объем файлов.
    Не следует указывать расположение папки, находящееся в корневом каталоге диска, где расположен файл подкачки виртуальной памяти, например C:. Это может привести к сбою процесса установки (это относится и к расположению для папки с программой).
    Ещё раз обращаю внимание на то, что указанные каталоги должны быть внесены в список исключений антивирусного сканирования на уровне файловой системы.

    image

    Далее на странице Proxy Information нам предлагается ввести информацию для авторизации на proxy сервере, если мы планируем использовать прокси сервер для обновления исполняемых модулей и антивирусных/антиспамовых описаний. Учётные данные пользователя можно не указывать (причину объясню далее).

    image 
    На странице Antispam Configuration мы выбираем Enable Forefront Protection 2010 for Exchange Server antispam later.
    Если мы захотим включить FPE защиту от нежелательной почты позже, то это можно сделать с помощью ввода следующей команды Windows PowerShell:
    Set-FseSpamFiltering -Enabled $true

    image 

    В следующем диалоговом окне выберите Use Microsoft Update to check for updates (recommended)

    image

    Далее получаем краткие инструкции о том, что сразу после установки FPE мы должны обеспечить обновление движков и описаний и этот процесс будет автоматически инициирован через 5 минут после окончания процесса установки. Также приводится описание последовательности действий для ручного запуска процесса обновления в том случае, если мы не желаем ждать 5 минут.

    image 

    Ну и наконец, запускаем непосредственный процесс установки и дожидаемся его завершения.

    image

    Проверка установки

    FPE поддерживает пять антивирусных ядер: от Майкрософт, Norman, Authentium, VirusBuster и Kaspersky.
    После новой установки следует загрузить новые файлы определений, чтобы обеспечить защиту от последних угроз (как ранее отмечено этот процесс будет инициирован автоматически через 5 минут после окончания установки).
    До загрузки обновлений для всех лицензированных антивирусных ядер в журнал событий могут быть занесены сообщения об ошибках. Среди них может быть ошибка “Could not create mapper object” (Не удалось создать объект сопоставителя) – это типичное поведение FPE и эти ошибки можно проигнорировать.

    Чтобы проверить правильность установки FPE и включение защиты по умолчанию посмотрим в диспетчер задач на предмет наличия запущенных процессов:

      • На сервере, на котором установлена роль сервера почтовых ящиков, должно быть запущено четыре процесса FSCRealtimeScanner.exe и один процесс FSCScheduledScanner.exe.
      • На сервере, на котором установлена роль транспортного сервера (например, роль транспортного сервера-концентратора, пограничного сервера или транспортного сервера-концентратора и сервера почтовых ящиков) должно быть запущено четыре процесса FSCTransportScanner.exe.
        Этот как раз наш случай.

    image

     

    Так же необходимо удостоверится в том, что в планировщике задач успешно создалась задача по обновлению модулей FPE.

    Первоначальная настройка

    В самом начале использования FPE в продуктивной среде нам следует обратить особое внимание на некоторые настройки…

    Идентификация внутренних доменов

    FPE предоставляет параметры, позволяющие идентифицировать внешние и внутренние адреса. Рекомендуется настраивать эти параметры сразу после установки FPE, чтобы входящая и внутренняя почта легко идентифицировалась и направлялась на проверку на наличие вредоносных программ и соответственно фильтровалась. По возможности сразу постарайтесь заполнить список внутренних почтовых доменов. При добавлении имени доменов в поле Domain names used for identifying internal addressesучитывайте, что будут включены и дочерние домены.

    Если имеется большое количество доменов, используемых в качестве внутренних адресов, то их можно ввести во внешнем файле с именем Domains.dat и оставить поле Domain names used for identifying internal addresses пустым. Чтобы использовать внешний файл Domains.dat, необходимо включить параметр Use external "Domains.dat " file instead of value in “Domain names used for identifying internal addresses”. Domains.dat является пустым текстовым файлом, расположенным в папке с данными FPE, которую мы указали в процессе установки. В этот текстовый файл можно ввести все свои внутренние домены, каждый на отдельной строке. Учтите, что при использовании файла Domains.dat все дочерние домены следует указывать отдельно.

    image

    Таймаут загрузки обновлений

    По умолчанию таймаут обновления движков установлен в 300 секунд. Если в нашем окружении используется не особо скоростной Интернет канал, то мы рискуем не уложится в этот интервал, что в свою очередь может привести к невозможности обновления.
    Поэтому рекомендую сразу увеличить значение данного параметра до удовлетворяющего вашим условиям. Изменить данное значение можно в консоли FPE (Policy Management > Global Settings >Engine Options > параметр Engine download timeout)

    image

    Обработка сжатых файлов

    По умолчанию FPE расценивает все многотомные .rar архивы и .zip архивы высокой степени сжатия, как поврежденные сжатые файлы, для которых в свою очередь в конфигурации по умолчанию установлено удаление таких файлов. Если в вашей организации нормальной практикой считается пересылка многотомных архивов, то во избежание потери этих файлов рекомендую сразу выключить обе эти опции (Policy Management > Global Settings >Engine Options > параметры секции Specialty File Type Settings)

    image

    Также обратите внимание, что на файлы, хранящиеся в многотомных архивах RAR, действует ограничение размера. Ограничение определяется параметром Maximum uncompressed file size. Значение по умолчанию для данного ограничения составляет 100 мегабайт. Если в вашей организации разрешена пересылка сообщений достаточно больших размеров, то возможно вам потребуется увеличить значение этого параметра. В противном случае, при превышении данного значения, все тома многотомного архива RAR, содержащие весь файл или часть файла, будут удалены (настройка по умолчанию). Кроме того, это значение можно задать с помощью Windows PowerShell (Например: Set-FseAdvancedOptions -UnCompressedFileSize 1024).

    image

    Получение обновлений через прокси-сервер

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

    image

    Самое интересное, что на прокси-сервер с нашего HT не было зафиксировано ни одного обращения. Тут закралось подозрение, что несмотря на то что ранее мы предоставили программе установки данные о прокси-сервере, - они попросту не использовались, а шла попытка работать через WinHttpClient который в свою очередь у нас вообще до этого не использовался и как следствие был не настроен. Пришлось прибегнуть к утилите Netsh для настройки клиента WinHttp

    Чтобы получить информацию о текущих настройках WinHttp мы использовали команду:

    Netsh winhttp show proxy

    Убедившись в том, что параметры прокси-сервера не заданы, выполняем их установку командой:

    Netsh winhttp set proxy proxy-server="http=PROXY-SERVER:3128;https=PROXY-SERVER:3128"

    image

    В дальнейшем при необходимости для сброса параметров WinHttp можно будет использовать команду:

    Netsh winhttp reset proxy

    Далее нам потребовалось открыть на прокси-сервере проход без авторизации к следующим интернет-узлам по HTTP и HTTPS:

    forefrontdl.microsoft.com/server/scanengineupdate
    cdn-microupdates.cloudmark.com
    lvc.cloudmark.com
    tracks.cloudmark.com
    pki.cloudmark.com

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

    image

    Распространение обновлений внутри организации

    Чтобы не выполнять скачивание обновлений из интернета на каждый сервер FPE мы назначим наш сервер сервером распространений обновлений.
    На сервере, который будет выступать в качестве распространителя, необходимо создать общую папку для папки Engines из каталога данных FPE (в нашем случае это каталог D:Microsoft Forefront Protection for Exchange ServerDataEngines).
    На эту общую папку дадим разрешение на чтение для специально созданной доменной группы ForefrontPE-Computers (в эту группу мы должны включить учетные записи всех серверов FPE которые будут обновляться с этой общей папки).
    На сервере распространения выполняем следующие команды:

    NET SHARE FPE_Updates="D:Microsoft Forefront Protection for Exchange ServerDataEngines" /GRANT:MydomForefrontPE-Computers,READ

    CACLS "D:Microsoft Forefront Protection for Exchange ServerDataEngines" /T /E /G MydomForefrontPE-Computers:R

    Затем на этом же сервере в консоли FPE включим функцию распространения обновлений (Policy Management > Global Settings >Engine Options > Enable as an update redistribution server)

    image

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

    Теперь необходимо настроить FPE который будет скачивать обновления с сервера распространения по UNC пути.
    Для этого откроем консоль FPE на принимающем сервере и включим соответствующую опцию (Policy Management > Global Settings >Engine Options > Enable UNC)

    image

    При необходимости не забудьте на принимающем сервере очистить параметры прокси-сервера и отключить опцию Enable as an update redistribution server её в случае, если она включена.
    Далее измените значения параметра Engine management на Manual (Policy Management > Global Settings > Advanced Options > Engine management).

    image

    Далее здесь же указываем UNC путь к каталогу обновлений для каждого антивирусного ядра

    image

    Например, в случае настройки обновления для ядра Norman Virus Control в нашем случае будет выглядеть так:

    image

    Обратите внимание на то, что UNC-пути, указанные для обновления антивирусных ядер, не должны оканчиваться знаком обратной косой черты (). После проведения указанных настроек на всех принимающих серверах начнёт работать обновление антивирусных ядер.

    Теперь процесс Установки и первоначальной настройки Microsoft Forefront Protection 2010 for Exchange Server на Exchange Server 2007 c ролью Hub-Transport в среде Windows Server 2008 можно считать законченным.

    Дополнительная информация: Microsoft® Forefront Protection 2010 for Exchange Server

  • Forefront Client Security Troubleshooting: The following non-MOM API has failed: objMomServerUtils.GetScriptResponseParameterValue(). Error code: -2147024891

    После развертывания сервера Forefront Client Security на Windows Server 2008 в топологии с одним сервером на консоли FCS можно обнаружить периодически (примерно раз в час) появляющиеся предупреждения о проблемах на FCS сервере. В отчетах это может выглядеть примерно так:

    image

    Также на сервере в логе Application параллельно фиксируются предупреждения подобного содержания.

    image

    Проблема решается включением доменной учетной записи пользователя DAS (в нашем случае это MyDoms-user) в локальную группу безопасности FCS сервера с именем MOM Administrators

  • Дополнительная настройка баз данных SQL Server используемых для Forefront Client Security

    Дополнительная настройка баз данных SQL Server используемых для Forefront Client Security

    В процессе установки серверных компонент Forefront Client Security предлагаемые по умолчанию значения для размеров баз данных Collection Database (OnePoint) и Reporting Database (SystemCenterReporting) достаточно далеки от истины. Дело в том, что OnePoint это фактически оперативная база данных, которая хранит значения сбора статистики за последние 72 часа (хотя данные могут в ней накапливаться за период до 10 дней), в то время как SystemCenterReporting это база для хранения исторических данных периодом до 395 дней (значение «по умолчанию»). Именно это объясняет то, что размер базы данных SystemCenterReporting должен быть на порядок больше чем у  OnePoint. Дополнительную информацию можно найти в документе Forefront Client Security - Database sizing.

    Максимальный размер базы OnePoint30 Gb, в то время как для базы SystemCenterReporting таких ограничений не установлено. Для обеих этих баз функция Autogrow не поддерживается и поэтому важно правильно рассчитать и выставить размер этих БД ещё в начале эксплуатации Forefront Client Security.

    Осмелюсь предположить, что в продуктивном окружении наверняка нет необходимости сохранять исторические данные антивирусной статистики в базе SystemCenterReporting на протяжение 395 дней. Предположим, что нас вполне устроит период в 30 дней (в основном исходя из возможных ограничений в дисковой подсистеме). Сократив период, мы можем уменьшить размер базы данных SystemCenterReporting и соответственно сократить накладные расходы сервера на её обслуживание.
    Воспользуемся
    информацией из статьи базы знаний Microsoft KB887016 - How to modify the number of days to retain data in the SystemCenterReporting database in Microsoft Operations Manager 2005 для того, чтобы сократить это значение.
    Изменить установленные в процессе развертывания серверных компонент FCS значения можно с помощью SQL Server Management Studio.
    Для начала выполним запрос к базе данных SystemCenterReporting , чтобы получить текущие значения 'Groom Days' для 6 главных таблиц:

    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs

    Join classschemas cs

    On cs.cs_classID = wcs.wcs_classID

    Where cs.cs_tablename = 'SC_AlertFact_Table'

    And wcs.wcs_mustbegroomed = 1

     

    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs

    Join classschemas cs

    On cs.cs_classID = wcs.wcs_classID

    Where cs.cs_tablename = 'SC_AlertHistoryFact_Table'

    And wcs.wcs_mustbegroomed = 1

     

    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs

    Join classschemas cs

    On cs.cs_classID = wcs.wcs_classID

    Where cs.cs_tablename = 'SC_AlertToEventFact_Table'

    And wcs.wcs_mustbegroomed = 1

     

    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs

    Join classschemas cs

    On cs.cs_classID = wcs.wcs_classID

    Where cs.cs_tablename = 'SC_EventFact_Table'

    And wcs.wcs_mustbegroomed = 1

     

    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs

    Join classschemas cs

    On cs.cs_classID = wcs.wcs_classID

    Where cs.cs_tablename = 'SC_EventParameterFact_Table'

    And wcs.wcs_mustbegroomed = 1

     

    SELECT cs.cs_tablename 'Table Name', wcs.wcs_groomdays 'Groom Days' from warehouseclassschema wcs

    Join classschemas cs

    On cs.cs_classID = wcs.wcs_classID

    Where cs.cs_tablename = 'SC_SampledNumericDataFact_Table'

    And wcs.wcs_mustbegroomed = 1


    image

    Убедившись в том, что срок хранения данных действительно установлен в значении «по молчанию», т.е. в 395 дней, следующим запросом изменим эти значения:

    Exec p_updategroomdays SC_AlertFact_Table, 30

    Exec p_updategroomdays SC_AlertHistoryFact_Table, 30

    Exec p_updategroomdays SC_AlertToEventFact_Table, 30

    Exec p_updategroomdays SC_EventFact_Table, 30

    Exec p_updategroomdays SC_EventParameterFact_Table, 30

    Exec p_updategroomdays SC_SampledNumericDataFact_Table, 30

    image

    После этого можно выполнить повторный запрос к базе данных SystemCenterReporting , чтобы получить текущие значения 'Groom Days' для 6 главных таблиц и убедиться в том, что установлено новое значение в 30 дней.

    Расчет размера файлов баз данных.

    Нам необходимо определиться с размерами баз данных OnePoint и SystemCenterReporting. Для этого можно воспользоваться таблицей ориентировочного расчета из руководства
    Forefront Client Security - Impact on server system resources

    То есть, если придерживаться данного расчета, то для обслуживания около 3000 клиентов на редакции SQL Server Standard, - размер базы OnePoint должен быть не менее  5 Gb а размер базы SystemCenterReporting около 22 Gb при условии хранения данных в базе SystemCenterReporting не более 30 дней.

    Расчет размера файлов логов транзакций.

    Размер лога транзакций базы OnePoint должен быть не менее 1/3 размера самой базы.
    К примеру, если мы установили размер файла базы OnePoint в 5120 Mb, то размер лога транзакций должен быть ориентировочно 1707 Mb. Изменить установленные в процессе развертывания серверных компонент FCS значения можно с помощью SQL Server Management Studio, открыв свойства базы данных OnePoint на закладке Files

    image

    Что нужно знать для расчета размера файла лога транзакция для базы SystemCenterReporting:
    1.
    Задача планировщика задач Windows с именем SystemCenterDTSPackageTask копирует данные из базы OnePoint в базу SystemCenterReporting с возрастом  72 часа и более. Поэтому важно обратить внимание на то, успешно ли это задание отрабатывает.
    2. Лог транзакций базы SystemCenterReporting должен быть не менее чем  в пять раз больше размера файла данных базы OnePoint.  То есть если размер базы OnePoint  5120
    Mb то размер лога транзакций базы SystemCenterReporting должен быть не менее 25600 Mb. Такой большой размер рекомендуется советами бывалых «заводчиков» FCS как исторически устоявшаяся истина. Примем её на веру  J.
    В итоге исходя из ранее взятых нами за пример значений размеров базы и логов OnePoint в размере 5120
    Mb / 1707 Mb соответственно и приведенных выше рекомендаций, - для БД SystemCenterReporting эти значения получатся соответственно  22528 Mb / 25600 Mb.

    Значение размера файла данных БД SystemCenterReporting 22528 Mb получено путём расчета из вышеприведенной таблицы в расчете на 3000 клиентов и 30 дней хранения данных, т.е. (128Gb * 30 дней)/180 дней = 22 Gb или 22528 Mb.
    Значение размера файла лога тразакций БД SystemCenterReporting получено путём вышеописанного расчета, т.е. (5120 Mb * 5) = 25600 Mb

    image

    Данный пост размещен как вольный перевод статьи  FCS with MOM 2005 Database Guidance .
    В оригинальной статье можно найти дополнительную информацию о том, как делать
    shrink large Databases, в случае если мы всё-таки по какой-то причине вышли за рассчитанные пределы размеров баз данных FCS.

  • Развертывание и конфигурирование клиентских компонент Forefront Client Security с помощью GPO

    В предыдущем посте Установка серверных компонент Microsoft Forefront Client Security на Windows Server 2008 (в топологии с одним сервером) мы выполнили установку серверных компонент Forefront Client Security (FCS). Настало время произвести настройку сервера FCS и выполнить развертывание клиентов.

    При первом запуске консоли FCS будет запущен мастер настройки подключения консоли к серверным компонентам. Последовательно пройдём все шаги мастера и укажем все необходимые данные, которые ранее были нами использованы в процессе установки серверных компонент FCS. Указанные данные при необходимости можно будет изменить в любой момент, вызвав в меню консоли Action > Configure.

    image

    После того как работа мастера первоначальной настройки завершена, мы получим доступ к текущей статистике о состоянии антивирусной защиты на закладке Dashboard.
    Теперь нам нужно создать и настроить политику настройки клиентов FCS. Для этого в консоли FCS переходим на закладку Policy Management и создаем новую политику (New Policy). В своем примере я рассматриваю вариант с созданием и применением одной политики на всех клиентов FCS, однако, реальное количество применяемых политик в вашей среде может быть больше и зависеть от разных факторов.
    Подробно останавливаться на настройке создаваемой нами политики мы не будем, так как интерфейс свойств политики достаточно интуитивно понятен. Подробное описание параметров политик можно найти в официальной технической документации на русском языке: Microsoft Forefront Client Security - Планирование политик.
    Замечу, однако, то, что сразу стоит уделить внимание настройке исключений файлов, папок и расширений файлов, которые не должны подвергаться антивирусному сканированию, чтобы после развертывания клиентов и применении данной политики не получить проблем с доступностью и производительностью приложений. Рекомендации по настройке исключений опубликованы ранее в посте Настройка исключений для антивирусного ПО.

    image

    Так же рекомендую включить удаление устаревших файлов из карантина на клиентах по истечению определенного периода в днях (максимально возможное значение 100 дней).
    Возможно, вы не захотите, чтобы все ваши клиентские компьютеры не участвовали в программе SpyNet и не отправляли информацию в Microsoft, в таком случае выполните соответствующий выбор на закладке Reporting свойств политики.

    image

    После того как мы закончили настройку нашей политики, мы должны определиться с тем на какую совокупность компьютеров мы хотим установить клиентскую часть FCS и сконфигурировать их нашей политикой. Так как основным способом распространения и настройки клиента является применение объектов доменных групповых политик (GPO), мы специально создадим в домене отдельную групповую политику для этой задачи (рекомендую не использовать уже существующие продуктивные GPO а именно создать новую отдельную политику и отказаться от её дальнейшего редактирования в ручную).
    Для создания политики используем консоль Group Policy Management установленную на нашем сервере в процессе развертывания серверных компонент FCS.
    Если в компании используется антивирусное ПО разных вендоров, и нам необходимо ограничить круг применения данной групповой политики на определенную совокупность компьютеров, то мы можем сделать это разными путями. Например, можно прилинковать созданную GPO к конкретному контейнеру (OU) в домене или создать специальную доменную группу безопасности и ограничить действие политики только на членов этой группы.
    По умолчанию, новая созданная нами групповая политика имеет фильтрацию безопасности, нацеленную на группу Authenticated Users .

    Удалим группу Authenticated Users и добавим специально созданную нами доменную группу безопасности, в которую включены все компьютеры, на которые мы желаем развернуть клиентскую часть FCS.

    image

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

    Теперь привязываем созданную групповую политику к OU в которых расположены компьютеры домена, входящие в специальную доменную группу безопасности (в нашем случае это группа KOM-AD01-GPO-ForefrontCS-Computers).
    Далее мы можем выполнить развертывание ранее настроенной нами в консоли FCS политики с помощью данной GPO. Для этого открываем консоль FCS, на закладке Policy Management выбираем созданную нами ранее политику и в контекстном меню выбираем пункт Deploy

    image

    В открывшемся окне выбираем специально созданную ранее нами групповую политику кнопкой Add GPO и после этого нажимаем кнопку Deploy

    image

    После этого будет инициирован процесс внесения соответствующих изменений в заданную нами групповую политику. Изменения можно будет увидеть в оснастке Group Policy Management

    image

    Теперь после очередного цикла применения доменных групповых политик на компьютерах будет применена наша специализированная групповая политика и инициирована установка клиентского ПО Forefront Client Security с сервера WSUS. Можно ускорить этот процесс, последовательно выполнив на клиентском компьютере команды:

    gpupdate /force (форсированное применение доменных групповых политик)
    wuauclt /detectnow (форсированное обращение на сервер WSUS для получения клиентских компонент FCS)

    После этого на клиентском компьютере будет предложено произвести установку

    После установки клиентских компонент компьютер появится на консоли сервера FCS. Но это может произойти далеко не сразу и чтобы ускорить этот процесс , на сервере FCS мы можем открыть административную консоль MOM 2005 (Administrator Console) и выполнить одобрение (Approve) клиентов.

    image

    После форсированной процедуры одобрения информация о клиенте появится уже на консоли сервера FCS.
    Результат применения клиентских политик можно будет увидеть в интерфейсе клиентской части FCS. Централизованно настроенные параметры будут не доступны для редактирования обычным пользователям

    image

    Далее нам необходимо настроить наш WSUS сервер на автоматическое одобрение обновлений антивирусных описаний Forefront Client Security. Для этого откроем консоль сервера WSUS и создадим правило авто-одобрения (Options > Automatic Approvals)

    image

    Создаваемое нами правило будет автоматически одобрять все новые описания для продуктов Forefront Client Security и Windows Defender

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

    Теперь наши клиенты Forefront Client Security развернуты, сконфигурированы и будут автоматически обновлять антивирусные описания с сервера WSUS.

    Дополнительную информацию можно найти в официальной технической документации:
    Microsoft Forefront Client Security - Развертывание Client Security
    http://technet.microsoft.com/ru-ru/library/bb404255.aspx

  • Установка серверных компонент Microsoft Forefront Client Security на Windows Server 2008 (в топологии с одним сервером)

    Встала задача - развернуть серверные компоненты Microsoft Forefront Client Security в конфигурации с одним сервером под управлением Windows Server 2008 (x86 SP2). После прочтения документации на technet.microsoft.com возникло ощущение что ничего в общем то особо сложного в этом нету, но на практике оказалось что данный процесс таит в себе много «НО»… достаточно для того, чтобы сесть и написать данный Step-by-Step во избежание хождения по граблям при будущих инсталляциях. Ибо дело чтением официальной документации не окончилось…пришлось переворошить массу дополнительных источников информации чтобы справится с поставленной задачей. В общем то для тех кому это ещё предстоит – думаю данный мануал будет полезен. Весь процесс логически разделен на несколько этапов. Итак поехали…

    Читать далее...