MSExchange ADAccess イベント 2937

もう今更ですが、Exchange パブリックフォルダーを削除した際によく見かけるイベントです。
なお、Exchange のバージョンは 2010 以降が該当します。

MSExchange ADAccess, Event ID: 2937
プロセス MSExchangeTransport.exe (PID=9356)。
オブジェクト [CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com]。
プロパティ [RemotePublicFolderMailboxes] が値 [contoso.com/Deleted Objects/PublicFolderMailbox DEL:d980f9a4-2014-4165-aad0-7ab91b35ef01] に設定されています。
これは Active Directory 内の Deleted Objects コンテナーをポイントしています。このプロパティは速やかに修正する必要があります。

上記プロセスは、Exchange で使っているものなら、何でも出ます。
パブリックフォルダーの削除で、そのデータベースを参照しているすべてのオブジェクトが変更されず、一部の情報が残ってしまったわけです。
この場合は、イベントログに出ている Active Directory オブジェクトを削除する、つまり、ADSI エディターで、削除されたパブリックフォルダーデータベースの参照を削除することでイベントを消すことができます。

対処方法

  1. Exchange PowerShell で RemotePublicFolderMailboxes のプロパティを確認しておきます
    Get-OrganizationConfig | Select RemotePublicFolderMailboxes
    今回のケースでは pFContacts という属性名になります
  2. ドメインコントローラーで ADSI エディターを起動します
  3. Configutation コンテキストを開きます (「既知の名前付けコンテキストを選択または入力する」から「構成」を選択する)
  4. 警告イベントに表示されているオブジェクトを辿り (上記ケースでは CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com です)、プロパティを開きます
  5. 属性エディターから削除されたパブリックフォルダーデータベースが記載されている属性を探します (今回は pFContacts)
  6. その属性の値を削除します
    なお、複数のパブリックフォルダーデータベースを使っている場合、全部消してはいけません

パブリックフォルダーデータベースが 1 つの場合には、
Set-Organization​Config -RemotePublicFolderMailboxes $null
でもよいです。
Exchange 系のサービスは特に再起動する必要は無いですが、可能であれば、再起動しておいた方が気分的にはいいかも。

Exchange で Information Store のメモリ最大値を制御する

Exchange ネタが続きます。

Exchange は、バージョン5.5 より、Dynamic Buffer Allocation という仕組みでメモリを使用しています。
手っ取り早く説明すると、余っているメモリがあれば、Information Store が管理するメールボックス(データベース)の
パフォーマンス向上のためにどんどんメモリを使いますってことなんです。
DBA は、Exchange のメールボックスを管理するサービスである Information Store サービスで主に使用しています。
Exchange 専用サーバーで運用している場合には、非常にありがたいのですが、Exchange 専用サーバーではなく
複数のサーバーアプリを動かすような環境だと、ちょっとやっかいです。一応、DBA は、他からのメモリ確保要求が
あった場合には、動的にメモリ量を減らすのですが、なかなか、思うように減らしてくれません。
そうなると、Exchange がどんどんとメモリを使ってしまい、他のアプリで使えるメモリが少なくなるという事態に陥ります。

実は、DBA では、チューニングすることで、最大メモリ量を制御することができるので、それを紹介します。
ただし、Active Directory 内に格納されている Exchange の設定を変更することになりますので、十分注意してください。

  1. ADSI Edit を起動する
  2. Active Directory の構成情報である CN=Configuration, DC= XXX, … に接続する
  3. 2 の下にある CN=Services を開く
  4. 3 の下にある CN=Microsoft Exchange を開く
  5. 4 の下にある “Exchange 組織” を開く
  6. 5 の下にある CN=Administrative Groups を開く
  7. 6 の下にある CN=Exchange Administrative Groups(FYDIBOHF23SPDLT) を開く
  8. 7 の下にある CN=Servers を開く
    この下に ”メールボックスの役割” をインストールしているサーバー(CN=サーバー名)があるはずです
  9. 8 の CN=サーバー名 の下にある CN=InformationStore を開き、右クリックのプロパティを表示する
  10. プロパティ画面の中から、msExchESEParamCacheSizeMax を探す

こんな感じです。

ここの値を編集します。ここには、ページ数で指定したメモリ量を入力します。
Exchange のメールボックス データベースは、1 ページ 8KB 単位で構成されているため
例えば、最大のメモリサイズを 16GB(16 × 1,024 × 1,024 = 16,777,216KB)にしたいという場合には、

16,777,216 ÷ 8 = 2097152

と入力します。
なお、上記ダイアログでは、メモリ量を 2G にしたいので、262144 と入力しています。
(実験用サーバーでそんなにメモリがない…うう)
設定を変更したら、Information Store サービスを再起動する必要がありますので、注意してください。
また、設定変更は、Active Directory の GC(グローバルカタログ)で行うようにしてください。

こんな感じで、メモリ喰いの Exchange Information Store のメモリを制御することができます。
なお、今回のネタは、Exchange 2007 & 2010 をターゲットとした内容ですが、Exchange 2000、2003 でも
同じようにできると思います。

ただし、本番環境では、DBA の最大メモリ量をチューニングするのではなく、

”Exchange メールボックスの役割” は専用サーバー(他の Exchange の役割は入れない、かつ、他アプリも動かさない)で運用する

ことを推奨します。

Exchange Server 2007 SP2 Rollup2 で注意

普段、このブログでは開発ネタが多いのですが、個人的には、Exchange に携わっている期間(5.5 から)が非常に長くて
実はガンガンに使っています。一応、MCITP の メッセージングも取得済みだったりします。
そんなわけで、TechNet フォーラムには、Exchange によく出没しているのです。
…と、そんな前書きはどうでもよく、2010/1/22 に Exchange Server 2007 SP2 Rollup2 がリリースされました。

Rollup2 の前、つまり、Rollup1 をインストールすると、Exchange 管理コンソールにある “ツールボックス”
をクリックすると、エラーが発生するという問題がありました。

レジストリの値(詳細は下記記事を参照)が、日本語版だと、日本語名称にしてしまうというローカライズの
問題です。この内容は、KB および 日本の Exchange チームブログにも記載されています。

で、Rollup2 がリリースされたわけですが、なんと、Rollup2 でも修正されていませんでした…。

私の環境は、Exchange 2007 SP2 RU1 で、上記ブログを見て、自分でレジストリを修正したのですが、
この環境に RU2 をインストールしたら、まんまと、元(つまり、RU1 と同じ状態)に戻されてしまいました。

つまり、

Exchange 2007 SP2 → RU1 インストール → ツールボックスでエラーでガックシ → レジストリ修正でうまー
→ RU2 インストール → ツールボックスでエラーでガックシ → レジストリ修正でうまー

です。
まだ RU1 をインストールされていない方は、RU1、RU2 をインストールした後にレジストリを修正してください。

OS 起動時に Exchange 2007 のマネージコードサービスがタイムアウト

最近、Exchange 2007 と戯れています。はぁ~。
Exchange 2007 ロールアップ 5 を適応すると、ありがちなトラブルなので、ネタにしておきます。
一応、KBには載っています。

  • Exchange 2007 用更新プログラムのロールアップをインストールすると Exchange 2007 マネージ コード サービスが開始されない
    http://support.microsoft.com/kb/944752/

原因も記載されていますので、読んでおくと良いと思います。
で、Workarounds ですが、SCM 全体の設定を変更することになるので、少しためらう方もいると思います。
(試したところ、ワタシの環境では、120 秒の設定で起動するようになりました…トホホ)

色々と探してみたところ、MSFT の Exchange Team Blog にネタがありました。

構成ファイルに generatePublisherEvidence 属性を追加してあげれば、起動時の署名チェックをバイパスできるとのこと。
少しファイルが多いので面倒ですが、こっちの方がよさそうです。
ワタシもこの方法で回避しています。