Windows SharePoint Services (WSS) 3.0 и Microsoft Office SharePoint Server (MOSS) 2007 позволяют передавать содержание списков и библиотек по электронной почте. Эта функция, добавленная к существующим методам, таким как загрузка через браузер, предоставляет конечным пользователям больше гибкости при обновлении содержимого групповых сайтов. Отправка по электронной почте - особенно удобный способ добавления контента в SharePoint для мобильных сотрудников, у которых не всегда есть под рукой надежное сетевое соединение.
Microsoft SharePoint Portal Server 2003 позволяет отправлять по электронной почте документы в библиотеки документов через почтовый ящик общей папки Exchange Server, но это окольный путь. WSS 3.0 и MOSS 2007 совершенствуют процесс при помощи прямой отправки сообщений в списки и библиотеки разных типов, без опоры на общие папки Exchange. Это долгожданное усовершенствование, но в реализации есть несколько несоответствий, которые могут сбить вас с толку. В этой статье речь пойдет о том, как электронная почта работает с SharePoint 2007. SharePoint также поддерживает отправку почты для уведомления о различных событиях, но этот вопрос останется за рамками статьи.
Базовая архитектура
Во-первых, мне хотелось бы подчеркнуть, что SMTP в SharePoint нет, и его не заботит, какая система работы с сообщениями используется; чтобы отправлять элементы электронной почтой в списки и библиотеки SharePoint, Exchange (или другая специфическая система) не требуется. По существу, SharePoint проверяет определенную папку, отыскивая правильно сформатированные сообщения SMTP. SharePoint не заботится о том, как эти сообщения попадают в папку, он только вскрывает их и пытается соотнести каждое сообщение со списком или библиотекой, которые находятся где-то на ферме серверов SharePoint. Он не возвращает уведомлений о невозможности доставки и не обрабатывает запросы о прочтении или доставке. Вот что я имел в виду, когда написал, что в SharePoint нет SMTP.
В обычной среде папка, которую проверяет SharePoint, является папкой загрузки сообщений для службы SMTP, запускаемой на внешнем Web-сервере внутри фермы. Общая инфраструктура обмена сообщениями настроена так, что предназначенные SharePoint сообщения направляются службе SMTP. Как реализуется маршрутизация, зависит от конкретной почтовой организации, но обычно SharePoint идентифицируется c использованием его собственного пространства имен SMTP и комбинации записей почтового сервера (MX) и почтовых коннекторов, должным образом маршрутизирующих трафик.
Если элемент в проверяемой папке может быть успешно разобран как сообщение SMTP, SharePoint использует адрес To для поиска пункта назначения - списка или библиотеки в текущей ферме. В зависимости от различных параметров настройки (кому разрешено отсылать почту в конкретный список и типа этого списка), электронная почта и вложения добавляются к этому списку, они становятся обычными элементами списка и, таким образом, попадают в поле зрения служб SharePoint, таких как поиск и представления.
Настройка входящих сообщений
Чтобы структура электронной почты была полезной, нужно указать, как и где внешние серверы будут проверять папку, как сопоставлять адреса входящих сообщений со списками и библиотеками и как управлять процессом, а также что и кому разрешается делать через почту. Первым делом следует запустить обработку входящей почты на уровне фермы через закладку Operations в SharePoint Central Administration. С работающей проверкой входящей почты SharePoint запускает по таймеру фоновое задание, которое называется Windows SharePoint Services Incoming E-Mail. Запускается оно каждую минуту на всех внешних серверах, чтобы запросить папку, есть ли новые сообщения. Как и все плановые задания, это задание контролируется службой Windows SharePoint Services Timer; если служба Timer не запущена, входящая почта обрабатываться не будет. Задание по обработке входящих сообщений запускается по умолчанию на всех внешних серверах, но конфигурация папки загрузки устанавливается в масштабе всей фермы. Следовательно, все внешние серверы в ферме, которые запускают службу обработки входящих сообщений, должны иметь одинаковую папку. Таким образом, если папка имеет адрес C:\Drop, все внешние серверы должны иметь папку C:\Drop и маршрутизация почты должна обеспечивать "складирование" входящих сообщений в этой папке.
Необходимо запустить службу Windows SMTP на внешних серверах, чтобы получать почту от других серверов SMTP: например, можно послать сообщения с Exchange 2007 прямо в WSS. Режим автоматической настройки на странице Configure Incoming E-Mail Settings в Central Administration соответствует потребностям многих организаций. Однако, если вы не используете службу Windows SMTP и хотите заполнять папку, используя другой механизм, нужно задать расширенные настройки папки вручную, используя графический интерфейс. Замечу, что использование расширенного режима не дает возможности указать безопасные серверы SMTP.
В автоматическом режиме можно указать, что вся входящая почта принимается, или определить список IP-адресов, которые принадлежат тем серверам SMTP, с которых вы получаете почту. Выбор зависит от всей топологии маршрутизации SMTP. Например, у вас может быть один центральный сервер SMTP, который пропускает всю почту, а нужно, чтобы этот сервер был единственным для обработки почты. Служба входящих сообщений анализирует заголовок Received внутри каждого сообщения, которое забирается из папки загрузки, чтобы определить, принимать ли сообщение.
Если вы не используете автоматический режим, требуется гарантировать, что у учетной записи, используемой для запуска службы Windows SharePoint Services Timer, есть разрешения modify на заданную папку, таким образом, служба сможет удалять сообщения после их обработки. Неудачная попытка это сделать приводит к многократной доставке сообщения.
Последний шаг настройки на данном этапе - указать, для какого SMTP-домена ваша ферма WSS обрабатывает почту. Например, для почтового адреса mi6@wss.spyrus.com домен SMTP будет wss.spysrus.com. В этом примере любой список или библиотека будут иметь адрес something@wss.spysrus.com. С точки зрения инфраструктуры проблема состоит в обеспечении гарантии того, что каждое почтовое сообщение, адресованное wss.spysrus.com, найдет свой путь к внешним серверам вместе с работающей службой обработки входящих сообщений. Вы могли сделать это разными способами, но с большей вероятностью настроили записи MX в DNS и коннекторы для других внутренних почтовых систем. Например, в Exchange 2007 можно было бы установить коннектор Send, который обрабатывает пространство имен wss.spysrus.com и указывает, что вы хотите отправить все сообщения для этого адресного пространства в интеллектуальный хост - хост, который является внешним сервером.
Разрешение доставки в список или библиотеку
После того как почта настроена на уровне фермы, администраторы сайта могут разрешить отправку почты в индивидуальные списки и библиотеки. Не все типы списков подходят для этого, но те, которые годятся, можно увидеть в списке Incoming email settings в разделе Communications. Доступные настройки зависят от типа списка - например, библиотека документов запрашивает, что вы собираетесь делать с вложением, а список блогов позволяет выбрать, будет ли входящий элемент опубликован немедленно. На экране 1 показаны доступные настройки для библиотеки документов.
Каждый список, который вы делаете доступным для приема почты, должен иметь почтовый адрес, уникальный в данной ферме. Но администратор сайта может выбирать только пользовательскую часть адреса, которую SharePoint хранит в таблице AllLists внутри базы данных контента, связанной с коллекцией сайта. Доменная часть адреса указывается на уровне фермы. Этот метод именования для почтовых адресов, вероятно, не подходит для большинства организаций. Почему? Во-первых, SharePoint не предлагает управление именами. Сотрудники, скорее всего, будут выбирать общие имена для общих списков - например, какой вы укажете почтовый адрес для своего списка объявлений Announcements? Announcements@domain.com? Но так может сделать любой на сайте SharePoint в ферме, и не существует способа проверить, какие текущие почтовые адреса используются, кроме как методом проб и ошибок, - SharePoint заблокирует попытку создания имени, которое уже существует. Таким образом, это ведет к помехам для конечного пользователя. SharePoint также не предоставляет никакого способа проверки достоверности того, что почтовый адрес согласуется с корпоративной политикой форматирования или использования ошибочных или неподходящих имен. Более того, отправитель сообщения не может узнать, было ли оно успешно доставлено в нужный список SharePoint и было ли доставлено вообще. Служба SMTP просто получает входящее сообщение, но она никоим образом не связана с SharePoint и, следовательно, не может подтвердить достоверность того, что адрес электронной почты указывает на список или библиотеку.
Последний аспект, о котором нужно упомянуть на этой стадии, - это безопасность; ее параметры можно настроить для входящей почты. Вы можете выбрать, принимать вам только почту, основываясь на разрешениях, установленных на список или библиотеку, либо принимать почту от любого отправителя.
Управление каталогом
Настроив маршрутизацию SMTP, вы можете отсылать элементы в SharePoint, вводя электронный адрес места назначения в сообщении. Однако реальные электронные адреса использовать затруднительно, поэтому большая часть электронных систем позволяет просматривать адреса, используя общие соглашения, такие как первое и последнее имена. WSS может связываться с Active Directory (AD) или другой службой каталогов, для этой цели существует Directory Management Service (DMS), Web-служба (SharepointEmailWS.asmx), которая не устанавливается по умолчанию на внешнем сервере и запускается на уровне фермы, через настройки входящей почты. Давайте посмотрим, как работает DMS и какие задачи он помогает решить, а также какие проблемы может создать.
DMS создает объекты Contact в Active Directory, чтобы представить списки и библиотеки, активированные для электронной пересылки. Кроме того, она может создать группы рассылки для представления групп сайтов, но эта функция не является предметом обсуждения в нашей статье. Для конечных пользователей, возможно, будут удобны эти записи со знакомой функцией поиска адреса и групповой рассылки, как и у других почтовых объектов. Я говорю "возможно", потому что активация DMS создает некоторые проблемы, которых не было бы, если бы вы ее не использовали. Надо отметить, что DMS не обязательна для поддержки получения сообщений электронной почты.
Настройка DMS - это вопрос задания организационного подразделения (OU) в Active Directory, где будут создаваться контакты. Самое лучшее - создать организационное подразделение, связанное с MOSS, что облегчит управление. Необходимо снабдить пул приложений SharePoint Central Administration учетной записью с разрешением на запись в эту OU, поэтому придется поработать со всеми, кто ответствен за вашу Active Directory. Вы также должны указать имя сервера SMTP для входящей почты - в конечном счете эта информация найдет свое место в электронных адресах, ассоциированных с контактами, которые создает DMS. Обратите внимание, что этот адрес может отличаться от Incoming E-Mail Server Display Address, который вы задаете в ходе настройки входящей почты.
Адрес, созданный при помощи DMS, более удобен для пользователя; он показывается в графическом интерфейсе SharePoint, и вам может впоследствии понадобиться изменить созданный в AD адрес объекта таким образом, чтобы это был допустимый адрес, на который может быть направлено сообщение. Также можно указать, могут ли объекты Contact в AD получать почту только от аутентифицированных пользователей, что отражается в специфическом для Exchange атрибуте, устанавливаемом на объекте Contact в Active Directory. Таким образом, если вы используете другие почтовые системы, эти настройки будут непригодны.
Использовать GAL или нет
В таблице перечислены главные атрибуты настроек DMS для объектов Contact в дополнение к стандартным системным атрибутам. В этих настройках есть некоторые ограничения, и примечательно то, что в чистой среде Exchange 2007 этих настроек недостаточно для того, чтобы допустимая запись появилась в глобальном списке адресов Global Address List (GAL). Exchange 2003 и Exchange 2000 включают в себя асинхронный компонент, названный Recipient Update Service (RUS), который устанавливает на объекты AD такие атрибуты, как proxyAddresses и showInAddressBook, на которые Exchange полагается при идентификации получателей и маршрутизации почты. Этот метод изменения адресов удален из Exchange 2007; все атрибуты устанавливаются во время создания, но только если вы в первую очередь используете Exchange Management Console (EMC) или Exchange Management Shell (EMS) для создания своих объектов.
Поэтому, чтобы получить правильные контакты в среде, где нет RUS, нужно скорректировать их после создания. Этот процесс обсуждается в журнале команды Exchange - Good bye RUS (msexchangeteam.com/archive/2006/10/02/429053.aspx). По существу, требуется модернизировать все необходимые списки адресов при помощи следующих EMS-команд:
Get-EmailAddressPolicy /
Update-EmailAddressPolicy
Get-AddressList / Update-AddressList
Get-GlobalAddressList /
Update-GlobalAddressList
Второе ограничение объектов Contact заключается в том, что они не настроены для того, чтобы вложения правильно посылались к ним. Эта проблема описана в статье Microsoft "Attachment is missing from an e-mail message that is sent to a Microsoft Windows SharePoint Services 3.0 document library" ("В электронных сообщениях отсутствуют вложения, которые отсылаются в библиотеку документов Microsoft Windows SharePoint Services 3.0"), support.microsoft.com/default.aspx? scid=kb; en-us;926891. В этой статье объясняется, что нужно задать для атрибута mAPIRecipient значение false и для атрибута internetEncoding - значение 1310720, для того чтобы вложения правильно отсылались к объекту Contact. Замечу, что, если не использовать DMS для активации функции поиска по GAL, эти проблемы не появляются. Exchange не может корректно доставить почту контакту, созданному с использованием DMS, из-за отсутствующих атрибутов.
Третья проблема связана с выводимым именем, которое создается и в конечном счете хранится в GAL. Это имя, при помощи которого обычно выбирают запись в GAL. Однако, возможно, у других пользователей уже есть подобные списки и имена сайтов, и весьма вероятно, что между этими записями в GAL будет мало различий. Напомню, что в SharePoint никак нельзя в графическом интерфейсе предупредить ситуацию, когда списки и сайты имеют одинаковые имена. На экране 2 показан пример двух сайтов: оба они названы Group Team Site и имеют стандартный список Team Discussion, куда можно отправлять почту. Какой из них пользователи должны выбрать? Чтобы сделать правильный выбор, им нужно знать почтовый адрес соответствующего списка. Наличие Contacts в GAL иногда может скорее мешать, чем помогать.
Последняя проблема, о которой я хотел бы упомянуть, - это недостатки управления. В SharePoint нет административного контроля над тем, что помещается в GAL: если вы решите запустить DMS, начнется неразбериха, он ведь доступен для всех. Можете себе представить, что в каждом сайте группы три списка доступны для получения почты? В какое количество записей в GAL выльется это в рамках организации? В моей компании их количество перевалило бы за миллион! А в силу устройства DMS все эти записи были бы в одном OU в AD. Я не уверен, что знаю такого администратора AD, который с радостью открыл бы свою AD для неправильной эксплуатации.
С почтой легче
Правильная настройка всех частей так, чтобы электронная почта соответствовала нужным спискам или библиотекам, может быть запутанной, но возможность отсылать элементы в SharePoint безусловно полезна, и способ, при помощи которого SharePoint управляет присылаемыми элементами, работает хорошо. Необходимо только изучить сведения о функциях, о том, как контакты будут появляться в GAL, и усвоить, что каждый - конечные пользователи, администраторы AD, администраторы Exchange - должен знать, чего ожидать от возможности получения сообщений в SharePoint. Особенно важно во всем