Содержание
- Tutorial
Я хочу описать сложности, с которыми администратор может столкнуться при настройке Exchange для нескольких доменов. Я не буду вдаваться в подробности решения данных проблем, однако опишу в общих словах как их следует решать и предоставлю ссылки на ресурсы (Microsoft или блоги специалистов по Exchange) где описано подробно решение тех или иных сложностей. Я стараюсь обхватить как можно больше «тонкостей», однако что-то мог и забыть 🙂 Кому интересно – под кат. Внимание: очень много букв! Прежде всего, стоит сказать о сложностях, которые мы встретим при внедрении Exchange в описанной в теме конфигурации: • Подготовка и создание объектов. Один из важнейших пунктов. Нужно быть уверенным, что объекты создаются правильно, в нужном месте и с правильными атрибутами, что в дальнейшем поможет Exchange-среде правильно функционировать. • Обеспечение безопасности для каждого домена/клиента. Сюда входит огромное множество функций и настроек, но если говорить просто – мы должны убедиться, что пользователи одной организации не будут видеть пользователей/данные из другой организации. Об этом надо думать сразу, при создании AD-инфраструктуры (к примеру, иерархия OU и права на них). • Системные параметры и политики. У Exchange есть много функций, доступных пользователям и администраторам, и эти функции могут управляться разными способами. Некоторые настройки влияют на отдельного пользователя, некоторые на БД, а некоторые на всю Exchange-организацию. • Транспорт. Очередным пунктом в настройке, который затронет всех пользователей – это транспорт. Речь идет о проблемах, когда Exchange пытается маршрутизировать почту между двумя доменами в режиме, будто они находятся в пределах одной организации, и пытается предоставить весь богатый функционал, который следует предоставлять пользователям одного AD-домена. • Дизайн и архитектура системы. Тут я пытаюсь сказать о именах для таких служб как OWA; URL, которые предоставляются клиентам с Outlook; конечных точках для таких сервисов как AutoDiscover и Outlook Anywhere. Эти адреса/hostname видны для всех клиентов и должны быть не привязаны ни к одному из них (non-branded) для избежания дальнейших проблем. • Масштабируемость. Еще одним ключевым атрибутом является масштабируемость. Речь идет не только о максимальном количестве доменов/пользователей, но и о расчете нагрузки, предсказании роста и определении слабых мест, чтобы понять как избегать проблем. Теперь я постараюсь сказать о каждом пункте в частности:Структура AD. Тут стоит придерживаться нескольких правил: 1) Каждый домен – отдельный OU. 2) Все пользователи каждого домена – в соотв. группе для этого домена. 3) Использование Active Directory List Object Mode. При включении List Object Mode в настройках Security (Advanced) для каждой OU можно будет выставлять права на List. Вот тут-то нам и потребуется группа из второго пункта – разрешить List OU определенного домена можно только пользователям этого домена. Это позволит разграничивать видимость объектов.Обеспечение безопасности для каждого домена/клиента. Я уже начал обсуждать это в предыдущем пункте: 1) Использование AD List Object Mode. 2) Использование модифицированных Global Address List и Offline Address Book для каждого домена. Для этого потребуется создавать Address Book Policy (которые стали доступны только в Exchange 2010 SP2). В блоге Михаила Токарева подробно описан этот процесс. 3) Порталы администрирования для администраторов в каждом домене. Для того, чтобы определённый пользователь мог сам администрировать определенную группу пользователей Exchange (через ECP), в Microsoft был создан механизм Role Groups. О том, как создавать группы ролей (где Вы и создадите набор прав для администраторов) написано тут. Однако при создании эти ролей Вам нужно будет указывать Scope – зоны, на которые они распространяются. В качестве «зон» рекомендую использовать OU (для каждого клиента – свою). О создании таких Management Scopes с помощью PowerShell и командлета New-ManagementScope Вы можете прочитать тут. 4) Я не рекомендую давать права на просмотр Message Tracking Logs (подтверждения о доставке), т.к. они распространяются на всю организацию и Администраторам будет видна вся почта. 5) Изменение прав на календари. По-умолчанию ВСЕ пользователи Exchange будут видеть Free/Busy статус ВСЕХ остальных пользователей Exchange. С помощью командлета Set-MailboxFolderPermission или утилит, таких как ExFolders, отобрать у «Default» пользователя доступ, но предоставить необходимые разрешения пользователям данного домена. 6) Опционально: Биллинг для клиентов. К сожалению, в Exchange не встроено механизмов биллинга, однако Вы можете создавать свои даже на базе Excel. Для получения статистики по ящикам рекомендую ознакомиться с командлетами Get-MailboxStatistics и Get-ActivesyncDeviceStatistics, используя которые (Вы можете фильтровать статистику по клиентам/доменам с использованием PowerShell) можно получить статистику и выгрузить ее в CSV/XLS. 7) Я не рекомендую включать Outlook Protection Rules, т.к. при включенном Outlook Advanced Logging будет доступны данные об SMTP-доменах всех клиентов. 8) Базы Exchange. Многие из тех, кто имеет опыт работы с Exchange скажет, что «удобнее» для каждого клиента создать свою базу и хранить все ящики одного домена в отдельной базе. Но, если у Вас нет веского основания так делать, не разделяйте клиентов по базам. Ведь в случае проблем с 1 базой – вся почта домена будет недоступна, а это неприемлемо. Создайте несколько баз и используйте Automatic Mailbox Distribution и дайте Exchange самому выбирать в какую базу «класть» ящики. О том, как работает Automatic Mailbox Distribution вы можете прочитать здесь.Системные параметры и политики. Этот пункт очень сильно «пересекается» с предыдущим, поэтому тут я скажу не много. 1) Не надо предоставлять клиентам прямой доступ (LDAP + MAPI). Это плохая идея. Многие хостеры так и делают (к примеру, Masterhost), но я не могу согласиться с правильностью такого решения. ТОЛЬКО RPC over HTTPs (тем более в следующей версии Exchange есть только такой доступ). Такой тип доступа чуть сложнее в начальной настройке но гарантированно избавит Вас от проблем в будущем. 2) Следите за Вашим файрволом. За DDoS-атаками, за возможными bruteforce атаками. Не оставляйте сетевую безопасность «на потом». 3) Я рекомендую отключать политику «авто-блокирования» аккаунтов в случае неверного ввода паролей (иначе злоумышленнику будет очень просто заблокировать аккаунт), но обязательно используйте политики, требующие от пользователей сложные пароли.Транспорт. 1) Требуется запретить отправку на Distribution-группы из других доменов. Для этого нужно ограничивать отправителей, которые имеют право отправлять на DG и требовать аутентификацию для отправки на DG. Это можно настроить через EMC или командлет Set-DistributionGroup. 2) Ограничение размера писем. К примеру, ограничение размера входящих писем на Edge-сервере должно быть меньше или равно ограничению, установленному для внутренней почты. Обратное будет просто тратой ресурсов Edge-сервера. Помните, что с помощью пользовательских лимитов Вы можете дать пользователю или группе пользователей превышать лимиты, установленные для всей организации Exchange. 3) Настройка маршрутизации почты для «соседних» доменов через внешний relay. Это требуется если Вы хотите полностью «замаскировать» почту от доменов на данном Exchange, если они отправляются домену-«соседу». Конечно, в header’ах останется некоторая информация, однако Вы обеспечите симуляцию того, что почта получена из Интернета, что, в свою очередь, предотвратит resolve этого отправителя во внутреннего. 4) Помните, что если Вы захотите использовать Mutual TLS (о том, что это такое, можно прочитать тут), настройки TLSRecieveDomainSecureList и TLSSendDomainSecureList настраиваются для всей организации Exchange. И если Вы собираетесь предложить данную функцию клиентам, нужно будет убедиться, что они понимают, почему флаг «Безопасно» будет отображаться на некоторых письмах, которые они будут получать. 5) Рекомендуется включить Анти-спам агентов на Hub-серверах, чтобы проверялась почта между доменами. Как это сделать – написано тут. 6) Требуется отключить внутренние сообщения Out Of Office между доменами. Ведь если пользователь выберет «отправлять OOF только внутри моей организации» письмо OOF может уйти пользователю данного Exchange, но из другого домена. Чтобы предотвратить это требуется создать несколько правил транспорта, которые будут разрешать сообщения класса 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 для Autodiscover. Пускай Ваши клиенты используют CNAME для веб-интерфейсов и Ваши MX-адреса для MX и SPF записей. Это очень сильно упростит администрирование и отслеживание почты. 2) Рекомендую не предоставлять пользователям доступ по POP и IMAP, т.к. это может создать проблемы при миграциях, а также при работе пользователей. 3) Задумайтесь о виртуализации. Microsoft не имеет ничего против виртуализации некоторых ролей Exchange. Это поможет сократить расходы на оборудование и лицензии.Масштабируемость. Тут все зависит от Ваших клиентов, оборудования и т.д. Все, что я могу посоветовать: не используйте «устаревшие» технологии (такие как Public Folders), рассчитывайте «железные» мощности и место на хранилищах и дисковых полках, старайтесь использовать динамические группы рассылки и максимально автоматизируйте свою работу – PowerShell скрипты, правила транспорта, GAL, политики именования и хранения. Буду рад ответить на Ваши вопросы и выслушать Ваши советы 🙂 Спасибо!
Exchange Server 2010 — программный продукт от корпорации Microsoft для обмена почтовыми, голосовыми, мгновенными сообщениями и поддержкой организации совместной работы (доступ к задачам, календарям, веб-доступ и поддержка мобильных устройств).
Содержание:
Данный продукт довольно тесно связан с Active Directory (AD), в которой хранится большая часть данных пользователей (связи доменных и почтовых аккаунтов пользователей, списки контактов), хотя почтовые ящики, ввиду своего размера, хранятся отдельно.
Когда нужна корпоративная почта?
Преимущества, которые получает компания от внедрения собственного сервера корпоративной почты:
1. Статус. Наличие собственного домена в почтовых сообщениях сотрудников компании, делает компанию более презентабельной для бизнес-партнеров, нежели при использовании услуг бесплатных почтовых сервисов.
2. Возможность создания правил пересылки почты.
3. Централизованное хранилище корпоративной переписки компании.
4. Наличие корпоративной адресной книги.
Необходимость внедрения в качестве корпоративного сервера почты Exchange Server 2010 (далее ES 2010) может возникнуть, если организации необходимо нечто больше чем прием-отправка электронной почты.
Руководители предприятия хотят назначать подчиненным задания и контролировать их выполнение.
В свою очередь, рядовые пользователи хотят эффективно планировать встречи и собрания, имея доступ к почте в любое время без привязки к рабочему месту.
Исходя из этих требований, повышается ожидаемый уровень информационной безопасности.
Т.к. руководители хотят быть уверенными в конфиденциальности переписки, а рядовые пользователи хотят получать как можно меньше вирусов и спама.
Преимущества и недостатки внедрения Exchange Server 2010
Преимущества внедрения ES 2010:
1. Наличие широких функциональных возможностей.
2. Интеграция с доменной структурой Windows.
3. Относительно простое администрирование.
К недостаткам ES 2010, следует отнести:
1. Высокую стоимость внедрения.
2. Высокие требования к производительности оборудования.
3. Необходимость отдельного приобретения антивирусного и антиспамового модулей.
4. Необходимость в создании доменной инфраструктуры.
Установка Exchange Server 2010
Коротко опишем процедуру установки ES 2010. Отметим, что для настройки будет использоваться оригинальная, англоязычная версия почтового сервера.
Совет!Для установки нам потребуется 2 сервера с установленной MS Windows Server 2008R2, при этом на одном из них должна быть поднята и настроена роль службы каталогов AD, с него и начнем.
Шаг 1. Настройка контролера домена
С целью повышения надежности системы, рекомендовано наличие в сети двух, аппаратно-независимых контролеров домена.
Дальнейшая настройка будет выполняться на контролере с ролью «Shema Master».
Загружаем на контролер домена самораспаковующийся архив ES 2010, запускаем приложение и указываем место для распаковки файла.
Для удобства архив можно распаковать в корень диска С.
Далее подготавливаем схему Active Directory. Запускаем командную строку от администратора StartAll ProgramsCommand Promt ПКМ «Run as administrator».
Переходим в распакованный ранее каталог, с помощью команды — «cd c:exchange» и выполняем подготовку схемы AD, набрав команду — «Setup.com /PrepareSchema» (все команды вводим без кавычек).
После завершения подготовки схемы AD, создадим организацию в Exchange с помощью команды «Setup.com /PrepareAd /OrganizationName: «COMP»».
Имя организации «OrganizationName» нужно указывать латиницей, записав в этот пункт имя организации, для которой выполняется настройка, в качестве примера, назовем нашу организацию СОМР.
После успешного выполнения данной команды, подготовку AD и создание организации Exchange завершена.
Переходим ко второму серверу, на котором планируется развернуть почтовый сервер.
Шаг 2. Настройка почтового сервера
Копируем и распаковываем заранее скачанный дистрибутив аналогично предыдущему пункту и переходим к установке необходимых компонентов, набор которых зависит от версии операционной системы и ролей, которые планируется использовать на сервере.
Запускаем Windows PowerShell от администратора, и прописываем «Import-Module ServerManager».
В нашем случае, установка Exchange 2010 производится на ОС Windows Server 2008R2, поэтому набор устанавливаемых компонент будет следующим:
«Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Windows-Auth, Web-Basic-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,RSAT-Web-Server,WAS-Process-Model,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Logging,Web-Http-Errors,Web-Http-Tracing,Web-Http-Redirect,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy-Restart».
Выполнив установку всех компонентов, сервер перезагрузится в автоматическом режиме.
Далее, необходимо установить пакет фильтров для включения поиска по содержимому в файлах определенных типов — MSOffice 2010 Filter Pack.
Копируем приложение FilterPack64bit.exe на будущий почтовый сервер и запускаем его. После запуска мы будем иметь дело с Мастером установки MSOffice 2010 Filter Pack. Переходим далее:
Соглашаемся с требованиями лицензии и также жмем «Next»:
После подготовительной установки всех необходимых компонент, переходим к непосредственной установке почтового сервера ES 2010.
Перемещаемся в папку с распакованным дистрибутивом и запускаем файл установки «setup.exe». Выбираем 4-й пункт в меню «Install»:
Ознакамливаемся с информацией об ES 2010, жмем «Next»:
Читаем условия лицензии, соглашаемся, переходим к следующему шагу.
На следующем шаге нам предлагают оповещать компанию Microsoft об ошибках, происходящих с почтовым сервером, отказываемся (выбираем «No»).
Выбираем роли, которые будут установлены на сервер. В нашем случае это стандартный набор ролей, отмечаем «Typical Exchange Server Installation».
После этого, мастер установки интересуется есть ли в нашей сети ПК, на которых установлен почтовый клиент «Outlook 2003».
Даже если таковых нет, рекомендуем выбирать положительный ответ («Yes»), т.к. в противном случае нельзя использовать функцию общих папок «Public Folders».
Указываем доменное имя сервера почты для доступа из пользователей из Интернет.
Далее, нас спросят, хотим ли мы поучаствовать в программе улучшения качества, вежливо отказавшись, переходим к следующему пункту.
Все предварительные настройки выполнены, выполняется проверка готовности к установке.
После проверки переходим к установке, нажав кнопку «Install».
После установки, кнопка «Install» сменится на кнопку «Finish» и появится окошко с уведомлением о перезагрузке системы для вступления в силу установленных компонент и настроек.
После перезагрузки системы для управления почтовым сервером можно использовать «Exchange Management Console».
Проверку состояния служб почтового сервера, можно выполнить командой «Test-ServiceHealth».
Надпись «True» в поле «RequireServiceRunning» свидетельствует о запущенной службе.
На этом установка почтового сервера завершена.
Вчера поздно ночью закончился вебкаст у Павла Нагаева. Народу было дикое количество. Все жаждали увидеть новый продукт. Паша, как MVP Exchange имел доступ к ранним версиям, и уже имел установленный экземпляр в виртуальной среде. Его доклад, да и доклад ли это, получился сумбурным, но ОЧЕНЬ интересным. Фактически мы разглядывали интерфейс, пробовали всяческие новые фичи, многие из которых отказывались работать. Но впечатления это не испортило. Восторженные отзывы звучали, как в прямом эфире, так и в чате нашей группы Exchange Server – Russia.
Я до сих пор нахожусь в состоянии подозрительного возбуждения, меня поразил сам факт. Нежданно, негаданно выход бета-версии взорвал мне мозг. Видимо я на самом деле очень сильно его ждал. О том, что через 20 минут после получения мной этого известия инсталлятор покоился на моем жестком диске, говорить, думаю излишне. Во время скачивания судорожно разворачивалось виртуальное окружение, а я пытаясь отвечать на какие-то запросы в почту, мессенджер, попытки жены заставить выполнять какую-то работу по дому, дерганья сыном моей штанины, вперил свой взор в соответствующий раздел библиотеки TechNet, с гордым идентификатором версии (EXCH.140). Это наверное не совсем правильно, но – плевать. Я его ждал. Я это заслужил 🙂
Во время вебкаста, участник чата Александр Одарчук на мою фразу о том, что я чужих статей ждать не буду, буду писать свои, спросил, а когда же, мол, первая? Я пошутил: “Завтра :)”. А он на полном серьезе ответил: “Ок!” За слова надо отвечать, Саша, заценивай! 😉
UPDATE: См. также установку в автоматическом режиме
UPDATE: Скринкаст от Дениса Урасова. Показан интерфейс и возможности OWA.
Итак, установочный пакет весит ни много, ни мало 302 Мб, что подозрительно, на фоне объемов старшего брата Exchange 2007. Скачиваем, укладываем до лучших времен. Готовим окружение.
Exchange 2010 требует:
1. Поддерживаемые операционные системы :
Для установки серверных компонентов:
Windows Server 2008 x64 Standard или Enterprise edition
Windows Server 2008 R2 x64 Standard или Enterprise edition.
Для установки консоли управления:
для версии x64 – Windows Vista x64 SP1
Для версии x32 – любая редакция Windows Vista (кроме Starter)
2. Минимальные системные требования:
Процессор – Intel x64 с поддержкой архитектуры EM64T; AMD64; Intel 800 Mhz для тестирования при наличии дистрибутива x32. IA64 Itanium традиционно не поддерживаются.
Память – объем зависит от количества установленных ролей, но существуют рекомендации по минимальным, максимальным и рекомендуемым объемам. В виде таблице, доступной по ссылке.
Дисковое пространство – для того, чтобы все завелось и Вы хотя бы увидели консоль, Вам потребуется минимум 1.2 Гб свободного дискового пространства, плюс 500 Мб для роли Unified Messaging, 200 Мб на системном томе, 500 Мб для базы очереди Hub Transport. Разделы отформатированы в NTFS.
Больше ничего сверхъестественного 🙂
3. Требования к службе каталогов Active Directory:
Schema Master – Windows Server 2003 SP2 Standard или Enterprise Edition
Global Catalog – Windows Server 2003 SP2 Standard или Enterprise edition
В документации так и написано: “The latest 32-bit edition of the Windows Server 2003 Standard or Enterprise”, но в другом месте встретилось, что достаточно минимум одного контроллера на базе Windows Server 2003 SP1. Т.е. pre-latest 🙂 Ну документация тоже в бета-версии, оно и понятно.
Требования к компонентам операционной системы:
1. Microsoft .NET Framework 3.5 – около 300 Мб, но при установке все равно потребует подключения к Интернет. Можно смело проигнорировать, потыкается в попытках соединения и все равно установится.
2. Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3) – 3.5 Мб – версия не ниже 6.0.6001.18172 (посмотрите вкладку Details в свойствах файла WsmSvc.dll, расположенного по адресу %systemroot%system32)
3. Windows PowerShell V2 CTP3 – 9.8 Мб– версия не ниже 6.1.6949.0 (посмотрите вкладку Details файла PowerShell.exe, расположенного по адресу C:WindowsSystem32WindowsPowerShellv1.0)
4. Обновление, описанное в статье базы знаний KB950888, позволяющее установить несколько соединений RMS Client в контексте одного пользователя. Думаю это пригодится при интеграции транспортных правил и системы объединеных сообщений с сервисом AD RMS. но без него ставиться отказывается 🙁
5. 2007 Office System Converter: Microsoft Filter Pack – устанавливает набор фильтров для службы индексирования, позволяющих службе поиска оптимизировать индексацию содержимого офисных файлов (.docx, .docm, .pptx, .pptm, .xlsx, .xlsm, .xlsb, .zip, .one, .vdx, .vsd, .vss, .vst, .vdx, .vsx, and .vtx)
7. ASP.NET AJAX 1.0 – расширенный набор скриптов для ASP.NET
6. Установите Active Directory management tools из оснастки управления сервером, либо выполнив команду ServerManagerCmd -i RSAT-ADDS. Это необходимо для операции по подготовке схемы леса и домена к установке Exchange Server 2010.
7. Установите роль Веб-сервера IIS, отметив следующие компоненты и службы роли:
IIS 6 Metabase Compatibility
Web Server (IIS) Tools
Windows Process Activation Service Process Model
IIS 7 Basic Authentication
IIS 7 Windows Authentication
IIS 7 Digest Authentication
IIS 7 .NET Extensibility
IIS 6 Management Console
HTTP Activation (ставится в Features.Net Framework 3.0 ComponentsWCF Activation )
IIS 7 Dynamic Content Compression
IIS 7 Static Content Compression
8. При установке роли Unified Messaging установите компонент Desktop Expirience из оснастки Server Manager, либо выполнив команду ServerManagerCmd -i Desktop-Experience. Это необходимо для установки кодеков медиаплейера.
Итак, все подготовлено, начинаем собственно установку 🙂
Скопировав установочный пакет, кликните на нем два раза, и он предложит извлечь файлы в тот же каталог, в котором находится. Выбираем нужный каталог, жмем ОК.
После извлечения, переходим в каталог, в который извлеклись установочные файлы и запускаем setup.exe… Go!
Первое, что мы видим – новый экран приветствия.
В нем появилось, на мой взгляд, одно отличие – описание процесса установки языковых пакетов. В остальном тот же старый, добрый Welcome Screen, даже ссылки на рекламу те же 🙂 Жмем Install Microsoft Exchange, и после занимающего некоторое время процесса копирования небходимых файлов во временный каталог, попадаем на экран Introduction. Ничего там особого нет, так, привет, мол, хорошо, что Вы выбрали наш продукт, бла-бла-бла. Жмем Next.
И вот уже еще одно нововведение. Экран Language File Location.
Как известно, в новой версии Exchange Server была заявлена поддержка нескольких основных языков, в том числе и русского. Причем поддержка полная, вплоть до голоса в Unified Messaging. Так вот, на этом экране Вам предлагается подключиться к Интернет для скачивания последних версий языковых пакетов либо указать местонахождение уже имеющегося файла языкового пакета. Если не выбрать ни одну из этих возможностей, продукт будет установлен с дефолтным пакетом английского языка. Я выбрал последний вариант, т.к. ставлю для тестовых целей, а на английском оно сподручнее 🙂 Да и Бог его знает, какой в бете перевод 🙂 Следующий экран меня предупредил, мол Вы точно выбрали тот пакет? А то смотрите, весь интерфейс и последующие экраны Мастера установки будут отображаться на английском! Да знаем, знаем – ответил я. Но задумался над содержанием предупреждения. Ведь можно исходя из этого предположить, что после выбора языкового пакета отличного от дефолтного, по идее должен смениться язык установщика! Интересная возможность, проверим позже.
Далее появился экран End-User License Agreement. Не знаю, как Вы, а я текст EULA читаю всегда. Ну если не ставлю продукт по сто раз в день, конечно. И, как оказалось, не зря. В тексте EULA обнаружил пару интересных моментов. Ну например, Вы не имеете права использовать данную версию в Production Environment. Только в условиях теста. Данная лицензия действует до 30 ноября 2009 года, либо заканчивается с выходом RTM версии. Что произойдет раньше, интересно? Вам вместе с данным продуктом предоставляются некоторые веб-сервисы, которые Вы, если хотите можете конечно отключить. Антимонопольно, однако 🙂 Ну и далее в том же духе. Accept, Next.
Отчеты в Microsoft отправлять нужно. Это помогает улучшить продукт, выявить кучу багов и т.п. Что я и выбрал на следующем экране. Next.
До боли знакомо, не правда ли? Я выбрал Typical, ибо больно уж хотелось побыстрее его потрогать руками, да и ресурсы моей домашней лаборатории особо разгуляться не дадут. Каталог установки тоже оставил по дефолту.
Следующий экран предложил выбрать название Exchange организации. Поломав голову, выпив три чашки кофе и выкурив полпачки сигарет, я нашел, на мой взгляд, гениальное название: “First Organization” 🙂 Next.
Имеются ли у меня в сети компьютеры с установленным MS Outlook 2003, Да Вы что? Нет конечно! Next!
Опять новость! Экран Программы по улучшению качества продуктов. Такой прикольный 🙂
Здесь Вы можете не только к ней присоединиться, но и выбрать наиболее полно харатеризуюущую деятельность Вашей компании категорию. Соц. опрос одним словом 🙂 Я изучаю продукт, значит Education 🙂 Next.
И вот экран оценки готовности. Помимо стандартных проверок организации и ролей, добавилась проверка языкового пакета. Если следовать всему описанному выше, итог должен выглядеть вот так:
Ну вот собственно. мы и готовы к установке. Install!
Отступление: Погорячился я при создании виртуальной машины. При наличии 1Гб памяти любовался на прогресс-бары около 2 часов. но в результате получил прелестный экран, говорящий об окончании установки.
Можно посмотреть подробный лог установки, который в принципе пишется все туда же C:ExchangeSetupLogs.
Жмем финиш, и при наличии уставновленной галки Finalixe installation using the EMC, открывается прелестная, до боли знакомая, родная, но все же неуловимо изменившаяся консоль управления Exchange Management Console.
Но о ней поговорим в другой раз. Что еще можно поделать? Можно попробовать проверить наличие последних обновлений. Это можно сделать из остававшегося все это время открытым Welcome Screen’a. Но, а) У моего сервера нет доступа в Интернет
б) Сомневаюсь я в наличии таковых на данный момент.
Вот собственно и завершена установка в типовой конфигурации Все-Роли-На-Одном-Сервере. В последующем посте опишу другие виды установок, в частности установку с разнесением ролей, автоматическую установку с использованием файла ответов, установку из командной строки, ну и установку консоли управления на различные редакции Windows.
P.S. В течение всего времени установки в панели задач висели два свернутых окна Вроде-бы-Как-Копирования
Зачем, непонятно, но после окончания установки, перед разворачиванием консоли управления они ожили, и сообщили, что временные файлы, скопированные в каталог %systemroot%temp удаляются. Р-р-р-аз! И удалились. Наверное новая архитектура дает о себе знать.
P.P.S. А закрыть их во время установки не получалось, и убивать их Task Manager’ом я постеснялся 🙂
P.P.P.S. А через 2,5 часа у меня экзамен в автошколе. Билеты, которые я должен был изучить, так и остались лежать на полке. Так что, если Вам понравился мой пост, подержите за меня кулачки, авось сдам 😉
Technorati Теги: Установка Exchange 2010Используемые источники:
- https://habr.com/post/155751/
- http://geek-nose.com/ustanovka-exchange-2010-kak-zapoluchit-sobstvennyj-domen/
- https://okrylov.wordpress.com/2009/04/16/exchange2010-install/