Главная Exchange/UC, Без рубрики, Новое Exchange 2007, Exchange 2010, Конкурс
  • Миграция с Exchange 2007 на Exchange 2010 в системах с кластерами

    BOX_Microsoft-Exchange2010 Добрый день! Хочу рассказать о своем опыте внедрения Exchange Server 2010. Первоначально этот документ планировался как Step-By-Step Guide для коллег, однако позже он перерос в доклад на заседании MCP-клуба.

    Я работаю системным администратором в небольшой организации, начитывающей 200-250 рабочих мест. Отрасль – энергетика. Регион – Сибирь. Предприятие является головным для нескольких подконтрольных компаний с общей численностью в 4’000 рабочих станций, но при этом само является звеном федерального холдинга. Работа части сотрудников связана с регулярными командировками по разным часовым поясам. В связи со всем вышеперечисленным, почтовый сервис является бизнес-критическим приложением.

  • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Storages, Конкурс
    • Exchange 2010 и SIS

      Small Single Storage Unit В Exchange Server 2010 больше нет системы Единого экземпляра хранения объектов – SIS, Single Instance Storage.

    • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
      • 10 мифов о хранилищах Exchange 2010

        computer-mailbox Многие уже слышали о кардинальных изменениях, произошедших в Exchange 2010, которые в совокупности позволили использовать почтовые ящики огромных размеров и доступные хранилища низкой стоимости. И было множество дискуссий о выборе систем хранения для Exchange, среди которых члены команды Exchange Team нашли и несколько интересных высказываний. Для окончательного прояснения ситуации были собраны наиболее часто встречающиеся мифы и заблуждения, а также объяснения к ним, подкреплённые авторитетными источниками.

        Для лучшего понимания управления почтовыми ящиками больших размеров Microsoft опубликовала Large Mailbox Vision Whitepaper.

        А теперь — 10 самых распространённых мифов о хранилищах Exchange, поехали!

        Миф #1: Exchange требует дорогие высокопроизводительные хранилища. «Мы не можем позволить себе большие почтовые ящики!»

        Правда: Exchange 2010 позволяет легко хранить огромные почтовые ящики на недорогих системах хранения данных. Такие системы показывают приемлемый уровень производительности на дисках низкой стоимости и предоставляют массу опций хранения. Смотрите в Large Mailbox Vision Whitepaper.

        Миф #2: Exchange 2010 не поддерживает Сети хранения данных SAN (Storage Area Network).

        Правда: Microsoft в Exchange 2010 отказалась от поддержки NAS (Network Attached Storage, хранилищ, подключаемых к сети) (выглядит похоже, может быть поэтому путают), но масса поддерживаемых вариантов хранилищ включает в себя SAN и DAS (Directly Attached Storage, напрямую подключаемые массивы). В зависимости от вашей модели отказоустойчивости, хранилища могут быть сконфигурированы в RAID массив, или без RAID – JBOD (просто последовательный набор дисков). Разные заказчики используют различные решения, основанные на собственных требованиях, но при этом все имеют возможность размещения почтовых ящиков больших размеров на доступных хранилищах низкой стоимости.

        Миф #3: «У нас уже есть SAN (или мы только что купили), так что теперь нет смысла применять DAS для Exchange. И кстати, в наш SAN можно подключить и эти дешёвые SATA-диски тоже.»

        Правда: Это не совсем миф, а просто некоторое недопонимание. Развёртывание SAN имеет смысл, поскольку вы также получаете возможность использования больших почтовых ящиков по низкой стоимости. Помните, что Exchange поддерживает широкий диапазон хранилищ, включая SAN и DAS. Если вы рассчитываете получить преимущество множества независимых копий баз данных – вам следует рассчитывать полную стоимость такого решения.

        Миф #4: Дисковые конфигурации JBOD непрактичны, потому что процедура повторного насаждения баз данных занимает много времени и требует слишком много усилий.

        Правда: Microsoft IT очень успешно применяет JBOD конфигурацию при достаточно низкой стоимости такого решения. Однако для управления подобной структурой требуется достаточный уровень опыта администраторов. Существует несколько факторов, влияющих на скорость развёртывания почтовых баз данных, и по внутренним исследованиям Microsoft, там эта процедура с JBOD проходит примерно в 35-70 GB/час.

        Миф #5: Большие почтовые ящики плохо обрабатываются в Outlook.

        Правда: Exchange 2010 поддерживает до 100,000 объектов в папке, по сравнению с 20,000 в Exchange 2007. Вдобавок к этому Outlook 2007 SP1, Outlook 2007 SP2 и Outlook 2010 с февральским обновлением 2009г. выдают в режиме кэширования (Cached Exchange Mode) хорошие показатели производительности обработки почтовых ящиков вплоть до 10 GB, и даже больше – до 25 GB на быстрых 7200 или SSD дисках. Ещё больше почтовые ящики? Хранилище Exchange 2010 спроектировано для поддержки очень больших почтовых ящиков – 100 GB+ при использовании Online режима и OWA. Кроме того, вы всегда можете использовать Личные архивы (Personal Archive) Exchange 2010 для снижения общего объёма основного почтового ящика клиентов в кэшированном режиме (Cached Exchange Mode).

        Миф #6: При миграции на Exchange 2010 базы данных катастрофически увеличатся в размере, поскольку Exchange 2010 не поддерживает Единый экземпляр хранения объектов (SIS, Single Instance Storage).

        Правда: Руководства по планированию хранилищ Exchange всегда требуют расчёта объёмов без учёта технологии SIS. Технология SIS снижает возможности последовательного доступа Exchange Server к данным, а новые изменения помогают обеспечить снижение количества операций ввода-вывода, I/O, до 70%! Помимо этого, Exchange 2010 умеет сжимать до 20% базы данных на HTML/текстовых сообщениях. Более подробно о SIS в Exchange 2010 читайте здесь, в статье Exchange 2010 и SIS.

        Миф #7: «Наш администратор Exchange не разбирается в системах хранения данных, это дело экспертов по СХД. Мы считаем, что управление более дешёвыми хранилищами требует больше усилий и времени.»

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

        Миф #8: Большие базы данных Exchange невозможно бэкапить.

        Правда: Имея функционал множественных копий баз данных (DAG), отложенной репликации баз и восстановления отдельных писем – традиционная архивация перестаёт быть острым моментом. Эти технологии позволяют реже проводить архивацию, вплоть до полной архивации раз в неделю или даже в две. Архивировать можно пассивные копии баз данных, а также задействовать экспресс-архивацию DPM, для экономии дискового пространства.

        Миф #9: «Нам понадобится сторонне решение архивации, потому что базы Exchange нужно хранить в крутом и мощном хранилище, а у нас такого нет.»

        Правда: Данные Exchange можно держать на любых хранилищах! И не только архивные копии. При достаточной степени продуманности можно совмещать «горячие» и резервные данные, для лучшей утилизации огромного дискового пространства по низкой цене, что также упрощает управление.

        Миф #10: «Все проекты хранилища для Exchange должны досконально соответствовать показаниям Exchange Mailbox Role Requirements Calculator! В противном случае получится неподдерживаемое решение.»

        Правда: Exchange Mailbox Role Requirements Calculator (для Exchange 2010 / Exchange 2007) предоставляет рекомендации по проектированию, а не поддерживаемым решениям хранения. А вот Exchange Solution Reviewed Program (ESRP) – содержит информацию от партнёров специализирующихся на выпуске хранилищ.

        Не верьте мифам!

        Maxim E. Zinchenko

      • Главная Exchange/UC, Без рубрики, Новое DAG, Exchange 2010, NLB, Конкурс
        • Отказоустойчивый Exchange 2010 (DAG + NLB)

          exchange20102

          UPD: Исправлен недочет в разделе организации NLB-массива.

          Сегодня ни кто уже не будет спорить, что почтовая система в каждой организации является одним из самых важных и уязвимых мест. Сточки зрения бизнеса, корпоративная почта должна быть доступна в режиме 24/7, т.к. часто запоздалая отправка, либо несвоевременное получение всего одного письма может принести компании ощутимый финансовый и имиджевый урон. В связи с этим, ИТ-администраторы предпринимают всяческие меры по обеспечению отказоустойчивости почтовых серверов. До выхода Exchange 2007 это было достаточно не простой задачей. Затем в 2007-м Exchange`е компания Microsoft изменила эту ситуацию, введя две новые функции CCR и SCR, которые, надо заметить, были весьма успешными в деле организации безаварийной работы.

          С выходом Exchange 2010, Microsoft пошла ещё дальше и улучшила функции CCR и SCR, соединив две функции в одном компоненте DAG (Database Availability Group), DAG стала новой функцией непрерывной доступности баз данных почтовых ящиков. Функция DAG, как и CCR, зависит от ограниченного набора компонентов отказоустойчивой кластеризации Windows (Failover Cluster), в основном, от базы данных кластера, файлового ресурса-свидетеля и функции импульса синхронизации. Группы DAG обеспечивают защиту на уровне базы, сервера и узла и делают развертывание решения высокой доступности и аварийного восстановления на уровне сайта гораздо проще, нежели в предыдущих версиях Exchange.

          Но обеспечить отказоустойчивость баз данных это ещё пол дела, также нужно обеспечить непрерывный доступ самих пользователей к этим базам данных. Как известно, за работу с почтовыми клиентами в Exchange отвечает CAS (Client Access Service). Для организации отказоустойчивости этой службы существует Client Access Array, который позволяет объединить несколько CAS серверов в массив, а затем настроить доступ к FQDN этого массива при помощи стандартного Windows NLB (Network Load Balancing) кластера.

          Кроме ролей Mailbox Server и Client Access Server существует ещё и роль транспортного сервера-концентратора (Hub Transport Server), как же быть с ней в плане отказоустойчивости? А с ней совсем делать ни чего не надо, достаточно установить на два или более сервера Exchange 2010 эту роль и отказоустойчивость будет обеспечена автоматически, т.к. транспортные серверы-концентраторы Exchange отказоустойчивы по умолчанию. То есть, при наличии более чем одного транспортного сервера-концентратора, развернутого на сайте Active Directory, и в случае недоступности одного из транспортных серверов-концентраторов в этом сайте Active Directory исходный транспортный сервер-концентратор, пытающийся доставить сообщение, перейдет к следующему транспортному серверу-концентратору в этом сайте Active Directory. Это проделывается с помощью механизмов циклического опроса DNS (если первый транспортный сервер-концентратор в списке не отвечает, переходим к следующему). Так что когда речь заходит о связи между двумя транспортными серверами-концентраторами или между сервером почтового ящика и транспортным сервером-концентратором (то есть внутренней), нам не нужно заботиться о высокой доступности (или балансировке, если на то пошло), поскольку это собственные функции Exchange 2010. Но не забывайте, что в случае установки роли транспортного сервера-концентратора на компьютере, где также установлена роль сервера почтовых ящиков, роль сервера почтовых ящиков будет предпочитать локальный транспортный сервер-концентратор любым другим транспортным серверам-концентраторам в сайте Active Directory (даже если локально установленный транспортный сервер-концентратор недоступен), когда служба отправки почты Microsoft Exchange отправляет сообщения. Но данный факт не относится к серверам, включенным в DAG группу. В случае, если Hub Transport`ы установлены на сервера MailBox, входящие в DAG, то сервера почтовых ящиков будет предпочитать любой другой Hub Transport в сайте AD, и только в последнюю очередь будут обращаться к локальным.

          Теперь перейдем от теории к практике и посмотрим, как обеспечить отказоустойчивость Exchange 2010.

          Для этого построим принципиальную схему организации почтовой системы предприятия:

          Рис.1. Принципиальная схема почтовой системы предприятия

          Примечание: Настройку сервера EDGE Transport в этой статье рассматривать не будем (о ней можно почитать тут). Так же не будем рассматривать процедуру установки Exchange серверов (это совсем не сложно), единственное, в чем хочу вас предостеречь, так это в том, что не стоит пытаться устанавливать несколько серверов одновременно (даже в тестовой среде), необходимо дождаться окончания установки одного сервера, а затем приступать к инсталляции другого, в противном случае системные ошибки неизбежны.

          Перейдем к настройке Database Availability Group

          Важно отметить, что в каждую DAG группу может входить до 16 серверов почтовых ящиков, таким образом, вы сможете иметь до 16 копий каждой базы (хранение более одной копии базы почтовых ящиков на каждом сервере не поддерживается, а также активной может быть только одна копия), причем нужно не забывать, что каждый Exchange 2010 Standard может поддерживать только 5 баз данных, а Enterprise версия – до 100 баз. Время переключение между базами в Exchange 2010 заметно снижено, и теперь составляет порядка 30 секунд, а если учесть тот факт, что клиенты общаются с базами данных через Client Access Servers, то они совсем не заметят этого перехода. Также в Exchange 2010 предпринята попытка отказаться от публичных папок (Public Folders), и хотя они все ещё поддерживаются, но теперь их нельзя включить в группу DAG и обеспечивать их доступность придется при помощи стандартных механизмов репликации баз данных публичных папок.

          Как уже говорилось выше, группы DAG в своей работе используют часть компонентов системы отказоустойчивых кластеров (Failover Clusters), таким образом, как и в классическом отказоустойчивом кластере, серверам нужно иметь по два сетевых интерфейса: один для MAPI-доступа клиентов, другой для трафика heartbeat/replication, по которому будет отслеживаться состояние узлов кластера. Хотя решения с одним сетевым интерфейсом на каждом сервере поддерживаются, но мы не будем экспериментировать и возьмем две сетевых карты, одна будет смотреть в локальную сеть предприятия и будет иметь адрес из диапазона 192.168.0.0/24, другая – в изолированную сеть с адресным пространством 192.168.1.0/24.

          Рис.2: Принципиальная схема Database Availability Group

          На интерфейсе для Heartbeat`ов можно отключить такие компоненты сетевого взаимодействия, как TCP/IPv6, Client for Microsoft Network, File and Printer Sharing и
          даже QoS. Затем надо проверить что локальный сетевой интерфейс находится первым в списке порядка привязки, для этого пойдем в меню Advanced (Дополнительно) > Advanced Settings (Дополнительные параметры) и посмотрим в раздел Connections.

          Что касается организации хранилищ для баз данных почтовых ящиков, то теперь вам не придется приобретать высокоскоростные, а, следовательно, и дорогие жесткие диски. В связи с изменениями в механизме расширяемого хранилища (ESE), с Exchange 2010 вы получаете вариант использования таких дисков с низкой производительностью, как диски SATA 7200! Фактически, вы можете размещать активную копию базы данных на одном SATA диске, а все остальные копии вместе – на другом, и ни каких проблема с производительность дисковой подсистемы у вас быть не должно. Правда тут надо заметить, что вместе с улучшениями в организации работы с жесткими дисками, у Exchange 2010 ещё более возрос аппетит к оперативной памяти сервера и теперь, Microsoft говорит, что !каждую роль! Exchange 2010 необходимо обеспечить 4 Гб оперативной памяти. Возможно это и некоторое преувеличение, но практика покажет, как дела обстоят на самом деле.

          Для функционирования DAG, кроме самих серверов Exchange 2010 необходим ещё один сервер, не входящий в группу DAG, он будет выполнять роль сервера-свидетеля, это что-то вроде кворума в классическом отказоустойчивом кластере и именно с помощью него отслеживается состояние серверов, входящих в DAG. Для организации сервера-свидетеля подойдет любой сервер в сайте Active Directory, даже без установленного Exchange 2010, единственным условием его функционирования является то, что в группу его локальных администраторов должна входить доменная группа Exchange Trusted Subsystem.

          Рис.3: Доменная группа
          Exchange Trusted Subsystem в группе локальных администраторов сервера-свидетеля.

          Итак, все подготовительные работы завершены, теперь давайте создадим новую DAG-группу. Для этого перейдем в раздел Organization Configuration (DAG находится именно на уровне организации), откроем вкладку Database Availability Groups и в меню Действия выберем New Database Availability Group… Откроется мастер конфигурирования DAG:

          Рис.4: Мастер настройки DAG

          Здесь нужно вписать имя группы, имя сервера-свидетеля (не забываем, что он не должен входить в DAG) и имя папки, где будет храниться информация о состоянии Exchange серверов (мастер создаст папку на удаленном сервере сам). Далее, если все настроено правильно, то мастер создаст группу и следующим шагом нам нужно будет добавить в неё сервера, для этого нажмем на группе правой кнопкой мыши и выберем пункт Manage Database Availability Group. В данном мастере необходимо добавить сервера с установленной ролью Mailbox, которым мы хотим обеспечить высокую доступность:

          Рис.5: Добавление серверов в группу DAG

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

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

          Рис.6: Проверка кластера.

          Если у вас в сети нет DHCP сервера, то DAG соберется, но будет в неактивном состоянии, т.к. группе не будет назначен IP адрес (состояние кластера можно также посмотреть в Диспетчер отказоустойчивости), чтобы исправить эту неприятность, необходимо воспользоваться командлетом New-DatabaseAvailabilityGroup с параметром DatabaseAvailabilityGroupIPAddresses, вот как-то так:

          New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddresses 192.168.0.5

          Когда группа DAG у вас будет собрана и активна, необходимо сделать копии баз данных на «соседних» серверах (не забывайте, что каждый сервер может хранить только одну копию базы). Чтобы создать копию базы данных, нажмите правой кнопкой мыши на исходной базе и выберите пункт меню Add Mailbox Database Copy…, далее откроется мастер, в котором нужно указать на каком сервере будет размещена копия и приоритет её активации:

          Рис.7: Создание копии базы данных.

          Если вам не нравится GUI, то можно это сделать с помощью командлета:

          Add-MailboxDatabaseCopy -Identity MDB2 -MailboxServer Server3 -ActivationPreference 2
          

          Создать копию базы данных с временем задержки воспроизведения и временем задержки усечения можно только из командной консоли Exchange (здесь 10 и 15 минут соответственно):

          Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 00:10:00 -TruncationLagTime 00:15:00 -ActivationPreference 2
          

          Таким образом, мы получаем несколько копий исходной базы данных, расположенные на разных серверах и в разных хранилищах. Чтобы активировать одну из копий, нужно нажать на ней правой кнопкой мыши и из выпадающего меню выбрать Activate Database Copy, после чего в открывшемся окне решить стоит ли перезаписывать параметры базы и нажать ОК, далее база данных будет автоматически смонтирована на другом сервере и её состояние измениться с Healthy на Mounted:

          Рис.8: Переключение баз почтовых ящиков.

          Примечание: Если вам необходимо сделать заполнение (обновление) одной из копий баз данных, то перед этим нужно приостановить её работу командой Suspend Database Copy, а затем выбрать пункт Update Database Copy…

          Рис.9: Обновление копии базы данных почтовых ящиков.

          Перейдем к настройке массива серверов CAS

           

          Принципиальная схема взаимодействия серверов в массиве будет выглядеть следующим образом:

          Рис.10: Принципиальная схема взаимодействия серверов в CAS массиве.

          Смысл в том, что клиенты, вместо подключения непосредственно к CAS серверу, будут подключаться к FQDN CAS-массива и при «падении» одного из серверов клиентские запросы возьмет на себя другой.

          Т.к. массив CAS используется только клиентами Outlook MAPI, то для обеспечения отказоустойчивости таких сервисов как Outlook Webb App, Exchange ActiveSync, Autodiscover и других, необходимо решить, что именно у вас будет выполнять роль балансировщика сетевой нагрузки (NLB). Microsoft рекомендует использовать для этих целей внешние аппаратные устройства, но если у вас таковых нет, то служба Windows Network Load Balancing вполне подойдет. Здесь нужно иметь в виду, что службы Windows NLB и Failover Cluster на одном сервере не живут!

          Для работы WNLB (как и других систем балансировки), необходимо иметь на DNS сервере запись, указывающую на виртуальный IP-адрес этой системы:

          Рис.11: Настройка DNS сервера.

          Далее давайте настроим Windows NLB кластер, для этого установим соответствующие компоненты в диспетчере сервера, затем откроем Диспетчер балансировки сетевой нагрузки в меню Администрирование и создадим новый кластер.

          Рис.12: Создание нового кластера NLB.

          В открывшемся мастере введем имя первого узла кластера и укажем локальный сетевой интерфейс. В следующем окне менять ни чего не нужно. Далее, добавим IP-адрес нашего кластера и укажем маску. Затем нужно настроить параметры кластера:

          Рис.12: Настройка параметров кластера.

          Снова введем IP-адрес и FQDN имя, указанное ранее в DNS сервере. Следующим шагом, нужно будет определить, какой режим работы выбрать, если кратко, то в одноадресном режиме, МАС адрес сетевого адаптера каждого сервера будет заменен виртуальным МАС адресом кластера и будет использоваться всеми серверами кластера. В многоадресном режиме МАС адрес добавляется в адаптер кластера на каждом сервере и каждый сервер сохраняет свой МАС адрес. Рекомендуется использовать Одноадресный режим!

          Подробнее про принцип работы NLB можно посмотреть здесь.
           Отдельное спасибо Александру Станкевичу за детальное описание данного механизма!

          Примечание: Если вы развертываете Exchange 2010 сервера в виртуальной среде, то при работе WNLB могут возникнуть проблемы, поэтому, если вы разворачиваете узлы кластера на платформе виртуализации VMware ESX Server, то вам придется использовать Многоадресный режим. Если же вы работаете с MicrosoftHyper-V, то лучше включить Одноадресный режим, но при этом внести некоторые изменения в настройки виртуального сетевого адаптера, а именно – настроить Статический МАС-адрес и включить функцию спуфинга МАС адресов.

          Рис.14: Настройка сетевых интерфейсов в Hyper-V

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

          • TCP/135 – для работы CAS-массива (убедитесь, что в Filtering Mode свойство Affinity включено в Single);
          • TCP/1024-65535 – диапазон RPC портов для MAPI-клиентов и CAS (если у вас не указаны статические порты);
          • TCP/443 – для Outlook Anywhere, Exchange ActiveSync и Outlook Web App;
          • TCP/993 – для Secure IMAP (Affinity включено в None);
          • TCP/995 – для Secure POP (Affinity включено в None);
          • TCP/80 – для внутреннего IIS перенаправления (HTTP > HTTPS).

          Далее нажимаем Готово и добавляем ещё один узел к кластеру, нажав на созданном кластере правой кнопкой мыши и выбрав пункт Добавить узел к кластеру. У нового узла значение приоритета выставляем в 2 и все остальные параметры оставляем по-умолчанию.

          Теперь осталось только собрать сам CAS массив.

          Для этой цели воспользуемся командлетом New-ClientAccessArray:

          New-ClientAccessArray -FQDN "mail.test-mail.local" –Site "Default-First-Site-Name"
          

          И подключить к массиву базы данных почтовых ящиков командлетом Set-MilboxDatabase:

          Set-MailboxDatabase -RpcClientAccessServer "mail.test-mail.local"
          

          Рис.15: Создание CAS массива.

          Проверить результат можно командлетом Get-MilboxDatabase.

          На этом настройка массива CAS серверов заканчивается, проверить работоспособность массива можно запустив MS Outlook, служба Autodiscover должна разрешить имя сервера как FQDN массива.

          Рис.16: Настройка MS Outlook.

          Статьи для подробного изучения:

           

          PS. Нужно иметь ввиду, что отказоустойчивые решения для систем виртуализации, в частности Failover Cluster для Hyper-V, использующие Live Migration, нельзя комбинировать с решениями репликации Exchange (ССR или DAG). Рекомендуется настраивать CCR или DAG на узлах Hyper-V не включенных в Failover Cluster и, соответственно, не использующих Cluster Shared Volumes.

          Запуск CCR или DAG на кластере с Live Migration не поддерживается!

          PPS. Если вам потребуется изменить URL`ы таких служб, как OWA (Outlook Web App), ECP (Exchange Control Panel), Exchange ActiveSync (EAS) и Outlook Anywhere (OA), то об этом вы сможете почитать тут.

          Алексей Богомолов (Alexx)

        • Главная Exchange/UC, Без рубрики, Новое Exchange 2010, Конкурс
          • Exchange Server 2010: MailTips

            Наверно многие из нас попадали в ситуацию когда письмо было отправлено на другую группу или не тому адресату?

            Если вы хоть раз попадали в подобную ситуацию то вы по достоинству оцените новую службу (веб сервис) MailTips в Exchange Server 2010

            • Конкурс: Microsoft Exchange 2010

              logo-header-e2010 После небольшого перерыва портал ITband.ru и форумы Microsoft TechNet с удовольствием сообщают о новом конкурсе статей и вебкастов. На этот раз конкурс будет посвящен выходу Microsoft Exchange 2010.

              На конкурс принимаются русскоязычные технические статьи и вебкасты описывающие техническую компоненту или технологию применяемую в Microsoft Exchange 2010. К участию в конкурсе так же допускаются подробные описания внедрения Microsoft Exchange 2010 на предприятии, а так же оригинальные переводы с других языков (в случае перевода необходима ссылка на оригинал).

              Призы будут присуждаться, в двух номинациях:

              новые возможности для пользователей – новые возможности для пользователей – описывает нововведения, механизм их настройки и функционирования в Microsoft Exchange 2010 направленные на улучшение работы пользователей. Например, к этой категории будет относится статья о голосовом доступе к почтовому ящику

              новые возможности для администраторов – описывает нововведения, которые упрощают работу администратора. Например статья о работе с командлетами PowerShell.

              Срок проведения конкурса с 24 марта по  1 июля 2010 года.
              Для участия в конкурсе необходимо отправить оформленную статью на адрес admin@itband.ru

              Правила оформления

              Для участия в конкурсе статья должна быть размещена на сайте itband.ru.

              Для размещения статьи, автор должен предоставить администрации сайта окончательно оформленную статью в файле формата doc или html.

              При наличии скриншотов, схем, графиков или иных изображений автор должен предоставить их отдельными файлами (gif, jpeg, png, tiff, bmp), пронумерованными по порядку расположения в статье.

              Призы

              168740_gallery_61717 За первое место –  ACER Aspire 8730ZG-423G32Mi

              Процессор: Intel Core 2 Duo (T4200)
              Память: 3072 МБ  (DDR3-1066), max: 4096 МБ
              Жесткий диск: 320 Гб, SATA
              Экран:     18.4″ (1600 x 900), WXGA++ 16:9
              Видео: nVidia GeForce 9300M G, 512Мб собственной памяти
              DVD±RW DL,  Wi-Fi: IEEE 802.11b; IEEE 802.11g Емкость батареи: 4800 мАч
              44,1 x 4,4 x 30 см
              Вес: 4,1 кг

              1000913888 За второе место – Samsung WiTu SGH-i900 8Gb

              Дисплей:  3.2″ (240×400), TFT, 256 000 цветов, сенсорный
              Операционная система: Windows Mobile 6.1
              Процессор: 624 МГц Marvell PXA312
              Память: RAM 128 \ ROM 256 Мб
              Встроенная память: 8 Гб
              Слот для карт памяти microSD (microSDHC до 16 Гб)
              Интерфейсы:    Bluetooth 2.0 (A2DP), USB 2.0, WiFi 802.11 b/g
              Доступ в интернет:  WAP 2.0, GPRS (class 12), EDGE (class 12)
              Цифровая камера: 5 Мпикс (2592х1944)
              Аккумулятор:    Li-Ion 1440 мАч

              124394 За третье место – Microsoft LifeCam VX-2000

              Интерфейс: USB 2.0
              Фокусировка: Автофокус
              Разрешение:
              Видео: 640 х 480 VGA
              Фото: до 1.3 мегапикселей (интерполяция)
              Веб-камера: 30 кадров / сек.
              Микрофон: Встроенный

              Дополнительные призы: подписка TechNet Plus. За каждую статью  свыше 10 000 знаков – ваучер для бесплатной сдачи экзамена Microsoft.

              Автор самой читаемой и комментируемой статьи получит шаманский бубен 😉

              Критерии оценки

              Выбор победителей осуществляется жюри состоящее из администрации ресурса и представителей компании Microsoft.

              Оцениваться будет не количество статей, а их качество.

              Ограничения

              Все статьи являются личной собственностью их авторов, однако участие в конкурсе накладывает ряд ограничений.

              К конкурсу допускается любой русскоязычный автор. Однако доставка физических призов осуществляется только по России. В случае присуждения приза участнику находящемуся за рубежом, приз будет доставлен в любую точку России, которую укажет автор.

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

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

              Отбор статей на конкурс, награждение и общая модерация конкурса проводится Администрацией itband.ru исходя из собственных субъективных ощущений, опираясь на мнения общественности и сторонних специалистов Microsoft.

              Статья может быть отклонена Администрацией itband.ru без указания причин.

              Администрация ITband.ru

            • Главная Exchange/UC, System Center, Без рубрики, Новое Exchange 2007, Exchange 2010, SCMDM 2008
              • Remote Wipe в Exchange Server и SCMDM

                images Одной из ключевых возможностей, которую предоставляют системы управления мобильными устройствами, является выполнение удаленной чистки устройства, т.н. Remote Wipe. При выполнении очистки устройство возвращается в исходное фабричное состояние, а вся информация из памяти устройства удаляется.

                Очень часто у людей, которые интересуются MDM, возникают вопросы:

                • А как это работает?
                • А точно ли устройство будет очищено?
                • А при каких условиях очистка не пройдет?
                • OCS 2007 R2: Как получить максимум с одного сервера? Часть 1: Установка

                  polycom_cx700

                     На текущий момент к модному слову "Сollaboration" добавилось еще два не менее модных – "Unified Communications". То, что "UC" переводится как объединенные коммуникации знают пожалуй все ИТ-специалисты, что же действительно это такое может объяснить далеко не каждый. Постараюсь сэкономить ваше время и кратко объясню о чем пойдет речь. Ниже будет дан ответ на вопрос: "Что можно получить от одного единственного сервера OCS 2007 R2 Standard и как его настроить". Приступим…

                • Главная Exchange/UC, Новое Exchange 2010
                  • Outlook Web Access 2010: Новый костюм старого друга.

                    owa 2010 Одной из новых фишек выходящей версии Exchange Server 2010 является переработанный Outlook Web Access. Поскольку OWA более чем популярен среди пользователей Exchange и в последних реализациях мало отличим от полнофункционального Microsoft Outlook, в рамках небольшого обзора хотелось бы пройтись по новинкам данного компонента.

                    • Управление устройствами в Exchange Server: Часть III. Что нас ждет в Exchange Server 2010

                      Pocket_PC_Emulator_Up

                         В первой половине октября произошло знаковое событие – 8-го числа в блоге команды Exchange появилось сообщение о том, что работы над новой версией продукта – Exchange Server 2010 – практически завершены, код финализирован и остается совсем немного времени до выхода полноценного RTM. В новой версии нас ожидает много новых и интересных вещей, большую часть которых можно было попробовать в доступных для общественности версиях Beta и Release Candidate. Меня, по определенным причинам, заинтересовали изменения, произошедшие в этой версии с ActiveSync, и именно о них я и хочу рассказать.