Я хочу описать проблемы, с которыми может столкнуться администратор при настройке Exchange для нескольких доменов.
Я не буду вдаваться в подробности решения этих проблем, а опишу в общих чертах, как их следует решать, и приведу ссылки на ресурсы (Microsoft или блоги специалистов Exchange), где подробно описано решение тех или иных трудностей.
Стараюсь охватить как можно больше «тонкостей», но может что-то забыл :) Кому интересно, см.
кат. Внимание: много букв! Прежде всего стоит поговорить о трудностях, с которыми мы столкнемся при реализации Exchange в конфигурации, описанной в теме: • Подготовка и создание объектов.
Один из самых важных моментов.
Вы должны быть уверены, что объекты создаются правильно, в нужном месте и с правильными атрибутами, что поможет вашей среде Exchange функционировать должным образом.
• Обеспечьте безопасность для каждого домена/арендатора.
Сюда входит огромное разнообразие функций и настроек, но, проще говоря, нам нужно сделать так, чтобы пользователи в одной организации не видели пользователей/данные из другой организации.
Об этом нужно думать сразу при создании инфраструктуры AD (например, иерархии OU и прав на них).
• Системные настройки и политики.
Exchange имеет множество функций, доступных пользователям и администраторам, и этими функциями можно управлять различными способами.
Некоторые параметры влияют на отдельного пользователя, некоторые — на базу данных, а некоторые — на всю организацию Exchange. • Транспорт. Следующий пункт настройки, который затронет всех пользователей, — транспорт. Мы говорим о проблемах, когда Exchange пытается маршрутизировать почту между двумя доменами, как если бы они находились в одной организации, и пытается предоставить всю богатую функциональность, которая должна быть предоставлена пользователям одного и того же домена AD. • Проектирование и архитектура системы.
Здесь я пытаюсь поговорить о присвоении имен таким сервисам, как OWA; URL-адреса, предоставляемые клиентам с Outlook; конечные точки для таких служб, как AutoDiscover и Outlook Anywhere. Эти адреса/имена хостов видны всем клиентам и не должны иметь фирменного оформления, чтобы избежать дальнейших проблем.
• Масштабируемость.
Еще одним ключевым атрибутом является масштабируемость.
Речь идет не только о максимальном количестве доменов/пользователей, но и о расчете нагрузки, прогнозировании роста и выявлении слабых мест, чтобы понять, как избежать проблем.
Теперь попробую рассказать о каждом пункте в отдельности: Структура АД.
Здесь следует придерживаться нескольких правил: 1) Каждый домен — это отдельное OU. 2) Все пользователи каждого домена – соотв.
группа для этого домена.
3) Используйте Объектный режим списка Active Directory .
Когда вы включаете режим списка объектов в настройках безопасности (дополнительно), вы можете установить права списка для каждого подразделения.
Вот тут-то нам и понадобится группа из второго пункта — только пользователям этого домена может быть разрешено перечислять подразделения определенного домена.
Это позволит дифференцировать видимость объектов.
Обеспечьте безопасность для каждого домена/арендатора.
Я уже начал обсуждать это в предыдущем абзаце: 1) Использование режима объекта списка AD. 2) Использование модифицированного глобального списка адресов и автономной адресной книги для каждого домена.
Для этого вам потребуется создать политику адресной книги (которая стала доступна только в Exchange 2010 SP2).
В блоге Михаила Токарева этот процесс подробно описан .
3) Порталы администрирования для администраторов каждого домена.
Чтобы конкретный пользователь мог администрировать определенную группу пользователей Exchange (через ECP), Microsoft создала механизм групп ролей.
Написано о том, как создавать группы ролей (где вы будете создавать набор прав для администраторов) здесь .
Однако при создании этих ролей вам потребуется указать Scope — зоны, к которым они применяются.
Я рекомендую использовать OU в качестве «зон» (по одной на каждого клиента).
Вы можете прочитать о создании таких областей управления с помощью PowerShell и командлета New-ManagementScope. здесь .
4) Не рекомендую давать права на просмотр журналов отслеживания сообщений (подтверждений доставки), т. к.
они распространяются на всю организацию и Администраторы смогут видеть всю почту.
5) Изменение прав на календари.
По умолчанию ВСЕ пользователи Exchange будут видеть статус «Свободен/Занят» ВСЕХ других пользователей Exchange. Использование командлета Set-MailboxFolderPermission или утилиты, такие как Бывшие папки , заберите доступ у пользователя «По умолчанию», но предоставьте необходимые разрешения пользователям этого домена.
6) Необязательный: Биллинг для клиентов.
К сожалению, в Exchange нет встроенных механизмов биллинга, но вы можете создать свой собственный даже с помощью Excel. Для получения статистики по почтовым ящикам рекомендую ознакомиться с командлетами Get-MailboxStatistics И Get-ActivesyncDeviceStatistics , с помощью которого (вы можете фильтровать статистику по клиентам/доменам с помощью PowerShell) можно получить статистику и загрузить ее в CSV/XLS. 7) Я не рекомендую включать правила защиты Outlook, потому что.
Когда включено расширенное ведение журнала Outlook, данные о доменах SMTP всех клиентов будут доступны.
8) Обмен базами данных.
Многие из тех, кто имеет опыт работы с Exchange, скажут, что каждому клиенту «удобнее» создать свою базу данных и хранить все почтовые ящики одного домена в отдельной базе данных.
Но если у вас нет веской причины для этого, не разделяйте клиентов по базам данных.
Ведь при проблемах с 1 базой вся почта домена будет недоступна, а это недопустимо.
Создайте несколько баз данных и используйте автоматическое распределение почтовых ящиков и позвольте Exchange выбирать, в какую базу данных «помещать» почтовые ящики.
Вы можете прочитать о том, как работает автоматическое распространение почтовых ящиков.
Здесь .
Системные настройки и политики.
Этот пункт во многом пересекается с предыдущим, поэтому я не буду здесь много говорить.
1) Нет необходимости предоставлять клиентам прямой доступ (LDAP+MAPI).
Это плохая идея.
Многие хостеры так делают (например, Мастерхост), но я не могу согласиться с правильностью такого решения.
ТОЛЬКО RPC по HTTPs (тем более в следующей версии Exchange есть только такой доступ).
Этот тип доступа немного сложнее при первоначальной настройке, но гарантированно избавит вас от проблем в будущем.
2) Следите за своим брандмауэром.
Для DDoS-атак, для возможных брутфорс-атак.
Не оставляйте сетевую безопасность на потом.
3) Рекомендую отключить политику «автоблокировки» учетных записей в случае неправильного ввода пароля (иначе злоумышленнику будет очень легко заблокировать учетную запись), но обязательно используйте политики, требующие от пользователей предоставления сложных паролей.
Транспорт. 1) Требуется запретить отправку в группы рассылки с других доменов.
Для этого вам необходимо ограничить число отправителей, которым разрешено отправлять сообщения в DG, и потребовать аутентификацию для отправки в DG. Это можно настроить с помощью EMC или командлета.
2) Ограничение размера букв.
Например, ограничение размера входящей электронной почты на пограничном сервере должно быть меньше или равно ограничению, установленному для внутренней почты.
Обратное было бы просто пустой тратой ресурсов Edge-сервера.
Помните, что с помощью пользовательских ограничений вы можете разрешить пользователю или группе пользователей превышать ограничения, установленные для всей организации Exchange. 3) Настройка маршрутизации почты для «соседних» доменов через внешний ретранслятор.
Это необходимо, если вы хотите полностью «замаскировать» почту с доменов на данном Exchange, если она отправляется на «соседний» домен.
Конечно, некоторая информация останется в заголовках, но вы обеспечите вид, будто почта получена из Интернета, что в свою очередь не позволит определить отправителя как внутреннего.
4) Помните, что если вы хотите использовать Mutual TLS (о том, что это такое, вы можете прочитать здесь ), параметры TLSRecieveDomainSecureList и TLSSendDomainSecureList настраиваются для всей организации Exchange. И если вы собираетесь предложить эту функцию клиентам, вам необходимо убедиться, что они понимают, почему в некоторых получаемых ими электронных письмах появляется флаг «Безопасно».
5) Рекомендуется включить на Хаб-серверах Антиспам-агенты, чтобы проверялась почта между доменами.
Как это сделать - написано здесь .
6) Требуется отключить внутренние сообщения об отсутствии на работе между доменами.
Ведь если пользователь выберет «отправлять OOF только внутри моей организации», то письмо OOF может прийти пользователю этой биржи, но из другого домена.
Чтобы этого не произошло, необходимо создать несколько правил транспорта, которые будут разрешать сообщения класса IPM.Note.Rules.Oof.Template.Microsoft (это класс, который имеют OOF-письма) только между идентичными доменами (в соответствии с правилами для каждого домена).
правило).
7) Отключите некоторые «подсказки» при отправке писем.
При многодоменной структуре вам придется пожертвовать некоторыми функциями, такими как отображение участников группы и предупреждения о том, что у получателя включен автоответ OOF и т. д. Изменить эти настройки можно через командлет Set-OrganizationConfig .
Дизайн и архитектура.
1) Используйте общие URL-адреса.
Например, зарегистрировать домен exchsuperhost.ru .
Создание узлов m.exchsuperhost.ru И m2.exchsuperhost.ru (для отказоустойчивого EDGE — это будут MX с разными приоритетами), mail.exchsuperhost.ru (для клиентского доступа и OutlookAnywhere) и autodiscover.exchsuperhost.ru для автообнаружения.
Позвольте вашим клиентам использовать CNAME для веб-интерфейсов и ваши адреса MX для записей MX и SPF. Это значительно упростит администрирование и отслеживание почты.
2) Я рекомендую не предоставлять пользователям доступ через POP и IMAP, потому что.
это может создать проблемы во время миграции, а также для удобства пользователей.
3) Подумайте о виртуализации.
У Microsoft нет проблем с виртуализацией некоторых ролей Exchange. Это поможет снизить затраты на оборудование и лицензии.
Масштабируемость.
Все зависит от ваших клиентов, оборудования и т. д. Единственное, что могу посоветовать: не используйте «устаревшие» технологии (типа Public Folders), рассчитывайте «аппаратную» емкость и место на хранилищах и дисковых полках, старайтесь использовать динамические группы рассылки.
и максимально автоматизируйте свою работу — сценарии PowerShell, правила транспорта, глобальный список адресов, политики именования и хранения.
Буду рад ответить на ваши вопросы и выслушать ваши советы :) Спасибо! Теги: #microsoft #it инфраструктура #Системное администрирование #microsoft Exchange #системное администрирование Windows #администрирование Exchange #exchange 2010 #хостинг Exchange #многодоменная организация #microsoft Exchange Server 2010
-
Краткий Обзор Услуг Интернет-Факса
19 Oct, 24 -
Я Хочу Подарок От Google
19 Oct, 24 -
Индуктивное Смещение И Нейронные Сети
19 Oct, 24 -
Playstation Приглашает Вас В Игромир
19 Oct, 24
