Блог IT-KB

System Center DPM 2007 QFE Rollup KB979970 (2.0.8864.0)

06.04.2010 Автор:Алексей Максимов
2 036 Просмотров Комментариев нет

В конце марта появился пакет исправлений для DPM 2007 SP1 - System Center DPM 2007 QFE Rollup (KB979970) который изменяет версию DPM до 2.0.8864.0
Данный пакет по сути является кумулятивным и включает все ранее выпущенные роллапы на DPM 2007 SP1.

Описание: Description of the latest hotfix rollup package for System Center Data Protection Manager 2007: March 29, 2010
URL для скачивания: System Center Data Protection Manager 2007 QFE Rollup

Требования для установки

- Windows Server 2003; Windows Server 2008; Windows Server 2008 R2
- System Center Data Protection Manager 2007 Service Pack 1.
- Сritical update KB962975 (если DPM установлен на Windows Server 2008).

После установки требуется перезагрузка DPM сервера и обновление всех клиентов DPM.
Сделать обновление клиентов DPM можно как с консоли DPM так и вручную (обе процедуры описаны в вышеперечисленных ссылках)
После обновления клиентов DPM также потребуется перезагрузка.

Вообще, после выхода SP1, список внесённых исправлений в DPM 2007 достаточно внушителен, так что наверняка в любом окружении есть смысл произвести обновление.
SCCM & Double UUID

01.04.2010 Автор:Алексей Максимов
6 864 Просмотров 3 комментария

Работа с SCCM продолжает приносить нам сюрпризы. В ходе того как мы начали использовать функционал OS Deployment вскрылись новые подробности.

При очередном развертывании целевой компьютер (HP DX7400) упорно отказывался начинать процесс установки ОС.

Для изучения проблемы пришлось в загружаемом образе WinPE включить возможность отладки, после чего мы получили доступ к логам WinPE клиента и обнаружили что на этапе когда загруженный WinPE клиент обращается на SCCM сервер для получения задания развертывания ОС – происходит коллизия. А именно, SCCM сервер почему то определяет этого клиента как уже существующий в БД SCCM компьютер (совершенно другой но такой же модели - HP DX7400)…Далее путём долгих мытарств выяснилось что эти два компьютера имеют одинаковый аппаратный UUID, который прошит в DMI области BIOS материнской платы на заводе производителе.
Выяснилось что если SCCM находит в своей базе данных совпадающий UUID то он как принимает два разных компьютера за один и тот же…что и является причиной отказа в развертывании… По доступной в интернете информации - дублирующимися UUID отличаются некоторые производители оборудования, дочерние предприятия DELL и HP. Сначала мы попробовали решить эту проблему «софтверно», то есть я открывал кейс в тех.поддержке MS…но как и следовало ожидать их ответ был неутешительным- «Обращайтесь к разработчику оборудования». Пока изучал проблему узнал интересную вещь - в свое время компания Microsoft для получения производителями статуса «Сертифицировано для Microsoft Windows» одним из условий выдвигала наличие у производителя поддержки RFC определяющего наличие и уникальность аппаратного UUID…но как оказалось наши «славянские братья» (если не путаю страна-производитель этих рабочих станций HP была Румыния) забили на все эти глупости )))
Потом была долгая переписка с тех.поддержкой HP…и пока она длилась было найдено обходное решение по сносу с таких компьютеров всех данных BIOS из области DMI. Но при этом из BIOS, как следствие, вытирался не только UUID но и S/N и P/N девайса, что уже само по себе не очень красиво получалось…хотя при желании эти данные можно было вернуть назад с помощью ещё одной немецкой хакерской тулзы … но все эти операции выглядели очень муторно и неудобно...
Совсем недавно наша переписка с инженером HP из !!!Индии!!! закончилась. Мы получили и успешно провели испытания утилиты SMBCFG от Phoenix Technologies. Данная тулза позволяет в режиме MS-DOS выполнить команду по регенерации аппаратного UUID не теряя при этом прочих данных их DMI области BIOS.

Делается это одной командой:

SMBCFG.EXE /UUID

Столкнувшиеся с подобной проблемой могу стянуть утилиту отсюда

PS: Обращаю ваше внимание на то что корректность работы утилиты проверена только на рабочих станциях HP DX7400 (Bios AWARD-Phoenix)
Exchange Server 2007 How-to: Перемещение файлов групп хранения и баз данных в кластере CCR

28.03.2010 Автор:Алексей Максимов
6 184 Просмотров Комментариев нет

Иногда может потребоваться выполнить перемещение расположения файлов групп хранения (Storage Group) и/или файлов баз данных (Database) на сервере Exchange Server 2007 с ролью Mailbox Server. Если сервер не является нодой CCR кластера, то сделать это можно стандартным способом через UI консоли Exchange Management Console

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

Для выполнения нашей задачи мы должны выполнить следующую последовательность действий:

1) Остановить репликацию группы хранения. Сделать это можно в Exchange Management Console через меню Actions – Suspend Storage Group Copy или же в Exchange Management Shell командой:

Suspend-StorageGroupCopy –Identity "CCRClusterStorageGroup" -SuspendComment "Moving files to new location" -Verbose

2) Размонтировать нашу базу данных. Сделать это можно в Exchange Management Console через меню Actions – Dismount Database или же в Exchange Management Shell командой:

Dismount-Database -Identity "CCRClusterStorageGroupDatabase" –Verbose

3) На обеих нодах CCR кластера в ручную копируем файлы в новое расположение (разумеется на обеих нодах путь к файлам должен быть идентичным).

4) Обновляем информацию о расположении файлов в Exchange Management Shell командой:
для файлов базы данных:

move-DatabasePath -Identity “CCRClusterStorageGroupDatabase” –ConfigurationOnly -EdbFilePath “R:NEW_DB_FOLDERDatabase.edb”

для файлов группы хранения:

move-StorageGroupPath -Identity “CCRClusterStorageGroup” -ConfigurationOnly -LogFolderPath “R:NEW_SG_FOLDER” -SystemFolderPath “R:NEW_SG_FOLDER”

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

Get-StorageGroupCopyStatus

Также обратите внимание на то, что если резервное копирование данных Exchange выполняется с помощью Data Protection Manager, то после перемещения файлов баз данных или групп хранения потребуется удалить старые сведения из Protection Group DPM и создать источник резервного копирования заново.

Дополнительная информация:

Exchange Server TechCenter - How to Move a Database in a CCR Environment
Exchange Server TechCenter - How to Move a Storage Group and Its Database in a CCR Environment
Microsoft Terminal Services - Практика использования Easy Print

02.03.2010 Автор:Алексей Максимов
38 639 Просмотров 23 комментария
Минимальные требования для клиентских ПК для использования универсального драйвера печати Easy Print таковы:
- Microsoft Windows XP SP3, Microsoft Windows Vista SP1, Microsoft Windows 7
- Средство подключения к удаленному рабочему столу (RDP Client) версии не ниже 6.1 (6.0.6001)
  Этот компонент распространяется в составе SP3 для Windows XP и SP1 для Windows Vista
- Microsoft .NET Framework 3.0 с пакетом обновления 1 (SP1) (можно использовать Microsoft .NET Framework 3.5)
  Распространяется через WSUS, хотя может быть установлен и вручную.
Далее...при подключении клиента к серверу в свойствах RDP клиента на закладке "Локальные ресурсы" должно быть включено перенаправление принтеров.

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

Поведение системы печати служб терминалов Windows Server 2008 по умолчанию предполагает использование драйвера Easy Print для всех клиентских принтеров.

Практика показала что не во всех случаях драйвер Easy Print работает корректно (например при некоторых сценариях съезжают поля при печати документов или вовсе не печатаются некоторые печатные формы из 1С). Для решения этой проблемы на наших терминальных серверах мы изменили настройки системы печати по умолчанию на следующий режим работы: при подключении клиента к серверу служба печати сначала пытается найти родной драйвер для каждого принтера клиента, если находит - использует его, если не находит использует для этого принтера драйвер Easy Print.

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

Разрешение проблем в работе Easy Print на Windows Server 2008 / 2008 R2

В случае проблем с перенаправлением принтеров клиента в терминальную сессию с помощью Easy Print необходимо выполнить нижеописанный ряд проверок:
- Проверяем есть ли на клиентском компьютере требуемая для работы Easy Print версия .NET framework.
- Проверяем на клиенте то, что в свойствах запускаемого RDC клиента (mstsc.exe) включена опция перенаправления принтеров клиента на закладке "Локальные ресурсы". Если вместо клиента мы запускаем настроенный RDP ярлык то открываем его в текстовом редакторе и убеждаемся в том что присутствует опция перенаправления принтеров клиента в виде строки: redirectprinters:i:1
- Проверяем свойства доменной учетной записи пользователя. Как было отмечено ранее, в свойствах учётной записи пользователя в домене (Закладка "Среда") должны быть включены опции "Подключение принтеров при входе" и "По умолчанию выбрать основной принтер клиента".
- Проверяем как сконфигурированы групповые политики влияющие на Easy Print на терминальном сервере. Соответствующий раздел GPO можно найти по пути: Computer Configuration -> Administrative templates -Windows Components -> Remote Desktop Services > Remote Desktop Session Host -> Printer Redirection.
  Опция "Use Remote Desktop Easy Print printer driver first" должна быть включена для работы редиректа принтеров с приоритетным использованием драйвера Easy Print или выключена в том случае если вы хотите использовать специально установленные драйвера принтеров на сервере.
- Проверяем конфигурацию терминального сервера (оснастка "Remote Desktop Configuration Tool" или tsconfig.msc) на предмет того, что опция редиректа “Windows Printer” не отмечена как отключенная.
- Проверяем что и на клиенте и на сервера запущена служба очереди печати (spooler service). Если служба запущена то проверяем корректность установленных прав на данную службу. Ниже приведен пример того как должны выглядеть правильные настройки безопасности службы очереди печати:
  C:>sc sdshow spooler
  D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SY)
  
  Если вывод команды отображения настроек безопасности отличен от указанного, например отсутствуют разрешения в дескрипторе безопасности для “AU” (Authenticated User), то устанавливаем необходимые для корректной работы службы права следующей командой
  
  C:> sc sdset spooler D:(A;;CCLCSWLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SY)
  [SC] SetServiceObjectSecurity SUCCESS
  
  После установки разрешений необходимо перезагрузить компьютер.
- Если подключение клиента производится через RD Gateway проверяем что на сервере RD Gateway выключена опция запрета перенаправления клиентских принтеров.
- Если у клиента большое количество принтеров и они перенаправляются в ограниченном количестве, то стоит обратить внимание на значение ключа реестра MaxPrintersPerSession (REG_DWORD) в ветке HKLMSoftwarePoliciesMicrosoftWindows NTTerminal Services. По умолчанию это значение равно 20 (т.е. не больше 20 принтеров на одну сессию).
Дополнительные ссылки:
- Некорректная печать документов содержащих страницы со смешанной ориентацией.
  Article ID: 954744 - Last Review: November 11, 2008 - Revision: 1.0
  FIX: Some pages are printed in the incorrect orientation when you use Terminal Services Easy Print to print a document that contains both portrait-oriented pages and landscape-oriented pages
  http://support.microsoft.com/kb/954744
- Некорректная печать документов в формате PDF.
  Article ID: 970603 - Last Review: June 22, 2009 - Revision: 1.0
  The content of a printout is different when you print a PDF document by using Terminal Services Easy Print in a Terminal Services (TS) session in Windows Vista or Windows Server 2008
  http://support.microsoft.com/kb/970603
- Некорректная печать полей страниц документов.
  Article ID: 959442 - Last Review: December 23, 2008 - Revision: 1.0
  The edges of a document are truncated when you try to print the document by using Terminal Services Easy Print from a client computer that is running Windows XP SP3, Windows Vista SP1, or Windows Server 2008
  http://support.microsoft.com/kb/959442
- Не работает печать на перенаправленных принтерах если роль терминального сервера установлена на контроллере домена.
  Article ID: 968605 - Last Review: March 4, 2009 - Revision: 1.0
  Terminal Server Easy Print not printing
  http://support.microsoft.com/kb/968605/EN-US
Использованный материал:
Remote Desktop Services (Terminal Services) Team Blog : Using Remote Desktop Easy Print in Windows 7 and Windows Server 2008 R2
Hyper-V Best Practies

27.02.2010 Автор:Алексей Максимов
4 564 Просмотров Комментариев нет

Настраиваем антивирусное ПО

Могу предположить что на физическом хосте Hyper-V имеется антивирус... Если это действительно так, то учитывая рекомендации Microsoft Best Practices и рекомендации бывалых …рекомендую расширить ранее используемый список исключений для реал-тайм сканирования файловой системы и процессов, а именно:
Добавляем исключения по именам процессов:
VMMS.EXE
VMWP.EXE
VMSWP.EXE
Добавляем исключения по типам файлов:
VHD, XML, VSV, ISO, AVHD, VFD
Дополнительную информацию об исключениях можно найти в посте - Настройка исключений для антивирусного ПО

Выбираем тип VHD

Для повышения скорости работы дисковой подсистемы в гостевых ОС (внутри VHD) рекомендуется использовать фиксированный а не динамический объём VHD при настройке VM. В сравнительных тестах публикуемых MS, скорость работы дисковой подсистемы VM на фиксированных дисках в некоторых случаях (например при операциях записи) может увеличиваться на 10 - 15%. Данное утверждение справедливо для первой версии Hyper-V. Во второй версии Hyper-V показатели производительности динамических VHD улучшены, но по моему субъективному мнению, лучше для продуктивных систем всё таки придерживаться использования конфигураций с фиксированными VHD.

Даже не смотря на то что динамический диск всегда можно встроенными средствами Hyper-V преобразовать в фиксированный (а при желании и обратно), при создании новой VM ёмкость диска лучше планировать заранее и сразу создавать диск фиксированного размера.

В случае если VM планируется использовать под ресурсы требовательные к дисковой подсистеме, например файловый сервер, сервер БД SQL и т.п. на этапе создания VM можно аттачить к VM Passthrough диск, т.е. предоставлять виртуальной машине полностью неразмеченный физический HDD хостового сервера Hyper-V. В таком случае VM забирает под себя этот диск полностью и общается с ним непосредственно напрямую на физическом уровне из гостевой системы,
что в свою очередь позволяет достигнуть максимального использования имеющейся производительности физических дисков. Но при этом надо учитывать ряд недостатков такой организации:
- теряется возможность создания мгновенных снимков виртуальной машины (shupshots);
- теряется возможность миграции VM между хостами Hyper-V с использованием технологии Quick-Migratiin;
- последней ложкой дёгтя можно считать то, что как выяснилось - теряется возможность делать горячее резервное копирование всей виртуальной машины в средствами DPM...Выводы делайте сами.

Выбираем виртуальный контроллер для VHD

Продолжая тему дискового вопроса важно сделать правильный выбор виртуального контроллера жёстких дисков в создаваемой VM.
Есть 2 типа IDE и SCSI.
IDE - полностью эмулируемый контроллер и работает с VM через вызовы процесса vmwp.exe, в то время как SCSI контроллер использует для своей работы VMBUS (Virtual Machine BUS) и предоставляет VM более тесную интеграцию с аппаратной частью хоста, т.к. VMBUS работает быстрее и меньше потребляет процессорных мощностей Hyper-V сервера. Вот дополнительная информация к размышлению на эту тему:
Hyper-V: How to get the most from your virtualized disk performance
Hyper-V: SCSI vs IDE - Do you really need an IDE and SCSI drive for best performance?
Hyper-V IDE or SCSI? What’s Performing Better, Faster?
Hyper-V Controllers: IDE or SCSI?
Ограничение вносимое текущей версией Hyper-V заключается в том, что для загрузочного системного диска нельзя использовать SCSI контроллер, - только IDE. Поэтому исходя из представленных реалий предлагается для загрузочного системного диска VM использовать виртуальный HDD созданный на контроллере IDE, а для рабочих данных - HDD на контроллере SCSI.

Настраиваем виртуальные сети

Практически любой сервер на сегодняшний день имеет два и более сетевых контроллеров. Соответственно, по возможности, настоятельно рекомендуется отделять трафик управления хостовой ОС от трафика виртуальных сетей Hyper-V. Для этого мы настраиваем на сервере первый сетевой интерфейс со статическим IP адресом по которому будет доступен сам Hyper-V сервер, назовем в системе этот интерфейс например NIC1. Соответственно второй интерфейс назовем - NIC2 и при развертывании роли Hyper-V именно этот сетевой интерфейс укажем для использования создаваемого виртуального свитча Hyper-V.
После установки роли Hyper-V в хостовой системе появится дополнительный сетевой интерфейс (его имя будет соответствовать имени виртуальной сети в Hyper-V) и этот интерфейс можно отключить. Также необходимо убедится в том что на интерфейсе NIC2 отключены все протоколы, кроме Microsoft Virtual Network Switch Protocol.

Hyper-V и его Time Synchronization Provider

Если вы натолкнулись на проблему рассинхронизации времени на виртуальных машинах работающих под управлением Hyper-V то самое время задуматься о том как устроена служба синхронизации времени физического хоста Hyper-V с его виртуальными машинами.

Давайте себе представим следующую ситуацию:
Есть физический хост с Hyper-V и он является членом домена.
Внутри этого хоста поднят виртуальный сервер который несёт в этом домене роль Контроллера домена (DC).

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

Собственно говоря, проблема может наблюдаться в случаях когда виртуальный DC проводит синхронизацию с внешними источниками а затем Hyper-V насильно заменяет это время на то значение которое в момент синхронизации гипервизор имеет на физическом хосте... по факту в таких случаях рассинхронизация времени на DC может получить хронический характер и привести к сбоям в работе служб AD.
В данном случае решением проблемы рассинхронизации времени может быть остановка службы синхронизации времени Hyper-V установленной на виртуальном DC в составе служб интеграции.
Именно поэтому в процессе развёртывания виртуальных машин и компонент интеграции Hyper-V важно уделить этому нюансу должное внимание.
В одном блоге как раз нашёл такую вот занятную историю из жизни - Hyper-V и синхронизация времени
Active Directory Certificate Services - Увеличение срока действия выдаваемых сертификатов

25.02.2010 Автор:Алексей Максимов
8 532 Просмотров 2 комментария

По умолчанию Центр сертификации служб Active Directory Certificate Services (AD CS) при создании новых сертификатов ограничивает срок действия этих сертификатов одним годом. Чтобы увеличить срок действия вновь выдаваемых CA сертификатов необходимо изменить настройки службы сертификации в системном реестре:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>

Значение параметра ValidityPeriod (по умолчанию Years) определяет единицы измерения времени, а значение параметра ValidityPeriodUnits (по умолчанию 1) определяет количество единиц времени для вновь выдаваемых сертификатов. Если изменить значение параметра ValidityPeriodUnits например на 10, то соответственно все вновь выдаваемые сертификаты будут действовать 10 лет.

После внесения изменений в реестр следует перезапустить службу сертификации командами:

net stop certsvc
net start certsvc

Данное справедливо для версий служб сертификации ОС Windows Server 2000 - 2022

Источник: Microsoft KB254632: How to change the expiration date of certificates that are issued by a Windows Server 2003 or a Windows 2000 Server Certificate Authority
Microsoft Data Protection Manager 2007 – Работа с ленточными накопителями

23.02.2010 Автор:Алексей Максимов
2 566 Просмотров Комментариев нет

Включение функции оптимизации (Colocation) при записи на ленту

По умолчанию DPM при работе с ленточными накопителями использует один носитель для каждой отдельной Protection Group, что не всегда оправдано, особенно если групп много и они имеют небольшой размер. В таких случаях на сервере DPM можно включить механизм Colocation с помощью команды Powershell:

Set-DPMGlobalProperty -DPMServerName DPMSERVER.Domain.com -OptimizeTapeUsage $True

Источник: System Center Data Protection Manager TechCenter - Setting Up Data Colocation

Шторм сообщений Free tape threshold reached (3305)

При использовании DPM 2007 в связке ленточными библиотеками может возникнуть ситуация когда в процессе выполнения задания резервного копирования движок DPM определяет то, что количество носителей, доступных для записи (имеющих статус Free) стало 20% и меньше. В такой ситуации DPM начинает с жуткой силой штормить алертами (на моей практике это было более 5000 сообщений за ночь). Корень этой проблемы кроется в том, что на ленточной библиотеке носители (кассеты с плёнкой) со статусом Expired автоматически не помечаются как Free...что рано или поздно приводит к исчерпанию доступных для записи накопителей. Поэтому задачу перевода накопителей из статуса Expired в статус Free мы автоматизируем средствами PowerShell.
Создадим на нашем DPM сервере имеющем подключение к проблемной ленточной библиотеке каталог C:Tools. В каталоге разместим три текстовых файла:

DPM_MarkExpiredTapesAsFree.ps1 - PowerShell скрипт выполняющий поставленную перед нами задачу
DPM_MarkExpiredTapesAsFree.cmd - Командный файл для запуска скрипта средствами Windows Task Scheduler
DPM_MarkExpiredTapesAsFree.log - Файл для записи вывода результата работы скрипта

Ссылка на скрипт: DPM_MarkExpiredTapesAsFree.zip

Командный файл DPM_MarkExpiredTapesAsFree.cmd представляет собой обычный текстовый файл с вызовом нашего скрипта:

powershell -command "& 'C:ToolsDPM_MarkExpiredTapesAsFree.ps1' DPM-SERVER" > C:ToolsDPM_MarkExpiredTapesAsFree.log

В качестве параметра DPM-SERVER используется имя DPM сервера, а также указывается вывод результата работы в текстовый лог.

После того как мы создадим задание в планировщике задач Windows Task Scheduler с исполнением командного файла DPM_MarkExpiredTapesAsFree.cmd к примеру раз в сутки - мы избавимся от вышеописанной проблемы.

Источник: Matthijs Blog: Script to resolve: Free tape threshold reached
Microsoft Data Protection Manager 2007 – Работа с Агентом

23.02.2010 Автор:Алексей Максимов
2 708 Просмотров 1 Комментарий

Установка агента DPM 2007 SP1 на сервер с включенной службой Windows Firewall

Последовательность действий:

1) На клиенте подключаем диск с сервера DPM и ставим с него клиента вручную:

net use X: \DPMSERVERC$
cd /d X:DPM2007_BinDPMAgentsRA2.0.8793.0amd641033
DPMAgentInstaller_KB959605_AMD64.exe DPMSERVER.Domain.com

При запуске инсталлятора, как видите, в качестве параметра передаем имя DPM сервера. После установки клиента перегружаем клиентский сервер.

2) После того как клиент поднялся из перезагрузки на DPM сервере открываем DPM Management Shell и выполняем команду присоединения клиента:

PS E:DPM2007_BinDPMbin> Attach-ProductionServer.ps1 DPMSERVER.Domain.com DPMCLIENT.Domain.com AdminUserName
Password:: **********
Domain:: Domain.com
Attached ProductionServer successfully

На клиенте проверяем чтобы в процессе установки инсталлятором в правила Windows Firewall было вписано правило dpmra, которое разрешает любую сетевую активность клиентскому приложению. Если правило по какой-то причине не создано, можем добавить его руками примерно так:

> Netsh firewall add allowedprogram "C:Program FilesMicrosoft Data Protection ManagerDPMbinDPMRA.exe" DPMRA

3) Заходим на консоль DPM сервера и проверяем то что клиент доступен.

Первоисточник: http://technet.microsoft.com/en-us/library/bb870937.aspx

Перенацеливание агента DPM на другой сервер без переустановки агентского ПО

Операция перенацеливания состоит из трёх действий:

1. На сервере DPM с которого нужно отключить агента - исключаем нашего клиента из всех Protection Group.
2. На клиенте из каталога установки клиентского ПО (%ProgramFiles%Microsoft Data Protection ManagerDPMbin) выполняем команду:

SetDpmServer.exe -dpmServerName NEWDPMSERVER.Domain.com
Configuring dpm server settings and firewall settings for dpm server =[NEWDPMSERVER.Domain.com]
Configuring dpm server settings and firewall settings for dpm server =[Domain.comNEWDPMSERVER]
Configuration completed successfully!!!

3. На сервере NEWDPMSERVER открываем DPM Management Shell (Powershell) и выполняем команду:

PS E:DPM2007_BinDPMbin> Attach-ProductionServer.ps1 NEWDPMSERVER.Domain.com DPMCLIENT.Domain.com AdminUserName
Password:: ********************
Domain:: Domain.com
Attached ProductionServer successfully
Microsoft Data Protection Manager 2007 – Установка на Windows Server 2008

23.02.2010 Автор:Алексей Максимов
3 117 Просмотров Комментариев нет

Перед развертыванием сервера DPM 2007 SP1 на ОС Windows Server 2008 необходимо выполнить определенные шаги:

1) Установить в ОС фичу Single Instance Store (SIS).
Запускаем командную строку с правами администратора сервера и выполняем команду:

start /wait ocsetup.exe SIS-Limited /quiet /norestart

После того как команда отработала необходимо выполнить перезагрузку сервера.

2) Включить фичу Windows PowerShell 1.0
Это можно сделать через оснастку "Диспетчер сервера" или командой:

ServerManagerCmd -i PowerShell

3) Включить роль сервера "Вэб-сервер" с обязательным наличием следующих компонент:

Web Server

Common HTTP Features
- Static Content
- Default Document
- Directory Browsing
- HTTP Errors
- HTTP Redirection

Application Development
- ASP.NET
- .NET Extensibility
- ISAPI Extensions
- ISAPI Filters
- Server Side Includes

Health and Diagnostics
- HTTP Logging
- Request Monitor

Security
- Windows Authentication
- Request Filtering

Performance
- Static Content Compression

Management Tools
IIS Management Console
IIS Management Scripts and Tools
IIS 6 Management Compatibility
- IIS 6 Metabase Compatibility
- IIS 6 WMI Compatibility

В случае недоустановки какой-то из указанных компонент IIS в процессе установки сервера DPM могут возникнуть ошибки приводящие к неудачному завершению установки.

В том случае если процесс установки сервера DPM 2007 SP1 затягивается на очень долгое время на этапе установки SQL Server 2005, возможное решение описано в посте:
Разрешение проблем возникающих при установке и настройке Microsoft SQL Server 2005 на Windows Server 2008
Там же описана проблема когда после установки SP3 на SQL Server может потеряться доступность вэбузла SQL 2005 Reporting Service и как следствие в консоли сервера DPM перестает работать закладка Reporting

Дополнительная информация:
System Center Data Protection Manager TechCenter: DPM Server Software Prerequisites
Установка и первоначальная настройка Microsoft Forefront Protection 2010 for Exchange Server на Exchange Server 2007 с ролью Hub-Transport в среде Windows Server 2008

20.02.2010 Автор:Алексей Максимов
6 047 Просмотров Комментариев нет
Аппаратные требования

· Компьютер на основе архитектуры 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. Рекомендуется использовать автоматическое переписывание старых записей в журнале, то есть настройки журнала должны выглядеть примерно так:

Если используется 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 я получил такое сообщение:

Это означало, что требуется внесение изменений в 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

Подобная процедура подготовки должна выполнятся для каждого сервера на который будет производится установка 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

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

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

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

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

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

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

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

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

Чтобы проверить правильность установки FPE и включение защиты по умолчанию посмотрим в диспетчер задач на предмет наличия запущенных процессов:
Так же необходимо удостоверится в том, что в планировщике задач успешно создалась задача по обновлению модулей 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 все дочерние домены следует указывать отдельно.

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

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

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

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

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

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

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

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

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

Netsh winhttp show proxy

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

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

В дальнейшем при необходимости для сброса параметров 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 должно начать проходить успешно.

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

Чтобы не выполнять скачивание обновлений из интернета на каждый сервер 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)

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

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

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

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

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

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

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

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