RSS Subscription 167 Posts and 2,643 Comments

Autodiscover, DNS, Certificates, and what you need to know

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):

https://CASServer/Autodiscover/Autodiscover.xml

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):

  • https://shudnow.net/autodiscover/autodiscover.xml
  • https://autodiscover.shudnow.net/autodiscover/autodiscover.xml

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.

  • OWA.shudnow.net
  • CASServer
  • CASServer.shudnow.net
  • autodiscover.shudnow.net

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.

InternalURLs

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.

ExternalURLs

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.

Example -

Environment:

  • Shudnow.local AD Domain
  • Shudnow.net External DNS
  • No Split DNS
  • No ISA

Certificate Requirements:

  • 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

Results:

  • 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

Commands:

  • 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:

  1. A request for webmail.shudnow.net/owa comes in to an Internet-facing CAS which belongs in SiteA.
  2. The Internet-facing CAS checks what mailbox the user belongs to and sees the mailbox is located in SiteB.
  3. The Internet-facing CAS checks to see whether there is a CAS in SiteB.
  4. 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:

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:

  • webmail.shudnow.net
  • webmail.shudnow.local
  • autodiscover.shudnow.net

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:

iisreset -noforce

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.

Share

77 Responses to “Autodiscover, DNS, Certificates, and what you need to know”

  1. on 21 Nov 2008 at 1:43 pmsubject: exchange

    Weekend reading…

    Next Version of Exchange Named Exchange 2010? Microsoft Exchange's challenges: Partners, the cloud…

  2. on 22 Dec 2008 at 8:25 amNathan Winters

    Hi Elan,

    Just thought I would say that this is a superb blog post!

    Thanks very much, I will point people here whenever they need help on this topic.

    Cheers
    Nathan

  3. on 08 Jan 2009 at 1:31 pmAndyJ

    Excellent stuff!

    How would autodiscover work in a multi site environment when there are two internet facing CAS servers.

    For example there is one CAS server in business unit A and the other in Business unit B. They all belong to one AD domain and also share the same primary SMTP address. The External autodiscover DNS record is pointing to the CAS server in Site A. So users in Site B will contact the Site A CAS server during autodiscover, I guess this CAS server then looks up in AD to find out where the mailbox resides and the Site A CAS talks to the CAS server in Site B and then returns the relevant URLS to the client?

    Could you talk to this?

    Thanks

    AJ

  4. on 08 Jan 2009 at 7:50 pmElan Shudnow

    Well, an internet facing CAS will do proxying for all services but allows you to do Redirection with OWA since it has a public certificate. You’ll also be able to do POP/IMAP directly to either server and the same for EAS and Outlook Anywhere.

    So the way it works is:
    Site A – Internet Facing
    Site B – Internet Facing
    Autodiscover pointing to Site A

    User launches Outlook and hits autodiscover.domain.com which hits Site A. The user gets the -ExternalURLs that are defined on one of the CAS Servers. Don’t forget, that only one site should have -ExternalURLs. The Outlook 2007 client then connects to those ExternalURLs. The Internet Facing CAS with the ExternalURLs will then check the user and see where their mailbox is located.

    Let’s say this mailbox is in Site B. The CAS will see then and then check the CAS Servers in Site B. Site A CAS will check -InternalURL on those CAS and then proxy the CAS data inbetween.

    If the same user hits https://sitea.domain.com/owa and the CAS in SiteB has -ExternalURL defined, the user’s browswer will be directed to the -ExternalURL in SiteB such as https://SiteB.domain.com/owa. OWA is the only thing that supports Redirection. Otherwise, everything else will have to proxy. I’m hoping this will get changed in the future so you save on internal bandwidth.

    Hope that helps.

  5. on 09 Jan 2009 at 3:14 amAndyJ

    Thanks. So are you saying that Outlook Anywhere and EAS clients will have to talk primarily to the CAS server in site A and all data is then proxied via CAS to CAS proxying?

    Thanks again for your help with this.

    AJ

  6. on 09 Jan 2009 at 3:27 amAndyJ

    Sorry let me rephrase that question.

    So Access to Outlook Anywhere for users in Site A and Site B will be direct to their own respective internet facing CAS servers.

    However for Exchange Web Services and the Autodiscover service this information will be proxied via CAS to CAS proxying

    For OWA we can either proxy or redirect depending on the CAS servers defined URLs i.e if they both have external URL defined redirection will occur.

    Thanks

    AJ

  7. on 09 Jan 2009 at 1:04 pmElan Shudnow

    So it’s a little bit different with Outlook Anywhere and EAS. Those 2 services, when using OA, will actually set the client to use a local CAS if it is configured for EAS or OA. So it’s not really proxying/redirection but is rather just telling the client to always go to their local CAS so they will always hit their local CAS and not do any proxying/redirection. Everything else has to use proxying except for OWA which can use either proxying or redirection.

  8. on 09 Jan 2009 at 2:35 pmAndyJ

    ok so now I am confused :)

    you said in an earlier post that an Outlook client would recive the external URLs configured on one of the CAS servers. In the example I gave, both sites will have different external URLs defined for web services. We dont want a OA user in site A to be directed to an OAB server in Site B for its offline address book or for availabity services.

    “User launches Outlook and hits autodiscover.domain.com which hits Site A. The user gets the -ExternalURLs that are defined on one of the CAS Servers. Don’t forget, that only one site should have -ExternalURLs. The Outlook 2007 client then connects to those ExternalURLs. The Internet Facing CAS with the ExternalURLs will then check the user and see where their mailbox is located.

    Let’s say this mailbox is in Site B. The CAS will see then and then check the CAS Servers in Site B. Site A CAS will check -InternalURL on those CAS and then proxy the CAS data inbetween.”

    You then went on to say that for OA this doesn’t happen

    “So it’s a little bit different with Outlook Anywhere and EAS. Those 2 services, when using OA, will actually set the client to use a local CAS if it is configured for EAS or OA. So it’s not really proxying/redirection but is rather just telling the client to always go to their local CAS so they will always hit their local CAS and not do any proxying/redirection. Everything else has to use proxying except for OWA which can use either proxying or redirection”

    Sorry to labour this but I think its important to understand. I may of just misunderstood what you said. If the first part of the above is correct then all our OA clients must have to talk to the CAS server where the external autodiscover record is published surely for things like the availability server and the OAB?

    Thanks for your continued help!

    AJ

  9. on 09 Jan 2009 at 2:47 pmElan Shudnow

    It definitely can be confusing.

    I think you need to read this:
    http://technet.microsoft.com/en-us/library/bb310763.aspx

    So OA will actually not if there’s no OA server in Site B. Instead, the CAS in one site will contact the Mailbox Server in another site directly. If there is a CAS OA Server in Site B, that’s when the CAS OA Server in Site B will have the user start using the CAS Server in site B permanently. Same thing happens for EAS. I should mention this is ONLY the case when you use Autodiscover and it’s properly working.

    And again, everything else uses proxying and OWA can use either proxying or redirection.

  10. on 09 Jan 2009 at 3:08 pmAndyJ

    Ive read that thing until I’m blue in the face :)

    Both sites will have a CAS server and both servers will be internet facing and also support OA. Both sites will have different external URLs defined

    What I want to know is will users of both site A and site B be able to use there own CAS servers without proxying for any of their services?

    Thanks

    AJ

  11. on 10 Jan 2009 at 1:48 pmNathan Winters

    Hi,

    Not sure but have you seen this post:

    http://www.shudnow.net/2008/08/24/configuring-exchange2007-autodiscover-site-affinity/

    Basically I think you need to edit the autodiscoverURI.

    Cheers
    Nathan

  12. on 10 Jan 2009 at 10:21 pmElan Shudnow

    That article is really only for internal Outlook usage. All the proxying and redirection stuff mostly happens for external usage. For internal usage, the Site Affinity is only for accessing Autodiscover. Autodiscover regardless of Site Affinity then passes back the InternalURLs to use based on proximity.

  13. on 16 Jan 2009 at 1:26 pmAndyJ

    Hello again Elan
    Wondering if you can help. I’ll try and be as clear as possible here.

    Can you tell me if under any circumstances that internal domain connected outlook clients will ever use DNS to locate the autodiscover service?

    From what I understand the Outlook client should locate the SCP in AD. We have an issue in that outlook clients in one AD site (site A) are getting certificate warnings for autodiscover.domain.com even though they are internal and domain joined.

    These outlook clients are domain connected so I am confused at why the certificate is giving a security alert for autodiscover.domain.com. I checked the SCP’s in AD and they are all configured as default with the servers netbios name.

    Now the CAS servers in site A have the correct UCC certs deployed with the correct SANS autodiscover.domain.com, netbios name of server etc. However the CAS servers in the other AD site (Site B) dont yet have the correct certs installed but have a self signed cert that was generated (not the default). This cert only contains the netbios name of the server. There are no users yet on the Exchange server in site B and this server has just been installed.

    I also understand that because I have not configured site affinity that it’s possible that the Outlook clients from Site A are being reffered to the CAS in Site B and this is what could be causing the security alert.

    However if this is the case, why is the security alert stating it is for autodiscover.domain.com and not the netbios name of the CAS server which would of been what the Outlook client retrieved as the SCP. That said if it did retreive the SCP from AD for the CAS in site B there would be no warnings apart from that the certificate is not trusted. At the moment the warning states the cert is not trusted and also that the name on the cetificate is invalid.

    Why is the Outlook client reffering to autodiscover.domain.com?

    I hope your still with me and you can answer this question for me becuase I am stuck on this. Autodiscover is confusing the hell out of me!

    Thanks
    AJ

  14. on 16 Jan 2009 at 3:37 pmElan Shudnow

    Internal user will use DNS if the Outook client isn’t domain joined. They won’t be able to use the SCP since they’re not connected to Active Directory so Outlook will revert to autodiscover.theirprimarySMTPdomain.com. Other than that, all I can say is do a Get-ClientAccessServer on the affected server and make sure the autodiscoverserviceinternaluri as well as web service URLs are configured accordingly.

  15. on 16 Jan 2009 at 4:12 pmAndyJ

    Thanks Elan. I have already checked the autodiscoverinternaluri and the web service URLs and they are as they should be. I’m at a loss why this is happening. Even if Outlook was reverting to DNS this would be resolved internally, as the previous consultant created an internal DNS record for autodiscover.domain.com pointing to the NLB IP of the CAS in site A. I guess I’m going to have to look into this a bit deeper.
    Thanks for all your help and keep up the good work!

  16. on 06 Feb 2009 at 6:02 pmAndyH

    Thanks for the article I believe I understand what I need to do, but I will post my ideas for confirmation. Thanks

    I have been looking at how to setup external access to an Exchange 2007 deployment with 4 Exchange Servers at separate sites, with each site having it’s own internet access via a different external domain name. The servers are all part of single domain which has been split into four sites. So we are looking at this scenario:

    AD Site Site1
    Exchange Server Exch1.domain.local
    External Domain exsite1.com

    AD Site Site2
    Exchange Server Exch2.domain.local
    External Domain exsite2.com

    AD Site Site3
    Exchange Server Exch3.domain.local
    External Domain exsite3.com

    AD Site Site4
    Exchange Server Exch4.domain.local
    External Domain exsite4.com

    Each site has an ISA 2006 SP1 firewall providing internet access.

    Now I have read about using split DNS and using SVR records but my preference is to purchase a SAN cert for each site with external and internal records as alternate names, i.e.

    For Site1

    owa.exsite1.com
    autodiscover.com
    exch1.exsite1.com
    exch1
    exch1.domain.local

    For Site2

    owa.exsite2.com
    autodiscover.com
    exch2.exsite2.com
    exch2
    exch2.domain.local

    etc etc

    Then on the Internal and External access names in Exchange for owa and autodiscover select the relevant name.

    Firstly will this work for both internal and external access, want to ensure both the Outlook 2003 SP3 and 2007 SP1 clients all work correctly.

    Or is there a better way of doing this?

  17. on 08 Feb 2009 at 11:29 amElan Shudnow

    Na, I think you are doing it correctly. If you plan on having OWA redirection, it’s important for each site to have their own owasite.externalDNSDomain.com. For example, if you want the US Site and China site to handle OWA externally, you would have USA.externalDNSdomain.com in there. Then just set up the ExternalURL for OWA in each site.

    If you want Outlook Anywhere to work in each site, you’d have the relevant FQDN in each site as well. This can be the OWA FQDN if you wish. The same goes for Activesync.

    The rest of the services need to use -InternalURL. One thing to keep into consideration is that autodiscover.domain.com is static. It can only ever go to one site. If your site fails, you’d have to change DNS to point to the new site. Because of this, I’d probably put autodiscover.domain.com in each certificate like you stated.

  18. on 18 Feb 2009 at 12:46 pmZabulon

    Thank you for this great BLOG Elan. Since I am using an ISA 2006 SP1 server I can just use our enerroot CA server for the CAS server and buy a SAN cert with mail.company.com for OWA, autodiscover.company.com for RPC? am I missing any other DNS entries to make OWA & RPC Outlook work?

    Thanks!

  19. on 18 Feb 2009 at 7:59 pmElan Shudnow

    Thanks. That should be it. We do this internally with our ISA Server. We use certificates from our internal CA for our CAS Servers and then use a public certificate for ISA. Client to ISA uses public CA and then communication from ISA to CAS uses the internal certificate. Because of this, don’t forget to put the certificate chain from your internal CA on your ISA Box.

  20. on 12 Mar 2009 at 12:40 amNordic

    Hello Elan. Thank you for these very clear presentations.

    We are planning a deployment similar to AndyH’s above: three sites each with individual Exchange servers (each server will host CAS, MBX, and Hub/Edge) and separate Internet access. All inbound Internet mail will get scrubbed by a hosted service and then passed to SiteA. SiteA will distribute mail to the other sites. So the only inbound SMTP will be to SiteA. However, I need external clients using both Outlook Anywhere and OWA to go directly to the public address of their MBX server.

    AndyH is using different external domains for each site. Our plan was to use different A-records for each site:

    mail-SiteA.domain.com
    mail-SiteB.domain.com
    mail-SiteC.domain.com

    Would that work as well?
    Would I need to put these all under a single SAN cert or would I get one for each site?

    Many thanks.

  21. on 13 Mar 2009 at 6:59 amElan Shudnow

    That looks fine. I would get a separate certificate. You can use the same certificate if the vendor allows for it to be used on multiple servers. Just know that Activesync requires the CN of a certificate. Also, Outlook Anywhere does by default as well but you can use Set-OutlookProvider to either disable Mutual Authentication or change the msstd: to a different FQDN since mutual authentication uses the CN of a certificate.

    But again, I would personally use separate certificates if at all possible.

  22. on 14 Mar 2009 at 7:43 pmNordic

    Thanks for the feedback. So, if I went with a separate cert at each location, it would house the URLs for all the services _at that site_, correct? (In this case, all services are running on the same physical server at each location.)

  23. on 15 Mar 2009 at 9:27 pmElan Shudnow

    Correct. One thing to take into consideration is depending on the vendor, they may require you to pay an extra fee for putting the certificate on more than one server (if you have multiple CAS in same site for instance) or may even require an entirely new certificate. So check with your vendor to ensure you are in legal compliance.

  24. on 02 Apr 2009 at 9:27 pmNik

    Hi Elan,

    Thanks for great info. But unfortunately I have only created one cert which is mail.mydomain.com in my environment using IIS 7.0 Server certificate and don’t know how to add additional autodiscover.mydomain.com SAN inside my existing mail.mydomain.com cert. Do you have any suggestion? Worst thing is that I need to regenerate certificate using EMS which I prefer not to do it. And then redeploy new cert to my ISA which will take time to reconfigure everything.

    I have 2 clustered MB, 2 ET, 2 NLB CAS, ISA 2006 to publish my OWA, ActiveSync, and also OA.

    Nik

  25. on 03 Apr 2009 at 2:19 pmElan Shudnow

    You can use the SRV method of Autodiscover. Your SRV will redirect the user to the existing CN of the certificate. Main difference is users will be prompted to accept the redirect message in Outlook.

    http://support.microsoft.com/kb/940881

  26. on 05 Apr 2009 at 7:35 amNik

    Noted, thanks a lot. I already get my external DNS provider to add new Autodiscover SRV record. I will test it.

    Nik

  27. on 16 Apr 2009 at 10:11 amChris

    Thanks for the great info on this post. Just a note when doing this for 2008 SBS for those who may stumble across this. All worked well, but the SBS bound the 443 port to my Default Web Site and my SBS Web Applications. The SBS Web Applications would no work. I just unbound the 443 port from the Default Web Site, but then SBS did away with my certificate in the SBS binding, so I had to make sure it was the correct certificate bound to 443 in SBS Web Applications. After this, all seems to be working fine.

    Thanks again for the great post.

  28. on 09 Jun 2009 at 5:35 pmClewis

    Hi,

    Nice article. I’m having some trouble that may be related. I’m receiving a Outlook popup box that says:

    Allow this website to configure mail@mydomain.com server settings?
    /autodiscover/autodiscover.xml?3d163918
    Your account was redirected to this website for settings. You should only allow settings from sources you know and trust.
    ( ) Don’t ask me about this webpage again.
    Allow Cancel

    —-
    It pops up every 5 minutes even if I tick the box to don’t ask me again. Have you covered this in any of your posts?

  29. on 23 Jun 2009 at 6:13 amJohny

    Hi Elan,

    In Post 22, you said “”Just know that Activesync requires the CN of a certificate. Also, Outlook Anywhere does by default as well but you can use Set-OutlookProvider to either disable Mutual Authentication or change the msstd: to a different FQDN since mutual authentication uses the CN of a certificate.”"”"

    Does this mean that activesync and Outlook Anywhere needs to have the common name in the cert as their url? What if I have two urls, say sync.domain.com and outlook.domain.com? Do I put sync as the CN and outlook as an additional entry in the san cert and disabled mutual authentication for Outlook Anywhere to work?

    Thanks.

  30. on 25 Jun 2009 at 9:59 amElan Shudnow

    Well you definitely want to have EAS using the CN. For Outlook Anywhere, the host you connect to doesn’t have to be the CN (does have to be in the cert), but the Mutual Authentication piece has to be the CN (the msstd:.) There is a way around this by using the Set-OutlookProvider to allow Autodiscover to provide a custom MSSTD which will allow you to connect to Outlook Anywhere via a different name than the CN but still set the msstd to the CN of the certificate.

    One thing to keep in mind is that this only configures new clients as the Autodiscover doesn’t really redo an already configured Outlook Anywhere setting (something that hopefully changes in the future.)

  31. on 02 Jul 2009 at 8:54 amDarko Grgic

    Hello Elan,

    I have a big Problem with my Outlook 2007 SP1 with Exchange 2007 SP1.
    It is a migration Scenario from Exchange 2003 to Exchange 2007.

    There where Problems to start the OOF-Assistant (get an Error!). I found a Hotfix for Exchange 2007 (KB952883) and installed it. This fixes the Problem and my testusers, which I have used before, can now Access the OOF and the Auto-Discovery-Test now pass successfully.

    but…..

    In this AD-Domain (Government) there is a policy (AD-Grouppolicy) to configure the IE to use a “proxy.pac” file.

    Now my problem:

    When I make tests without IE configuered for a PAC file, all functions work fine (OOF, Autodiscovery-Test pass successfully).

    When I configure the IE to use te PAC file, the Autodiscovery-Test fails and it is unable to open the OOF-Assistent (OOF=OutOfOffice). I get an Error, something like “Server not found ” or “Server is not reachable”.

    I Think….

    … that the AutoDiscovery-Service on the Exchange work properly.
    … there might be a misconfiguration in the proxy.pac file.

    can there be something wrong with the Exchange?

    The Proxy-Server is a SQUID-Server (2.6.stable I suppose)
    In the Global Config of the Proxy there are Excludes (configs for DIRECT connection, not use proxy)

    Excludes are

    internaldomain.local
    exchangeserver.internaldomain.local
    emaildomain.de
    autodiscover.emaildomain.de
    http://www.w3.org (???? I am wondering, why outlook try to connect these URL – but the logs say so) (The squid is in the dmz and not reacheble for me… someone else can read the logs)

    I need your help an hope you have an Idea.
    To configure IE-Proxy manuall is not an option

    Thanx a lot !

    Greetinx from Germany (ConstanzLake)
    DARKO

  32. on 02 Jul 2009 at 8:55 amDarko Grgic

    Hi Elan (again)

    I forgot to say that the OAB-Delivery per HTTP is anabled and the Compatibility to older Versions are also set.

    thx
    DARKO

  33. on 02 Jul 2009 at 11:48 amElan Shudnow

    Autodiscover on Exchange seems fine. You said it works when not going through your forward proxy. Start troubleshooting your proxy. And I’m not the person to talk to about forward proxies, only reverse proxying with ISA. :)

  34. on 02 Sep 2009 at 12:24 amAsaf

    Hi,

    I have a question relating to the autodiscovery and the following popup:
    ***************
    Allow this website to configure mail@domain.com server settings?
    https:///autodiscover.domain.com/autodiscover/autodiscover.xml
    Your account was redirected to this website for settings. You should only allow settings from sources you know and trust…
    ***************

    Now in our environment we don't have Exchange 2007 – we're on 2003 (no current plans to upgrade). Additionally, the default SMTP address we set for our users is something like user@domain.com (which belongs to the parent company), however the domain we have means the user also gets user@subdomain.domain.com
    We're rolling out Office 2007

    The questions are:
    1. How does the autodiscover work when you don't have Exch2007? I'm guessing that Exch2007 create the necessary information in AD when it is installed?
    2. Are we able to change the autodiscover url to https://autodiscover.subdomain.domain.com as opposed to the parent company https://autodiscover.domain.com which it seems to pick up from the default SMTP?
    3. Will changing the url have any affect in a non-2007 environment?

  35. on 02 Sep 2009 at 2:08 pmElan Shudnow

    1. There is no autodiscover when you don't have Exchange 2007. When you install Exchange 2007, it'll create the necessary SCP records within AD. You'll still want Autodiscover A records for non-domain joined clients and clients external to the network. You'll also want it for Communicator integration if you plan on OCS.
    2. Outlook 2007 always uses the SMTP for the autodiscover request and this is hard coded. For instance, if your e-mail is Asaf@subdomain.domain.com. The autodiscover request will do https://autodiscover.subdomain.domain.com.
    3. No, it won't.

  36. on 03 Sep 2009 at 11:14 pmAsaf

    Thanks for replying Elan – so I guess the question really is, how do I prevent these auto-discover messages popping up in Outlook 2007 in a non-Exch2007 environment? The messages will be pretty anoying not to mention that the users will expect some sort of "fix"…

    thanks

    Asaf

  37. on 04 Sep 2009 at 1:54 amElan Shudnow

    So you don't have any Exchange 2007 servers? Have you ever had one in your environment but didn't graciously uninstalled? Can you post a screenshot of your error? You shouldn't be getting autodiscover messages.

  38. on 04 Sep 2009 at 6:06 amAsaf

    Hi Elan,

    In our AD envrionment (which is completely seperate from the parent organisation – a university), we've never had any Exchange 2007 installations, so there should be no autodiscover to discover. Something to note is that the primary SMTP points to the university and they DO have Exchange 2007 servers, but once again, no ties via AD between them and us, nor is our Exchange system tied in to theirs in any way other that forwarding e-mail…

    PS. how do I upload a picture in here?

  39. on 04 Sep 2009 at 1:17 pmElan Shudnow

    I'm assuming this happens for users who are not on the corporate network and for users who are on the corporate network but are not domain joined? If so, Outlook 2007 will query for autodiscover.smtpdomain.com. And because that smtpdomain is at your university where they do have Exchange 2007, the Outlook 2007 users will get a response.

    PS. I'm not sure how to upload a picture. I have that feature enabled but I don't see any documentation on how to do it. I have a new comment system I just added a few days ago so I'm still getting used to how to get things working. For now, you can just provide a link.

  40. [...] 15, 2009 http://www.shudnow.net/2008/11/18/autodiscover-dns-certificates-and-what-you-need-to-know/ Posted by gktech Filed in Exchange 2007 Leave a Comment [...]

  41. on 17 Dec 2009 at 10:19 pmShaun

    Hello,
    I'm having a similar problem, Except I cannot find a SCP for autodiscovery in my AD using adsi. Is there a way I can create one?

  42. on 17 Dec 2009 at 11:08 pmAsaf

    Hi guys, sorry for the non-reply but we were extremely busy and I had to hand it off to someone else to research.

    I've just spent 30min trying to find the solution we implemented but here are the details:
    http://www.roxx.com.au/cms/index2.php?option=com_

    I haven't read the document but our solution is based on this…
    we deployed an autodiscover.reg file which includes:
    ********************
    Windows Registry Editor Version 5.00

    [HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0OutlookAutoDiscover]
    "PreferLocalXML"=dword:00000001
    "DOMAIN1.COM"="C:\Program Files\Microsoft Office\Office12\OutlookAutoDiscover\DOMAIN1.COM.XML"
    "DOMAIN2.COM"="C:\Program Files\Microsoft Office\Office12\OutlookAutoDiscover\DOMAIN2.COM.XML"
    ******************

    more to come…

  43. on 17 Dec 2009 at 11:10 pmAsaf

    Contents of Domain1.com.xml: (part 1)
    ******************
    <?xml version="1.0" encoding="utf-8"?>
    <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"><Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"&gt;
    <Account>
    <AccountType>email</AccountType>
    <Action>settings</Action>
    <Protocol>
    <Type>POP3</Type>
    <Server>SERVER's DNS TO POINT TO WHEN REQUESTING DOMAIN1.COM eg. server.somedomain.com</Server>
    <Port>110</Port>
    <SPA>off</SPA>
    <SSL>off</SSL>
    <AuthRequired>on</AuthRequired>
    </Protocol>
    *** see next post for part 2

  44. on 17 Dec 2009 at 11:11 pmAsaf

    ***Part 2 starts here
    <Protocol>
    <Type>SMTP</Type>
    <Server>SERVER's DNS TO POINT TO WHEN REQUESTING DOMAIN1.COM eg. server.somedomain.com</Server>
    <Port>25</Port>
    <SPA>off</SPA>
    <SSL>off</SSL>
    <AuthRequired>on</AuthRequired>
    <UsePOPAuth>on</UsePOPAuth>
    </Protocol>
    </Account>
    </Response></Autodiscover>
    ******************
    End of xml file

  45. on 17 Dec 2009 at 11:32 pmAsaf

    this is frustrating… the second xml file is domain2.com.xml and references the same exchange server but using a different domain name (domain2.com)

    I hope that helps…

  46. on 18 Dec 2009 at 5:34 amElan Shudnow

    Shaun, the SCP is created only when installing a CAS Server.

  47. on 05 May 2010 at 7:01 amecrgvp

    Hi Elan.

    This was a great blog. I jsut have nother question, How do use certificates on multiple CAS servers in the same site and how do we load balance them using a hardware load balancer (which is available). Should I use seperate certs for each of my CAS servers, if yes, which one should I import to ISA for External access to work.

  48. on 05 May 2010 at 12:19 pmElan Shudnow

    Use the same cert. You just need to make sure the vendor is fine with that. The vendor may have extra fees to host the cert on multiple servers. You can typically just get 1 cert that has mail.domain.com, autodiscover.domain.com, and if you're co-existing Exchange 2010 with a legacy Exchange, then legacy.domain.com. You can export this cert and use it on import it on ISA. Make sure to change your InternalURLs, ExternalURLs, and autodiscoverserviceinternalURI to point to the mail.domain.com as the Server FQDN will not be on the certificate anymore.

    As for how to load balance it, you'll need to refer to the hardware load balancer's documentation around Exchange.

  49. on 17 May 2010 at 2:30 pmMohamed

    Dear Elan

    I have already published outlook anywhere and OWA using ISA 2006 SP1. But I want to publish the autodiscover feature also. What I have in ISA, a rule that publishes this URL: email.xxxx.com
    can I add simply the URL : autodiscover.xxxx.com to Public Name Tap of the same publishing rule in ISA and it will work ?? meaning I will have two public names: email.xxxx.com and autodiscover.xxxx.com

    Thanks.

  50. on 17 May 2010 at 3:17 pmElan Shudnow

    Yes, that should suffice.

  51. [...] Directory, OBA configuration, and how outlook finds Free/Busy is explained here in in Elan  Shudnow blog read here this excellent [...]

  52. on 10 Feb 2011 at 11:32 amJames

    I don't know if anyone will see this, but I am having the same issue Darko has. Which to clarify is this: If you use a .pac(WPAD.dat) file AT ALL the autodiscover fails. I created a .pac file installed it locally to a domain joined machine and the only line in it is to return DIRECT. With that file alone, autodiscover fails. However, if you remove using the .pac file totally autodiscover works fine.

    Any help would be greatly appreciated. I am actually using Exchange 2010, but seem to have the same exact issue.

  53. on 18 Jun 2011 at 6:08 amMohd

    Hello I like the article ,
    Just a more question i have an exch2010, now i using exch2010 certificate that is free, i am using owa normally from outside and inside, I have split DNS
    The issue if I want to use outlook anywhere and ActiveSync I must buy a police CA or I can still use the internal one the exchange 2010 has if I have to buy a public one it is one certificate only for one server even if I want to use all above services (outlook anywhere, ActiveSync)

  54. on 20 Jul 2011 at 8:24 pmMat

    Elan_two sites Site A and Site B and CAS servers in all sites have the Internal URL same (e.g mail.contoso.com which is the same as the external URL as we are using a single public certificate). In case of outlook, for a user (domain-connected) in a third AD site C (but has his mailbox in Site A), gets the SCP record for a CAS in site B. Now site B CAS will return the internal URLS for a SITE A CAS, but since these internal URLS are same, on a DNS query the client might hit a CAS in site B… so will the user be redirected or proxied to a CAS in Site A ? or have I misundertood the concept ?__Thanks Mat

  55. on 05 Aug 2011 at 6:30 pmElan Shudnow

    Every Site should have a unique namespace. If you want to scope Autodiscover requests on a site by site basis, I suggest taking a look at the article I wrote on Autodiscover Site Affinity. http://www.shudnow.net/2008/08/24/configuring-exc

  56. on 23 Aug 2011 at 3:11 pmRich

    I also am having the same problem connecting to an Exchange 2007/2010. I can connect to the server fine without the proxy.pac file (ie at home), but at work which requires proxy.pac to connect to the internet, the autodiscover fails.

  57. on 23 Aug 2011 at 3:12 pmRich

    Hi James, did you have any luck figuring out the problem?

  58. on 31 Aug 2011 at 4:58 pmJames

    Can you please talk about casarray with split dns single vr
    Certificate and out of office

  59. on 12 Sep 2011 at 2:36 ammanju

    Dear All,

    We have issue in the autodiscovery or Availability Service or (OutlookanywhereOOF).

    URL Details:

    Company Name: Company.com

    OWA URL : owa.rh-bridge.com

    Outlook Anywhere : webmail.internaldomain.net

    I Ran test-outlookwebservices -Identity m.gowda@company.com -ClientAccessServer "CASSERVER1" |fl

    Id : 1013

    Type : Error

    Message : When contacting https://OWA.RH-bridge.com/Autodiscover/Autodiscov… received the error The remote server returned an error: (401) Unauthorized.

    Id : 1006

    Type : Error

    Message : The Autodiscover service could not be contacted.

    I try to access the URL https://owa.rh-bridge.com/Autodiscover/Autodiscov… and got the below response.

    <?xml version="1.0" encoding="utf-8" ?>
    -<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"&gt;
    -<Response>
    -<Error Time="08:48:25.1001679" Id="2365811618">
    <ErrorCode>600</ErrorCode>
    <Message>Invalid Request</Message>
    <DebugData/>
    </Error>
    </Response>
    </Autodiscover>
    ================================================================================
    I Ran Get-WebServicesVirtualDirectory |fl and the external and internal URL part is as below
    InternalUrl : https://owa.rh-bridge.com/EWS/Exchange.asmx
    ExternalUrl : https://webmail.corporateroot.net/EWS/Exchange.as
    AdminDisplayName :
    ================================================================================
    I Ran Get-OabVirtualDirectory |fl and the External URL field is empty (Is it related?)
    Server : CASSERVER1
    InternalUrl : http://owa.rh-bridge.com/OAB
    InternalAuthenticationMethods : {WindowsIntegrated}
    ExternalUrl :
    ExternalAuthenticationMethods : {WindowsIntegrated}
    =========================================================================
    I Ran Get-OutlookAnywhere |fl here i suspect the external host name is it correct here….
    ServerName : CASSERVER1
    SSLOffloading : True
    ExternalHostname : webmail.corporateroot.net
    ClientAuthenticationMethod : Ntlm
    IISAuthenticationMethods : {Ntlm}
    ================================================================================
    I Ran Get-OutlookProvider |fl here I added the msstd:webmail.corporateroot.net now but no change…
    CertPrincipalName : msstd:webmail.corporateroot.net
    Server :
    TTL : 1
    AdminDisplayName :
    ExchangeVersion : 0.1 (8.0.535.0)
    Name : EXPR
    DistinguishedName : CN=EXPR,CN=Outlook,CN=AutoDiscover,CN=………,DC=net
    Identity : EXPR
    ==========================================================================
    MY Qs…
    1. Are the URLs used here are proper ?
    2. Meaning the OA URL and the external OWA URL are different. Is it ok?
    3. Whyy these errors appear in the above tests…
    4. When I RUN https://www.testexchangeconnectivity.com/ the Auto discovery URL is pointing tocompany.com and failing. Is it correct.
    But the Company.com URL is really required to get the Auto discovery to work? Where I am failing.
    Provide me a solution to the issues I am facing here…..
    Manju

    Added:

    I am not able to ping the OutlookAnywhere URL from internal LAN (webmail.internaldomain.net)

    Here ;

    1. My certificate is given by internal Windows CA.
    2. We use ISA 2006 for the OWA publishing
    3. I dont have Autodiscover.externalurl.com in the certificate
    4. On outlook anywhere we are not able to get freeusy or OOF information on the OUtlook anywhere

    Please throw light on this !!!

  60. on 12 Sep 2011 at 2:49 ammanju

    Dear All,

    Also let me whether I can use the same setup (Internal Windows CA Different Outlook anywhere Proxy URL-msstd:webmail.internaldomainname.net) and add the autodiscovery.externalurl.com entry in the existing Certificate.

    OR

    I need to create a new Certificate including the autodiscovery.externalurl.com in the new certificate and assign the services to the new certificate (Internal Windows CA Generated)

    Doubt: (totally Confused here)

    autodiscovery.externalurl.com i meant here is my owa URL which is the current autodiscovery URL if I run the following command
    [PS] C:Windowssystem32>Get-ClientAccessServer | FL Name,AutoDiscoverServiceInternalUri
    Name : CASSERVER1
    AutoDiscoverServiceInternalUri : https://owa.rh-bridge.com/Autodiscover/Autodiscov
    Name : CASSERVER2
    AutoDiscoverServiceInternalUri : https://owa.rh-bridge.com/Autodiscover/Autodiscov
    [PS] C:Windowssystem32>Get-ClientAccessServer | FL Name,AutoDiscoverServiceexternalUri
    Name : CASSERVER1
    Name : CASSERVER2
    [PS] C:Windowssystem32>

    What I am missing here?

    Manju

  61. on 05 Oct 2011 at 11:25 amChrissy LeMaire

    Incredible, thorough post! Thank you.

  62. on 16 Nov 2011 at 11:06 amTom

    Hi Elan, hopefully you can further my understanding because I cant find an explicit explanation or "glean" any understanding from various articles I have read :-)

    Situation: I have a very large 2007 infrastructure, published externally via ISA2006. All connections are via Outlook Anywhere, AutoDiscover, OWA and ActiveSync.

    I have built a large Exchange 2010 infrastructure alongside the 2007 one, all within the same AD Forest, single Domain (2007contoso.com) and 1 single AD site.

    Problem: Autodiscover is published (using redirection) through the ISA and points to a 2007 CAS farm…. there are NO 2010 servers in the CAS farm that ISA points to. AutoDiscover works fine….all our clients are STILL using Exchange 2007 mailboxes.

    HOWEVER, I have set the Outlook Anywhere, ActiveSync, OWA and EWS URL's on the 2010 Servers to use a temporary namespace….lets say 2010contoso.com. I have created ISA rules and an external DNS record for 2010contoso.com (So that I can set my test mobile devices, Outlook 2007 client etc to this new namespace). I was quite sure I could not actually test Autodiscover for 2010, because i would have to flick the current autodiscover over to the 2010 one, and I'm not ready for that change.

    I did not think however that there would be an issue using the 2010 environment, with this new namespace, for some testing of other connection types.

    UNFORTUNATELY, as soon as I enabled Outlook Anywhere on the 2010 servers, my external users started getting this 2010.domain.contoso.com url for Outlook, and could not connect.

    I am trying my hardest to find any Microsoft information to explain why Autodiscover is returning external urls's that are set on the 2010 CAS servers?? ISA is ONLY sending Autodiscover and Outlook Anywhere connections to the 2007 CAS servers….. so why would Autodiscover then generate an XML file that contain data from the 2010 environment. I just cant understand it. None of my users are Exchange 2010 mailbox users yet, so surely 2010 CAS server url's should never be returned….

    Part of my concern for this also has to do with the fact I wanted to test ActiveSync in a similar fashion. I want to create ISA rules for 2010.domain.contoso.comMicrosoft-Server-ActiveSync that point to the 2010 CAS servers and can then redirect the connection back to the mobile user who should then be sent back through ISA to their 2007 CAS environment…… but I'm now completely faithless that a different Activesync URL on the 2010 CAS servers wont get sent back by Autodiscover TO Exchange ActiveSync devices over version 12.1, which leverage AutoDiscover.

    Apologies for the length of this, but any advice would be much appreciated.
    Tom

  63. on 16 Nov 2011 at 4:33 pmElan Shudnow

    It's because Autodiscover is not version aware when handing back Outlook Anywhere FQDNs. It's site aware. It's the reason that when cutting over everything to Exchange 2010 that you enable Outlook Anywhere on Exchange 2010 and then disable it on Exchange 2007. Now all Outlook Anywhere goes to Exchange 2010 and then Exchange 2010 CAS proxies RPC traffic directly to Exchange 2007 Mailbox for 2007 users nad Exchange 2010 Mailbox for 2010 users.

    A tip is that even if you do not enable Outlook Anywhere, as long as the RPC over HTTPS service is installed you can still make an Outlook Anywhere connection. Enabling Outlook Anywhere only really makes it so Autodiscover sees it and starts handing the specified FQDN back. So what you can do here is not enable Outlook Anywhere on 2010 CAS Servers, on the client machine testing against Exchange 2010, disable Autodiscover in the registry, and then manually set the client to point to the 2010 Outlook Anywhere FQDNs withou them being specified.

  64. on 04 Apr 2012 at 9:59 amPaul

    Elan,
    Great post.
    I have pretty much the exact setup you have. I do want to verify I am on the correct path.
    I have ISA 2006 SP1 publishing our webmail for Exchange 2003. I currently have 5 remote sites, and 1 corporate site. The corporate site is the internet facing site. All email goes in and out from there. We are currently upgrading to Exchange 2010. I have two exchange '10 servers set up, 1 in corp, 1 in a remote site. Mail is flowing out of the company and between sites.
    We do not have a split DNS
    I am researching the external cert set up. From your post I gather I can create private keys for each Exchange 2010 server with my internal PKI for internal clients to connect to the CAS's. each cert will have the internal FQDN for each server (CAS.xyz.domain.com.)
    On the external cert I need to have webmail.domain.com, autodiscovery.domain.com, legacy.brentw.com (to redirect users accessing OWA who have mailboxes on 2003.)

    I am a bit confused with needing webmail.domain.com on my internal certificates?

  65. on 17 Apr 2012 at 8:14 amElan Shudnow

    It's autodiscover.domain.com, not autodiscover.domain.com. And legacy.domain.com can go on the cert but it will need to be exported and put on Exchange 2003. Exchange 2010 will redirect users to Exchange 2003 and then clients will do SSL to Exchange 2003. I don't typically put server FQDNs on the servers themselves if you're doing load balancing. I typically come up with a different FQDN such as internal.domain.com and that goes to a VIP which load balances everything internally.

    So since you don't have split DNS, you could have: webmail.externaldomain.com, autodiscover.externaldomain.com, legacy.externaldomain.com, and internalweb.internaldomain.com.

  66. on 17 Apr 2012 at 11:00 amTerry

    Hi Elan,
    I found this while searching for information on autodiscover. This explains a lot, thanks! Would you be able to point me in the right direction? We are running Exchange 2003 on a single server. I loaded a readiness tool for Exchange 2010 from Microsoft. Ever since then, still running on Exchange 2003 mind you, our internal users who are running RPC over HTTPS (I guess called Outlook Anywhere now?) get a certificate prompt that autodiscover.domain.com doesn't match the security certificate name which is mail.domain.com. (I replaced our real domain name with 'domain' there). They click accept and it goes away. But it comes up each time outlook clients (Outlook 2007) are started, those using RPC over HTTPS. Our cert is self-generated, I used the Certificate Authority role on a Windows 2008 server to create them. I scanned the AD server and the Exchange server both for the autodiscover.xml file you noted in the https urls, but didn't find it. Also, I can't run those commandlets you listed, but then I'm only on version 2003. So any ideas on where I should look to stop this new autodiscover security certificate prompt from popping up? Thanks!
    Terry

  67. on 18 Apr 2012 at 10:33 amElan Shudnow

    Hm, this makes no sense. A client should not be able to hit any kind of Autodiscover unless Exchange 2007 and/or Exchange 2010 is installed. I've run the tool you mentioned before in Exchange 2003 environment without issue. Check the SCP location I pointed out in AD and see if you can ping autodiscover.domain.com and try to find out how clients are connecting to autodiscover.

  68. on 18 Apr 2012 at 6:26 pmTerry

    Using ADSI Edit, I trace that group of objects under the Configuration section. Mine translates to "CN=Protocols,CN=BUD,CN=SERVERS,CN=indy,CN=Administrative Groups,CN=biosound,CN=Microsoft Exchange,CN=Services". Under there, there isn't an Autodiscover CN, only 5 protocols, CN=HTTP, CN=IMAP4, CN=NNTP, CN=POP3, and CN=SMTP. I don't see a 'find' function in ADSI so apparently I can't 'search' all the trees easily for Autodiscover, but I clicked around on a lot of them hunting, but no luck. More in next reply…

  69. on 18 Apr 2012 at 6:27 pmTerry

    Also, something related, if it is a clue, is that I used to be able to go into 'Active Directory Users and Computers' and drill down to a user account double-click on it to open its properties. I still can directly on my AD server, but on my Exchange server, instead of opening properties, it puts the user account on the left side of the tree as if it were another container, and the right side of the window pane is empty. I keep forgetting and have to backup the tree one level and then right-click and select properties. Point is, it was an addtional change in the design of the AD on the Exchange Server changed with that too. Again, in case that is a clue. Do you know of a search tool I can use to scan the entire AD for any CN with Autodiscover in its name?

  70. on 18 Apr 2012 at 6:58 pmTerry

    I found a web page on using ldap.exe to scan AD for character strings. I used it to scan for the string Autodiscover, and it did not return any results. I tested a couple other strings I knew were there, and it successfully found them, so I believe I was using the search tool the right way.

    Also, more on the certificate prompt: When I click the details the certificate it is showing me is the certificate I generated for mail.domain.com, the one the users get when they browse to that OWA web site. Normally, though, coming across it at the web site, the name matches of course. Just that when opening the 2007 client on the network, it introduces it as the security certificate for autodiscover.domain.com. Also, I realize tonight that while I have an RPC over HTTP profile in outlook, that's not the one I'm using (but others get this cert prompt and are using their RPC over HTTP connnection). I realize I'm using the one that is a regular exchange account that requires LAN access to the exchange server, and I get the prompt too.

  71. on 18 Apr 2012 at 7:28 pmTerry

    I just now saw the 'ping autodiscover.domain.com'… I did and the external ip of my exchange server responds!? Where did that come from? I checked our internet dns service at Network Solutions – I maintain the dns records on-line at their site – and I have an * (for all) at the domain, and an @ for a 'none' at the domain (domain.com, or anythingwierd.domain.com). So I imagine that outlook 2007 is looking for autodiscover.domain.com, hitting my * record, being directed to my exchange IP which responds with my exchange cert. Sound right? So I should delete my * DNS record… I'll try it and see what happens.

  72. on 19 Apr 2012 at 7:02 amTerry

    I believe that did it. I and three others confirmed we did not get the cert prompt this morning. Around the same time as the install of the readiness tool, an exec was complaining that he didn't get redirected to our site when he typed an address that was close but not valid, I forget what now, but I went overboard and used the * A record in my DNS so anything.domain.com went to the owa site. I'll have to be more careful and specific if/when that resurfaces. But thanks again for your blog here, I am trying to learn about Exch 2010 as it is apparently significantly more complex than Exch 2003!

    Regards,
    Terry

  73. on 07 May 2012 at 7:37 amGuillaume

    Hello,
    I have a problem, I don't know if this is the same :
    in Outlook, when I try to validate the contact name, the contact name is validated but the server name is replace from mx.mydomain.com to mx.domain.local.
    My Exch server is managing the domain domain.local, but my dns for mx.mydomain.com is stetted on the Exch server.
    Why Exchange change the value of the server in Outlook ?

  74. on 07 May 2012 at 11:04 amElan Shudnow

    Perhaps the DNS records are set to CNAMEs instead of A records? Or perhaps something in IIS is redirecting incorrectly.

  75. on 09 May 2012 at 7:44 amVideo lead capture

    Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.

  76. [...] http://www.shudnow.net/2008/11/18/autodiscover-dns-certificates-and-what-you-need-to-know/ [...]

  77. on 10 May 2013 at 2:34 amConfluence: Raab IT - KnowHow

    Exchange 2010 Dienste…

    Exchange 2010 bei Outlook 2003 Clients / Migration…

Trackback this post | Feed on Comments to this post

Leave a Reply