Exchange 2007 の複数のフォレストにおける自動検出サービスのトラブルシューティング
トピックの最終更新日: 2011-08-01
Microsoft Exchange Server 2007 の自動検出サービスは、Microsoft Office Outlook 2007 クライアントに対して Exchange の各 Web サービスの URL を提供するためのサービスです。また、自動検出サービスは、Microsoft Exchange ベースのメッセージング環境内の Outlook 2007 クライアントに対してプロファイルの自動構成機能も提供します。
Microsoft Exchange を実行しているコンピュータにクライアント アクセス サーバーの役割をインストールするときに、インターネット インフォメーション サービス (IIS) の既定の Web サイトに新しい仮想ディレクトリが作成されます。また、Active Directory ディレクトリ サービスに、サービス接続ポイント オブジェクトが作成されます。このオブジェクトにより、ドメインに接続されて Outlook 2007 を実行しているすべてのクライアントで、Active Directory に対するクエリの実行と Outlook プロファイルの自動構成が可能になります。
多くの組織では、次のような複雑なトポロジを構成しています。
組織内に複数のフォレストがあり、リソース フォレストで Exchange が実行されている。
組織のユーザー アカウントが、複数の異なるアカウント フォレストまたはユーザー フォレストに存在する。
このように複数の信頼されているフォレストが存在する場合、Microsoft Exchange のいくつかの機能では、自動検出サービスを使用して複数のフォレストのユーザー アカウントにアクセスします。たとえば、可用性サービス、オフライン アドレス帳、不在時の応答、およびユニファイド メッセージングといった機能がこれに相当します。このような場合には、複数の信頼されているフォレストに属するユーザーが自動検出サービスを利用できる必要があります。
このトピックの目的は、自動検出サービスの動作を説明することではありません。ここでは、複数フォレストのトポロジにおける自動検出サービスの実装方法について説明します。また、典型的な複数フォレスト環境で実行される自動検出サービスに関するトラブルシューティング情報を提供します。このトピックは、自動検出サービスの展開時の一般的な例や手法を記載した実践的なチェックリストとして利用できます。複数フォレスト環境で問題が発生した場合には、このチェックリストを利用して解決してください。
Microsoft Exchange の自動検出サービスの動作方法、および展開時の考慮事項の詳細については、次のホワイト ペーパーを参照してください。
トラブルシューティング情報
手順 1 : DNS の名前解決の確認
Active Directory では、PDC エミュレータの役割を持つドメイン コントローラがドメイン間の信頼関係を管理します。したがって、各フォレスト内の PDC エミュレータの役割を持つドメイン コントローラが管理対象のフォレストと通信できることを確認する必要があります。そのためには、ping (Packet Internet Groper) ツールを使用して、管理対象のフォレストのドメイン名に接続できるかどうか試してみます。
Exchange 2007 の複数フォレスト組織
この場合は、ping.exe を使用して、通信に関する次の点を確認します。
fourthcoffee.com のプライマリ ドメイン コントローラ (PDC) から northwindtraders.com に対して ping を実行
northwindtraders.com の PDC から fourthcoffee.com (Microsoft Exchange リソース フォレスト) に対して ping を実行
northwindtraders.com の Outlook 2007 クライアントから fourthcoffee.com に対して ping を実行
これらの ping コマンドのいずれかが失敗した場合は、各フォレストの DNS の名前解決について確認する必要があります。たとえば、次のすべての項目を確認します。
DNS クライアントの構成
DNS サーバーのプライマリ ゾーン、セカンダリ ゾーン、およびスタブ ゾーン
DNS フォワーディング オプション、およびルート ヒント オプション
手順 2 : 2 つのフォレスト間の信頼関係のテスト
リソース フォレストとユーザー フォレストの間の信頼関係について確認します。Exchange リソース フォレストとユーザー アカウント フォレストの間には、一方向かつ出力方向の信頼関係が必要です。信頼の構成方法の詳細については、「Create a one-way, outgoing, forest trust for both sides of the trust」を参照してください (このサイトは英語の場合があります)。
複数フォレストのドメイン間の信頼について検証するには、各フォレストのドメイン コントローラで Domain.msc スナップインを実行します。または、次の Netdom.exe コマンドを実行します。
netdom trust <trusted_domain_name> /domain: <trusting_domain_name> /verify
信頼が正常に検証された場合は、次の結果が返されます。
northwindtraders.com と fourthcoffee.com の間の信頼関係が正常に確認されました。 |
アカウント フォレスト (ユーザー フォレスト) ドメインとリソース フォレスト (Exchange フォレスト) ドメインの間に信頼関係を再作成する必要がある場合は、次の手順を実行します。
注 : |
---|
この手順では、northwindtraders.com がアカウント フォレスト内にあり、Fourthcoffee.com がリソース フォレスト内にあると想定しています。 |
アカウント フォレスト内のドメイン コントローラにログオンします。次に、Active Directory ドメインと信頼関係の MMC スナップインを開始します。
[Active Directory ドメインと信頼関係] で、アカウント フォレストの northwindtraders.com を右クリックし、[プロパティ] をクリックします。
[信頼] タブをクリックし、[新しい信頼] をクリックします。
新しい信頼ウィザードで、[次へ] をクリックします。
[名前] ボックスに、リソース フォレストの名前を入力します。この例では「fourthcoffee.com」と入力し、[次へ] をクリックします。
[一方向: 入力方向] をクリックし、[次へ] をクリックします。
[信頼の方向] ページで、[このドメインと指定されたドメインの両方] をクリックし、[次へ] をクリックします。
[ユーザー名とパスワード] ページで、アカウント ドメインの管理者権限を持つアカウントの資格情報を入力します。たとえば、fourthcoffee.com ドメインの Administrator アカウントの資格情報を入力します。[次へ] をクリックします。
[ドメイン全体の認証] をクリックし、[次へ] をクリックします。
[信頼の選択の完了] ページで信頼設定を確認し、[次へ] をクリックします。
[信頼の作成完了] ページで、[次へ] をクリックします。
[入力方向の信頼の確認] ページで、[確認する] をクリックして入力方向の信頼を確認します。[次へ] をクリックして、[完了] をクリックします。
[northwindtraders.com のプロパティ] ダイアログ ボックスで、[このドメインを信頼するドメイン (入力方向の信頼)] に、fourthcoffee.com の信頼が新たに表示されていることを確認します。
手順 3 : リンクされたメールボックスに対するマスタ アカウントのアクセス許可の確認
アカウント フォレスト (northwindtraders.com) の各ユーザー用のリンクされたメールボックスを、リソース フォレスト (forthcoffee.com) に作成する必要があります。リンクされたメールボックスおよび SMTP アドレスへのフル アクセスがマスタ アカウントで可能なことを確認します。そのためには、Get-Mailbox コマンドレットと Get-MailboxPermission コマンドレットを使用します。
詳細については、「リンクされたメールボックスを作成する方法」を参照してください。
これらのコマンドレットを実行すると、次のような結果が表示されます。
Get-Mailbox <mailbox_user> | fl
PrimarySmtpAddress: |
Vandy@fourthcoffee.com |
RecipientType: |
UserMailbox |
RecipientTypeDetails: |
LinkedMailbox |
IsLinked: |
True |
LinkedMasterAccount: |
NORTHWINDTRADERS\Vandy |
Get-MailboxPermission <mailbox_user> | fl
AccessRights: |
{FullAccess, ExternalAccount} |
InheritanceType: |
All |
ユーザー : |
NORHTWINDTRADERS\Vandy |
Identity: |
Fourthcoffee.com/Users/Vandy |
Exchange 管理コンソールを使用して、リンクされたメールボックスをリソース フォレストに作成するには、次の手順を実行します。
Exchange 管理コンソールで、[受信者の構成] の [メールボックス] をクリックし、操作ウィンドウで [メールボックスの新規作成] をクリックします。
[メールボックスの新規作成] ページで、[リンクされたメールボックス] をクリックし、[次へ] をクリックします。
[新しいユーザー] をクリックし、[次へ] をクリックします。
[ユーザー情報] ページで、リソース ドメイン (fourthcoffee.com) のユーザー情報を入力します。たとえば、次のようにユーザー情報を指定します。
フィールド
値
組織単位
Fourthcoffee.com/Users
名
Vandy
名前
Vandy@fourthcoffee.com
ユーザー ログオン名
Vandy
パスワード
<パスワード>
パスワードの確認入力
<パスワード>
[次へ] をクリックします。
[エイリアス] ボックスに、ユーザーのエイリアスを入力します。たとえば、「vandy」と入力します。[次へ] をクリックします。
[マスタ アカウント] ページで、アカウント フォレストのアカウント情報を入力します。たとえば、次のようにユーザー情報を指定します。
フィールド
値
信頼されているフォレストまたはドメイン
Northwindtraders.com
ユーザー名
Northwindtraders\administrator
パスワード
<パスワード>
リンクされたドメイン コントローラ
dc-1.northwindtraders.com
リンクされたマスタ アカウント
Northwindtraders\vandy
[次へ] をクリックします。
[構成の概要] で、リンクされたメールボックスの構成が正しいことを確認します。[次へ] をクリックし、[完了] をクリックします。
[メールボックス - Fourthcoffee.com] 詳細ウィンドウに、新たにリンクされたメールボックスが表示されます。
手順 4 : サービス接続ポイントの Keywords 属性と ServiceBindingInformationService 属性の確認
Export-AutoDiscoverConfig コマンドレットを実行すると、アカウント フォレストに新しいサービス接続ポイント (SCP) オブジェクトが作成されます。この SCP オブジェクトは、リソース フォレストの自動検出サービスの URL を指します。Outlook 2007 クライアントが自動検出要求に応答する SCP を見つけるためには、次の 2 つの属性が必要になります。
Keywords
ServiceBindingInformationService
リソース フォレストでは、これらの属性は次の役割を果たします。
Keywords 属性には、クライアント アクセス サーバー (CAS) が配置されているサイトの名前が格納されます。Keywords 属性はサイト アフィニティを制御します。これは、Outlook 2007 クライアントが、Outlook 要求への応答に最も適した CAS を検出するのに役立ちます。
ServiceBindingInformation 属性には自動検出の URL が格納されます。たとえば、https://<cas_server>.example.fourthcoffee.com/autodiscover/autodiscover.xml といった URL です。
アカウント フォレストでは、これらの属性は次の役割を果たします。
Keywords 属性には、権限のある、承認済みのすべての SMTP ドメインが格納されます。Exchange 管理コンソールでは、この情報は [組織の構成]\[ハブ トランスポート]\[承認済みドメイン] に表示されます。
ServiceBindingInformation 属性には、Microsoft Exchange リソース フォレストの LDAP URL が格納されます (例 : ldap://fourthcoffee.com)。
各 Microsoft Exchange クライアント アクセス サーバーの SCP オブジェクトの Keywords 属性と ServiceBindingInformationService 属性を確認するには、ldifde.exe コマンド、Adsiedit.msc、または Get-ClientAccessServer コマンドレットを使用します。たとえば、次のコマンドを使用します。
Ldifde コマンド
Ldifde -f scp_account.txt -d "CN=Fourthcoffee.com,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Nwtraders,DC=com"
結果
dn: |
CN=Fourthcoffee.com,CN=MicrosoftExchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com |
distinguishedName: |
CN=Fourthcoffee.com,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com |
keywords: |
Domain=Example.com |
keywords: |
Domain=Fourthcoffee.com |
keywords: |
67661D7F-8FC4-4fa7-BFAC-E1D7794C1F68 |
serviceBindingInformation: |
LDAP://Fourthcoffee.com |
Get-ClientAccessServer コマンドレット
Get-ClientAccessServer | fl *Auto*
結果
AutoDiscoverServiceCN: |
CAS_SERVER |
AutoDiscoverServiceClassName: |
ms-Exchange-AutoDiscover-Service |
AutoDiscoverServiceInternalUri: |
https://cas_server.fourthcoffee.com/Autodiscover/Autodiscover.xml |
AutoDiscoverServiceGuid: |
77378f46-2c66-4aa9-a6a6-3e7a48b19596 |
AutoDiscoverSiteScope: |
{Default-First-Site-Name} |
手順 5 : Outlook 2007 クライアントから SCP を検出できるかどうかの確認
SCP の Keywords オブジェクトと ServiceBindingInformationService オブジェクトが存在して適切に構成されている場合は、次に Outlook 2007 クライアントがそれらのオブジェクトを検出できるかどうかを確認します。そのためには、次の手順を実行します。
リソース フォレストの既定のドメイン コントローラに関するグループ ポリシー オブジェクトを変更し、監査を有効にします。
[コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[ローカル ポリシー]、[監査ポリシー] の順に展開します。
詳細ウィンドウで [ディレクトリ サービスのアクセスの監査] をダブルクリックし、[成功] チェック ボックスをオンにして、[OK] をクリックします。
次のポリシーの成功監査を有効にします。
アカウント ログオン イベントの監査
アカウント管理の監査
ディレクトリ サービスのアクセスの監査
ログオン イベントの監査
ポリシーの変更の監査
システム イベントの監査
アカウント フォレストのドメイン コントローラで ADSIEdit.msc スナップインを起動し、fourthcoffee.com の SCP オブジェクトの監査を有効にします。
ADSI エディタで [構成] コンテナを展開してから、次のパスを展開します。
CN=Fourthcoffee.com,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com
Microsoft Exchange 自動検出オブジェクトを右クリックし、[プロパティ] をクリックします。
[セキュリティ] タブをクリックし、[詳細設定] をクリックします。次に [監査] タブをクリックします。
[監査エントリ] の一覧に Everyone グループを追加します。
[アクセス] の一覧で、[成功] 列の [すべてのプロパティの読み取り] チェック ボックスをオンにします。
[OK] を 3 回クリックして、オブジェクトの変更内容を保存します。
Outlook 2007 のプロファイルを作成するか、[電子メールの自動構成のテスト] 機能を使用して、監査イベントを生成します。いずれの方法でも、システム ログおよびセキュリティ ログに次のイベントが生成されます。
システム ログのイベント
ログオンが成功するたびに、システム ログにイベント ID 540 が記録されます。
|
セキュリティ ログのイベント
ユーザーが SCP オブジェクトへのクエリを実行できた場合、セキュリティ ログに次のイベントが記録されます。このイベントの説明にあるオブジェクト名は、アカウント フォレストの SCP です。
イベント ソース : セキュリティ カテゴリ : ディレクトリ サービス アクセス イベント ID : 566 ユーザー : NORTHWINDTRADERS\<UserName> 説明 : オブジェクトの操作 オブジェクトのサーバー : DS 操作の種類 : オブジェクト アクセス オブジェクトの種類 : serviceConnectionPoint オブジェクトの名前 : CN=fourthcoffee.com,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=northwindtraders,DC=com ハンドル ID : - プライマリ ユーザー名 : <UserName> プライマリ ドメイン : NORTHWINDTRADERS |
手順 6 : 証明書の設定の確認
既定では、クライアント アクセス サーバーの役割をインストールすると、自己署名証明書がインストールされます。この証明書は、サーバーの NetBIOS 名に対応する共通名を持っています。自己署名証明書には、証明書の "サブジェクトの別名 (SAN)" フィールドに追加で格納される DNS 名として、サーバーの内部 FQDN も含まれています。これにより、ドメインに接続したクライアントは、証明書の有効期限が切れていない場合に限り、証明書に関する警告を受け取ることなく自動検出サービスに正常に接続できるようになります。詳細については、ホワイト ペーパー「White Paper: Exchange 2007 Autodiscover Service」の「Autodiscover and Certificates」のセクションを参照してください。
注 : |
---|
通常、自己署名証明書は、Windows 証明書サービスを使用して生成した別の証明書、またはサードパーティの証明機関から取得した別の証明書に置き換えます。新しい証明書には、元の自己署名証明書の DNS 名とは異なる名前、または元の自己署名証明書の DNS 名に追加された名前が含まれるのが普通です。このセクションの例は、内部の CA によって生成された証明書に基づくものです。 |
クライアント アクセス サーバーの Exchange 証明書を確認するには、Get-ExchangeCertificate コマンドレットを使用します。このコマンドレットを実行すると、次の属性を確認できます。
CertificateDomains
Services
Status
IsSelfSigned
Issuer
Subject
Get-ExchangeCertificates コマンドレット
Get-ExchangeCertificates | fl
結果
CertificateDomains :{mail.fourthcoffee.com, TX136711-MS1, TX136711-MS1.fourthcoffee.com, Fourthcoffee.com, autodiscover.Fourthcoffee.com } HasPrivateKey :True IsSelfSigned :False Issuer :CN=Fourthcoffee, DC=Fourthcoffee, DC=com Services :IMAP, POP, IIS Status :Valid Subject :CN=mail.fourthcoffee.com |
手順 7 : Export-AutoDiscoverConfig コマンドレットの実行
Exchange 管理コンソールの [組織の構成]\[ハブ トランスポート]\[承認済みドメイン] で権限のある承認済みドメインを新たに作成する場合は、そのたびに Export-AutoDiscoverConfig コマンドレットを実行する必要があります。この操作によって、アカウント フォレスト内の keyword 属性が更新されます。
注 : |
---|
権限のある承認済みドメインを新たに作成する場合、アカウント フォレスト内の keyword 属性は自動的には更新されません。 |
Export-AutoDiscoverConfig コマンドレットを実行する前のキーワード情報は次のようになっています。
dn: |
CN=Fourthcoffee.com,CN=MicrosoftExchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com |
distinguishedName: |
CN=Fourthcoffee.com,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=Northwindtraders,DC=com |
keywords: |
Domain=dallas.com |
keywords: |
Domain=Fourthcoffee.com |
keywords: |
67661D7F-8FC4-4fa7-BFAC-E1D7794C1F68 |
serviceBindingInformation: |
LDAP://Fourthcoffee.com |
ソース フォレストの Exchange CAS サーバーで次のコマンドを実行して、Export-AutoDiscoverConfig コマンドレットを実行するのに必要な資格情報を取得します。
$a = Get-Credential
その後、次の Export-AutoDiscoverConfig コマンドを実行します。
Export-AutoDiscoverConfig -DomainController <FQDN> -TargetForestDomainController <String> -TargetForestCredentials $a -MultipleExchangeDeployments $true
手順 8 : Exchange 2007 Extra.exe ツールの実行
自動検出サービスのトレースを実行するには、Microsoft Exchange トラブルシューティング アシスタント (Extra.exe) を使用します。
[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「extra.exe」と入力し、[OK] をクリックします。
[[ようこそ] ページに移動する] をクリックし、[タスクを選択する] をクリックします。
[トレースを制御する] をクリックします。トレースを解釈するためのモジュールが存在しないことを示すメッセージが表示されたら、[OK] をクリックします。
[手動トレース タグを設定する] をクリックし、トレースの種類を示す次のチェック ボックスをオンにします。
PFD
致命的
エラー
警告
情報
パフォーマンス
機能
[トレースするコンポーネント] の一覧で、次のチェック ボックスをオンにします。
ADProvider
MSExchangeAutodiscover
[トレースを開始する] をクリックします。
結果
次のトレースの結果は、Outlook 2007 のプロファイルが正常に作成されたことを示しています。トレースの結果を確認するには、トラブルシューティングの対象であるユーザー アカウントと、それに対応する UserID を知る必要があります。この例では、ユーザー アカウントは Tim@dallas.com です。
577502E94268MSExchangeAutodiscoverFramework[Provider.base()] Timestamp="16:53:55.5388560";CompterNameHash="1359685320";EmailAddress="Tim@dallas.com";LegacyDN="";UserSID="S-1-5-21-1704072791-1889598559-3047533862-1110"; 57870ADProviderLdapFilterBuilderLdapFilterBuilder::LdapFilterFromQueryFilter - forming LDAP Filter for (&((&((|((Sid Equal S-1-5-21-1704072791-1889598559-3047533862-1110)(MasterAccountSid Equal S-1-5-21-1704072791-1889598559-3047533862-1110)))(ObjectClass NotEqual foreignSecurityPrincipal)))(|((ObjectCategory Equal person)(ObjectCategory Equal msExchDynamicDistributionList)(ObjectCategory Equal group)(ObjectCategory Equal publicFolder)(ObjectCategory Equal msExchPublicMDB)(ObjectCategory Equal msExchSystemMailbox)(ObjectCategory Equal msExchExchangeServerRecipient)(ObjectCategory Equal exchangeAdminService)))(!((&((ExchangeVersion GreaterThanOrEqual 1.0 (0.0.0.0))(Exists(ExchangeVersion)))))))). 57880ADProviderLdapFilterBuilderLdapFilterBuilder::LdapFilterFromQueryFilter - Ldap filter = (&(|(objectSid=S-1-5-21-1704072791-1889598559-3047533862-1110)(msExchMasterAccountSid=S-1-5-21-1704072791-1889598559-3047533862-1110))(!(objectClass=foreignSecurityPrincipal))(|(objectCategory=person)(objectCategory=msExchDynamicDistributionList)(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchPublicMDB)(objectCategory=msExchSystemMailbox)(objectCategory=msExchExchangeServerRecipient)(objectCategory=exchangeAdminService))(!(&(msExchVersion>=1125899906842624)(msExchVersion=*)))). 5799013965FAADProviderADFindADSession::Find using vandyr139404c.nwtraders.com:3268 - LDAP search from , scope 2, filter (&(|(objectSid=S-1-5-21-1704072791-1889598559-3047533862-1110)(msExchMasterAccountSid=S-1-5-21-1704072791-1889598559-3047533862-1110))(!(objectClass=foreignSecurityPrincipal))(|(objectCategory=person)(objectCategory=msExchDynamicDistributionList)(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchPublicMDB)(objectCategory=msExchSystemMailbox)(objectCategory=msExchExchangeServerRecipient)(objectCategory=exchangeAdminService))(!(&(msExchVersion>=1125899906842624)(msExchVersion=*)))), sizeLimit 2, timeout 00:00:30 66130MSExchangeAutodiscoverFramework[LoadProvider()] 'provider "Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider, Microsoft.Exchange.Autodiscover, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is loaded' 661702E94268MSExchangeAutodiscoverFramework[base.GenerateResponseXml()] 'redirectOrError=false; 'Calling provider's WriteConfigXml()' 668003B97E22MSExchangeAutodiscoverFramework[OnLoad()] 'Request is successfully processed' |
詳細情報
詳細については、次のドキュメントを参照してください。