Microsoftアカウントと組織アカウントの違いについて

MSのアカウント管理はややこしいなーと思うのでメモです。

AzureやらOffice365やらを使う時に「あなたのアカウントはMicrosoftアカウントですか?それとも組織アカウントですか?」と聞かれる。

Microsoftアカウントとは?

一般市民がGmailYahoo!メールで登録できる、普通のアカウント。私的なアカウントというか。Googleで言うと、そのまんま”アカウント”となる。

組織アカウントとは?

Microsoftクラウドサービスを利用している会社が発行するメールアドレスで、登録したアカウント。

例えば、株式会社TESTがOffice365を使用するとして、xxx@test.comというドメインでOffice365を利用したとする。この時、当然Microsoftは@test.comのドメインで登録されたメールアドレスはMicrosoftのサービスを利用しているということを知っている。なので、@test.comを持つメールアドレスは、組織アカウントとして登録する権利を持つ。

一方、@gmail.comや@yahoo.comというドメインのメールアドレスは、Microsoftの辞書にない。あるいは、Unixベースのメールシステムを使用している@oracle.comというドメインも(有名ではあるが)Microsoftの辞書にないため、組織アカウントとして登録することが出来ない(※1)

Microsoftが”組織アカウント”と”Microsoftアカウント”に分けている理由、もうちょい言えば”組織アカウント”なる定義を作っている理由だが、例えばMicrosoftのゴールドバートナーの会社に特典を付与する場合、その会社の組織アカウントでMSのサイトにアクセスする必要がある、などMicrosoftの管理上の問題といえる。つまりMSの都合。

使う側にとっては、必ずしも組織アカウントで登録する方がいい、とはいえず、Microsoftアカウントでしか出来ないようなアクションもある。とはいえ、MSのゴールドパートナークラスの会社なら、同じAzureを使うにしても組織アカウントで使っといたほうが何かといい(この会社の従業員はMSにお布施してくれてるな、というのが分かる)ような気がする。

ちなみに

  1. とある会社はMicrosoftのサービスを使っていない
  2. 従業員がその会社のメールアドレスをMicrosoftアカウントとして使用
  3. とある会社がMicrosoftのサービスを使用開始し、メールアドレスが組織アカウントして登録可能になる

このケースの場合、2で会社のメールアドレスをMicrosoftアカウントとして登録してしまった人はどうなるかというと、そのアカウントは一生Microsoftアカウントとなり、組織アカウントには登録できなくなる。それが私なのだが、救済策として、表示上はMicrosoftアカウントだが、特典などは組織アカウントと同等に受けられるようになる。

ややこしいのは、ドメイン自体は組織アカウントなので、「あなたのアカウントはMicrosoftアカウントですか?それとも組織アカウントですか?」と聞かれて組織アカウントを選択した場合、そもそもアカウント自体が存在しない扱いのため一生ログインできないというハメに合う。そのハメに合ったため、この記事を書いている。

自分用メモ

  1. イニシャル@xxx.com 組織アカウント。O365にログインして各種サービスを使えるのはこれ。
  2. イニシャル@xxx.co.jp Microsoftアカウントだが実質組織アカウントでいろんな権限が付与されている。パスワードは大文字7桁+1(どうやら同盟の組織アカウントも存在していることになるらしい?)
  3. 名.姓@xxx.com 1のエイリアスであるが、Azure利用上は1と違うアカウントになるぽくてよく分からない。Microsoftアカウントぽい。
  4. xxx@gmail.com クリーンなMicrosoftアカウント

※1 正確に言うと、AzureADにドメインを登録していれば、Microsoftに課金していなくても組織アカウントとして認められそうだが、ここらへんは試していないのでよくわかりません。

Office365のIMAP移行を試す話

Postfix + Devecot環境のメールシステムからOffice365への移行をすることになった。Office365のIMAP移行というのはよー分からん、ということで、試しにGmailのテストアカウントからOffice365への移行を行うことにした。

prius.hateblo.jp

環境

Office365の新規テナント契約

  • exoadmin@tokyoppp01.onmicrosoft.com
  • よく使われる8文字

テスト用Gmailアカウントの取得

  • tokyoppp01@gmail.com
  • よく使われる8文字 + 自分用7文字の5~大文字

IMAP移行バッチの作成

以下のマニュアルを参考に、移行バッチの作成を行う。

注意点は以下。

  • 2016/7/19時点では、新管理ポータルはプレビュー版なので、GUIからやる時は旧ポータルを使用する
  • おそらく、一度移行エンドポイントを作成後(今回の場合、GmailへのIMAP接続)は、2回目移行の利用でそれを利用できるので手順が異なる
  • 移行バッチには最大同期数の制限(100?)があるらしいので、抵触しないようにする
  • とはいえ、100以上のユーザーを同時に同期状態にするとネットワーク負荷が高くなりそうなので、順次移行を検討するのがよい。
  • 例:ユーザー数1,000人の場合、50人単位で移行バッチを実行し、同期が終了したら元メールシステムに転送設定を入れ、IMAP移行バッチ自体は解除する、など。
  • その他、移行できるアイテム数と1アイテムあたりの容量に制限があるので注意

結果

ほとんど空っぽなテストユーザーのデータが3分ほどで同期状態となった。この後は、24時間に1回くらいの頻度で差分同期が走るらしい。
つまり、これは大事なことなのだが常に元のメールシステムのデータが正であるということ。

実際の現場では

  1. 同期バッチ完了
  2. 元メールシステム→新メールシステムへの転送開始
  3. 24時間後の同期完了
  4. 同期状態解除

の順番でないとと、漏れるメールが発生する。3が終わってから4するのが大事。

こう考えると、移行バッチはユーザー1名1名単位で実装るのがよいか。1バッチ中の人数が多ければ細かい転送設定制御ができず、ネットワークトラフィックに無理が出てしまう…。

コマンドライン

以下の様なものが用意されているらしい。

  • Complete-MigrationBatch
  • Get-MigrationBatch
  • Get-MigrationConfig
  • Get-MigrationEndpoint
  • Get-MigrationStatistics
  • Get-MigrationUser
  • Get-MigrationUserStatistics
  • New-MigrationBatch
  • New-MigrationEndpoint
  • Remove-MigrationBatch
  • Remove-MigrationEndpoint
  • Remove-MigrationUser
  • Set-MigrationBatch
  • Set-MigrationEndpoint
  • Start-MigrationBatch
  • Stop-MigrationBatch
  • Test-MigrationServerAvailability

New,Remove,Set,Start,Stopは手動でやるとして、Get系はエビデンスを取得するために使えそう。あとはTestか。

追加検証

GB単位のGmailアカウントはどれくらいで移行できるんだろう?と興味があったので今やってます。