Лучший отвечающий
Exchange-VPN-DC

Вопрос
-
Добрый день, коллеги! Нужен совет - собираюсь вот развернуть Exchange 2010 на внешнем сервере, при этом контроллер домена, который будет обслуживать Exchange, находится в офисной локалке. Можно ли сделать так - соединить Exchange-server и нашу сетку по VPN? В итоге Exchange будет иметь как внешний IP (MX), так и адрес из сетки 192.168.1.1/24 (связь с DC и с рабочими станциями офиса). Какой ширины канала будет достаточно для работы почты? И если вдруг упадет VPN, будет ли Exchange продолжать принимать входящую почту для адресатов в нашем домене? Заранее спасибо за ответы.16 ноября 2011 г. 10:53
Ответы
-
Если вы у вас будет достаточно мощьный сервер. То вы можете создать
1. Развернуть Hyper-V.
2. Создать ресурсный домен.
3. Установить домен контроллер для ресурсурсного домена AD + DNS + PKI .
4. Установить Edge Exchange 2010 SP1, FPE 2010 SP1, TMG 2010 SP2.
5. Установить Еchange 2010 SP1 CAS/HUB/MBX.
6. Через VPN создать односторонние трасты с доменом в компании.
Комментарии.
Можно не создавать ресурсный домен, тогда увеличиваються риски получения доступа во внутрь компании.
Более безопасное решение и дешевле по стоимость владения, это Exchange, SharePoint, Lync Online Could.
MCITP. Знание - не уменьшает нашей глупости.- Помечено в качестве ответа Yuriy Lenchenkov 28 ноября 2011 г. 12:57
17 ноября 2011 г. 5:51Модератор
Все ответы
-
День добрый.
На сайте, где будет находиться Exchange, должен быть установлен доменный контроллер с ролью GC. В противном случае при падении VPN Exchange, не будет корректно работать.
MCITP. Знание - не уменьшает нашей глупости.16 ноября 2011 г. 13:41Модератор -
А если арендуется всего один сервер, зато мощный? Может быть, следует установить доменный контроллер в виде виртуальной машины? Или это должен быть отдельный физический сервер?
Еще вариант - собрать Hyper-V Core, а на нем собрать DC и Exchange, объединив их виртуальной сетью. В распоряжении 12 Гб ОЗУ - как думаете, этого хватит?
16 ноября 2011 г. 14:28 -
Наверное, неправильно Вас понял :-) Вы хотели сказать, что сервер, на котором будет разворачиваться Exchange 2010, должен быть с ролью Global Catalog?16 ноября 2011 г. 14:39
-
Если вы у вас будет достаточно мощьный сервер. То вы можете создать
1. Развернуть Hyper-V.
2. Создать ресурсный домен.
3. Установить домен контроллер для ресурсурсного домена AD + DNS + PKI .
4. Установить Edge Exchange 2010 SP1, FPE 2010 SP1, TMG 2010 SP2.
5. Установить Еchange 2010 SP1 CAS/HUB/MBX.
6. Через VPN создать односторонние трасты с доменом в компании.
Комментарии.
Можно не создавать ресурсный домен, тогда увеличиваються риски получения доступа во внутрь компании.
Более безопасное решение и дешевле по стоимость владения, это Exchange, SharePoint, Lync Online Could.
MCITP. Знание - не уменьшает нашей глупости.- Помечено в качестве ответа Yuriy Lenchenkov 28 ноября 2011 г. 12:57
17 ноября 2011 г. 5:51Модератор -
Сейчас смастерил так:
- новый домен, его контроллер - на удаленном сервере;
- Exchange - на этом же сервере, что позволит почтовому серверу работать напрямую с доменом;
- VPN между Exchange и офисной локалкой, в локалке будет находиться второй DC этого домена;
Единственное, что не соображу никак - какой адрес будет выдавать DHCP моего Exchange-сервера? Обычно как делал - настраивал RRAS, клиентам, подключающимся извне, выдавался адрес из подсети 192.168.1.0/24 и это позволяло удаленным клиентам работать со всеми сетевыми ресурсами компании. Если я подниму RRAS на Exchange (а он имеет только один сетевой контроллер с реальным IP-адресом), как сотрудники смогут получать почту в офисе? Или я не в том направлении копаю? :-) Мне нужно настроить Outlook сотрудников таким образом, чтобы они могли работать с Exchange по MAPI. Скажем так - должен ли Exchange-сервер находиться в той же подсети, что и клиенты Outlook, для корректной работы MAPI?
18 ноября 2011 г. 0:08 -
MCITP. Знание - не уменьшает нашей глупости.18 ноября 2011 г. 6:10Модератор -
Схема решения. Но я бы не заморачивался взял решение в облаках.
Пример.
http://cloud.softline.ru/catalog/category/communications
MCITP. Знание - не уменьшает нашей глупости.18 ноября 2011 г. 6:13Модератор -
Хочу вот что уточнить еще:
1) для корректной работы через RPC over HTTP должны ли клиенты Outlook состоять в том же домене, что и Exchange? Если человек будет работать из дома, используя Windows Home Edition, сможет ли он работать с почтой?
2) допускается ли использование сразу двух почтовых серверов на одном домене? Что имею ввиду - MX-запись сейчас ссылается на чужой сервер (временно арендованный, на UNIX-платформе), смогу ли я добавить еще одну MX-запись, чтобы наш почтовый домен обслуживали какое-то время сразу 2 сервера?
18 ноября 2011 г. 12:38 -
1. Человек сможет работать удаленно с любой точки мира.
2. Это называеться, сосуществование и разделение smtp домена, его можно настроить.
MCITP. Знание - не уменьшает нашей глупости.
- Изменено Oleg.KovalenkoModerator 18 ноября 2011 г. 13:21
18 ноября 2011 г. 13:20Модератор -
по второму пункту -
разве недостаточно будет в админке нашей прописать еще один почтовый сервер, с другим IP-адресом? Серверы все-таки должны знать о существовании друг друга? Можно ли настроить по приоритетам? - то есть если сервер A не принял сообщение, оно идет на сервер B.
18 ноября 2011 г. 13:27 -
Требуеться настройка и пересылка письма из Unix, если почтовый ящик находиться в Exchange. И пересылкаписьма из Exchange в Интернет, через Unix (В зависимости от настроек DNS).
MCITP. Знание - не уменьшает нашей глупости.- Изменено Oleg.KovalenkoModerator 18 ноября 2011 г. 13:57
18 ноября 2011 г. 13:55Модератор -
Возможно, немного отклоняюсь от темы - хотел уточнить по поводу авторизации Exchange. Что непонятно - настройки позволяют выбрать либо аутентификацию через веб-формы, либо Windows-аутентификацию. Что нужно мне - чтобы если сотрудник из локалки заходит на Веб-сайт Exchange (owa), его бы автоматически Exchange пускал, то есть он должен сразу видеть список сообщений и в правом верхнем углу имя своей учетки. (подразумевается, что этот компьютер состоит в домене и человек заходит из-под доменной учетки). А если он заходит извне, то должна работать авторизация по логин-паролю. Вот не пойму, можно ли совместить эти методы на одном сервере? Пока что выходит - или-или.21 ноября 2011 г. 10:50
-
По безопасности рекомендуеться использовать в OWA Basic authentication и HTTPS.
http://technet.microsoft.com/en-us/library/bb125207.aspx
MCITP. Знание - не уменьшает нашей глупости.- Изменено Oleg.KovalenkoModerator 21 ноября 2011 г. 11:13
21 ноября 2011 г. 11:11Модератор -
Вы знаете, не получилось у меня пока что с VPN - связать основной и резервный контроллеры домена - один находится на удаленном сервере, второй (резервный) - в офисе. Как я делал: на удаленном сервере добавил компонент Routing and remote access, настроил учетку Администратора на удаленный доступ. Диапазон адресов, выдаваемых при подключении клиентов по PPTP, назначил от 192.168.1.100 до 192.168.1.103.
В локалке развернул виртуальную машину (резервный DC), дал ей IP из той же подсети, 192.168.1.20, DNS у нее - это DNS нашего шлюза в локалке. Подключаюсь с этого сервера на мой удаленный DC, авторизацию проходит, IP-адрес (как клиент VPN) получает (192.168.1.101). Но вот если я пытаюсь при помощи dcpromo назначить этой машине роль DC, включив его в существующий домен, ничего не выходит - тупо не видит этот сервер существующий домен. Я так подозреваю, что-то напутал с DNS. Вы не могли бы пошагово обрисовать схему такого подключения? DNS в VPN-подключении - это должен быть собственно адрес основного DC, которому в том числе выдана роль DNS-сервера?
А может быть, я забыл пробросить какие-либо порты внутрь нашей локалки на резервный DC?
23 ноября 2011 г. 9:18 -
Вы знаете, не получилось у меня пока что с VPN - связать основной и резервный контроллеры домена - один находится на удаленном сервере, второй (резервный) - в офисе. Как я делал: на удаленном сервере добавил компонент Routing and remote access, настроил учетку Администратора на удаленный доступ. Диапазон адресов, выдаваемых при подключении клиентов по PPTP, назначил от 192.168.1.100 до 192.168.1.103.
В локалке развернул виртуальную машину (резервный DC), дал ей IP из той же подсети, 192.168.1.20, DNS у нее - это DNS нашего шлюза в локалке. Подключаюсь с этого сервера на мой удаленный DC, авторизацию проходит, IP-адрес (как клиент VPN) получает (192.168.1.101). Но вот если я пытаюсь при помощи dcpromo назначить этой машине роль DC, включив его в существующий домен, ничего не выходит - тупо не видит этот сервер существующий домен. Я так подозреваю, что-то напутал с DNS. Вы не могли бы пошагово обрисовать схему такого подключения? DNS в VPN-подключении - это должен быть собственно адрес основного DC, которому в том числе выдана роль DNS-сервера?
А может быть, я забыл пробросить какие-либо порты внутрь нашей локалки на резервный DC?
День добрый.
Откройте тему в другом разделе, пожалуйста.
MCITP. Знание - не уменьшает нашей глупости.24 ноября 2011 г. 10:46Модератор