Некоторые аспекты настройки Office365 для средних и больших предприятий

Office365 вышел на российский рынок. Самое время начать разбираться, что к чему. За общей информацией можно обратиться сюда. Если вы хотите бесплатно протестировать технологию, это возможно сделать, например, здесь, или здесь.

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

Есть две возможные конфигурации использования Office365:

• организация использует только облачные ресурсы Office365;
• организация использует и свои, и облачные ресурсы Office365.

В первом случае, подходящем как правило для предприятий с небольшим количеством сотрудников, пользователи получают полностью облачный функционал Exchange, Lync, SharePoint и Office. Все учётные данные пользователей заводятся и управляются в Облаке через веб-интерфейс, в локальной инфраструктуре надобности нет либо она минимальна (рабочая группа, не домен).

Во втором случае у предприятия уже есть собственная ИТ-инфраструктура, служба каталога Active Directory, бизнес-приложения, её использующие. Как правило, такое бывает как раз у предприятий среднего и большого размеров. Руководство может задуматься о привлечении облачных ресурсов для оптимизации своего ИТ-хозяйства. Какие задачи поможет решить использование Office365?

• снизить совокупную стоимость владения ИТ-инфраструктурой Компании;
• повысить возможности мобильного (в широком смысле) доступа пользователей к основным средствам работы: офисные приложения, почта, служба коммуникаций, корпоративный портал;
• улучшить возможности совместной работы пользователей над документами.

Как правило, руководство ставит следующие условия достижения поставленных задач:

• преобразования должны затронуть пользователей в самой минимальной степени;
• требуется исключить из процесса возможных преобразований несколько отделов, представляющих особую ценность для бизнеса (бухгалтерия, HR).

Таким образом, часть сотрудников предлагается пересадить в Облако (для почты, Lync, MSOffice), а часть из них продолжит работать с локальными (On-Premises) сервисами Exchange/Lync/MSOffice. Ну а корпоративный Портал, нужно думать, может быть перенесён в Облако целиком, или создан там, если ранее его не было.

Такой режим работы сервисов называется сосуществованием. Взаимодействуя друг с другом, среда On-Premises и среда Облака составляют единое целое. В результате, например, в части почты, будет совершенно не важно, где находится почтовый ящик пользователя – в Облаке или On-Premises, письмо всё равно достигнет получателя.

Перевод части пользователей в Облако позволит снизить нагрузку на используемое оборудование, отказаться от покупки нового, сэкономить на энергопотреблении, сопровождении.

Для начала работы с Облаком пользователю домена AD потребуется единоразово установить на ПК обновление (может быть выполнено самостоятельно по инструкции). Никаких новых пользовательских профилей, миграций пользовательских данных, переустановки ОС/приложений. А те, у кого на ПК ещё не установлен Outlook/Office/Lync, смогут получить последние версии дистрибутивов непосредственно из Интернета.

Важно, что все пользователи останутся в локальном домене Active Directory, продолжат работать с другими доменными приложениями как раньше, их рабочие ПК будут так же управляться доменными политиками, а их учётные записи – доменными администраторами.

Технически, всё выглядит следующим образом. При выделении в Облаке соответствующего Tenant-а (арендуемого пространства) там создаётся выделенная ЕСК Active Directory, на базе которой работают облачные сервисы (почта, Lync, SharePoint). Сосуществование обеспечивается синхронизацией учётных данных (пользователи, группы) между локальной ЕСК AD и облачной. Синхронизация выполняется с помощью специально адаптированного под эти цели Microsoft Identity Integration Server (итоговый механизм называется DirSync). Важно понимать, что синхронизация в этой версии Office365 происходит всегда только в одну сторону (в Облако). Это означает, что если нужно обеспечить единообразие списков учётных записей (и почтовых Адресных книг как следствие), нужно производить все изменения в учётных записях только на стороне On-Premises (тогда они будут оттранслированы в Облако). Создать учётную запись пользователя непосредственно в Облаке можно, но она не будет синхронизирована в локальную ЕСК.

Синхронизация учётных данных даёт возможность получить единую почтовую Адресную книгу. Однако на этом всё заканчивается. Ряд важных функций, таких как использование общих для пользователей с ПЯ в Облаке и On-Premises календарей/задач, информация о занятости, MailTips – не будут работать. А пользователи, подключаясь к облачным почтовым ящикам, будут вынуждены каждый раз набирать логин и пароль, хотя они и будут совпадать с их учётными данными локального домена.

Но мы можем подкрутить нашу инфраструктуру, настроив т.н. «федерацию идентификаторов». Тогда для подключения к Облачным сервисам не потребуется повторный ввод реквизитов пользователя, и станет возможным настоящее взаимодействие двух почтовых подсистем – локальной и облачной.

Чтобы это сделать, нужно будет добавить в On-Premises серверы ADFS v2.0. При подключении к Облачному сервису, например, к почтовому ящику, пользователь будет аутентифицироваться с доменными реквизитами, проверяемыми с участием локального сервера ADFS. Это означает (тонкий момент!), что данный сервер (а лучше – серверы) должен быть доступен из Интернета всегда.

Федерация идентификаторов совместно с синхронизацией каталогов обеспечивает единый вход по доменным учётным данным, управление учётными данными может осуществляться исключительно из локальной инфраструктуры, становится возможным настройка федерации Exchange (а значит – Shared Calendars & Tasks, Free/Busy, MailTips, Mail Tracking, Online-Archive, Move Mailboxes).

Таким образом, для средних и крупных предприятий, желающих использовать облачные сервисы наравне с имеющимися уже локальными, потребуется развертывание сервера синхронизации DirSync, и сервера(ов) ADFS 2.0.

Проясним вопрос с именами доменов. Допустим, наш локальный домен Active Directory = contoso.com. При создании Tenant-а в Office365, ему ставится в соответствие доменное имя contoso.onmicrosoft.com. Тогда:

• пользователи домена contoso.com и локальной почтовой системы имеют UPN-суффиксы и скорее всего email-адреса username@contoso.com,
• созданные в облаке пользователи имеют UPN-суффиксы и email-адреса username@contoso.onmicrosoft.com,
• просинхронизированные в облако пользователи будут иметь UPN-суффиксы и email-адреса username@contoso.com.

Следует учитывать, что:

• домен, выбранный для федерации (в нашем примере contoso. com), должен быть зарегистрирован как общедоступный (публичный) домен DNS;
• каждый домен, который требуется объединить в федерацию, нужно зарегистрировать в Облаке как домен с единым входом;
• каждый пользователь должен иметь суффикс UPN;
• суффиксы UPN пользователей должны совпадать с доменами, зарегистрированными в Облаке для единого входа.
• пользователи должны знать, что при входе в Office 365 (через веб) используется суффикс UPN.

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

1. в локальном домене должен быть создан дополнительный UPN cloud.contoso.com,
2. в свойствах пользователей-облачников этот UPN должен быть проставлен как главный,
3. этот домен должен быть прописан на стороне Облака как «домен с единым входом» (как – сейчас разбирать не будем),
4. пользователи должны подключаться к облачным сервисам под логином username@cloud.contoso.com.

На первый взгляд, создание дополнительного поддомена не имеет смысла. Но на настоящий момент это не так, если нужно совместно использовать Lync. Дело в том, что в настоящей версии Office365 Lync Online и локальный Lync должны обязательно использовать разные SIP-домены. Соответственно, чтобы одни пользователи могли работать с локальным Lync, а другие – с облачным, ничего другого не остаётся, как активировать для облачного Lync дополнительный домен. А можно не активировать дополнительный домен, а просто добавить в локальную ЕСК UPN-суффикс contoso.onmicrosoft.com, и использовать его. Просто не всем нравится такое доменное имя, они предпочитают применить своё.

Локальный и облачный Lync-и всё-таки являются совершенно разными организациями, без единой адресной книги. Но общение (федерацию) пользователей локального и облачного Lync настроить будет возможно. Единственное неудобство – добавлять контакты из другой Lync-системы придётся каждому пользователю вручную.

Поэтому в части Lync, видимо, лучше всего будет тем, у кого в локальной инфраструктуре этот сервис ещё не развернут. Тогда они смогут организовать единый сервис Lync, предположим – только в Облаке (не забудем только про лицензии). Или – только on-premises. Пока не существует shared SIP-addresses, совместное использование двух Lync-систем я не могу обосновать.