Troubleshoot Messaging Integration in SharePoint

[アーティクル]
08/25/2016

SharePoint の内部メッセージング統合のトラブルシューティング

Pav Cherny

コードのダウンロード : SharePoint2008_08.exe(416 KB)

適切に設計された SharePoint 環境では、インフォメーションワーカーが共同作業を行うためにコミュニケーションの習慣や仕事のやり方を変える必要はありません。SharePoint を使用すると、定期的にグループ作業サイトを手動で確認することなく、(通知やアラームなどを使用して) ドキュメントやその他の情報をメールボックスに直接配信できます。

ユーザーは配信されたメッセージに返信したり、新しいアイテムを電子メールメッセージとしてドキュメントライブラリやリストに送信することによって、ワークフローに参加することもできます。

ただし、SharePoint® と安全性の高いメッセージング環境を統合することは難しい課題です。この統合により、SharePoint 以外のコンポーネントが SharePoint ベースのコラボレーションに影響を及ぼす可能性が生じます。このような統合環境では、問題が発生する場所にかかわらず、問題の根本原因を効率的に特定して取り除くことが課題となります。

今回のコラムでは、すぐに効果が現れる、実績のあるトラブルシューティング戦略に基づいた SharePoint メッセージングの統合について説明します。問題の発生場所を効率的に特定してから、対象を限定した詳細なトラブルシューティング手順を使用して問題を確認します。

大きな組織では、問題の初期解析を行った後、問題を別の専門家に引き渡すことが、この段階的な調査の定義であるかもしれません。問題が SharePoint 以外のコンポーネントと関係している場合は特にその傾向が強くなるでしょう。一方、中小規模の組織では、1 人の IT 管理者が関連するすべてのシステムのトラブルシューティングを直接行う必要があるのは珍しいことではありません。つまり、中小規模の組織では、構造化されたアプローチを使用する必要性がさらに高いということになります。

実用性を重視したコラムにするために、ここでは Active Directory®、Exchange Server 2007、および WSS 3.0 を使用したテスト環境を使用します。このテスト環境を構築する一連の手順、およびこのコラムと付属リソースで説明しているトラブルシューティングツールは、TechNet Magazine Web サイトのコードダウンロードセクションで入手できます。

一般的なトラブルシューティングのアプローチ

おそらく他の相互運用シナリオよりも、SharePoint のメッセージング統合のトラブルシューティングを行う際には十分に構造化されたアプローチが必要になります。このようなアプローチを実現するのが困難である要因は、いくつかあります。

複雑なテクノロジを扱う必要があることは言うまでもありませんが、メッセージ転送の問題、メッセージ形式の変換、セキュリティの状態、およびディレクトリ管理の問題に取り組んでいると、わかりづらい SharePoint のエラーメッセージに遭遇することがあるでしょう。また、インターネットのニュースグループは、未解決のディスカッションスレッドや間違った方向に物事を進めるように誘導する解決策 (たとえば、メッセージング統合を行うために、SharePoint サーバーの全体管理のアプリケーションプール ID を使用して、すべての Web アプリケーションを実行するなど) であふれています。

しかし、プラスの面もあります。SharePoint は、非常に柔軟性が高い製品です。たとえば、適切な場所を参照すれば、詳細なトラブルシューティング情報を得ることができます。また、少量の基本的なスクリプトを使用して、トラブルシューティングの効率を大幅に向上させることもできます。

トラブルシューティングを行う際の 1 つ目の目標は、対応している問題を理解することです。問題が発生している場所と、その問題に関連しているコンポーネントを特定する必要があります。また、さまざまなシステム構成で問題を再現し、Windows® イベントログとテキストベースのログファイルを詳しく調べてみることもできます。しかし、一部の問題はたまにしか発生しないので、これは厄介な作業になる可能性があります。それでも、問題を再現できれば、その根本原因をさらに早く特定して取り除くことができます。見過ごされることが多いですが、もう 1 つの重要な目標は、構成の変更と修正をすべて記録して、その変更と修正が環境内にある関連しているすべてのシステムに適用されるようにすることです。

SharePoint のメッセージングアーキテクチャ

メッセージングの統合に関する問題に直面したときは、トラブルシューティングを行う前に、まずコーヒーかお茶を飲み、それから SharePoint のメッセージング統合アーキテクチャを確認することをお勧めします。このような手順を踏まないと、違う問題やコンポーネントを修正することになってしまう可能性があります。たとえば、"アクセスが拒否されました" というエラーが表示され、Active Directory で連絡先オブジェクトを作成できない場合、そのエラーは必ずしも Active Directory のアクセス許可を修正する必要があるということを表しているわけではありません (これについては、後で説明します)。

どのような場合も、メッセージングの統合にかかわる各コンポーネントの役割と、個々のコンポーネントの相互作用について理解することは非常に重要です。図 1 は、SharePoint と Exchange Server の接続シナリオにおける重要なコンポーネントを示しています。この詳細については、後続のセクションで説明します。

図 1 SharePoint のメッセージング統合アーキテクチャ (画像をクリックすると拡大表示されます)

診断情報の取得

信頼性の高い診断情報は、最も重要なトラブルシューティングツールの 1 つです。以前から変わらずにあるのは、Windows イベントログです。特に、SharePoint サーバーの全体管理を使用して、SharePoint による Web サーバー上の Windows イベントログへの書き込みのレベルを細かく制御することができるのは有益です (この設定には、[サーバー構成の管理] ページの [ログおよびレポートの作成] で、[診断ログ] をクリックしてアクセスできます)。イベントログとトレースログに記録する、最も重要度が低いイベントを指定できます。詳細な情報を検索する場合は、トレースログ (既定では、%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs にあります) が非常に便利ですが、すぐにいっぱいになるため、この機能は慎重に使用してください。

診断情報を取得するもう 1 つの方法は、付属リソースの Web Application Config.pdf で説明しているように、影響を受けた Web アプリケーションに対応する web.config ファイルを構成して、その Web アプリケーションのデバッグを有効にすることです。SharePoint では、詳細なトレース情報がユーザーインターフェイスに直接表示されます。このアプローチのメリットは、何 MB ものトレースデータを解析しなくても、関連するエラー情報を確認できることです。ただし、Web アプリケーションのシステム構成を変更する必要があるというデメリットがあります。システム構成を変更する際には、元の web.config ファイルをバックアップし、トラブルシューティングが完了したら元の構成に戻すことを忘れないでください。

また、SMTP サービスを構成して、詳細な処理情報を SMTP プロトコルログに書き込むこともできます (これには、IIS マネージャで、[全般] タブの [ログの記録を有効にする] チェックボックスをオンにします)。ODBC ログを使用する予定がない場合でも、付属リソースの SharePoint Messaging Integration.pdf で説明しているように、SMTP サービスの機能を使用する場合は、ODBC のログモジュールも一緒にインストールするようにしてください。このモジュールをインストールしないと、SMTP サービスではプロトコルログの書き込みが行われません。既定では、SMTP プロトコルログは %SystemRoot%\System32\LogFiles\SmtpSvc1 にあります。このログは、SMTP 通信を詳しく分析し、メッセージが SharePoint サーバーから配信されたかどうかを判断するのに使用できるテキストファイルです。

SMTP サービスと通信しているハブトランスポートサーバーでは、送信コネクタと受信コネクタの構成でプロトコルログを有効にすることもできます (詳細については、SharePoint Messaging Integration.pdf を参照してください)。また、メッセージ追跡、キュービューア、パイプライントレースなど他のさまざまなツールを使用して、Exchange Server 2007 環境内のハブトランスポートサーバーやメールボックスサーバー間でメッセージが通過する経路を追跡できます。Exchange Server 2007 のメールフローの問題に関するトラブルシューティングの詳細については、「トランスポートおよびメールフローに関する問題」(go.microsoft.com/fwlink/?LinkID=120145) を参照してください。

Active Directory のドメインコントローラでは、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics にある対応するレジストリエントリを設定し、カテゴリの値を 0x0 にすると、重要なイベントだけがログに記録され、0x5 にするとデバッグ情報を含むすべてのイベントが記録されます。0x3 より大きいログレベルを使用すると、サーバーのパフォーマンスが低下し、Windows イベントログがすぐにいっぱいになります。通常運用時は、すべての値を 0x0 に設定することをお勧めします。

トラブルシューティングを行う際には、SharePoint、Exchange Server、および Active Directory の各サーバーの詳細な診断情報を収集すると、問題が発生している場所をすばやく簡単に特定するのに役立ちます。システム間の通信のほとんどがコンピュータネットワーク経由で実行されるため、TCP/IP ツール (ping、tracert、telnet など) やネットワークモニタなどの、その他のトラブルシューティングツールが役に立つ場合もあります。Microsoft® Network Monitor 3.1 は go.microsoft.com/fwlink/?LinkId=120143 で入手できます。

送信メッセージの転送

関連リソース

イベントログ、トレースログ、プロトコルログ、メッセージ追跡ログ、およびネットワークトレースが準備できたら、SharePoint のメッセージング統合のトラブルシューティングに着手できます。では、まず簡単な部分から始めたいので、送信メッセージの転送について説明しましょう。SharePoint ではさまざまな構成での送信メッセージの転送がサポートされており、Web サーバーのローカル SMTP サービスは必要ありません。ただし、完全なメッセージングの統合シナリオでは、ローカル SMTP サービスを使用するよう構成することをお勧めします。図 2 に、このシナリオの主要なコンポーネントを示します。

図 2 送信メッセージの転送 (画像をクリックすると拡大表示されます)

このメッセージングシナリオは 4 つの段階で構成されています。まず、SharePoint がメッセージを SMTP サービスに転送し、次に SMTP サービスがメッセージを処理して、ハブトランスポートサーバーがメッセージを受信し、最後に Exchange Server 2007 がメッセージを最終的な送信先に転送する必要があります。

SharePoint がメッセージを SMTP サービスに転送できない場合は、通常、電子メールの通知を送信できないことを示すエラーメッセージがユーザーインターフェイスに表示されます。このエラーの原因は SMTP サービスが実行されていないことである可能性があります。また、SMTP プロトコルログには、SMTP サービスがエラーコード 550 (Requested action not taken: mailbox unavailable (要求された操作を実行できません : メールボックスが使用できません)) で送信を拒否したということが記録されている場合もあり、これは SMTP サービスに問題があるということを示しています。

これが SharePoint の問題ではないことを確認するためには、基本的なスクリプトを使用し、同じ送信者と受信者の情報を使用して SMTP サービス経由でテストメッセージを送信します (スクリプトの詳細については、付属リソースの SMTP.vbs を参照してください)。問題の原因が SMTP サービスにある場合は、スクリプトがエラーになります。実際に、図 3 に示しているように、このスクリプトを使用すると問題の根本原因についての重要な手がかりを得ることができますが、残念なことに、デバッグを有効にしいても SharePoint では問題の根本原因が明らかにされません。

図 3 メッセージを中継できないことを示すエラーメッセージ (画像をクリックすると拡大表示されます)

SMTP サービスの構成で Web サーバーの中継許可を与えて、SMTP サービスを再起動すると、SharePoint のメッセージの送信に関する問題を解決することができます。メッセージが SMTP サービスに届くようになったら、SMTP サービスがメッセージをハブトランスポートサーバーに転送できるかどうかが次の重要な問題になります。

メッセージがキューフォルダ内に残っている場合は、SMTP サービスがハブトランスポートサーバーに接続できないことを意味します。これは、Microsoft Exchange Transport サービスが実行されていないこと、またはネットワーク通信や構成に問題があることのどちらかが原因であると考えられます。Telnet クライアントを使用することによって、内部通信用に構成された受信コネクタの宛先ポートに接続できるかどうかをすばやく簡単に確認できます。

宛先ポートは必ずしも TCP ポート 25 というわけではありません。実際、SMTP サービスでこのポートが使用されている場合は、ハブトランスポートサーバーの既定の受信コネクタにメッセージを転送することがありますが、この受信コネクタは匿名で送信されたメッセージをブロックするように構成されています。この場合は、ドロップフォルダにメッセージファイルがあることが確認できます (ただし、Windows SharePoint Services タイマサービスを停止しないと、メッセージが数秒後に消えてなくなるので、このサービスを停止する必要があります)。このメッセージファイルは、"Diagnostic-Code: smtp;550 5.7.1 Client was not authenticated" というエラーで、メッセージが拒否されたことを示す配信状態通知です。

この問題を解決するには、SharePoint サーバー専用の受信コネクタを作成する必要があります。SharePoint サーバーは内部システムであるため、[外部的にセキュリティで保護 (たとえば、IPsec を使用)] 認証オプションを選択します。このようにすると、拡張された権利を匿名ログオンアカウントに与える必要はありません。また、IPsec を使用して、SharePoint サーバーとハブトランスポートサーバー間の通信を保護することも検討してください。

メッセージが SMTP のキューフォルダから配信され、メッセージが正常に転送されたことが SharePoint サーバーとハブトランスポートサーバーの SMTP プロトコルログ (%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive フォルダを確認します) に記録されている場合は、作業が完了したと考えてかまいません。ただし、Exchange Server 2007 がメッセージを宛先に転送できることが前提となります。既に述べたように、メッセージが Exchange 受信者に届かない場合は、Exchange Server 2007 に用意されているメールフローのトラブルシューティングツールを使用して、問題を調査できます。不適切な受信者情報、スパムフィルタ、およびメッセージのサイズ制限が原因で、この段階で最終的なメッセージの送信ができなくなる可能性があります。

受信メッセージの転送

メッセージを逆の方向に転送する場合は、発生する可能性がある問題がさらにわかりにくくなるため、少し複雑になります。たとえば、SharePoint 製品のドキュメントでは、SharePoint の電子メールドメイン用に DNS の MX レコードを構成することが推奨されていますが、この構成を使用すると Exchange Server を使用している組織ではメッセージが適切に転送されなくなる可能性が生じます。

Exchange Server 2007 では、関連付けられているアドレス空間と送信コネクタを使用してメッセージを転送します。SharePoint サーバーが内部サーバーである場合も、インターネット経由で転送するために SharePoint のメッセージがエッジトランスポートサーバーに転送される場合があります。内部メッセージの転送では、詳細なアドレス空間と送信コネクタを使用し、コネクタの構成で SMTP サービスをスマートホストとして実行している SharePoint サーバーを指定します (詳細については、この記事のダウンロードに含まれている SharePoint Messaging Integration.pdf を参照してください)。適切に定義されたルーティングトポロジと専用のブリッジヘッドサーバーを構築することは、Exchange Server から SharePoint に確実にメッセージを転送できるようにするのに役立ちます。

SharePoint サーバーにメッセージが届いたことを確認するには、Windows SharePoint Services タイマサービスを停止します。Windows SharePoint Services タイマサービスがメッセージを処理し、受信者の電子メールアドレスと関連付けられたドキュメントライブラリに添付ファイルを配置するため、このサービスを停止すると、メッセージは図 4 のようにドロップフォルダに蓄積されます。ドロップフォルダにメッセージが配信されない場合は、ハブトランスポートサーバーでキュービューアを使用して、Exchange Server でメッセージが正しく転送されているかどうかを確認します。その後、ハブトランスポートサーバーと SharePoint サーバーの SMTP サービスの通信を妨げている可能性がある、ネットワーク通信の問題が発生していないかどうかを調査します。

図 4 受信メッセージの転送 (画像をクリックすると拡大表示されます)

Windows SharePoint Services タイマサービスを再起動すると、ドロップフォルダからメッセージアイテムが消えていることを確認できます。ただし、Windows イベントログに SharePoint でメッセージが正常に処理されたことが記録されていても、メッセージの添付ファイルが所定のドキュメントライブラリに配置されない場合は、Exchange Server では、メッセージが Exchange の RTF 形式で送信されたということになります。この問題を調査するには、もう 1 度タイマサービスを停止し、Outlook® クライアントから添付ファイルを追加した別のメッセージを送信し、そのメッセージがドロップフォルダに配信されたら、メッセージをメモ帳で開きます。メッセージを開いたら、winmail.dat という文字列を検索します。この文字列が見つかった場合は、Exchange Server では間違った形式でメッセージが送信されていることになります。

SharePoint では、メッセージの添付ファイルが MIME 形式または UUENCODE 形式でエンコードされている必要があります。また、SharePoint では winmail.dat に関連する処理の問題が Windows イベントログに記録されません (図 5 参照)。このような問題が発生した添付ファイルは単にドキュメントライブラリに表示されないだけです。メモ帳をトラブルシューティングツールとして使用し、Exchange 管理コンソールでリモートドメインの定義を SharePoint の電子メールドメイン用に構成することによって、形式に関する問題を解消できます。それには、[ジャーナルレポートの添付用に送信された元のメッセージの形式] タブの [Exchange リッチテキスト形式] で [使用しない] を選択します。

図 5 winmail.dat メッセージの処理 (画像をクリックすると拡大表示されます)

ディレクトリの管理

タイマサービスのさらに便利なイベントの 1 つはイベント 6873 です。これは、不明なエイリアスが原因で、受信メールファイルの処理中にエラーが発生したことを示すイベントです。このイベントは、Exchange ユーザーがメッセージを送信する際に、不適切な SharePoint の電子メールアドレス (たとえば、存在しないドキュメントライブラリ) を指定した場合に発生します。

SharePoint サーバーの全体管理の受信メールの設定で Directory Management Service を構成して、メールが有効になっているドキュメントライブラリ用の受信者オブジェクトを Active Directory に作成することによって、この問題を緩和できます。このように構成すると、Exchange ユーザーは、適切なアドレス情報がを設定された受信者オブジェクトをアドレス帳から簡単に選択できます。

ただし、今度は、これまでとまったく別のトラブルシューティングに関する厄介な問題に対応する必要があることに注意してください。Directory Management Service は、Web サーバーでは管理者特権が必要なので、セキュリティが確保されたシステム構成では、最小特権の原則によりエラーになります。また、製品ドキュメント (technet.microsoft.com/library/cc262947.aspx など) では、Active Directory の SharePoint 受信者オブジェクトに指定した OU で、サーバーの全体管理アプリケーションプールアカウントに "ユーザーアカウントの作成、削除、および管理" の権限を与える必要がある状況が少しおおげさに述べられています。

Directory Management Service では、連絡先オブジェクトとグループオブジェクトが作成されるので、サーバーの全体管理アプリケーションプールアカウントには、この OU 内の連絡先オブジェクトとグループオブジェクトに対するフルコントロールが必要になりますが、ユーザーアカウントに対する管理者権限は必要ありません。製品ドキュメントの説明に従って Web ファームで Directory Management Service を設定し、ドキュメントライブラリでメールを有効にしようとすると、"アクセスが拒否されました" というエラーが発生する可能性が非常に高くなります。

エラー情報では Active Directory の権限に問題があることが指摘されているので、SharePoint の管理者は SharePoint の OU に対するフルコントロールを Everyone にすばやく割り当てるかもしれません。ただし、この方法では Active Directory のセキュリティが脆弱になるだけでなく、問題も解決されません。

構造化されたトラブルシューティングの手順では、まず問題が発生した場所を特定してから、問題が発生している構成を変更する必要があります。このアプローチに従い、ドメインコントローラの Windows イベントログを確認し、ネットワークモニタを使用してネットワーク通信を追跡すると、この問題が発生したときに SharePoint が Active Directory にアクセスしていないことが確認できます。ですから、Active Directory の構成を変更しても問題は解決する可能性は低いと言えます。問題は SharePoint サーバーで発生しています。

残念ですが、この権限の問題についてさらに有益な情報を得るのは非常に困難です。というのも、SharePoint では、Windows イベントログに詳細な情報が記録されないからです。ただし、SharePoint でデバッグを有効にすると、コールスタックを確認できます (図 6 参照)。ここでは、Directory Management Service で SharePoint Web サービスの CreateContact メソッドを使用していることが示されています。SharePoint SDK では、これが Email Integration Web Service (電子メール統合 Web サービス、<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx) であることが通知されます。

図 6 デバッグの結果

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

Web ブラウザで SharepointEmailWS.asmx を確認して、サポートされている操作の一覧を見てみましょう。CreateContact メソッドが表示されています。このメソッドのリンクをクリックすると、Active Directory で連絡先を作成する場合に、この Web サービスに送信する必要がある SOAP メッセージが表示されます。この方法では、スクリプトを使用するトラブルシューティングツールを作成して SharePoint ユーザーインターフェイス以外で作業を行い、テスト実行中に異なるユーザーアカウントをさらに簡単に指定できるので、非常に役に立ちます (ツールの作成については、付属リソースの SharepointEmailWS.vbs を参照してください)。図 7 に、サーバーの全体管理アプリケーションプールアカウントと SharePoint の管理者アカウントを使用してこのスクリプトを実行した場合に返される情報を示します (左側が前者、右側が後者の情報です)。

図 7 2 種類の "アクセスが拒否されました" エラー (画像をクリックすると拡大表示されます)

これらのダイアログボックスには、異なるエラーメッセージが表示されています。どちらのメッセージにもアクセスが拒否されたことが示されています。しかし、左側のエラーには処理の問題が表示されていますが、右側のエラーには表示されていません。では、アプリケーションプールアカウントと SharePoint の管理者アカウントでは一体何が違うのでしょうか。

SharePoint 管理者は SharePoint サーバーのローカル管理者ですが、アプリケーションプールアカウントはそうではありません。Web アプリケーションのアプリケーションプールアカウントをローカル Administrators グループに追加して Web サーバーを再起動すると問題は解決しますが、これはすばらしいお知らせというわけではありません。実稼動の Web サーバーで管理者特権のあるアプリケーションプールアカウントを実行するのは適切ではありません。

なぜアプリケーションプールアカウントにはこのような管理者特権が必要なのでしょうか。ここでも、スクリプトを使用すると、その理由が明らかになります。テスト目的で Web サーバーのローカル Administrators グループの権限をすべてのユーザーに与えると、アプリケーションプールアカウントは Email Integration Web Service (電子メール統合 Web サービス) を使用できますが、SharePoint 管理者を含む他のすべてのアカウントについては、このサービスへのアクセスが拒否された状態を維持できます。つまり、Email Integration Web Service (電子メール統合 Web サービス) では、アクセス制御を判断する基準としてアプリケーションプールの構成を使用しているということになります。

アプリケーションプールの構成は IIS メタベース (IIS 7.0 では、applicationHost.config ファイル) の一部であり、既定ではメタベースへのアクセスはローカル Administrators グループに限定されています。さいわい、IIS 6.0 Resource Kit Tools に収録されている Metabase Explorer を使用して、管理者以外のアカウントにメタベースへのアクセス権を与えることができます。IIS 7.0 では、次のコマンドを実行するだけで、簡単に applicationHost.config ファイルへのフルコントロール権限を与えることができます。

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

要するに、Active Directory で連絡先オブジェクトを作成するには、サーバーの全体管理アプリケーションプールアカウントに、対象 OU の連絡先オブジェクトとグループオブジェクトに対するフルコントロール権限が必要になります。また、Web アプリケーションのプールアカウントには、Web ファーム内の SharePoint サーバーのメタベースに対するフルコントロール権限が必要になります。これらの権限を与えると、SharePoint ユーザーインターフェイスを使用して連絡先オブジェクトを作成できるようになります。

でもちょっと待ってください。まだ続きがあります。Active Directory で受信者オブジェクトを作成することは、ディレクトリを統合する処理の半分にすぎません。これ以外に、Exchange 関連の受信者属性を作成し、サーバーベースのアドレス帳を更新する必要があります。たとえば、Exchange 管理シェルコマンド Update-GlobalAddressList "Default Global Address List" を使用して Exchange Server サーバーのグローバルアドレス一覧を更新すると、Outlook アドレス帳に SharePoint ドキュメントライブラリ用の受信者オブジェクトが表示されるようになります。しかし、これらの受信者にメッセージを送信すると、アドレス情報が適切ではないことが原因で、図 8 のような配信不能レポートが返されます。

図 8 ドキュメントライブラリに配信できないメッセージ (画像をクリックすると拡大表示されます)

IMCEAEX は Internet Mail Connector Encapsulated Address for Exchange の頭文字です。これは、Exchange 以外の受信者アドレスが、従来の Exchange Internet Mail コネクタが処理できる形式でカプセル化されていることを意味します。しかし、最近は Exchange Server 2007 とネイティブな SMTP ベースの送信コネクタを使用して形式の異なるアドレスに対処できるようになりました。

つまり、SharePoint の Email Integration Web Service (電子メール統合 Web サービス) では、Exchange Server 2007 でメッセージを転送する際に必要なアドレス属性が記述されず、名前、姓、表示名、および対象のアドレス (必要に応じて、ms-Exch-RequireAuthToSendTo) の属性だけが書き込まれます。しかし、メールのニックネーム、または従来の Exchange DN やプロキシアドレスを設定したり、受信者オブジェクトと Exchange 受信者ポリシーが関連付けられたりすることはありません。

この問題を解決するには、Exchange 管理シェルの Get-Mailbox コマンドレットを使用して、SharePoint の電子メールドメインをポイントするすべての受信者オブジェクトと対象のアドレスを取得します。次のように出力を Set-MailContact コマンドレットにパイプして、Exchange 受信者ポリシーをアクティブにします。

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

また、Exchange 管理コンソールを使用し、連絡先オブジェクトのプロパティで [電子メールアドレスポリシーに基づいて電子メールアドレスを自動更新する] チェックボックスをオンにして、この問題を解決することもできます。

WSS 3.0 と MOSS 2007 では、既定ですべてのメッセージングの統合がサポートされており、電子メールベースのアラートや通知、ワークフロー、およびドキュメントの送信を有効にすることができます。システムを正しく構成するのは簡単なことではありませんが、メッセージシステムを統合すると従業員の生産性を向上させることができます。具体的には、受信メッセージと送信メッセージの両方が問題なく転送されるようにしたり、ディレクトリを正しく統合したりする必要があります。

SharePoint のエラーメッセージには、わかりづらいものや情報が不足しているものもあります。ですが、今月のコラムでは、統合に関する問題の原因を突き止め、根本原因を特定し、SharePoint サーバーのセキュリティを危険にさらすことなく、その根本原因を解決する方法を説明しましたので、今後は、ぜひこの方法をご活用ください。

Pav Cherny は、主にコラボレーションとユニファイドコミュニケーションに関するマイクロソフトテクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイトペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズサービスの専門企業 Biblioso Corporation の代表取締役です。

目次

図 6 デバッグの結果

その他のリソース