Zimbra GALの自動同期を設定して動作を確認する方法

ZimbraにおけるGAL自動同期の実際の動作

ユーザーがグローバルアドレス一覧（GAL）を検索できるにもかかわらず、新しく作成または変更された連絡先がかなり後になってから表示される場合、通常は「GALが無効になっている」という問題ではありません。多くの場合、GAL同期アカウントは存在しているものの、データソースのポーリング間隔が長すぎる、データソースが無効になっている、または最後にスケジュールされた同期が失敗したことが原因です。

Zimbraの最新版Daffodil（v10）管理者ガイドでは、GALはドメインごとの機能であり、内部、外部、両方の3つのモードがあると説明されています。GAL同期アカウントは、同期されたGAL連絡先をアドレス帳に保存し、クライアントがオートコンプリートやブラウジングをより高速に行えるようにします。Zimbraはまた、GAL同期アカウントが利用できない場合、システムは従来のLDAPベースの検索にフォールバックできるとも述べています。この点は重要です。検索が成功したからといって、スケジュールされたGAL同期が正常に機能しているとは限りません。

参考資料：Zimbra Daffodil v10 管理者ガイド。

変更を加える前に、現在のGALモードと同期アカウントを確認してください。

zimbraオペレーティングシステムのユーザーとして管理者コマンドを実行します。

su - zimbra
zmprov gd example.com | egrep 'zimbraGalMode|zimbraGalMaxResults|zimbraGalAccountId'

実際のZimbraドメインに置き換えてくださいexample.com。最初に役立つ結果はGALモードです。

• 内部情報：GALデータはZimbra LDAPディレクトリから取得されます。
• 外部：GALの検索と同期には、Active Directoryなどの外部LDAPディレクトリが使用されます。
• 両方：Zimbraは内部および外部のGALソースを組み合わせて使用​​します。

よくある誤解： GALモードとGAL同期は同じ設定ではありません。GALモードは、ディレクトリ情報の取得元をZimbraに指示するものです。自動同期は、GALデータソースとそのポーリング間隔によって制御されます。対処法：無関係なオートコンプリート設定を変更する前に、まずドメインモードを確認し、次にデータソースを調べてください。

スケジュールを編集する前に、GAL同期データソースを確認してください。

ドメインに既にGAL同期アカウントが存在する場合は、そのデータソースを一覧表示します。

zmprov gds galsync@example.com

次のような値を探してください。

zimbraDataSourceName: InternalGAL
zimbraDataSourceEnabled: TRUE
zimbraDataSourcePollingInterval: 1d
zimbraGalLastSuccessfulSyncTimestamp: ...
zimbraGalLastFailedSyncTimestamp: ...
zimbraGalStatus: enabled

正確なデータソース名は異なる場合があります。InternalGALは内部データソースの一般的な名前です。外部データソースにはExternalGAL、ADGAL、 、または管理者が選択した名前が付けられる場合があります。

Zimbraのテクニカルセンターのドキュメントによると、データソースのポーリング間隔によって、自動インポートの頻度が決まります。最新のv10管理者ガイドにも記載されているように、この間隔は日、時間、分、秒で指定でき、データソースごとに設定します。

参照：Zimbraテクニカルセンター：GAL同期アカウント。

実用的なGALポーリング間隔を設定する

既存のデータソースを1時間ごとに同期するように変更するには：

zmprov mds galsync@example.com InternalGAL   zimbraDataSourcePollingInterval 1h

その他の例としては30m、、、12hまたはなどがあります。Zimbra の公開スキーマ ドキュメントでは、、、、など1dの期間単位を使用しています。hmsd

間隔を短くすれば必ずしも良いとは限りません。小規模な内部ディレクトリであれば、1時間間隔が妥当な場合もあります。しかし、大規模な外部LDAPディレクトリやWAN接続のActive Directoryでは、頻繁なポーリングによってディレクトリやメールボックスサーバーに不要な負荷がかかる可能性があります。対策：ディレクトリの変更をどれだけ迅速に反映させる必要があるか、また、環境における完全同期または増分同期のコストを考慮して、適切な間隔を選択してください。

よくある誤解： forceSync自動同期を設定するものではありません。即座に同期を開始します。繰り返しスケジュールはから取得されますzimbraDataSourcePollingInterval。対処法：まず間隔を設定し、その後強制同期を使用して設定を即座に検証してください。

設定を確認するために、強制的に同期を実行します。

間隔を設定した後、即座に同期をトリガーします。

zmgsautil forceSync -a galsync@example.com -n InternalGAL

によって返される正確なデータソース名を使用してくださいzmprov gds。Zimbra の公式テクニカル センターのドキュメントでは、内部および外部の GAL データ ソースの両方にこのコマンドを使用しています。

次に、データソースを再度検査します。

zmprov gds galsync@example.com | egrep 'zimbraDataSourceName|zimbraDataSourceEnabled|zimbraDataSourcePollingInterval|zimbraGalLastSuccessfulSyncTimestamp|zimbraGalLastFailedSyncTimestamp|zimbraGalStatus'

有用な検証結果とは、単に「コマンドが明らかなエラーなく返された」というだけではありません。直近の同期成功タイムスタンプ、有効になっているデータソース、想定されるポーリング間隔、そして操作が繰り返し失敗していることを示す新たな同期失敗タイムスタンプがないことを確認する必要があります。

管理コンソールからGALの自動同期を設定する方法

新規ドメインまたは再構成されたドメインの場合、Zimbra v10 でサポートされているグラフィカルパスは、ドメインの GAL 構成を経由するものです。

1. Zimbra管理コンソールを開きます。
2. 「設定」→「ドメイン」に進みます。
3. 必要なドメインを選択してください。
4. ドメインアクションから「GALの設定」を開きます。
5. 必要に応じて、 「内部」、「外部」、または「両方」を選択してください。
6. GAL同期アカウント名とデータソース名を確認してください。
7. GALのポーリング間隔を設定します。
8. ウィザードを完了したら、zmgsautil forceSyncすぐにテストが必要な場合に使用してください。

v10 管理者ガイドには、GAL モードが「両方」の場合、LDAP データソースごとにアドレス帳が作成されることが明記されています。また、同期によって手動で行った変更が上書きされる可能性があるため、同期されたアドレス帳を直接編集しないよう管理者に警告しています。対処方法：ディレクトリの変更は、GAL 同期アカウントで生成されたアドレス帳ではなく、権限のある LDAP ソースで行ってください。

GAL同期アカウントが存在しない場合はどうなりますか？

新規導入の場合は、ドメイン、GALアカウント、データソースの関係を常に一定に保つことができるため、可能な限り管理コンソールを使用してください。

Zimbraのテクニカルセンターでは、CLIの作成方法についても説明していますzmgsautil createAccount。内部GALの例を以下に示します。

zmgsautil createAccount   -a galsync@example.com   -n InternalGAL   --domain example.com   -s mailstore.example.com   -t zimbra   -f _InternalGAL

メール-sボックスサーバーオプションについては、ZCS 8以降のバージョンに関するテクニカルセンターの記事に記載されています。コマンドラインの動作はリリースやパッケージによって異なる場合があるため、zmgsautil古いコマンドをそのままコピーするのではなく、新しいアカウントを作成する前にインストール済みのサーバーのヘルプを確認してください。

よくある誤解：一般的なアカウント削除コマンドで破損したGALアカウントを削除することは、GALユーティリティを使用して削除することとは異なります。Zimbraのテクニカルセンターでは、GALアカウントを誤って削除すると、ドメインがzimbraGalAccountId無効なアカウントを指したままになる可能性があると警告しています。対処法：zmgsautil deleteAccount GALアカウントを削除して再作成する必要がある場合は、通常のメールボックスアカウントのように扱うのではなく、ドキュメントに記載されている手順に従ってください。

参考資料：Zimbra テクニカルセンター：GAL アカウントの削除、作成、および強制同期。

外部LDAPまたはActive Directory：どのような変更がありますか？

外部GALを使用する場合、スケジュールされたメカニズムは依然としてGALデータソースのポーリング間隔ですが、同期の成功は、サーバーURL、バインドDN、バインドパスワード、検索ベース、フィルタなどの外部LDAP構成にも依存します。

Zimbraのドキュメントによると、最初の外部データソースはドメインからGAL構成を継承できます。追加のデータソースは、独自のLDAP接続設定で構成できます。外部同期が失敗した場合、ポーリング間隔を短くしても、バインドパスワードの誤り、LDAPホストへの到達不能、検索ベースの誤り、TLSの問題、または想定されるユーザーを除外するフィルタの問題は解決されません。

対処方法：失敗した場合はforceSync、外部ディレクトリへの接続とフィルタリングを確認してから、間隔をさらに短くしてください。

自動同期が実際に機能しているかどうかを確認する方法

設定後、以下の簡単な検証チェックリストを使用してください。

オートコンプリート機能だけを唯一のヘルスチェックとして使用しないでください。Zimbraは同期アカウントが利用できない場合、LDAPベースのGAL検索にフォールバックできるため、スケジュールされたGALアドレス帳の同期が古い場合でも、ユーザーは名前を見つけることができる可能性があります。

スケジュールは正しく見えるのにデータが古いままの場合のトラブルシューティング

同期タイムスタンプの失敗を確認する

タイムスタンプが前回の正常実行時よりも新しい場合zimbraGalLastFailedSyncTimestamp、スケジューラは正しく動作しているものの、データソースに問題がある可能性があります。これは「自動同期が無効になっている」場合とは異なります。対処法：ポーリング間隔を繰り返し変更するのではなく、データソースのトラブルシューティングを行ってください。

同期試行前後のメールボックスログを確認してください。

Zimbraは、/opt/zimbra/log/mailbox.logメインのmailboxdアクティビティログとして記録します。これを使用して、強制またはスケジュールされたGAL操作の前後に発生したエラーを関連付けることができます。

tail -f /opt/zimbra/log/mailbox.log

本番システムでは、必要でログ量の増加を理解している場合を除き、広範囲なデバッグログを有効にすることは避けてください。

重複する連絡先が表示される場合は、重複するデータソースを確認してください。

Zimbraは、検索範囲が重複する複数のGALデータソースが重複エントリをインポートする可能性があることを指摘しています。システムはこれらの重複を自動的に調整しません。対処方法： LDAP検索ベースを絞り込むか、フィルタを設定して各データソースのスコープを明確にしてから、新しい同期を実行してください。

既存のGAL同期アカウントの名前を変更しないでください

最新のZimbra v10管理者ガイドによると、作成後に名前を変更すると同期が壊れる可能性があるとのことです。名前を変更するには、サポートされている手順を使用してGAL構成を削除し、再作成してください。対処方法：運用上の正当な理由がない限り、正常に動作しているGAL同期アカウント名は変更しないでください。

推奨される構成パターン

一般的な単一ドメイン展開の場合、信頼性の高いアプローチは次のとおりです。

• ディレクトリ構造に適したGALモードを維持してください。
• ZimbraのGAL設定ワークフローを通じて作成された専用のGAL同期アカウントを使用してください。
• 各データソースは有効のままにしてください。
• ディレクトリ変更の許容遅延時間に合わせてポーリング間隔を設定してください。
• zmgsautil forceSync即時検証またはトラブルシューティングのみに使用してください。
• ユーザーのオートコンプリートだけでなく、データソースのタイムスタンプを使用して成功を確認してください。
• 外部LDAPの場合、接続性、バインド認証情報、検索ベース、およびフィルタを個別の依存関係として扱います。

これらのチェックに合格すれば、Zimbraは設定されたスケジュールに従ってGAL同期アドレス帳を更新します。タイムスタンプの更新が停止したり、強制同期が失敗した場合は、次のステップは間隔を短くすることではなく、スケジュールされたジョブの完了を妨げているデータソースまたはLDAPエラーを特定することです。