SharePoint изнутри: Поиск и устранение неполадок в интеграции с единой системой обмена сообщениями

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

Участники потоков работ могут отвечать на сообщения такого рода и отправлять новые элементы в библиотеки и списки документов по электронной почте.

Однако нужно отметить, что интеграция системы SharePoint® в среду безопасного обмена сообщениями — процесс непростой. Компоненты, не связанные с системой SharePoint, могут нарушать работу самой системы. Самая сложная задача — выявить и устранить исходные причины всех неполадок, возникающих при интеграции среды.

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

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

Дабы подчеркнуть практический характер этой статьи, мы использовали среду, в которую входят Active Directory®, Exchange Server 2007 и WSS 3.0. Поэтапные указания по формированию аналогичной тестовой среды, а также средства поиска и устранения неполадок, обсуждаемые в данной статье, имеются в разделе загрузки кода на веб-узле журнала TechNet Magazine.

Общие методы поиска и устранения неполадок

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

Не вызывает сомнений тот факт, что работать вам приходится со сложной технологией. Ведя борьбу со сбоями передачи сообщений, преобразования форматов, обеспечения безопасности, управления каталогами, вы столкнетесь с тем, что некоторые сообщения об ошибках в SharePoint попросту непонятны. Группы новостей в Интернете полнятся незакрытыми обсуждениями неполадок, и в них встречаются такие советы, которые способны направить по ложному пути. Например, для бесперебойной передачи сообщений рекомендуют запускать все веб-приложения под удостоверением пула приложений «Центр администрирования SharePoint».

Но есть во всем этом и положительные моменты. Система SharePoint обладает большим запасом гибкости. Она сама может рассказать вам о том, как устранить неполадку, — нужно только знать, где эту информацию найти. Пара несложных сценариев способна здорово упростить работу по поиску и устранению неисправностей.

При решении проблемы первым делом нужно понять, в чем она, собственно, заключается. Нужно определить источник проблемы, выяснить, какие компоненты она затрагивает. Иногда приходится воспроизвести аналогичную ситуацию при различных настройках системы и изучить журналы событий Windows® и текстовые файлы журналов. Не всегда это просто сделать, поскольку бывают неполадки, которые возникают лишь от случая к случаю. И все же, чем точнее вы сможете воспроизвести проблемную ситуацию, тем быстрее отыщете и устраните ее первопричину. Еще одна важная задача, о которой часто забывают, — документировать все перенастройки и исправления и обеспечивать их применение на всех затронутых системах среды (например, всех серверах клиентского доступа отдельно взятой веб-фермы).

Архитектура системы обмена сообщениями SharePoint

Столкнувшись с проблемой, связанной с интеграцией системы обмена сообщениями, отойдите в сторонку, выпейте чашку чая или кофе, вернитесь, проверьте архитектуру интеграции системы обмена сообщениями SharePoint и только после этого приступайте к устранению неполадок. В противном случае может статься так, что вы исправите не ту проблему или не тот компонент. Например, появление сообщение «Доступ запрещен» при попытке создать объект-контакт в Active Directory не обязательно свидетельствует о том, что нужно исправлять права доступа в Active Directory, как станет видно дальше.

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

Рис. 1 Архитектура интеграции системы обмена сообщениями SharePoint

Сбор диагностической информации

Надежная диагностическая информация — одна из важнейших основ процесса устранения неполадок. Нетленная классика — журнал событий Windows. В центре администрирования SharePoint, помимо всего прочего, можно определить уровень подробности записей SharePoint в журнале событий Windows на веб-серверах (на странице «Операции», в блоке «Ведение журналов и составление отчетов», нужно щелкнуть пункт «Сбор данных диагностики»). Можно указать минимальный уровень важности событий, заносимых в журнал событий и журнал трассировки. Журнал трассировки (по умолчанию он хранится в папке %CommonProgramFiles%\Microsoft Shared\Web Ser­ver Extensions\12\Logs) весьма полезен в том случае, когда требуются данные низкого уровня, но он очень быстро заполняется, поэтому использовать его нужно как можно реже.

Еще один способ сбора диагностической информации — использование отладки веб-приложения, в работе которого возникли неполадки. Включается отладка в соответствующем файле web.config (см. информацию в файле Web Application Config.pdf в сопровождающих материалах). Система SharePoint будет выдавать подробные данные трассировки непосредственно в пользовательском интерфейсе. Преимущество такого подхода состоит в том, что для поиска нужной информации об ошибке не приходится прочесывать мегабайты данных трассировки. Недостаток — в том, что нужно менять настройку веб-приложения. Не забудьте сделать резервную копию файла web.config и восстановить настройку, когда устраните проблему.

Кроме этого, можно настроить службу SMTP так, чтобы она записывала подробную информацию об обрабатываемых данных в журнал протокола SMTP (в диспетчере служб IIS нужно на вкладке «Общие» установить флажок «Вести журнал»). Обязательно установите модуль ведения журнала ODBC вместе со службой SMTP, даже если вы не планируете использовать журналы ODBC (см. информацию в файле SharePoint Messaging Integration.pdf в сопровождающих материалах). В противном случае служба SMTP вести журнал не сможет. По умолчанию журнал протокола SMTP хранится в папке %SystemRoot%\System32\LogFiles\SmtpSvc1. Он представляет собой текстовый файл, позволяющий подробно проанализировать процессы обмена данными по протоколу SMTP и определить, было ли сообщение отправлено с сервера SharePoint.

На транспортном сервере-концентраторе с установленной службой SMTP можно также включить ведение журнала протокола в настройке соединителей отправки и получения (см. указания в файле SharePoint Messaging Integration.pdf). Существует множество других средств, позволяющих отслеживать пути следования сообщений в среде Exchange Server 2007 при прохождение ими транспортных серверов-концентраторов и серверов почтовых ящиков: отслеживание сообщений, средство просмотра очереди, средство конвейерной трассировки. Подробную информацию о поиске и устранении неполадок, связанных с передачей сообщений в среде Exchange Server 2007, приведены в разделе «Неполадки в процессах передачи сообщений» на странице go.microsoft.com/fwlink/?LinkID=120145.

Чтобы собрать информацию, необходимую для устранения неполадок, на контроллерах доменов Active Directory, нужно включить функцию сбора данных диагностики для доступа к каталогам и других категорий (делается это путем настройки соответствующих разделов реестра в блоке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics). Если для некой категории установлено значение 0x0, в журнал заносятся только самые важные события; если установлено значение 0x5, заносятся все события. При уровне подробности записей более 0x3 производительность сервера может заметно снизиться, а журнал событий Windows быдет быстро переполняться. При нормальной работе систем следует использовать значение 0x0.

Сбор данных диагностики на серверах SharePoint, Exchange и Active Directory помогает быстрее и с большей степенью надежности обнаружить причину сбоя. Также могут оказаться полезными дополнительные средства поиска и устранения неполадок, например средства управления протоколом TCP/IP (проверка связи, tracert, telnet и т. д.) и сетевой монитор, поскольку обмен информацией между системами такого рода по большей части происходит через сеть. Сетевой монитор Microsoft® версии 3.1 можно загрузить на странице go.microsoft.com/fwlink/?LinkId=120143.

Передача исходящих сообщений

Материалы

• Веб-узел «Продукты и технологии SharePoint»
• Технический центр служб Windows SharePoint
• Центр разработчиков для служб Windows SharePoint
• Блог группы «Продукты и технологии Microsoft SharePoint»

Итак, у нас есть журнал событий, журналы трассировки, журналы протоколов, журналы отслеживания сообщений и сетевой трассировки. Можно приступать к поиску и устранению неполадок в процессах интеграции системы обмена сообщениями SharePoint. Начнем с самого простого: с передачи исходящих сообщений. Система SharePoint поддерживает различные настройки передачи исходящих сообщений, причем локальную службу SMTP на веб-серверах иметь совсем необязательно, однако в полном варианте интеграции системы обмена сообщениями ее все же рекомендуется использовать. На рис. 2 показаны основные компоненты такого варианта.

Рис. 2 Передача исходящих сообщений

В этом варианте передача сообщения выполняется в четыре этапа: передача из системы SharePoint службе SMTP, обработка службой SMTP, передача на транспортный сервер-концентратор и передача сообщения сервером Exchange Server 2007 конечному получателю.

Если системе SharePoint не удается передать сообщение службе SMTP, обычно появляется сообщение об ошибке в пользовательском интерфейсе, например сообщение о том, что уведомление не удалось отправить по электронной почте. Причиной может быть неработающая служба SMTP. Другой вариант: в журнале протокола SMTP появляется запись о том, что служба SMTP отклонила попытку передачи с кодом ошибки 550 («Запрошенное действие не выполнено: почтовый ящик недоступен»). Такая запись говорит о том, что причиной сбоя является служба SMTP.

Убедиться в том, что проблема не связана с системой SharePoint, поможет несложный сценарий (см. файл SMTP.vbs в сопровождающих материалах). Он позволяет отправить через службу SMTP тестовое сообщение, содержащее те же данные об отправителе и получателе, что и реальное неотправленное сообщение. Если причина сбоя действительно кроется в службе SMTP, сценарий выполнить не удастся. Этот сценарий в действительности может дать ценные указания на истинную причину проблемы. Такие данные сам SharePoint, увы, не предоставит даже при включенной отладке (см. рис. 3).

Рис. 3 Сбой отправки сообщений

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

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

Это не обязательно должен быть протокол TCP, порт 25. На самом деле, если служба SMTP использует именно этот порт, сообщения могут доставляться на стандартный соединитель получения транспортного сервера-концентратора, который, в соответствии с его настройками, блокирует анонимную передачу сообщений. В таком случае в папке входящей почты появится файл сообщения. (Службу таймера служб Windows SharePoint необходимо остановить: в противном случае сообщение через несколько секунд будет удалено.) Файл сообщения представляет собой оповещение о состоянии доставки следующего содержания: «Diagnostic-code: smtp;530 5.7.1 Client was not authenticated» (клиент не прошел проверку подлинности).

Для решения этой проблемы нужно создать выделенный соединитель получения для серверов SharePoint. Поскольку серверы SharePoint являются внутренними системами, следует выбрать вариант проверки подлинности «Внешняя защита (например, с помощью IPsec)». Это позволит не не предоставлять излишних прав учетной записи ANONYMOUS LOGON. Кроме того, стоит использовать IPsec для защиты данных, передаваемых между серверами SharePoint и транспортным сервером-концентратором.

Если сообщения уходят из папки очереди SMTP, а в журналах протокола SMTP на сервере SharePoint и на транспортном сервере-концентраторе (в папке %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) нет записей о сбое передачи, можно считать проблему решенной при условии, что сервер Exchange Server 2007 доставляет сообщения конечному получателю. Как уже упоминалось ранее, для поиска и устранения неисправностей в работе системы Exchange Server 2007 можно использовать различные средства анализа процессов обмена сообщениями, поставляемые вместе с системой. На этом этапе причиной недоставки сообщения могут быть неправильно указанный адрес получателя, фильтры нежелательной почты, ограничения на размер сообщений.

Передача входящих сообщений

Передача сообщений в обратном направлении — процесс несколько более сложный, потому как потенциальные причины сбоев определить не так просто. К примеру, в документации к SharePoint рекомендуется настраивать записи MX в DNS для почтовых доменов SharePoint, а ведь такой подход легко может нарушить пути передачи сообщений в организации Exchange.

Для передачи сообщений в системе Exchange Server 2007 используются соединители отправки и связанные области адресов. Сообщения SharePoint могут передаваться на пограничный транспортный сервер для дальнейшей передаче через Интернет даже несмотря на то, что серверы SharePoint являются внутренними. Для внутренней передачи сообщений следует вместо этого использовать соединители отправки с подробными определениями пространств адресов, а в качестве промежуточных узлов в настройке соединителя следует указывать серверы SharePoint, на которых работает служба SMTP (см. информацию в файле SharePoint Messaging Integration.pdf в сопровождающих материалах). Правильно организованная топология маршрутизации, включающая в себя выделенные серверы-плацдармы, поможет добиться более высокой надежности передачи сообщений из Exchange в SharePoint.

Чтобы проверить, приходят ли сообщения на серверы SharePoint, остановите службу таймера Windows SharePoint Services. Сообщения будут накапливаться в папке входящих сообщений, поскольку именно служба таймера отвечает за обработку сообщений и размещение вложенных файлов в библиотеки документов, связанные с адресом получателя (см. рис. 4). Если сообщения в папку входящих сообщений не поступают, воспользуйтесь средством просмотра очереди на транспортном сервере-накопителе и проверьте, правильно ли Exchange выполняет маршрутизацию. Затем проверьте работу сети: сбои в этой области могут приводить к нарушению обмена данными между транспортным сервером-накопителем и службой SMTP на сервере SharePoint.

Рис. 4 Передача входящих сообщений

Когда вы снова запустите службу таймера, проверьте, удаляются ли сообщения из папки входящих сообщений. Если вложения, присланные вместе с сообщениями, остаются в библиотеках назначения, хотя записи в журнале Windows говорят о том, что SharePoint успешно обрабатывает сообщения, значит, Exchange отправляет сообщения в формате Exchange RTF. Чтобы проверить, действительно ли это так, снова отключите службу таймера, отправьте еще одно сообщение с вложением из клиента Outlook®. Когда оно будет доставлено в папку входящих сообщений, откройте его в программе «Блокнот». Попытайтесь найти в файле строку winmail.dat. Если она там есть, значит, сервер Exchange отправляет сообщения в неправильном формате.

SharePoint требует, чтобы вложения кодировались в формате MIME или UUENCODE. Кроме того, система SharePoint не отражает в журнале событий Windows проблемы, связанные с обработкой winmail.dat (см. рис. 5). Файлы вложений просто не будут помещаться в библиотеку документов. В качестве средства поиска неполадок используйте «Блокнот». Для решения проблемы, связанной с неправильным форматированием, нужно исправить определение удаленного почтового домена SharePoint в консоли управления Exchange. На вкладке «Формат исходного сообщения, которое отправляется в виде вложения в отчет журнала» в поле «Формат RTF Exchange» выберите значение «Не использовать».

Рис. 5 Обработка сообщений Winmail.dat

Управление списками рассылки

Одно из самых полезных событий службы таймера — событие 6873, в котором говорится, что произошла ошибка обработки входящего файла электронной почты из-за того, что указан неизвестный псевдоним. Такое происходит, когда пользователь Exchange неправильно вводит адрес электронной почты SharePoint при отправке сообщения, например если выбранная библиотека документов не существует.

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

Однако нужно четко понимать, что в этом случае открывается новое поле деятельности по устранению неполадок. Служба управления спсиками рассылки дает сбой в безопасной настройке системы, выполненной по принципу наименьших прав, поскольку на веб-сервере ей требуются расширенные разрешения. Нужно отметить, что в документации к продукту (например, на веб-узле technet.microsoft.com/library/cc262947.aspx) эти требования несколько преувеличиваются: там учетной записи пула приложений центра администрирования предлагается предоставлять права на создание, удаление учетных записей пользователей и управление ими в том подразделении, которое указано для объектов-получателей SharePoint в Active Directory.

Служба управления списками рассылки создает объекты-контакты и объекты-группы, следовательно, пул приложений центра администрирования должен иметь полный контроль над контактами и группами в данном подразделении, а вот разрешение на администрирование учетных записей пользователей ему ни к чему. Если настроить службу управления списками рассылки на веб-ферме так, как предложено, и попытаться включить для некой библиотеки документов возможность работы с почтой, велика вероятность того, что будет выдана ошибка «Доступ запрещен».

Появление такой ошибки говорит о том, что что-то не так с настройкой разрешений в Active Directory. Первым делом администратор предоставляет учетной записи «Все» полный контроль над подразделением SharePoint. Однако это лишь ослабляет защиту Active Directory, а саму проблему не решает.

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

К сожалению, получить еще какую-то полезную информацию в случае такого сбоя крайне сложно. SharePoint никаких дополнительных данных в журнал событий Windows не заносит. Однако, если включить отладку SharePoint, то по стеку вызовов (см. рис. 6) можно определить, что служба управления списками рассылки использует метод CreateContact веб-службы SharePoint. Пакет SharePoint SDK говорит о том, что это веб-служба интеграции электронной почты (<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx).

Рис. 6. Выходные данные отладки

Server was unable to process request. ---> Access is denied.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias, String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String newAlias)
at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
at Microsoft.SharePoint.SPList.Update()
at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender, EventArgs args)
at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Откроем файл SharepointEmailWS.asmx в обозревателе и взглянем на список поддерживаемых операций. Найдите метод CreateContact и щелкните ссылку — появится сообщение SOAP, которое нужно отправить веб-службе, чтобы создать контакт в Active Directory. Это весьма полезная информация, поскольку теперь мы можем создать средство поиска и устранения неполадок на основе сценариев (см. файл SharepointEmailWS.vbs в сопровождающих материалах), которое будет работать вне пользовательского интерфейса SharePoint, что упростит выбор учетных записей пользователей во время тестирования. На рис. 7 показаны данные, которые возвращает сценарий при запуске под учетной записью пула приложений центра администрирования (слева) и под учетной записью администратора SharePoint (справа).

Рис. 7 Два случая запрета доступа

Сообщения об ошибке различаются! Оба говорят о том, что доступ запрещен, однако слева мы видим сбой обработки, а справа — нет. Так в чем же разница между учетной записью пула приложений и учетной записью администратора SharePoint?

Администратор SharePoint — это локальная учетная запись сервера SharePoint, в то время как учетные записи пула приложений таковыми не являются. Можно добавить учетные записи пула приложений в локальную группу администраторов. Проблема будет решена, однако это не лучший способ ее устранения. Мы считаем предоставление прав администратора учетным записям пула приложений на производственных веб-серверах недопустимым.

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

Настройка пула приложений — это часть метабазы служб IIS (или файла applicationHost.config в случае IIS 7.0), а доступ к ней по умолчанию для локальных администраторов ограничен. К счастью, учетным записям не администраторов можно предоставить доступ к метабазе при помощи проводника для метабазы, входящего в пакет IIS 6.0 Resource Kit. В IIS 7.0 предоставить полный контроль для файла applicationHost.config еще проще – нужно запустить следующую последовательность команд:

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"   
/G "<application pool account>" :F /E iisreset /noforce

Итак, для создания объектов-контактов в Active Directory пулу приложений центра администрирования требуется полный контроль над объектами-контактами и объектами-группами в целевом подразделении. Учетным записям пула, назначенным веб-приложениям, требуется полный доступ к метабазе на серверах SharePoint веб-фермы. Вот теперь мы можем создавать объекты-контакты через пользовательский интерфейс SharePoint.

Нет, стоп. И это еще не все. Создание объектов получателей в Active Directory — лишь половина дела. Вторая половина — это создание атрибутов получателей для Exchange и обновление серверных адресных книг. Например, если обновить глобальный список адресов на сервере Exchange при помощи командной консоли Exchange (команда вида Update-GlobalAddressList "Глобальный список адресов, используемый по умолчанию") новые объекты получателей, созданные для библиотек документов SharePoint, появятся в адресной книге Outlook. Но при отправке сообщений таким получателям будет приходить отчет о недоставке, поскольку адрес указан неверно (см. рис. 8).

Рис. 8 Сообщение в библиотеку документов не доставлено

Аббревиатура IMCEAEX расшифровывается как Internet Mail Connector Encapsulated Address for Exchange. Это инкапсулированный адрес получателя, не входящего в организацию Exchange, в таком формате, который мог обрабатывать старый соединитель электронной почты Интернета Exchange. Но сейчас мы работаем с Exchange Server 2007 и встроенными соединителями отправки, основанными на SMTP.

Все дело в том, что веб-служба интеграции электронной почты не записывает те атрибуты адреса, которые требуются системе Exchange Server 2007 для передачи сообщения. Записывается только имя, фамилия, отображаемое имя и адрес назначения (и иногда еще атрибут ms-Exch-RequireAuthToSendTo). Ни почтовый псевдоним, ни устаревшее различенное имя Exchange (DN), ни адрес прокси не указываются, объекты получателей с политикой получателей Exchange не связываются.

Для устранения этой проблемы используется командлет Get-Mailbox командной консоли Exchange. Он выдает список всех объектов получателей, адрес которых указывает на почтовый домен SharePoint. Этот список подается на вход командлета Set-MailContact для активации политики получателей Exchange:

Get-Contact | where { $_.WindowsEmailAddress –like    
  '*sharepoint.contoso.com' } | Set-MailContact    
  -EmailAddressPolicyEnabled:$True 

Другой способ — воспользоваться консолью управления Exchange: в свойствах объектов-контактов установить флажок «Автоматически обновлять адреса электронной почты на основании политики адресов электронной почты».

WSS 3.0 и MOSS 2007 полностью поддерживают интеграцию системы обмена сообщениями (предупреждения и уведомления, связанные с электронной почтой, потоки работ, передачу документов). Правильная настройка системы — задача нетривиальная, однако интеграция систем обмена сообщениями может значительно повысить производительность. В частности, одна из важных задач — обеспечить успешную передачу как входящих, так и исходящих сообщений. Кроме этого, должна быть выполнена интеграция каталога.

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