Exchange Serverの自動検出サービス
自動検出 サービスにより、クライアントは、Exchange の機能にアクセスにできるようになり、ユーザーによる構成手順と展開手順は最小限に抑えられます。 Exchange Web サービス (EWS) クライアントの場合、通常、自動検出 は EWS エンドポイント URL を見つけるために使用されます。 ただし、自動検出 は、別のプロトコルを使用するクライアントを構成するための情報も提供できます。 自動検出 は、クライアント アプリケーションがファイアウォールの内側または外側に存在するシナリオや、リソース フォレスト内および複数のフォレスト内に存在する場合に機能します。
Exchange 2016 では、以前に複数のサーバーによって処理されていたサービスに対する変更が導入されました。 メールボックス サーバーはクライアント アクセス サービスを提供するようになったため、以前のバージョンの Exchange では可能であった、スタンドアロンのクライアント アクセス サーバーの構成はできなくなりました。 Exchange 2016 および Exchange 2019 の自動検出サービスは、次の理由で可能です。
Exchange は、インターネット インフォメーション サービス (IIS) の既定の Web サイトの下に という名前
autodiscoverの仮想ディレクトリを作成します。Active Directory では、ドメインに参加しているコンピューターの権限のある URL が格納され、提供されます。
メールボックス サーバー上のクライアント アクセス サービスは、内部および外部のクライアント接続に対して認証とプロキシ サービスを提供します。
Outlook では、ユーザー名とパスワードのみを使用してサービスを構成します。
注:
Outlook クライアントを Exchange サーバーに接続するためのユーザーの手順については、「Outlook のメールを設定する」を参照してください。
自動検出 サービスと Active Directory
Exchange は Exchange サーバーの構成と、ユーザーのメールボックスに関する情報を Active Directory に保存します。 Exchange Serverをインストールする前に、Active Directory フォレストとそのドメインを準備する必要があります。 Exchange フォレストまたはドメインに慣れていない場合は、「 手順 3: Active Directory ドメインを準備する」を参照してください。
Exchange は、クライアントが接続するフロントエンド クライアント アクセス サービス Web サイトである IIS の仮想ディレクトリ autodiscover をインストールするときに自動的に作成します。 これにより、Outlook は Exchange メールボックスの設定を検出して、ユーザーが詳細設定を手動で構成する必要がないようにすることができます。
自動検出 サービス仮想ディレクトリと同時に、SCP オブジェクトも Active Directory に作成されます。 SCP はドメインに参加しているコンピューターに向けた自動検出サービスの最優先される URL を保存および提供します。
この SCP オブジェクトを更新して、Exchange サーバーを指すようにします。 検出プロセスの向上のために Exchange サーバーが追加の 自動検出 情報をクライアントに提供するには、これが必要になります。 SCP オブジェクトは、 Set-ClientAccessService コマンドレットを使用して更新できます。 詳細については、「 Set-ClientAccessService」を参照してください。
重要
Set-ClientAccessService コマンドレットを実行する前に、アクセス許可が割り当てられている必要があります。 コマンドレットを組織内で実行するために必要になるアクセス許可とパラメーターを調べるには、「 Find the permissions required to run any Exchange cmdlet」を参照してください。
自動検出 を使用すると、Exchange サーバー上のメールボックスに接続するために必要な情報を簡単に取得できます。 SCP オブジェクトは、ユーザーの設定を取得するための適切な 自動検出 サーバーまたはエンドポイントを検索します。 また、AD DS の SCP オブジェクトによって、ドメインに参加しているクライアントは 自動検出 サーバーを簡単に検索することができます。
Exchange は、次の 2 種類の 自動検出 サービスの SCP オブジェクトを発行します。
SCP ポインター: ユーザーのドメインの自動検出 SCP オブジェクトの検索に使用する必要がある特定の LDAP サーバーを指す情報が含まれます。 SCP ポインターには、67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68 という GUID が割り当てられています。
SCP URL: 自動検出エンドポイントの URL が含まれています。 SCP URL は、次の GUID でスタンプされます: 77378F46-2C66-4aa9-A6A6-3E7A48B19596
SCP オブジェクトには、そのフォレストの 自動検出 サービスの権限リストが含まれます。 自動検出 サービス エンドポイントの検出の詳細については、「自動検出エンドポイントの一覧を生成する」を参照してください。
Exchange 2016 および Exchange 2019 のクライアント接続は Exchange 2013 に似ていますが、Exchange 2010 とは異なります。 Exchange 2016 および 2019 では、以前に Outlook クライアントが Outlook Anywhere (RPC over HTTP) を使用していた場合、HTTP 経由の MAPI が既定で有効になります。 Exchange 2016 および 2019 では、Exchange 2010 よりもサイト回復性のあるソリューションの名前空間が少なくて済み、以前に必要だった 7 つの名前空間から 2 個に減ります。 名前空間とExchange Serverの詳細については、Exchange 2016 の名前空間計画に関するブログを参照してください。
別のサイトで自動検出サービスを構成したかどうかに応じて、自動検出サービスの URL は次のいずれかの値になります。ここで //<SMTP-address-domain> 、プライマリ SMTP ドメイン アドレスはです。
https://<SMTP-address-domain>/autodiscover/autodiscover.xmlhttps://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml
たとえば、ユーザーの電子メール アドレスが の場合、 tony@contoso.comプライマリ SMTP ドメイン アドレスは contoso.com。
クライアント アプリケーションは、アプリケーションの初回起動時に 自動検出 サービスを使用します。 たとえば、Exchange Web サービス (EWS) アプリケーションが初めて起動したときに、アプリケーションは 自動検出 サービスを使用して、それ自体を構成します。 contoso.com ドメインと Longview 地域の Active Directory サイトに参加しているユーザーのコンピューターの場合、アプリケーションはこれらの 自動検出 サービス エンドポイントの一覧を生成します。
| エンドポイント | 生成元のツール |
|---|---|
| https://longview.contoso.com/autodiscover/autodiscover.xml | SCP 結果 |
| https://email.contoso.com/autodiscover/autodiscover.xml | SCP 結果 |
| https://newark.contoso.com/autodiscover/autodiscover.xml | SCP 結果 |
| https://contoso.com/autodiscover/autodiscover.exc | 電子メール アドレスから派生 |
| https://autodiscover.contoso.com/autodiscover/autodiscover | 電子メール アドレスから派生 |
SCP オブジェクトの詳細については、「 サービス接続ポイントを使用した発行」を参照してください。
DNS での 自動検出
Exchange では、Exchange 2010 で自動検出の名前空間要件が導入され、証明書にはいくつかの要件が必要でした。 サーバーの回復性のシナリオでは、次のすべての要素が必要でした。
プライマリ データセンターの IP 名前空間
セカンダリ データセンターの IP 名前空間
プライマリ Outlook Web App フェールバック名前空間
セカンダリ Outlook Web App フェールバック名前空間
トランスポート名前空間 (SMTP の場合)
プライマリ データセンターの RPC クライアント アクセス名前空間
セカンダリ データセンターの RPC クライアント アクセス名前空間
サーバーの回復性のシナリオが改善され、5 つの名前空間が 2 に減らされました。 これは、Exchange では RPC クライアント アクセス名前空間と、アクティブなメールボックス データベースをホストするメールボックス サーバーへのクライアント アクセス サービスのプロキシ要求が不要になったためです。 ある Active Directory サイトのメールボックス サーバーは、別の Active Directory サイトのメールボックス サーバーにセッションをプロキシできます。
つまり、それぞれのデータセンターで一意の名前空間が不要になったということです。 たとえば、mail.contoso.com と mail2.contoso.com の代わりに、データセンターのペアには単一の名前空間 (mail.contoso.com) のみが必要です。 さらに、データベース可用性グループ (DAG) のアクティブ化シナリオで、フェールバック名前空間は不要になりました。
自動検出は、外部 (パブリック) DNS に CNAME リソース レコードを作成するだけで済むため、ドメインの設定が簡単です。 CNAME レコードを使用すると、ネットワークに接続するクライアントからネットワークの実装の詳細を非表示にすることができます。 ネットワークで内部的に使用される CNAME レコードを使用すると、ユーザーは host.examplemachinename.domain.com ではなく、より単純な URI mail.domain.com を使用できます。
CNAME (または正規名) レコードは、Windows のショートカットや Apple Mac エイリアスに相当する DNS の機能です。 CNAME レコードは、IP アドレスを対象サーバーにマップするアドレス (A) レコードを表すエイリアスです。 たとえば、ドメインが contoso.com の場合は autodiscover.contoso.com の CNAME レコードを作成します。 CNAME レコードの名前は、証明書の名前と一致する必要があります。 CNAME レコードはホスト名に対してのみ機能します。 CNAME は外部で動作しますが、ブラウザーのバーの URL は置換しません。 証明書が URL と照合されると警告が出て失敗しますが、サービスへのアクセスは引き続き可能です。
一般的な CNAME レコードは次のようになります。
名前: autodiscover
TTL:3600
RR の種類:CNAME
対象:外部アクセス可能なメールボックス サーバーの FQDN (mail.contoso.com など)
この例では、autodiscover.contoso.com は mail.contoso.com に解決されます。 詳細については、「Exchange サーバーのメール フローおよびクライアント アクセスの構成」の、「手順 4: 外部 URL を構成する」を参照してください。
ドメインのエイリアスや承認済みドメインを含む、アカウントのすべてのドメインに対して 自動検出 CNAME レコードを作成することをお勧めします。 自分のドメインをホストしている CNAME レコードまたは SRV レコードを作成する必要があります。 オフライン アドレス帳を同期し、空き時間情報を表示し、Outlook で不在時機能を有効にすることができます。
サービス (SRV) リソース レコードを使用すると、特定のサービス、プロトコル、および DNS ドメインのサーバーの場所を指定できます。 たとえば、ドメインに 2 つの Web サーバーがある場合、どのホストが Web サーバーなのかを示す SRV リソース レコードを作成できます。 リゾルバーは、Web サーバーのすべての SRV リソース レコードを取得できます。
一般的な SRV レコードは次のようになります。
サービス: _autodiscover
プロトコル: ._tcp
ポート番号:443
ホスト: mail.contoso.com
優先度:0
重み:0
この例では、Outlook サーバーの名前空間は mail.contoso.com です。
CNAME レコードと SRV レコードの詳細については、Exchange チームブログ「 Exchange 2016 での名前空間の計画」を参照してください。
Outlook の 自動検出 サービス
Outlook クライアントはユーザーの資格情報のみで Active Directory の認証を行い、自動検出 SCP オブジェクトを検索できます。 クライアントは 自動検出 サービスのインスタンスを取得して列挙し、その後、列挙されたリストの最初のメールボックス サーバーのクライアント アクセス (フロントエンド) サービスに接続します。 次に、クライアントはユーザーのメールボックスと使用可能な Exchange 機能に接続するために必要なプロファイル情報を XML データ形式で収集します。
注:
DNS プロバイダーの要件によっては、完全修飾ドメイン名 (FQDN) をホスト名として追加する必要があります。 その場合、ドメインが contoso.com であれば、ホスト名は autodiscover.com ではなく autodiscover.contoso.com になります。
自動検出 サービスを提供するサーバーを指す、ドメイン名の特別な DNS レコードを設定して、Exchange アカウントが Outlook で正常に機能できるようにする必要があります。 外部アクセスの場合、または DNS を使用する場合、クライアントはユーザーの電子メール アドレスのプライマリ SMTP ドメイン アドレスを使用して、インターネット上の 自動検出 サービスの場所を特定します。
自動検出 サービスは、これら 4 つの方法のいずれか 1 つを使用して、電子メール クライアントを構成します。 最初の 2 つは、小規模で単一の SMTP 名前空間組織に適しています。 最後の 2 つは、複数の SMTP 名前空間を提供します。
接続先: https://autodiscover.contoso.com/AutoDiscover/AutoDiscover.xml
リダイレクトの自動検出リダイレクト URL: https://autodiscover.contoso.com/autodiscover/autodiscover.xml
DNS SRV レコードを検索する
一部のホスト名と URL は Exchange 管理センター (EAC) と Exchange 管理シェル を使用して構成できますが、それ以外では PowerShell を使用する必要があります。 詳細については、「メール フローおよびクライアント アクセスの構成」を参照してください。
自動検出 サービスを使用して、Outlook はユーザーのメールボックスで構成された新しい接続ポイントを検出します。 つまり、自動検出 では、GUID と @、およびユーザーのプライマリ SMTP アドレスのドメイン部分で構成される ID が使用されます。 自動検出 サービスは、次の情報をクライアントに返します。
ユーザーの表示名
内部および外部接続用それぞれの接続設定
ユーザーのメールボックスの場所 (メールボックスのアクティブなコピーを現在保持しているメールボックス サーバー)
空き時間情報、Exchange 2016 のユニファイド メッセージング (UM) (Exchange 2019 ではなく)、オフライン アドレス帳 (OAB) などの機能を管理するさまざまな Outlook 機能の URL
Outlook Anywhere サーバーの設定
次に示すサービスの仮想ディレクトリに、正しい外部 URL を構成していることを確認する必要があります。 次の表の例は、contoso.com 電子メール ドメインに必要な値を示しています。
| サービス | Exchange 管理シェル | 変更 |
|---|---|---|
| オフライン アドレス帳 | Get-OabVirtualDirectory | Set-OabVirtualDirectory -ExternalURL https://mail.companycontoso.com/oab |
IIS で使用される OAB 仮想ディレクトリ |
| Exchange Web サービス | Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -ExternalURL https://mail.companycontoso.com/ews/exchange.asmx |
IIS の Exchange Web サービス仮想ディレクトリ |
| Outlook Anywhere (RPC over HTTP) | Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalHostname mail.contoso.com -ExternalClientsRequireSsl $true |
IIS の Outlook Anywhere 仮想ディレクトリ |
| メッセージング アプリケーション プログラミング インターフェイス (MAPI) over HTTP (Exchange 2013 SP1 以降) | Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -ExternalURL https://mail.companycontoso.com/mapi |
IIS の MAPI 仮想ディレクトリ |
これらの URL を取得または再構成する方法の詳細については、前述の表の「サービス名」をクリックしてください。
ユーザーの Exchange 情報が変更されると、Outlook は自動検出サービスを使用してユーザーのプロファイルを自動的に再構成します。 たとえば、ユーザーのメールボックスが移動された場合などです。 または、クライアントがユーザーのメールボックスまたは使用可能な Exchange 機能に接続できない場合、Outlook は自動検出サービスに接続し、メールボックスと Exchange 機能に接続するために必要な情報を含むようにユーザーのプロファイルを自動的に更新します。
その他のクライアント
自動検出サービスは、Skype for Business Server 2015 のすべてのサービスを検索するための推奨される方法です。 接続が成功すると、自動検出サービスは、モビリティ サービス (IIS でサービス用に作成された仮想ディレクトリによって Mcx と呼ばれます)、Lync Web App、Web スケジューラ URL など、ユーザーのホーム プールのすべての Web サービス URL を返します。 ただし、内部モビリティ サービス URL と外部モビリティ サービス URL の両方が外部 Web サービス FQDN に関連付けられています。 そのため、モバイル デバイスがネットワークの内部か外部かに関係なく、デバイスは常にリバース プロキシを介してモビリティ サービスに外部接続します。 自動検出サービスは、内部/UCWA、External/UCWA、UCWA への参照も返します。 これらのエントリは、ユニファイド コミュニケーション Web API (UCWA) Web コンポーネントを参照します。
自動検出サービスを構成する
自動検出 は、ファイアウォールの内側および外側のクライアント アプリケーション、リソース フォレストおよび複数のフォレスト シナリオで機能します。 EWS クライアントの場合、通常 自動検出 は EWS エンドポイント URL を見つけるために使用されますが、その他のプロトコルを使用するクライアントを構成する情報も 自動検出 から提供されます。
Exchange Serverをインストールすると、Exchange サーバーによって作成および署名された自己署名証明書がサーバーに自動的にインストールされます。 ただし、他のサービスに使用できる追加の自己署名証明書を作成することもできます。
証明書要求の作成は、1 つ以上の Exchange サービスのトランスポート層セキュリティ (TLS) 暗号化を構成する Exchange サーバーに新しい証明書をインストールする最初の手順です。 証明書要求 (証明書署名要求または CSR とも呼ばれる) を使用して、証明機関 (CA) から証明書を取得します。 詳細については、次のトピックをご覧ください。
注:
自動検出 サービスは、Microsoft リモート接続アナライザーを使用して確認できます。 接続が成功したら、Outlook 接続テストも選択して実行します。 失敗した場合は、Exchange で外部 URL を設定する必要があります。 Microsoft リモート接続アナライザー からの結果は、接続に失敗した理由を説明する必要があります。 通常、接続障害は、さまざまな Outlook サービスの仮想ディレクトリに正しい外部 URL が構成されていないことを意味します。
自動検出 サービスを管理する
クライアントが複数の Exchange サーバーに接続する展開では、自動検出 SCP オブジェクトが各メールボックス サーバー上の (フロントエンド) クライアント アクセス サービス用に作成されます。 SCP オブジェクトには、 の形式 https://<ExchangeServer>/autodiscover/autodiscover.xml でクライアントが接続する Exchange サーバーの FQDN を持つ ServiceBindingInfo 属性が含まれています (例: https://cas01/autodiscover/autodiscover.xml)。
Exchange ActiveSync自動検出テストと Outlook 自動検出テストは、Microsoft Remote Connectivity Analyzer で実行できます。 ユーザーがローカル ワイヤレス ネットワークを使用して Exchange に接続している場合、ユーザーは両方のテストを実行して、ローカル ネットワークで ActiveSync エンドポイントへの接続が許可されていることを確認する必要があります。
Exchange 展開の一部として自動検出サービスを計画および展開する方法については、「Exchange Serverの計画と展開」を参照してください。