5. Выполните подготовительные задания перед переводом.

Шаг 1: Поиск задач

1. Обновление лицензий (если применимо) — Лицензии не перемещаются в процессе переноса. Если в исходной среде используется другая версия Google Workspace, чем в целевой среде, необходимо обновить исходную версию, чтобы она соответствовала целевой. Для получения дополнительной информации см. раздел «Перенос лицензий» в подразделе «Задачи целевой среды» .

   Примечания:

   • В исходной среде для временного приобретения лицензий и избежания затрат можно использовать льготные или пробные лицензии. Однако обратите внимание на следующие моменты:
     • Эти лицензии блокируют возможность замены основного домена любым другим доменом. Перед предоставлением временных лицензий измените основной домен.
     • Если в целевой среде доступны полные лицензии, то в результате передачи пользователям предоставляются полные лицензии.
   • Пользователи в исходной среде, которым не назначены лицензии, всё равно переходят в новую среду.
2. Отмена неподдерживаемых лицензионных подписок — Отмена лицензионных подписок может иметь последствия. В средах с Google Voice, использующих исходный код, этому шагу следует уделить особое внимание. Подробности см. в разделе «Лицензии исходного кода» .
3. Добавление домена-заполнителя в Google Workspace (если применимо) — Добавьте и подтвердите новое дополнительное доменное имя в исходной среде, которое в конечном итоге заменит существующий основной домен . Если дополнительный домен существует и его не нужно переносить, вы можете использовать его вместо основного. Подробности см. в разделе «Добавление домена-псевдонима пользователя или дополнительного домена» .
4. Создайте временного администратора и назначьте его основным администратором учетной записи . — Создайте учетную запись пользователя, связанную с временным доменом . Если вы используете старую учетную запись повторно, убедитесь, что к ней не привязаны другие домены, используемые в качестве псевдонимов. Предоставьте этому пользователю роль суперадминистратора и назначьте его основным администратором учетной записи. Для получения дополнительной информации перейдите к разделу «Отправка уведомлений о выставлении счетов и учетной записи другому администратору» . Убедитесь, что настроена двухфакторная аутентификация Google , и войдите в систему хотя бы один раз, чтобы подтвердить доступ с помощью учетной записи временного администратора.
5. Поменять местами основной домен и домен-заполнитель — Выполнить замену домена, сделав домен-заполнитель новым основным доменом.

   Перед тем как сменить домен :

   Когда будете готовы к смене домена, перейдите в раздел «Изменение основного домена для Google Workspace» .

   • Отмените все подписки на устройства, включая оборудование Google Meet и Chrome Enterprise.
   • Перед передачей может потребоваться удалить некоторые неподдерживаемые лицензии. Подробности см. в разделе «Исходные лицензии» .
   • Если в исходной среде используются пробные лицензии, замена будет заблокирована. Убедитесь, что замена происходит до предоставления каких-либо временных лицензий.
   • Изменение основного домена и использование дополнительных доменов сопряжены с известными проблемами. Ознакомьтесь с альтернативами изменению основного домена .
   • Не переименовывайте пользователей или группы, перенесенные в другой домен, после изменения основного доменного имени. Пользователи и группы должны оставаться в своих доменах, в которые они были перенесены.
   • Если вы настраиваете единый вход (SSO) с использованием стороннего поставщика удостоверений и используете эмитента, привязанного к домену, утверждение SAML изменяется в соответствии с новым основным доменом. Проверьте конфигурацию вашего поставщика удостоверений, чтобы убедиться, что пользователи смогут проходить аутентификацию после смены основного домена. Подробности см. в разделе «Требования к утверждениям SSO» .
6. Настройка правил хранения данных в Google Vault — Создание пользовательских правил хранения данных на неопределенный срок.

   Создайте одно правило для следующих приложений:

   • Gmail — В поле «Организационное подразделение» выберите корневое организационное подразделение.
   • Google Groups — Для выбора групп выберите «Все группы».

   Создайте 2 правила для следующих приложений:

   • Чат — Выберите организационное подразделение Корневая организационная единица. Для второго правила выберите «Все чаты» .
   • Диск — Выберите организационное подразделение корневую организационную единицу. Для второго правила выберите «Все общие диски» .
   • Встреча — Выберите организационное подразделение Для корневого организационного подразделения включите параметр «Включать элементы с общих дисков» . Для второго правила выберите «Все общие диски» .
   • Сайты — Выберите организационное подразделение Для корневого организационного подразделения включите параметр «Включать элементы с общих дисков» . Для второго правила выберите «Все общие диски» .

   Кроме того, перед переносом в целевой среде настраиваются правила бессрочного хранения данных. Подробности см. в разделе «Бессрочное хранение данных в Google Vault в целевой среде ». Дополнительную информацию о переносе данных из Vault см. в разделе «Перенос данных Vault с переносом домена» .

7. Обновите запись Sender Policy Framework (SPF) (если применимо) — Если в целевой среде используется исходящий шлюз, отличный от исходящей среды, источнику следует обновить свою запись SPF, включив в нее исходящий шлюз.

   Примечание: Если вы используете DomainKeys Identified Mail (DKIM), перенос не должен повлиять на вашу политику аутентификации, отчетности и соответствия сообщений на основе домена (DMARC). Запись SPF продолжит выравниваться после переноса, даже если DKIM временно не будет выравниваться. Также убедитесь, что вы выполнили задачу DKIM после переноса в целевой среде.

8. Устранение конфликтов ресурсов календаря — Если возникли конфликты ресурсов календаря , устраните их, прежде чем продолжить:
   • Идентификаторы зданий — Идентификатор здания в исходной среде не может совпадать с идентификатором здания в целевой среде. Чтобы обойти блокировку переноса, у вас есть 2 варианта. Вы можете удалить здание в исходной среде. Или вы можете сделать данные двух зданий идентичными, чтобы объединить исходное и целевое здания. Чтобы сделать два здания идентичными, сделайте идентификатор, название, все поля адреса, описание и этаж абсолютно одинаковыми для обоих зданий.
   • Названия зданий — Если ресурс здания в исходной среде имеет то же имя, что и ресурс здания в целевой среде, необходимо изменить имя одного из ресурсов, чтобы разрешить конфликт. После завершения процесса переноса можно объединить два ресурса зданий.
   • Идентификаторы ресурсов — Если ресурс в исходной среде имеет тот же идентификатор, что и ресурс в целевой среде, это создает конфликт, который не может быть разрешен процессом переноса, и ресурс не будет перенесен. Удалите один из конфликтующих ресурсов и создайте его заново с неконфликтующим идентификатором. Для полного удаления удаленного ресурса из системы требуется 30 дней. Вы можете либо дождаться полного удаления ресурса, либо команда по переносу доменов может отправить запрос на его ручное удаление.
9. Оцените влияние на соответствующую организацию Google Cloud (если применимо) — Если используется Google Cloud, уведомите администраторов этой среды о потенциальном влиянии переноса домена Google Workspace на Google Cloud. При необходимости обратитесь за помощью к своему партнеру или контактам в Google Cloud для оценки последствий и принятия мер по их устранению. Команда Google Workspace Domain Transfer не оказывает помощь Google Cloud во время переноса домена.
10. Уведомите своего реселлера Google Workspace (если применимо) — сообщите ему о планируемом времени переноса домена и попросите не вносить изменения в учетную запись (например, не обновлять подписки) в течение периода переноса.

11. Зарегистрируйтесь в любых альфа- или бета-программах, в которых участвует исходная или целевая среда (если применимо) — регистрация в альфа- и бета-программах не переносится в исходную среду. Аналогично, исходная среда может зависеть от регистрации в целевой среде. Незарегистрированная среда должна подать заявку и быть принята в эти программы, чтобы продолжить их использование.
    Мы рекомендуем вам зарегистрироваться в альфа- или бета-программах до начала переноса, чтобы у пользователей, которых вы переносите, были все доступные функции на протяжении всего процесса переноса. Однако процесс регистрации может занять некоторое время, и успех не гарантирован. Поэтому это рекомендуется, но не является обязательным.

12. Для переноса данных с устройств Chrome, зарегистрированных в режиме нулевого касания:
    1. В исходной среде отзовите существующий токен предварительной настройки и отмените настройку всех устройств. Сбросьте устройства до заводских настроек по умолчанию.
    2. В целевой среде создайте новый токен предварительной подготовки.
    3. Предоставьте новый токен вашему авторизованному партнеру по предварительной настройке. Ваш партнер использует токен для предварительной настройки устройств в целевой среде.

    Устройства регистрируются автоматически после подключения к интернету. Состояние устройства меняется на «Подготовлено».

    Для получения дополнительной информации об устройствах с нулевым касанием перейдите на страницу регистрации устройств с нулевым касанием .

Шаг 2: Целевые задачи

1. Лицензии не перемещаются в процессе переноса, поэтому необходимо выделить достаточное количество свободных лицензий Google Workspace для поддержки всех переносимых пользователей. При переносе пользователей им назначается тот же набор лицензий в целевой среде, что и в исходной среде. Следовательно, на момент переноса в целевой среде должно быть достаточно свободных лицензий того же типа.

   Если в целевой среде используется другая версия Google Workspace, чем в исходной, убедитесь, что лицензии совпадают, обновив лицензии либо в исходной, либо в целевой среде.

   Примечания :

   • Google рекомендует обновить лицензии, чтобы предотвратить запуск процесса полного удаления сервисов (SWP) .
   • Предоставьте все недостающие лицензии, чтобы в целевой среде существовало несколько подписок. После переноса вы можете по желанию повысить или понизить уровень лицензий для отдельных пользователей. Обратите внимание, что не все типы лицензий поддерживают частичное лицензирование доменов (PDL) .
   • Убедитесь, что в целевой среде имеется достаточное количество свободных лицензий. Учтите, не добавляются ли новые пользователи (например, новые сотрудники) в каждую исходную среду в период между началом и завершением процесса переноса. Если переносов несколько, необходимо также учесть общее количество пользователей из исходных сред по всем переносам.
   • Пользователи в исходной среде, которым не назначены лицензии, всё равно переносятся. Необходимо отслеживать автоматическое назначение лицензий в целевой среде, чтобы убедиться, что эти пользователи не получат лицензии.
   • При переносе домена специальные тарифные планы Google Workspace не предусматривают приобретение дополнительных лицензий во время переноса. Если лицензии исходной среды оформлены на годовой тарифный план, они остаются активными и оплачиваются до конца срока действия вашего годового договора. Если у вас возникнут дополнительные вопросы относительно тарифных планов Google Workspace, обратитесь к своему торговому представителю или менеджеру по работе с клиентами.

2. Убедитесь, что лицензии правильно применяются к передаваемым пользователям, если существует несколько лицензий. — Некоторые конфигурации в целевой среде могут влиять на способ назначения лицензий передаваемым пользователям. В результате передаваемые пользователи могут получить лицензию, отличающуюся от ожидаемой. К таким конфигурациям относятся автоматическое лицензирование и переопределение автоматического лицензирования для конкретных организаций .

   Чтобы избежать непредвиденных изменений в лицензионных соглашениях во время передачи, необходимо выполнить следующие действия:

   • Если в целевой среде для автоматического лицензирования установлено значение «Отключено для всех» или если в целевой среде используется только один тип лицензии, то никаких изменений не требуется.
   • Если в целевой среде автоматическое лицензирование включено для всех (например, лицензии Google Workspace), убедитесь, что переопределение включено для конкретных организационных подразделений. Для корневого организационного подразделения, в которое осуществляется передача данных, убедитесь, что автоматическое лицензирование отключено, и дальнейшее переопределение для дочерних организационных подразделений не требуется.

3. Создайте корневую организационную единицу для переноса и, при необходимости, воссоздайте структуру организационных единиц исходной среды. — Создайте организационную единицу, которая будет служить родительской организационной единицей для всех пользователей, используемых для переноса. После создания у вас есть 2 варианта:

   • Ничего не делать — В процессе переноса домена структура организационной единицы воссоздается из исходной среды в рамках новой корневой организационной единицы переноса. Для выполнения этого шага установите параметр переноса «предварительно воссоздать структуру организационной единицы» в значение «Нет». Все входящие пользователи переноса наследуют политики, которые вы применяете на уровне организационной единицы.
   • Вручную воссоздайте структуру организационных единиц исходной среды в рамках корневой организационной единицы переноса — Перенос домена гарантирует, что вся структура организационных единиц исходной среды будет должным образом реплицирована перед продолжением переноса. Для этого установите параметр переноса «предварительно воссоздать структуру организационных единиц» в значение «Да». Этот параметр полезен, если вы хотите установить разные политики для разных дочерних организационных единиц.

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

4. Установите соответствующие политики и настройки, отражающие требования исходной и целевой среды. Политики и настройки исходной среды не переносятся в целевую среду. Кроме того, после завершения процесса переноса к переносимым пользователям и их данным будут применяться только политики и настройки целевой среды.

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

   Ниже приведён неполный список политик и настроек, которые следует проверить в процессе установки. Также проведите полный аудит обеих сред, чтобы убедиться, что все соответствующие разделы проанализированы:

   • Включение/выключение служб — Убедитесь, что службы, используемые в исходной среде, включены в целевой среде, и что корневая организационная единица переноса работает должным образом. Это особенно важно при использовании Google Vault, поскольку правила Vault могут не применяться, если служба отключена.
   • Gmail, расширенные настройки и записи MX — Проверьте такие параметры, как маршрутизация почты, правила соответствия и включение и делегирование IMAP. Для получения подробной информации перейдите в раздел «Активация Gmail с помощью Google Workspace» .
   • Управление паролями — Проверьте свои политики паролей, чтобы убедиться, что они соответствуют процедурам вашей организации. После переноса пользователей в целевую среду они наследуют политики управления паролями в целевой среде.
   • Двухфакторная аутентификация — определяет, разрешено ли пользователям добавлять конфигурацию двухфакторной аутентификации к своей учетной записи, разрешена ли она или является обязательной. Если пользователи, у которых включена двухфакторная аутентификация, переносятся в целевую среду или организационное подразделение, где двухфакторная аутентификация отключена, администраторы целевой среды не смогут ими управлять. Вместо этого администраторы могут либо переместить этих пользователей в другое организационное подразделение, где двухфакторная аутентификация включена, чтобы внести изменения, либо удалить двухфакторную аутентификацию из учетных записей перед переносом.
   • Настройки общего доступа — определяют, могут ли пользователи делиться своим контентом за пределами организации. Если в исходной среде общий доступ заблокирован, а в целевой — нет, то переданный контент может быть доступен за пределами вашей организации. Если в исходной среде по умолчанию включен открытый общий доступ, а в целевой — нет, то переданный контент может быть недоступен для пользователей вашей организации. Подробнее о параметрах общего доступа для Google Диска и Google Календаря .
   • Правила предотвращения потери данных (DLP) — отслеживают и предотвращают передачу пользователями конфиденциальной информации за пределы вашей организации. Когда DLP запрещает пользователям обмениваться информацией в исходной среде, и контент передается в целевую среду без настройки DLP, пользователи в целевой среде могут обмениваться информацией за пределами вашей организации. Узнайте больше о правилах DLP в Gmail и правилах DLP в Google Drive .
   • История чата — определяет, включена или выключена история чата, а также позволяет пользователям устанавливать принудительное сохранение истории для всех чатов или сделать её значением по умолчанию. Если в исходной среде история чата включена, а в целевой среде она отключена, то история чата будет потеряна. Хотя Google Chat указан как неподдерживаемый для переноса, личные сообщения (DM) будут перенесены.
   • Страны/регионы хранения данных — Определяет, в каком конкретном географическом регионе будут храниться ваши перенесенные данные. Пользователи, которым необходимо оставаться в определенном географическом регионе, должны соответствующим образом настроить эту политику в целевой среде, чтобы гарантировать, что их данные неожиданно не покинут требуемую страну/регион хранения данных. Для получения подробной информации перейдите в раздел «Регионы хранения данных: выберите географическое местоположение для ваших данных» .
   • Менее защищенные приложения (также известные как пароли приложений) — Если в исходной среде включены менее защищенные приложения, а в целевой среде они отключены, соединение с приложением, использующим менее защищенные приложения, прерывается по истечении времени ожидания. Время ожидания варьируется в зависимости от приложения, но обычно истекает в течение 60 минут. Будущие запросы доступа, сделанные небезопасным приложением, блокируются. Для получения подробной информации перейдите в раздел «Управление доступом к менее защищенным приложениям» .
   • Области действия OAuth, единый вход (SSO) для SAML, доверенные приложения и расширения Chrome — элементы управления OAuth определяют уровень доступа к API, разрешенный пользователям и сторонним приложениям. SSO для SAML, независимо от того, предоставляется ли он Google Workspace или реализован как пользовательское приложение, позволяет пользователям использовать свои учетные данные Google Workspace для доступа к другим приложениям или сервисам. Доверенные приложения определяют, какие приложения пользователи могут устанавливать из Google Workspace Marketplace или Chrome Web Store, и каким приложениям разрешено обходить ограничения OAuth. Узнайте больше о том, как управлять сторонними и внутренними приложениями , SAML SSO , приложениями Google Workspace Marketplace , а также приложениями и расширениями Chrome .
   • Делегирование на уровне домена — позволяет приложениям получать доступ к данным Google Workspace пользователей. Чтобы убедиться в корректной работе клиентов и областей действия, перед передачей настройте делегирование на уровне домена в целевой среде.

   Важно : Невозможность правильно установить политики и настройки может привести к следующим последствиям:

   • Непреднамеренное раскрытие ваших данных за пределами вашей организации (например, в целевой среде более открытые настройки, чем в исходной).
   • Ограниченный доступ к ранее доступным данным (например, целевая среда имеет более строгие настройки, чем исходная).
5. Примите соглашения, регулирующие передачу данных — ознакомьтесь с поправкой к соглашению об обработке данных (DPA), типовым пунктом договора и поправкой HIPAA о деловом партнерстве (BAA) в целевой среде. Для получения более подробной информации перейдите в раздел «Соответствие требованиям конфиденциальности и ведение записей для Google Workspace и Cloud Identity» .
6. Включите Vault, если он используется в исходной среде. — Если в целевой среде Vault не используется, а в исходной среде используется, то в целевой среде необходимо включить Vault.
7. Уведомите своего реселлера Google Workspace (если применимо) — сообщите ему о планируемом времени переноса домена и попросите не вносить изменения в учетную запись (например, не обновлять подписки) в течение периода переноса.

8. Зарегистрируйтесь в любых альфа- или бета-программах, в которых участвует исходная или целевая среда (если применимо) — регистрация в альфа- и бета-программах не переносится в исходную среду. Аналогично, исходная среда может зависеть от регистрации в целевой среде. Незарегистрированная среда должна подать заявку и быть принята в эти программы, чтобы продолжить их использование.
   Мы рекомендуем вам зарегистрироваться в альфа- или бета-программах до начала переноса, чтобы у пользователей, которых вы переносите, были все доступные функции на протяжении всего процесса переноса. Однако процесс регистрации может занять некоторое время, и успех не гарантирован. Поэтому это рекомендуется, но не является обязательным.

Важный :

• Понижение версии лицензии может привести к потере доступа к сервисам и функциям Google Workspace. Перед внесением каких-либо изменений внимательно изучите различия между версиями Google Workspace и последствия как повышения, так и понижения версии. Узнайте больше о версиях Google Workspace .
• Понижение уровня лицензий может запустить процедуру SWP , которая может задержать перевод на срок до 90 дней.

Шаг 3: Другие задачи и соображения

• Управление изменениями — Ни команда Google Workspace Domain Transfer, ни сам процесс переноса не предоставляют пользователям автоматически информацию о ходе переноса. Настоятельно рекомендуется, чтобы представители исходной и целевой среды заранее информировали пользователей о процессе переноса и его потенциальных последствиях.

  Во время переноса блокируются все административные действия как в исходной, так и в целевой среде, включая доступ к API и консоли администратора Google. Настоятельно рекомендуется, чтобы представители исходной и целевой среды уведомили всех суперадминистраторов домена и делегированных администраторов до начала переноса и после его завершения.

• Внешние зависимости — Если вы используете Google Cloud Directory Sync (GCDS), GAM (сторонний инструмент командной строки для администраторов Google Workspace, позволяющий управлять настройками домена и пользователей) или стороннего поставщика единого входа (SSO), обязательно проанализируйте влияние переноса. Также изучите, как сосуществование исходной и целевой сред в одной среде влияет на вашу систему и время выполнения переноса.

Бессрочное хранение в хранилище Google Vault в целевой среде.

Функция Google Workspace Domain Transfer& настраивает бессрочные пользовательские правила хранения в целевой среде. Администраторам целевой среды никаких действий не требуется.

Архив Vault для пользователей, участвующих в передаче, перемещается, но правила хранения Vault из исходной среды остаются неизменными. Чтобы гарантировать сохранность данных Vault во время и после передачи, процесс передачи создает следующие правила хранения Vault в целевой среде до выполнения каких-либо действий по передаче:

• Gmail — Бессрочное пользовательское правило хранения (область действия: передача данных в корневую организационную единицу).
• Google Календарь — Бессрочное пользовательское правило хранения (область действия: передача корневого организационного подразделения).
• Google Chat — Бессрочное пользовательское правило сохранения (область действия: личные сообщения с пользователями, перешедшими в корневое организационное подразделение, но не в Spaces).
• Google Drive — Бессрочное пользовательское правило хранения, не включающее общие диски (область действия: корневая организационная единица передачи).
• Google Groups — Бессрочное пользовательское правило хранения (область действия: корневое организационное подразделение). Сохраняет данные для всех групп в целевой среде, включая те, которые не были включены в процесс переноса.
• Google Meet — требует 2 настраиваемых правила бессрочного хранения:
  1. Не включая общие диски (область охвата: корневая организационная единица передачи).
  2. Включая все общие диски (область действия: корневая организационная единица).

     Сохраняет данные со всех общих дисков в целевой среде, включая те, которые не были включены в процесс передачи.

• Google Sites — Требуется 2 пользовательских правила бессрочного хранения.
  1. Не включая общие диски (область охвата: корневая организационная единица передачи).
  2. Включая все общие диски (область действия: корневая организационная единица).

     Сохраняет данные со всех общих дисков в целевой среде, включая те, которые не были включены в процесс передачи.

• Общие диски — Настраиваемое правило бессрочного хранения для всех общих дисков (область действия: корневое организационное подразделение). Сохраняет данные для всех общих дисков в целевой среде, включая те, которые не были включены в процесс передачи.

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