ここに含まれている各章では、インストール後、Calendar Server を使用する前に実行する必要のある設定と移行の手順について説明します。
次の章で構成されています。
Calendar Server をインストールしたあと、実行する前に設定を行う必要があります。2 つの設定プログラムを次の順序で実行することが重要です。
comm_dssetup.pl
『Sun Java System Communications Suite 5 Installation and Configuration Guide』の説明に従って、LDAP ディレクトリサーバーを設定します。
csconfigurator.sh
この章の説明に従って、Calendar Server を設定します。
この章の内容は次のとおりです。
以前のバージョンの Calendar Server または Messaging Server をすでにインストールしている場合、LDAP ディレクトリエントリを Schema バージョン 1 から Schema バージョン 2 に移行する必要があります。
この章で説明している設定ユーティリティーを実行する前に、必ず『Sun Java Communications Suite 5 Schema Migration Guide 』を参照してください。上記マニュアルでは、設定ユーティリティーを実行するためのタイミングとオプションについて説明しています。
Calendar Server 設定プログラム csconfigurator.sh は、新しい ics.conf 設定ファイルを次のディレクトリに作成します。
Solaris の場合: /etc/opt/SUNWics5/config
Linux の場合: /etc/opt/sun/calendar/config
設定プログラムでは、インストールについての特定の情報を入力する必要がある、多くの質問が表示されます。
設定プログラムを実行する前に、次の設定情報を収集する必要があります。
設定情報の追跡に役立つように、付録 B 「Calendar Server 設定ワークシート」のワークシートを使用してください。ただし、他のコンポーネント製品との競合、たとえばポート番号の競合などを避けるため、Java Enterprise System インストーラを実行する前に情報を特定する必要があります。
Calendar Server では、ユーザーの認証や、ユーザー設定の格納と検索を行うためのディレクトリサーバーが必要です。次の表に、LDAP サーバーのホスト情報やポート情報の収集に使用するオプションを示します。
表 2–1 ユーザー設定ディレクトリのオプション
オプション |
説明 |
---|---|
LDAP サーバーのホスト名 |
ユーザー認証とユーザー設定に使用する LDAP ディレクトリサーバーのホスト名。デフォルトは現在のホストです。 |
LDAP サーバーのポート |
LDAP ディレクトリサーバーが待機するポート番号。標準設定は 389 です。 |
次の表に、Directory Manager として指定されたユーザーの名前とパスワードの収集に使用するオプションを示します。
表 2–2 Directory Manager のオプション
オプション |
説明 |
---|---|
Directory Manager DN |
ディレクトリサーバースキーマに変更を加えることができるユーザーの名前。デフォルトは cn=Directory Manager です。 |
Directory Manager のパスワード |
Directory Manager DN のパスワード。パスワードはプレーンテキストでは保存されません。デフォルト値はありません。 |
Calendar Server 管理者は他の Calendar Server ACL より優先されるユーザーアカウントです。Calendar Server 管理者ユーザーアカウントは、認証ディレクトリサーバーに存在している必要があります。このアカウントはプロキシ認証にも使用されます。次の表に、Calendar Server 管理者のユーザー ID とパスワードの収集に使用するオプションを示します。
表 2–3 Calendar Server 管理者のオプション
オプション |
説明 |
---|---|
管理者ユーザー ID |
Calendar Server 管理者のユーザー ID。上記の LDAP ディレクトリサーバー内のユーザーである必要があります。デフォルトは calmaster です。 |
管理者のパスワード |
Calendar Server 管理者のパスワード。デフォルト値はありません。 |
サーバーに問題が生じたときに Calendar Server 管理者に電子メールのアラームメッセージを送信するように Calendar Server を設定できます。次の表に、電子メール情報の収集に使用するオプションを示します。
表 2–4 電子メールと電子メールアラームのオプション
オプション |
説明 |
---|---|
電子メールアラーム |
電子メールアラームを有効または無効にします。デフォルトは有効です。 |
管理者の電子メールアドレス |
電子メールのアラームメッセージを受信する Calendar Server 管理者の電子メールアドレス。 |
SMTP ホスト名 |
Calendar Server システムが電子メールアラームメッセージの送信に使用する SMTP サーバーのホスト名。デフォルトは現在のホストです。 |
次に示す Calendar Server のランタイムオプションとシステムリソースオプションを設定できます。
表 2–5 ランタイム設定のオプション
オプション |
説明 |
---|---|
サービスポート |
Web (HTTP) アクセスができるようにするために Calendar Server が待機しているポートの番号。デフォルトは 80 です。 |
最大セッション |
同時実行可能な Calendar Server セッションの最大数。デフォルトは 5000 です。 |
最大スレッド |
同時実行可能な Calendar Server スレッドの最大数。デフォルトは 20 です。 |
サーバープロセスの数 |
Solaris の場合: 同時実行可能な Calendar Server プロセスの最大数。デフォルトは Calendar Server をインストールしたサーバーの CPU 数です。 Linux の場合: 同時に実行できるプロセスは 1 つのみです。 |
ランタイムユーザー ID |
Calendar Server を実行する UNIX ユーザー名。このユーザー名に root を指定することはできません。アカウントが存在しない場合は、設定プログラムによって作成されます。デフォルトは icsuser です。 |
ランタイムグループ ID |
Calendar Server を実行する UNIX グループ。グループが存在しない場合は、設定プログラムによって作成されます。デフォルトは icsgroup です。 |
Calendar Server が自動的に起動するように、次のオプションを設定できます。
表 2–6 Calendar Server 起動オプション
オプション |
説明 |
---|---|
インストールが成功したら起動する |
インストールに成功したあと、Calendar Server が自動的に起動するかどうか。デフォルトで選択されています。 |
システムの起動時に起動する |
システムの起動後、Calendar Server が自動的に起動するかどうか。デフォルトで選択されています。 |
Calendar Server は特定のディレクトリにカレンダデータベースファイル、ログファイル、および一時ファイルを作成し、情報を格納します。
表 2–7 データベース、ログ、および一時ファイルのディレクトリのオプション
オプション |
説明 |
---|---|
データベースディレクトリ |
Calendar Sever システムがカレンダデータベース (*.db) ファイルを作成し、格納するディレクトリ。デフォルトは次のとおりです。 /var/opt/SUNWics5/csdb |
ログディレクトリ |
Calendar Server がログファイルを書き込むディレクトリ。デフォルトは次のとおりです。 /var/opt/SUNWics5/logs |
一時ファイルディレクトリ |
Calendar Server システムが一時ファイルを書き込むディレクトリ。デフォルトは次のとおりです。 /var/opt/SUNWics5/tmp |
アーカイブおよびホットバックアップの設定 |
Calendar Server システムがアーカイブバックアップを書き込むディレクトリ。毎日のスナップショットとトランザクションログを格納するためのユーザー定義ディレクトリ。両タイプのバックアップが必要な場合は、それらを別々のディレクトリに格納します。ディレクトリを指定しないと、バックアップは現在のディレクトリに格納されます。 |
添付ファイルの保存用ディレクトリ |
Calendar Sever システムが予定と作業に添付するファイルを格納するディレクトリ。 |
ログファイルと一時ファイルのディレクトリの位置や名前を変更しないでください。
設定プログラムは、グラフィカルユーザーインタフェース (GUI) からでも、コマンド行からでも実行できます。
プログラムをリモート実行する場合は、DISPLAY 環境変数を正しく設定し、サーバーからの X-Windows 接続により、使用しているコンピュータ上に表示できるようにする必要があります。たとえば、xhost ユーティリティーを使用するには、使用しているコンピュータで次のコマンドを実行します。
# xhost +
ここでは、次の内容について説明します。
スーパーユーザー (root) としてログインするか、スーパーユーザーになります。
/opt/SUNWics5/cal/sbin ディレクトリに移動します。
次の表から選択したオプションを使用してスクリプトを実行します。
オプション |
説明 |
---|---|
-nodisplay |
設定スクリプトをテキストのみモード (非 GUI) で実行します。 |
-noconsole |
テキスト出力を表示しません。設定スクリプトをサイレントモードで実行するには、このオプションに -nodisplay を指定して実行します。 |
-novalidate |
入力フィールドのテキストを検証しません。 |
-saveState [statefile] |
設定に関する質問に対して入力した回答を状態ファイル (テキストファイル) に保存します。状態ファイルの完全修飾パスを指定しない場合、ファイルは次のデフォルトディレクトリに保存されます。/opt/SUNWics5/cal/jconfigure 。 |
-state [statefile] |
入力値の設定に状態ファイルを使用します。このオプションは、-novalidate および -noconsole と一緒に使用する必要があります。 |
たとえば、コマンド行モードで設定スクリプトを実行するには、次のコマンドを使用します。
./csconfigurator.sh -nodisplay
コマンド行バージョンでは、GUI と同じ情報が同じ順序で尋ねられます。デフォルト値は、角カッコ [] で示されます。デフォルト値をそのまま使用するには、キーボードで Enter キーを押します。
スクリプトによって提示されるさまざまな質問に含まれる情報については、以降の節で示す GUI 画面内のテキストを参照してください。
スーパーユーザー (root) としてログインするか、スーパーユーザーになります。
/opt/SUNWics5/cal/sbin ディレクトリに移動します。
次のコマンドを実行します。
./csconfigurator.sh
設定プログラムでは、次の画面が表示されます。
設定プログラムはシングルドメインを設定できるだけです。複数のドメインを使用する予定の場合は、Delegated Administrator を使用してドメインを追加する必要があります。
どの画面でもタイトルバーが正しくありません。バージョン番号は、表示された 6.5 ではなく 6.3 です。
続行する場合は「次へ」をクリックし、終了する場合は「取消し」をクリックします。
ユーザー認証に使用する LDAP ディレクトリサーバーのホスト名。デフォルト: 現在のホスト
LDAP サーバーが待機するポート番号。デフォルト: 389
ディレクトリサーバースキーマに変更を加えることができるユーザーの名前。デフォルト: cn=Directory Manager
Directory Manager のパスワード。これはプレーンテキストでは保存されません。デフォルト: なし
仮想ドメイン、ホストされたドメイン、複数ドメインはどれも同一の機能を表す名前であり、対応するユーザーおよびグループレコードとともに複数の LDAP ドメインを保持できることを意味します。
非仮想ドメイン環境からアップグレードする場合は、「仮想ドメインのサポートを有効」チェックボックスにチェックマークを付ける必要があります。すでに複数ドメイン環境が存在する場合は、チェックボックスはグレー表示になっています。仮想ドメインのサポートは現在、Calendar Server のデフォルトの機能になっており、オプションではありません。
現在、Calendar Server を新規インストールした場合、仮想ドメインはデフォルトでサポートされます。設定プログラムのグラフィカルユーザーインタフェースを使用して、「新しいデフォルトドメイン」入力ボックスにデフォルトのドメイン名を入力します。設定プログラムによりドメインが作成されます。
「デフォルトドメイン」ボックスに示されるドメインから、デフォルトドメインとして 1 つを選択します。以前のバージョンの Calendar Server で複数ドメインをすでに使用しており、「デフォルトドメイン」ボックスに示されるドメインを使用しない場合は、ボックスをクリックしてドメインのリストを表示し、そこから新しいデフォルトドメインを選択します。
Calendar Server 管理者のユーザー名。デフォルト: calmaster
Calendar Server 管理者のパスワード。デフォルト: なし
Calendar Server 管理者の電子メールアドレス。
サイト管理者とは、複数のドメインのプロキシ認証権限を持つユーザーです。
次の基準に従って該当する選択肢をクリックします。カレンダ管理者がサイト管理者でもある場合、「はい」。カレンダ管理者がサイト管理者ではない場合、「いいえ」。
続行する場合は、「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。
サーバーに問題が生じたときに Calendar Server が Calendar Server 管理者に電子メールのアラームメッセージを送信するかどうかを指定します。デフォルト: 「無効」。「無効」を選択した場合、サーバーの問題に関する電子メールアラームは管理者に送信されません。
電子メールのアラームメッセージを受信する Calendar Server 管理者の電子メールアドレス。デフォルト: なし
アラームメッセージの送信に使用される SMTP サーバーのホスト名。デフォルト: 現在のホスト。
続行する場合は、「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。
Web (HTTP) アクセスができるようにするために Calendar Server が待機しているポートの番号。デフォルト: 80
同時実行可能な Calendar Server セッションの最大数。デフォルト: 5000
同時実行可能な Calendar Server スレッドの最大数。デフォルト: 20
サーバー上で実行できる Calendar Server プロセスの最大数。デフォルト: Calendar Server をインストールしているサーバーの CPU 数
Calendar Server を実行する UNIX ユーザー名。アカウントが存在しない場合は、設定プログラムによって作成されます。デフォルト: icsuser
ランタイムユーザー ID には root を使用しないでください。
Calendar Server を実行する UNIX グループ。グループが存在しない場合は、設定プログラムによって作成されます。デフォルト: icsgroup
チェックボックスをクリックしてどちらかまたは両方のオプションを選択します。
設定が成功したら起動する
この設定プログラムの実行が成功したあと、Calendar Server が自動的に起動するかどうかを指定します。
システムの起動時に起動する
システムの起動後、Calendar Server が自動的に起動するかどうかを指定します。
デフォルトでは、「システムの起動時に起動する」チェックボックスだけにチェックマークが付けられています。
続行する場合は「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。
このサーバーを単一サーバー配備として設定するか、フロントエンド/バックエンド配備として設定するかを選択します。Calendar Server の単一サーバーインスタンスを使用することにした場合、この画面のチェックボックスにはチェックマークを付けません。1 つまたは複数のサーバーに Calendar Server データベースを配備し、別のサーバー上のクライアントと通信するプロセスを継続する場合は、チェックボックスにチェックマークを付けます。
ここでは、次の内容について説明します。
管理プロセスとデータベースの両方を 1 つのサーバーに置く単一サーバー配備の場合は、この画面のどの部分も変更しないでください。「次へ」をクリックして次に進みます。
フロントエンドマシンとバックエンドマシンを別々に配備する場合は、「フロントエンド/バックエンド配備を設定」というチェックボックスにチェックマークを付けます。次の 2 つのスクリーンショットに示すように、画面表示が変更し、フロントエンドサーバーとバックエンドサーバーを個別に設定できます。
この画面では、次の手順を実行します。
バックエンドサーバー、つまりカレンダデータベースを格納するサーバーを設定するには、サービスポートを指定するだけです。
「サービスポート」入力ボックスにはあらかじめ、 ics.conf のパラメータである service.dwp.server.hostname.port と service.dwp.port で指定されたポートが入力されています。
ポート番号を変更する場合は、「サービスポート」入力ボックスに適切なポート番号を入力します。
フロントエンドサーバーを設定するには、「ホストを追加」をクリックして、設定しているサーバーのホスト名と IP アドレスを入力します。
現在設定しているサーバー以外はリストに追加しないでください。別のフロントエンドサーバーを設定する予定の場合は、それらの設定時に追加します。設定に追加する各サーバーで設定プログラムを実行する必要があります。
このサーバーがデフォルトのフロントエンドサーバーである場合は、「標準」チェックボックスにチェックマークを付けます。
「次へ」をクリックします。
「選択したホストを削除」をクリックして、このリストからサーバーを削除することもできます。
この画面では、デフォルトのディレクトリをそのまま使用してください。設定およびデータファイルの格納先ディレクトリを選択できますが、お勧めしません。
設定ファイル (ics.conf) が格納されるディレクトリ。
Calendar Server でカレンダデータベースファイルを作成し、格納するディレクトリ。デフォルト: /var/opt/SUNWics5/csdb
添付ファイルが格納されるディレクトリ。デフォルト: /var/opt/SUNWics5/astore
Calendar Server がログファイルを書き込むディレクトリ。デフォルト: /var/opt/SUNWics5/logs
Calendar Server が一時ファイルを書き込むディレクトリ。デフォルト: /var/opt/SUNWics5/tmp
続行する場合は「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。
これらのディレクトリのいずれかがまだ存在していない場合は、存在しないディレクトリごとにポップアップウィンドウが表示されます。適切なボタンをクリックして、設定プログラムに新しいディレクトリを作成させるか、別のディレクトリを選択できる画面に戻るかを選択します。
すでに存在しているが空ではないディレクトリの場合は、2 つの選択肢を示すポップアップウィンドウが表示されます。適切なボタンをクリックして、ディレクトリをそのまま使用するか、別のディレクトリを選択できる画面に戻ります。
この画面では、自動バックアップタイプの両方、または 2 つのタイプのどちらかを選択できます。または、どちらも選択しなくてもかまいません。必要に応じて、各ボックスを選択または選択解除します。アーカイブバックアップとホットバックアップの両方を使用することを強くお勧めします。
機器の損傷のためにデータベースのコピーがすべて失われることがないようにしてください。自動バックアップコピーは、ライブデータベースが格納されているものとは別のディスクやディスクシステムに保存してください。
自動バックアップについては、第 9 章「自動バックアップ (csstored) の設定」を参照してください。
このボックスにチェックマークが付いていると (デフォルト)、csstored によって 24 時間ごとにカレンダデータベースのスナップショットが取得されます。終日にわたって、その日のトランザクションログファイルがスナップショットとともにアーカイブバックアップディレクトリに定期的に格納されます。
このボックスにチェックマークが付いていない場合、「アーカイブディレクトリ」入力フィールドはグレー表示になります。
「参照...」をクリックしてバックアップディレクトリを選択するか、デフォルトをそのまま使用します。
このボックスにチェックマークが付いていると (デフォルト)、csstored によって 24 時間ごとにカレンダデータベースのスナップショットが取得され、設定された間隔 (デフォルトでは 2 分) で終日にわたりトランザクションログがスナップショットに適用されるため、ライブデータベースとほぼ同じ内容が保証されます。
このボックスにチェックマークが付いていないと、「ホットバックアップディレクトリ」入力フィールドはグレー表示になります。
「参照...」をクリックしてバックアップディレクトリを選択するか、デフォルトをそのまま使用します。
このフィールドは、「アーカイブを有効」ボックスにチェックマークを付けた場合にのみ使用できます。それ以外の場合はグレー表示になります。
「最小」および「最大」フィールドの上向きの矢印または下向きの矢印をクリックすると、アーカイブバックアップをバックアップディレクトリに保存しておく日数を選択できます。
このフィールドは、「ホットバックアップを有効」ボックスにチェックマークを付けた場合にのみ使用できます。それ以外の場合はグレー表示になります。
次の 2 つの方法で、ホットバックアップを保持する日数を設定できます。
「最小」および「最大」フィールドの上向きの矢印または下向きの矢印をクリックすると、ホットバックアップをディレクトリに保存しておく日数を選択できます。
一度に実際に格納されるコピー数は、ファイルのサイズやディレクトリのサイズによって異なります。サイズ制限または最大コピー数の制限のいずれかを超えると、この設定画面で指定した最小数まで、もっとも古いコピーが破棄されます。
ホットバックアップの設定をアーカイブバックアップと同じにする場合は、「アーカイブと同じ」ボックスにチェックマークを付けます。
続行する場合は「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。設定プログラムを終了する場合は「取消し」をクリックします。
これまで、画面を使って設定に必要な情報を収集したり、有効性を検査したりしてきました。この時点では、設定情報を前に戻って入力し直すことも、設定を開始することもできます。
Calendar Server を設定する場合は「すぐに設定する」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。
このパネルでは、すべての作業とその結果 (成功または失敗) に関する情報が実行中に更新されます。「すべての作業が成功しました」というメッセージが表示されたら、設定は終了です。表示されたログファイルを見て、エラーメッセージがないかどうかを調べてください。
設定プログラムが完了したら「次へ」をクリックします。
「詳細」をクリックして設定ログの詳細を表示するか、または「閉じる」をクリックして設定プログラムを終了します。
ここでは、Calendar Server 6.3 ソフトウェアをインストールし、設定したあとにカレンダデータベースと LDAP データベースを移行するためのさまざまなデータベース移行ユーティリティーについて説明します。
この章の内容は次のとおりです。
Calendar Server 6.0、6.1、または 6.2 バージョンから移行する場合は、「3.3 csmigrate ユーティリティー」 と呼ばれるユーティリティーを実行します。以前の配備で、定期的な予定および作業に対して cs5migrate が実行済みでない場合は、csmigrate を実行する前に既存のカレンダデータベースで cs5migrate を実行する必要があります。
Calendar Server 5.1.1 から移行する場合は、「3.2 適切な Calendar Server ユーティリティーの選択」で説明するように、移行ユーティリティーを使用してカレンダデータベースと LDAP データベースを移行します。
5.1.1 より古いバージョンの Calendar Server がインストールされている場合は、データの移行についてはテクニカルサポートにお問い合わせください。
ここでは、それぞれの移行ユーティリティーについて説明します。過去にインストールされた Calendar Server のバージョンに応じ、必要となる移行ユーティリティーのみを使用します。これらのユーティリティーは sbin ディレクトリにあります。
データベースに対して過去に cs5migrate ユーティリティーを実行したことがあるが、そのときに -r オプションを指定しなかった場合は、ほかのユーティリティーを実行する前に -r オプションを指定してこのユーティリティーを再実行する必要があります。
移行ユーティリティーとは、次のものを指します。
Calendar Server 6 データベース内の各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これによって、複数ドメインおよび LDAP カレンダ検索データベース (CLD) プラグインがサポートされます。
cs5migrate のあと、csvdmig の前にこのユーティリティーを実行します。
カレンダのドメイン (@domainname) を各 calid に追加することにより、Calendar Server 6 サイトをアップグレードして、複数ドメインを使用するようにします。たとえば、sesta.com というドメインでは、jdoe の calid は jdoe@sesta.com となります。このユーティリティーは Calendar Server に同梱されています。
csmig のあと、cs5migrate の前にこのユーティリティーを実行します。
カレンダデータベースを Calendar Server バージョン 5 の形式からバージョン 6.2 の形式に移行します。-r オプションを指定し、データベースに対してこのユーティリティーを実行する必要があります。以前に Calendar Server バージョン 5.1.1 から 6.2 に移行したが、-r オプションを指定して cs5migrate ユーティリティーを実行しなかった場合は、csmigrate ユーティリティーの前に、このユーティリティーを実行する必要があります。
このユーティリティーは、csmig および csvdmig のあと、csmigrate の前に実行します。
Calendar Server バージョン 6.0、6.1、または 6.2 から Calendar Server 6.3 バージョンにアップグレードするために、カレンダデータベースを移行します。cs5migrate を -r オプションを指定して実行する必要がある場合は、このユーティリティーの前に実行します。
Access Manager (Legacy モード) での使用に備え、LDAP データを Schema バージョン 1 から Schema バージョン 2 に移行します。
ここでは、すべてのカレンダデータベースおよび LDAP データベースを、Calendar Server 6.3 ソフトウェアレベルに移行するために実行する必要のあるユーティリティーを判断する方法について説明します。
次の表を使用し、適切なユーティリティーのコレクションを見つけます。
ユーティリティーは、指定の順序で実行します。
移行前の Calendar Server のバージョン |
データベースファイルの状態 |
使用するユーティリティー |
---|---|---|
Calendar Server 6.0、6.1、6.2 |
定期的な予定と仕事があり、過去に cs5migrate を実行したことがある。 Schema バージョン 2 をすでに使用している。 |
csmigrate を実行します。 |
Calendar Server 6.0、6.1、6.2 |
定期的な予定と仕事があり、過去に cs5migrate を実行したことがある。 過去に Schema バージョン 2 を使用したことはないが、使用する必要性が生じた。 |
csmigrate および commdirmig を実行します。 |
Calendar Server 6.0、6.1、6.2 |
ファイルに対して cs5migrate を実行したことがない。 Schema バージョン 2 をすでに使用している。または、Schema バージョン 1 を使用しており、今後も使用を続ける予定である。 |
cs5migrate および csmigrate を実行します。 |
Calendar Server 6.0、6.1、6.2 |
ファイルに対して cs5migrate を実行したことがない。 過去に Schema バージョン 2 を使用したことはないが、使用する必要性が生じた。 |
cs5migrate、csmigrate、および commdirmig を実行します。 |
Calendar Server 5.1.1 |
過去に複数ドメインを使用したことがない。 |
csmig、csvdmig、cs5migrate、csmigrate、および commdirmig を実行します。 |
Calendar Server 5.1.1 以前 |
ファイルは複数ドメインまたは LDAP CLD をサポートしていない。LDAP データベースは Schema バージョン 1 を使用している。 |
データベースと LDAP ファイルを Calendar Server 5.1.1 レベルに移行する方法については、テクニカルサポートにお問い合わせください。 |
Calendar Server 5.1.1 以前 |
システムは制限付きの仮想ドメインに対応するよう設定されているか、Calendar Server ソフトウェアの複数のインスタンスが Solaris 10 以前のオペレーティングシステムにインストールされている。 |
移行要件の評価については、セールス担当者にお問い合わせください。 |
csmigrate ユーティリティーは、Calendar Server 6.0、6.1、または 6.2 データベースを Calendar Server 6.3 データベースに移行するために使用されます。csmigrate ユーティリティーは、その他の管理ツールとともに Calendar Server 製品の sbin ディレクトリ内にあります。
ここでは、次の内容について説明します。
csmigrate コマンドの構文は次のとおりです。
csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir
オプションとその用途は次のとおりです。
非出力モードを指定し、印刷指示は出しません。
ドライランモードを指定し、新規データベースは書き込まれません。
ログレベルを指定します。移行ログは csmigrate.log に書き込まれ、エラーはデフォルトログディレクトリの csmigrateError.log に書き込まれます。
ソースデータベースのバックアップを作成するディレクトリを指定します。プログラムはこのディレクトリにソースデータベースのバックアップを作成し、ソースデータベースを破損しないために、そのコピーに対して作業を行います。デフォルトの場所は、ソースデータベースディレクトリの backup です。
移行前のデータベースファイルが保存されているディレクトリ。
移行後のファイルが保存されるディレクトリ。
ツールのバージョン情報の印刷。
ツールの使用情報の印刷。
プログラムの終了コードは、失敗の場合は 255、成功の場合は 0 です。
csmigrate コマンドのオプションの使用例は次のとおりです。
csmigrate -b /var/opt/SUNWics5/tmpdb /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db csmigrate -q /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db csmigrate -l min old_db /var/opt/SUNWics5/new_db csmigrate -l max old_db /var/opt/SUNWics5/new_db
root 権限でログインします。
すべてのサービスを停止します。
たとえば、次のコマンドを実行します。
stop-cal
現在のデータベースを一時ディレクトリに移動します。
たとえば、csdb ディレクトリ全体を oldcsdb に移動します。
mv cal-svr-base/SUNWics5/csdb/* cal-svr-base/SUNWics5/oldcsdb
新規ディレクトリと、そのディレクトリ内の古いファイルの両方が、デフォルト管理者 (icsuser、icsgroup) によって所有されていることを確認します。
所有権が誤っている場合は、次のコマンドを使用して所有権を変更します。
chown -R icsuser:icsgroup /cal-svr-base/SUNWics5/oldcsdb/
移行ツールを実行します。
次の例に示すように、新規バックアップコピー (oldcsdb) から csdb ディレクトリに移行します。
cd cal-svr-base/SUNWics5/cal/sbin/ ./csmigrate -l max /cal-svr-base/SUNWics5/oldcsdb cal-svr-base/SUNWics5/csdb
カレンダサービスを再起動します。
たとえば、次のコマンドを使用します。
stop-cal
csmigrate ユーティリティーは、Calendar Server 5.1.1 データベースを Calendar Server 6.3 レベルに移行するために使用されます。加えて、初期の Calendar Server 6 バージョンから移行するときに、定期的なオプションを使用しなかった場合にもこのユーティリティーを使用します。
cs5migrate ユーティリティーでは、次の作業を実行できます。
これまでに、Connection for Microsoft Outlook を使用する計画がなかった場合は、定期的なデータ変換を行わずにこのユーティリティーを実行することもできます。ただし、Calendar Server 6.3 以降では、定期的なデータを新しい形式に変換する必要があります。
このユーティリティーは、Calendar Server 6.3 ソフトウェアへのアップグレード後に、ほかの管理ツールとともに sbin ディレクトリに格納されます。
csmig ユーティリティでは、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。
csmig ユーティリティーは複数ドメインと LDAP Calendar Lookup Database (CLD) プラグインをサポートします。移行されたデータベース内のカレンダには、LDAP CLD プラグインを使用してアクセスできます。LDAP CLD プラグインについては、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。
ここで説明する内容は次のとおりです。
csmig 移行ユーティリティーでは、次の機能を実行します。
csmig は、caldb.berkeleydb.homedir.path パラメータによって指定された現在のカレンダデータベース (*.db ファイル) 内のユーザーとリソースの両方のカレンダを移行します。新しい移行先ターゲットデータベースでは、csmig により、カレンダプロパティー (calprops)、予定、仕事 (作業)、およびグループスケジューリングエンジン (GSE) データベースファイルに含まれる、LDAP CLD プラグインで必要とされるエントリが更新されます。
csmig は移行先ターゲットデータベースだけに書き込みを行います。既存のカレンダデータベースに書き込むことはありません。
csmig は、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。すべてのデフォルトの calids はそのまま維持され、変更は行われません。
その他のカレンダは次のようにマッピングされます。
有効な所有者がいないユーザーカレンダは、-c オプションによって csmig に渡されるユーザーが所有します。たとえば、jsmith というカレンダ ID の所有者がいない場合、-c オプションとして orphan を指定すると、このカレンダ ID は orphan:jsmith に変換されます。
所有者がいないリソースカレンダは、-r オプションによって csmig に渡されるリソースユーザーが所有します。
リソースカレンダの名前にコロン (:) が含まれる場合、移行された名前に含まれるコロンが 1 つのみになるように、それらのコロンは下線に変換されます。
たとえば、所有者が bkamdar の football というカレンダ名は、bkamdar:football に変換されます。所有者が bkamdar の tchang:soccer というカレンダ名は、bkamdar:tchang_soccer に変換されます。所有者が admin1 の auditorium:room1 というカレンダ名は、admin1:auditorium_room1 に変換されます。
csmig は、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、およびリソースカレンダに対する uid を含む、関連するすべての LDAP エントリの LDAP 属性を更新します。csmig は、LDAP ディレクトリサーバーデータベース内の各カレンダの icsDWPHost 属性を作成します。icsDWPHost は、カレンダが存在するバックエンドサーバーのホスト名を指定します。
csmig を使用するための要件は次のとおりです。
カレンダデータベースが破損していないこと。csdb check コマンドを使用してカレンダデータベースを確認し、必要に応じて csdb rebuild コマンドを実行してデータベースを再構築します。これらのコマンドについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。
新しい移行先ターゲットデータベース、および、バックアップデータベースがある場合にはその分も含めて、十分なディスクの空き容量があること。
csmig を実行するには、icsuser、または設定中に指定した Calendar Server のランタイムユーザー ID としてログインします。スーパーユーザー (root) として csmig を実行する場合は、移行されたファイルに対するアクセス権のリセットが必要になることもあります。
ユーザー設定を格納する LDAP ディレクトリサーバーでカレンダユーザーの属性を管理するための権限も必要です。
Calendar Server は停止している必要があります。
csmig [-t DestinationDB] [-b Backend-DWPHost] [-o OutputFile] [-e ErrorFile] [-m MappingFile] [-c calendarOwner] [-r resourceOwner] { migrate|dryrun } |
次の表に、ユーティリティーのオプションを一覧表示し、各オプションの説明とデフォルト値も示します。
csmig のオプション |
説明とデフォルト値 |
---|---|
-t DestinationDB |
csmig で生成する移行先ターゲットデータベースを指定します。デフォルトは MigratedDB です。 |
-b Backend-DWPHost |
DWP バックエンドホストサーバーの名前を指定します。この名前は ics.conf ファイルで指定された DWP バックエンドホストサーバー名と一致している必要があります。 |
-o OutputFile |
csmig の画面への出力と発生するあらゆるエラーを書き込む出力ファイルを指定します。デフォルトは MigrateOut です。 |
-e ErrorFile |
csmig でエラーや解決できないデータベースエントリが書き込まれるファイル。解決できないデータベースエントリは、移行先データベースに書き込まれません。デフォルトは MigrateError です。 |
-m MappingFile |
dryrun モードで生成された出力マッピングファイルを指定します。出力マッピングファイルには、LDAP スキーマで変更する必要のあるエントリが一覧表示されます。次に例を示します。 古いエントリ: calid=jsmith 新しいエントリ: calid=jsmith:basketball マッピングファイルでは、LDAP スキーマに対して行われる変更のリストだけが生成されます。csmig では、実際にはスキーマへの変更は行われません。 マッピングファイルは、migrate モードでは使用されません。 |
-c calendarOwner |
所有者がいないユーザーカレンダの所有者を指定します。 |
-r resourceOwner |
所有者がいないリソースカレンダの所有者を指定します。 |
migrate|dryrun |
ユーティリティーがどのモードで実行されているかを指定します。移行を行う場合は、migrate モードを使用します。実際に移行を行う前に出力マッピングファイルを生成する場合は、dryrun モードを使用します。 |
バージョン 5.1.1 以前の Calendar Server を使用している場合は、Calendar Server 6.3 のインストールと設定が完了したあとに csmig を実行し、既存の Calendar Server および LDAP データベースを移行します。LDAP データの移行は、LDAP CLD プラグインを正常に動作させるために必要です。csmig を使用してカレンダデータを移行する場合は、次の手順を実行します。
comm_dssetup.pl を使用し、Directory Server を設定します。
まだ comm_dssetup.pl を使用して LDAP 属性にインデックスを作成していない場合は、ここで行います。これによって、LDAP データの移行処理のパフォーマンスが大幅に向上します。
テストサーバー (本稼働サーバーではない) を使用して、テストドライランを実行します。
ドライランでは、実際の移行中に csmig によって何が行われるかがレポートされますが、データは移行されません。ドライラン後、実際に移行を行う前に、エラーを修正し、未解決のカレンダを処理する計画を決定します。
テストドライランの実行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。
運用データを移行します。
本稼働では、csmig によって、カレンダデータベース (.db ファイル) と LDAP データ (ユーザーおよびグループの設定データ)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダ用) が移行されます。移行後、すべてのカレンダリソースに LDAP エントリが作成されます。
運用データの移行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。
必要に応じて、Calendar Server 6.3 を中継サーバーにインストールします。
カレンダデータベースのスナップショットを中継サーバーにコピーします。
次の作業を実行して、中継サーバー上に本稼働 LDAP 環境を再現します。
Directory Server をインストールします。
このサーバーに LDAP データベースのスナップショットをインストールします。
comm_dssetup.pl を実行して、中継 Directory Server を設定します。
csconfigurator.sh を実行して、中継 Calendar Server を設定します。
icsuser としてログインします。これが異なる場合は、設定中に指定した Calendar Server のランタイムユーザー ID としてログインします。スーパーユーザー (root) として csmig を実行する場合は、移行されたファイルに対するアクセス権のリセットが必要になることもあります。
cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。
csdb check コマンドを実行して、データベースに破損が生じていないかどうかを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。
所有者がいないユーザーカレンダにすべてを割り当てるための calid を作成することを考慮します。たとえば、次のコマンドを実行すると、orphan という calid を持ったユーザーが作成されます。
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan |
必要に応じて、stop-cal コマンドを使用して Calendar Server を停止します。
cal-svr-base/SUNWics5/cal/sbin/stop-cal
-dryrun オプションを指定して csmig を実行します。たとえば、次のように入力します。
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
このコマンドを実行すると、所有者のいないユーザーカレンダ (orphan カレンダ) が所有者 orphan に割り当てられ、所有者のいないリソースカレンダが所有者 calmaster に割り当てられます。
出力マッピングファイル (csmig.map) を確認します。マッピングファイルに、LDAP スキーマ内で更新する必要のあるエントリが一覧表示されます。
出力ファイル、マッピングファイル、およびエラーファイルを確認します。検出された LDAP の問題やエラーを解決します。実際の移行の前に、未解決のカレンダを処理する方法を決定します。
選択肢は以下のとおりです。
移行する前に、不要なカレンダを削除します。
未解決のカレンダに所有者を割り当てます。
-c オプションと -r オプションを使用して csmig を実行し、移行中にカレンダに所有者を割り当てます。
csmig を実行して、中継カレンダデータベースを移行します。
たとえば、次のコマンドを実行すると、カレンダデータベースが /var/opt/SUNWics5/testcsdb/ ディレクトリに移行されます。
./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster migrate
テスト移行が完了したら、次の手順を実行して、新しく移行されたカレンダデータベースを確認します。
移行されたデータベースを、caldb.berkeleydb.homedir.path パラメータで指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。
新しいカレンダデータベースで csdb check を実行します。移行されたデータベースの予定や仕事の数は、移行前の合計数と一致している必要があります。
icsCalendarOwned エントリを検索し、エントリが移行前のカレンダ数と一致していることを確認します。
Communications Express にログインし、移行されたデータベース内のいくつかのカレンダを検証します。
テスト移行が正常に行われたら、運用データベースの移行準備は完了です。
icsuser (または設定中に指定した Calendar Server のランタイムユーザー ID) としてログインします。スーパーユーザー (root) として csmig を実行する場合は、移行されたファイルに対するアクセス権のリセットが必要になることもあります。
cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。
stop-cal コマンドを使用して Calendar Server を停止します。
cal-svr-base/SUNWics5/cal/sbin/stop-cal
以下のデータのバックアップを作成します。
カレンダデータベース (.db ファイル)
LDAP データ: slapd データベースディレクトリおよび LDAP データベース。
ics.conf ファイル。この手順は実際には必要ありませんが、元の設定に戻す必要がある場合に役立ちます。
-migrate オプションを指定して csmig を実行します。
たとえば、次のコマンドを実行すると、カレンダデータベースが /var/opt/SUNWics5/newcsdb/ ディレクトリに移行されます。
./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.log -c orphan -r calmaster migrate
エラーファイル (csmig.errors) で未解決のカレンダを確認し、「3.5.4 csmig ユーティリティーの移行の手順」 の 「3.5.4 csmig ユーティリティーの移行の手順」の計画に従って問題を解決します。
csdb check コマンドを実行して、移行されたデータベースを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。
移行されたデータベースを、caldb.berkeleydb.homedir.path パラメータで指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。
ics.conf ファイルで、必要に応じて次の構成パラメータを変更し、LDAP CLD プラグインを有効にします。
caldb.dwp.server. server-hostname.ip = "server-hostname" (ローカルサーバーを含む各バックエンドサーバー用)
caldb.cld.cache.homedir.path では、CLD キャッシュディレクトリの場所を指定します。デフォルトは、/var/opt/SUNWics5/csdb/cld_cache です。
LDAP CLD プラグインの構成パラメータの指定方法については、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。
start-cal コマンドを使用して Calendar Server を再起動します。
Communications Express にログインし、移行されたカレンダのいくつかを確認して、正常に設定されたかどうかを検証します。
確認を行う間アラームを無効にするには、ics.conf ファイルで次の各パラメータを "no" に設定します。
ここでは、次のヒントとトラブルシューティングの例について説明します。
tchang:myCalendar という名前のカレンダの所有者がカレンダデータベース内の jsmith であるため、csmig のドライランのマッピングでは jsmith:tchang_myCalendar と表示されます。しかし、このカレンダの名前を tchang:myCalendar とし、tchang という所有者を割り当てるとします。
移行前に、cscal ユーティリティーを使用して、カレンダ tchang:myCalendar の所有者を tchang に変更します。これを実行すると、移行によってこのカレンダが tchang:myCalendar にマッピングされ、icsCalendarowned がユーザー ID tchang の LDAP エントリに追加されます。
移行後、LDAP カレンダ検索が有効になりますが、カレンダ検索ダイアログに何も結果が表示されないか、一部の結果だけが表示されます。
LDAP カレンダ検索を有効にすると、Calendar Server で検索に (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用できるようになります。
次のフィルタを使用して LDAP データに対して 2 つの異なる検索を手動で実行し、出力を比較します。
フィルタ (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用した LDAP 検索
フィルタ (icscalendarowned=*substr* ) を使用した LDAP 検索
サーバーで icsCalendarUser オブジェクトクラスを含むフィルタを使用するため、スキーマの確認が無効な状態で LDAP サーバーが配備され、一部のカレンダエントリが icsCalendarUser オブジェクトクラスなしでプロビジョニングされた可能性があります。
csmig のドライランマッピングファイルおよび出力ファイルに、カレンダ名の重複が記録されます。
たとえば、元のデータベースで、jsmith が次のカレンダを所有しているとします。
basketball (5 個の予定あり)
jsmith:basketball (10 個の予定あり)
ドライランでは、移行中に 2 つのカレンダがマージされ、生成されるカレンダは、所有者が jsmith で、合計 15 個の予定が含まれた jsmith:basketball となります。
出力ファイルには次の警告メッセージが記録されます。
Error modifying calendar properties, error=2
2 つのカレンダをマージしない場合は、移行前に basketball の所有者を jsmith 以外のユーザーに変更します。これによって、2 つの独立したカレンダのデータの完全性が維持されます。
デフォルトでは、csmig によって親のないすべてのカレンダに 1 人の所有者が割り当てられますが、一部の親のないカレンダに、異なる複数の所有者を割り当てるとします。
csmig では、コマンド行からはマッピングファイルを操作できません。ただし、移行前に、元のデータベース内の親のないカレンダに所有者を割り当てることはできます。親のないすべてのカレンダに対するドライランのマッピングファイルを確認します。移行前に、cscal ユーティリティーを使用して、親のないカレンダに所有者を割り当てます。再び -dryrun モードで csmig を実行し、新しい所有者を確認します。
カレンダユーザーを 1 台のバックエンドサーバーから別のバックエンドサーバーに移動するにはどうしたらよいですか。
カレンダユーザーを移動するには、元のサーバーにある各ユーザーのカレンダをエクスポート (export) し、次にそのカレンダを 2 台目のサーバーにインポート (import) します。カレンダの移動後、元のサーバー上のカレンダを削除できます。カレンダの移動方法については、「15.6 ユーザーカレンダの管理」を参照してください。
csvdmig ユーティリティーは、複数ドメイン環境で使用するカレンダデータベースおよび LDAP ユーザーおよびグループエントリを準備します。デフォルトドメインしか使用しない場合でも、このユーティリティーを実行する必要があります。
非ドメイン環境を、Calendar Server 6.3 の複数ドメイン環境に移行する場合は、このユーティリティーを使用する前に必ず csmig を実行してください。
ここで説明する内容は次のとおりです。
csvdmig ユーティリティーは、データベースと LDAP エントリに対して次の変更を加えます。
カレンダ ID (calids) の形式が変更されます。
変更前: userid[:calendar-name]
変更後: userid@domain[:calendar-name]
ACL (アクセス制御リスト) のアクセス規則が変更されます。
変更前: userid
変更後: userid@domain
Calendar Server 属性の LDAP ディレクトリサーバーのユーザーエントリが次のように変更されます。
userid[:calendar-name] から userid@domain[:calendar-name]。
カレンダデータベースに含まれる予定と作業の所有者フィールドと出席者フィールドを更新します。次に例を示します。
ドメイン sesta.com の jsmith が予定の所有者である場合、新しい所有者フィールドには jsmith@sesta.com が入ります。
csvdmig ユーティリティーでは、データベースと LDAP ディレクトリに適切な更新を行います。つまり、移行データベースを個別に作成するのではなく、変換中のデータベースを変更します。したがって、念のため、データベースと LDAP ディレクトリのスナップショットに対して csvdmig を実行してください。
csvdmig ユーティリティーの構文は次のとおりです。
csvdmig [-t DestinationDB] [-c ConfigFile] [-e ErrorFile] [-m MappingFile] migrate [DB|LDAP] |
次の表に、csvdmig によって使用されるオプションと、各オプションの説明を示します。
オプション |
説明とデフォルト値 |
---|---|
-m MappingFile |
マッピングファイルを指定する入力パラメータ。マッピングファイルについては、「3.6.2.1 マッピングファイル」を参照してください。デフォルトは MigrateMapping です。 |
-c ConfigFile |
Calendar Server 設定ファイルを指定する入力パラメータ。デフォルトは ics.conf ファイルです。 |
-t DestinationDB |
移行するデータベースの位置を指定する出力パラメータ。デフォルトは MigratedDB です。 ヒント – 常に -t オプションを使用します。 このオプションについて詳しくは、「3.6.2.2 出力先 DB」を参照してください。 |
-e ErrorFile |
解決できないエラー用のエラーファイルの名前を指定する出力パラメータ。デフォルトは MigrateError です。 |
DB | LDAP |
どのデータベースを変更するかを指定します。 DB: カレンダデータベース LDAP: LDAP ディレクトリ デフォルトはカレンダデータベース (DB) です。 |
マッピングファイルは、既存のユーザーをそれぞれのドメインにマッピングする入力テキストファイルです。csvdmig を実行する前に、マッピングファイルを作成する必要があります。古い値と新しい値の間にスペースを入力し、1 行に 1 つのエントリを指定します。次に例を示します。
user1 user1@sesta.com user2 user2@siroe.com user3 user3@sesta.com ... usern usern@siroe.com
移行されるデータベースの場所。ユーティリティーは、ここにあるファイルをアップデートします。csvdmig ユーティリティーを使用する前に、このディレクトリをバックアップしてください。
-t オプションを指定しなければ、ユーティリティーは現在のディレクトリ (コマンド行で pwd を実行することで指定されたディレクトリ) の内容の移行を試行しますが、その結果は予期できません。
次に csvdmig の例を示します。
デフォルト値を使用して、LDAP ディレクトリサーバーのデータを移行します。
csvdmig migrate LDAP
Calendar Server データベースを移行します。
csvdmig -t targetDB -e errorFile -m mappingFile migrate
commdirmig ユーティリティーでは、認証サービスに Access Manager を使用できるように、LDAP データを Sun LDAP Schema バージョン 1 から Schema バージョン 2 に移行します。過去のインストールが Schema バージョン 2 をすでに使用している場合は、このユーティリティーを再度実行する必要はありません。
この移行ユーティリティーは、Schema バージョン 1 の LDAP データベースを Schema バージョン 2 に移行します。Access Manager ソフトウェアを認証に使用する場合は、このユーティリティーを実行して LDAP エントリを Schema バージョン 2 に変換する必要があります。
Access Manager を使用していない場合、Schema バージョン 2 は LDAP を使用するすべての Communications Suite 製品に最適な LDAP モードであるため、LDAP データの移行を検討することをお勧めします。
設定用の LDAP ディレクトリが個別に用意されている場合は、認証用の LDAP だけでなく、その LDAP に対しても commdirmig を実行する必要があります。
カレンダおよび LDAP データベースを、旧バージョンの Calendar Server ソフトウェアから Calendar Server ソフトウェアのバージョン 6.3 に移行するために必要なほかのすべての移行ユーティリティーを実行したあとに、commdirmig を実行します。
commdirmig 移行ユーティリティーには、特別な準備と計画が必要です。このユーティリティーについては別のマニュアルで説明しています。『Sun Java Communications Suite 5 Schema Migration Guide 』を参照してください。
commdirmig ユーティリティーは、Communications Suite インストーラからインストールする Delegated Administrator にバンドルされています。
ユーティリティーのパッチもテクニカルサポートから入手できます。