Exchange 2010 роли сервера

Посетителей: 6781 | Просмотров: 10113 (сегодня 5) Шрифт:

В Exchange Server и серверных ролях многое изменилось. До выпуска Exchange Server 2003 приходилось устанавливать все роли на одном сервере. Нельзя было выбрать функции, которые должны быть доступны. Можно было назначить сервер Exchange 2000 или Exchange 2003 в качестве так называемого «сервера переднего плана», но он работал как обычный сервер Exchange в качестве прокси протокола. На нем по-прежнему по умолчанию устанавливались база данных почтовых ящиков и база данных общих папок.

В Exchange Server 2007 была представлена концепция «серверных ролей». Exchange Server 2010 значительно расширяет эту концепцию. Exchange Server 2010 имеет следующие серверные роли, каждая из которых имеет определенную функцию.

• Роль сервера почтовых ящиков
• Роль сервера клиентского доступа
• Роль транспортного сервера-концентратора
• Роль пограничного транспортного сервера
• Роль сервера единой системы обмена сообщениями

Можно установить эти роли серверов на отдельном оборудовании, на котором каждая машина имеет собственную роль. Также можно объединить роли на одном сервере. Например, типичная установка сервера включает роли серверов почтовых ящиков, клиентского доступа и транспортного сервера-концентратора. Средства управления всегда устанавливаются во время установки независимо от устанавливаемой роли сервера.

Однако роль пограничного транспортного сервера не может объединяться с другими ролями. Фактически, роль пограничного транспортного сервера может быть даже частью внутреннего домена, поскольку предназначена для установки в периметре сети. Есть множество причин разделения Exchange Server на несколько серверных ролей.

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

Ниже подробно рассматриваются все серверные роли.

Роль сервера почтовых ящиков

Роль сервера почтовых ящиков — сердце среды Exchange Server 2010. В ней устанавливаются базы данных почтовых ящиков и общих папок. Единственная цель сервера почтовых ящиков — размещение почтовых ящиков и общих папок, и ничего более.

В предыдущих версиях Exchange Server, включая Exchange Server 2007, клиенты Outlook использовали MAPI с подключением напрямую к роли сервера почтовых ящиков. Это больше не так в Exchange Server 2010. Теперь клиенты MAPI подключаются к службе под названием «Клиентский доступ RPC», выполняющейся на сервере клиентского доступа.

Роль сервера почтовых ящиков не выполняет маршрутизацию никаких сообщений. Она только сохраняет сообщения в почтовых ящиках. Роль транспортного сервера-концентратора обрабатывает всею маршрутизацию сообщений, даже между почтовыми ящиками на одном сервере или в одной базе данных почтовых ящиков. Сервер клиентского доступа всегда требуется для доступа к почтовым ящикам. Для реализации модели управления доступом на основе ролей (RBAC) требуются IIS в роли сервера почтовых ящиков, даже если клиент обращается к серверу почтовых ящиков напрямую.

Группы хранения больше не существуют в Exchange Server 2010, но почтовые ящики по-прежнему хранятся в базах данных, как и в Exchange Server 2007. Как и в предыдущих версиях Exchange Server, по-прежнему используется расширенный обработчик хранилищ (ESE), хотя в базу данных и в схему баз данных внесены серьезные изменения. По умолчанию первая база данных на сервере устанавливается в каталог: C:Program Files MicrosoftExchange ServerV14MailboxMailbox Database >

> — это уникальное число для обеспечения уникальности имени базы данных почтовых ящиков в организации сервера Exchange.

С точки зрения производительности и восстановления рекомендуется размещать базу данных и прилагаемые файлы журналов на выделенном диске. Этот диск может размещаться в сети хранения данных, подключенной по оптоволоконному каналу (SAN), iSCSI SAN или в решении системы хранения с прямым подключением (DAS). Целью проектирования было ограничение числа дисковых операций ввода-вывода на уровне, на котором можно установить базу данных и файлы журнала на диске SATA размером 1 ТБ, но это возможно только при настройке копий базы данных и наличии не менее двух копий базы данных почтовых ящиков, чтобы избежать появления единственной точки сбоя.

Роль сервера клиентского доступа

Роль сервера клиентского доступа предоставляет все доступные протоколы доступа к почтовым ящикам. В Exchange Server 2003 корпорация Майкрософт представила концепцию серверов «переднего плана» и «внутренних» серверов. Роль сервера клиентского доступа сравнима с сервером переднего плана Exchange Server 2003.

Все клиенты подключаются к серверу клиентского доступа. После проверки подлинности запросы передаются через прокси соответствующему серверу почтовых ящиков. Связь клиента и сервера клиентского доступа осуществляется по обычным протоколам (HTTP, IMAP4, POP3 и MAPI). Связь сервера клиентского доступа и сервера почтовых ящиков осуществляется через удаленные вызовы процедур (RPC).

Сервер клиентского доступа Exchange Server 2010 предоставляет следующие функции.

• HTTP для Outlook Web App
• Мобильный Outlook (ранее называвшийся RPC/HTTP) для Outlook 2003, Outlook 2007 и Outlook 2010
• ActiveSync для карманных ПК
• Протоколы Интернета POP3 и IMAP4
• MAPI на среднем уровне (MoMT)
• Служба доступности, автообнаружение и веб-службы Exchange: предоставляются для клиентов Outlook 2007 и обеспечивают сведения о доступности, автоматическую настройку клиентов Outlook 2007 и Outlook 2010, загрузки автономной адресной книги и функцию отсутствия на месте.

Сервер клиентского доступа не предоставляет службы SMTP. Транспортный сервер-концентратор обрабатывает все службы SMTP. Для каждого сервера почтовых ящиков на сайте Active Directory требуется по крайней мере один сервер клиентского доступа, а также быстрое соединение между сервером клиентского доступа и сервером почтовых ящиков. Серверу клиентского доступа также требуется быстрое соединение с сервером глобального каталога.

Сервер клиентского доступа должен быть развернут во внутренней сети, а не в периметре сети. Для доступа к серверу клиентского доступа из Интернета необходимо установить сервер Microsoft Internet Security and Acceleration (ISA) Server в периметре сети. Затем требуется «опубликовать» все необходимые для Интернета службы Exchange на этом сервере ISA Server.

Роль транспортного сервера-концентратора

Роль транспортного сервера-концентратора ответственна за маршрутизацию сообщений не только между Интернетом и инфраструктурой Exchange, но также и между серверами Exchange. Сообщения всегда маршрутизируются с помощью роли транспортного сервера-концентратора, даже если почтовые ящики источника и назначения находятся в одной базе данных почтовых ящиков. Например, транспортный сервер-концентратор маршрутизирует сообщения следующим образом.

Шаг 1. Кто-нибудь отправляет сообщение транспортному серверу-концентратору.

Шаг 2. Если отправитель и получатель находятся на одном сервере, сообщение пересылается обратно.

Шаг 3. Если получатель находится на другом сервере почтовых ящиков, сообщение направляется на соответствующий транспортный сервер-концентратор.

Шаг 4. Затем второй транспортный сервер-концентратор доставляет сообщение на сервер почтовых ящиков получателя.

Обеспечение соответствия — основная причина маршрутизации всех сообщений через транспортный сервер-концентратор. Можно отслеживать все сообщения в организации Exchange и принимать необходимые меры для соблюдения правовых требований, закона об отчетности в области медицинского страхования (HIPAA), закона Сарбэйнса – Оксли и других норм. На транспортном сервере-концентраторе для целей соответствия можно настроить следующие агенты.

• Агенты правила транспорта. К сообщениям можно применять действия в соответствии с условиями или фильтрами правил. Правила можно применить к внутренним сообщениям, внешним сообщениям или обоим типам сообщений.
• Агенты ведения журналов. Эти агенты сохраняют копии все сообщений, отправленных или полученных определенным получателем.

Поскольку сервер почтовых ящиков не доставляет сообщения, для каждого сервера почтовых ящиков на сайте Active Directory требуется транспортный сервер-концентратор. Транспортному серверу-концентратору также необходимо быстрое подключение к серверу глобального каталога для запросов Active Directory. Этот сервер глобального каталога должен находиться в том же сайте Active Directory, в котором находится транспортный сервер-концентратор.

Если сообщение предназначается внешнему получателю, оно отправляется с транспортного сервера-концентратора через Интернет. Это может осуществляться через пограничный транспортный сервер Exchange Server 2010 в периметре сети, но транспортный сервер-концентратор также доставляет сообщения напрямую через Интернет.

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

Можно использовать возможности защиты от вирусов Microsoft Forefront для Exchange. Их использование на транспортном сервере-концентраторе обеспечивает проверку входящего и исходящего SMTP-трафика. На сервере почтовых ящиков будет проверяться содержимое базы данных почтовых ящиков, что обеспечивает два уровня защиты.

Роль пограничного транспортного сервера

Роль пограничного транспортного сервера была представлена в Exchange Server 2007 и обеспечивает дополнительный уровень гигиены сообщений. Обычно она устанавливается как шлюз SMTP в периметре сети. Внешние сообщения сначала доставляются роли пограничного транспортного сервера. После прохождения фильтров защиты от вирусов и нежелательной почты эти сообщения перенаправляются транспортному серверу-концентратору во внутренней сети.

Пограничный транспортный сервер также может предоставлять следующие функции.

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

Пограничный транспортный сервер устанавливается в периметре сети. Он может быть членом внутренней службы Active Directory или организации Exchange Server 2010. Пограничный транспортный сервер использует службы Active Directory облегченного доступа к каталогам (AD LDS) для хранения всей информации.

В ранних версиях Windows эта служба называлась режимом Active Directory Application Mode (ADAM). Службы AD LDS сохраняют основные сведения об инфраструктуре Exchange, такие как получатели и транспортный сервер-концентратор, которому пограничный транспортный сервер отправляет сообщения. Они используют функцию синхронизации под названием EdgeSync для обновления базы данных AD LDS. Это обеспечивает передачу информации с транспортного сервера-концентратора пограничному транспортному серверу с регулярными интервалами.

Роль сервера единой системы обмена сообщениями

Роль сервера единой системы обмена сообщениями Exchange Server 2010 объединяет базу данных почтовых ящиков, голосовые сообщения и сообщения электронной почты в одном хранилище. Роль сервера единой системы обмена сообщениями предоставляет доступ ко всем сообщениям в почтовом ящике по телефону или с помощью компьютера. Можно использовать IP-систему или «классическую» аналоговую телефонную систему АТС, хотя в последнем случае для подключения двух систем требуется специальный шлюз IP единой системы обмена сообщениями.

Роль сервера единой системы обмена сообщениями предоставляет следующие функции.

• Ответы на вызовы. Эта функция действует как автоответчик. Если невозможно ответить на вызов, записанное персональное сообщение отправляется в почтовый ящик получателя как файл MP3.
• Абонентский доступ. Эта функция иногда называется «голосовым доступом к Outlook». Абонентский доступ позволяет пользователям прослушивать сообщения голосовой почты в своих почтовых ящиках, используя обычную телефонную линию. Также предоставляется доступ к элементам почтовых ящиков, таким как сообщения и элементы календаря, также можно изменять график встреч.
• Автосекретарь. Эта функция позволяет создавать пользовательское меню в единой системе обмена сообщениями, используя голосовые инструкции. Вызывающий абонент может использовать клавиатуру телефона или голосовые команды для перемещения в меню.

Служба единой системы обмена сообщениями, установленная в роли сервера единой системы обмена сообщениями, тесно взаимодействует с подсистемой работы с речью Microsoft Exchange. Подсистема работы с речью предоставляет двухтональный многочастотный набор (DTMF), также называемый тональным набором, автоматическое распознавание речи и функцию преобразования текста в речь, ответственную за чтение элементов почтового ящика и голосовых меню.

Роль сервера единой системы обмена сообщениями должна быть установлена на сайте Active Directory вместе с транспортным сервером-концентратором. Последний сервер ответственен за маршрутизацию сообщений серверам почтовых ящиков. Также требуется быстрое соединение с сервером глобального каталога. Если возможно, также следует установить роль сервера почтовых ящиков максимально близко к роли сервера единой системы обмена сообщениями, желательно в пределах одного сайта с достаточным сетевым подключением.

Функции обеспечения высокой доступности, управления и обеспечения соответствия требованиям делают Exchange Server 2010 привлекательным решением. Фактически, новые функции Exchange Server 2010, как правило, обеспечивают снижение сложности, что всегда предпочтительно.

Введение

В Exchange 2000 и Exchange 2003 разрешения выдавались через мастер делегирования Delegation Wizard, который располагался в консоли Exchange System Manager. Этот мастер позволял администратору присвоить одну из трех ролей пользователю, которому был нужен административный доступ. Вот эти три роли: Exchange View-Only Administrator, Exchange Administrator и Exchange Full Administrator. И хотя выдача пользователям этих ролей давала возможность разграничить уровни доступа, основная проблема при этом состояла в том, что для многих организаций такого разграничения было недостаточно. К примеру, хотя можно было дать разрешения на уровне корпоративной или административной групп, давать доступ к отдельным серверам было невозможно; если администратор получал доступ на уровне административной группы, он получал доступ ко всем серверам Exchange, относящимся к данной группе.

Ситуация с детализацией разрешений в Exchange 2007 улучшилась. Роль Exchange Full Administrator, которая была в Exchange 2000 и Exchange 2003, а теперь в Exchange 2007 называется Exchange Organization Administrator, по-прежнему дает администраторам полный доступ ко всем объектам Exchange во всей организации. Роль Exchange View-Only Administrators также осталась, обеспечивая администраторам разрешение на чтение во всей организации Exchange. В Exchange 2007 появились еще три эффективные роли:

• Exchange Recipient Administrator — Позволяла администраторам модифицировать настройки Exchange, касающиеся пользователей, групп, контактов и общих папок
• Exchange Public Folder Administrator — Была введена в Exchange 2007 Service Pack 1, и, согласно своему названию, позволяла администраторам контролировать общие папки
• Exchange Server Administrator — Позволяла администраторам полностью управлять определенным сервером Exchange 2007 в случае, если они также являлись членами локальной группы Administrators на этом сервере

Хотя модель разрешений в Exchange 2007 и представляла собой значительное улучшение по сравнению с моделями из предыдущих версий Exchange, она все еще не могла удовлетворить различным административным сценариям, возникающим в различных организациях. В сущности, роли в Exchange 2007 все еще давали слишком много власти администраторам в децентрализованной организации Exchange, что делало сложной задачу ограничения доступа для конкретных администраторов. И хотя существовала возможность реализации модели разделенных разрешений в Exchange 2007 при помощи списков контроля доступа (Access Control List — ACL), это было сложной процедурой, которая часто приводила к ошибкам и трудноразрешимым проблемам.

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

Модель RBAC

Модель разрешений, используемая в Exchange 2010, называется Role Based Access Control (RBAC – контроль доступа на основании ролей). Суть RBAC в том, что она позволяет очень точную настройку, вследствие чего вы легко сможете контролировать уровень доступа для пользователей и администраторов. Например, если у вас есть служба техподдержки, которой нужно управлять квотами почтовых ящиков, модель RBAC позволяет это реализовать.

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

Первый важный принцип в RBAC состоит в том, что есть три различных способа выдачи разрешений:

• Группы управляющих ролей
• Политики назначения управляющих ролей
• Прямое делегирование ролей пользователям

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

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

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

Группы управляющих ролей

В Exchange 2010 Microsoft значительно упростила задачу выдачи обычных наборов разрешений администраторам и специализированным пользователям, создав заранее 11 групп управляющих ролей по умолчанию. Поместив пользователя или группу в группу управляющих ролей, вы назначаете роли, связанные с данной группой управляющих ролей, выделив этому пользователю или группе необходимые разрешения. Microsoft использует термин role holder(носитель роли) для обозначения администратора или специализированного пользователя, добавленного в группу управляющих ролей. Эти 11 групп управляющих ролей по умолчанию создаются при установке Exchange 2010. Точнее, эти группы управляющих ролей создаются тогда, когда в процессе установки Exchange 2010 производятся действия по подготовке Active Directory, которые можно выполнить отдельно, запустив программу установки Exchange 2010 setup.com с ключом /PrepareAD. На группы управляющих ролей можно посмотреть в организационной единице Microsoft Exchange Security Groups Organizational Unit (OU), создаваемой в корневом домене в процессе установки Exchange. Эта OU и входящие в нее группы показана на Рисунке 1. Обратите внимание, что из 16 групп, показанных на Рисунке 1, только 11 являются группами управляющих ролей; они отмечены специально.

Рисунок 1: Группы управляющих ролей по умолчанию

Вот краткое описание групп управляющих ролей по умолчанию, автоматически созданных при установке Exchange 2010:

• Delegated Setup — Члены этой группы управляющих ролей получают возможность запускать программу установки Exchange 2010, и, следовательно, развертывать, но не устанавливать новый сервер Exchange 2010. Развертывание можно осуществлять только на тех серверах, которые уже получили разрешения от администратора с дополнительными полномочиями.
• Discovery Management — Участник группы Discovery Management имеет возможность выполнять поиски по всем почтовым ящикам в организации Exchange, а также включать функцию Legal Hold в Exchange 2010. Подробнее эту группу мы рассмотрим позднее в нашем цикле статей.
• Help Desk — Члены группы Help Desk получают полномочия, обычно нужные для службы техподдержки, например, модификация данных о пользователях, такие как: адрес и номер телефона.
• Hygiene Management — Эта группа управляющих ролей используется для обеспечения полномочиями, связанными с управлением и настройкой антивирусного и антиспамового элементов в Exchange 2010.
• Organization Management — Группа Organization Management аналогична административной роли Exchange Full Administrator в Exchange 2003 и роли Exchange Organization Administrator в Exchange 2007. По сути, членство в этой группе дает пользователю право почти любую задачу в Exchange 2010 за исключением некоторых, основной среди которых является возможность осуществлять поиск по почтовым ящикам; которую можно получить через группу Discovery Management.
• Public Folder Management — Эта группа управляющих ролей дает возможность своим членам управлять средой общих папок.
• Recipient Management — Участник этой группы может создавать и модифицировать получателей Exchange.
• Records Management — Группа Records Management дает возможность своим членам контролировать и настраивать функции соответствия в Exchange 2010. Примеры подобных функций включают транспортные правила, настроенные на сервере Hub Transport, а также классификации сообщений в Outlook.
• Server Management — Эта группа управляющих ролей предоставляет возможность управлять всеми серверами Exchange в организации. Полномочия, получаемые участниками этой группы работают, таким образом, на уровне конфигурации сервера, находящейся в консоли Exchange Management Console, и не работают, скажем, на организационном уровне, находящемся в консоли Exchange Management Console.
• UM Management — Согласно своему наименованию, данная группа управляющих ролей дает возможность управлять всеми аспектами среды Unified Messaging.
• View-Only Organization Management — Эта группа позволяет своим членам просматривать конфигурацию любого элемента в организации Exchange.

Участие в группе ролей управления

В этом цикле статей мы сконцентрируемся на одной группе ролей управления, а именно на группе ролей Discovery Management. Как предполагает название этой группы, включение пользователя в эту группу дает ему возможность выполнять поиск в почтовых ящиках сотрудников для юридических целей. Концентрируясь на одной группе ролей управления, мы сможем посмотреть, как различные компоненты RBAC работают вместе для предоставления участникам этой группы возможности выполнять поиск в почтовых ящиках. После рассмотрения этого процесса вы сможете понять, как работают группы ролей управления и, возможно, у нас останется время на рассмотрение остальных стандартных групп ролей управления и того, как их можно использовать в организации Exchange.

Давайте начнем с рассмотрения команд Exchange Management Shell, необходимых для управления принадлежностью к группам ролей управления, и того, как можно контролировать принадлежность к группе роли Discovery Management. По умолчанию эта группа не содержит участников.

Команда Add-RoleGroupMember используется для добавления участников в эту группу. Таким образом, чтобы добавить пользователя ‘Neil’ в группу роли Discovery Management, нужно использовать следующую команду:

Add-RoleGroupMember ‘Discovery Management’ ‘Member Neil

Подобно этому, можно легко удалять участников из группы ролей управления с помощью команды Remove-RoleGroupMember. Чтобы удалить добавленного нами пользователя, воспользуемся следующей командой:

Remove-RoleGroupMember ‘Discovery Management’ ‘Member Neil

Обратите внимание, что команда Remove-RoleGroupMember без ‘Confirm параметра со значением $false приведет к тому, что Exchange Management Shell запросит у вас подтверждение на удаление, поэтому следует учитывать данный факт, используя эту команду в сценарии.

Если вы в какой-то момент захотели получить список членов группы Discovery Management, используйте команду Get-RoleGroupMember, как показано на рисунке 2.

Рисунок 2: Команда Get-RoleGroupMember

Наконец, также есть полезная команда Update-RoleGroupMember, которую можно использовать для изменения принадлежности к группам ролей управления. Допустим, пользователь Neil уже является участником группы роли Discovery Management, как видно из рисунка 2. Если нам потребуется добавить двух новых участников, Mark и Rob, в группу ролей управления, и в то же время удалить существующих в ней участников, команду Update-RoleGroupMember можно использовать следующим образом:

Update-RoleGroupMember ‘Discovery Management’ ‘Members Mark,Rob ‘Confirm:$false

Результаты команды показаны на рисунке 3, где показана принадлежность к группе ролей управления до и после выполнения команды Update-RoleGroupMember.

Рисунок 3: Обновление принадлежности к группе ролей управления

Роли управления

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

Для начала нужно понять, что группа ролей управления представляет собой группу, в которой имеется одна или несколько ролей управления. Для просмотра свойств этой группы ролей управления, которые будут включать информацию о том, какие роли назначены для этой группы, нужно воспользоваться Get-RoleGroup командой для соответствующего имени группы и обработать результаты в команде форматирования списка (сокращенно ‘fl’). Например:

Get-RoleGroup ‘Discovery Management’ | fl

Результаты этой команды показаны на рисунке 4.

Рисунок 4: Результаты команды Get-RoleGroup

На рисунке 4 видно, что с группой роли Discovery Management связаны несколько интересных параметров, но на данный момент нас интересует параметр ролей (Roles), который является четвертым параметром в списке на рисунке 4. Параметр Roles показывает, что группе роли Discovery Management назначены роли управления Legal Hold и Mailbox Search. Это две встроенные роли управления, которые идут с Exchange 2010. На момент написания этой статьи имелось 64 различных встроенных роли управления в Exchange 2010. Запустив команду Get-ManagementRole, можно получить весь список ролей, как показано на рисунке 5. Обратите внимание, что не все роли управления показаны на рисунке 5, поскольку результаты команды не влезли в снимок.

Рисунок 5: Стандартные роли управления

Любой пользователь, который добавлен в группу роли Discovery Management, получает роли управления Legal Hold и Mailbox Search. Вполне очевидно из названия этих ролей, что именно роль Mailbox Search дает пользователю возможность выполнять поиск в почтовых ящиках для юридических целей поиска информации. Сами роли управления содержат группу команд, которые позволено выполнять пользователю, являющемуся участником данной группы ролей управления. Эти команды называются записи ролей управления (management role entries), и о них мы поговорим позже. А пока нам нужно рассмотреть то, что называется задания ролей управления (management role assignments), которые показаны на рисунке 4 в результатах параметра RoleAssignments.

Задания ролей управления

Задания ролей управления представляют собой связи между группой ролей управления и ролями управления. Если вы взгляните на рисунок 4, вы увидите, что группа роли Discovery Management имеет два задания ролей управления:

• Legal Hold-Discovery Management
• Mailbox Search-Discovery Management

Поскольку мы рассматриваем элемент почтового поиска в группе управления, давайте вызовем свойства задания роли Mailbox Search-Discovery Management. Для этого используем команду Get-ManagementRoleAssignment:

Get-ManagementRoleAssignment ‘Mailbox Search-Discovery Management’ | fl

Результаты команды показаны на рисунке 6.

Рисунок 6: Свойства задания роли управления

Одним из ключевых моментов в задании роли управления является то, что оно может использовать границы управления. Более того, границу управления можно настроить по-разному для серверов и объектов получателей. В середине рисунка 6 видно, что атрибуты RecipientReadScope и RecipientWriteScope имеют значение Organization. Это означает, что границы этого задания роли управления для получателей составляют пределы всей организации Exchange, а не его подразделения (например). Конечно, этого и следовало ожидать, так как пользователям, принадлежащим к этой группе, потребуется возможность осуществлять поиск в почтовых ящиках всей организации.

На рисунке 6 также видно, что RoleAssignmentDelegationType атрибут имеет значение Regular, что означает, что задание роли Mailbox Search-Discovery Management является регулярным заданием. Регулярное задание роли управления означает, что (в данном случае) оно позволяет участникам группы роли Discovery Management получать доступ к записям роли управления, командам, связанным с ролью управления Mailbox Search. Другим типом задания роли управления является delegating задание роли управления, которое дает пользователям возможность назначать роли другим участникам группы. Для этих заданий роли управления атрибут RoleAssignmentDelegationType будет иметь значение DelegatingOrgWide.

Заключение

На этом завершаем вторую часть цикла статей, в которой мы рассмотрели связи между группами ролей управления, ролями управления и заданиями ролей управления. В третьей части мы завершим разговор рассмотрением записей ролей управления и конечного результата, посредством которого пользователь может выполнять поиск в почтовых ящиках, являясь участником группы Discovery Management.

Автор: Нейл Хобсон (Neil Hobson)

При настройке гибридного развертывания в организации Exchange 2010 настоятельно рекомендуется по крайней мере один сервер Exchange Server 2013 с ролями сервера клиентского доступа и почтовых ящиков в существующей организации Exchange 2010. When you configure a hybrid deployment in an Exchange 2010 organization, we strongly recommend at least one Exchange 2013 server with the Client Access and Mailbox server roles in your existing Exchange 2010 organization. Серверы клиентского доступа и почтовых ящиков Exchange 2013 координируют связь между существующей локальной организацией Exchange 2010 и организацией Exchange Online. The Exchange 2013 Client Access and Mailbox servers coordinate communications between your existing Exchange 2010 on-premises organization and the Exchange Online organization. Это взаимодействие включает в себя функции транспорта сообщений и обмена ими между локальной организацией и организацией Exchange. This communication includes message transport and messaging features between the on-premises and Exchange Online organizations.

Мы настоятельно рекомендуем установить несколько серверов Exchange 2013 в локальной организации, чтобы повысить надежность и доступность функций гибридного развертывания. We highly recommend installing more than one Exchange 2013 server in your on-premises organization to help increase reliability and availability of hybrid deployment features.

Роли серверов в гибридном развертывании Server roles in a hybrid deployment

Ниже представлен краткий обзор ролей серверов Exchange 2013 в гибридном развертывании: Here is a quick overview of the Exchange 2013 server roles in a hybrid deployment:

Роль сервера клиентского доступа: роль сервера клиентского доступа Exchange 2013 продолжает предоставлять многие из функций, которые обычно предоставляются серверами клиентского доступа Exchange 2010 в Организации, с некоторыми дополнениями, необходимыми для поддержки гибридного развертывания и сосуществования с Exchange 2010. Client Access server role: The Exchange 2013 Client Access server role continues to provide many of the same functions that are typically provided by Exchange 2010 Client Access servers in your organization with some additions required to support a hybrid deployment and coexistence with Exchange 2010. Сервер клиентского доступа также обрабатывает защищенные почтовые сообщения, отправленные из организации Exchange Online в локальную организацию, правила транспорта, политики ведения журнала и доставку сообщений на серверы почтовых ящиков при гибридном развертывании. The Client Access server also handles secure mail messages sent from the Exchange Online organization to the on-premises organization, as well as handling transport rules, journaling policies, and message delivery to Mailbox servers in a hybrid deployment. Выделенный соединитель приема настраивается на сервере клиентского доступа для поддержки безопасной передачи гибридной почты. A dedicated Receive connector is configured on the Client Access server to support secure hybrid mail transport. Все подключения клиентов, в том числе связанные с клиентским доступом Outlook, Outlook Web App и мобильным Outlook, устанавливаются на гибридном сервере через роль сервера клиентского доступа. All client connectivity, including Outlook client access, Outlook Web App, and Outlook Anywhere goes through the Client Access server role. Функции связей между локальной организацией и организацией Exchange Online, такие как обмен сведениями о занятости, также обрабатываются на сервере ролью сервера клиентского доступа. Organization relationship features between the on-premises and Exchange Online organizations, such as free/busy sharing, are also handled by the Client Access server role.

Роль сервера почтовых ящиков: роль сервера почтовых ящиков Exchange 2013 обрабатывает защищенные сообщения электронной почты, отправленные в организацию Exchange Online из локальной организации. Mailbox server role: The Exchange 2013 Mailbox server role handles secure mail messages sent to the Exchange Online organization from the on-premises organization. Хотя это не свойственно для данной роли, она также может размещать локальные почтовые ящики получателей и поддерживать связь с организацией Exchange Online с помощью прокси-сервера через локальный сервер клиентского доступа. Although not typical, it also can host on-premises recipient mailboxes and communicate with the Exchange Online organization by proxy via the on-premises Client Access server. Выделенный соединитель отправки по умолчанию настраивается на сервере ролью почтовых ящиков для поддержки безопасной передачи гибридной почты. A dedicated Send connector is configured by default on the Mailbox server role to support secure hybrid mail transport.

Дополнительные сведения см. в разделе Mailbox Server. Learn more at Mailbox Server.

В зависимости от желаемой конфигурации гибридного развертывания, на сервере Exchange 2013 требуется установить одну или несколько ролей сервера: Depending on the hybrid deployment configuration that you want, an Exchange 2013 server requires one or both of the server roles to be installed on it:

Один сервер Exchange Server: Если вы решили установить один сервер Exchange в локальной организации, необходимо установить роли сервера клиентского доступа и сервера почтовых ящиков на один сервер. Single Exchange server: If you choose to install a single Exchange server in your on-premises organization, you’ll need to install both the Client Access and Mailbox server roles on the single server.

Несколько серверов Exchange Server: Если вы решили установить более одного сервера Exchange Server в локальной организации, вы можете установить роли сервера на отдельных серверах в локальной организации. More than one Exchange server: If you choose to install more than one Exchange server in your on-premises organization, you can install the server roles on separate servers in your on-premises organization. Например, можно установить один сервер Exchange 2013 с установленными ролями почтовых ящиков и клиентского доступа, а также установить другой сервер Exchange с установленной ролью сервера клиентского доступа. For example, you could install one Exchange 2013 server that has the Mailbox and Client Access roles installed and also install another Exchange server that has only the Client Access server role installed. Однако лучшей методикой и рекомендованной конфигурацией сервера является установка ролей сервера клиентского доступа и сервера почтовых ящиков на каждом сервере Exchange 2013, развернутом в локальной организации. However, the best practice and recommended server configuration is to install both the Client Access and Mailbox server roles on each Exchange 2013 server deployed in your on-premises organization.

Функциональные возможности сервера Exchange в гибридных развертываниях Exchange server functionality in hybrid deployments

Серверы Exchange обеспечивают несколько важных функций для локальной организации в гибридном развертывании: Exchange servers provide several important functions for your on-premises organization in a hybrid deployment:

Федерация: серверы Exchange 2013 и Exchange 2010 позволяют создать доверие федерации для локальной организации с помощью шлюза Microsoft Federation Gateway. Federation: Exchange 2013 and Exchange 2010 servers enable you to create a federation trust for your on-premises organization with the Microsoft Federation Gateway. Шлюз Microsoft Federation Gateway — это облачная служба, предоставляемая корпорацией Майкрософт, которая действует как брокер доверия между локальной организацией и организацией-владельцем Office 365. The Microsoft Federation Gateway is a free, cloud-based service offered by Microsoft that acts as the trust broker between your on-premises organization and the Office 365 tenant organization. Наличие федерации является одним из требований для создания связи между локальной организацией и организацией Exchange Online. Federation is a requirement for creating an organization relationship between the on-premises and the Exchange Online organizations.

Дополнительные сведения см. в разделе Understanding Federation. Learn more at Understanding Federation.

Связи Организации: серверы Exchange 2013 с ролью сервера клиентского доступа позволяют создавать связи Организации между локальной организацией и организацией Exchange Online. Organization relationships: Exchange 2013 servers with the Client Access server role enable the creation of organization relationships between the on-premises and Exchange Online organizations. Связи организаций требуются для других различных служб в гибридном развертывании, в том числе для обмена данными календаря и сведениями о занятости, отслеживания сообщений и перемещения почтовых ящиков между локальными организациями и организациями Exchange Online. Organization relationships are required for many other services in a hybrid deployment, including calendar free/busy information sharing, message tracking, and mailbox moves between the on-premises and Exchange Online organizations.

Транспорт сообщений: серверы Exchange 2013 с ролями серверов клиентского доступа и почтовых ящиков отвечают за транспортировку сообщений в гибридном развертывании. Message transport: Exchange 2013 servers with the Client Access and Mailbox server roles are responsible for message transport in a hybrid deployment. Используя соединители отправки и получения, они выступают в качестве конечной точки подключения для входящих внешних сообщений и также обеспечивают доставку исходящих сообщений в Интернет и организацию Exchange Online. Using Send and Receive connectors, they serve as the connection endpoints for incoming external messages and also provide outbound message delivery to the Internet and the Exchange Online organization.

Защита транспорта сообщений: серверы Exchange 2013 с ролями серверов клиентского доступа и почтовых ящиков помогают защитить обмен сообщениями между локальной организацией и организацией Exchange Online с помощью функции безопасности домена в Exchange 2013. Message transport security: Exchange 2013 servers with the Client Access and Mailbox server roles help to secure message communication between the on-premises and Exchange Online organizations by using the Domain Security functionality in Exchange 2013. Безопасность можно усилить путем использования взаимной проверки подлинности по протоколу TLS и шифрования при передаче сообщений. Security can be increased by using mutual transport layer security authentication and encryption for message communications.

Outlook Web App: Exchange 2013 Servers с ролью сервера клиентского доступа. Настройка одной конечной точки URL-адреса для внешних подключений к локальным почтовым ящикам и почтовым ящикам Exchange Online. Outlook Web App: Exchange 2013 servers with the Client Access server role support configuring a single URL endpoint for external connections to on-premises and Exchange Online mailboxes. Для локальных почтовых ящиков серверы клиентского доступа настраиваются на обработку запросов Outlook Web App. For on-premises mailboxes, Client Access servers are configured to service Outlook Web App requests. Для почтовых ящиков организации Exchange Online серверы клиентского доступа настраиваются на автоматическое отображение ссылки на конечную точку Outlook Web App в организации Exchange Online. For Exchange Online organization mailboxes, Client Access servers are configured to automatically display a link to the Outlook Web App endpoint on the Exchange Online organization.

Топология серверов Exchange Exchange server topology

Если для поддержки гибридного развертывания добавляются дополнительные серверы Exchange 2013, развертывание сервера Exchange выполняется во многом аналогично развертыванию любого другого сервера Exchange в существующей организации Exchange 2010. Настройка существующей локальной организации Exchange 2010 для гибридного развертывания не требует какой-либо особой топологии серверов Exchange. Тем не менее, на серверах Exchange 2010 необходимо установить пакет обновления 3 (SP3) для Exchange 2010 и накопительный пакет обновления 1 (CU1) для Exchange 2013, чтобы обеспечить совместимость и полную гибридную функциональность с Office 365. If you add additional Exchange 2013 servers to support your hybrid deployment, the Exchange server is deployed much like any other Exchange server is deployed to your existing Exchange 2010 organization. Configuring your existing on-premises Exchange 2010 organization for a hybrid deployment doesn’t require any special Exchange server topology. However, you must install Exchange 2010 Service Pack 3 (SP3) on your Exchange 2010 servers and also install Exchange 2013 Cumulative Update 1 (CU1) or greater to enable compatibility and full hybrid functionality with Office 365.

В следующей таблице кратко описаны изменения в службах после развертывания гибридного решения. The following table describes briefly the changes in services after configuring a hybrid deployment.

Служба Service	До гибридного развертывания Before hybrid deployment	После гибридного развертывания After hybrid deployment	Описание Description
Транспорт сообщений (входящие и исходящие) Message transport (inbound and outbound)	Сервер клиентского доступа Exchange 2010 Exchange 2010 Client Access server	Сервер клиентского доступа Exchange 2013 или служба защиты Exchange Online (EOP) в Office 365 Exchange 2013 Client Access server or Exchange Online Protection (EOP) included with Office 365	Запись MX (почтового обменника) для домена может оставаться неизменной или обновляться для ссылки на службу EOP. The MX (mail exchanger) record for the domain may remain unchanged or be updated to point to EOP.
Общедоступный URL-адрес Outlook Web App Outlook Web App public URL	Сервер клиентского доступа Exchange 2010 Exchange 2010 Client Access server	Сервер клиентского доступа Exchange 2013 Exchange 2013 Client Access server	Серверы клиентского доступа Exchange 2013 используют прокси-сервер для получения запросов Outlook Web App на локальные почтовые ящики на серверах клиентского доступа Exchange 2010. Запросы Outlook Web App на почтовые ящики, размещенные в Exchange Online, предоставляются со ссылкой на URL-адрес Outlook Web App Exchange Online. Exchange 2013 Client Access servers proxy Outlook Web App requests for on-premises mailboxes to Exchange 2010 Client Access servers. Outlook Web App requests for mailboxes hosted on Exchange Online are provided with a link to the Exchange Online Outlook Web App URL.

Программное обеспечение серверов Exchange Exchange server software

Exchange 2013 с накопительным пакетом обновления 1 (CU1) или более поздних версий предусмотрены функции гибридного развертывания с помощью мастера гибридной конфигурации. При установке дополнительных серверов Exchange 2013 можно использовать любые носители с накопительным пакетом обновления 1 (CU1) для Exchange 2013. Exchange 2013 CU1 or greater enables hybrid deployment functionality with the Hybrid Configuration wizard. You can use any Exchange 2013 CU1 or greater media when installing additional Exchange 2013 servers.

Сведения о том, как скачать последнюю версию Exchange Server, можно найти в статье Updates for Exchange. For information on how to download the latest version of Exchange Server, see Updates for Exchange.

При настройке гибридного развертывания необходимо лицензировать гибридный сервер. You need to license your hybrid server when you configure a hybrid deployment. HCW теперь может обнаруживать и лицензировать Ваш заданный локальный сервер Exchange 2010, Exchange 2013 или Exchange 2016 без необходимости переходить на отдельный веб-сайт или позвонить в службу поддержки Майкрософт. The HCW is now able to detect and license your designated on-premises Exchange 2010, Exchange 2013, or Exchange 2016 hybrid server for free without going to a separate web site or calling Microsoft support. Здесьможно получить доступ к HCW. You can access the HCW here. Обратите внимание на то, что бесплатная лицензия Exchange Server недоступна для гибридных серверов Exchange 2019. Note that the free Exchange Server license is not available for Exchange 2019 hybrid servers.