情シス Corporate Engineering Google Workspace

2022-01-19

Google Workspaceのプライマリドメイン変更を実施しました

情シス Corporate Engineering Google Workspace

こんにちは、ペパボのCorporate Engineering Group（以下CEG）でソフトウェアエンジニアをしている加治です。

CEGでは、主にペパボ社内で利用されている社内向けサービスの開発・運用・保守を行っています。運用・保守を行っているサービスの中にはSaaSも含まれています。そのSaaSの一つであり、ペパボでメインで使用されているオフィススイートであるGoogle Workspaceのプライマリドメインを変更したお話をします。

最初に、このお話のターゲットを明確にしておこうと思います。

これからプライマリドメインを変更したい情シス、コーポレートエンジニアなどの担当者
プライマリドメインを変更したことがあり、ペパボではどうだったのかな〜と気になった人
Google Workspaceの運用をしていて、プライマリドメインが事実上のメインのドメインと異なるときの影響を知っておきたい人

このような方々を想定読者とします。また、そこそこの年月Google Workspaceなどを運用してきた関係で、背景の説明などが少々冗長に感じるかもしれませんがご容赦ください。

プライマリドメインをどうして変更するのか
どうしてプライマリドメインを変更できずにいたのか
1. メールダウンタイムが発生する
2. コアサービス以外のサービスに影響があるかもしれない
プライマリドメインを変更するための準備
1. メールダウンタイムへの対応
2. 非コアサービスへの対応
いざ、プライマリドメイン変更
1. ドメインエイリアス解除〜セカンダリドメイン登録
2. メールのダウンタイム回避
なぜプライマリドメイン変更ができなかったのか
プライマリドメイン変更に再トライする
プライマリドメイン変更の影響
プライマリメールアドレス変更の影響
今プライマリドメインを変更するならどうするか
まとめ

プライマリドメインをどうして変更するのか

プライマリドメインというのはその名の通り、Google Workspaceの主たるドメイン、メインのドメインと思ってもらって差し支えないと思います。このプライマリドメインは、デフォルトで作成されるユーザのメールアドレスのドメインや、Google Siteのパスなど、Google Workspaceを利用していると様々な箇所で目にすることになります。

ペパボで利用されているプライマリドメインは、プライマリドメイン変更を実施するまでは paperboy.co.jp というプライマリドメインでした。これは社名が「paperboy&co.」であった頃に取得、運用を開始されたドメインです。そしてGMOペパボに社名を変更した後、 pepabo.com というドメインが取得、運用されるようになりました。

このドメインは長らくGoogle Workspace上ではドメインエイリアスとして登録されて運用されていました。そして、自然と pepabo.com が利用される場面が増え、次第に pepabo.com が主たるドメインとして振る舞うようになりました。しかし、次第にGoogle Workspaceのプライマリドメインが paperboy.co.jp であることによって不便さを感じさせる場面が現れました。その例を下記に記します。

Google OAuth 2.0認証（Googleアカウント認証）でSaaSのアカウントを作成すると、ユーザのメールアドレスが username@paperboy.co.jp になってしまう
ユーザを作成する際、 username@pepabo.com なメールアドレスをエイリアスとしてユーザに付与する手間がかかる
Googleカレンダーなどでユーザを検索する際、 username@pepabo.com と username@paperboy.co.jp 2つが検索結果に出てしまう

また、 pepabo.com がドメインエイリアスであるということも不便さを感じさせる要因でした。セカンダリドメインであれば、username@pepabo.com をプライマリメールアドレスに持つユーザを作成できるのですが、ドメインエイリアスでは作成できません。また、ユーザの一覧を取得して棚卸しを実施する場合など、他のシステムでは username@pepabo.com というメールアドレスで登録されているため、スプレッドシート上で置換処理が必要など、細かなところで不便さを感じる場面がありました。

また、IDaaSと連携したプロビジョニングも実装されていません。これは、プライマリドメインが paperboy.co.jp であるため素直な実装にはならないことがわかっていたこともあり、プライマリドメイン変更を実施してからプロビジョニングの作り込みがしたいという心象になり手がつかずにいました。

プライマリドメインが旧社名であっても、CEGの担当者の作業が増えるなどの影響はあるもののGoogle Workspaceの運用そのものは可能でした。ただし、Google OAuth 2.0認証が実質利用不可として扱わざるをえなくなったり、細かな不満が積み重なっていきました。

どうしてプライマリドメインを変更できずにいたのか

それだけ不満を抱えていてどうしてプライマリドメインを変更できなかったのかというと、端的に言えばこのプライマリドメインを変更するという行為はGoogleも公式のヘルプで「複雑」と表現する程度には複雑だからです。2021/12/22時点のヘルプページには次のように記載されています。

なお、プライマリドメインの変更は複雑な手続きを伴うため、代わりに別のドメインをアカウントに追加するという方法もあります。詳しくは、プライマリドメインの変更に代わる方法をご覧ください。

引用に記載の通り、プライマリドメイン変更をしないで問題を解決する手段をヘルプページに提示する程度にはこの「プライマリドメイン変更」は厄介なのです。また、調査した限りでは次の影響があることがわかっていました。

新プライマリドメインになるドメイン宛のメールについてダウンタイムが発生する
一般に影響を受けないとされるのはコアサービスのみである

さて、また新しい用語が出ました。詳しく説明するために、それぞれの影響について言及します。

メールダウンタイムが発生する

今回、ペパボの新プライマリドメインになる予定の pepabo.com はドメインエイリアスとして登録されていました。Google Workspaceのドメインの登録には「プライマリドメイン」「セカンダリドメイン」「ドメインエイリアス」の3種類あります。プライマリドメインに変更できるドメインは、セカンダリドメインだけです。なので、 pepabo.com をドメインエイリアスとしての登録を削除し、セカンダリドメインとして登録し直す必要がありました。

そして、セカンダリドメインとして登録し直したものをプライマリドメインに昇格させる必要があります。それが完了したあと、ユーザのプライマリメールアドレスを新しいプライマリドメインをドメインに持つものに変更するというのがプライマリドメイン変更の全容です。 pepabo.com をドメインエイリアスから削除するのをスタート時点とするなら、そこからダウンタイムは次のように計算されることになります。

pepabo.com をドメインエイリアスから削除し、セカンダリドメインで登録できるようになるまでの時間（最大30分）
セカンダリドメインとして登録して、プライマリドメインに変更できるようになるまでの時間（最大24時間）
プライマリドメインを変更、完全に変更が完了するまでの時間（最大48時間）
ユーザのプライマリメールアドレスを変更するまでの時間（ユーザ数にもよりますが、ユーザ数500人ほどのペパボでは実測10分もかからなかったです）

つまり、合計72時間と40分ほどはダウンタイムが発生しうる、ということになります。最大、なのでもっと早く終わることもあります。実際、事前に検証用のGoogle Workspaceのテナントでプライマリドメインを変更した際は全体の作業が1時間半ほどで終わりました。

しかし、本番環境は検証環境に比べてユーザ数も多いし利用されてきた期間も長いです。したがってこの最大時間を考慮したダウンタイムをどうにか乗り切る必要があるでしょう。

コアサービス以外のサービスに影響があるかもしれない

本記事で述べるコアサービスとは、Google Workspaceのサポートに入っているサービスのことを指します。Gmail、Googleカレンダー、Google Driveなどがそうです。こちらに一覧があります。

サポートの範囲

また、それに含まれないサービスのことを非コアサービスと呼ぶことにします。非コアサービスの例としては、Google AnalyticsやGoogle広告、Data Studioなどがあります。これらのサービスはGoogle Workspaceのサポート対象外であるため、Google Workspaceのサポート窓口で問い合わせもできません。そのような仕様の一方で、Google Workspace上ではそれらの非コアサービスの利用許可/禁止を管理可能な仕様です。ペパボのGoogle Workspaceもご多分に漏れず、Google Analyticsなどを利用許可していました。その場合、ログインするユーザはGoogle Workspaceのユーザになります。今回のプライマリドメインの変更には、ユーザのプライマリメールアドレスの変更を含みます。そうなると、非コアサービスにも影響がでそうな気がしてきます。

非コアサービスとはいっても、業務で利用しているわけですから影響範囲は特定する必要があるでしょう。

プライマリドメインを変更するための準備

さて、ここまででプライマリドメインを変更する動機と、変更が及ぼしうる影響について記述しました。次は、ペパボでプライマリドメインを変更するためにした準備を紹介します。

メールダウンタイムへの対応

メールダウンタイムの対応には2つの案がありました。

Amazon SESなどでメールリレーサーバを構築し、一時的に pepabo.com 宛のメールをそのメールリレーサーバで paperboy.co.jp に転送する運用に切り替えることで受信できるようにする
休日夜間など比較的メールの利用されづらい時間帯にに作業する

まず1の案について検討しました。こちらは一時的に pepabo.com のMXレコードをGoogle WorkspaceからSESに向け直すことになります。SESでなくても、メールサーバを自前で構築してダウンタイムをできる限り無くすことはできそうです。Google Workspaceのサポートとディスカッションした結果、下記のような流れで実行することになりそうでした。

一時的に pepabo.com を受信するメールサーバ（以下回避サーバ）で pepabo.com で利用しているアドレスすべて作成する
pepabo.com のMXレコードを、回避サーバに変更する
メール受信が安定したことを確認したら、プライマリドメイン変更の作業を行う
pepabo.com へのアドレス変更が管理コンソールで完了したら、MXレコードをGmailに戻す

しかし、一時的に回避サーバで受信したメールの取扱を考える必要があること、ペパボでは殆どのコミュニケーションをSlackなどに移行していたことなどから、休日夜間帯であれば事前に告知を行った上であれば受容可能であろうという判断がなされました。

非コアサービスへの対応

非コアサービスに対しても、対応方法を考えました。まずGoogle Workspaceのサポートは非コアサービスについては基本的には回答できないため、各非コアサービスのサポート窓口に問い合わせる必要があります。しかし、非コアサービスへの影響についてCEGの担当者が調べるのには下記のような課題がありました。

CEGの担当者がすべての非コアサービス、非コアサービス上のプロジェクトを把握しているわけではない
非コアサービスによっては問い合わせるのに登録が必須で、登録するのにそのサービスを利用する環境がないと厳しい場合がある
問い合わせができたとして、利用している事業部の利用機能や環境に合わせた問い合わせはできない

これらの課題に対処するために、CEGでは下記の対応を取りました。

Google Workspaceの管理コンソールにて、Google Workspaceのアカウントで利用可能になっている非コアサービスを洗い出す
その非コアサービスをリスト化、各事業部に担当者を立ててもらい利用状況をヒアリング
利用している場合は、リスクアセスメントを実施してもらう

非コアサービスの利用を組織部門の機能を使って許可を行い把握に努めている場合は、利用している非コアサービスに絞ってヒアリングを行えばよいですが、ペパボのテナントでは一部の非コアサービスを除いて、テナント全体への許可が実施されていました。したがって、全社に向けて協力を依頼することになりました。これはテナント運用のケースによって対応が異なると思います。

しかし、この対応を行ってもまだ不安が残りました。非コアサービスによっては、サポート窓口、あるいは担当者にプライマリドメイン変更に伴う影響があるかの知見が不足している場合があったためです。そもそも、Google Workspaceと非コアサービスは別サービス扱いになっていることが問い合わせを進めている中でわかってきたので、別の対応策を合わせて実施してリスク低減を行いました。

Google Workspaceのプライマリドメインを変更して非コアサービスに起こる影響として最も想像がしやすいのは「非コアサービスに今までと同じようにログインできなくなる」ということでした。非コアサービスのいくつかの利用状況を考えると、プライマリドメインと関連がありそうなのはユーザのプライマリメールアドレスを変えることで別のユーザとして扱われることから波及する影響だろうという推測が成り立つと考えました。したがって、別のGoogle Workspaceのテナントを用意し、各事業部向けにログインができなくなったときのための回避用のアカウントを作成、非コアサービスのプロジェクトに管理者として追加してもらうことで、万が一ログインできなくなった際に管理者としてログインし復旧作業に当たれるようにしました。

いざ、プライマリドメイン変更

ここまで準備をし、十分に先述のメールダウンタイムについての告知を周知した上でプライマリドメイン変更を実施しました。メールへの影響を最小限にするために、休日夜間の実施にしました。

結論から言うと、1回目のプライマリドメイン変更は失敗に終わっています。どのようなことが起こったのか、事例の一つとしてご紹介します。

ドメインエイリアス解除〜セカンダリドメイン登録

pepabo.com はドメインエイリアスとして登録されていたため、セカンダリドメインとして登録し直す必要があります。

まずはドメインエイリアスの削除です。問題なく削除できます。

domain_alias_delete

ちなみに、すぐにセカンダリドメインとして登録し直そうとするとエラーになります。これは想定内なので特に焦ることもなく待ちです。

invalid_secondly_domain

しばらくすると登録しなおせました。gmailを有効化する手順もすんなりと自動的に検証済みまで進みました。

enable_gmail

次は管理コンソールのドメイン管理画面からプライマリドメイン変更を実行するだけですが、ここでエラーが出ました。

faild_change_primary_domain

ちなみに、ペパボのGoogle Workspaceテナントはこのエラーメッセージに記述された失敗の原因のどれにも該当していません。しかし、元々セカンダリドメインとして登録し直したドメインがプライマリドメインに昇格できる様になるのに最大24時間かかる想定だったので、「24時間待ちの時間かな…」と考え、長丁場に備えて仮眠をとったりしながら待っていました。しかし、翌朝になっても登録できる気配はありません。

元々24時間の待ちは想定していたので、特に問題があるわけではないのですが、エラーメッセージが引っかかります。単にセカンダリドメイン登録から24時間経っていないからというより、元々このテナントではプライマリドメイン変更ができないかのような書き方がされています。

もしかして、CEGが把握していないだけで事業部門Googleライセンスのリセラー契約をしているのではないか、などの考えがよぎります。だとすると、このエラーメッセージをもってGoogleのサポートに問い合わせて、プライマリドメイン変更を仕切り直すほうが得策に思えてきました。

ここで、取れる手は3つあります。

セカンダリドメインから pepabo.com の登録を削除、ドメインエイリアスとして登録し直し、すべての設定をロールバックする
プライマリドメイン変更を強行する
どうにかしてセカンダリドメインの登録をした状態で、プライマリドメイン変更作業前と同じ利用ができるようにテナントの設定を変える

セカンダリドメインからドメインエイリアスにロールバックするのは、それをしたからといってGoogle Groupsなどに起こった変化がロールバックするわけではない（Google Groupsのメンバーはドメインエイリアスの登録が削除された場合、エイリアス先のドメインのメールアドレスに置換されます）ので、他のところで影響が出るかもしれません。

プライマリドメイン変更の強行はどうでしょうか。失敗すると事業に影響を与えかねないため、迅速に判断する必要があります。気持ちとしては、強行してしまいたい思いが募っていましたが、とにかくメールのダウンタイムをどうにかしたいです。裏を返せば、メールのダウンタイムさえどうにかすれば3で望まれている「プライマリドメイン変更作業前と同じ利用ができる」状態になります。

メールのダウンタイム回避

元々ダウンタイムは予定しており、まだ時間はあったのでどうにかする方法を考えます。まず、ユーザのメールアカウントの状態はこの様になっていました。

after_deleted_domain_alias_user_settings

元々、 pepabo.com の方のメールアドレスはユーザ自身のGmail設定でエイリアスとして登録されていましたが、それが解除されているようです。ドメインエイリアスとして pepabo.com が登録されている状態であれば、ユーザ自身のGmail設定でエイリアスとして登録されていればメールの送受信が可能でしたが、それができない状態になっていました。

しかし、実は管理コンソールから「予備のメールアドレス（メールエイリアス）」として pepabo.com のメールアドレスを追加すると送受信が可能になります(画像はプライマリメールアドレス変更後のため、ドメイン部分が旧プライマリドメインの paperboy.co.jp になっています)。ちなみに、Google Groupsにも同じ設定項目があります。

alias_address

つまり、全ユーザ、グループの「予備のメールアドレス（メールエイリアス）」を追加すれば、メールのダウンタイムを一旦抜けることができます。

とはいえ、500人近いユーザと、 pepabo.com ドメインのGoogle Groupsすべてにこの設定を手動でやるのは骨が折れます。そこで、「こんな事もあろうかと」準備していたスクリプトの出番です。

require 'google/apis/admin_directory_v1'
require 'google/apis/gmail_v1'

ENV['GOOGLE_APPLICATION_CREDENTIALS'] = './user_alias.json' #ドメイン全体の委任の権限を持っている必要がある

scopes = [
  'https://www.googleapis.com/auth/admin.directory.domain',
  'https://www.googleapis.com/auth/admin.directory.customer',
  'https://www.googleapis.com/auth/admin.directory.user',
  'https://www.googleapis.com/auth/gmail.settings.basic',
  'https://www.googleapis.com/auth/gmail.settings.sharing'
]

user_primary_mail_address = "josys_admin@old.example.com"
domain = "old.example.com"
alias_domain = "new.example.com"

authorization = Google::Auth.get_application_default(scopes).dup
authorization.sub = user_primary_mail_address
authorization.fetch_access_token!

directory_service = Google::Apis::AdminDirectoryV1::DirectoryService.new
directory_service.authorization = authorization

list_users = directory_service.list_users(domain: domain)
users = list_users.users

while list_users.next_page_token.nil?.!
  list_users = directory_service.list_users(domain: domain, page_token: list_users.next_page_token)
  users.concat(list_users.users)
end

users.each do | user |
  alias_email_address = "#{user.primary_email.split("@").first}@#{alias_domain}"
  puts user.primary_email
  unless user.aliases.nil?
    next if user.aliases.include?(alias_email_address)
  end

  a = {primary_Email: user.primary_email, alias: alias_email_address}
  alias_email = Google::Apis::AdminDirectoryV1::Alias.new(a)

  directory_service.insert_user_alias(user.primary_email, alias_email)
end

Google Groups向けには以下のスクリプトを利用しました。

require 'google/apis/admin_directory_v1'
require 'google/apis/gmail_v1'

ENV['GOOGLE_APPLICATION_CREDENTIALS'] = './google_credential.json' #ドメイン全体の委任の権限を持っている必要がある

scopes = [
  'https://www.googleapis.com/auth/admin.directory.domain',
  'https://www.googleapis.com/auth/admin.directory.group'
]

user_primary_mail_address = "josys_admin@old.example.com"
domain = "old.example.com"
alias_domain = "new.example.com"

authorization = Google::Auth.get_application_default(scopes).dup
authorization.sub = user_primary_mail_address
authorization.fetch_access_token!

directory_service = Google::Apis::AdminDirectoryV1::DirectoryService.new
directory_service.authorization = authorization

list_groups = directory_service.list_groups(domain: domain)
groups = list_groups.groups

while list_groups.next_page_token.nil?.!
  list_groups = directory_service.list_groups(domain: domain, page_token: list_groups.next_page_token)
  groups.concat(list_groups.groups)
end

groups.each do | group |
  alias_email_address = "#{group.email.split("@").first}@#{alias_domain}"
  puts group.email
  unless group.aliases.nil?
    next if group.aliases.include?(alias_email_address)
  end

  a = {primary_email: group.email, alias: alias_email_address}
  alias_email = Google::Apis::AdminDirectoryV1::Alias.new(a)

  # Google Workspaceによって予約されているメールアドレスは追加できないため、失敗することがある
  begin
    directory_service.insert_group_alias(group.email, alias_email)
  rescue => e
    puts e
  end
end

これに追加で、下記を準備してください。

Ruby 3.0.2が動く環境
GoogleAPIのRubyラッパーgemをgem installしておく（Gemfileを置いても良い）
ドメイン全体の委任設定をしたAPI認証用のサービスアカウント

これらを実行し、ユーザとGoogle Groupsに name@pepabo.com 相当の予備のメールアドレス（メールエイリアス）を追加しました。注意点として、このスクリプトはGoogle APIの非同期処理を考慮していないので、件数次第では複数回実行しないと漏れが生じる可能性がありますが、問題なく追加することができました。

このスクリプトの実行によって、ひとまずプライマリドメイン変更作業前の状態にロールバックする必要がなくなり、メールのダウンタイムを解消することができました。

なぜプライマリドメイン変更ができなかったのか

さて、メールのダウンタイムを解消したところでなぜプライマリドメイン変更ができなかったのかを調査しました。サポートに聞いてみたところ、ペパボのテナントではChromeデバイスのライセンスが有効になっており、その状態ではプライマリドメイン変更ができないという回答でした。

確かに、ヘルプページを見ると下記のような記述があります。

注: Google Workspace for Nonprofits、Chrome デバイス管理ライセンス、Chromebox for meetings のいずれかをご利用のお客様、または Google Workspace の正規販売パートナーの方は、推奨の対応方法についてサポートまでお問い合わせください。

できない条件には目を光らせて、サポートにも今のテナントの状態でプライマリドメイン変更はできるのか？という問い合わせをした際に、できるという回答を得ていたため油断していました。確かに、推奨の対応方法を取ればプライマリドメイン変更は可能であるため可能という理解はあっているのですが、Chromeデバイスのライセンスがある状態だとプライマリドメイン変更はできません。

プライマリドメイン変更に再トライする

プライマリドメイン変更に再トライするために、Chromeデバイスのライセンスを一時的に削除する必要があります。そのためにはまずすべての機器をデプロビジョニングする必要がありました。比較的出社が増えていたものの、COVID-19の感染対策のために会議室を用いる機会が減っていたため、設置しているMeetデバイスが使用不可になる影響は軽微であろうと考えられました。Chromebookをメイン端末として利用しているケースもなかったため、予定して進めました。

なお、少なくともペパボでプライマリドメイン変更を実施したときはChromeデバイスのライセンス削除・再付与はサポート窓口ではなく、別部門の担当者が対応していたため、非常に時間がかかりました。クリスマス休暇のシーズンなのもあったかもしれませんが、1週間程度使えない期間を想定したほうが良さそうでした。

さて、2回目のプライマリドメイン変更時のテナントの環境を改めて整理します。

Chromeデバイスのライセンスをすべて削除してもらった状態
すべてのユーザとGoogle Groupsの予備のメールアドレス（メールエイリアス）に新しいドメインのメールアドレスを追加済み
新しいプライマリドメインはセカンダリドメインとして登録済み

この状態で、プライマリドメインの変更、その後プライマリメールアドレスの変更を行います。

primary_domain_change

ポチッと押すだけですぐ終わりました。

次に、プライマリメールアドレスの変更を行いました。プライマリメールアドレスのアップデートにはいくつか方法がありますが、最も手軽な管理コンソールからCSVをアップロードする方法を用いました。ここまでの作業で、ペパボのGoogle Workspaceのテナントにはすでに予備のメールアドレス（メールエイリアス）に新しいプライマリメールアドレスが追加されている状態です。その状態で、「New Primary Email」カラムに新しいプライマリメールアドレスを追加してアップロードすると、旧プライマリメールアドレスと予備のメールアドレス（メールエイリアス）がスイッチするような挙動になりました。また、プライマリドメイン変更、プライマリメールアドレス変更どちらにもメールのダウンタイムはありませんでした。

今回のペパボのテナントで言えば、「New Primary Email」には username@pepabo.com を指定することになります。また、アップロード時の変化は下記のようになります。

before
- プライマリメールアドレス： username@paperboy.co.jp
- 予備のメールアドレス（メールエイリアス）： username@pepabo.com
after
- プライマリメールアドレス： username@pepabo.com
- 予備のメールアドレス（メールエイリアス）： username@paperboy.co.jp

プライマリドメイン変更の影響

プライマリドメインそのものが変更されたことによる影響は、結論ほぼありませんでした。少なくとも、変更から数週間たった今、確認できていません。ただし、プライマリドメインを変更するにあたって発生するメールのダウンタイムがもとで、いくつかのSaaSから送付されるメールがバウンスされ、バウンスリストに登録された結果メール通知が来なくなるという事象がありました。事前に案内をしていたこともあり、事業部のエンジニアの協力により解決に至りました。

プライマリメールアドレス変更の影響

実は、プライマリドメイン変更そのものよりそれに付随して行われることの多いプライマリメールアドレスの変更のほうが影響が大きいです。下記のような影響がありました。

Google Groupsのメンバーのメールアドレスが変わるため、josefで管理しているYAMLに差分が出た
Googleカレンダーの共有設定が初期状態になった
仕事用プロファイルをインストールしている端末の一部に影響が出た
- 仕事用プロファイルが削除された端末があった
- 再ログインを要求されただけの端末もあった
Google Cloud Platformのユーザのプライマリメールアドレスも変更される
- terraformなどで管理している場合、 terraform plan の出力を注視したほうが良さそう
- 適宜古いプライマリドメインが含まれる箇所を置換すればさほど大きな対応はなさそう
Googleアカウント認証でSaaSでログインできないものが発生した
- 問い合わせで解決した
- 内製でGoogleアカウント認証を実装しているケースでユーザのプライマリメールアドレスのドメイン部分を見る処理をアップデートする必要があった

今プライマリドメインを変更するならどうするか

随分長いエントリになってしまいました。しかし、ここまで読んでくださった方でこれからプライマリドメインを変更しようという方は、「で、結局どうすんのがいいわけ」となってるんじゃないかなと思います。

なので、今もう一度プライマリドメインを変更するならどのような計画を作るのか、ざっくり残しておこうと思います。あくまで2021年12月時点の、GMOペパボのGoogle Workspaceのテナントで得た知見を元にこのようにするだろうというものですので、各テナントごとに読み替え・追加調査などはして頂く必要があること、Google Workspaceのアップデートで全く違った挙動になりうることを前提に読んでいただければと思います。また、文中の日時は仮でわかりやすいのを置いています。

前提とするGoogle Workspaceのテナント

ヘルプ記事にあるプライマリドメイン変更条件を満たすこと
新プライマリドメインはドメインエイリアスであること（セカンダリドメインの場合はセカンダリドメインに変更後から読むと良いと思います）
Chromeデバイスのライセンスがあること（無いならChromeデバイス関連の項目をすべて無視していいです）
- ここではChromeBoxとします

各種サービスへの影響

Gmailにて、切り替え先のメールエイリアスのドメインに紐付いたメールアドレスでのメールの送受信が30分〜1時間程度（ユーザとGoogle Groupsの件数による）できなくなります。したがって、該当する時間にメールがダウンすることを案内する必要があるでしょう。
Chromeデバイスの利用がChromeデバイスのデプロビジョニング〜プロビジョニングまでの間できなくなります。したがって、会議室のChromeBoxに利用不可な時間が生じることを案内します
その他、先述の影響について書いた項目について対処・共有し、何か起こった際は対応してもらうように案内します

前準備

メールのダウンタイム、非コアサービスへの回避用アカウントの追加を計画する
1. プライマリドメイン変更メンテナンス開始日時を決定します
2. ここでは仮に 6月3日（土）20時から実施することとします
Googleのサポートに連絡の上、Chromeデバイスのライセンスがあるテナントでプライマリドメインを変更したい旨を伝える
1. Chromeデバイスのデプロビジョニングを実施する日時を決めます。デプロビジョニング後、Googleでライセンス削除の対応を実施する必要があるため、6月2日（金）17時にデプロビジョニングを開始、18時には完了しGoogleに連絡することを前提とします（事前にそのように計画していることを伝えておくのが良いでしょう）
2. USのエンジニアが対応する場合時差があるため、1日置いています

計画概要

プライマリドメイン変更メンテナンス準備
- 6月2日（金）17時 Chromeデバイスのデプロビジョニング実施（Chromeデバイスダウンタイム開始）
プライマリドメイン変更メンテナンス
- 6月3日（土）20時ドメインエイリアスをセカンダリドメインに切り替える（新プライマリドメインになる予定のドメイン宛メールダウンタイム開始）
- 6月3日（土）21時予備のメールアドレス（メールエイリアス）追加完了（新プライマリドメインになる予定のドメイン宛メールダウンタイム終了）
- 6月3日（土）22時プライマリドメイン変更開始
- 6月4日（日）22時プライマリドメイン変更完了、サポートに連絡
プライマリドメイン変更後対応
- 6月5日（日）22時〜Chromeデバイスライセンスを再付与完了後、プロビジョニングを実施（Chromeデバイスダウンタイム終了）

Chromeデバイスのライセンス再付与のみ、Google側の作業となりアンコントローラブルなためぼかしていますが、なるべく長めにダウンする可能性を考慮しておくと間違いなかろうと思います。

6月2日（金）17時 Chromeデバイスのデプロビジョニング実施

デプロビジョニングを行います。基本的に管理コンソールからの操作で完結しますが、まれにデプロビジョニングしてもうまくステータスが反映されないことがあります（古いChromeデバイス特有の動作かもしれません）。先述の通り、Googleのサポートと連携しライセンス削除を依頼します。

6月3日（土）20時ドメインエイリアスをセカンダリドメインに切り替える

ドメインエイリアスをセカンダリドメインに切り替えます。この際、メールのダウンタイムが開始されます。セカンダリドメインへの登録が済んだら次へ行きます。

6月3日（土）21時予備のメールアドレス（メールエイリアス）追加完了

先述のスクリプトを利用して全てのユーザとGoogle Groupsに予備のメールアドレス（メールエイリアス）を追加します。これが完了するとメールのダウンタイムが終了します。

6月3日（土）22時プライマリドメイン変更開始

先述のChromeデバイスのライセンスが適切に削除されている前提です。プライマリドメインを変更します。

6月4日（日）22時プライマリドメイン変更完了、サポートに連絡

プライマリドメインが変更できたら、プライマリメールアドレスを変更します。公式のヘルプ記事にある通りCSVアップロードで実施します。先述の通り、予備のメールアドレス（メールエイリアス）に変更後のプライマリメールアドレスが設定されている場合、変更前のプライマリメールアドレスとスイッチする動作になるのでメールのダウンタイムはありません。

また、Googleのサポートにデバイスのライセンスを復旧するように依頼します。ペパボでは12月のクリスマス休暇シーズンだったせいか、時間がかかりました。ケースバイケースだと思われます。

6月5日（日）22時〜Chromeデバイスライセンスを再付与完了後、プロビジョニングを実施

デプロビジョニングしたデバイスのプロビジョニングを実施しましょう。

ここまでできたら、プライマリドメインの変更メンテナンス完了になります。

まとめ

プライマリドメイン変更を実施した流れ、起こったトラブルや影響、それを元にしたもしもう一度プライマリドメインを変更するとしたらどうするかについて記述しました。

元々、プライマリドメイン変更の際にメールのダウンタイムは最大72時間30分を想定していました。（内訳はドメインエイリアスからセカンダリドメインへの切り替え30分、セカンダリドメインからプライマリドメインに変更できるまでの時間24時間、プライマリドメイン変更にかかる最大時間48時間）しかし、今後実施する場合、セカンダリドメインへの切り替え後すぐに予備のメールアドレス（メールエイリアス）への追加を実施することでメールのダウンタイムを解消できるため、実質的にメールのダウンタイムを70時間ほど短縮することができる事がわかりました。メールのダウンタイムが72時間だと許容できなくても、1〜2時間ほどであれば許容できる企業も多そうに思います。

なかなか実施することのないプライマリドメイン変更作業なので、私がこれから対応することがあるかはわかりませんがこれを読んだプライマリドメイン変更を計画している情シスのエンジニアの助けになれば幸いです。

メニュー

最新記事

リンク

Google Workspaceのプライマリドメイン変更を実施しました

プライマリドメインをどうして変更するのか