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

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

После каждого пробного запуска группа по переносу доменов предоставляет результаты с подробным описанием невыполненных задач перед переносом и способами их решения.

Выполните эти задачи до перевода.

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

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

    Примечания:

    • В исходной среде для временного приобретения лицензий и избежания затрат можно использовать льготные или пробные лицензии. Однако обратите внимание на следующие моменты:
      • Эти лицензии блокируют возможность замены основного домена любым другим доменом. Перед предоставлением временных лицензий измените основной домен.
      • Если в целевой среде доступны полные лицензии, то в результате передачи пользователям предоставляются полные лицензии.
    • Пользователи в исходной среде, которым не назначены лицензии, всё равно переходят в новую среду.
  2. Отмена неподдерживаемых лицензионных подписок — Отмена лицензионных подписок может иметь последствия. В средах с Google Voice, использующих исходный код, этому шагу следует уделить особое внимание. Подробности см. в разделе «Лицензии исходного кода» .
  3. Добавление домена-заполнителя в Google Workspace (если применимо) — Добавьте и подтвердите новое дополнительное доменное имя в исходной среде, которое в конечном итоге заменит существующий основной домен . Если дополнительный домен существует и его не нужно переносить, вы можете использовать его вместо основного. Подробности см. в разделе «Добавление домена-псевдонима пользователя или дополнительного домена» .
  4. Create a placeholder administrator and make it the primary administrator of the account —Create a user account associated with the placeholder domain . If you repurpose an old account, make sure no other transfer domains existing as aliases are attached to the account. Grant this user the super administrator role and make them the primary administrator on the account. For more information, go to Send billing and account notifications to another admin . Make sure that Google 2-Step Verification is set up and sign in at least once to verify access with the placeholder administrator account.
  5. Поменять местами основной домен и домен-заполнитель — Выполнить замену домена, сделав домен-заполнитель новым основным доменом.

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

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

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

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

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

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

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

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

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

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

  8. Устранение конфликтов ресурсов календаря — Если возникли конфликты ресурсов календаря , устраните их, прежде чем продолжить:
    • Building IDs —A building ID in the source environment cannot be the same as a building ID in the destination environment. To bypass the transfer block, you have 2 options. You can delete the building in the source environment. Or, you can make the 2 buildings' details identical to merge the source and destination buildings. To make the 2 buildings identical, make the ID, name, all address fields, description, and floor exactly the same for both buildings.
    • Названия зданий — Если ресурс здания в исходной среде имеет то же имя, что и ресурс здания в целевой среде, необходимо изменить имя одного из ресурсов, чтобы разрешить конфликт. После завершения процесса переноса можно объединить два ресурса зданий.
    • Resource IDs —A resource in the source environment that has the same Resource ID as a resource in the destination creates a conflict that can't be resolved by the transfer process, and the resource won't transfer. Delete one of the conflicting resources and re-create it with a non-conflicting ID. It takes 30 days for a deleted resource to be completely cleared from the system. You can either wait for the resource to be completely deleted, or the Domain Transfer team can submit a request to manually delete it.
  9. Evaluate impact to the associated Google Cloud organization (if applicable) —If Google Cloud is being used, notify the administrators of that environment regarding the potential impacts Google Workspace Domain Transfer might have on Google Cloud. If necessary, involve your Google Cloud partner or contacts at Google Cloud for help with evaluating impacts and remediation steps. The Google Workspace Domain Transfer team doesn't offer assistance with Google Cloud during a domain transfer engagement.
  10. Уведомите своего реселлера Google Workspace (если применимо) — сообщите ему о планируемом времени переноса домена и попросите не вносить изменения в учетную запись (например, не обновлять подписки) в течение периода переноса.

  11. Enroll in any alpha or beta programs the source or destination environment is participating in (if applicable) —Alpha and beta program enrollments are not transferred in the source environment. Likewise, the source environment might depend on enrollments in the destination environment. The unenrolled environment needs to apply to and be accepted into those programs to continue to use them.
    Мы рекомендуем вам зарегистрироваться в альфа- или бета-программах до начала переноса, чтобы у пользователей, которых вы переносите, были все доступные функции на протяжении всего процесса переноса. Однако процесс регистрации может занять некоторое время, и успех не гарантирован. Поэтому это рекомендуется, но не является обязательным.

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

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

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

  13. Удалите гостевые учетные записи — гостевые домены и гостевые учетные записи не переносятся в целевую среду. Отключите приглашения для гостей и удалите все существующие гостевые учетные записи.

    Чтобы отключить приглашения для гостей:

    1. В консоли администратора перейдите в меню . а потом Безопасность а потом Контроль доступа и данных а потом Внешний доступ .
    2. Снимите флажок « Разрешить пользователям отправлять гостевые приглашения лицам, не входящим в вашу организацию» .

    Чтобы удалить гостевые учетные записи:

    1. В консоли администратора перейдите в меню . а потом Каталог а потом Гости .
    2. Выберите всех гостевых пользователей и нажмите «Удалить пользователя» .
  14. Настройка управления мобильными устройствами:

    1. В консоли администратора Google перейдите в меню. а потом Устройства а потом Мобильные устройства и конечные точки а потом Настройки а потом Универсальный .

      Для этого требуются права администратора системы управления мобильными устройствами .

    2. Нажмите «Общие» а потом Управление мобильными устройствами и выбор опции:
      • Базовый (без агентов) режим — Вы можете установить базовые требования к паролю блокировки экрана, развертывать управляемые приложения и удаленно удалять только рабочую учетную запись (но не личные данные) в случае утери или кражи устройства.
      • Расширенные настройки (требуется приложение «Политика устройств») — все функции базового режима плюс управление через приложение, удаленное стирание данных с устройств и подтверждение доступа к устройствам.
      • Пользовательские настройки — Настройка параметров управления в зависимости от платформы устройства.
      • Отключите управление мобильными устройствами (неуправляемый режим) — пользователи могут добавлять свои рабочие учетные записи и получать доступ к корпоративным данным (таким как Gmail и Drive) без политик безопасности или административного контроля.
    3. Нажмите « Сохранить ».

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

  1. Licenses are not moved as a part of the transfer process so you must provision enough spare Google Workspace licenses to support all transfer users —When you transfer users, they're assigned the same set of licenses in the destination environment they had in the source environment. Therefore, there must be enough spare licenses of the same type in the destination environment at the time of the transfer.

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

    Примечания :

    • Google рекомендует обновить лицензии, чтобы предотвратить запуск процесса полного удаления сервисов (SWP) .
    • Предоставьте все недостающие лицензии, чтобы в целевой среде существовало несколько подписок. После переноса вы можете по желанию повысить или понизить уровень лицензий для отдельных пользователей. Обратите внимание, что не все типы лицензий поддерживают частичное лицензирование доменов (PDL) .
    • Убедитесь, что в целевой среде имеется достаточное количество свободных лицензий. Учтите, не добавляются ли новые пользователи (например, новые сотрудники) в каждую исходную среду в период между началом и завершением процесса переноса. Если переносов несколько, необходимо также учесть общее количество пользователей из исходных сред по всем переносам.
    • Пользователи в исходной среде, которым не назначены лицензии, всё равно переносятся. Необходимо отслеживать автоматическое назначение лицензий в целевой среде, чтобы убедиться, что эти пользователи не получат лицензии.
    • Domain transfer does not offer special Google Workspace billing plans to accommodate the purchase of spare licenses during the transfer. If the source environment licenses are under an annual billing plan, they remain active and are billed until the end of your annual plan contract. Consult your sales representative or account manager if you have more questions regarding Google Workspace billing plans.

  2. Ensure licenses are correctly applied to transfer users when multiple licenses exist —Some configurations within the destination environment might impact the way transfer users are assigned licenses.This situation might result in transfer users ending up with a different license than expected. These configurations include automatic licensing and overriding automatic licensing for specific organizations .

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

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

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

    • Ничего не делать — В процессе переноса домена структура организационной единицы воссоздается из исходной среды в рамках новой корневой организационной единицы переноса. Для выполнения этого шага установите параметр переноса «предварительно воссоздать структуру организационной единицы» в значение «Нет». Все входящие пользователи переноса наследуют политики, которые вы применяете на уровне организационной единицы.
    • Manually re-create the source environment organizational unit structure under the transfer root organizational unit —Domain transfer ensures that the source environment's entire organizational unit structure is properly replicated before proceeding with the transfer. To do this step, set the transfer option "recreate the organizational unit structure in advance" to Yes. This option is useful if you want to set distinct policies on different child organizational units.

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

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

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

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

    • Включение/выключение служб — Убедитесь, что службы, используемые в исходной среде, включены в целевой среде, и что корневая организационная единица переноса работает должным образом. Это особенно важно при использовании Google Vault, поскольку правила Vault могут не применяться, если служба отключена.
    • Gmail, расширенные настройки и записи MX — Проверьте такие параметры, как маршрутизация почты, правила соответствия и включение и делегирование IMAP. Для получения подробной информации перейдите в раздел «Активация Gmail с помощью Google Workspace» .
    • Управление паролями — Проверьте свои политики паролей, чтобы убедиться, что они соответствуют процедурам вашей организации. После переноса пользователей в целевую среду они наследуют политики управления паролями в целевой среде.
    • 2-Step Verification —Controls whether users are allowed to add a 2-Step Verification configuration to their account, whether it's allowed or it's enforced. If transfer users with 2-Step Verification turned on are transferred into a destination environment or organizational unit where 2-Step Verification is turned off, destination administrators will be unable to manage them. Instead, admins can either move these users to a different organizational unit where 2-Step Verification is turned on to make changes, or they can remove 2-Step Verification from accounts before the transfer.
    • Sharing settings —Controls whether users can share their content outside the organization. If the source environment blocks sharing and the destination environment does not, then transfer content might be accessible outside your organization. If the source environment has open sharing by default and the destination environment does not, then transfer content might be inaccessible to users in your organization. Learn more about sharing options for Google Drive and Google Calendar .
    • Data loss prevention (DLP) rules —Monitors and prevents users from sharing sensitive information outside your organization. When DLP prevents users from sharing information in the source environment, and content is transferred into a destination environment without DLP setup, users in the destination environment can share information outside your organization. Learn more about Gmail DLP rules and Drive DLP rules .
    • Chat history —Controls whether chat history is on or off the record, and whether users can set enforcement on all chats or make it the default. If the source environment allows for chat history to be turned on, but the destination environment forces it to be off, then chat history is lost. While Google Chat is listed as unsupported for the transfer, direct messages (DMs) will transfer.
    • Data countries/regions —Controls which specific geographic location to store your migrated data. Transfer users that need to stay in a specific geographic location must have this policy set appropriately in the destination environment to make sure their data does not unexpectedly leave their required data country/region. For details, go to Data regions: Choose a geographic location for your data .
    • Less secure apps (also known as App Passwords) —If less secure apps are turned on in the source environment and are turned off in the destination environment, the connection with the application using less secure apps time out and close. Timeout periods vary by application, but usually expire within 60 minutes. Future access requests made by the insecure application are blocked. For details, go to Control access to less secure apps .
    • OAuth scopes, single sign-on (SSO) for SAML, trusted apps, and Chrome extensions —OAuth controls determine the level of API access allowed to users and third-party applications. SSO for SAML, whether supplied by Google Workspace or implemented as a custom application, allows users to leverage their Google Workspace credentials to access other applications or services. Trusted apps determine the applications users can install from the Google Workspace Marketplace or Chrome Web Store and which apps are allowed to bypass OAuth restrictions. Learn more about how to control third-party & internal apps , SAML SSO , Google Workspace Marketplace apps , and Chrome apps and extensions .
    • Делегирование на уровне домена — позволяет приложениям получать доступ к данным Google Workspace пользователей. Чтобы убедиться в корректной работе клиентов и областей действия, перед передачей настройте делегирование на уровне домена в целевой среде.

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

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

  8. Enroll in any alpha or beta programs the source or destination environment is participating in (if applicable) —Alpha and beta program enrollments are not transferred in the source environment. Likewise, the source environment might depend on enrollments in the destination environment. The unenrolled environment needs to apply to and be accepted into those programs to continue to use them.
    Мы рекомендуем вам зарегистрироваться в альфа- или бета-программах до начала переноса, чтобы у пользователей, которых вы переносите, были все доступные функции на протяжении всего процесса переноса. Однако процесс регистрации может занять некоторое время, и успех не гарантирован. Поэтому это рекомендуется, но не является обязательным.

Важный :

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

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

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

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

  • External dependencies —If you use Google Cloud Directory Sync (GCDS), GAM (a third-party command-line tool for Google Workspace administrators to manage domain and user settings), or a third-party single sign-on (SSO) provider, make sure to analyze the effect of the transfer. Also examine how having the source and destination environments coexisting in a single environment affects your system and the timing of your transfer execution.

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

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

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

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

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

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

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

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

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