Configuring Autodiscover for Internal DNS

The Issue

Ever since Outlook 2016 was released, Autodiscover has been a necessity, rather than an option.

Autodiscover allows any Mail Client that connects to Exchange server to configure the appropriate settings for communication so you don’t have to input everything manually. It’s very handy, but can cause certificate errors if not configured correctly. One issue you may run into occurs most often with Exchange Organizations with non public DNS domains like domain.local. The same problem exists when organizations use a public domain that they don’t own. On an unrelated note, this is one of the reasons that Microsoft has started recommending the use of Public domain names for Active Directory domains.

If you have a domain that isn’t publicly useable on your Exchange AD environment, you will run into certificate errors when mail clients use Autodiscover. This becomes particularly problematic when you use Exchange 2013 or newer and try to use HTTPS for Outlook Anywhere. This is because Microsoft is now enforcing certificate validity with Exchange 2013’s Autodiscover features (Note, though, that Outlook Anywhere will use unsecured HTTP when your Exchange Server certificate is determined to be invalid for modern Exchange deployments). With Exchange 2007 and 2010, you will get a Certificate error every time you open Outlook. This error will state that the name on the certificate is not valid. If you need a primer on Digital Certificates and validity.

The Cause

To solve the issue with certificates, you need to configure your environment so it enforces the appropriate action with Autodiscover. By default, Autodiscover will attempt to communicate with a number of URLs based on the Client’s email address (for external users) or domain name (for internal users). It will take the following pattern when checking for Autodiscover services:

1. Autodiscover will attempt to find the Autodiscover configuration XML file at the domain name of the SMTP address used in configuration. The Active Directory SCP will be picked up first, then a lookup against https://domain.com/autodiscover/autodiscover.xml occurs (Domain.com matches the email domain for this situation)

2. If the autodiscover record is not found at domain.com/domain.local, the server will attempt to connect to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml (replace domain.com with domain.local for internal). This is why the typical recommendation for having an A Record for Autodiscover in your DNS that points to the mail server exists. In addition, you would need to have autodiscover.domain.com as a SAN on the SSL certificate installed on the Exchange server for it to be valid when attempting to connect to autodiscover using this step.

3. If autodiscover information cannot be found in either of the first two steps, Exchange will attempt to use a Service Locator record in DNS to determine the appropriate location of the configuration files. This record points the Autodiscover service to a specific location for getting the configuration it needs.

Because of the way this works, there is some configuration necessary to get Autodiscover working correctly. This usually involves adding Subject Alternate Names to the SSL certificate you use for your Exchange Server to allow the many host names used to be authenticated with the certificate.

The problem though, is that many Third Party Certificate Authorities that provide SSL certificates are beginning to deny requests for Subject Alternate Names that aren’t publicly available (There are valid security reasons for this that I won’t go in to in this post, but maybe later). As a result, you won’t be able to get a valid SSL certificate that allows domain.local as a SAN. This means that the automated steps Exchange uses for Autodiscover configuration will always fail on an Internal domain with a name that is not publicly accessible or not owned.

The Solution

IMPORTANT NOTE: This particular solution only applies to computers on your network that are *not* added to the domain. Domain-joined computers have a different issue to work with. Please read my article on resetting the Active Directory SCP for resolving Autodiscover issues like this on domain-joined computers. Additional problems and solutions can be found here.

There are actually two ways to solve the certificate issues, here. The first would be to prevent Outlook from automatically entering a user’s information when they create their profile. This will result in more work for you and your users, so I don’t recommend it. The other solution is to leverage that last step of the Autodiscover configuration search to force it to look at a host name that is listed on the certificate. This is actually fairly simple to do. Follow these steps to configure the Service Locator record in your internal domain.

  1. Open the DNS manager on one of your Domain Controllers.
  2. Expand out the management tree until you can see your Internal Domain’s Forward Lookup Zone. Click on it, and make sure there are no A records for autodiscover.domain.local in the zone.
  3. Once no autodiscover A records exist, right click the Zone name and select Other New Records.
  4. Select Service Location (SRV) from the list.
  5. Enter the settings as shown below:Image
  6. Hit OK to finish adding the record.

Once the SRV record is added to the internal DNS zone, Outlook and other autodiscover clients that attempt to configure themselves with a domain.local SMTP address will work properly without the Certificate errors on all versions of Exchange.

Other Nifty Stuff

There are some additional benefits to utilizing the Service Locator record for Autodiscover rather than an Autodiscover A or CNAME record, even in your public domain. When you use a SRV record, you can also point public clients to communicate with mail.domain.com or outlook.domain.com, or whatever you have configured your external server name to be. This means you can get away with having a single host name on your SSL certificate, since you wouldn’t need autodiscover.domain.com to get autodiscover working. Since most Third Party CAs charge up to three times more for SANs or wildcards than they do for Single Name SSL certs, you can save a bit of money (you may need to change your Internal and External Web Services URLs in Exchange to match the name you have configured).

Another Problem the SRV record Fixes

There are also some other issues you may run into that are easily fixed by adding a SRV record. One of the most common is the use of multiple Email Domains in a single Exchange Server Environment. If you have users that are not assigned a Primary or secondary SMTP address that matches the domain name listed on the SSL certificate, you’ll discover that those users and the rest of your users will not be able to share calendar data between their mailboxes. You can fix this by adding an Autodiscover SRV record to the DNS zone that manages the additional mail domains. For example, you have domain1.com and domain2.com on the same Exchange Server. user@domain1.com can’t see user@domain2.com’s calendar. The fix for this is to add the SRV record to the domain2.com DNS zone and point it to the public host name for domain1.com’s mail server. Once that’s done the services that operate the calendar sharing functions will be properly configured and both users will be able to share calendars.

170 thoughts on “Configuring Autodiscover for Internal DNS”

  1. The pop ids are not prompting the login password in outlook 10 in exchange server but the users having mail alias ids under the main id sterling asking the password in very 5 minutes.

    regards

    1. Unfortunately, that seems like an issue with Smartermail, which is a mail server I’m not familiar with. You’ll have to contact Smartermail’s support team or look through their documentation to resolve any issues you’re having there.

  2. Hello

    after adding the srv record in how much time it will propogated
    as we have add both the records in public dns and exchange server
    and wanted to know in exchange where is the autodiscover.domain.com will be available i mean to say in which path.

    Regards

    1. Right now, if I go to autodiscover.domain.com for the domain you’re using, I get a login for SmarterMail, which is a completely different solution for email than Exchange. It has its own way of handling Autodiscover. https://portal.smartertools.com/kb/a2752/set-up-autodiscover-for-smartermail.aspx explains it a bit, so you’ll need to do some setup on the smartermail server to get it to work with Outlook’s Autodiscover features.

      In addition, the certificate you have installed on the exchange server won’t work with autodiscover.domain.com. You will need to remove any DNS entries for autodiscover.domain.com that you have in public and private DNS, then create a SRV record that points to plesk-1sm.ukdns.biz
      which is where your autodiscover record is acting as an alias for. The SRV record setup instructions depend on who you’re using for your DNS, but you can use the values included in this article to add the record there.

      Once you have a SRV record in place, Autodiscover will work, but you’ll get a different popup that says you’re being redirected. This can be suppressed with the following configuration changes in the registry: https://support.microsoft.com/en-us/help/2480582/how-to-suppress-the-autodiscover-redirect-warning-in-outlook-2010-and

      1. Hello

        you said

        then create a SRV record that points to plesk-1sm.ukdns.biz

        wanted to know this SRV record will create in Public DNS of the domain.com or in
        Exchange server DNS ?

        Regards

  3. Hello

    The website is hosted on linux server hostdime.com
    IP: 66.7.201.36

    The setup is like that a Mail software Pytheas Mail gate download the mails to the
    Local server and distributed it, and when client open its outlook 10 in exchange server it popup autodiscover certificate on view the certificate is showing of Linux server certificate.

    Pytheas Mail gate connects mail.domainname.com to fetch all the mails.
    this setting is working fine before migration to the new server of smartermail 16x.
    after migration to the new server it is prompting the autodiscover certificate window.
    http://prntscr.com/ftk4cu see the printscreen.

    http://prntscr.com/ftk4sn see on click view certificate it is showing linux server certificate where the website is hosted.

    http://prntscr.com/ftk5h4 see more of certificate detail.

    http://prntscr.com/ftjvhm outlook10 setup in exchange

    http://prntscr.com/ftjvuz autodiscover page

    http://prntscr.com/ftjwyr autodiscover output

    http://prntscr.com/ftk1bg Dns record on windows server

    Linux server A record IP 66.7.201.36

    Pls Help to resolve the autodiscover window promting issue in outlook 10 in the exchange server.

    Regards
    Ranjib

    1. Sorry for such a long delay. Your issue is that the autodiscover lookup process is getting hung up with in tries to locate https://domain.com/autodiscover/autodiscover.xml. The only way to fix this is to configure the website to return a 404 error when it attempts to find that file, or configure outlook to skip that part of the lookup. This can be done with the Outlook section of the Office ADMX templates for your version of Office, deployed through a GPO.

  4. Hello

    we have a similar issue on our exchange client prompting the autodiscover certificate window on Outlook 10 Client side. but the certificate is showing is the Linux server certificate, as the emails are working on a Windows 2016 server and A record is on a Linux server. The autodiscover certificate is started after Mail server upgradations from smarterMail 15 to 16x.

    As it is crazy all the user using the Outlook client.

    wanted your help to resolve the issue of autodiscover certificate

    regards
    Ranjib

    1. This can happen if the linux server is hosting a website at http://domain.com or if there is a wildcard DNS record for the domain that points to a Linux web server and no autodiscover record. Wildcard DNS records aren’t really recommended, so if you have one, it’s best to remove it. If you have the other issue, with a linux server hosting http://domain.com, you can configure outlook to ignore that part of the autodiscover lookup process. https://support.microsoft.com/en-us/help/2612922/how-to-control-outlook-autodiscover-by-using-group-policy explains how to do this. Another option would be to create an HTTP redirect on the Linux webserver that redirects https://domain.com/autodiscover/autodiscover.xml to your Exchange server.

      1. Hello

        website is hosted on linux server and mails are on windows server
        we fetch mails using a software pytheas mail gate and it will distributed to exchange server clients using outlook 10

        The autodiscover is showing our linux server certificate where our website is hosted

        Linux server IP 66.7.201.36 the A record is setup in the windows Server DNS zone.

        see the screenshot below

        http://prntscr.com/ftjvhm outlook10 setup in exchange

        http://prntscr.com/ftjvuz autodiscover page

        http://prntscr.com/ftjwyr autodiscover output

        http://prntscr.com/ftjzb7 DNS Record

        Regards
        Ranjib

        1. Autodiscover.domain.com is pointing to your Linux-based Web server on Public DNS. That DNS record should be pointing to the Exchange server. This would need to be done internally and externally.

  5. Great Post!
    i have exchange 2016 on premise. Lately, some users can not connect to outlook due to error 10 – outlook is unable to connect to proxy server. pls i need hep!

    1. hi joshua. This particular error is caused by the internal url value for outlook anywhere being set incorrectly. Run get-outlookanywhere ¦ set-outlook anywhere -internalurl -internalclientsrequiressl $true

      Then run iisreset to fix the problem.

  6. Hello Adam, it is me again, I just want to say a super hyper mega THANKS for your help, you keep helping me during all this time and thanks to your kind suggestions and skills I was able to sort out this problem. you amigo are a genius!!!

    I have to say that nowadays is very difficult to find people keen on do what you do, so kudos to you!!!!!

    thanks again.

  7. fantastic blog sir, thank you very much, finally got that autodiscover malarkey figure it out!!!, 4 days ago I migrated a very old sbs 2003 to a brand new spanky 2012 server with exchange 2016 for 50 internal people and 200 people out and about. Having to rekey and reimport the ssl certificate was one of my worries, so much so that I got as many external devices in just to make sure that the internet ones were all good!!!…surprise, surprise the ones suffering after the migration are the internal people (including a very unforgiving owner) as all of them are getting the “there is a problem with the proxy servers certificate. The name on the security certificate is invalid or does not match the name of the target certificate servername.companyname.local….at the beginning I thought the issue was with servername as servername is the new name of the server and the ssl would not know about it…godaddy to the rescue not!!! as they refused automatically to issue a new san for my servername.companyname.local. at this point all my external customers are pointing to autodiscover.company.com (which is part of the sll) and it is working fine, but my internal customers are not. In my internal primary dns companyname.local there is an autodiscover.companyname.local (A) record entry pointing to my new server. If I understood correctly I must remove that record and instead create a SRV where domain is company.local, service is _autodiscover, protocol _tcp, host offering this service autodiscover.company.com? can you please confirm if this is the soluton and if so, if I will be getting the redirect message as I don’t think any one will be happy to change one message for another? or can I get away from the second message easier than from the first one?

    thanks a million for the help

    1. Go check that one out, since it more than likely applies to your situation. The article here is missing some information on Autodiscover (it’s the first one I wrote, after all, before I really got into figuring that “feature” out). The SRV record method is only necessary when you have an SSL certificate that doesn’t include autodiscover.domain.com, or for additional domains managed by the server itself. It will also fix computers on the LAN that aren’t members of the AD domain if you don’t want to have or want to use internal split DNS. The article in the link here (which is also linked at the start of this blog) will explain another Autodiscover method, the AD SCP, which is the first place Domain Joined Computers will look for the Exchange Server’s name. That setting, by default, is servername.domain.local, so it usually needs to be changed.

      1. Hello, it is me again, finally today I was able to test the certificate issue. What I did was.
        open DNS
        click on the zone
        remove autodiscover which read autodiscover…FQDN autodiscover.mydomain.local
        Ip address…my correct local ip address…

        The I followed your instructions..cretete the srv
        mydomain.local
        service _autodiscovery
        protocol _tcp
        priority 0
        weitgh 0
        por number 443
        host offering this service…myservername.mydomainname.local
        the entry went to the _tcp folder
        restarted DNS
        Restarted the client machine…
        The message “there is a problem with the proxy server’s …..the target site…myservename.mydomain.local

        the valid SSL certificates that I have for the SAN are
        remote.mydomain.co.uk
        http://www.remote.mydomain.co.uk
        autodiscover.mydomain.co.uk
        myserver.mydomain.co.uk
        mydomain.co.uk

        Any ideas what I may be doing wrong?

        thanks a million

        1. The “Host offering this service” needs to match a name that exists on the certificate. But what you need to do is in my other article. Run this in powershell:

          set-clientaccessserver -AutoDiscoverServiceInternalUri myserver.mydomain.co.uk

    2. Also, there’s a group policy option to suppress the redirect notice in the Office GPO templates. Or there’s a registry setting you can push out. Someone left a comment here about it a while back, but I don’t recall what it was off my head. Comment should still be here. It’s one of the older comments.

      1. Hello, for some reason I can not reply to you in the post above. Yes I read your other blog and now my internaluri reads AutoDiscoverServiceInternalUri : https://myserver.mydomain.co.uk/autodiscover/autodiscover.xml I restarted the Internet web service, but still the certificate pop up keeps coming up. After that I removed the srv record and put back the original A record for discover, restart web services but still same result…I really thought that changing the internaluri would work…

        Any help will be appreciated.

      2. Hello, sorry to bother you but I was wondering if you had any more suggestions I can follow, all my intranet users using outlook client still getting the same proxys certifixate error

        1. If you can run the Autoconfiguration test by holding ctrl while right clicking the Outlook icon in the Notification bar (By the system clock in the lower right), send the results of the test to me and I’ll go through it to see what’s failing.

  8. This is great information, thank you for posting this. I’m currently dealing with a situation concerning a client that I just inherited from a previous company. They were migrated to O365, but started getting an expired certificate notification for “mail.company.com” recently in their Outlook clients. I’m assuming this was the cert for their previous on premises Exchange server, which was not uninstalled cleanly from the environment (Exch services were just disabled, server is still a member server). There are no autodiscover A records in DNS, but there is an autodiscover CNAME record pointing to autodiscover.outlook.com. Could adding a SRV record for autodiscover.outlook.com help with this issue? Anything that could help point me in the right direction would be very much appreciated.

    1. The problem you have is likely due to the old server being listed in the Autodiscover SCP in Active Directory. The first thing that gets checked in Autodiscover is the SCP if the clients are on the domain, so if that isn’t pointing to Office 365, you’ll get an error message first no matter what. I wrote another article about that. http://wp.me/pUCB5-7X should help.

  9. Thank you for this. We recently got a new Exchange certificate and we’re getting the Outlook security alert with the 3rd item X-ed out “The name on the security certificate is invalid…” The popup lists EX2010.xxx.lan as the name. Our certificate is for mail.yyyyy.com. I set up a new SRV with xxx.lan as the domain and autodiscover.yyyyy.com in the Host field. Our Exchange server AutodiscoverServiceInternalUri is https://mail.yyyyy.com/autodiscover/autodiscover.xml

    But I’m still getting the Outlook popup. What do I need to change to fix this?

    1. Check all of the URL settings for your virtual directories. Just getting to Autodiscover is only part of the process. You also need to make sure that Autodiscover is sending the correct URLs. Autodiscover sends whatever URLs are attached to the various Virtual Directories for Exchange to Outlook, and if any of those is incorrect, you’ll get a pop up as well. You’ll particularly want to check the settings for your EWS virtual directory, since that is the one that is most likely to cause pop-ups if autodiscover is set up properly. You can get a better understanding of what’s happening with the autodiscover process by holding down the Control Button, right click the Outlook icon in the Notifications area of the task bar (Lower right, by the click), then select “Test Email Autoconfiguration”. When you run the tests in the window that pops up, it will tell you what information Autodiscover is sending to Outlook, and you can then get a better idea about what’s wrong.

    2. Thanks for the AutoConfiguration right-click thing, but I’m not sure what I’m looking for. Almost all of our URLs are https://mail.yyyyy.com/… (where … is EWS/Exchange.asmx, /owa, /OAB, /Microsoft-Server-Activesync, etc.) I don’t see any errors in the Log on AutoConfiguration.

      1. You may be dealing with an issue where the Outlook Profile gets more or less “Tattooed” with the incorrect autodiscover settings. This can usually be fixed by running a Repair on the account in the profile.

        Another option could be Outlook Provider misconfiguration. Run
        get-outlookprovider EXPR
        to see what the CertPrincipalName value is. If you had a Wildcard certificate before, someone may have changed this to match the wildcard certificate, and it would likely need to be changed back to mail.company.com or a host name that is listed on the certificate. You’ll want to do the same thing with the EXCH exchange provider. (get-outlookprovider EXCH)
        You would use
        set-outlookprovider EXPR -certprincipalname msstd:mail.domain.com
        To change it if needed.

  10. im in trouble guys can you help me with this. this is a very helpful blog but i wasnt able to accomplish the resolution based on what we have.

    outook users cant have the new certificate and it doesnt open, i change the SSL with go daddy successfully but he local outlook users suffers after that.

    1. Sorry for the delay…Have you resolved this? If not, could you clarify a little? Are the users getting certificate errors in Outlook, or something else? If they are getting certificate errors, which of the three issues in the Certificate Error box have a red X next to it?

  11. Thank you and sure, We will go for upgrade but this is long procedure but for time begging could you please anyone give us the best solution for windows server 2003 as how can we set up an internal DNS record for the external mail FQDN in windows 2003 by steps. and where we can change this external name in MS Exchange 2007.

    1. The instructions should be similar for Server 2003. You make the changes in DNS on any DC. That said, I’d highly recommend getting off of Server 2003 as soon as you can, since it’s past it’s End of Life.

  12. Do I have to change the webserver, CAS and autodiscover URL/ URI for internal resolution with set command or leave it with XXXX.local instead of changing to xxxx.com.
    I tried the same and removed the internal zones I created for public zones and it has not worked. Though it does work if I create the public zone in internal DNS with certificate error. In test lab I have applied internal CA certificate and the certificate server acts as both root and issuing certificate

    1. There’s actually two parts to this particular blog. The other entry covers the Autodiscover SCP, which is part of where your error is coming from. Domain Joined computers will look at the SCP before going to any other DNS lookups. SRV records are good for making sure extra email domains can use Autodiscover and for getting autodiscover to work with a certificate that has only one host name entry. Configuring it in the internal domain will allow you to redirect non-domain joined computers as well, however, domain joined computers work differently. Setting the Autodiscoverinternaluri and Virtual Directory Internal/external URLs will allow those computer to work properly.

  13. Hi,
    I have create an srv record but after that I cannot open outlook with this error message:
    ” cannot start microsoft outlook. cannot open the outlook window. the set of folders cannot be opened. the attempt to logon to microsoft exchange has failed”
    please HELP 🙁

    1. There are a lot of things that can cause that error to come up, but it isn’t usually caused by autodiscover. I would recommend removing all accounts from the user’s mail profile and recreating them to see if that resolves the error.

  14. Hi guys very nice page I hope you guys can help since I think i’m close to figure it out but need help !

    If I would like autodiscover to use domain2.com instead of domain1.com used by Internal/External URL is that possible ?

    Issue is that when i’m running the MS Connectivity Analyser it always look for autodiscover.domain1.com and not domain2.com that I have assigned using the cmd

    I have used this cmd Set-ClientAccessServer –Identity -AutoDiscoverServiceInternalUri https://domain2.com/Autodiscover/Autodiscover.xml

    Have created a DNS Zone locally named autodiscover.domain2.com with A inside that point to the Exchange server local IP.

    Outlook and everything else look fine internally but externally can’t get iPhone to work.

    Thanks !

    1. Can you clarify a little? Are you wanting to use domain2.com externally only, internally only, or for both?
      Also, is domain2.com the domain in the email address you are using for your users?

      1. Hello !

        Sorry for the late reply and thanks for helping me !

        I’d say both. domain2.com is a valid domain used in my enterprise.

        No domain2.com is no the primary domain in the email address but it exist in my Exchange. It’s an allowed domain + a domain in my address policy.

        1. Okay. I understand a little better now. The powershell command you wrote above will set things up to allow domain joined clients to use domain2.com as their autodiscover address, but that won’t change how things work externally. For this to work the way you want with the connectivity analyzer, you would need to set up a SRV record on your external DNS for domain1.com so that it points to domain2.com, then remove any autodiscover records that exist in domain1.com (autdiscover.domain1.com). You could also use a CNAME record for autodiscover.domain1.com and point it to autodiscover.domain2.com (or whatever is pointing to the exchange server) to get similar results, but it would still look for autodiscover.domain1.com first.

  15. Hi there!

    I’m in a happy situation that I have to create a new Exchange 2013 environment from scratch. The FQDN of my new Active Directory structure is “ad.mydomain.com”.

    I now need to configure the external and internal URLs for Exchange and I’m a bit unsure if I shall use “mail.mydomain.com” or “mail.ad.mydomain.com”. If I go with the first one, I again need Split-DNS, right?

    What is best practice here? If I use mail.ad.mydomain.com, are there any implications with autodiscover?

    Many thanks in advance!!!

    Best regards
    Mischa

    1. The External URL will be whatever your public DNS domain is, so mail.mydomain.com. Since mydomain.com isn’t an internal DNS zone (unless you make one), internal clients will use the DNS info that is published on the public DNS servers. This means that internal clients will use Public IP addresses to communicate with Exchange. As a result, you’ll need to make sure your firewall allows traffic that originates from your internal network to access your public IP addresses. This *also* means that all clients will be considered External clients, so the Internal URL can be left blank (or set to the internal URL to mail.mydomain.com as well).

  16. hi, this may be really simple for you to resolve, i just want to verify this will work.

    single server/domain running sbs2011 and exchange 2010. i want to use exchange online and can setup outlook clients fine using autodiscover but only when these clients are external.

    the internal outlook clients still point to the internal exchange, i can’t get them to see the external exchange because the domain name is the same.

    will an SRV entry in the internal server’s dns (pointing to the external exchange) fix this issue?

    thanks
    ~greg

    1. For this you would actually need to remove the Exchange Autodiscover service connection point or change it to point to autodiscover.outlook.com instead of the internal Exchange. I wrote a follow up post on how to do this.

      1. thanks, i believe i found your follow-up post but the attributes tab isn’t viewable and even though i fired up ADSIEdit as you suggested, i am unable to locate what is required to be changed (since ADSIEdit has no search ability) so i am still trying to figure this out.

        just replying to let you know that i am grateful for your help thus far. hopefully i’ll get this before i go completely grey.

        ~G

      2. update march 23, 2015 6:31am EST- got it to work as per your instructions; i was able to locate the fields using ASDIEdit eventually.

        many thanks.
        ~Greg

  17. The GUID it shows you is the actual mailbox location for that user. It’s a new “feature” for Exchange 2013. So that GUID will be different for each user account.

    As to Certificates, as long as you use SRV records, a single name cert will work fine for you. I don’t think you can do a test cert that is valid by default on client machines, though. You can test by installing the certificate into the trusted root CA store on a client computer with the cert you have now, though.

    1. about the guid i used the “Get-Mailbox mailbox | FL Identity,ExchangeGuid” command

      Btw, i autoconfigured an internal client in which i had to use the INTERNAL domain UPN or it wouldn’t work: user@contoso.local
      the values it configured are interesting:
      the GUID domain pointed to public domain name, but the HTTP proxy used “mail.contoso.local”

      is this ok?, i assume it is as it detected the OA local address but that hostname won’t validate the certificate as it’s the local one(but the correct for internal clients)

      i mean, i have internal and external url confgiured for OA and all services, one points to the local domain, the others to the public, and internal clients whould use the internal one even when the single name cert is only for the external, or do i need to cnfigure the same external url for everything in this case?

  18. 1: Yeah. SCP was probably pointing to the external DNS. You can check that with the instructions in the latest article on here.Once you added the A record, that should have made non-domain computers work as well, but I’d have to see the configuration myself to make sure of that.

    2: Yes. You’ll need split DNS to keep from going out and in the firewall, which is likely blocking that kind of traffic. This is part of the reason for new recommendations on domain naming in AD.

    3: You can use an Internal CA or self-signed certificate and not get errors as long as that certificate is deployed to the Trusted Third Party Root CAs certificate store on any client computer that accesses the Exchange server. Otherwise you’ll get a certificate error no matter what you use for the FQDN on the client.3rd party certs are trusted by default in most OSes, so they will result in less work. Certificate deployment can be a huge pain in the rump.

    4: No, a CNAME won’t work the way you think here. CNAME just allows multiple DNS entries for the same server. SRV record with no autodiscover.company.com will be the way you want to go, because that will configure DNS to point clients to whatever is listed on the certificate you have, if that’s how you want to go. SRV record essentially makes it so Outlook uses whatever you set the SRV record to point to, mail.company.com, xyz.company.com, or however you want to do it, but it’s the last lookup that outlook will use, so if you have any autodiscover.company.com A records or CNAMEs in DNS, those will take precedence.

    5: When you get moving to multiple mail domains, autodiscover isn’t too much more of a pain. The gotchas you deal with have more to do with usernames vs. email addresses, primary SMTP addresses, address policies, and stuff like that. Some of that gets a little too complicated to cover easily in writing, but I can help you out over the phone or with a remote session when you start dealing with that if you are interested. Just shoot me an email at the address in the About section here.

    1. urgh i typed a lengthy reply and it failed….
      Thanks for your detailed responses!

      anyways, i think i got the most of it, now i think my next steps are:

      1) checked the SCP and points to domain.local corectly so i have no idea why non-domain clients where not working.
      non-domain computers still fail

      2) the split-dns will be annoying, specialyl since the website is hosted externally

      3) the idea is not to have to do anything on the client side, deploying a the trust root will be annoying. So far i think i’ll only need a single-name cert since i’m using the same external hostname for everything.
      With the split dns i won’t have to configure firewall rules i take it.
      ¿is there some free test cert i can use before having to buy the real thing?, preferably one that has a public root chain already

      4) So i’ll ask the dns provider to setup a SRV record for autodiscover pointing to mail.externalhost.com

      5) i already have policies based on OUs in place since the current domain is different intenal/external

      the env is pretty simple, using contoso a example:
      the AD domain is “contoso.local”
      the external public domain is “externalcontoso.com”, the others will be “anotercontoso.com” “yetanotheracontoso.com”

      oh, and since the changes i made yesterday, some outlook clients stopped working and autoconfig as well :/ (all i did was finish configuring the internal and external hostname for the different exchange virtual servers).

      and as a side note, checking on one client that DOES work i see that the server uses the “GUID@externaldomain.com”, the usr is the external FQDN and the HTTP proxy is set to “mail.internaldomain.local”
      interesting… if i replicate that on a non-domain computer it keeps failing (extracted the correct GUID previously)

Leave a Reply

Your email address will not be published. Required fields are marked *