次のリストに、この製品に関して報告されている問題を示します。
ホストドメイン環境の場合、csexport では、calid は完全修飾名である必要があります。たとえば、uid@domain のような形式になります。
状態ファイルが作成されない。
csconfigurator.sh を -saveState オプションを指定して実行し、指定された状態ファイルにパスが含まれていない場合、状態ファイルは作成されません。次に例を示します。
/opt/sun/calendar/sbin/csconfigurator.sh -saveState cs.state
回避方法: 状態ファイルを作成する場所を、常にフルパス名で指定します。
リソースカレンダのデフォルトの出席依頼ステータスは「受諾済み」でならなければならない。
リソースカレンダのデフォルトの出席依頼ステータスは、「受諾済み」でなければなりません。リソースカレンダが出席依頼を受け付けることができないため、リソースカレンダに登録されたユーザーに出席依頼が表示されないことが起こり得ます (「Communications Express」->「オプション」->「カレンダ表示」で、ユーザーが受諾済みの出席依頼のみの表示を選択している場合)。
回避方法: サーバーレベルの自動受諾は、ics.conf のパラメータ resource.invite.autoaccept = "yes" により決定されます。また、icsAutoaccept LDAP 属性を使用して、各リソースレベルで決定することもできます。
定期的な予定に関する問題。
日付以外のフィールドを変更して (storeevents を使用して) dtstart および dtend パラメータを送信すると、データが破壊されます。
回避方法: 日付以外のフィールド変更が必要なストア変更コマンドでは、dtstart および dtend を指定しないでください。
Directory Server がスキーマ 2 で、ドメインが作成されていない場合、Calendar Server 設定プログラムによりエラーメッセージが表示され、この種の Directory Server に対する設定が許可されません。
この問題は、GUI バージョンの設定プログラムのみで修正済みです。コマンド行バージョンの場合は、Delegated Administrator でドメインを作成してから、Calendar Server を設定する必要があります。
Java ES 2005Q1 からのアップグレード後に、Access Manger を使用したシングルサインオンが機能しません。たとえば、Portal Server デスクトップにログインしてから Calendar Server へのアクセスを試みると、シングルサインオンによる自動認証が実行されずにログインページが表示されます。
回避方法: この問題を回避する方法はありません。
フロントエンドおよびバックエンドのインストールを含む Calendar Server 配備をアップグレードしたあと、DWP を使用して通信を行うと、フロントエンドのインストールの開始が失敗し、さまざまなエラーがログに記録されます。この問題は、キャッシュディレクトリが新規インストールにコピーされなかったことが原因です。
回避方法: cld_cache および ldap_cache ディレクトリを /var/opt/SUNWics5/csdb.old から /var/opt/SUNWics5/csdb にコピーします。次に、新規ディレクトリの所有者およびグループを icsuser および icsgroup に設定します。
データベースログファイルが csdb に蓄積される。
ストアデーモンが適切な設定ファイルパラメータを読み込んでいません。存在しない caldb.berkeley.*.enable を検索しています。次に、このデーモンは無効な循環ログのデフォルトを取得します。これは、ホットバックアップが実行されないなど、ほかの問題の原因にもなります。正しい ics.conf パラメータは caldb.berkeleydb.*.enable です。
回避方法: サービスを再起動します。csstored は、累積されたログファイルを削除することでこの問題に対処します。
エクスポートまたはインポートを使用して、異なる calid のカレンダ間でデータを移動することはできません。インポートされるデータには、インポートしようとしているカレンダと同じ calid が必要です。
csrestore がユーザーの個人用カレンダを処理しない。
個人用カレンダの作成およびバックアップを実行したあとで、個人用カレンダを手動で削除します。次に、restore コマンドを使って個人用カレンダを復元します。ログファイルから、カレンダの復元に成功したことを確認できます。ただし、UWC や Calendar Express インタフェースへのログ記録中に、個人用カレンダの表示や管理を実行することはできません。この問題は、csrestore がユーザーの LDAP エントリ、登録済みカレンダ、または独自のカレンダを処理しないことが原因です。
回避方法: csrestore を使用して削除および復元された複数値の属性 icsSubscribed を、ユーザーごとに手動で編集または削除します。
ログインの失敗および過度のセッションタイムアウトメッセージの原因となっているセッションデータベースの破損。
回避方法:
サービスを停止します。
セッションデータベースを削除します。
サービスを起動します。
Calendar Server パッケージには、JMQ クライアントはバンドルされていません。インストールされている Messaging Server から JMQ クライアントを使用します。JMQ が有効になっている場合、JMQ クライアントのインストールに失敗すると、admind
プロセスが異常終了します。
回避方法: Messaging Server バンドルから、JMQ クライアントをコピーしてください。
2007 年 3 月 11 日から 2007 年 4 月 1 日まで、カレンダの予定が 1 時間ずれる
これは、夏時間期間の延長のため、夏時間への切り替え日および標準時間への切り替え日が変更されたために発生します。以前よりも、春 (3 月) の切り替え日が早まり、秋 (11 月) の切り替え日が遅くなりました。Calendar Server 6.3 に付属している時間帯ファイルは、これらの変更を反映するように更新されています。
Calendar Server の時間帯ファイルではなく、JVM の時間帯情報を使用する Communications Express の場合、使用している JVM を更新して、新しい時間帯の変更を取得する必要があります。時間帯データの更新、およびセキュリティーの修正などのそのほかの製品改良を提供する手段として、最新の Sun Java SE JDK/JRE 更新リリースの使用をお勧めします。次のマニュアルで説明されている手順に従って、JVM 更新プログラムを使用してください。
http://java.sun.com/javase/tzupdater_README.html
時間帯情報を更新すると、時間帯の更新前にスケジュールされていた予定は、以前の切り替え日と新しい切り替え日の間、1 時間ずれて表示されます。
要求に応じて、テクニカルサポートから修正用ファイルが入手できます。
単純に、以前の切り替え日と新しい切り替え日の間にスケージュールされている予定の時間を更新するよう、ユーザーに依頼する方法もあります。または、独自のスクリプトを実行して、更新が必要な予定についてデータベースを処理します。
LDAP ツールの場所が変更された
以前の (ベータ) バージョンの Java Enterprise System をインストールしている場合、リリース (RR) バージョンの Java Enterprise System 5 をインストールする前に、SUNWldapcsdk-tools を削除する必要があります。これは、リリースバージョンでは SUNWldapcsdk-tools パッケージの場所が変更されているためです。このパッケージを削除せず、リリースバージョンをインストールして Calendar Server または Messaging Server を起動しようとすると、次のようなエラーメッセージが表示されます。
Could not find .../bin/ldapsearch utility Please install the ldapcsdk-tools package |
このエラーメッセージは、LDAP ツールの場所が変更されているために表示されます。
回避方法: リリースバージョンの Java Enterprise System 5 をインストールする前に、SUNWldapcsdk-tools パッケージを削除してください。SUNWldapcsdk-tools のバージョンを確認するには、コマンド pkgparam -v SUNWldapcsdk-tools VERSION を実行します。
6.00,REV=2006.12.11.00.08 以降のバージョンである必要があります。そうでない場合、LDAP 検索ユーティリティーが見つからないというエラーメッセージが表示されます。
pkgrm SUNWldapcsdk-tools コマンドを使用して、SUNWldapcsdk-tools パッケージを削除してください。
Java Enterprise System 5 インストーラをすでに実行している場合、SUNWldapcsdk-tools パッケージを手動で削除し、次のコマンドを使用してインストールすることができます。
cd <jes5_distro>/Solaris_sparc/Product/shared_components/Packages pkgadd -d . SUNWldapcsdk-tools |
Linux プラットフォームで csmfagent サーバーを起動できない。
カレンダのバイナリは、Linux バージョンでの監視フレームワークの共有ライブラリを検索できません。Monitoring Framework ファイルの正確なパスは /opt/sun/mfwk/share/lib ですが、Calendar Server は、/opt/sun/calendar/lib にあると予期しています。
回避方法: 次の例のように、Calendar Server ライブラリの適切なライブラリにシンボリックリンクを追加します。
# cd /opt/sun/calendar/lib # ln -s /opt/sun/mfwk/share/lib/*.so .
これを実行するもう 1 つの手段として、次のように監視フレームワークライブラリからカレンダサービスを起動する方法があります。/opt/sun/mfwk/share/lib
Linux プラットフォームで、Calendar Server 6.3 へのアップグレード後にログインできない。
この問題は、Calendar Server 6.3 Upgrade 1、パッチ番号 121658-17 で修正されます。この問題の詳細については、このリリースノートの次の節 「Calendar Server の既知の問題」を参照してください。
設定プログラムを使用してバックエンドサーバーを設定すると、プログラムの問題により、完全修飾ホスト名の代わりに IP アドレスが次のパラメータに誤って設定されてしまいます。
caldb.dwp.server.hostname.ip
ics.conf ファイルを編集してパラメータ値を修正する必要があります。修正しないと、システムがバックエンドサーバーを検出できません。正しい値は、バックエンドサーバーの完全修飾ホスト名です。
高可用性パッケージ SUNWcsics には、正常に機能するためのいくつかの更新が必要です。Java Enterprise System ソフトウェアバンドルで使用されるパッケージが正しいパッケージです。この問題を修正するパッチが提供されるまでの間、次の回避方法に従う必要があります。
Calendar Server の配布に含まれる SUNWcsics パッケージを手動で削除します。
pkgadd を使用して、Java Enterprise System ソフトウェアの配布に含まれる SUNWcsics パッケージを追加します。