このタイプの移行の要件は次のとおりです。
移行元 (旧) および移行先 (新) の両方のメッセージングサーバーで stored が実行されている。
移行元システムおよび移行先システムの両方が共存して稼動する場合は、相互にメッセージをルーティングできるようにする必要がある。これはたとえば、配信状態通知メッセージを移行先システムで生成し、それを移行元システムに配信できるようにするために必要です。
メッセージングサーバーを以前のバージョンから新しいバージョンにアップグレードする場合にだけ当てはまる手順もあります。メールボックスをメッセージストアから別のメッセージストアに移行するだけの場合は、それらの手順は適用されない可能性があります。システム全体の移行に適用される手順には、その旨が示されています。
移行元システムで、backup-groups.conf ファイルを使用して、移動するユーザーエントリを均等なバックアップグループに分けます。
ここで、手順のあとの方の手順 8 で実行するメールボックスの移行に備えます。詳細については、「バックアップグループを作成するには」を参照してください。
ユーザー名をファイルに入れ、imsbackup コマンドで -u オプションを使用する方法もあります。
移動するユーザーに対し、移動が完了するまでメールボックスにアクセスできないことを通知します。
データを移動する前に、移動するユーザーがメールシステムからログアウトしていることを確認します。(「ユーザーアクセスを監視する」参照。)
バックエンドメッセージストアおよび MMP システムで認証キャッシュのタイムアウトを 0 に設定し、MTA で ALIAS_ENTRY_CACHE_TIMEOUT オプションを 0 に設定します。
移動するメールボックスを含むバックエンドメッセージストアで、認証キャッシュのタイムアウトを 0 に設定します。
configutil -o service.authcachettl -v 0 |
この手順と手順 7 (mailUserStatus を hold に変更) を実行するとすぐに、ユーザーは移行中にメールボックスにアクセスできなくなります。
すべての MMP で、認証キャッシュのタイムアウトを 0 に設定します。
ImpProxyAService.cfg と PopProxyAService.cfg の LdapCacheTTL を 0 に設定します。
移動するメールボックスにメッセージを挿入する MTA をホストするすべての Messaging Server で、ALIAS_ENTRY_CACHE_TIMEOUT オプションを 0 に設定します。
移動するメールボックスにメッセージを挿入する MTA をホストする Messaging Server は、通常、バックエンドメッセージストアになります。ただし、システムが LMTP を使用している場合は、そのシステムが着信 MTA になります。設定をチェックして確認してください。
/msg_svr_base/config/option.dat の ALIAS_ENTRY_CACHE_TIMEOUT をリセットすると、MTA はキャッシュをバイパスして LDAP エントリを直接参照します。これは、中間チャネルキュー (たとえば、conversion チャネルや reprocess チャネル) に対して、移動中のユーザーの古いキャッシュ情報ではなく新しい mailUserStatus (hold) を提示するためです。ALIAS_ENTRY_CACHE_TIMEOUT は option.dat にあります。
キャッシュをリセットしたシステムを再起動します。
これまでの変更を有効にするには、システムの再起動が必要です。手順については、「サービスを起動および停止する」を参照してください。
移行元 Messaging Server と移行先 Messaging Server の両方が起動して実行されていることを確認します。
移行元 Messaging Server で、着信メッセージを新しい移行先サーバーにルーティングできるようにする必要があります。
メールボックスを移動するすべてのユーザーエントリについて、LDAP 属性 mailUserStatus を active から hold に変更します。
この属性変更によって着信メッセージが hold キューに保留され、IMAP、POP、および HTTP 経由でメールボックスにアクセスできなくなります。通常、ユーザーはグループに分けて移動します。1 つのドメインのすべてのメールボックスを移動する場合は、mailDomainStatus 属性を使用できます。
mailUserStatus の詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』の「mailUserStatus」を参照してください。
移動するメールボックス宛のメッセージが ims-ms チャネルキューまたは tcp_lmtp* チャネルキュー (LMTP 配備済みの場合) 内に滞留しないようにします。
次のコマンドを使用して、移動するユーザー宛のメッセージがチャネルキューのディレクトリツリーに存在し、held 状態になっている (.HELD ファイルを参照する) かどうか調べます。
imsimta qm directory -to=<user_address_to_be_migrated> -directory_tree imsimta qm directory -to=<user_address_to_be_migrated> -held -directory_tree |
キューにメッセージがある場合は、これらのコマンドをあとで実行して MTA がそれらのメッセージをキューから取り出したかどうか確認します。キューから取り出されていないメッセージがある場合は、移行の前にこの問題を解決する必要があります。このような状況はまれですが、受取人のメールボックスが制限容量を超えている、おそらくユーザーがログインしてメッセージを移動中であるためにメールボックスがロックされている、LMTP バックエンドサーバーが応答しない、ネットワークまたはネームサーバーに問題がある、などの状況が原因として考えられます。
移動するユーザーエントリ、およびすべてのメールグループエントリにある LDAP 属性 mailHost を変更します*。
ldapmodify コマンドを使用して、エントリを新しいメールサーバーに変更します。Messaging Server または Directory Server に付属している ldapmodify を使用してください。Solaris OS の ldapmodify コマンドは使用しないでください。
* メールグループエントリの mailHost 属性を変更する必要があるのは、古いメールホストがシャットダウンされているときだけです。この属性を新しいメールホスト名に変更するか、属性全体を省いてしまってもかまいません。メールグループの mailHost の指定はオプションです。mailHost の指定は、そのホストだけがグループ拡張を行えることを意味し、mailHost の省略 (こちらの方が一般的) は、すべての MTA でグループ拡張を行えることを意味します。メールグループエントリには移行対象となるメールボックスはなく、通常は mailhost 属性さえ指定されません。
mailhost の詳細については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』の「mailHost」を参照してください。
メールボックスデータを移行元 Messaging Server のメッセージストアから移行先 Messaging Server のメッセージストアに移動し、起動した時刻を記録します。
imsbackup ユーティリティーを使用してメールボックスをバックアップし、imsrestore ユーティリティーを使用して新しい Messaging Server にメールボックスを復元します。たとえば、oldmail.siroe.com という Messaging Server 5.2 システムから newmail.siroe.com にメールボックスを移行するには、oldmail.siroe.com で次のコマンドを実行します。
/server-root/bin/msg/store/bin/imsbackup -f- /instance/group \ | rsh newmail.siroe.com /opt/SUNWmsgsr/lib/msg/imsrestore.sh \ -f- -cy -v1 |
バックアップと復元のセッションを同時に複数 (グループごとに 1 つ) 実行すると、新しいメッセージストアへの転送速度を最適化できます。imsbackup ユーティリティーと imsrestore ユーティリティーの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Command Descriptions」および 「メッセージストアのバックアップと復元を行う」を参照してください。
あとで配信の検証を行うときのために imsbackup の実行時のタイムスタンプを記録しておいてください。
(システムアップグレード用の条件付き手順) メールボックスの移行が、Messaging Server を以前のバージョンから現在のバージョンにアップグレードするプロセスの一部である場合は、この現在のバージョンの Messaging Server がシステムの新しいデフォルトの Messaging Server になるように設定します。
newmail.siroe.com (以前 oldmail.siroe.com によってホストされていたドメインを管理するサーバー) をポイントするように、oldmail.siroe.com の DNS A レコードを変更します。
新しいメッセージストアへのユーザーアクセスを有効にします。
状況に応じて、 LDAP 属性 mailUserStatus または mailDomainStatus を、hold に変更される前の値 (たとえば、active) に設定します。
すべての移行元 Messaging Server にある held 状態のメッセージを解放します。
着信メッセージを保留している可能性のあるすべてのシステムで、次のコマンドを実行してすべてのユーザーメッセージを解放する必要があります。
imsimta qm release -channel=hold -scope |
scope に all を指定するとすべてのメッセージが解放されます。user を指定すると対象がユーザー ID、domain を指定すると対象がユーザーが存在するドメインになります。
認証キャッシュのタイムアウトおよび ALIAS_ENTRY_CACHE_TIMEOUT オプションをデフォルトまたは特定の値にリセットし、システムを再起動します。
これで、移行が必要なすべてのユーザーメールボックスの移行が完了しました。次に進む前に、古いシステムを mailhost とする LDAP 新規エントリが作成されていないことを確認してください。そのようなエントリが見つかった場合は、それらを移行します。プロビジョニングシステムの変更によっても、そのようなエントリが作成できないことを確認してください。
preferredmailhost 属性を新しいメールホストの名前に変更することもお勧めします。
バックエンドメッセージストアでは、認証キャッシュのタイムアウトを次のように設定します。
configutil -o service.authcachettl -v 900 |
MMP では、ImpProxyAService.cfg および PopProxyAService.cfg で LdapCacheTTL オプションを 0 に設定します。
MTA では、ALIAS_ENTRY_CACHE_TIMEOUT オプションを 600 に設定します。ALIAS_ENTRY_CACHE_TIMEOUT は option.dat にあります。
これまでの変更を有効にするには、システムの再起動が必要です。手順については、「サービスを起動および停止する」を参照してください。
ユーザークライアントで新しいメールサーバーが指定されていることを確認します。
アップグレードが終了したら、ユーザーに、メールクライアントプログラムから新しいメールサーバーをポイントしてもらいます (この例では、oldmail.siroe.com から newmail.siroe.com をポイントしてもらう)。
別の方法として、メッセージングマルチプレクサ (MMP) の使用があります。MMP を使用すると、ユーザーのクライアントから新しいメールサーバーを直接ポイントしてもらう必要がなくなります。MMP は、LDAP ユーザーエントリに保存されている mailHost 属性から必要な情報を取得し、クライアントを新しいサーバーに自動的にリダイレクトします。
すべてが正常に動作したら、移行後、古いメッセージストアに配信されたメッセージがないことを確認します。
古いメッセージストアに移動し、mboxutil -l を実行してメールボックスの一覧を表示します。最新のメッセージ配信タイムスタンプをチェックします。移行のタイムスタンプ (imsbackup コマンド実行時のタイムスタンプ) よりあとに配信されたメッセージがある場合は、バックアップおよび復元のコマンドを使ってそれらのメッセージを移行します。これまでの手順で十分に準備しているので、移行後に配信されたメッセージが見つかることはまず考えられません。
理論的には、notices チャネルキーワードで指定された日数または時間数の間、メッセージがキューに滞留することはあり得ます (「通知メッセージの配信間隔を設定するには」を参照)。
新しいメッセージストアで重複しているメッセージを削除し、relinker コマンドを実行します。
このコマンドによって、新しいメッセージストアのディスクの空き容量が増える可能性があります。詳細については、「同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」を参照してください。
移行元のストアから古いメッセージを削除し、古いストア上のデータベースからユーザーを削除します。
mboxutil -d コマンドを実行します。(「mboxutil ユーティリティー」を参照)。