Exchange 2010 объединяет сайты на разных сайтах с общим внешним пространством имен DNS
Нужны советы по объединению двух существующих сайтов Exchange 2010. Основным драйвером является обмен календарной информацией и общим GAL.
Из-за сложностей с внутренними доменными именами и общим (не существующим) корневым доменом объединение двух сайтов в Exchange выглядит сложным.
Вот информация о потоке почты.User@domain.com пересылается в облачный фильтр содержимого MTA, затем правила MTA пересылают письма на соответствующий сайт Exchange:user@uk.domian.com. Внутреннее полное доменное имя uk.domian.comuser @ us.domain.com Внутреннее полное доменное имя us.domian.internal
Из-за того, что американский сайт является пространством имен.internal, это затрудняет присоединение сайта, я исследовал переименование домена или создание нового домена и миграцию, но это требует большого административного вклада, а на сайте в США мало ИТ-персонала.
В результате кажется, что создание доверия федерации Exchange представляется единственно возможным вариантом (разве есть другие решения?)
Глядя на федеративное доверие, кажется, что необходимо изменить DNS, изменить записи автообнаружения и т. Д.
Поскольку между двумя сайтами существует частный туннель IPSEC, я подумал, можно ли создать правила автоматического обнаружения на внутренних DNS-серверах, а затем использовать VPN-туннель для федерации.
Любые другие жизнеспособные варианты или рекомендации?
Заранее спасибо!
2 ответа
Вы имеете в виду информацию о занятости или фактическом совместном использовании календаря? Ваш лучший путь - использовать федерацию для информации о занятости. Вам понадобится galsync (FIM 2010 R2) для настройки GAL. Или используйте один из сценариев powershell, который создаст для вас контакты без использования FIM.
Я сделал настройку так же, как вы спрашиваете. Он будет обрабатывать списки дистрибутивов и т. Д. Будьте осторожны с тем, чтобы такие же списки были в разных лесах... как служба поддержки, продажи или что-то еще.
В основном это сводится к двум вещам:
- Вы должны (если вы этого еще не сделали) иметь общее пространство имен SMTP для domain.com. Это сделает отправку и получение как domain.com для КАЖДОГО... и упростит используемые пространства имен. Вы можете сделать это через лес.
- Посмотрите в Федерацию Cross-Forest, если это необходимо. По сути, это обеспечит доступность ресурсов между лесами и синхронизацию занятости. Помогает для встреч и т. Д. Мы использовали (и я очень рекомендую) продукт от netsec.de, который называется GAL Sync... http://www.netsec.de/en/produkte/galsync/ Он сделан немецкой компанией, но он имеет полную поддержку английского языка и работает на удивление хорошо. Для этого потребуется настроить его с обеих сторон, но он так хорошо работает с таким количеством настраиваемых параметров. Мы изучили все остальные, такие как IIFP (теперь ILM), Quest Collaboration Services, делали это дома, ручные контакты с обеих сторон и т. Д.
Это не для слабонервных в целом, хотя. Вы должны действительно убедиться, что делаете все правильно, потому что Exchange привередлив. Возьмем, к примеру, один контакт, который у вас уже есть в другом лесу. Теперь удалите его, создайте заново и посмотрите, что происходит, когда кто-то пытается ответить на существующее письмо от исходного "контакта". Он отскочит, потому что ищет тот оригинальный объект Exchange, а не адрес SMTP. Так что будьте осторожны и идите медленно. Даже с учетом описанных выше вариантов мне потребовалось несколько месяцев на планирование и тестирование, чтобы убедиться, что запуск в эксплуатацию пройдет гладко.