アドレス帳サービスの管理

アドレス帳サーバーの電話番号正規化

Lync Server 2010 では、標準の RFC 3966/E.164 電話番号が必要です。体系に沿っていない形式や一貫性のない形式の電話番号を使用するには、Lync Server では、アドレス帳サーバーを利用して電話番号を前処理してから正規化ルールに渡します。アドレス帳から電話番号が使用され、正規化ルールが適用されると、クライアント (Microsoft Lync 2010、Microsoft Lync 2010 Phone Edition、Microsoft Lync 2010 Mobile など) で、これらの正規化された番号を使用できます。

「新しいアドレス帳の機能」の説明のとおり、以前のバージョンで使用されていた正規化ルールは、いくつかの調整を行わなければ適切に動作しない場合があります。空白文字や不要な文字は正規化ルールの前に削除されるため、特にダッシュや削除された文字を正規表現で検索している場合、正規化ルールがエラーになることがあります。こういった不要な文字を検索していないことと、ルールの想定の場所に文字が存在しない場合にルールが問題なくエラーになって続行するよう、正規化ルールを確認する必要があります。

ユーザー レプリケーターとアドレス帳サーバー

アドレス帳サーバーは、ユーザー レプリケーターが提供するデータを使用して、グローバル アドレス一覧 (GAL) から最初に取得する情報を更新します。 ユーザー レプリケーターは、各ユーザー、連絡先、およびグループの Active Directory ドメイン サービス (AD DS) 属性をデータベース内の AbUserEntry テーブルに書き込み、アドレス帳サーバーはデータベースのユーザー データを、アドレス帳サーバーのファイル ストア内のファイルと、アドレス帳データベース RTCab または RTCab1 に同期します。 AbUserEntry テーブルのスキーマは、UserGuid および UserData の 2 つの列を使用します。 UserGuid はインデックス列で、Active Directory オブジェクトの 16 バイトの GUID を格納します。 UserData はイメージ列で、その連絡先の前述の Active Directory ドメイン サービス (AD DS) 属性をすべて格納します。

ユーザー レプリケーターは、AbUserEntry テーブルと同じ SQL Server ベースのインスタンス内にある構成テーブルを読み取って、どの Active Directory 属性を書き込むかを決定します。 AbAttribute テーブルには、ID、名前、フラグ の 3 つの列があります。 このテーブルはデータベースのセットアップ中に作成されます。 AbAttribute テーブルが空の場合、ユーザー レプリケーターはその AbUserEntry テーブル処理ロジックをスキップします。 アドレス帳サーバーの属性は動的で、AbAttribute テーブルから取得され、アドレス帳サーバーがアクティブ化される際、アドレス帳サーバーによって最初に書き込まれます。

アドレス帳サーバーのアクティブ化により、Lync Server のサポートに必要な値が AbAttribute テーブルに書き込まれます。 次の表にそれらの現在の値を示します。

ID 列の数字は一意である必要があり、再利用は一切できません。 また、ID の値を 256 未満に保つことで、アドレス帳サーバーにより書き込まれる出力ファイルの領域を確保します。 しかしながら、最大 ID 値は 65535 です。名前 列は、ユーザー レプリケーターによって連絡先ごとの AbUserEntry テーブル内に配置される Active Directory 属性名に対応しています。 フラグ 列の値は、属性の種類の定義に使用されます。 次の種類のアドレス帳サーバー属性はユーザー レプリケーターにより認識され、フラグ 列の値の低バイト数で示されます。

アドレス帳のフィルター処理

アドレス帳サーバー ファイルに追加されるユーザーは、AbAttribute テーブルの一覧にある特定の Active Directory ドメイン サービス (AD DS) 属性に基づいて制御できます。 そのようなフィルター処理に使用される属性の 1 つは、msExchangeHideFromAddressBook 属性です。 これは、Exchange スキーマによって追加されるユーザー属性です。 この属性の値が TRUE に設定されている場合、Exchange Server はこの属性を使用し、Outlook のグローバル アドレス一覧 (GAL) で連絡先を非表示にします。 同様に、この属性の値が TRUE の場合、ユーザー レプリケーターはそのユーザーを AbUserEntry テーブルに含め、このユーザーはアドレス帳サーバー ファイルに存在しなくなります。

一部のフラグ ビットを使用して、アドレス帳サーバー属性に対して使用するフィルターを定義できます。 たとえば、特定のフラグ ビットがあることにより、ある属性を include 属性か exclude 属性として指定できます。 ユーザー レプリケーターは、exclude 属性を含む連絡先を除外したり、include 属性を含まない連絡先を除外したりします。

現在は 3 種類のフィルターがあります。 次の表にこれら 3 つのフィルターの一覧を示します。

注:
0x4000 (exclude 属性) と 0x8000 (include 属性) の両方のフラグ ビットが設定されている場合、0x4000 ビットが 0x8000 ビットより優先され、連絡先は除外されます。

アドレス帳をフィルターして特定のユーザーのみを含めることができますが、エントリを制限すると、他のユーザーがフィルターされたユーザーへ連絡したり、プレゼンス状態を参照したりできる範囲が制限されます。 ユーザーは、ユーザーの完全なサインイン名を入力することで、アドレス帳にないユーザーに対する検索、インスタント メッセージの手動送信、手動での通話の開始をいつでも実行できます。 また、ユーザーの連絡先情報は、Outlook や Windows アドレス帳でも検索できます。

アドレス帳ファイルにすべての連絡先レコードがあれば、Lync 2010 による電子メール、電話、セッション開始プロトコル (SIP) が構成されていないユーザーとのエンタープライズ VoIP 通話 (サーバーで エンタープライズ VoIP が有効化されている場合) ができますが、組織によっては SIP 対応のユーザーのみをアドレス帳サーバーのエントリに含める必要がある場合があります。 次の必要とされる属性の フラグ 列の 0x800 ビットをクリアしてアドレス帳をフィルターし、SIP 対応ユーザーのみを含めることもできます。 mailNickname、telephoneNumber、homePhone、および mobile。 また、msRTCSIP-PrimaryUserAddress 属性の フラグ 列に 0x8000 (include 属性) を設定して、アドレス帳をフィルターし、SIP 対応のユーザーのみを含めることもできます。 これは、アドレス帳ファイルからサービス アカウントを除外する際にも便利です。

AbAttribute テーブルを変更した後、コマンドレット Update-CsUserDatabase のコマンドを実行し、AbUserEntry テーブルのデータを更新できます。 UR のレプリケーションが完了した後、コマンドレット UpdateCsAddressBook のコマンドを手動で実行し、アドレス帳サーバー ファイル ストアのファイルを更新できます。

注:
アドレス帳サーバーが配置されているフロント エンドは、管理上構成できません。 1 つは展開中 (通常は最初のフロント エンドの展開時) に選択されます。 障害時、アドレス帳サービスは別のフロント エンドに移動し、管理上の注意は必要ありません。 また、アドレス帳サービスには 2 つのデータベース (RTCab と RTCab1) があります。 データベースは毎日更新されますが、更新されるデータベースは交互です。 RTCab データベースが更新されている場合、更新処理中、クエリは RTCab1 データベースに対して実行されます。 次の日は RTCab1 が更新され、更新処理中、クエリは RTCab に対して実行されます。 これにより、クエリやアドレス帳ファイルの作成において、少なくとも 1 つのデータベースが必ず使用可能となります。

重要:
複数フォレスト展開または親子展開からのインフラストラクチャ統合やその他の変更を行った場合 (Lync Server 2010 への移動前のインフラストラクチャ統合など)、一部のユーザーに対するアドレス帳サービス ダウンロードやアドレス帳 Web クエリにおいてエラーが見つかる場合があります。 複数のドメインやフォレストがある展開内では、問題の発生しているユーザー オブジェクトに属性 MsRTCSIP-OriginatorSid が追加されます。 問題を解決するには、これらのオブジェクトの MsRTCSIP-OriginatorSid 属性を NULL に設定する必要があります。