locked
Exchange 2010 Outlook AutoDiscover Update Issues RRS feed

  • Question

  • Hi folks,

    I have a server an Exchange server named vmINFRA-EXCH1.  It acts as all roles (MB/CA/HT etc).  I have internal DNS entry pointing mail.domain.com to the internal IP address of vmINFRA-EXCH1. I also have external DNS entry pointing mail.domain.com to the external IP address of vmINFRA-EXCH1.

     

    I've purchased a certificate from Thawte, for mail.domain.com, domain.com, and autodiscover.domain.com.  https://mail.domain.com/owa and /ecp are working fine, and I've left autodiscover disabled for now (I'll enable this later in the year).

     

    The problem I now have is that Outlook users, connected to the internal network and joined to the domain.com AD domain, experience a certificate error when they configure their Outlook and start it up each day.  It's because their Outlook always configures itself to vminfra-EXCH1.domain.com, which isn't included in the certificate.  I've tried manually reconfiguring the Outlook profiles to point to mail.domain.com, but it always reverts back to vminfra-EXCH1.

     

    Is there a way to change this behaviour, or am I going to have to send back the certificate and get an additional SAN on for vminfra-EXCH1.domain.com?  Also, is there any danger of breaking the Exchange IIS virtual directories by forcing all access to mail.domain.com only?

     

    Many thanks,

    Alistair

    • Edited by AlistairC Tuesday, July 13, 2010 8:15 PM Updated thread title to better reflect issue.
    Wednesday, July 7, 2010 8:50 AM

Answers

  • There are two possible solutions to your problem as I see it.

    1. Request a new certificate and include the internal domain name.

    2. Configure both internal and external autodiscover to use your external domain name and possibly use a split-dns

    It's your choice, you can request the new certificate or you can configure autodiscover. If you configure autodiscover to use the external domain name your clients will connect externally to receive their configuration. To prevent this you can add a zone for your external domain in your internal DNS. Then configure all internal Urls to use the external domain name instead.


    Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.com
    • Marked as answer by AlistairC Monday, August 2, 2010 9:09 AM
    Wednesday, July 7, 2010 10:05 AM
  • Domain Machines will look up the SCP (Service connection Point) in AD and connect to the first in the list, this is probably still the internal name of your server hence the error. you can change this,

    Set-ClientAccessServer –Identity <CAS Server Name> -AutoDiscoverServiceInternalUri: <Internal URL>

    Take a look at this article, it might help you understand the process http://technet.microsoft.com/en-us/library/bb124251.aspx & http://msexchangeteam.com/archive/2007/04/30/438249.aspx

    If you need any more help please open EMS and run

    Get-AutodiscoverVirtualDirectory ¦ fl Name,internalurl,externalurl

    &

    Get-clientAccessServer ¦ fl Name,AutoDiscoverServiceInternalUri

    • Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
    Saturday, July 10, 2010 1:30 AM
  • Hi Alistair.

    Could you please post the result of the script that you found here: http://msunified.net/2010/01/13/configure-exchange-2010-internalurl-powershell-script/ so that we can be a 100% sure that the internal urls are correct. remember that you must use https and http regardless of what the script say :)

    As for the outlook profile it will still point to VMINFRA-EXCH1.domain.com because you probably have not created a CAS array or changed the RPC connection point on you database. This is as expected and should not be a problem.

    Ståle Hansen
    MCITP EMA, MCTS OCS 2007, MCTS Exchange 2010
    http://msunified.net

    • Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
    Wednesday, July 14, 2010 8:37 AM
  • Alistair, I dont think creating a cas array will make any difference in this scenario, though it is good practice to create a cas array before migrating users to your Exchange 2010 environment. In you case name of the CAS array would be mail.domain.com. see this article about this: http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclientaccessserver-database-parameter/

    Regarding the certificate issue you are having now, I think it may be a problem with you certificate. It may be that you need to enable the certificate to be all purpose. do this on the certificate itself and also on the root certificates for Thawte on the exchange server only. see this article regarding this issue. It is about a OCS problem, but may apply in this scenario. http://ocsguy.com/2010/01/13/a-certificate-gotcha-that-got-me-again/

    Also you may have to request a new certificate without the name ".domain.com" as subject alternate name and just use mail.domain.com and autodiscover.domain.com. Alternatively you could just use only mail.domain.com and use SRV record externally for autodiscover and have it point to mail.domain.com. this works for windows mobile activesync clients and outlook anyhwere using outlook, and not for MAC clients. For testing puprose try use a local CA server in you domain if you have one to issue the certificate.

    Here is the article about using srv record for autodiscover: http://support.microsoft.com/kb/940881

    Let me know how it goes.

    Ståle Hansen
    MCITP EMA 2010, UC Voice Specialization
    http://msunified.net

     

    • Marked as answer by AlistairC Monday, August 2, 2010 9:10 AM
    Thursday, July 15, 2010 12:26 PM
  • Hi There,

    Just a final update on this issue before I close the question.  My original problem was that Outlook was always prompting users with a certificate error notification.  Every time I saw this behaviour I noticed that Outlook had substituted 'mail.domain.com' with 'vmINFRA-EXCH1.domain.com', which was not part of the certificate and therefore I (wrongly) assumed that this was the source of the certificate error.  From that point on I concentrated on trying to get Outlook to stop replacing mail.domain.com with vmINFRA-EXCH1.domain.com, so the only test I was performing was adding a new Mail profile to Outlook to see if it picked up the correct server alias, which it never did.

     

    After additional testing, I've now noticed that even though Outlook is still 'pointing' to vmINFRA-EXCH1, the certificate error notification is no longer occurring - I think my update of the all internal URIs at some point along my troubleshooting has caused Outlook to communicate with Exchange using the correct URLs, therefore fixing my problem; I just hadn't noticed as I was testing for the wrong behaviour.  In hindsight, I should have taken a Wireshark trace in order to figure out what was going on under the hood!  I just held off on an update for a couple of weeks as I wanted to be sure my issue had been resolved.

     

    Thanks again for all your help guys, much appreciated!

    Alistair

     

    • Marked as answer by AlistairC Monday, August 2, 2010 9:12 AM
    Monday, August 2, 2010 9:08 AM

All replies

  • There are two possible solutions to your problem as I see it.

    1. Request a new certificate and include the internal domain name.

    2. Configure both internal and external autodiscover to use your external domain name and possibly use a split-dns

    It's your choice, you can request the new certificate or you can configure autodiscover. If you configure autodiscover to use the external domain name your clients will connect externally to receive their configuration. To prevent this you can add a zone for your external domain in your internal DNS. Then configure all internal Urls to use the external domain name instead.


    Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.com
    • Marked as answer by AlistairC Monday, August 2, 2010 9:09 AM
    Wednesday, July 7, 2010 10:05 AM
  • Martin,

    Thanks for your reply.  I'm trying to reconfigure the autodiscover to use mail.domain.com.  I followed instructions here:

    http://technet.microsoft.com/en-us/magazine/ff381470.aspx

     

    However a 'Test-OutlookWebServices -ClientAccessServer "vmINFRA-EXCH1" still returns:


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1019

    Type       : Information

    Message    : A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://vm

                 INFRA-EXCH1.domain.com/Autodiscover/Autodiscover.xml.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1006

    Type       : Information

    Message    : Contacted the Autodiscover service at https://vmINFRA-EXCH1.domain.com/Autodiscover/Autodiscover.xml.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1016

    Type       : Information

    Message    : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://vmINFRA-EXCH1

                 .domain.com/Autodiscover/Autodiscover.xml.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1015

    Type       : Information

    Message    : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://vmINFRA-EXCH

                 1.domain.com/Autodiscover/Autodiscover.xml.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1014

    Type       : Information

    Message    : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://vmINFRA-EXCH1

                 .domain.com/Autodiscover/Autodiscover.xml.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1022

    Type       : Success

    Message    : Autodiscover was tested successfully.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1024

    Type       : Success

    Message    : [EXCH] Successfully contacted the AS service at https://mail.domain.com/ews/exchange.asmx. The elapse

                 d time was 45 milliseconds.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1026

    Type       : Success

    Message    : [EXCH] Successfully contacted the UM service at https://mail.domain.com/ews/exchange.asmx. The elapse

                 d time was 15 milliseconds.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1124

    Type       : Success

    Message    : [Server] Successfully contacted the AS service at https://vminfra-exch1.domain.com/ews/exchange.asmx.

                  The elapsed time was 45 milliseconds.


    RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0

    Id         : 1126

    Type       : Success

    Message    : [Server] Successfully contacted the UM service at https://vminfra-exch1.domain.com/ews/exchange.asmx.

                  The elapsed time was 15 milliseconds.

     

    Is there another configuration I'm missing to replace the vmINFRA-EXCH1 URL?

    Apologies, as you can tell I'm new to Exchange 2010...

    Thanks,

    Alistair

    Wednesday, July 7, 2010 1:27 PM
  • No need to apologies!

    It might be the the AutoDiscoverServiceInternalUri?

    You can check this by running the following command and look for the value of the AutoDiscoverServiceInternalUri parameter:
    Get-ClientAccessServer | fl


    Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.com
    Thursday, July 8, 2010 6:29 AM
  • Thanks Martin,

    I've reset AutoDiscoverServiceInternalUri  to the correct parameter, but still no luck, Outlook still configures itself for vminfra-exch1.domain.com...  I also set 

    Set-AutodiscoverVirtualDirectory -InternalURL  and still no luck!

     

     

    If I remove the top level https://domain.com from the certificate, and replace it with vmINFRA-EXCH1.domain.com, would that break anything else?  In terms of external auto discovery, http://domain.com will always divert to our company website so autodiscover will never be found there, it'll always have to go to autodiscover.domain.com instead...

     

    Let me know what you think.

     

    Thanks,

    Alistair

     

    Thursday, July 8, 2010 9:19 AM
  • The external certificate should be a SAN certificate and include domain.com, mail.domain.com and autodiscover.domain.com, just as yours does. If you replace it with a certificate matching only the internal name, autodiscover probably would work internally but not externally.

    By the way, what do you mean with " I've left autodiscover disabled for now (I'll enable this later in the year)."? In what way is it disabled?


    Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.com
    Thursday, July 8, 2010 2:01 PM
  • Sorry, I meant that Outlook anywhere is disabled; I haven't specifically disabled AutoDiscover itself so it'll still be sitting with the default configuration (apart from me trying to force the URL changes...).

     

    I'm at a loss, I've reconfigured every InternalURL I can see, but Outlook clients are STILL picking up "vmINFRA.domain.com" even if I specify "mail.domain.com" during the manual setup of the Outlook profile.  I've even tried removing the reverse DNS entry and flushing the DNS cache - still the same.  Perhaps there's a setting hidden somewhere in the AD I need to change...  I noticed this article, but it relates to Exchange 2007 :/

    http://blogs.technet.com/b/askds/archive/2008/09/18/service-connection-points-scps-and-adam-ad-lds.aspx

     

    Test-OutlookWebServices is now returning this:

     

     

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1019

    Type       : Information

    Message    : A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1006

    Type       : Information

    Message    : Contacted the Autodiscover service at https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1016

    Type       : Information

    Message    : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1015

    Type       : Information

    Message    : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1014

    Type       : Information

    Message    : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1022

    Type       : Success

    Message    : Autodiscover was tested successfully.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1106

    Type       : Information

    Message    : Contacted the Autodiscover service at https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.

                 xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1116

    Type       : Information

    Message    : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1

                 .domain.com:443/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1115

    Type       : Information

    Message    : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH

                 1.domain.com:443/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1114

    Type       : Information

    Message    : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1

                 .domain.com:443/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1122

    Type       : Success

    Message    : Autodiscover was tested successfully.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1024

    Type       : Success

    Message    : [EXCH] Successfully contacted the AS service at https://mail.domain.com/ews/exchange.asmx. The elapse

                 d time was 62 milliseconds.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1026

    Type       : Success

    Message    : [EXCH] Successfully contacted the UM service at https://mail.domain.com/ews/exchange.asmx. The elapse

                 d time was 15 milliseconds.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1124

    Type       : Success

    Message    : [Server] Successfully contacted the AS service at https://vminfra-exch1.domain.com/ews/exchange.asmx.

                  The elapsed time was 374 milliseconds.

     

    RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1

    Id         : 1126

    Type       : Success

    Message    : [Server] Successfully contacted the UM service at https://vminfra-exch1.domain.com/ews/exchange.asmx.

                  The elapsed time was 15 milliseconds.

     

     

     

    I guess I'll just have to return my current Thawte certificate and spend another £189 on another additional SAN :(  It won't break the bank but it annoys me that I shouldn't have to yet can't get Autodiscover to play ball!

     

    Thanks,

    Alistair

    • Edited by AlistairC Monday, July 12, 2010 9:41 AM
    Friday, July 9, 2010 7:16 PM
  • Just one thing, have you restarted IIS after applying the changes in Client Access?
    Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.com
    Friday, July 9, 2010 7:41 PM
  • I'm currently working the same issue. mine has only happened to a few users as I just fired up the 2010 CAS yesterday. I'm suspecting the internalurl; made the changes and I'm bouncing the server.

     

    If you right click the outlook icon and do a test autodiscover do you see your invalid fqdn showing up anywhere?


    http://exchangedeepthoughts.blogspot.com
    Friday, July 9, 2010 7:54 PM
  • Domain Machines will look up the SCP (Service connection Point) in AD and connect to the first in the list, this is probably still the internal name of your server hence the error. you can change this,

    Set-ClientAccessServer –Identity <CAS Server Name> -AutoDiscoverServiceInternalUri: <Internal URL>

    Take a look at this article, it might help you understand the process http://technet.microsoft.com/en-us/library/bb124251.aspx & http://msexchangeteam.com/archive/2007/04/30/438249.aspx

    If you need any more help please open EMS and run

    Get-AutodiscoverVirtualDirectory ¦ fl Name,internalurl,externalurl

    &

    Get-clientAccessServer ¦ fl Name,AutoDiscoverServiceInternalUri

    • Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
    Saturday, July 10, 2010 1:30 AM
  • Hi,

    Martin - yes I've restarted IIS, recycled the webapps, restated the whole server - no luck.  Blackuke, I've already made that change I'm afraid, see below for outputs:

     

    [PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory | fl Name,internalurl,externalurl

    Name        : Autodiscover (Default Web Site)

    InternalUrl : https://mail.domain.com//Autodiscover/Autodiscover.xml

    ExternalUrl :

     

    [PS] C:\Windows\system32>Get-ClientAccessServer | fl name,AutoDiscoverServiceInternalUri

    Name                           : VMINFRA-EXCH1

    AutoDiscoverServiceInternalUri : https://mail.domain.com/Autodiscover/Autodiscover.xml

     

    Knightly, I didn't know about the CTRL+Click on Outlook...  Look at the XML the autodiscover is returning:

    <?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">

        <User>

          <DisplayName>Alistair</DisplayName>

          <LegacyDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Alistair</LegacyDN>

          <DeploymentId>43910e92-c468-4b17-90e5-fbee2a318d9a</DeploymentId>

        </User>

        <Account>

          <AccountType>email</AccountType>

          <Action>settings</Action>

          <Protocol>

            <Type>EXCH</Type>

            <Server>VMINFRA-EXCH1.domain.com</Server>

            <ServerDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=VMINFRA-EXCH1</ServerDN>

            <ServerVersion>7380827F</ServerVersion>

            <MdbDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=VMINFRA-EXCH1/cn=Microsoft Private MDB</MdbDN>

            <PublicFolderServer>VMINFRA-EXCH1.domain.com</PublicFolderServer>

            <AD>vmINFRA-DC1.domain.com</AD>

            <ASUrl>https://mail.domain.com/ews/exchange.asmx</ASUrl>

            <EwsUrl>https://mail.domain.com/ews/exchange.asmx</EwsUrl>

            <EcpUrl>https://mail.domain.com/ecp</EcpUrl>

            <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um>

            <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr>

            <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt>

            <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms>

            <OOFUrl>https://mail.domain.com/ews/exchange.asmx</OOFUrl>

            <UMUrl>https://mail.domain.com/ews/UM2007Legacy.asmx</UMUrl>

            <OABUrl>https://mail.domain.com/OAB/398ac3c3-8ed4-4224-8d7f-2621cb8e5137/</OABUrl>

          </Protocol>

          <Protocol>

            <Type>WEB</Type>

            <Internal>

              <OWAUrl AuthenticationMethod="Basic, Fba">https://mail.domain.com/owa/</OWAUrl>

              <Protocol>

                <Type>EXCH</Type>

                <ASUrl>https://mail.domain.com/ews/exchange.asmx</ASUrl>

              </Protocol>

            </Internal>

            <External>

              <OWAUrl AuthenticationMethod="Fba">https://mail.domain.com/owa/</OWAUrl>

              <Protocol>

                <Type>EXPR</Type>

                <ASUrl>https://mail.domain.com/ews/exchange.asmx</ASUrl>

              </Protocol>

            </External>

          </Protocol>

        </Account>

      </Response>

    </Autodiscover>

     

    Specifically, the <Server>VMINFRA-EXCH1.domain.com</Server> and <PublicFolderServer>VMINFRA-EXCH1.domain.com</PublicFolderServer>...  I wonder if I can somehow change that without breaking other functionality?  I'm just trying to get Outlook clients to connect to the DNS alias mail.domain.com instead of the Exchange server FQDN hostname vmINFRA-EXCH1.domain.com; maybe Exchange 2010 autodiscover doesn't support this...

     

    Thanks,

    Alistair

     

    Monday, July 12, 2010 8:01 AM
  • maybe change your EWS url too?

    http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/configuring-exchange-server-2007-web-services-urls.html

     

    That'll cover OOF and Availability.


    http://exchangedeepthoughts.blogspot.com
    Monday, July 12, 2010 9:54 PM
  • Tried that too - all are set to mail.domain.com, even the InternalNLBBypassURL (which could cause issues in future)...  TestOutlookWebServices still gets:

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1019

    Type       : Information

    Message    : A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1006

    Type       : Information

    Message    : Contacted the Autodiscover service at https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1016

    Type       : Information

    Message    : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1015

    Type       : Information

    Message    : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1014

    Type       : Information

    Message    : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1022

    Type       : Success

    Message    : Autodiscover was tested successfully.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1106

    Type       : Information

    Message    : Contacted the Autodiscover service at https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1116

    Type       : Information

    Message    : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1115

    Type       : Information

    Message    : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1114

    Type       : Information

    Message    : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1122

    Type       : Success

    Message    : Autodiscover was tested successfully.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1024

    Type       : Success

    Message    : [EXCH] Successfully contacted the AS service at https://mail.domain.com/ews/exchange.asmx. The elapsed time was 109 milliseconds.

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1026

    Type       : Success

    Message    : [EXCH] Successfully contacted the UM service at https://mail.domain.com/ews/exchange.asmx. The elapsed time was 31 milliseconds.

     

    So it all looks fine till it gets to here:

     

    RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca

    Id         : 1106

    Type       : Information

    Message    : Contacted the Autodiscover service at https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.

     

    I've updated every single configuration URL I can find, both in EMS and the EMC, I'm at a complete loss as to where it's picking up the server name from.  Must be hidden somewhere deep in the Active Directory.  As a side note, I've noticed the EMS always connects to vmINFRA-EXCH1 too, but maybe that's expected.

    I've run out of time, just got to bite the bullet and buy another additional SAN for my Thawte certificate...  Roll on Exch 2010 SP1, this release just feels half-baked at the moment, barely production-ready IMO.

    Thanks for trying guys!

    Alistair

    Tuesday, July 13, 2010 8:02 PM
  • Hi Alistair.

    Could you please post the result of the script that you found here: http://msunified.net/2010/01/13/configure-exchange-2010-internalurl-powershell-script/ so that we can be a 100% sure that the internal urls are correct. remember that you must use https and http regardless of what the script say :)

    As for the outlook profile it will still point to VMINFRA-EXCH1.domain.com because you probably have not created a CAS array or changed the RPC connection point on you database. This is as expected and should not be a problem.

    Ståle Hansen
    MCITP EMA, MCTS OCS 2007, MCTS Exchange 2010
    http://msunified.net

    • Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
    Wednesday, July 14, 2010 8:37 AM
  • Hello,

    Thanks for your reply.  PFA the entire output from the scripts:

     

    [PS] C:\Users\alistair\Desktop>.\InternalURL.ps1

    Type internal Client Access FQDN starting with http:// or https://: https://mail.domain.com

    WARNING: The command completed successfully but no settings of 'VMINFRA-EXCH1\owa (Default Web Site)' have been

    modified.

    WARNING: The command completed successfully but no settings of 'VMINFRA-EXCH1\ecp (Default Web Site)' have been

    modified.

     

    Identity                                                    InternalUrl

    --------                                                    -----------

    VMINFRA-EXCH1\Autodiscover (Default Web Site)               https://mail.domain.com/autodiscover/autodiscover.xml

     

    Identity                                                    AutoDiscoverServiceInternalUri

    --------                                                    ------------------------------

    VMINFRA-EXCH1                                               https://mail.domain.com/autodiscover/autodiscover.xml

     

    Identity                                                    InternalUrl

    --------                                                    -----------

    VMINFRA-EXCH1\EWS (Default Web Site)                        https://mail.domain.com/ews/exchange.asmx

     

    Identity                                                    InternalUrl

    --------                                                    -----------

    VMINFRA-EXCH1\OAB (Default Web Site)                        https://mail.domain.com/oab

     

    Identity                                                    InternalUrl

    --------                                                    -----------

    VMINFRA-EXCH1\owa (Default Web Site)                        https://mail.domain.com/owa

     

    Identity                                                    InternalUrl

    --------                                                    -----------

    VMINFRA-EXCH1\ecp (Default Web Site)                        https://mail.domain.com/ecp

     

    Identity                                                    InternalUrl

    --------                                                    -----------

    VMINFRA-EXCH1\Microsoft-Server-ActiveSync (Default Web S... https://mail.domain.com/Microsoft-Server-ActiveSync

     

     

    [PS] C:\Users\alistair\Desktop>

     

    Do you think creating a CAS array would resolve the issue?  Would this even be possible with only one CAS server...  I presume changing the RPC connection point is more likely to create other problems?

     

    Thanks,

    Alistair

     

    Wednesday, July 14, 2010 9:55 AM
  • Alistair, I dont think creating a cas array will make any difference in this scenario, though it is good practice to create a cas array before migrating users to your Exchange 2010 environment. In you case name of the CAS array would be mail.domain.com. see this article about this: http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclientaccessserver-database-parameter/

    Regarding the certificate issue you are having now, I think it may be a problem with you certificate. It may be that you need to enable the certificate to be all purpose. do this on the certificate itself and also on the root certificates for Thawte on the exchange server only. see this article regarding this issue. It is about a OCS problem, but may apply in this scenario. http://ocsguy.com/2010/01/13/a-certificate-gotcha-that-got-me-again/

    Also you may have to request a new certificate without the name ".domain.com" as subject alternate name and just use mail.domain.com and autodiscover.domain.com. Alternatively you could just use only mail.domain.com and use SRV record externally for autodiscover and have it point to mail.domain.com. this works for windows mobile activesync clients and outlook anyhwere using outlook, and not for MAC clients. For testing puprose try use a local CA server in you domain if you have one to issue the certificate.

    Here is the article about using srv record for autodiscover: http://support.microsoft.com/kb/940881

    Let me know how it goes.

    Ståle Hansen
    MCITP EMA 2010, UC Voice Specialization
    http://msunified.net

     

    • Marked as answer by AlistairC Monday, August 2, 2010 9:10 AM
    Thursday, July 15, 2010 12:26 PM
  • Hi There,

    Just a final update on this issue before I close the question.  My original problem was that Outlook was always prompting users with a certificate error notification.  Every time I saw this behaviour I noticed that Outlook had substituted 'mail.domain.com' with 'vmINFRA-EXCH1.domain.com', which was not part of the certificate and therefore I (wrongly) assumed that this was the source of the certificate error.  From that point on I concentrated on trying to get Outlook to stop replacing mail.domain.com with vmINFRA-EXCH1.domain.com, so the only test I was performing was adding a new Mail profile to Outlook to see if it picked up the correct server alias, which it never did.

     

    After additional testing, I've now noticed that even though Outlook is still 'pointing' to vmINFRA-EXCH1, the certificate error notification is no longer occurring - I think my update of the all internal URIs at some point along my troubleshooting has caused Outlook to communicate with Exchange using the correct URLs, therefore fixing my problem; I just hadn't noticed as I was testing for the wrong behaviour.  In hindsight, I should have taken a Wireshark trace in order to figure out what was going on under the hood!  I just held off on an update for a couple of weeks as I wanted to be sure my issue had been resolved.

     

    Thanks again for all your help guys, much appreciated!

    Alistair

     

    • Marked as answer by AlistairC Monday, August 2, 2010 9:12 AM
    Monday, August 2, 2010 9:08 AM
  • OK, this is a bit old, but I had the same issue. The thing is that I did everything as described here on the Exchange server, however, Outlook showed still that damn certificate warning. After I renamed the local Outlook profile (C:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook) to force Outlook to sync with Exchange, everything was peachy!!!!
    Wednesday, January 23, 2013 10:39 AM