Thursday, October 18th, 2018

Публикация Web доступа к Outlook и Outlook RPC/HTTP с помощью аутентификации, основанной на формах в ISA Server 2006 Enterprise Edition (Часть 2)

Published on Февраль 10, 2009 by   ·   Комментариев нет

Во второй части я рассмотрю две ключевые проблемы, которые являются наказанием администраторов ISA-серверов: DNS и проблемы внедрения сертификатов.

Если вы пропустили остальные части этой серии статей, пожалуйста прочтите:

В первой части статьи о публикации OWA и RPC/HTTP с помощью ISA Server 2006 я описал цели статьи и объяснил примерный сценарий и лабораторные условия, в которых мы будем производить настройку и тестирование.

Во второй части я рассмотрю две ключевые проблемы, которые являются наказанием администраторов ISA-серверов: DNS и проблемы внедрения сертификатов. Эти две области ISA-сервера и сетевой безопасности ответственны за огромное количество проблем и разочарований администраторов ISA-серверов. Я знаю, что вы хотите поскорей разобраться с настройками публикации сайтов OWA и RPC/HTTP, но поверьте, данные вопросы очень важны, и необходимо разобраться с DNS и сертификатами до того, как начать решать проблемы с публикацией web-ресурсов на ISA-сервере.

Замечание: Если вы хорошо знакомы с DNS и проблемами, связанными с сертификатами при создании правил web-публикаций на ISA-сервере, вы можете пропустить данную статью и подождать выхода третьей части, в которой мы углубимся в детали настройки ISA-сервера.

В частности, мы остановимся на следующих вопросах:

  • Значение инфраструктуры разделенной DNS
  • Разделенная DNS в данной статье
  • Важность соглашений по именованию сертификатов

Значение инфраструктуры разделенной DNS

Из всех вопросов, связанных с работой ISA-сервера в сети, одним из самых насущных является вопрос о разделенной системе DNS. Я не могу объяснить, почему администраторы ISA-серверов так не любят инфраструктуру разделенной DNS. Однако, скорее всего, это можно объяснить следующими заблуждениями:

  • Они уверены, что придется переименовывать внутренние домены – наглая ложь
  • Они думают, что система безопасности будет под угрозой – бесстыдная ложь
  • Они думают, что DNS настолько сложна для понимания, что сама мысль о сложности данного вопроса приводит их на грань безумия – для некоторых это правда

Истина в том, что разделенная DNS может облегчить вашу жизнь и жизнь пользователей. При правильном использовании разделенной DNS вы получаете следующее:

  • Пользователям не нужно помнить об использовании различных имен в разных местах. Находится ли пользователь внутри корпоративной сети или где-нибудь в Интернете – он использует одно и то же имя
  • Клиентские приложения не нужно перенастраивать в зависимости от места расположения пользователя. Клиенты Outlook MAPI, SMTP, POP3, IMAP4, web-браузера, FTP и т.д. не нужно перенастраивать. Внутри и снаружи корпоративной сети используется одни и те же настройки для имени сервера.
  • Внутренним узлам для доступа к ресурсам корпоративной сети не нужно замыкание через брандмауэр. Один из лучших способов уменьшения производительности ISA-сервера является разрешение узлам в защищенной ISA-сервером сети замыкания через брандмауэр. Разделенная DNS гарантирует, что у вас никогда не будет такой утечки производительности.
  • Вы можете сохранить текущее имя домена Active Directory. Разделенная DNS не требует переименования внутреннего (внутренних) домена (ов). Вы можете добавить новые домены DNS, которые будут использоваться исключительно для поддержки инфраструктуры разделенной DNS, при этом не влияя на DNS, отвечающую за Active Directory.
  • Все версии клиента Outlook MAPI (97/98/200/2002/2003) будут «просто работать». Пользователь может временно прекратить работу в корпоративной сети на своем ноутбуке, а затем включить его в гостинице, находящейся за 10000 километров, и Outlook автоматически соединится с корпоративным Exchange-сервером. Пользователю никогда не придется перенастраивать Outlook и его текущее место расположения абсолютно не важно для доступа к ресурсам корпоративной сети.

Как инфраструктура разделенной DNS облегчает жизнь администраторамISA-серверов

Разделенная DNS делает ресурсы доступными для внутренних и внешних пользователей. Независимость от места расположения делает возможным использование пользователями одного и того же имени для доступа информации корпоративной сети. Пользователю не нужно запоминать отдельные адреса URL или имена серверов при нахождении внутри корпоративной сети или соединении с ней из любого места в Интернете.

Рассмотрим пример. Пользователь находится внутри корпоративной сети, и ему необходим доступ к серверу SharePoint Portal по адресу https://sps.domain.com. Использование разделенной DNS позволяет пользователю использовать адрес https://sps.domain.com при соединении с тем же сервером из любого места в Интернете.

Рассмотрим другой важный пример с использованием Outlook Web Access (OWA). При нахождении внутри корпоративной сети пользователь для доступа к OWA использует адрес https://owa.domain.com/exchange. При использовании разделенной DNS пользователь, находясь в Интернете, получит доступ к OWA с помощью того же адреса https://owa.domain.com/exchange.

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

ВНИМАНИЕ: Основная особенность: DNS-серверы, отвечающие за разрешение имен для внешних узлов, недоступны для внутренних узлов. DNS-серверы, отвечающие за разрешение имен для внутренних узлов, недоступны для внешних узлов. Полное разделение внутренних и внешних зон и серверов DNS – это главное, что позволяет разделенной DNS предоставлять необходимую прозрачность места расположения приложения.

DNS-сервер, отвечающий за разрешение имен корпоративной сети (внутренний DNS-сервер и зона), содержит записи ресурсов для сопоставления имен серверов их внутреннему IP-адресу, который обычно является адресом серверов во внутренней сети. Я говорю «обычно», поскольку на пути к серверу могут находиться внутренние устройства NAT. DNS-сервер, отвечающий за разрешение имен для пользователей из Интернета, разрешает имена серверов во внешний IP-адрес, открывая таким образом входящий доступ к ресурсам корпоративной сети. Внешний IP-адрес может быть привязан ко внешнему интерфейсу ISA-сервера и использоваться правилами web-публикации или правилами публикации сервера, а может быть привязан и NAT-устройству, находящемуся перед ISA-сервером.

Вот некоторые из ресурсов, к которым может быть открыт доступ для внешних и внутренних пользователей:

  • Web-сайты Outlook Web Access Пользователи используют один и тот же адрес для доступа к OWA, не взирая на то, находятся они внутри корпоративной сети или в Интернете.
  • Web-сайты сервера Sharepoint Portal Пользователи используют один и тот же адрес для доступа к службам SharePoint Portal, не взирая на то, находятся они внутри корпоративной сети или в Интернете.
  • Обычные web-сайты с корпоративной информацией То же самое применяется и здесь – пользователям не нужно запоминать различные имена для каждого места расположения. Они используют одно и то же имя не зависимо от того, где они находятся.
  • Доступ MAPI-клиента Exchange-сервера Разделенная DNS важна для безопасной публикации Exchange RPC. Без наличия хорошо разработанной разделенной структуры DNS вы не сможете увеличить безопасность, мобильность и прозрачность, предоставляемую безопасной публикацией Exchange RPC.
  • POP3-серверы Многие продолжают использовать POP3-доступ. Настройка клиента POP3 сложна для среднего пользователя. Сколько вы сэкономите на звонках в службу поддержки, если пользователям не придется больше перенастраивать POP3-клиента?
  • SMTP-серверы Многие компании предоставляют доступ к SMTP-серверу для внутренних и внешних пользователей. Подумайте, сколько может сэкономить ваша служба поддержки, если им не придется тратить время на перенастройку установок SMTP-сервера у пользователей, если последние работают вне офиса?
  • IMAP4-серверы Многие компании используют клиенты IMAP4. Вы увидите, что разделенная DNS предоставляет те же преимущества, что и в случае клиентов POP3. Больше не будет звонков в службы поддержки от пользователей, работающих вне офиса, с просьбой изменить настройки сервера IMAP4.
  • NNTP-серверы Здесь все то же самое. При работе вне офиса никакие перенастройки клиента NNTP не требуются.
  • Серверы терминалов Удаленный доступ к серверам терминалов становиться все более популярным. Пока вы даете пользователям два IP-адреса для работы, один внутри сети, другой – вне сети, подумайте об использовании всего одного простого имени FQDN в любом месте сети.
  • Шлюзы SSL VPN SSL VPN – очень важная тема, и она стала еще более важной после того, как компания Microsoft купила Whale. Разделенная DNS станет ключом к успеху для любого внедрения SSL VPN.

Подробности внедрения разделенной DNS

Посмотрим на структуру разделенной DNS для работы с OWA и SharePoint. В вашей корпоративной сети находятся серверы Exchange и SharePoint Portal. На внутреннем DNS-сервере создайте две записи узла (тип А) в зоне mydomain.net:

  • owa.mydomain.net Эта запись привязывается ко внутреннему IP-адресу сервера корпоративной сети или адресу шлюза корпоративной сети, через который осуществляется доступ к данному серверу, как в случае с внутренним устройством NAT
  • sps.mydomain.net Эта запись привязывается ко внутреннему IP-адресу сервера корпоративной сети или адресу шлюза корпоративной сети, через который осуществляется доступ к данному серверу, как в случае с внутренним устройством NAT

На внешнем DNS-сервере для домена mydomain.net также создайте две записи типа А:

  • owa.mydomain.net Эта запись привязывается ко внешнему IP-адресу, который осуществляет доступ к внутреннему сайту OWA. Этот адрес может быть IP-адресом, привязанным ко внешнему интерфейсу ISA-сервера, или же IP-адресом, привязанному ко внешнему устройству NAT, если между внешней сетью и внешним интерфейсом ISA-сервера располагается такое устройство
  • sps.mydomain.net Эта запись привязывается ко внешнему IP-адресу, который разрешает доступ ко внутреннему сайту SharePoint. Этот адрес может быть IP-адресом, привязанным ко внешнему интерфейсу ISA-сервера, или же IP-адресом, привязанному ко внешнему устройству NAT, если между внешней сетью и внешним интерфейсом ISA-сервера располагается такое устройство

Давайте рассмотрим, как клиент разрешает имена этих серверов. Корпоративная сеть для назначения IP-адресов узлам использует DHCP. DHCP-сервер сообщает IP-адрес внутреннего DNS-сервера узлам корпоративной сети. DNS-серверы, назначенные узлам корпоративной сети, являются полномочными для домена mydomain.net. Когда пользователи корпоративной сети соединяются с owa.mydomain.net, DNS-запрос ко внутреннему DNS-серверу предоставляет клиенту внутренний адрес сервера OWA. Пользователи получают прямой доступ к сайту OWA в корпоративной сети, минуя брандмауэр или любое другое устройство, использующееся для предоставления внешнего доступа к OWA-сайту.

Когда пользователи меняют внутреннюю сеть на внешнюю, они соединяются с внешним интерфейсом сети или провайдером и получают информацию об IP-адресе через DHCP. Внешнему узлу с помощью DHCP приписывается DNS-сервер для разрешения имен узлов Интернет. Когда пользователь внешней сети соединяется с owa.mydomain.net, DNS-сервер выдает клиенту внешней сети внешний адрес, который вы настроили для данного ресурса на внешнем DNS-сервере, полномочном для домена mydomain.net.

На рисунке показана схема работы разделенной DNS и соединений для внутренних и внешних узлов.

Проблемы с восприятием dns в isa

Рисунок 1

  1. Внешний компьютер посылает DNS-запрос на внешний DNS-сервер для разрешения имени owa.mydomain.net. DNS-серверы разрешают это имя с помощью опроса других DNS-серверов в Интернете
  2. DNS-сервер возвращает внешний IP-адрес owa.mydomain.net клиенту
  3. Внешний клиент посылает запрос на внешний адрес, предоставленный DNS-сервером. Это адрес, который используется для доступа внешних пользователей ко внутренним серверам. В данном запросе есть HTTP-заголовок для имени owa.mydomain.net
  4. ISA-сервер должен разрешать имя внутреннего DNS-сервера, основываясь на имени, настроенном в сертификате сайта OWA. В нашем примере, в сертификате OWA-сервера прописано имя owa.mydomain.net (обратите внимание, что оно ничего не имеет общего с именем сервера, с именем NetBIOS или с полностью определенным доменным именем в Active Directory). ISA-сервер настроен на использование внутреннего DNS-сервера и разрешает имя owa.mydomain.net во внутренний IP-адрес OWA-сайта.
  5. Теперь внутренний пользователь получает доступ к OWA-сайту. Внутренний OWA-клиент посылает DNS-запрос на внутренний DNS-сервер для имени owa.mydomain.net. Далее внутренний клиент посылает запрос к внутреннему IP-адресу OWA-сервера, который предоставлен ему внутренним DNS-сервером.

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

ВНИМАНИЕ: Существует много путаницы, касающейся роли Active Directory в структуре разделенной DNS. Разделенная DNS может быть встроена в домен Active Directory или же вы можете создать отдельную систему DNS и отделить ее от вашей разделенной DNS. Учтите, что в то время как Active Directory зависит от DNS, DNS не зависит от Active Directory. Поэтому, вы можете создать устойчивую разделенную DNS без нарушения соглашений именования в Active Directory.

Инфраструктура разделенной DNS для данной статьи

В данной статье я использовал чистую разделенную систему DNS, при которой внутреннее имя домена Active Directory то же самое, что и имена доменов, использующиеся внешними пользователями для доступа к сайту. Это не обязательное требование. Я мог бы создать параллельную инфраструктуру разделенной DNS, в которой имя домена Active Directory отличалось от того, что использовалось бы для доступа к сайтам.

Это важный момент, и мне следует объяснить его прежде, чем мы продолжим. Вы можете внедрить два типа инфраструктуры разделенной DNS:

  • Так называемую чистую инфраструктуру разделенной DNS, в которой внутреннее имя домена Active Directory является таким же, что и имя, которые внешние пользователи используют для доступа ко внутренним ресурсам
  • То, что называется параллельная инфраструктура разделенной DNS, в которой имя домена Active Directory никак не относится к инфраструктуре разделенной DNS, используемой для безопасного удаленного доступа

Параллельная инфраструктура разделенной DNS приемлема для тех, кто использует недопустимые имена доменов второго уровня (такие как этот ужасный .local), или по неверным соображениям безопасности уверен, что чистая инфраструктура разделенной DNS является единственной гарантией защиты (это не так, однако многие «эксперты» безопасности не понимают смысла безопасности и дают явно неверные советы).

Параллельная инфраструктура разделенной DNS относительно легка в настройке, но все-таки вам придется немного попотеть при ее создании. Параллельная инфраструктура разделенной DNS работает по тем же принципам, что и внутренняя DNS. Внешняя DNS поддерживает те же имена доменов, внутренняя DNS предоставляет разрешение внутренних имен, а внешняя – разрешение имен для внешних клиентов. Единственное отличие состоит в том, что для поддержки вам нужно создать новую зону DNS во внутренней сети.

Для примера, представим следующее:

  • Внутреннее имя домена Active Directory — corp.net
  • Некие «эксперты» по безопасности ввели руководство в заблуждение, не разрешив использовать имя corp.net для безопасного удаленного доступа
  • У вас уже есть внешнее имя домена externalcorp.net для безопасного удаленного доступа

В этом примере вы создаете на вашем внутреннем DNS-сервере новую зону для домена externalcorp.net. Далее вы вводите записи ресурсов для всех серверов корпоративной сети, которые принимаю входящие соединения от внешних пользователей. Вам не нужно копировать всю внутреннюю систему DNS, вы просто включаете в нее записи для опубликованных серверов. Хотя в больших организациях такая схема повлечет дополнительные административные издержки, я думаю, что это не станет проблемой, поскольку IP-адреса серверов являются статическими и редко изменяются. На внешней DNS вам не нужно ничего менять. Если у вас уже есть зона для домена externalcorp.net, все в порядке. Добавление внутренней зоны не изменит настройки внешней зоны. Это справедливо и для чистой и для параллельной инфраструктуры разделенной DNS.

Соглашение по связанному именованию в разделенной DNS

В тестовых условиях, которые мы используем в данной статье, я буду использовать подсеть с чистой инфраструктурой разделенной DNS с помощью соглашения по связанному именованию в разделенной DNS. При использования соглашения по связанному именованию в разделенной DNS полностью определенное доменное имя ресурса (FQDN), которое внешние пользователи используют для доступа к опубликованным web-серверам, является тем же самым именем, которое использует ISA-сервер. Единственное различие состоит в том, что внешние пользователи соединяются с опубликованными web-серверами посредством внешнего IP-адреса, а ISA-сервер соединяется с ними с помощью внутреннего IP-адреса.

В нашем правиле web-публикации для OWA и RCP/HTTP мы используем имя owa.msfirewall.org. ISA-сервер тоже будет настроен на использование этого же имени owa.msfirewall.org для переадресации соединений на внутренние Exchange-серверы. Сделано это вопреки удобству, но не вопреки необходимости. Неверно считать, что вы обязаны использовать связанное именование, это не так. Однако, если вы этого не делаете, у вас могут возникнуть трудности с разделенной DNS, и могут исчезнуть основные функции, которые она выполняет.

Например, можно было бы настроить внешних пользователей на использование адреса owa.msfirewall.org для соединения с опубликованными сайтами OWA и RPC/HTTP, ISA-сервер настроить на адрес mail.msfirewall.org. Такая схема работала бы хорошо, но это разрушило бы нашу структуру разделенной DNS, поскольку пользователи, находящиеся в Интернете, должны были бы помнить имя owa.msfirewall.org, которое при нахождении во внутренней сети заменилось бы для них на mail.msfirewall.org. Поскольку целью использования разделенной DNS является устранение этой проблемы, нет смысла использовать схему связанного именования.

Существует другая причина для отказа от использования схемы связанного именования в разделенной DNS: это использование сертификатов и их имен. Этот вопрос мы рассмотрим в следующем разделе.

Важность соглашений по именованию сертификатов

Продолжим работу с нашим примером для понимания того, что соглашение по именованию сертификатов очень важно для инфраструктуры разделенной DNS. Как видно из примера, пользователи нашей тестовой сети получают доступ к сайтам OWA и RPC/HTTP с помощью имени owa.msfirewall.org и из внутренней сети за ISA-сервером, и из внешней сети. Это происходит из-за того, что мы используем соглашение по связанному именованию в разделенной DNS.

Теперь представим, что мы не используем соглашение по связанному именованию в разделенной DNS.В этом случае обычным именем сертификата web-сайта, привязанного к web-приемнику, публикующему сайты OWA и RPC/HTTP является owa.msfirewall.org. Поскольку мы не используем соглашение по связанному именованию в разделенной DNS, мы привязываем сертификат к прокси-серверу OWA и RPC/HTTP с именем mail.msfirewall.org. Какие результаты мы увидим?

  • Внешние пользователи смогут использовать имя owa.msfirewall.org для доступа к сайтам OWA и RPC/HTTP, поскольку web-приемник прослушивает соединения с адресом owa.msfirewall.org и именем сертификата является owa.msfirewall.org.
  • ISA-сервер настроен на переадресацию соединений на mail.msfirewall.org, поскольку это имя сертификата web-сайта, привязанного к сайту OWA и RPC/HTTP. Имя mail.msfirewall.org разрешается в IP-адрес web-сайта во внутренней сети (предположим, что в сети нет внутренних устройств NAT)
  • Внутренние пользователи используют имя mail.msfirewall.org для доступа к сайтам OWA и RPC/HTTP, поскольку это обычное имя сертификата, привязанного к сайту. Внутренние пользователи могут соединяться, поскольку их запрос к сайту содержит то же самое имя, что и сертификат
  • Пользователям должны помнить адрес https://owa.msfirewall.org/exchange при соединении из внешней сети, и адрес https://mail.msfirewall.org/exchange при соединении из внутренней сети.
  • К тому же пользователи должны помнить о перенастройке Outlook RPC/HTTP в зависимости от места их расположения. Если пользователи находятся в Интернете, они должны настроить Outlook на связь с адресом owa.msfirewall.org, а если они находятся во внутренней сети — на связь с адресом mail.msfirewall.org или на использование MAPI-соединений (что является установкой по умолчанию).

Ситуация не так уж ужасна для клиентов RPC/HTTP, поскольку они должны быть настроены на использование MAPI RPC при соединении с корпоративной сетью, но мы знаем, что не всегда все это работает гладко, и иногда соединения RPC/HTTP используются в корпоративной сети тогда, когда не нужно (загруженные сети с относительно большим временем ожидания). Для пользователей OWA ситуация очень критична, поскольку они должны помнить об использовании разных имен в разных случаях.

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

  • Имя сертификата должно совпадать с именем, которое использует клиент для соединения с сайтом. Если клиент использует имя http://owa.domain.com, именем сертификата должно быть owa.domain.com
  • Имя сертификата не связано с именем NetBIOS или DNS компьютера. Однако, для того, чтобы соединяться с сервером, должна существовать запись DNS для имени сертификата, привязанного к web-сайту или web-приемнику, поскольку это то имя, которое используют пользователи. Например, имя компьютера в DNS Active Directory может быть serverA.domain.com, но имя сертификата, привязанного к web-сайту, будет mail.domain.com. Требуется запись в DNS для обоих имен, но с одним IP-адресом
  • Несколько правил web-публикации могут переадресовывать запросы на одно и то же имя, даже если они используют web-приемники с сертификатами с разным именем. Например, web-приемник 1 прослушивает соединения с rpc.msfirewall.org, а web-приемник 2 – соединения с mail.domain.com. Правила web-публикации, использующие эти web-приемники, могут быть настроены на переадресацию соединений на один и тот же безопасный сайт, который использует сертификат с именем exchange.msfirewall.org

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

Резюме

Перед внедрением решения для работы ISA-сервера при безопасной публикации сайтов OWA и RPC/HTTP следует разобраться с DNS и именами сертификатов. Лучшим решением DNS для безопасного удаленного доступа к сайтам OWA и RPC/HTTP является чистая инфраструктура разделенной DNS со вспомогательной параллельной инфраструктурой разделенной DNS. Очень плохим решением для безопасного удаленного доступа к сайтам OWA и RPC/HTTP является использование разных имен для внутреннего и внешнего доступа, поскольку это требует от пользователей постоянного запоминания различных имен.

Именование сертификатов тесно связано с инфраструктурой DNS. Имя сертификата должно совпадать с именем, которое пользователь использует для доступа к сайту. При публикации безопасных сайтов на ISA-сервере, внешние пользователи должны использовать имя сертификата web-приемника в правиле web-публикации, а ISA-сервер должен соединяться с опубликованными web-серверами, используя привязанное к web-сайту имя.

В следующей статье мы займемся более интересным делом: мы настроим ISA-сервер для публикации web-приложений внешних Exchange-серверов. Увидимся!

www.isaserver.org


Смотрите также:

Tags: , , , , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]