Поиск на сайте: Расширенный поиск


Новые программы oszone.net Читать ленту новостей RSS
CheckBootSpeed - это диагностический пакет на основе скриптов PowerShell, создающий отчет о скорости загрузки Windows 7 ...
Вы когда-нибудь хотели создать установочный диск Windows, который бы автоматически установил систему, не задавая вопросо...
Если после установки Windows XP у вас перестала загружаться Windows Vista или Windows 7, вам необходимо восстановить заг...
Программа подготовки документов и ведения учетных и отчетных данных по командировкам. Используются формы, утвержденные п...
Red Button – это мощная утилита для оптимизации и очистки всех актуальных клиентских версий операционной системы Windows...
OSzone.net Microsoft ИТ-инфраструктура Облако Microsoft Office 365: Гладкий переход в облако RSS

Microsoft Office 365: Гладкий переход в облако

Текущий рейтинг: 3.8 (проголосовало 5)
 Посетителей: 2747 | Просмотров: 3433 (сегодня 0)  Шрифт: - +

К перемещению в облако нельзя подходить легкомысленно. Практически ни у кого нет сомнений, что переход на Microsoft Office 365 позволит компании сэкономить существенные деньги, но планирование и процессы миграции с существующей инфраструктуры в облачную среду — очень серьезное мероприятие.

Microsoft настоятельно советует организациям всех размеров начинать миграцию в облако, когда выйдет Microsoft Office 365, и прилагает все усилия, чтобы этот процесс прошел максимально гладко. Microsoft Office 365 состоит из облачных версий Microsoft Exchange Server 2010, SharePoint 2010 и Microsoft Lync Server. Некоторые варианты подписки на Office 365 также включают доступ к Microsoft Office Professional Plus, а также Microsoft Office Web Apps.

Наличие такого большого числа продуктов в пакете Microsoft Office 365 затрудняет общее планирование миграции. Но мы посмотрим, как в среде Microsoft Office 365 выполняются некоторые стандартные задачи, и подумаем, с какими проблемами мы можем столкнуться в процессе миграции.

Доменные имена

Один из серьезных вопросов — как переход на Microsoft Office 365 затронет доменные имена в организации. Exchange, SharePoint и Lync сильно завязаны на взаимодействие с Active Directory. Решение проблемы доменных имен зависит от того, что планируется использовать:локальную службу каталогов Active Directory или службу федерации.

Если вы планируете сохранить Active Directory, но не хотите связываться с федерацией, можете настроить Microsoft Office 365 на обработку доменных имен посредством процесса, который называется частичным переделегированием. Доменные имена останутся за компанией, но некоторые функции, такие как электронная почта и веб-хостинг придется перепоручить серверам Microsoft Office 365.

Microsoft максимально упростила процесс переделегирования домена для работы Microsoft Office 365 — это делается в консоли администрирования Microsoft Office 365 (см. рис. 1).

*

Рис. 1. Существующие доменные имена можно истегрировать с Microsoft Office 365

Перед добавлением домена в Microsoft Office 365 нужно подтвердить свое владение доменным именем домена, предоставив регистрационные данные регистратора доменов или поставщика хостинговых услуг.

Пользователи и группы

Работа с пользователями и группами в среде Microsoft Office 365 требует определенного привыкания. Это делается с помощью не консоли «Active Directory — пользователи и компьютеры» (Active Directory Users and Computers), а специального интерфейса (рис. 2).

*

Рис. 2. Административная консоль позволяет создавать и управлять учетными записями пользователей

Доступны несколько вариантов управления учетными записями пользователей. Если у вас уже имеется среда Active Directory, оптимальным вариантом будет синхронизация с Active Directory. При этом создается связь между локальной службой Active Directory и облаком Microsoft Office 365. Вам останутся доступны существующая инфраструктура Active Directory и все инструментальные средства управления Active Directory.

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

Другой вариант управления учетными записями пользователей — использовать федерацию идентификационной информации. Основная идея федерации идентификационной информации — сохранение возможности управлять собственной средой Active Directory. Версия 2.0 службы федерации Active Directory позволяет пользователям входить в облако, используя свои обычные регистрационные данные Active Directory.

Если вы планируете использовать синхронизацию Active Directory, Microsoft настоятельно рекомендует организовать федерацию идентификационной информации. Если же вы планируете использовать синхронизацию Active Directory без федерации идентификационной информации, нужно переделегировать управление доменом, как описано ранее.

Старт в облако

Следует отметить, что наличие локальной Active Directory необязательно для использования Microsoft Office 365. Также вы можете перенести все локальные приложения в облако при условии, что в локальной сети нет приложений, которым для работы нужна Active Directory (помимо тех, что входят в состав Microsoft Office 365).

Административный интерфейс позволяет создавать учетные записи пользователей непосредственно в среде Microsoft Office 365, но этого не стоит делать, если используется синхронизация с каталогом. Учетные записи пользователей можно создавать по одной средствами доступного через веб мастера, а административная консоль позволяет выполнять массовое создание учетных записей, на основании информации из предварительно созданного и импортированного CSV-файла. Как видно на рис.3, административная консоль позволяет загрузить пустой CSV-файл или файл-пример.

*

Рис. 3. Возможно массовое создание учетных записей путем загрузки информации о пользователях из CSV-файла

Миграция существующих пользователей

Microsoft Office 365 позволяет не только создавать в облаке новые учетные записи пользователей, но и переносить существующих пользователей. В состав Microsoft Office 365 входит Exchange Server 2010. Хотя данные почтового ящика хранятся на сервере почтовых ящиков, сам почтовый ящик является атрибутом Active Directory. Таким образом перемещение учетной записи пользователя также означает перенос его почтового ящика.

Миграция не является процессом в стиле «все или ничего». Возможна реализация сценария сосуществования, при котором у части пользователей почтовые ящики хранятся на локальном Exchange-сервере, а почтовые ящики других пользователей размещаются в облаке.

Таким образом, миграция пользователей в Microsoft Office 365 рассматривается как миграция почтовых ящиков. Microsoft Office 365 поддерживает два типа миграции почтового ящика: IMAP-миграцию (Internet Message Access Protocol) и миграцию локальных пользователей Exchange.

IMAP-миграция

Этот тип миграции используется для переноса данных почтовых ящиков из систем, отличных о Exchange, или с Exchange 5.5 или Exchange 2000. Сам процесс миграции относительно прост, но может потребовать существенных усилий по подготовке.

Перед IMAP-миграцией надо создать почтовые ящики Exchange для всех пользователей, данные почтовых ящиков которых планируется перемещать. Также нужно создать CSV-файл с адресом электронной почты, именем пользователя и паролем всех перемещаемых почтовых ящиков. Собрав всю необходимую информацию, можете запустить миграцию командой E-Mail Migration в Outlook Web App (рис. 4).

*

Рис. 4. Миграция почтовых ящиков в Outlook Web App

Пока Microsoft Office 365 находится в состоянии бета-тестирования, поэтому не совсем понятно, сколько пользователей можно перемещать за раз без ущерба для производительрности. В интерфейсе миграции почты указано, что число почтовых ящиков не должно превышать 1000, но в документации говорится, что можно выполнять крупномасштабную миграцию, перемещая почтовые ящики в рамках пакетной операции, причем размер пакета не должен превышать 2500 почтовых ящиков.

Миграция Exchange

Как и IMAP-миграция, Exchange-миграция служит для переноса данных почтовых ящиков в облако. В процессе миграции перемещаются сообщения, контакты и группы рассылки.

Есть два вида Exchange-миграции. При простой миграции переносятся все почтовые ящики Exchange сразу. Поэтапная миграция позволяет переносить часть почтовых ящиков и обычно применяется в сценариях сосуществования.

Первый этап простой миграции — определение типа переноса: Exchange 2007 и более поздние версии или Exchange 2003 и более позднее версии (рис. 5). Единственное реальное различие между этими вариантами в том, что в первом для автоматического определения параметров подключения используется служба автообнаружения (Autodiscover). В варианте «Exchange 2003 и более позднее версии» параметры подключения задаются вручную.

*

Рис. 5. Автообнаружение параметров подключения в варианте простой миграции Exchange 2007

Естественно, что процесс миграции занимает некоторое время, особенно, если почтовых ящиков много или они объемные (в Microsoft Office 365 действует квота на размер почтового ящика — 25 ГБ). Для обеспечения синхронности почтовых ящиков в процессе миграции в Microsoft Office 365 применяются два метода синхронизации.

В процессе начальной синхронизации данные почтовых ящиков сначала копируются в облако. После этого Exchange выполняет операции добавочной синхронизации каждые 24 часа, в процессе которой в облако копируются все новые данные почтовых ящиков.

По завершении миграции всех почтовых ящиков Exchange-сервер отправляет соответствующее сообщение электронной почты. Это сообщение содержит два вложения: файл MigrationErrors.csv, в котором перечислены все почтовые ящики, которые не удалось перенести, и файл MigrationStatistics.csv с информацией о числе перенесенных элементов.

Но самое важное, что файл MailboxStatistics.csv содержит временные пароли всех пользователей. Этот пароль нужен пользователю для входа в облако, где ему будет предложено заменить временный пароль на постоянный.

Сейчас можно переадресовать запись Mail Exchange на корпоративном DNS-сервере на сервер в облаке. Тогда сообщения будут поступать непосредственно на облачный сервер. Миграция завершается финальной синхронизацией и отправкой подтверждающих сообщений электронной почты. С этого момента вы и ваши пользователи считаетесь полностью перенесенными в облако.

Автор: Брайен Поузи  •  Иcточник: Журнал TechNet  •  Опубликована: 03.06.2011
Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER


Оценить статью:
Вверх
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.