• Microsoft Data Protection Manager 2007 – Работа с ленточными накопителями

    Включение функции оптимизации (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 – Работа с Агентом

    Установка агента 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

    Перед развертыванием сервера 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

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

    · Компьютер на основе архитектуры 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

  • Создание привязки иконок приложений для новых типов файлов в библиотеках документов SharePoint Server 2007

    При добавлении в библиотеку документов SharePoint файлов имеющих расширения незарегистрированных в SP типов - визуальное представление таких документов выглядит в форме белого листа. Если к примеру мы хотим зарегистрировать два новых типа файлов, сделать это можно так:
    На фронт-энд сервере SharePoint в каталог

    C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEIMAGES
    добавляем файлы с изображением нужных нам иконок в формате gif размером 16x16. Пускай к примеру в нашем случае это ICPS1.gif (файлы скриптов PowerShell) и ICPDF.GIF (файлы Adobe PDF)
    Далее в файле

    C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEXMLDOCICON.XML

    делаем следующие изменения в соответствующей секции:
    <DocIcons>
        <ByExtension>
            <Mapping Key="pdf" Value="ICPDF.GIF"/>
            <Mapping Key="ps1" Value="ICPS1.gif"/>       
         </ByExtension>
    </DocIcons
    >

    Затем перегружаем IIS командой

    iisreset /noforce

    и открыв представление библиотеки документов с файлами типа *.pdf и *.ps1 любуемся результатом ))

  • Добавление иконки Favicon на узел SharePoint 2007

    Для внедрения иконки Favicon в SharePoint нам нужно будет выполнить незначительную модификацию шаблона главной страницы Master Page на фронт-энд сервере SharePoint.

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

    На фронт-энд сервере MOSS помещаем наш кастомный файл Favicon.ico в каталог

    C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEIMAGES
    В Master Page вносим изменение - в заголовке страницы в конце секции <head></head> вносим строчки со ссылкой на нашу иконку:

    <link rel="shortcut icon" href="/_layouts/images/favicon.ico" />
    <link rel="icon" type="image/gif" href="/_layouts/images/animated_favicon.gif">

    В браузере рефрешим страницу и проверяем результат.
  • Интеграция обновлений в дистрибутив SharePoint Server 2007

    Рассмотрим пример процесса создания дистрибутива SharePoint Server 2007 с интегрированным пакетом обновлений и кумулятивным обновлением.

    1) Скачиваем оригинальный дистрибутивный пакет финальной версии SW_DVD5_Office_SharePoint_Server_2007_64Bit_English_-2_1_PA_BP_ISO_Onl_X13-38819.ISO

    Распаковываем в оригинальный дистрибутив в каталог Install

    2) Скачиваем пакет исправлений Windows SharePoint Services 3.0 Service Pack 2 (x64), распаковываем его в каталог Install в подкаталог Updates

    wssv3sp2-kb953338-x64-fullfile-en-us.exe /extract:"C:InstallUpdates"
    3) Скачиваем пакет Windows SharePoint Services 3.0 April cumulative update package (x64), распаковываем его в каталог Install в подкаталог Updates
    wss-kb968850-fullfile-x64-glb.exe /extract:"C:InstallUpdates"
    4) Скачиваем пакет Microsoft Office servers 2007 Service Pack 2 (x64), распаковываем его в каталог Install в подкаталог Updates

    officeserver2007sp2-kb953334-x64-fullfile-en-us.exe /extract:"C:InstallUpdates"

    5) Скачиваем пакет Office SharePoint Server 2007 April cumulative update package (x64), распаковываем его в каталог Install в подкаталог Updates

    office-kb968851-fullfile-x64-glb.exe /extract:"C:InstallUpdates"
    Примечание В силу того что мы используем не WSS а SharePoint Server, надо удалить из каталога Updates файл wsssetup.dll, чтобы в процессе установки обновлений не возникло конфликтов с файлом svrsetup.dll
    Дистрибутив готов.
    Создаем из папки Install образ диска ISO

    Перед установкой SharePoint с применением встроенных обновлений необходимо выключить Windows Firewall

    Дополнительная информация:
    April Cumulative Update Packages Ready for Download
    How to create a SharePoint slipstream using the latest updates
  • Настройка IIS 7.0 на Windows Server 2008 для выполнения кода Silverlight 2.0 в ферме серверов SharePoint 2007

    Прежде всего устанавливаем в систему пакет Microsoft .NET Framework 3.5 Service Pack 1. После установки пакета .NET Framework 3.5 с пакетом обновления 1 необходимо сразу установить обновление KB959209, чтобы устранить ряд известных проблем совместимости приложений
    Если у вас работает WSUS то обновление KB959209 должно само прикатиться на сервер с WSUS сразу после установки .NET Framework 3.5 Service Pack 1.
     
    Далее проверяем настройки MIME типов на IIS 7.0. Для исполнения Silverlight должен быть разрешён тип application/x-silverlight-app с расширением файлов .xap
     
    Следующий шаг - регистрация библиотеки System.Web.Silverlight.dll в кэше глобальных сборок (GAC)
    Во первых для того чтобы получить саму библиотеку нам нужно скачать с MS пакет Microsoft Silverlight 2 Software Development Kit. Проблемы  в этом нет, так как на сайте Microsoft этот пакет находится в свободном для скачивания доступе.
    После скачивания устанавливаем данный пакет на сервере где работает наш IIS. После установки находим нужную нам библиотеку System.Web.Silverlight.dll в каталоге C:Program Files (x86)Microsoft SDKsSilverlightv2.0LibrariesServer
    Зарегистрировать библиотеку в GAC можно несколькими путями. Опишу 2 основных:
    • Первый и самый простой способ - через проводник Windows производим операцию копирования файла из каталога C:Program Files (x86)Microsoft SDKsSilverlightv2.0LibrariesServer в каталог C:Windowsassembly
      Если на сервере включена функция контроля UAC - для выполнения данной операции её придётся на время отключить в противном случае система нам просто не даст скопировать файл в каталог C:Windowsassembly,
      т.е. отключаем UAC > перезагружаем сервер > копируем через Проводник Windows библиотеку в C:Windowsassembly (GAC) >  включаем UAC > перезагружаем сервер.
    • Второй способ более изящный но более сложный, т.к. для его реализации нам понадобится утилита Global Assembly Cache Tool (Gacutil.exe) которую найти можно либо в составе пакета Microsoft Visual Studio либо в составе пакета NET Framework Software Development Kit (SDK)
      после того как мы нашли данную утилиту установка библиотеки System.Web.Silverlight.dll в GAC может быть выполнена без манипуляций с отключенем UAC следующей командой

      Gacutil.exe /i  "C:Program Files (x86)Microsoft SDKsSilverlightv2.0LibrariesServerSystem.Web.Silverlight.dll"

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

    Теперь мы можем размещать в нашей ферме SharePoint контент Silverlight 2.0, т.е. можем кидать на страницы портала вэб-части с использованием Silverlight. Надо понимать, что если в ферме несколько вэб-серверов, то вышеописанные действия нужно выполнить на всех этих серверах.

  • Разрешение проблем возникающих при установке и настройке Microsoft SQL Server 2005 на Windows Server 2008

    Перечень проблем, возникающих при установке и первоначальной настройке MS SQL Server 2005 на Windows Server 2008, которые встречались на моей практике чаще всего:

    • При установке SQL Server 2005 нет возможности установить Report Services (в мастере установки недоступна опция) либо не устанавливаются клиентские компоненты и прочие дополнительные модули
    • Остановка процесса установки MS SQL Server 2005 на стадии Setting File Security
    • Нет возможности установить Report Services т.к. в программе установки включение этой опции недоступно.
    • После установки SQL Server 2005 отказывается стартовать служба полнотекстового поиска - SQL Server FullText Search
    • После установки SP3 для SQL Server 2005 служба SQL Server Reporting Services не стартует с описанием ошибки об истечении таймаута запуска 
    • После установки SP3 на SQL Server может потеряться доступность вэбузла SQL 2005 Reporting Service

    При установке SQL Server 2005 нет возможности установить Report Services (в мастере установки недоступна опция) либо не устанавливаются клиентские компоненты и прочие дополнительные модули

    Сценарий с которыми приходилось сталкиваться:

    В мастере установки SQL Server 2005 отмечаются для установки клиентские модули и утилиты управления и настройки, в том числе SQL Server Management Studio, но после окончания установки эти модули в системе отсутствуют.

    Причина и решение проблем:

    Вероятнее всего установка производится с архивного носителя (не с оригинального инсталляционного CD).
    К примеру в архивной поставке RTM версия SQL Server 2005 x64 English Standard Edition мы имеем два архива:

    SW_CD_SQL_Svr_Standard_Edtn_2005_64Bit_X64_English_1_x64_MLF_X11-57664.EXE
    SW_CD_SQL_Svr_Standard_Edtn_2005_64Bit_X64_English_2_x64_MLF_X11-57665.EXE

    В первом архиве находятся файлы необходимые для установки самого движка SQL Server, а во втором всевозможные к нему добавы типа Report Services, SQL Server Management Studio и т.п...
    Так вот архитектура инсталлятора SQL Server подразумевает то, что эти два архива перед установкой будут распакованы в соответствующие каталоги с конкретными именами: Servers и Tools
    И при этом ещё эти каталоги должны находиться вместе в одном каталоге. Только в таком случае можно будет гарантировать успешный и правильный исход программы установки.
    Кажется полным бредом...но тем не менее это факт проверенный на практике.

    Остановка процесса установки MS SQL Server 2005 на стадии Setting File Security

    При попытке установить MS SQL Server 2005 x64 на Windows Server 2008 Standard x64 столкнулся с проблемой - программа установки "замерзает" на шаге "Setting File Security"

    image

    В этот момент статусном логе установки можно наблюдать последние записи что-то типа:
     
    <EndFunc Name='SetCAContext' Return='T' GetLastError='203'>
    Doing Action: Write_sqlRegSDDL
    PerfTime Start: Write_sqlRegSDDL : Tue Feb 24 15:00:07 2009

    Как оказалось эта проблема связана с тем что для текущего домена в котором выполняется установка существуют
    доверительные отношения с другими доменами и в некоторых случаях процесс установки из-за этого может затягиваться более чем на сутки
    на стадии "Setting File Security". В общем-то проблема описана в статье
    MS KB 910070
    Таже приводится весьма  замороченный способ исправления проблемы с манипуляциями по пропатчиванию msi пакетов программ инсталляции SQL Server 2005.
    Бойцами невидимого фронта опытным путём было выяснено что в момент “замерзания” программы установки достаточно выключить сетевой интерфейс чтобы имитировать пропадание сетевого подключения, после чего (у меня получилось примерно 10 минут) программа установки как ни в чём не бывало продолжит свою работу.
     
    Бойцы невидимого фронта:

    Нет возможности установить Report Services т.к. в программе установки включение этой опции недоступно

    Как известно компонент Microsoft SQL Server 2005 - Report Services требует наличие прeдустановленных служб IIS.
    При включении роли Вэб-сервер (IIS) на Windows Server 2008 в дефолтной конфигурации компонент Report Services не будет доступен для установки.
    Лечится это так - в настройке ролей сервера в разделе IIS добавить компоненты - IIS 6 Management Compatibility - Совместимость управления IIS 6.
    Об этом описано в статье
    MS KB 938245 - How to install and how to configure SQL Server 2005 Reporting Services on a computer that is running Windows Server 2008

    Также дополнительную информацию по этому вопросу можно найти в стаптье из SQL Server 2005 Books Online (November 2008) - How to: Install and Configure Reporting Services on Windows Server 2008

    После обновления роли IIS перезагружаем сервер. После ребута установка Report Services станет доступной.

    После установки SQL Server 2005 отказывается стартовать служба полнотекстового поиска - SQL Server FullText Search

    После установки SQL Server 2005 отказывается стартовать служба полнотекстового поиска - SQL Server FullText Search и в журнале System при старте этой службы регистрируется ошибка с кодом Event ID 7003 (источник - Service Control Manager Eventlog Provider)
    и содержанием:

    The SQL Server FullText Search (MSSQLSERVER) service depends the following service: NTLMSSP. This service might not be installed.

    Проблема имеет два решения:

    1) В системном реестре отключить зависимость от службы NTLMSSP: Найти в системном реестре ключ HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesmsftesqlDependOnService
    Удалить из значения ключа параметр "NTLMSSP" и перезагрузить сервер.

    2) Более простое и правильное - после установки SQL Server 2005 установить c WSUS пакет исправлений SP2 (или более новый).

    После установки SP3 для SQL server 2005 cлужба SQL Server Reporting Services не стартует с описанием ошибки об истечении таймаута запуска

    Замечено что после установки SP3 на SQL Server 2005 может перестать автоматически стартовать служба SQL Server Reporting Services, а при попытке стартовать службу вручную мы получим ошибку с описанием типа "Error 1053: The Service did not respond to start or control request in a timely fashion".

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

    В системном реестре находим ветку  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
    Создаем в ней параметр DWORD с именем ServicesPipeTimeout и значением 60000 (Десятичное значение)
    Перезагружаем компьютер и убеждаемся в то что проблемная служба успешно стартовала.

    Обращаю ваше внимание на то что значение параметра указывается в миллисекундах и влияет на запуск всех служб в ОС.
    Источник: Microsoft KB824344 How to debug Windows services

    После установки SP3 на SQL Server может потеряться доступность вэбузла SQL 2005 Reporting Service

    Данная проблема связана с тем что при установке SP3 на SQL Server 2005 в свойствах вэб узла SQL 2005 Reporting Service слетают настройки безопасности.
    Для решения проблемы в консоли Internet Information Services (IIS) Manager раскроем Default Web Site и в нем найдем ReportServer. Выберем Handler Mappings.

    image

    Выбираем справа Edit Feature permissions и включаем права на Script и Execute.

    image

  • Установка SP2 на CCR кластер Exchange Server 2007 SP1 в среде Windows Server 2008

    Рассмотрим установку пакета обновлений SP2 на кластерный экземпляр CCR Exchange Server 2007 SP1 под управлением ОС Windows Server 2008 x64 SP2.
    В моём примере в качестве нод кластера будут выступать два сервера с именами KOM-TCSO-CM01 и KOM-TCSO-CM02 (активная и пассивная ноды соответственно), имя CCR кластера - KOM-TCSO-MAIL

    Технически процесс установки SP2 на кластерный экземпляр CCR Exchange Server 2007 SP1 состоит из трёх основных этапов:

    • Обновление первого (пассивного) узла кластера;
    • Остановка CCR кластера, перемещение кластера на обновлённый узел и обновление самого кластера.
    • Обновление второго узла кластера

    Рассмотрим более подробно все три этапа.

    Этап #0. Подготовительные процедуры

    Перечисленные ниже процедуры рекомендуемы к выполнению на обоих узлах кластера непосредственно перед запуском программы установки SP2:

    • Останавливаем все службы, которые используют открытые дескрипторы счетчиков производительности.
      К общеизвестным службам, которые надо остановить, относятся служба журналов производительности и предупреждений (Performance Logs & Alerts), а также все агенты Microsoft Operations Manager (например System Center Management).
    • Останавливаем и затем запускаем заново службу удаленного реестра (Remote Registry).
    • В силу того что на запуск служб Exchange в некоторых ситуациях может уходить достаточно много времени и это может привести к ошибкам в процессе установки, рекомендуется увеличить системное значение таймаута запуска служб как минимум вдвое (по умолчанию это значение составляет 30 секунд).

      В системном реестре находим ветку  HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
      Создаем в ней параметр DWORD с именем ServicesPipeTimeout и значением 60000 (Десятичное значение).

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

      Источник: Microsoft KB824344 How to debug Windows services

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

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

      1. Запустите Internet Explorer.
      2. В меню Сервис выберите пункт Свойства обозревателя.
      3. Откройте вкладку Дополнительно и перейдите в раздел Безопасность.
      4. Снимите флажок Проверять аннулирование сертификатов издателей и нажмите кнопку ОК.
      5. После завершения установки накопительного пакета обновления установите флажок Проверять аннулирование сертификатов издателей

    image
    Дополнительные сведения см. в статье 974445 базы знаний Майкрософт Создание образов NGEN занимает слишком много времени


    Этап #1. Обновление первого (пассивного) узла кластера

    Для начала в консоли Exchange Management Console откроем свойства нашего CCR кластера и убедимся, что он находится в состоянии Online, и пассивной нодой в кластере на данный момент является сервер KOM-TCSO-CM02

    image

    Теперь выполним первый этап обновления – обновление пассивного узла кластера на сервере KOM-TCSO-CM02.
    Для этого распакуем дистрибутив SP2, откроем командную строку с правами администратора и запустим команду установки:

    setup.com /mode:upgrade

    image

    После завершения процесса установки выполняем перезагрузку сервера.

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

    Этап #2. Обновление кластера.

    После перезагрузки заходим на обновленную пассивную ноду (KOM-TCSO-CM02) и снова проделываем подготовительные процедуры перед очередным запуском программы установки. Затем открываем консоль Exchange Management Shell и выполняем команду по остановке нашего CCR кластера (на этом этапе пользователи потеряют подключение к нашему серверу):

    Stop-ClusteredMailboxServer KOM-TCSO-MAIL -StopReasonSP2 Install

    image

    Далее выполним команду перемещения кластера CCR на обновлённую пассивную ноду (KOM-TCSO-CM02):

    Move-ClusteredMailboxServer KOM-TCSO-MAIL -TargetMachine KOM-TCSO-CM02 -MoveCommentSP2 Install

    image

    Далее из командной строки запустим процедуру обновления кластера CCR:

    setup.com /upgradecms

    image

    С этого момента наш обновленный кластер запущен и снова принимает подключения клиентов работая на обновленной ноде.
    Для того чтобы в этом убедиться, мы можем например открыть консоль Exchange Management Console и посмотреть свойства нашего кластера.
    Как мы можем видеть, версия кластера изменилась на новую и теперь соответствует версии SP2.

    image

    Теперь можно перейти к окончательному этапу – обновлению второго узла кластера.
    Не забываем вернуть в работающее состояние службы, остановленные на этапе подготовительных процедур (клиентов MOM, SCOM и т.п.)

    Этап #3. Обновление второго узла кластера

    Заходим на второй узел кластера (KOM-TCSO-HT01) и выполняем подготовительные процедуры, описанные ранее.
    Далее мы должны обеспечить полное перемещение всех кластерных ресурсов Windows Failover Cluster на уже обновленный узел. Делаем это с помощью CLI-утилиты cluster.exe. Сначала получим список всех кластерных групп:

    cluster group

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

    cluster group <GroupName> /move

    Выглядеть это будет примерно так:

    image

    Теперь все кластерные ресурсы расположены на первой обновленной ноде (KOM-TCSO-CM02) и мы можем запустить программу установки SP2 на необновленной ноде (KOM-TCSO-CM01):

    setup.com /mode:upgrade

    image

    После этого перезагружаем сервер и проверяем работоспособность всех служб Exchange.
    На этом установку SP2 в на CCR кластер Exchange Server 2007 можно считать оконченной.

    Официальное описание процесса обновления можно найти на сайте TechNet Microsoft:
    на русском языке - http://technet.microsoft.com/ru-ru/library/bb676320(EXCHG.80).aspx
    на английском языке - http://technet.microsoft.com/en-us/library/bb676320(EXCHG.80).aspx

    Загрузка SP2 для Exchange Server 2007 доступна по ссылке: Exchange Server 2007 Service Pack 2