Exchange データベースに対する名前付きプロパティとレプリカ識別子の制限値の影響について

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

トピックの最終更新日: 2012-03-26

Microsoft では、異なるメッセージング トランスポート コンポーネントを接続するための手段としてメッセージ API (MAPI) を使用しています。MAPI 仕様では、ほとんどのオブジェクトがプロパティとして表されます。これらのプロパティを識別するために、MAPI では、プロパティ ID または PropID と呼ばれる識別子が使用されます。

プロパティ ID は、1 ~ 0xFFFF の範囲の一連の 16 進数の値です。これにより、65,534 個のプロパティを表すことができます。これらのプロパティは、範囲と呼ばれる次のグループに分割されます。

  • 送信可能プロパティ - この範囲は、Exchange がメッセージで送信できるプロパティで構成されています。
  • 内部プロパティ - この範囲は、Exchange によってのみ設定できるプロパティで構成されています。
  • 非送信可能プロパティ - この範囲は、Exchange がメッセージを配信するときに組織の外部には配信されないプロパティを表します。

これらの範囲内のプロパティは、標準プロパティと呼ばれます。標準の MAPI プロパティは固定の ID を持ち、0x8000 未満のすべてのプロパティを表します。

これらの範囲の他にもう 1 つ範囲が存在します。この範囲が最も大きく、0x8000 以上のすべてのプロパティを表します。この範囲内のプロパティは、名前付きプロパティと呼ばれます。名前付きプロパティを使用すると、ベンダが独自のプロパティを追加することで標準 MAPI プロパティを拡張できます。

名前付きプロパティは、次の 2 つの主な種類で構成されています。

  • 名前に数字を使用するプロパティ。これらは、Microsoft Outlook などのプログラムによって使用されるプロパティです。これらのプロパティ名は一般に、ソース ファイル内で定義されます。
  • 名前に文字列の値を使用するプロパティ。これらのプロパティは、"文字列名前付きプロパティ" と呼ばれます。名前に加えて、これらの各プロパティには GUID が関連付けられています。これにより、開発者は、名前付きプロパティをプロパティ セットに分割できます。

名前付きプロパティには一定の ID が割り当てられていないため、MAPI には、名前付きプロパティのために一意の ID を動的に作成し、名前付きプロパティと一意の ID との間で永続的なマッピングを維持する機能が用意されています。ただし、これらの ID が動的に作成されることは、名前付きプロパティのプロパティ ID がコンピュータ間で異なる場合があることを意味します。

Microsoft Exchange Information Store サービスでは、データベースごとに名前付きプロパティのテーブルが保持されています。インフォメーション ストアでは、カスタム情報を含むメッセージを処理するとき、そのカスタム プロパティが以前に処理されたことがない場合は、名前付きプロパティのテーブルにエントリが自動的に追加されます。

インターネット経由で送信されるメッセージは、Message/RFC822 と呼ばれる形式で転送されます。これは、プレーン テキストのメッセージと、一連のキーと値の組み合わせを含むヘッダーが含まれたテキスト形式です。RFC822 には、X-Header と呼ばれる一連のプロパティのサポートが含まれています。

メッセージを Message/RFC822 形式から MAPI 形式に変換するために、Exchange では Imail と呼ばれるコンポーネントが使用されます。Imail は RFC822 メッセージからキーと値の組み合わせを取得し、可能であれば、それらのキーと値の組み合わせを MAPI プロパティに変換します。また Imail では、MAPI プロパティを取得し、それを RFC822 キーと値の組み合わせに変換する双方向の変換も提供されます。

Microsoft Exchange 2000 Server からは、Imail コンポーネントに、"アドホック" ヘッダーと呼ばれるヘッダーのサポートが含まれています。これは、Exchange で将来必要になった際に使用するために保持されるヘッダーです。アドホック ヘッダーの定義に含まれていたヘッダーの種類の 1 つが X-Header でした。そのため、Exchange は、X-Header 情報を後で使用するために格納していました。

たとえば、ある企業が Exchange と統合された新しいアプリケーションを実装し、SMTP X-Header を使用した場合、Microsoft Exchange Information Store サービスでは X-Header を含む最初のメッセージを処理するときに、そのカスタム情報に対する名前付きプロパティが作成されました。

note注 :
以降のメッセージに同じ X-Header が含まれていても、Exchange では、追加の名前付きプロパティは作成されません。

Exchange では、これらの名前付きプロパティが、特定の X-Header を含むメッセージと共に格納されます。Microsoft では、インターネット経由で受信されたメッセージの X-Header をグループ化するために PS_INTERNET_HEADERS 名前空間を公開しました。

名前付きプロパティの制限

次の一覧は、名前付きプロパティに関する重要な点をいくつかまとめたものです。

  • X-Header は、特定の重要な値を保持する、Message/RFC822 メッセージ内のフィールドです。
  • 名前付きプロパティは、特定の値の ID を予約するために Exchange によって使用される方法です。
  • 名前付きプロパティは、0x8000 ~ 0xFFFF のプロパティ ID の範囲に分類されます。そのため、メッセージング データベース (MDB) で作成できる名前付きプロパティの数には制限があります。
  • 名前付きプロパティを割り当てた後、そのプロパティの割り当てを解除することはできません。そのプロパティは、特定の名前と GUID の組み合わせに対して予約されたままになります。
    note注 :
    割り当てられた名前付きプロパティの回復は、技術的には可能です。ただし、このプロセスは現実的でなく、各メッセージを検証してどのプロパティが未使用であったかを判定する間、MDB のマウントを解除する必要があります。

使用可能な名前付きプロパティの数は固定されているため、Exchange はクォータ システムを使用して、割り当てられた名前付きプロパティの数を追跡します。このシステムでは、名前付きプロパティ ID がすべて使用される前に、Store.exe プロセスによって警告が表示されます。2 番目のしきい値に達すると、Store.exe プロセスによって名前付きプロパティ ID は割り当てられなくなります。

名前付きプロパティの消費

多くのプログラムが名前付きプロパティを使用していますが、Microsoft Outlook は名前付きプロパティを最も多く使用します。名前付きプロパティ ID がすべて使用されると、Outlook は名前付きプロパティをマップできません。このシナリオでは、次のような現象が現れることがあります。

  • イベント ID 9666 および 9667 がアプリケーション ログに記録されます。詳細については、「Exchange データベース用の名前付きプロパティまたはレプリカ識別子が消耗したときに受信するイベント 9666、9667、9668、および 9669」を参照してください。

  • マップできないプロパティを含むメッセージは配信されません。影響を受けたメッセージのメッセージ追跡情報には次のような情報が示されています。

    550 5.2.0 STOREDRV.Deliver: Microsoft Exchange Information Store サービスでエラーが報告されました。このエラーの原因を特定するには次の情報が役立ちます。

  • メッセージに名前付きプロパティまたは X-Header を追加するアドインが Outlook にインストールされている場合は、特定のメッセージが組織内の他のユーザーに送信されないことがあります。このシナリオでは、送信側のユーザーが、次のような配信不能レポート (NDR) を受信します。

    このメッセージは受信者側の電子メール システムに到達しましたが、メッセージの配信は拒否されました。メッセージを再送信してください。配信できない状態が続く場合は、システム管理者に連絡してください。

レプリカ識別子

名前付きプロパティの使用可能性を制限している問題によって、パブリック フォルダのレプリカ識別子も影響を受けます。各データベースで使用できるプロパティ ID には、32,767 個という最大制限値があります。特定のデータベースでこの制限値に達した場合、Exchange で新しいプロパティ ID を作成することはできません。

メールボックス データベースでこの問題が発生した場合は、新しいメールボックス データベースを作成し、この新しいデータベースにすべてのメールボックスを移動して、プロパティ ID の制限に達したメールボックス データベースを削除する必要があります。その後で、新しいメールボックス データベースを作成し、そのメールボックス データベースにメールボックスを戻します。

この問題がパブリック フォルダ データベースで発生した場合、回復の手順はより複雑です。この場合は、すべてのパブリック フォルダを別のサーバーにレプリケートし、影響を受けたパブリック フォルダ データベースを削除する必要があります。その後で、コンテンツを元のサーバーにレプリケートして戻します。ただし、パブリック フォルダで既にレプリケーションが構成されている場合は、名前付きプロパティを使い果たしたアイテムが組織内の他のパブリック フォルダにも含まれる可能性があります。これらのデータベースでも、制限値に到達する可能性があります。この問題を回避するには、パブリック フォルダのエージングを構成する必要があります。これにより、名前付きプロパティを消費している可能性のある、アクセスされていない古いコンテンツが削除されます。代わりに、パブリック フォルダ データベースのコンテンツを複数のパブリック フォルダ データベースに分散することもできます。

既定では、Microsoft Exchange Server 2007 の、認証されたユーザーによって作成された名前付きプロパティとレプリカ識別子の制限は 16,384 です。認証されていないユーザーによって作成された名前付きプロパティの既定の上限は 8,192 です。これらの既定の制限値により、プロパティ ID が枯渇するおそれがあることについて事前に通知を受け取ることができます。これにより、データベースが操作不能になる最大制限値に達する前に、何らかの対策を講じることができます。したがって、この制限は、正しく機能していないアプリケーションや悪意のあるサービス拒否攻撃の影響を最小限に抑えるのに役立ちます。名前付きプロパティとレプリカ識別子の数について制限を構成することもできます。制限を構成する手順の詳細については、「Exchange 2007 データベースの名前付きプロパティとレプリカ識別子の制限を構成する方法」を参照してください。

Exchange 2007 SP1 および Exchange 2007 SP2 用の更新プログラムのロールアップ 8 での X-Header の変更

Exchange Server 2007 SP1 用の更新プログラムのロールアップ 8 から、Exchange による X-Header のサポート方法が変更されました。

note注 :
これらの変更は、Exchange 2007 Service Pack 2 (SP2) にも含まれています。

以前の Exchange ビルドでは、データベース レベルで X-Header が昇格されています。そのため、特定のユーザーがデータベース上の名前付きプロパティをマップすると、そのデータベース上の他のユーザーも、名前と GUID の組み合わせに対して同じプロパティ ID を受信します。更新プログラムのロールアップ 8 以降では、どのアクティビティが X-Header 値を格納するために名前付きプロパティを消費できるかに関する規則が新しく実装されています。

note注 :
特定の X-Header 値に対する名前付きプロパティが既にデータベース上で昇格されている場合、そのプロパティは、更新プログラムのロールアップ 8 以降では削除されません。既存の X-Header マッピングが保持されます。ただし、Exchange が、データベース上で昇格されていない X-Header を含むメッセージを受信した場合は、新しい X-Header 昇格規則が有効になります。

新しい X-Header 昇格規則を使用すると、新しい名前付きプロパティを消費して X-Header データを保持していた多くのシナリオが機能しなくなります。ここでは、これらのシナリオのいくつかについて説明します。

X-Header の保持に名前付きプロパティを消費しなくなったシナリオ

匿名の発信

インターネットからの匿名の電子メール メッセージが、X-Header の名前付きプロパティを消費しなくなりました。匿名の電子メール メッセージからの既存の X-Header 情報は保持されますが、X-Header の値は、電子メール メッセージ上のプロパティとしては保存されません。

埋め込みメッセージ

埋め込みメッセージ機能は、MAPI アプリケーションに対する相互運用性の機能として作成されました。この機能を使用すると、エンベロープまたは最上位レベルのプロパティを設定できます。この機能による埋め込みメッセージが、新しい名前付きプロパティを消費しなくなりました。

ジャーナル メッセージ

ジャーナル メッセージは、Exchange で最大量の X-Header を消費します。次のシナリオについて考えます。

  • 組織内に 100 個のデータベースと 1 個のジャーナル データベースがあります。
  • 各メッセージング データベース (MDB) は、インターネットから 1 か月あたり 100 個の新しい X-Header に公開されています。

このシナリオでは、ジャーナル MDB に毎月 100 x 100 個の新しい X-Header が必要になります。そのため、使用可能な名前付きプロパティをすぐに使い果たしてしまいます。

note注 :
ジャーナル メッセージによって新しい X-Header マッピングは昇格されなくなりますが、ジャーナル コンテンツは引き続き期待どおりに保存されます。たとえば、ジャーナル処理されたレポートやメッセージは引き続き保存されます。

X-Header の保持に引き続き名前付きプロパティを消費するシナリオ

認証されたユーザー

認証されたユーザーは、引き続き X-Header が昇格されるメッセージを作成できます。

MAPI アプリケーション

MAPI アプリケーションは、引き続き名前付きプロパティを作成できます (PS_INTERNET_HEADERS 名前空間に配置されるプロパティは X-Header になります)。また、プロパティのマッピングを使用する Exchange Web サービス アプリケーションも名前付きプロパティを作成できます。これらのプロパティも X-Header にできます。

note注 :
MAPI から X-Header を使用しているアプリケーションを変更する必要はありません。アプリケーションは、名前付きプロパティの組み合わせの ID を正しく要求する必要があります。たとえば、アプリケーションは PS_INTERNET_HEADERS と "X-<ヘッダー文字列>" を要求する必要があります。

要求で MAPI_CREATE フラグを使用した場合は、MDB に保持されている X-Header の一覧に特定の X-Header がアプリケーションによって自動的に追加されます。また、アプリケーションが、PS_INTERNET_HEADERS 名前空間で名前付きプロパティのマッピングを作成することによって MAPI から X-Header を設定すると、X-Header のマッピングがすぐに作成されます。Exchange は、受信メッセージのこのマッピングを保持し、送信メッセージのマッピングを生成します。

important重要 :
アプリケーションが名前付きプロパティ ID の要求時に MAPI_CREATE を使用していない場合、また、PS_INTERNET_HEADERS 名前空間に分類される名前を要求し、別のクライアントがまだその ID を要求していない場合、そのアプリケーションは機能しません。そのアプリケーションは、承認されたクライアントまたは MAPI クライアントが名前で X-Header を要求した後に機能します。

Exchange 2010 でのプロパティの変更

Exchange Server 2010 では、このドキュメントで説明されている問題に対処するために、さらに機能が強化されています。Exchange 2010 では、名前付きプロパティのリソースはデータベース レベルではなく、メールボックス レベルに移動されます。

詳細情報

データベースの管理の詳細については、「ストレージ グループとデータベースの管理」を参照してください。

Exchange 2007 のセキュリティ機能と保護機能の詳細については、「セキュリティと保護」を参照してください。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。