• Управление устройствами в Exchange Server: Часть I. ActiveSync в Exchange Server 2003

    Fujitsu-Siemens-Pocket-LOOX-N500

    В этом и следующей  статье  я коротко расскажу о возможностях управления устройствами в Exchange Server. И начну я с Exchange Server 2003, причем с SP2. С одной стороны, учитывая близость релиза Exchange Server 2010, говорить о позапрошлой версии вроде бы и немного нелепо, с другой стороны в нашей стране до сих пор можно встретить организации, в которых используется  Exchange Server 5.5…

  • Главная Exchange/UC, Новое Exchange 2007, Microsoft.next
    • Настройка тестового стенда Exchange ActiveSync

      ActiveSync Exchange ActiveSync это протокол, позволяющий синхронизировать почтовый ящик Exchange с мобильным устройством, который с развитием Windows Mobile успел обрести определенную популярность. Получение практического опыта работы и тестовые испытания Exchange ActiveSync сопряжены с определенными трудностями, вызванными требованиями к  наличию необходимого оборудования. В данном документе Владислав Артюков рассказывает как, используя доступные средства виртуализации, построить стенд для тестирования данной технологии.Тестовый стенд ActiveSync предназначен для испытания технологии Exchange ActiveSync (EAS) на виртуальной серверной платформе MS Exchange Server 2007 SP1 и виртуальной клиентской платформе MS Windows Mobile 6.

      Замечание: Описанная в данном руководстве инфраструктура предназначена для испытательных целей, но с некоторыми оговорками применима и для производственной системы.

    • Главная Exchange/UC, Windows, Новое Active Directory, Exchange 2007
      • Синхронизация глобальных списков адресов (GAL) с использованием ILM 2007 FP1

        catalog Как обычно посетив работу, узнаешь, что задачи и проекты по реализации падают, как снег на голову и вот именно поэтому появилась данная статья. Сегодня мы поговорим о том, как настроить синхронизацию адресных книг (GAL) между двумя лесами средствами Microsoft Identity Lifecycle Manager 2007 FP1. Очень часто в крупных сетях требуется объединить несколько почтовых организаций в единый Global Address List. При этом обоснование очень простое “это требуется бизнесу”. Ну, надо так надо.

      • Главная Exchange/UC, Новое Exchange 2007
        • Обзор технологий высокой доступности Exchange Server 2007 и настройка Standby Continuous Replication.

          e12icon[7] Корректное функционирование и доступность почтовых систем становятся все более и более критичными для бизнеса.  Почтовые системы выросли от просто инструмента обмена письмами до средства групповой работы. Сегодня нередко от администраторов почтовых систем требуют обеспечить высокую доступность сервиса.
          Как обеспечить отказоустойчивость почтовых серверов? Что такое высокая доступность? Какие технологии высокой доступности есть в Exchange Server 2007 и в чем разница между ними? Как обеспечить высокую доступность почтовых серверов с минимальными затратами? В данной статье я попробую ответить на эти и другие вопросы

          В первоначальном выпуске Exchange 2007 (RTM) существовало три технологии для обеспечения высокой доступности и отказоустойчивости. В данной статье я хотел бы более подробно остановится на четвертой технологии – Standby Continuous Replication, включенной в состав Service Pack 1 для Exchange Server 2007. Почему именно на ней? Во-первых, эта технология включена в функционал Exchange Server Standard Edition.

          Табл. 1. Технологии обеспечения высокой доступности и выпуски Exchange Server.

          Exchange Standard Edition

          ( $ 728,42 или 25 879,45 p.)

          Exchange Enterprise Edition

          ($ 4 166,03 или 148 011,55 p)

          Local Continuous Replication (LCR)

          Поддерживается

          Поддерживается

          Standby Continuous Replication (SCR)

          Поддерживается

          Поддерживается

          Cluster Continuous Replication (CCR)

          Не поддерживается

          Поддерживается

          Single Copy Cluster (SCC)

          Не поддерживается

          Поддерживается

          Примечание: Стоимость и курс доллара даны на начало марта 2009 года и являются примерными. В данном случае стоимость взята с сайта ms-expert.ru. Точная стоимость зависит от «жадности» продавца.

          Во-вторых, технология достаточно новая и не включается с помощью графических мастеров.

          Давайте вообще определимся, что такое технологии высокой доступности и почему может не хватить обычного резервного копирования. При составлении дизайна почтовой инфраструктуры мы всегда определяем процедуры резервного копирования и восстановления. Однако время, затрачиваемое на восстановление из резервной копии, может оказаться неприемлемым для бизнеса. Представим, что устройство, с которого мы будем восстанавливать базу данных почты, имеет скорость восстановления 20 Gb в час. Соответственно для восстановления почтовой базы в 100 Gb (рекомендуемый максимальный размер базы без технологий обеспечения высокой доступности) придется затратить 5-6 часов. По бизнес требованиям это может оказаться недопустимым. При дизайне и составлении соглашения о сервисе бизнес может выдвинуть требования о максимальном времени простоя гораздо меньшим и тогда необходимо обращаться к данным технологиям.

          Краткий обзор технологий обеспечения высокой доступности.

          Local Continuous Replication (LCR). Есть два жестких диска на одном сервере (вторым жестким диском может быть, например SAN). База почтовых ящиков работает на одном диске, второй диск хранит пассивную копию базы данных. Первоначально копируется база на второй диск и затем ее идентичность базе на первом диске обеспечивается за счет доставки и применения журналов транзакций. В случае падения первого диска мы имеем возможность восстановить базу со второго диска (например, подключив его под той же буквой или используя Volume Mount Point под тем же именем папки, как и оригинальная база). В отличие от восстановления с резервной копии получается значительный выигрыш во времени восстановления – база уже есть, журналы транзакций на нее применены, остается только настроить ее подключение на место оригинала. Переключение ручное. Рекомендуемый максимальный размер базы – 200 Gb. Точка отказа – жесткий диск. Самая дешевая технология. Журналы транзакции доставляются сразу после их закрытия (по достижении 1 Mb)

          Cluster Continuous Replication (CCR). Настраивается два сервера в кластер. У каждого узла свой диск. Один узел хранит активную базу, второй пассивную. Идентичность баз обеспечивается за счет доставки и применения логов на пассивный узел. У каждого узла по два сетевых интерфейса. Один для внутренней сети кластера (по ней общаются узлы, чтобы узнать живой ли сосед), второй для обслуживания клиентов (причем оба узла видятся для клиентов как единый IP адрес). Кроме того настраивается сервер-свидетель который служит для корректного автоматического переключения в случае отказа одного из узлов. Переключение автоматическое. Рекомендуемый максимальный размер базы – 200 Gb. Точка отказа – сервер. Технология подороже. Требуется выпуски Windows Server Enterprise Edition и Exchange Server Enterprise Edition, еще как минимум один сервер (свидетелем может быть любой другой сервер даже не с Exchange). Журналы транзакции доставляются сразу после их закрытия (по достижении 1 Mb)

          Single Copy Cluster (SCC). Кластер в классическом понимании. Есть два компьютера – оба подключены к одному внешнему хранилищу. Оба компьютера могут работать с одной и тоже базой (база то доступна обоим компьютерам), но в один момент времени только один компьютер обслуживает одну базу. В случае его отказа второй компьютер автоматически берет на себя обслуживание базы. У каждого узла по два сетевых интерфейса. Один для внутренней сети кластера (по ней общаются узлы, чтобы узнать живой ли сосед), второй для обслуживания клиентов (причем оба узла видятся для клиентов как единый IP-адрес). Свидетель не требуется. Самая дорогая технология, так как по сравнению с CCR требуется еще определенное железо, которое поддерживает такую кластеризацию. Точка отказа – сервер.

          Standby Continuous Replication (SCR). Как можно увидеть технологии, которые позволяют избежать неработоспособности в случае отказа сервера до SP 1 были включены только в Enterprise Edition Exchange Server 2007. Local Continuous Replication не обеспечивала доступности в случае отказа сервера, только в случае отказа жесткого диска. В SP1 встроена технология обеспечения доступности в случае отказа сервера в редакции Standard – это SCR. Технология позволяет доставлять транзакционные лог файлы на другой сервер и применять их. В случае падения сервера, несущего нагрузку по обслуживанию рабочей базы – мы можем переключить пользователей на второй сервер уже готовый их обслуживать (он настроен – база есть).

          Что необходимо учесть:

          1. Поддерживается сколь угодно много серверов, на которые доставляются журналы в случае с SCR (рекомендуется не более четырех). В LCR и CCR поддерживается только один получатель.

          2. В случае LCR и CCR журналы транзакций применяются автоматически и практически сразу. В случае SCR по умолчанию журналы транзакции не применяются сразу после доставки – должно выполнится два условия (эту логику частично можно изменить):

          a. Должно быть доставлено 50 журналов с рабочего сервера.

          b. Должно пройти 24 часа с момента доставки журналов на сервер – получатель.

          3. Нельзя использовать разные ОС на источнике и получателе. Например, нельзя, чтобы на источнике была Windows Server 2003 а на получателе Windows Server 2008.

          4. Как и для LCR и CCR также и для SCR требуется чтобы была только одна база данных в одной группе хранения (Storage Group).

          Итак, после теоретической части включим и настроим SCR.

          Часть 1. Настраиваем SCR.

          В итоге мы должны пройти через следующие этапы:

          1. Включение SCR

          2. Имитацию падения рабочей базы

          3. Восстановление почты из копии.

          Сценарий. Есть два сервера. Оба под управление Windows Server 2008, на обоих серверах установлен Exchange Server 2007 SP1. Один сервер (SYD-DC1) является рабочим сервером, второй сервер (SYD-EX2) является сервером для копии.

          image

          Рис.1 Создаем на рабочем сервере группу хранения:

          Имя группы SCR-SG, месторасположение E:\ExchDataSCR.

          Создаем в данной группе хранения почтовую базу SCR-DB

          image

          Рис 2. Место хранения E:\ExchDataSCR\SCR-DB.edb

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

          После подготовки базы, можно в ней завести пользователей, я заведу пользователя для тестирования работоспособности и отработки механизма переключения пользователя. Итак, я завожу пользователя Vasya Pupkin с почтовым ящиком в данной базе (SCR-DB)

          image

          Рис.3

          image

          Рис.4 Отправляю несколько писем от Администратора и обратно к нашему Васе.

          Теперь давайте настроим SCR. Как я уже писал, настраивается только с помощью Power Shell. Для настройки репликации необходимо запустить командлет на рабочем сервере :

          Enable-StorageGroupCopy « группа хранения» -StandbyMachine «имя удаленного сервера»

          В нашем случае группа хранения SCR-SG, удаленный сервер SYD-EX2. В итоге мы запускаем

          Enable-StorageGroupCopy SCR-SG -StandbyMachine SYD-EX2

          image

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

          Я указал параметр –RelayLagTime и поставил значение 0.0:0:0 (дни.часы:минуты:секунды). Напомню, что по умолчанию для применения журналов транзакций в SCR должно быть выполнено два условия:

          1. Должно быть доставлено 50 журналов (доставляются как только они зарываются – после достижения размера в 1 Мб).

          2. Должно пройти 24 часа с момента доставки.

          Я изменил второй параметр и указал применять сразу после доставки 50 логов. Можно его настроить в диапазоне от 0 секунд до 7 дней. Первый параметр изменить нельзя. Такая задержка была встроена специально. Представим себе, что у Вас повредилась рабочая база, причем ее повреждение было вызвано некорректным письмом. В случае мгновенной доставки и применения логов это некорректное письмо будет отображено во всех базах и все базы будут неработоспособны. При наличии задержки мы можем предусмотреть эту ситуацию и, например не применить на сервере транзакционные лог файлы с некорректным письмом и вернуться к работоспособному состоянию. Эти параметры нельзя изменить в последующем. Для их изменения Вам придется перенастроить SCR.

          Кроме того есть еще параметр TruncationLagTime. Он отвечает за время, через которое журналы транзакций, доставленные на второй сервер и примененный будут удалены.

          Еще один важный момент у меня база на диске E. На сервере получателе должен быть диск с буквой E иначе не создастся SCR. Обратите внимание, что мы на сервере получателе ничего не делали, ни создавали базу данных , ни группу хранения. Единственное требование – идентичная серверу источнику операционная система и наличие диска с такой же буквой, какая у диска на которой хранится боевая база данных.

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

          image

          Рис.6

          Обратите внимание, что на втором сервере в момент выполнения командлета Enable-StorageGroupCopy создалась на диске E папка ExchDataSCR (соответствует названию папки группы хранения рабочего сервера) и в ней появились логи. Причем только логии и самой базы нет (не доставлено еще 50 логов). Логов всего 7.

          image

          Рис.7 Я сымитировал ведение деловой переписки Васей

          Мы можем убедиться, что логи доставляются постоянно, на следующем рисунке обратите внимание, что доставился еще один журнал.

          image

          Рис.8

          Стало всего восемь логов на сервере получателе. Также мы можем убедиться в корректности работы SCR с помощью командлета Get-StorageGroupCopyStatus. Обратите внимание, что данный командлет был запущен на сервере-источнике (вверху на синей полосе контекст SYD-DC1)

          Get-StorageGroupCopyStatus SCR-SG –StanbyMachine Syd-ex2

          image

          Рис 9. Командлет проверки состояния SCR на сервере-источнике

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

          image

          Рис 10. Командлет проверки состояния SCR на сервере-получателе.

          В консоли управления Exchange на сервере получателе Вы не увидите базы SCR-DB.

          image

          Рис 11. Консоль управления Exchange на сервере – получателе.

          Все репликация настроена.

          Часть 2. А что если все-таки база упадет?

          Теперь давайте сымитируем падение рабочей базы.

          Я отмонтирую базу на рабочем сервере и для чистоты эксперимента удалю ее файлы.

          image

          Рис. 12 Отмонтированная база на сервере-источнике и удаленные файлы из места расположения базы.

          Теперь нам необходимо восстановить базу на сервере получателе (SYD-EX2).

          Для этого необходимо выполнить командлет

          Restore-StorageGroupCopy SYD-DC\SCR-SG –StandbyMachine SYD-EX2 –Force

          Параметр Force я указал, так как недоступна оригинальная база, если бы она была доступна, то я бы указал без этого параметра.

          А теперь внимание. Самой базы у нас нет – еще не прошло 50 доставок, поэтому я достаю саму базу из бэкапа. Это к важности бэкапа. И копирую его в папку, куда настроено было копирование на сервере получателе, где находятся доставленные логи. Если будет 50 логов, то база автоматически создастся. Это тонкий момент – его надо обязательно учесть. Вы не сможете восстановить базу, пока не пройдут 50 репликации журналов транзакций.

          Теперь я создам группу хранения и базу данных на сервере получателе, в которую я восстановлю базу. Создавать надо с путями по умолчанию или с любыми другими путями но только не с путем, где хранится база с логами доставленными.

          image

          Рис. 13 Создание SG на сервере получателе

          image

          Рис.14 Создание базы данных на сервере получателе.

          Далее я запускаю командлеты для переноса путей созданной базы в место, где доставлялись логи с рабочего сервера. Для того, что бы существующая база не затерла доставленные логии и базу я указываю параметр  –ConfigurationOnly

          Move-StorageGroupPath SYD-EX2\RecoveredSCR-SG -SystemFolderPath E:\ExchDataSCR -LogFolderPath E:\ExchDataSCR –ConfigurationOnly

          Move-DatabasePath  SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB  -EdbFilePath E:\ExchDataSCR\SCR-DB.edb  –ConfigurationOnly

          На все вопросы говорю Yes

          image

          Рис. 15 Перемещение путей на сервере получателе.

          База данных находится в отмонтированном состоянии. Для ее подмонтирования я должен поставить галочку «This database can be overwritten by a restore» в свойствах базы или выполнить командлет

          Set-MailboxDatabase SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB  -AllowFileRestore:$true

          и подмонтировать базу опять же либо с помощью консоли управления Exchange либо с помощью командлета

          Mount-Database SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB

          База готова. Однако у пользователей в AD до сих пор ссылка на место хранения своей почты на сервер SYD-DC1. Нам необходимо провести замену этой ссылки и сказать, что теперь у пользователей база на SYD-EX2. Это делается опять же с помощью командлета Move-Mailbox с добавочкой –ConfigurationOnly.

          Важно! Необходимо, чтобы перемещались почтовые ящики всех кроме системного помощника Exchange и системные ящики.  Для этого я наберу командлет:

          Get-Mailbox -Database SYD-DC1\SCR-SG\SCR-DB |where {$_.ObjectClass -NotMatch ‘(SystemAttendantMailbox| ExOleDbSystemMailbox)’}| Move-Mailbox -ConfigurationOnly -TargetDatabase  SYD-EX2\RecoveredSCR-SG\RecoveredSCR-DB

          image

          Рис.  17 Перемещение почтовых ящиков.

          Все я готов к работе. Давайте войдем как VasyaPupkin.

          image

          Рис. 18 Вся важная деловая переписка сохранена.

          image

          Рис. 19 Почтовый ящик пользователя на новой базе.

          Для пользователя все прозрачно. Если у пользователя Outlook 2003, то необходимо будет еще переуказать путь к новому серверу в его профиле Outlook. Для Outlook 2007 с настроенным Autodiscovery неактуально. Теперь можем опять настроить SCR. Итог.В этой статье мы прошли с Вами через весь процесс создания SCR и познакомились с основными концепциями ее работы.

          Хочу привести командлеты для настройки:

          Disable-StorageGroupCopy – Отключает назначение репликации SCR для группы хранения.

          Get-StorageGroupCopyStatus –  Определяет текущее состояние назначения репликации SCR.

          New-StorageGroup –  Создает новую группу хранения с поддержкой SCR, при этом не требуется отдельно включать SCR с помощью командлета Enable-StorageGroupCopy.

          Restore-StorageGroupCopy – Отключает SCR и делает базу данных назначения SCR пригодной для присоединения с помощью операции Mount-Database в процедуре восстановления.

          Resume-StorageGroupCopy –  Восстанавливает непрерывную репликацию для группы хранения, в которой она была приостановлена.

          Suspend-StorageGroupCopy – Приостанавливает непрерывную репликацию для группы хранения, в которой она была включена.

          Update-StorageGroupCopy –  Используется для заполнения целевой группы хранения.

          Николай Муравлянников, MCITP, MCSE