The Autodiscover service, Certificates, DNS, etc. are a very tricky subject which depends a lot on your environment. I will provide general information while also providing real world guidance. The method I describe below (using autodiscover.domain.com) is not the only method but it is the recommended method by Microsoft and the most widely used. If you have specific questions that relate to your environment or are confused, please comment and I will help you out.
The topics I will cover include:
- DNS – Split DNS or no Split DNS
- Internal Autodiscover and the Service Connection Point
- External Autodiscover Access
- Web Service InternalURLs and ExternalURLs
- Real World Example of InternalURLs and ExternalURLs
- Proxying and Redirection
- Requesting our Certificate
There is the topic of Autodiscover Site Affinity as well. In this article, I will not be talking about how to configure Autodiscover Site Affinity as I have blogged about this in the past in great detail. You can read this article here. I will briefly touch on the purpose of Autodiscover Site Affinity and why you may want to use it throughout the article.
DNS – Split DNS or no Split DNS
For those that do not know what Split DNS is, it’s when you have an internal DNS zone that matches your external (internet) DNS. For example, shudnow.net is my external DNS. If my domain was shudnow.local, I wouldn’t have Split DNS due to the difference in DNS Namespaces. But if I add a primary DNS zone on my Domain Controllers for shudnow.net so the zone is available internally, I would then have Split DNS. Or having your AD Domain match your external DNS is also considered Split DNS.
When you configure your Autodiscover service, there is something called InternalURL, ExternalURL, and AutodiscoverServiceInternalURI. These will all have to be configured appropriately depending on your DNS configuration. For example, if you don’t have Split DNS, your InternalURL would have to point to shudnow.local and your ExternalURL would have to point to shudnow.net. If you do have Split DNS, your InternalURL can point to shudnow.net and your ExternalURL woudl also point to shudnow.net.
As you can see, the namespace that is specified when configuring the Autodiscover service depends on your DNS setup both internally and externally.
Internal Autodiscover and the Service Connection Point
The Autodiscover service is a mechanism that can do several things.
- Automatic Mailbox Creation
- Redirects Outlook 2007 clients to point to the correct server in which their mailbox is located
- Provides URLs to Web Services for Outlook 2007
When you first launch your Outlook 2007 client (Outlook 2007 required for Autodiscover access), it will search Active Directory for a Service Connection Point (SCP) record. Every time a CAS Server is installed, it will register this SCP record within Active Directory in the following location:
CN=Autodiscover,CN=Protocols,CN=<CASServer>,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services
When an Outlook 2007 client has the ability to find this record because they are domain joined and on the internal network, they will locate all SCP records and choose one at random. If you have slow links or want to remove this randomness, Autodiscover Site Affinity can be used. This SCP will return the AutodiscoverInternalURI FQDN in which this client should contact the Autodiscover service. You can modify this FQDN by using the following command:
Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://LocationOfCAS/Autodiscover/Autodiscover.xml
By default, the SCP is configured with the following URL (Uses NetBIOS instead of FQDN):
Now in the above Set-ClientAccessServer cmdlet, I specified the location as LocationOfCAS because the FQDN is largely dependent on a couple things. You can set it to the NetBIOS as long as the certificate you request contains the NetBIOS name of the CAS. You can set it to the FQDN of the server as long as the certificate you request contains the fQDN of the server. You can set it to any FQDN really including your OWA URL (owa.shudnow.net perhaps) as long as that name is on the certificate.
You can use the NetBIOS name in the certificate, but you will be exposing your NetBIOS name to internet users. Some may think this is a big deal while others don’t care too much. Personally, and this is just a personal opinion, is who cares. It’s not like an attacker is going to access your server by the NetBIOS name over the internet. And if a hacker did get into your network, it’s not because you exposed the NetBIOS name.
Now if you were using ISA and internal PKI, you have the option of utilizing an internal certificate on Exchange 2007 and using a public certificate on ISA and have clients on the internet utilize the ISA certificate in which ISA will proxy the data using the internal certificate. In this scenario, you can use NetBIOS names on your internal certificate and only the publicly accessible names on the ISA certificate. Or if you don’t care about exposing the name of the server, you can use the same certificate on Exchange and ISA. You would need to check with your certificate vendor if this is allowed as it may not be or you may have to pay an additional fee to utilize the same certificate on more than one server.
So an example of how this works for domain joined clients who have access to Active Directory is included on the Autodiscover Whitepaper:
A domain joined Outlook 2007 client will find this SCP record which will return the AutodiscoverInternalServiceURI you specify with Set-ClientAccessServer. Again, don’t forget that it’ll get a list of all SCPs for all CAS servers in your environment and use one at random. If you have slow links or just want to force Outlook clients to use a CAS in their own site, check out my article here.
External Autodiscover Access
So we now understand how we access the Autodiscover service when we are domain joined and internal to the network. What happens if we are on the corporate network and are not domain joined or we are external to the network and doin’t have AD connectivity? Or what happens if we connect via Outlook Anywhere when internal or external to the network? Essentially, what happens when we don’t have access to Active Directory?
Because our Outlook 2007 clients don’t have access to Active Directory, we cannot obtain the AutodiscoverServiceinternalURI since the client can’t get to the SCP record. Because of this, Outlook 2007 will fall back to utilizing a different method. The first method is to contact the following DNS records in order (domain = the user’s primary SMTP domain):
The majority of people will use the autodiscover.shudnow.net method. Taking a close look at the URLs, we will utilize https. This means that we will need the autodiscover.shudnow.net name in our certificate. To have multiple names in our certificate, we will need a Unified Communications Certificate that is provided by various vendors. My favorite certificate vendors are Entrust followed by Digicert.
So let’s say we want our NetBIOS name on our certificate, FQDN of CAS, our OWA FQDN, and our Autodiscover name, we’d have the following FQDNs on our certificate.
But again, as stated earlier, if you have ISA, you have the capability of using an internal certificate from your own PKI infrastructure and then using a 3rd party certificate on ISA and have external client access to ISA using the 3rd party certificate in which ISA will proxy that traffic to the CAS using the internal PKI certificate. This allows you to hide your internal server names if you wish. Otherwise you can just use your third party certificate across the board (costs may increase depending on licensing for the certificate).
So an example of how this works for domain joined clients who don’t have access to Active Directory, Outlook Anywhere clients, or non-domain joined clients is included on the Autodiscover Whitepaper:
As you can see, Outlook 2007 attempts to connect to Active Directory to get a list of all the SCPs and it fails. Because of this, Outlook 2007 then attempts to contact autodiscover.shudnow.net. There would need to be an A record for autodiscover which will lead the client to a CAS server.
Web Service InternalURLs and ExternalURLs
General Information (Outlook 2003 Vs Outlook 2007)
As has been stated earlier in the article, one of the functions of the Autodiscover Service is to provide Web Service URLs to Outlook 2007 clients. It does this by providing either InternalURLs or ExternalURLs to clients depending on how they are connecting.
To first understand why we have InternalURLs and ExternalURLs for Exchange 2007 Web Services, we must understand a little bit about Outlook 2003 and Outlook 2007 and how they differentiate from how they access these services. Outlook 2000 works the same way as Outlook 2003 but Outlook 2000 is not supported for Exchange 2007.
Microsoft is trying to de-emphasize public folders. De-emphasize as in they’re not adding new features for public folders and they’re adding other applications to take over the functionality of public folders. An example is SharePoint with its shared contacts, discussion lists, etc… Microsoft provides a good article on Public Folders Vs SharePoint and their support for public folders in the future in addition to a feature matrix. You can find this article here.
Because of this, Outlook 2007 was given the functionality to obtain features that were previously in public folders through IIS. For example, the OAB is a system folder within your public folders. Your CAS will use the file distribution service to copy the OAB files from the OAB Generation server to any CAS that is allowed for web distribution. This allows the OAB files to be distributed by the CAS. This allows Outlook 2007 to bypass needing public folders for OAB.
So because of this, Outlook 2007 doesn’t require any public folders to retrieve things like Free Busy, OAB, etc… Outlook 2003 doesn’t have the built in functionality to retrieve this data that way and must have public folders for things like OAB and Free/Busy.
The Autodiscover service has an Outlook Provider called EXCH. This provides access to Outlook 2007 clients who are able to access the Autodiscover service using the SCP record in Active Directory. When an Outlook 2007 client access this SCP record and utilizes the AutodiscoverInternalURI record to access the Autodiscover Service, they access the EXCH Outlook Provider on that CAS Server’s Autodiscover Service. The Autodiscover Service will then fetch InternalURL records to feed back to the client in an Autodiscover.xml file.
The Autodiscover service has an Outlook Provider called EXPR. This provides access to Outlook 2007 clients who are NOT able to access the Autodiscover service using the SCP record in Active Directory. When an Outlook 2007 client cannot access this SCP record and utilizes the Autodiscover.PrimarySMTPDomain.TLD record to access the Autodiscover Service, they access the EXPR Outlook Provider on that CAS Server’s Autodiscover Service. The Autodiscover Service will then fetch ExternalURL records to feed back to the client in an Autodiscover.xml file.
Configuring InternalURLs and ExternalURLs
There are several Web Services that the Autodiscover Service will return to an Outlook 2007 client. These consist of:
- Web Services (Includes Out of Office, Availability Service for Free/Busy, etc.)
- Offline Address Book
- Outlook Anywhere
- Exchange ActiveSync
- Unified Messaging
In order to configure these services, you would run the following commands:
Note: The FQDNs depend on the environment, Split DNS vs no Split DNS, what names will go on the certificate, etc.) This is what I will cover in Part 2 using real world examples. The commands provided below are just examples on the syntax.
Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://Host.InternalDNSNamespace.TLD/EWS/Exchange.asmx -ExternalURL https://Host.ExternalDNSNamespace.TLD/EWS/Exchange.asmx -BasicAuthentication:$true
Set-OABVirtualDirectory -Identity “CASServer\OAB (Default Web Site)” -InternalURL https://Host.InternalDNSNamespace.TLD/OAB -ExternalURL Host.ExternalDNSNamespace.TLD/OAB -RequireSSL:$true
Note: When configuring the URLs for the OAB Virtual Directory, a good thing to make note of is that Outlook uses BITS to connect and download the OAB. BITS does not support self-signed certificates. This is why the OABVirtualDirectory is the only Service to use http instead of https by default. If you use https, you will need to use a trusted pki certificate instead of a self-signed certificate for IIS.
Enable-OutlookAnywhere -Server CASServer -ExternalHostname “Host.ExternalDNSNamespace.TLD” -ClientAuthenticationMethod “Basic” -SSLOffloading:$False
Note: The above Enable-OutlookAnywhere command works on SP1. For RTM, substitute -ClientAuthenticationMethod with -ExternalAuthenticationMethod.
Set-ActiveSyncVirtualDirectory -Identity “CASServer\Microsoft-Server-ActiveSync (Default Web Site)” -ExternalURL https://Host.ExternalDNSNamespace.TLD/Microsoft-Server-Activesync
Set-UMVirtualDirectory -Identity “CASServer\UnifiedMessaging (Default Web Site)” -InternalURL https://Host.InternalDNSNamespace.TLD/UnifiedMessaging/Service.asmx -ExternalURL https://Host.ExternalDNSNamespace.TLD/UnifiedMessaging/Service.asmx -BasicAuthentication:$true
Real World Example of InternalURLs and ExternalURLs
So let’s go through a real world example using my domain as an example. I will then explain what we can tweak if we had ISA or have Split DNS.
- Shudnow.local AD Domain
- Shudnow.net External DNS
- No Split DNS
- No ISA
- Do not contain NetBIOS or Server FQDN on Certificate
- Provide OWA/Outlook Anywhere/EAS/Web Services Connectivity over webmail.shudnow.net
- Grant Autodiscover Access from the outside
- Provide Web Service connectivity over webmail.shudnow.local for internal uses
- InternalURL namespace will be Shudnow.local
- ExternalURL namespace will be Shudnow.net
- Include webmail.shudnow.net on certificate for external OWA, Outlook Anywhere, EAS, and Web Services (OAB/OOF/EWS)
- Include webmail.shudnow.local on certificate for internal Web Services
- Include autodiscover.shudnow.net on certificate
- Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://webmail.shudnow.localS/Autodiscover/Autodiscover.xml
- Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://webmail.shudnow.local/EWS/Exchange.asmx -ExternalURL https://webmail.shudnow.net/EWS/Exchange.asmx -BasicAuthentication:$true
- Set-OABVirtualDirectory -Identity “CASServer\OAB (Default Web Site)” -InternalURL https://webmail.shudnow.local/OAB -ExternalURL webmail.shudnow.net/OAB -RequireSSL:$true
- Enable-OutlookAnywhere -Server CASServer -ExternalHostname “webmail.shudnow.net” -ClientAuthenticationMethod “Basic” -SSLOffloading:$False
- Set-ActiveSyncVirtualDirectory -Identity “CASServer\Microsoft-Server-ActiveSync (Default Web Site)” -ExternalURL https://webmail.shudnow.net/Microsoft-Server-Activesync
- Set-UMVirtualDirectory -Identity “CASServer\UnifiedMessaging (Default Web Site)” -InternalURL https://webmail.shudnow.local/UnifiedMessaging/Service.asmx -ExternalURL https://webmail.shudnow.net/UnifiedMessaging/Service.asmx -BasicAuthentication:$true
Note: Don’t forget that for the Enable-Outlook Anywhere cmdlet, you should substitute -ClientAuthenticationMethod with -ExternalAuthenticationMethod if you are using Exchange 2007 RTM.
So as you can see, our InternalURL is different from ExternalURL. What would have changed if we had Split DNS? Well, I could have just used webmail.shudnow.net across the board and not needed to use webmail.shudnow.local and not need it in the certificate. If we put the NetBIOS name of our CAS on our certificate, we really wouldn’t have to change any of our InternalURLs because as I stated earlier, the InternalURL defaults to using the NetBIOS name in the URL by default.
Now what if we were adding ISA? Well, we could have done the same thing with our URLs in our example and/or if we were adding ISA. What is different is what I explained above, if you get an Entrust certificate for instance, you can use that certificate on Exchange, export it with its private key, and also use that certificate on ISA (contact Entrust to ensure this is alright with your environment). Or you can use your own internal PKI, include NetBIOS names on your certificate, and use NetBIOS names instead for your InternalURLs and just have ISA accept communications on an Entrust certificate and then just proxy using your InternalPKI.
In regards to ISA, I have utilized several methods before:
- I have not used the NetBIOS name on the certificate or the CASServer FQDN on the certificate. I included only the webmail.domain.com and autodiscover.domain.com in the certificate, used that same certificate on both Exchange and ISA. The client was of course using Split DNS.
- I have also put the NetBIOS name on the certificate and the CASServer FQDN on the certificate. I then did the same method as above. I exported the certificate with its private key, put it on ISA, and used that for remote access. Isle released a video in which she goes through the entire process of using this method as well as publishing it via ISA here.
- I have also used an Internal PKI and put the NetBIOS names on the certificate that lives on the CAS Server and then use a separate certificate from a thrid party certificate vendor and used that exclusively on ISA. ISA receives traffic, decrypts the traffic for application layer inspection, and then reencrypts it using the Internal certificate’s public key. Remember, encryption uses the receiving party’s public key. You’ll want to make sure you have the internal PKI’s root cerrtificate installed on ISA.
As you can see, a lot of it depends on your environment, what you have set up, if you have ISA in the mix, etc… It’s very difficult to cover all the scenarios out there. But as I said in the beginning of this article, if you have a question, feel free to comment and I’ll help you out.
Proxying and Redirection
It is important to understand how CAS to CAS communication works if you are in a multi-site configuration. Your certificates for CAS to CAS communication are important. When you are dealing with CAS Servers, there are two kinds: Intra-facing CAS Servers and Internet-facing CAS Servers.
An internet-facing CAS Server is one that accepts communication from the internet. Because of this, it will have both ExternalURLs and InternalURLs defined. An intranet-facing CAS servers will have only InternalURLs defined.
The way proxying works is as follows:
- A request for webmail.shudnow.net/owa comes in to an Internet-facing CAS which belongs in SiteA.
- The Internet-facing CAS checks what mailbox the user belongs to and sees the mailbox is located in SiteB.
- The Internet-facing CAS checks to see whether there is a CAS in SiteB.
- The Internet-facing CAS finds a CAS in SiteB and checks its list for ExternalURLs and InternalURLs. If an ExternalURL is defined, the CAS in SiteA will redirect the client’s browser to the ExternalURL of the CAS in SiteB. If no ExternalURL is defined, the CAS will proxy the OWA traffic in the background using the InternalURL.
One thing to keep in mind is that Redirection is only possible for OWA traffic. All other services can only utilize the InternalURL and proxy.
Now here is where certificates are important. If you’re doing 100% proxying, it’s fine to use the self-signed certificate as long as the CAS can communicate with the other CAS servers over its NetBIOS name (*cough* WINS *cough*) or using its FQDN which is a SAN name on the self-sigend certificate. If you don’t want WINS, you need to ensure that all InternalURLs utilize the FQDN name of the CAS or request a new certificate with whatever you like and set the InternalURL to use that FQDN.
If you do decide you want to do OWA redirection and let the other services proxy, you’ll want a public certificate on the CAS in SiteB to support Redirection. And if you’re not using Split DNS, make sure you include 2 names on the certificate, one that will allow Redirection using your external namespace and one that’ll support web services over your internal namespace.
If you are interested in learning more about CAS to CAS and/or CAS to Mailbox/BackEnd communicatiosn for proxying/redirection, check out the following articles from Microsoft:
- Overview of Proxying and Redirection – MSExchangeTeam Blog
- How Exchange 2007 CAS Proxying works for ActiveSync – MSExchangeTeam Blog
- How Exchange Server 2007 CAS Proxying works for Outlook Web Access (OWA) – MSExchangeTeam Blog
- Understanding Proxying and Redirection – TechNet Library
Requesting our Certificate
So now we have all the information we need to determine what we want on our certificate. How can we actually obtain the certificate? It is done through the Exchange Management Shell. Digicert has provided a tool which can help you create your certificate request. You can find this tool here.
So taking a look at our example above, we determined we’d use the following names on the certificate:
Once you enter your command into the Exchange Management Shell, it will place a .csr file in C:\. This file will contain text that provides you with the text information you need to submit to your certificate vendor. Once they approve the certificate, they will provide you with some text information which you then store in a .cer file.
Once you have this .cer file, you can import it. It will then bind to your previous certificate request. You can import it by running the following command and enable services on the certificate all in the same one liner:
Import-exchangecertificate –path <full path to cert file> | Enable-exchangecertificate -services IMAP, POP, UM, IIS, SMTP
Note: The services you enable depend on what services are enabled on the server you are running this command.
Then to be safe, run the following command:
Tip: When you use your New-ExchangeCertificate command, you can leave the autodiscover.domain.com name out of your certificate request and use the following switch: -IncludeAutodiscover and -IncludeAcceptedDomains. This command will take a look at your environment and add the names as it sees fit. If you have a lot of Accepted Domains, this may not be feasable. But the functionality is there if needed and requires SP1.