オンプレミスの電子メールサーバから Office365 への移行
野口 宏 1), 大瀧 保広 1), 鎌田 賢 1),2)
1) 茨城大学 IT 基盤センター
2) 茨城大学 工学部 情報工学科{noguchi, y.ohtaki, m.kamada}@mx.ibaraki.ac.jp
概 要：茨城大学 IT 基盤センターでは、教職員及び学生に電子メールのサービスとして、これまで学内に電子メールサーバを用意して運用してきた。現在、このサービスを、マイクロソフト社が提供する Office365 へ移行中である。移行手順として、短期的な利用者である学生と長期的な利用者である教職員とで異なる手順を採用したことを報告する。

1

はじめに茨城大学(以下、「本学」)では、従来、学内に電2

背景子メール用のサーバを用意し、本学構成員である

2.1 オ ン プ レ ミ ス の 電 子 メ ー ル サ ー ビ ス
本学のキャンパスは、図 1 に示す通り水戸,

教職員及び学生に電子メールサービス(以下、「従日立, 阿見の 3 地区に分かれている。殆どの 1 年来サービス」)を提供してきた。一方、Gmail に代生は水戸キャンパスにいるが、2 年生以上は表 1表される無料の電子メールサービスの利用容量は、に示した通りのキャンパスにいる。学生用の電子しばらく前までは想像できなかった程まで大容量メールサーバは演習用のサーバを兼ねているため、化してきた。これらには、クラウドサービスであ停電やキャンパス間ネットワーク断を考慮し、キるが故に、電気設備の法定点検等によるサービスャンパス毎にサーバを配置している。そのため、停止が起こらない等の利点もある。この様な背景

学部単位で利用するサーバを指定している。

から、本学でもクラウドの上の電子メールサービスの導入を検討し、マイクロソフト社のOffice365(以下、「O365」)を利用することとなった。
本稿では、現在進行中である本学におけるO365 への移行を報告すると共に、移行後の問題

表 1: キ ャ ン パ ス と 学 部
キャンパス

学部

水戸人文, 教育, 理

日立工阿見農点を明確にする。
一方、教職員用の電子メールサーバは、日立キャンパスに配置してあった。これは、管理母体である IT 基盤センターがそこにあるためである。
このため、電子メールアドレスのドメインは、学生はキャンパス単位で異なり、教職員はさらに別のドメインを利用していた。
電子メールのスプールは、学生は 1GB/人であるが, これは文書ファイル等と合わせての容量であるため，スプールが溢れ電子メールを受け取れなくなる者もいた。教職員のスプールは 3GB/人だ

図 1: キ ャ ン パ ス の 位 置

ったが、それでも足りないという意見があった。
それぞれの電子メールサーバでは、Web メールとして Active!mail を導入し、PC 上の MUA を利用しないユーザの利便性を図っていた。迷惑メール対策として SPF, DKIM を導入するとともに、ウィルスチェックもサーバ上で行っていた。
以前から教員個人による電子メールサーバの運用は登録制としてあり、OP25B やサブミッションポートの利用も対応してきた。

2.2 移 行 に あ た っ て の 必 要 条 件
従来メールを移行するにあたり、本学としての新メールシステムに対する必要条件は次の通りであった。
a.

Web メールb.

スプールの容量増c.

法定点検等による停電に影響されない

d.

安価

e.

国内法の適用対象

f.

キャンパスに依存しないドメイン名g.

迷惑メール対策h.

ウィルスチェック

検討した結果、Office365 を選択することとなった。スプールが 50GB/人で、DKIM はないものの SPF やウィルスチェックが行われている。

図 2: ADFS の 配 置

4 移行計画
教職員は業務でメールを利用することから、そこでは学外秘の情報等もやりとりされる。このような情報を含む電子メールのサービスに学外のサーバを利用するという意識改革が必要であったた
め、学生と教職員のサービス移行にタイムラグが生じた。更に基本的には 4 年間の短期利用となる学生サービスの移行手順は、長期利用の教職員サービスには適さないため、別の移行計画を設定した。本章では、学生と教職員のサービスを分けて移行手順を述べる。

4.1 導 入 準 備

3 Office365 導入時の環境
本 学 で は 、 全 学 統 合 認 証 基 盤 と し て ActiveDirectory(以下、「AD」)を利用しており、O365の導入にあたっては学内の AD と連携をとって認既に全学統合認証基盤として、全構成員に一意に ID を付与したものを AD により管理を行っていた。この環境の下に 2013 年 3 月に 3 で証を行う ADFS 及び ADFS Proxy を導入した。

示した環境を構築し、約 1 年間関係者で運用のADFS 等を一つのキャンパスに設置すると、電気ための試行錯誤を行った。

設備の点検や落雷等による停電により、電子メールが利用出来なくなる危険性がある。このため、既に各キャンパスに配置した AD に加えて、ADFS及び ADFS Proxy を 2 つのキャンパスに配置した。
(図2) そ の 際 、 ADFS と ADFS Proxy は

4.2 学 生 サ ー ビ ス の 移 行
本学では、1 で述べた通り、学生番号及び所属キャンパスから生成される電子メールアドレNLB(Network Load Balancing)で同一 IP アドレスを付与している。基本的には学部生は 4 年間、スによる参照が可能となるように、同一セグメン大学院生はそれより短い期間の利用となるため、トに配置する必要がある。このため、広域イーサ

従来サービスと O365 の並行運用を行うこととネットで接続されたキャンパス間で tag VLAN をした。O365 の開始時期は 2014 年 4 月からであ構成した。

り、並行運用は現計算機システムのレンタル期

これにより、対外接続ネットワークに障害がない限り、自然災害等にも耐えうる O365 に対す間終了直前の 2016 年 2 月末までとした。(図 3)

る認証基盤を構築している。[2][3]

図 3: 学 生 サ ー ビ ス の 移 行

この 2 年弱の間に、学生は自身でサービス移行を行うこととした。具体的な作業は、(a)電子メールアドレス変更の友人等への周知と(b)従来サーバから新サービスへの電子メールの取り理由もある。
しかし、学生と異なり、教職員はそれまで長期間利用していたことや論文等に電子メールアドレスを記載していること等を考慮すると、並行運用の後に 1 年に満たない移行期間で従来サービスの込みの 2 点となる。メールサービスの移行では電子メールアドレスが利用出来なくなることは学

新サービスへの転送設定をすることが多いが、内の了解を得ることが出来ない。そのため、従来従来サービスで利用している Active!mail ではサービスからの切り換え後に、従来サービスの電電子メール転送時に envelope-from を書き換え

子メールアドレス宛のものも O365 において受信ないため、転送すると O365 において SPF チェックの際に拒否される危険性があった。そこで(b)に関しては、O365 の機能である『接続されするようにする必要があった。
以上より、次の 3 つの方針で移行を行うこととした。(A)O365 では従来サービスと異なるドメイン名とし、(B)従来サービスの電子メールアドレスているアカウント』を利用してもらうこととしも受信する。更に(C)従来サービスで受信していたた。これは、O365 が IMAP クライアントとな電子メールは O365 へ各自が取り込むものとする。

り、サーバとして従来サービスのサーバを指定(図 4)することにより、従来サーバから電子メールを取得するものである。取得は、これまでに着信していた電子メールだけでなく、新規に従来サーバで着信した電子メールも逐次取得の対象となる。そのため、従来サービスから O365 への転送をする必要がなくなった。
図 4: 教 職 員 サ ー ビ ス の 移 行
4.3 教 職 員 サ ー ビ ス の 移 行
4.3.1 シ ス テ ム と し て の 移 行
教職員サービスを移行することが学内で決まこの方針の下で次に示す手順で作業を行った。
①	  従来ドメインに関して、DNS 上で MX, A,ったのは、学生サービスの移行を開始してから半TXT レコードの削除及び確認年以上後であった。現システムのレンタル期間終②	  O365 上に従来ドメインの設定

了は 2016 年 3 月であるため、決まった時点です
ぐに移行作業を開始しても学内周知等の手続きを見込むと、移行期間は 1 年にも満たなかった。
前述の通り、本学における全学統合認証基盤は

DNS 上で MX, A, TXT レコードの追加③	  DNS 上で各レコード追加の確認が取れた
後に O365 上の各ユーザに対し従来ドメインの受信設定

AD を利用している。更に、eduroam での認証にO365 上にドメイン名が無い状態では③の作業関しても、RADIUS の認証サーバにも同じ AD をを行うことが出来なかった。そのため DNS 上で利用している。eduroam で指定するドメインと各レコードの追加の確認をした後に各ユーザの設O365 利用するドメインが密接に関係しているこ定を行わざるをえなかった。とと、eduroam におけるドメインを学生と教職員

これらの作業は通常営業時間には行うことがを共通にすることにより運用上の負荷を軽減する出来ず、また万が一作業に手戻りが発生することことを目的として、O365 における教職員のドメを考慮して、最も影響が少ないと思われるお盆のイン名は従来サービスから変更して学生と同一の一斉休業期間中に行った。事前準備を行っていたものとした。これには、セキュリティの観点から、ため、作業自体は最終確認を含め約 4 時間で終了

せめて教職員だけでも、認証 ID と電子メールアした。この時間のほとんどは O365 上に設定が反ドレスを独立させたいという要望を、ドメイン名映されるまでの待ち時間であり、オンプレミスの変更の際に実現させることが容易となる二次的なサーバであれば 30 分も掛からない作業であった

とも考えられる。

5.2 学 生 サ ー ビ ス の 現 サ ー バ 停 止
学生の移行は今年度 2 月まで継続して行わ

4.3.2 ユ ー ザ と し て の 移 行
移行後の学内の電子メールサーバは、送受信の機能は停止したが、IMAP のサービスは継続してれ、その時点で従来サービスのサーバを停止することになる。ほとんどの学生は O365 に移行いる。これは、これまで送受信した電子メールを、したようであるが、まだ従来サービスを利用し前述の O365 の機能である『接続されているアカている学生もいる。周知が届いていない学生にウント』を利用し、O365 に取り込めるようにすは、移行自体の情報が伝わっていない可能性もるためである。移行前に Web メール等を利用し電ある。その様な学生に対しては、教職員と同じ子メールをサーバ上に残していたユーザは、この機能により全ての電子メールを O365 に取り込むことが出来た。

ように従来サービスのドメイン宛の電子メールを O365 で受信出来るように設定を行う必要がまた、Web メールシステムである Active!mailあるかもしれない。但し、全ての学生に対して、上にアドレス帳を作成していたユーザに関しては、その設定を行うと逆に混乱する可能性もあるた

そのデータを O365 に反映させるためのマニュアめ、現在はその方針を検討中である。

ルとスクリプトを用意し、各ユーザ自身で作業を行ってもらうこととした。
アドレス帳の移行を含め今回の移行作業にあたっては、学内へ周知文の配布のみならず、説明会を移行以前及び移行後に約 10 回程度開催したため、大きな混乱は生じなかった。

参考文献[1] 野口他、BCP としての学内テータセンターの設置とその活用方針、学術情報処理研
究 No.18、pp.24-32、2014．
[2] 野口他、分散キャンパスを利用したファイ

5 今後の課題
移行は順調に行われたが、メーリングリス
トの運用継続という課題と学生サービスの現サーバ停止という課題が残っている。

ルバックアップシステム、学術情報処理研
究 No.16、pp.25-32、2012．
[3] Noguchi 他, Design and Practice of File

Backup System Taking Advantage ofRemotely

5.1 メ ー リ ン グ リ ス ト の 継 続 運 用
O365 では、メーリングリスト(以下、「ML」)の機能が無いようである。電子メールにはグループという機能はあるが、通常の ML とは次の点で異なる。グループを利用して送信した電子メールを受信者が確認をすると、送信先がグループ名ではなくグループに登録されたアドレスが全て列挙されている。通常の ML では、メンバーを相互に非公開にした配送が可能であるが、こうした使い方ができない。
このため、学内で mailman で運用していたML サーバを継続して利用することした。このため、電子メールサービスを完全には O365 へ移行することが出来ていない状況である。

Distributed

Campuses,

WSSM- 2015, pp.694-697, 2015.