Monday, December 11th, 2017

Публикация сайтов Интернет-подключений к удаленному рабочему столу с помощью ISA-сервера Часть 3: Проверка и устранение неисправностей

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

В первой части статьи о публикации сайтов интернет-подключений к удаленному рабочему столу мы рассмотрели вопросы работы интернет-подключений к удаленному рабочему столу. Во второй части мы рассмотрели настройки, связанные с публикацией web-сервера служб удаленного рабочего стола и RDP-сервера. В третьей части мы обсудим важные проблемы, возникающие при публикации web- и RDP-серверов.

Если вы хотите прочесть остальные части статьи, воспользуйтесь ссылкой:

Проверка решения

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

В нашем примере мы создали в файле HOSTS запись для имени tsweb.msfirewall.org. Она и будет разрешать это имя в IP-адрес web-приемника.

Для тестирования выполните следующие действия на компьютере-клиенте:

  1. На компьютере-клиенте во внешней сети откройте Internet Explorer. В адресной строке введите https://tsweb.msfirewall.org и нажмите ENTER.
  2. Введите учетные данные в диалоговом окне Connect to (Соединиться с) и нажмите OK.

    Сайт для удаленного подключения

    Рисунок 1

  3. Если вы используете Windows XP Service Pack 2, вы обнаружите, что при первом посещении сайта настройки ActiveX блокированы. В диалоговом окне, сообщающем о невозможности установки компонентов ActiveX, нажмите OK.
  4. В Internet Explorer нажмите на информационную панель и установите компоненты ActiveX. В диалоговом окне Internet Explorer – Security Warning (Предупреждение системы безопасности Internet Explorer) нажмите Install (Установить).
  5. После установки компонентов ActiveX появится окно Remote Desktop Web Connection (Интернет-подключение к удаленному рабочему столу). В текстовое поле Server (Сервер) введите имя сервера. В нашем примере это tsweb.msfirewall.org. Обратите внимание, что это имя разрешается в IP-адрес, использованный в приемнике для правила публикации RDP-сервера. Также учтите, что это имя может и не быть реальным именем сервера в корпоративной сети. Не важно, какое имя у сервера. Важно то, что имя, введенное в поле Server (Сервер), разрешается в IP-адрес, который связан с приемником для правила публикации RDP-сервера. Установите флажок в поле Send logon information for this connection (Послать информацию для этого соединения) и введите в текстовые поля User name (Имя пользователя) и Domain (Домен) необходимую информацию. Нажмите Connect (Соединить).

    Соединение закрыто удаленным сервером

    Рисунок 2

  6. В полноэкранном режиме появится диалоговое окно входа службы терминалов. Поля User name (Имя пользователя) и Domain (Домен) заполняются автоматически. Введите пароль и нажмите OK.

    Интернет подключение к удаленному рабочему столу

    Рисунок 3

  7. Теперь вы зашли в сессию службы терминалов. Все работает!

Устранение неисправностей

Хотя все процедуры кажутся простыми, существует несколько проблем, описание которых периодически появляется на досках объявлений сервера ISAserver.org, почтовых рассылках и сетевых конференциях. Некоторые из этих проблем связаны с ошибками в настройках ISA-сервера, а некоторые совсем не связаны с настройками ISA-сервера. Мы рассмотрим проблемы обоих типов.

Обычные проблемы:

  • Не запускается служба RDP на RDP-сервере
  • Внешний интерфейс ISA-сервера использует частный IP-адрес
  • Не проходит аутентификация на ISA-сервере
  • При соединении клиента появляется окно сертификатов

Не запускается служба RDP на RDP-сервере

Представьте себе такой сценарий: вы прочли статью и сделали все, о чем я рассказал. Вы хорошо понимаете модели web-публикации и публикации серверов, сеть Windows и работу протокола TCP/IP. Кажется, что все сделано правильно, однако при попытке связи с удаленным рабочим столом связь постоянно нарушается.

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

Первый вопрос, который вы себе задаете: «Интересно, чтобы случилось, если бы я использовал встроенный клиент подключения к удаленному рабочему столу для связи с RDP-сайтом и не возился бы с интернет-подключением к удаленному рабочему столу?» Вы запускаете клиента RDP и соединяетесь с IP-адресом приемника в правиле публикации RDP-сервера. Перед вами появляется такое окно:

Сайт для удаленного подключения

Рисунок 4

Если вы посмотрите в файлах журнала ISA-сервера записи, связанные с вашей попыткой соединения, вы увидите что-то подобное Рисунку 5. Обратите внимание, что нигде в записях нет информации о том, что соединение не разрешено. Все записи в колонке Action (Действие) это Initiated Connection (Создание соединения) и Closed Connection (Закрытие соединения).

Это приводит нас к следующим выводам:

  • Нет правил, запрещающих соединение
  • Есть правило, разрешающее соединение

Если вы пришли к таким выводам, вы абсолютно правы. Есть правило, разрешающее соединение. Это правило публикации RDP-сервера. Нет правил, запрещающих соединение.

Соединение закрыто удаленным сервером

Рисунок 5

Ну и что? Что вызывает обрыв соединения? Ключ к решению находится в колонке Result Code (Код результата). Здесь вы видите, что код при закрытии соединения равняется 0x80074e21. Этот код означает, что, либо сервер, либо клиент закрыл соединение при TCP RST. Ладно, а что такое TCP RST?

TCP RST – это сегмент TCP (обратите внимание, что TCP посылает сообщения сегментами, а НЕ пакетами, что часто неправильно употребляется в среде сетевых администраторов), который показывает, что с соединением что-то не так. RST посылается в следующих случаях:

  • Посылается SYN для несуществующего сервера.
  • TCP хочет прервать соединение.
  • Получен сегмент, для которого не существует соединения.

В нашем случае – это первая причина. «Несуществующий сервер» — это отсутствие включенного RDP-приемника на сервере терминалов или сервере подключений к удаленному рабочему столу (например, Windows XP). Если вы включите приемник на сервере терминалов или разрешите удаленные соединения с опубликованным сервером подключений к удаленному рабочему столу (например, Windows XP Professional или Windows Server 2003 Admin RDP), все будет работать.

На будущее: в таблицах 1 и 2 указаны коды ошибок ISA-сервера, которые помогут вам решить проблемы с помощью кода из колонки Result Code (Код результата) файла журнала ISA-сервера. Эта информация получена с сайта MSDN по адресу http://msdn.microsoft.com/library/default.asp?url=/library/en-us/isasdk/isa/error_codes.asp

Символическое имя Шестнадцатеричный идентификатор Сообщение
FWX_E_TERMINATING 0xC0040001 Объект отключается.
FWX_E_INVALID_ARG 0xC0040002 Неверный аргумент.
FWX_E_ALREADY_IN_BLOCKING_OP 0xC0040003 Операция уже запущена.
FWX_E_NOT_IN_BLOCKING_OP 0xC0040004 Нет операции для завершения.
FWX_E_FILTER_NOT_REGISTERED 0xC0040005 Фильтр не зарегистрирован.
FWX_E_ALREADY_EXISTS 0x800700B7 Объект не может быть создан, поскольку уже есть объект с таким именем.
FWX_E_BUFFERFULL 0xC0040007 Не все данные помещены в буфер, поскольку буфер переполнен.
FWX_E_ALREADY_EMULATED 0xC0040009 Соединение уже эмулировано другим фильтром.
FWX_E_BAD_CONTEXT 0xC004000A Метод не был вызван при работе с поддерживаемыми событиями.
FWX_E_NOT_SUPPORTED 0xC004000B Изменение этого свойства в данной сессии запрещено.
FWX_E_NOT_AUTHENTICATED 0xC004000C Действие не может быть выполнено, поскольку сессия не аутентифицирована.
FWX_E_POLICY_RULES_DENIED 0xC004000D Правила политики не разрешают запрос пользователя.
FWX_E_MIME_NEEDED 0xC004000E Требуется MIME-тип.
FWX_E_MUST_USE_DS 0xC004000F
FWX_E_NOT_EMULATED 0xC0040010 Соединение не эмулировано
FWX_E_IS_BUSY 0xC0040011
FWX_E_NETWORK_RULES_DENIED 0xC0040012
FWX_E_FRAGMENT_PACKET_DROPPED 0xC0040013
FWX_E_FWE_SPOOFING_PACKET_DROPPED 0xC0040014
FWX_E_TCPIPDROP_PACKET_DROPPED 0xC0040015
FWX_E_NO_BACKLOG_PACKET_DROPPED 0xC0040016
FWX_E_TCP_NOT_SYN_PACKET_DROPPED 0xC0040017 Не-SYN пакет был отброшен, поскольку он был послан источником, который не установил соединение с ISA-сервером.
FWX_E_BAD_LENGTH_PACKET_DROPPED 0xC0040018
FWX_E_PING_OF_DEATH_PACKET_DROPPED 0xC0040019
FWX_E_OUT_OF_BAND_PACKET_DROPPED 0xC004001A
FWX_E_IP_HALF_SCAN_PACKET_DROPPED 0xC004001B
FWX_E_LAND_ATTACK_DROPPED 0xC004001C
FWX_E_UDP_BOMB_DROPPED 0xC004001D
FWX_E_FULLDENY_DROPPED 0xC004001E
FWX_E_IPOPTIONS_DROPPED 0xC004001F
FWX_E_UNCOMPLETED_CONNECTION_REQUEST 0xC0040020 Попытка входа на VPN-сервер отклонена во время аутентификации, поскольку данные не были своевременно получены. Сессия завершена.
FWX_E_CONNECTION_REQUEST_REJECTED 0xC0040021 Попытка входа на VPN-сервер отклонена во время аутентификации. Сессия завершена.
FWX_E_VALIDATE_QUARANTINE_FAILED 0xC0040022 Установки карантина VPN не подтверждены. Сессия завершена.
FWX_E_VPN_CONNECTIONS_LIMIT_EXCEEDED 0xC0040023 Достигнут предел VPN-соединений. Сессия завершена.
FWX_E_OUT_OF_RESOURCES 0xC0040024
FWX_E_BROADCAST_PACKET_DROPPED 0xC0040025
FWX_E_UNKNOWN_ADAPTER_DROPPED 0xC0040026
FWX_E_ICMP_ERROR_PACKET_DROPPED 0xC0040027
FWX_E_INVALID_PROTCOL_PACKET_DROPPED 0xC0040028
FWX_E_PORT_ZERO_PACKET_DROPPED 0xC0040029
FWX_E_SYN_ATTACK_START 0xC004002A ISA-сервер обнаружил SYN-атаку.
FWX_E_SYN_ATTACK_END 0xC004002B ISA-сервер больше не испытывает SYN-атаку.
FWX_E_INVALID_DHCP_OFFER 0xC004002C
FWX_E_UNREACHABLE_ADDRESS 0xC004002D
FWX_E_ADDRESS_NOT_ALLOWED 0xC004002E
FWX_E_IPSEC_NO_ROUTE_DROPPED 0xC004002F
FWX_E_OUTBOUND_PATH_THROUGH_DROPPED 0xC0040030
FWX_E_BAD_TCP_CHECKSUM_DROPPED 0xC0040031
FWX_E_VPN_USER_MAPPING_FAILED 0xC0040032 Попытка присоединить VPN-клиента к пользователю Windows не удалась. Сессия завершена.
FWX_E_RULE_QUOTA_EXCEEDED_DROPPED 0xC0040033 Соединение было отклонено, поскольку достигнуто максимальное число соединений, установленных правилом.
FWX_E_SEQ_ACK_MISMATCH 0xC0040034 TCP-пакет был отклонен, поскольку неверен его порядковый номер или номер подтверждения.

Таблица 1: Коды ошибок служб брандмауэра

Символическое имя Шестнадцатеричный идентификатор Описание
WSA_RWS_GRACEFUL_SHUTDOWN или FWX_E_GRACEFUL_SHUTDOWN 0x80074E20 Соединение было закрыто процессом завершения работы после синхронизации, инициированной пакетом FIN.
WSA_RWS_ABORTIVE_SHUTDOWN или FWX_E_ABORTIVE_SHUTDOWN 0x80074E21 Соединение было закрыто после посылки RST-сегмента.
WSA_RWS_QUOTA или FWX_E_RULE_QUOTA_EXCEEDED_DROPPED 0x80074E23 Соединение было отклонено из-за переполнения квоты, установленной в правиле.
WSA_RWS_CONNECTION_KILLED или FWX_E_CONNECTION_KILLED 0x80074E24 ISA-сервер прервал соединение.
WSA_RWS_TIMEOUT или FWX_E_TIMEOUT 0x80074E25 Соединение было прервано, поскольку истек период ожидания, или период ожидания незавершенного действия закончился.
WSA_RWS_ADMIN_TERMINATE или FWX_E_ADMIN_TERMINATE 0x80074E26 Соединение было завершено с помощью консоли управления ISA-сервера во время завершения работы или при отключении VPN-клиента.

Таблица 2: Дополнительные коды, возвращаемые службами брандмауэра, которые могут появиться в файлах журнала ISA-сервера.

Внешний интерфейс ISA-сервера использует частный IP-адрес

Это частая проблема в сетях с внешним устройством NAT перед ISA-сервером. NAT-устройство может быть как простым NAT-устройством, типа маршрутизатора широкополосной сети, так и брандмауэром с функцией обычной проверки пакетов, типа PIX или Sonicwall. Общего у маршрутизатора широкополосной сети и брандмауэра с функцией обычной проверки пакетов то, что они отвечают за Интернет-соединения и выполняют трансляцию сетевых адресов (в любой форме) между своими LAN и WAN интерфейсами.

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

На Рисунке 6 показан пример такой ситуации. NAT-устройство использует открытый адрес, который приписан к WAN-интерфейсу, и частный адрес, который привязан к LAN-интерфейсу, и осуществляет сетевое распределение адресов для соединений между этими двумя интерфейсами. ISA-сервер имеет частный адрес и на внутреннем, и на внешнем интерфейсе. ISA-сервер также осуществляет сетевой распределение между внутренним и внешним интерфейсом (однако, у вас есть возможность маршрутизации между этими интерфейсами, что является очень удобным при сценарии с сервером SBS 2003, при котором перед ISA-сервером находится NAT/VPN-устройство и VPN-соединение между этим NAT/VPN-устройством и другим устройством.)

Как уже было отмечено в этой статье, внешним клиентам требуется возможность опроса публичного DNS-сервера для разрешения имен, использующихся для связи с сайтом подключений удаленного рабочего стола и правилом публикации RDP-сервера. Я уже говорил, что DNS-сервер должен разрешать имена, которые клиенты удаленного рабочего стола используют для доступа к сайту и приемнику правила публикации RDP-сервера, в IP-адреса web-приемника и приемника правила публикации RDP-сервера.

При рассмотрении различных сценариев подключения ISA-сервера я столкнулся с проблемой, которая состояла в том, что я предполагал, что у вас внешний интерфейс ISA-сервера имеет публичный IP-адрес. Если внешний интерфейс ISA-сервера имеет публичный IP-адрес, все мои комментарии об именах, которые внешние пользователи используют для доступа к web и RDP-сайтам и которые разрешаются в IP-адрес внешнего интерфейса ISA-сервера, верны. Однако, при наличии перед ISA-сервером NAT-устройства данный совет является неверным, поскольку внешние пользователи не могут соединяться с частным IP-адресом.

Для простоты (в основном для себя) я всегда предполагаю, что внешний интерфейс ISA-сервера имеет публичный IP-адрес, или же, если у вас есть NAT-устройство перед ISA-сервером, вы понимаете последствия данной конфигурации. Однако, все эти предположения используются только для моего удобства и не обязательно отражают знания пользователей ISA-сервера.

На рисунке ниже представлен типичный случай неправильной настройки, которая ведет к невозможности установления как web, так и RDP-соединений. Пользователь настроил на DNS-сервере запись узла (запись типа А), которая разрешает имя, используемое для связи с web- и RDP-сайтами в IP-адрес внешнего интерфейса ISA-сервера. Такая схема не будет работать, поскольку IP-адрес внешнего интерфейса ISA-сервера — это частный адрес, который не доступен напрямую из Интернета.

Интернет подключение к удаленному рабочему столу

Рисунок 6

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

Подключение к терминальному серверу с помощью

Рисунок 7

Правильная запись в DNS – это только половина проблемы. Вторая половина – это настройка NAT-устройства на переадресацию соединений на правильный IP-адрес внешнего интерфейса ISA-сервера. Обычно это называется переадресация портов. В нашем сценарии вам нужно переадресовать входящие соединения с TCP-портом 80 и 3389 на IP-адрес внешнего интерфейса ISA-сервера.

В нашем случае это очень просто, поскольку ко внешнему интерфейсу ISA-сервера привязан только один IP-адрес, и у нас есть только один опубликованный RDP-сервер. Сложнее (но не намного) настроить на работу схему с несколькими RDP-серверами, поскольку к WAN-интерфейсу NAT-устройства нужно привязать несколько IP-адресов. Несколько частных IP-адресов нужно привязать и ко внешнему интерфейсу ISA-сервера.

Еще одна вещь, на которую стоит обратить внимание, это настройка шлюза по умолчанию на внешнем интерфейсе ISA-сервера. Шлюзом по умолчанию на внешнем интерфейсе ISA-сервера должен быть IP-адрес LAN-интерфейса NAT-устройства.

Не проходит аутентификация на ISA-сервере

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

Однако, для того, чтобы ISA-сервер смог аутентифицировать пользователя, он должен использовать один из методов аутентификации. Для правил web-публикации вы можете использовать следующие методы:

  • Локальная база данных SAM, расположенная на ISA-сервере
  • Внутренняя база данных Active Directory
  • RADIUS-аутентификация и каталог пользователей RADIUS

Не рекомендуется хранить базу данных пользователей на ISA-сервере, поскольку затраты на управление синхронизацией паролей могут стать огромными. К тому же есть вероятность, хотя и очень маленькая, что ISA-сервер будет «захвачен» и все данные будут доступны злоумышленникам.

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

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

  • Сервер безопасного удаленного доступа VPN и шлюз
  • Брандмауэр входящего доступа для web-публикаций и публикаций серверов
  • Брандмауэр исходящего доступа для клиентов SecureNAT, Web-прокси и брандмауэра

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

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

ИТОГ:
При настройке предварительной аутентификации на ISA-сервере выберите метод аутентификации. При одном ISA-сервере, ответственном за контроль входящего и исходящего доступа, всегда делаете его членом домена и используйте встроенную аутентификацию Active Directory. Если ISA-сервер осуществляет только контроль входящего доступа, используйте RADIUS-аутентификацию.

При соединении клиента появляется окно сертификатов

При настройке SSL-соединений ISA-сервера у вас есть два варианта использования сертификатов:

  • Использовать коммерческий сертификат
  • Использовать частный сертификат

Коммерческие сертификаты покупаются у коммерческих центров сертификации. Примером может служить компания Verisign. Частные сертификаты вы создаете сами (или их создают для вас), и они не являются частью сети коммерческих центров сертификации.

Преимущество использования частных сертификатов в том, что вы их создаете сами. Недостаток: никто, кроме вас, не доверяет этим сертификатам. Если у вас есть домен Active Directory, вы можете автоматически настроить все компьютеры-члены домена на то, чтобы они доверяли созданным вами сертификатам. Компьютеры — не члены домена вам придется настраивать на доверительные отношения с сертификатом.

Этот факт является преимуществом коммерческих сертификатов. Большинство компьютеров под управлением Windows изначально доверяют большинству коммерческих центров сертификации. Вам не потребуется добавлять сертификат коммерческого центра сертификации в хранилище Trusted Root Certification Authorities (Доверенные корневые центры сертификации), поскольку компания Microsoft уже поместила их туда и периодически их обновляет.

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

Однако, если у вас не все компьютеры являются членами домена или у некоторых компьютеров не установлен сертификат центра сертификации в хранилище Trusted Root Certification Authorities (Доверенные корневые центры сертификации), то пользователи при доступе к SSL-сайтам увидят диалоговое окно, сообщающее им, что их компьютер не доверяет сертификату web-сайта. Обычный пользователь не понимает, что происходит и либо закрывает появившееся окно, либо звонит в службу поддержки.

Для решения этой проблемы необходимо установить сертификат центра сертификации в хранилище Trusted Root Certification Authorities (Доверенные корневые центры сертификации) на всех компьютерах, которые соединяются с защищенными web-сайтами. Есть несколько способов сделать это, включая использование web-сайта регистрации, групповые политики Active Directory и оснастку Certificates (Сертификаты). Проблема внедрения и поддержки PKI находится далеко за пределами этой статьи, однако вы можете почерпнуть некоторую информацию по установке различных центров сертификации и сертификатов.

Резюме

В данной части мы завершили статью о публикации интернет-подключений к удаленному рабочему столу. Мы протестировали наше решение и рассмотрели некоторые возможные проблемы. Надеюсь, вы узнали о web-публикации и публикации серверов что-то новое, и я был бы счастлив узнать от вас, какую информацию вы еще желаете получить.  Спасибо!

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 – часть ... [+]