ども。こんばんは。
気づけばもう連休もあと1日半です・・・。
昨日はずっと寝てたのと、今日も夕方まで寝てしまったので、さっさと続きをやります。
とりあえず、前回の残タスクの通り、ライセンス節約のため個人メールボックスを共有メールボックスに変換します。
やり方はこんな感じ。
- 変換するユーザーメールボックスには、共有メールボックスに変換する前に割り当てられたライセンスが必要です。 そうでない場合、変換オプションがメールボックスに表示されません。ライセンスを削除した場合、メールボックスを変換するために再度それを戻す必要があります。 ライセンスは、メールボックスを共有に変換した後に、ユーザー アカウントから削除できます。
- 共有メールボックスは、ライセンスなしで、最大 50 GB のデータを保持することができます。 これ以上のデータを保持するには、ライセンスを割り当てる必要があります。 ライセンスを削除するには、(添付ファイルがあるものなど) 大きなメールを多数削除してサイズを小さくする必要があります。
古いユーザー アカウントは削除しないでください。 それは共有メールボックスの固定に必要です。 ユーザー アカウントを既に削除している場合、「削除済みユーザーのメールボックスを変換する」 (削除されたユーザーのメールボックスを変換する) を参照してください。
ポイントとしては、上記の3点ですね。特に3つ目。読んでなかったら確実に消してたわ。
【追記：やらかした】
やかしました。多分大丈夫ですが、上記のサイトの下の方にこんなことが書いてあります。
もしかしたら、またユーザメールボックスに戻される・・・のかも？？？うーん・・・。まぁいっか。
強くお勧めするならもっと上に書いておいてほしかったです。。。
目次
ハイブリッド環境でユーザーのメールボックスを変換する
この共有メールボックスがハイブリッド環境にある場合は、ユーザーのメールボックスをオンプレミスに戻して、ユーザーのメールボックスを共有メールボックスに変換してから、共有メールボックスをクラウドに戻すことを強くお勧めします。
その理由は次のとおりです。クラウド内のメールボックスを変換すると、そのメールボックスは変換されますが、新しい現実はオンプレミスに同期されないため、オンプレミスではメールボックスがユーザーのメールボックスであると見なされます。
通常、これは問題ではありませんが、オンプレミスの属性 (メールボックスがユーザーのメールボックスであると考えられる) が新しいクラウドバージョンの属性を上書きする可能性があるため、その結果、メールボックスの変換が行われる場合があります。 ユーザーメールボックスがライセンスを必要とするか、30日後に削除された場合は、この問題が発生します。
これが発生する理由のほとんどが解決されましたが、これはまだ発生する可能性があります。 安全にして、メールボックスをオンプレミスに戻すことをお勧めします。
あと、やっぱりいきなり契約せず評価ライセンスではじめてほんとに良かった。移行するにしてもライセンスが最初は必要になるんですね。
ちなみに、ちゃんと ハイブリッド構成にしたおかげて？権限も移行できてるので、ちゃんとメインで使う予定のユーザは他のメールボックスを開くことはできます。(フルアクセセスを与えており、ちゃんと引き継がれた。さすがハイブリッド！)
でもやりたいのはこうじゃないし、それぞれのボックスの所有者でログインしたり、それぞれの予定表を作る予定もなく、あくまで、システム通知やSNS系のメールの受け用のボックスがほしいのです。
で、後悔しないように改めてこちらの記事も読んでみました。うん、今回はやっぱり共有メールボックスが正しい・・はず！
■ユーザメールボックスを共有メールボックスに変換する
早速やってみます。
Exchange管理センターから該当メールボックスをポチッと。
はいはい。
即効でおわります。数秒。
この時点では、ライセンスを停止してない？ので、まだ元のメールボックスの所有者でログインしてOWAでメールが見えるっぽいですね。
もう一つ変換対象があるので、そっちも同様の手順でやります。(10GBくらいあるボックスだったのですが、2分くらいで終わりました。)
無事共有に変換できました。
とりあえず、OWA上で追加してみる。
メインのアカウント上で自分の名前を右クリックして「共有フォルダーの追加」をクリックします。
あとは選ぶだけ。(「他のメールボックスを開く…」と要領は同じですね。)
最終的にこんな感じになりました。
とりあえず、送受信テストしてみます。
あれ、差出人が共有メールボックスにできないですねー。
うーん。フルコントロールなんだけどなー。
一応権限つけてみました。
だめですねー。候補に出てこない。
念の為、「他のメールボックスを開く…」でやってみたところ・・・・
このメールボックスからメッセージを送信するためのアクセス許可がありません。
えー。うそんフルコンやし、ちゃんと送信する権限もつけたけどなー。反映に時間かかるのかなー。
まぁいいわ。別に。そのうちなんとかなるでしょう。「メールボックス所有者として送信する」の権限は必須ぽいので。
ちょっと先に進めます。
■ライセンスを剥奪して、サインインも禁止する！
これで、共有メールボックス化が無事できたので、旧ユーザからはライセンスを剥奪します。
あと、サインアップ時に作った「.onmicrosoft.com」もライセンス剥奪してみます。
また、ADから引っ越してきたユーザはパスワードがボロい可能性も大いにあるので、サインインも禁止します。
さらばライセンス。
ちなみにいいかどうか知りませんが、onmicrosoftのアカウントもライセンス剥奪しました。
これで、ライセンスを持っているのは1人のみになりました。
ちなみにライセンスを剥奪したユーザでログインしてみました。
おー、空っぽですね。
で、一応今回ADと同期してはいますが、余計なユーザはOffice365にサインインできないようにしてみます。
※onmicrosoft,comのユーザは念の為、ライセンスは剥奪しましたが、サインインは可能にしてあります。もちろん別で全体管理者は設定済み&サインアップ時の連絡先は、ライセンス付与済みユーザにしています。
【2019/05/05 追記】
勢い余って、Azure AD Connectに必要な同期用ユーザまでサインイン禁止にしてしまったみたいです。
なので、「Sync_[サーバ名]_[ランダム？]@hitsnetcom.onmicrosoft.com」はサインインを有効にしてあげたら治りました。
これでsyncしたら、ブロックしたユーザまたサインイン許可に戻ってしまった・・・。
うーん。やっぱりAD側でログイン無効化して同期させるのが正しいんだろうけど、やだなーこれ。課題ですね。
で、サインイン禁止したユーザで入ってみたところ。
※てかID・PWの確認はできてしまう気がする。。。。。。
↑これは反映中だったみたいです。しばらくするとこうなります。
とはいえ、アカウントの存在とパスワードが正しいことはバレちゃいますねこれ。まぁいいか。。
Azureも一緒にかわるっぽい？(←もともとこのユーザサインインできてたか未確認です)
さぁ、だいたいできた。
■正規のライセンスを買って割り当てる
まだ評価期間は残っていますが、このっている今だからこそ正規版を買います。
※そしたら、何かあっても、最悪評価版に割り当て直して調査できる猶予がある！はず・・・。
いきなり１年契約でかいます。
住所とかを入れます。
年間¥6,998です。
何故かシークレットモードのブラウザだと手順3にいけませんでしたのでやり直し。。。
支払い方法を入れます。
かいましたー。
無事追加。
ライセンスを割り当て直します。
試用版をoffにして購入した方をonにします。
個別の機能でのon/offもできるんですね。
できましたー。
ちゃんとライセンス数が更新されていますね。
一応請求書などのメール連絡先も確認します。
予定通り、追加しておいた全体管理者が有効になっており、onmicrosoftの方の連絡先メールアドレスもライセンスのあるユーザになっています。
これならonmicrosoftにはライセンスなくても大丈夫・・・だと思います。
おまけ。ライセンス変更前後のサインイン後の画面。
ちょっとへりました。
■仕上げ：DNSレコードの変更(外部向け)
さて、ここまででもう準備は終わったのでいよいよDNSレコードの向き先を変えます。
とりあえず、CSVでエクスポートもしていたのですが、MXとCNAMEをいれます。
途中の画面を取り忘れましたが、チェックする機能があります。
終わったら確認を押すと以下のようにOKになります。
管理のドメインから状況が確認できます。
おっと、一つカスタムドメインのDNS設定が漏れていましたね。困りはしないのですが一応いれます。
使うサービスを選びます。(これによって向け先に出てくるレコードが変わるみたいですね。Exchangeなら基本MXとautodiscover用のCNAMEとSPFだけとか。)
Exchangeだけえんだので、3つだけです。
※ただし、見切れてますがこの画面上にあるエクスポート機能でエクスポートすると全サービス分のレコードがCSVででてきます。
はい。おわりました！
ちなみに今回SPFレコードは、Office365に加え、自宅の固定IPアドレスも残しています。
それでもチェック結果はOKだったので問題ないと思われます。
■仕上げ：DNSレコード+Postfixのtransportの変更(内部向け)
ここからは内部向けの話なので、関係ない人はここまでで晴れてOffice365ユーザとして利用可能になります！
さて、うちの場合は、
内部DNSサーバのMXレコード修正と、内部用メールをtransportでオンプレExchangeに向けている部分を修正します。
ありふれた手順なので省略します。reloadとかpostmapとか忘れないでね。
ということで、経路がこうなりました。
(この辺ももうリプレースしないとですね。)
内部サーバ->オンプレExchange->ハイブリッド構成->o365
内部サーバ->o365
※ここはTLSにしたいところだけど、面倒くさいのでやめました。
ちなみに、これは主に内部サーバのシステム通知系なので、自ドメイン以外には送信しません。
※内部ですけど、外から来るメールと同じ扱いにしました。
【メモ】
Zabbixの通知先に携帯キャリアメールが入っている。今はオンプレPostfixにSMTPを向けているがこれをo365に変更するときは、うちでも設定が必要。
各種サーバは全体的にSmartRelayでo365にむけないとなぁ。
なので、o365用のMXレコード宛に送りつけるだけです。自ドメイン以外の外部に送る場合は、認証がいるはずです。
この辺を参考にしてみてください。
Office 365 を使用してメールを送信するように多機能デバイスまたはアプリケーションをセット アップする方法
※昔は性的なグローバルIPアドレスを認証条件にできたけど、いつからかTLSで証明書入れるの必須にならなかったけ。
さて、あとはインターネットからメールサーバ宛の25/tcpを閉じれば終わりですね。
TTLも300だしもうとっくに伝播したと思いますが、一応旧メールサーバのmaillogを流しながら、全アドレスにテストメールを送信して、旧サーバに回っていないことを確認しました。
というかこの時点でもまだ、差出人が共有メールボックスにできないです。この記事を書いている間に数時間経過したのですが・・・。まぁそれは別の課題で。。。
ということで、一旦終わりです。
あとは細かなタスクとして・・・
- macOSのメールアプリで共有メールボックスにアクセスする
- 古いサーバのメールの向き先変更(snmptrapのメール変換とかもそろそろやめたい・・・)
- Zabbixの通知メールサーバ変更(宛先にキャリアメールが入っているので注意)
- 各種アプライアンスのメール通知先とか見直し
そんなところかな。あーWebサーバの移行できるかなぁ。
【バックナンバー】
- 令和になったことだしクラウドへ移行する – 1 – 全体方針
- 令和になったことだしクラウドへ移行する – 2 – Exchange Server 2010 to Office 365(1)
- 令和になったことだしクラウドへ移行する – 3 – Exchange Server 2010 to Office 365(2)
- 令和になったことだしクラウドへ移行する – 4 – Exchange Server 2010 to Office 365(3)
ではでは。またの機会に。