データがコピーされていない！
最初のトラブルから2週間後，ようやく本来の移行作業を迎えた。しかし，プロジェクトは2つ目のトラブルに見舞われる（図3[拡大表示]）。今度は，日立情報が青ざめる番だった。作業はメールボックスの移行を終え，最終段階であるパブリックフォルダの移行に入っていた。「余裕を見ても2週間で終わる」（片山氏）と踏んでおり，途中までは順調に進んだ。
ところが移行を終え，旧サーバーを切り離すと，移行したはずのパブリックフォルダのデータの一部がExchange 2000上から消えてしまうのである。新旧サーバーがネットワーク上にある状態ではデータにアクセスできるのに，旧サーバーを切り離すとデータにアクセスできなくなってしまう。
松井証券では，Exchangeのパブリックフォルダを半ばファイル・サーバーのように使っており，会議やプレゼン用の各種資料を添付ファイルとして大量に登録していた。フォルダ数はなんと3000弱，データ容量は8Gバイトに達する。インフォメーションストア全体では約16Gバイトで，しかも更新頻度が高い。「フォルダを作成する権限は部課長以上に限定していたが，使い方にルールは設けなかった」（樋口氏）ために，野放し状態となっていたのだ。
トラブルの本当の原因は結局最後まで突き止められなかったが，日立情報では「このパブリックフォルダのデータの多さが，関係しているのではないか」（片山氏）と推測している（別掲記事を参照）。
|
|
チェックシートで試行錯誤
ともあれ，作業を先に進めなければならない。
片山氏のチームはまず，チェック・リストをExcelで作成し，3000弱のフォルダがそれぞれどういう状態にあるか，どういう処理を行うとどういう動作を起こすかを洗い出した。
具体的には，管理ツールでパブリックフォルダのプロパティに対して複製の設定を行った。これにより，コピーされていなかったデータの一部が正常にコピーされるようになった。また，旧サーバー上のフォルダにダミー・データを入力してみた。フォルダ内で何らかのアクションを起こせば，それがトリガーとなってコピーが始まるかもしれないと考えたためだ。一部のデータは，この方法でうまくいった。
これらを3000弱のフォルダ1つずつについて，手作業で行い，実データがコピーされるかどうかを確認した。最初は日立情報の担当者が毎日夕方に来社して作業していたが，途中から松井証券側も加わり日中は松井の担当者が作業を進めた。
こうした地道な作業で，大部分のフォルダが正常にコピーできることが分かった。数個のフォルダは最後までコピーされずに残ってしまったが，約1カ月間の努力の末，99％の移行に成功し，稼働にこぎ着けた。当初は2002年8月には移行を終わらせている予定だったが，最終的には9月末にずれ込んでいた。
一つ言えることは，松井証券のインフォメーションストアの容量が移行前に既に，Exchange 5.5の制限値である16Gバイトに達しており，早晩運用が破たんするのが目に見えていたことだ。また，この制限値はExchange 2000においても変わらない。
そこで新しい環境では，インフォメーションストアを2つに分けて，一方にメールボックスを，他方にはパブリックフォルダを入れ，1つ当たりの容量を減らしている。さらに，余計なデータを減らすため，ユーザーにはファイル・サーバーで済むものはそちらを使うよう促している。
今回，幸いだったのは，プロジェクトが情報システム部門自身の運用工数にかかわる部分であり，プロジェクトが遅延しても外部への影響が全くなかったことだ。ユーザーのメール読み込みが遅れるという小さな問題を除けば，業務への実害はなかった。
移行後は運用工数を3割程度減らすことができ，今は問題なく動いている。
この現象は特殊な例ではないExchange Serverに詳しいNTTデータ関西テクシス ソリューションマーケティンググループ 永尾幸夫氏によると，「ファイル名などディレクトリ・レベルでの情報はActive Directoryに複製されているが，インフォメーションストアには正常にデータが複製されていない状態で，このような現象が起こる」と言う。 その原因として，(1)ADC（Active Directoryコネクタ）の「パブリックフォルダ接続許可書」をチェックしていない，(2)双方のサーバーでのパブリックフォルダ複製間隔と複製メッセージサイズの制限値が同一ではない，(3)インフォメーションストアの上限値である16Gバイトにデータ容量が達している，の3つが可能性として考えられる。 松井証券の事例では，(1)は確認済み，(2)は未確認だった。(3)が該当するが，因果関係があるかどうかは分からない。 |
