Setup a DNS A record (hostname) which points to the IP address of this IIS server. Dedicate an IIS server used for the HTTP redirection method (Step 3 above).), use a DNS name in this domain which will be listed on your SSL certificate and will be the DNS name in which all your tenants point to for their autodiscover CNAME record. Choose a master domain in which to host your HTTPS autodiscover DNS name (e.g.Let’s say you run a multi-tenant environment and you have the following domains: It’s not possible in a multi-tenant environment to have a single SAN certificate to cover all the many different domains which you host. As HTTPS is used, there needs to be an SSL certificate with a SAN of the autodiscover URL e.g. The 3rd method is an HTTP redirect, which simply redirects autodiscover requests, normally to an HTTPS URL. As you can see above, the first two connections are HTTPS connections and are the only true methods for autodiscover, the 4th method is used primarily for internal use. If all methods fail, then autodiscover fails. Attempting to contact the Autodiscover service using the DNS SRV redirect method _autodiscover._.Attempting to contact the Autodiscover service using the HTTP redirect method.Attempting to test potential Autodiscover.For example, take a user which has an email address of Autodiscover would take the domain name section of this email address only ( ), then run some checks for autodiscover in the following order stopping at the first one that is successful: If setting up their mail for the first time, all the user has to do is enter their email address/username and password, upon clicking next, autodiscover will work its magic and grab the exchange server name, connection settings, free/busy and other important URLs needed for the client to have a successful connection experience.įor autodiscover, there is a certain order to the way a client checks this. Īs for autodiscover, when you setup mail for the first time, or each time you re-open your mail client, autodiscover is always working automatically in the background without the user knowing. and the RPC proxy endpoint can be both, an internal and external resolvable DNS name e.g. Generally the RPC endpoint is an internally resolvable DNS name only e.g. The MAPI/RPC clients (normally LAN and internal clients) connect to the non-externally resolvable CAS Array Object FQDN (aka RPC endpoint) for Mailbox access and the external/remote HTTPS based clients connect to Outlook Anywhere hostname (aka RPC proxy endpoint) for all Mailbox and Public Folder access.
The RPC proxy endpoint normally stays the same no matter how many domains/tenants you are hosting for and is generally .īit of background, in Exchange 2010, all Outlook clients will normally use MAPI/RPC or Outlook Anywhere (RPC over HTTPS) to connect to a Client Access Server. Exchange 2010 can be setup for Multi-Tennant easily by using only a much smaller and cheaper SSL certificate for both the Exchange RPC proxy endpoint and autodiscover DNS names. This blog post will explain a solution to prevent the need to use a massive SAN (Subject Alternate Name) SSL certificate for all your tenant domain names.
0 kommentar(er)
