Введение
Эта статья не показывает Вам, как конфигурировать Outlook Web Access (OWA), Outlook Mobile Access (OMA) или Exchange ActiveSync (EAS). Вместо этого она обсуждает технические выполняемые функции, скрытые за обеспечением удалённого HTTP доступа к почтовым ящикам Exchange 2003. А раз так, этот документ становится весьма многословным, техничным и, возможно, немного 'тяжёлым?.
Итак, почему нас это беспокоит? Да потому что HTTP механизмы, используемые для доступа к почтовым ящикам, являются несколько причудливыми! Хотя Exchange считает за лучшее скрыть от нас эти абстрактные идеи, они тем не менее остаются, ожидая как бы подловить неосторожного. Здесь Вы можете быстро найти ответы на то, почему некоторые HTTP методы доступа к почтовым ящикам причиняют так много неприятностей, а понимание этих фактов значительно упростит конфигурирование этих средств.
Статья также охватывает изменения, сделанные в SP1 для Exchange, который пошёл далее по направлению к затемнению некоторых из этих таинственных механизмов, но во время описания эти изменения остаются в стадии разработки('work-in-progress?). По крайней мере, есть проблеск надежды на будущее!
Осмысление HTTP доступа к почтовым ящикам Exchange
Ключевое понятие, которое нужно усвоить для осмысления HTTP доступа к почтовым ящикам Exchange есть то, что email адреса и SMTP домены очень важны для обеспечения этого доступа: хотя пользователь регистрируется своим мандатом(credentials) входа в систему, доступ к данным почтового ящика зависит от их email адресов. Обеспечение понимания этой несколько абстрактной концепции — вот главное предназначение этого руководства.
Многие из нас будут конфигурировать OWA, OMA и EAS не понимая этих концепций, хотя все испытают проблемы, которые от них происходят! Настоящие трудности ожидают в тех организациях с множеством идентичностей, которые выражает эти идентичности в множестве email адресов, таких как [email protected] и [email protected]. С Exchange поддержкой множества SMTP доменов, обеспечение HTTP доступа к почтовому ящику становится всё более и более хитрым делом, но с пониманием концепций Вы можете избежать многих распространённых конфигурационных ошибок.
Exchange Web Store
Exchange Store (иногда называемый Web Store)- это структура, поддерживающая почтовый ящик и данные публичной папки (public folder). Store доступен для программистов через нечто, называемое Exchange OLE DB Provider (ExOLEDB), которое регистрируется с OLE RootBinder, чтобы позволить ему быть доступным через Uniform Resource Locator (URL). К URLам присоединяется приставка, чтобы получить доступ к Exchange Store:
file://./BackOfficeStorage/Для доступа к пользовательскому почтовому ящику URL должен содержать глобально уникальную информацию описания пользователя. Вы могли бы быть прощены за мнение, что эта информация будет доменом и именем пользователя или пользовательским UPN, но это не так. Вместо этого обычно используются сфокусированные на Exchange свойства SMTP домена по умолчанию и вымышленные имена почтового ящика. Например, файловый URL для доступа к элементам в пользовательском Inbox:
file://./BackOfficeStorage/DefaultSMTPDomain/MBX/MailboxAlias/Inbox/…>Частица ‘MBX? указывает, что этот URL обращается к хранилищам(stores) почтовых ящиков. URL для доступа к хранилищам публичных папок Exchange очень похож, но вместо MBX стоит имя папки верхнего уровня, сопровождаемой любыми добавочными публичными папками в иерархии. ‘Public Folders? — это папка верхнего уровня по умолчанию:
file://./BackOfficeStorage/DefaultSMTPDomain/Public Folders/…Диск M:
Можно обратиться к ExOLEDB так, как предлагает его файловый URL, как если бы он был частью серверной файловой системы. Exchange 2000 отобразил диск M в BackOfficeStorage, позволяя содержимому почтового ящика быть доступным так, как если бы оно было файлами. Люди, которые начали запускать антивирусы и утилиты резервного копирования на диске столкнулись с бедственными последствиями! Exchange 2003 не отображает диск в BackOfficeStorage!
Если Вы действительно любопытны, Вы можете исследовать Exchange Store, запустив команду subst m: \\.\BackOfficeStorage в командной строке и передвигаясь по получающемуся в результате виртуальному диску M. Обратите внимание на использование именно обратных слэшей; здесь нам нужен Universal Naming Convention (универсальное соглашение именования)(UNC), а не файловый URL. Запустите subst -D m: после того, как Вы завершите 'просмотр?.
Доступ к Exchange Web Store, используя HTTP URLы
Файловые URLы могут предоставлять локальный доступ для локальных приложений, но для обеспечения удалённого доступа необходимо чтобы был обеспечен HTTP протокол. Чтобы сделать это, мы можем сконфигурировать виртуальную директорию (или сервер) в Internet Information Server (IIS) на сервере Exchange с его локальным путём, установленным в \\.\BackOfficeStorage, и позволить просмотр: Опять же, такая процедура только для любопытных!
Наличие базового HTTP доступа имеет небольшое практическое значение так как позволяют только рассматривать содержимое, поэтому аналоги OWA используют серверные(server-side) приложения для преобразования базового содержания во что-то значительно более полезное для клиента. OWA также применяет усовершенствованные технические приёмы, известные как Web Distributed Authoring and Versioning( (WebDAV). WebDAV-это расширение HTTP, позволяющее файловые операции, такие как копирование, перенос, удаление, и drag-and-drop через Internet.
Web приложения, такие как OWA, работают с более специфическими местами расположения, чем корень BackOfficeStorage. Например, виртуальная директория, сконфигурированная для доступа к почтовым ящикам, такая как виртуальная директория по умолчанию 'Exchange?, сконфигурированная Exchange-ем для OWA, будет иметь локальный путь:
\\.\BackOfficeStorage\SMTPDomain\MBXТеперь, объяснения были довольно понятными вплоть до этой точки, но пора приступить к худшему! В строке выше используется SMTP домен, но он не должен быть SMTP доменом по умолчанию, как предлагалось ранее в этом параграфе; в действительности, он не должен быть SMTP доменом вообще, как подразумевает любая старая строка! Всё, что появляется здесь, транслируется где-то во внутренностях IIS и Exchange в правильное местоположение, содержащее SMTP домен по умолчанию.
Этот наворот? добавлен, чтобы его использовал OWA. Виртуальная директория для OWA конфигурируется для специфического SMTP домена и этот домен появляется в своём локальном пути. Когда OWA клиент осуществляет доступ напрямую к пользовательскому Inbox, он использует URL, содержащий не псевдоним пользовательского почтового ящика или имя пользователя, а left-hand side(левую сторону) (LHS) одного из пользовательских email адресов (то, что слева от @?):
HTTP://ServerName/Exchange/LHSofSMTPAddress/InboxOWA приложение берёт эту LHS частицу и присоединяет её соответственно SMTP домену, для которого оно сконфигурировано(в действительности, правая сторона email адреса). Пользователь должен иметь этот получившийся email адрес, иначе OWA возвращает ошибку 'не найдено?.
Конечно, мы обычно не определяем LHS частицу при доступе к OWA, но когда OWA возвращает построенную Web страницу клиенту, он будет иметь ссылок на него больше, как описано выше. Чтобы сделать это, OWA находит пригодный email адрес в сконфигурированном SMTP домене. Если пользователь имеет много пригодных email адресов, то OWA всё равно, какой email адрес использовать, но если пользователь не имеет email адреса в сконфигурированном домене, OWA возвращает ошибку 'не найдено? и вход в систему не производится.
Exchange 2003 Service Pack 1
Если всё это звучит сумасбродно, не только Вы так думаете. Даже Microsoft находит проблемы в том, что эти механизмы создают слишком много всего, чтобы это можно было вынести, и работает над тем, чтобы удалить их. Exchange 2003 SP1 ввёл поддержку для другой формы HTTP URLа, который не заботится о том, в каком SMTP домене находится адрес электронной почты пользователя. Вот этот формат:
HTTP://ServerName/Exchange/Emailname@SMTPDomain/InboxЗдесь нет LHS или RHS, используется полный SMTP email адрес (включая '@?). Виртуальные директории OWA могут быть оставлены сконфигурированными для SMTP домена по умолчанию, потому что больше не важно, для какого домена это конфигурируется.
Во время написания статьи, только OWA поддерживает этот новый формат; OMA и EAS придерживаются старого формата (и хуже!).
RPC поверх HTTP
Так где же RPC поверх HTTP приноравливается ко всему этому?
Первое, что нужно сказать о RPC over HTTP есть то, что он ничего не делает с Exchange 2003! RPC over HTTP на клиентской стороне — это средство Windows XP, которое использует клиент Outlook 2003. Серверной стороной 'RPC Proxy? может быть любой сервер Windows 2003 с или без установленным(ого) Exchange Server. RPC Proxy не заботится о том, какому SMTP домену Вы принадлежите или даже то, что Вы обращаетесь к серверу Exchange! Proxy лишь принимает HTTPS запросы от клиентов и действует от их имени как RPC клиент в локальной сети. Именно то, что Вы ожидали от 'RPC proxy?.
Эта точка зрения несколько приводится в беспорядок текущим SP1 для Exchange 2003, который ввёл 'управляемый(managed)? RPC over HTTP для Exchange: Exchange System Manager теперь может быть использован для конфигурирования размещения RPC over HTTP для Exchange. Однако, Вы всё ещё можете конфигурировать это средство без вмешательства System Manager и получить немного больше гибкости делая так.
RPC over HTTP-это очень важный инструмент для удалённого доступа к почтовым ящикам Exchange 2003, но тема хорошо освещена в других статьях и не нуждается в повторении здесь.
Продолжение следует…
Теперь Вы вооружены базовым пониманием того, как HTTP клиенты могут извлекать данные почтового ящика из Exchange 2003. В Части 2 мы рассмотрим, как OWA, OMA и EAS используют эти механизмы.
