Autodiscover issue?

Hi folks,
I have an issue with setting up new outlook clients. When connecting to the autodiscover service it picks up the user and email no problem.
When it gets to the "logging on the mail server" bit I am presented with an error.
"The connection to Microsoft exchange is unavailable...." 
I can see the connection is going to one of my DAG servers?? and not the CAS array? 
DOM-EDB01 instead of DOM-CAS (array NLB)
Were using split DNS to correct the wildcard cert issues...(problem i inherited :) )
Identity      AutoDiscoverServiceInternalUri
DOM-CAS01 https://autodiscover.domain.com/autodiscover/autodiscover.xml
DOM-CAS02 https://autodiscover.domain.com/autodiscover/autodiscover.xml
get-autodiscovervirtualdirectory | select InternalUrl, ExternalUrl | Format-Table -AutoSize
InternalUrl ExternalUrl
[PS] C:\Windows\system32>Get-RpcClientAccess | select server, identity, responsibility | Format-Table -AutoSize
Server        Identity        Responsibility
DOM-CAS01 RpcClientAccess      Mailboxes
DOM-CAS02 RpcClientAccess      Mailboxes
DOM-EDB01 RpcClientAccess  PublicFolders
DOM-EDB02 RpcClientAccess  PublicFolders
Am i missing something?? Any pointers in the right direction would be massively appreciated!!!
Thanks and kind regards,
Aidan

Hi coffee,
Thank you for your question.
What is the version of Exchange?
How did you know the outlook are trying to connect to a MBX server instead of CAS sever.
We could right click “outlook icon” in taskbar, then click “Test E-mail AutoConfiguration”>choose “use Autodiscover”>Test
In Log table, we could check outlook how to choose CAS server.
If there are any questions regarding this issue, please be free to let me know. 
Best Regard,
Jim

Similar Messages

  • Outlook 2007 won't connect / Autodiscover issues

    Hello Foristas,
    I'm stuck ... so I hope someone will point me in the right direction. This is the scenario:
    Target: Migrate 2003SBS to EX2013. SBS hat been migrated to 2008R2 AD Server plus EX2010. This went without problems. Outlook and OWA worked just fine. A 2012 AD Server has been added.
    EX2013 has been installed on a fresh 2012 Server. Still everything worked. Mailboxes were moved and still everything worked. EX2010 was decomissioned (seemingly in a hurry :-( ) and now users can't connect via Outlook.
    Outlook Version (2007) is up to date, OWA works fine. I can't use the external Connectivity Test because I have no access to either external DNS nor Firewallconfiguration. The customer also doesn't need external access.
    Internally I have A-Records for
    exchsrv.intdom.local
    autodiscover.intdom.local
    Lookups work fine. I can access https://autodiscover/autodiscover/autodiscover.xml as well as https://autodiscover.intdom.local/.... and exchsrv/autodiscover (I get the invalid request answer)
    Certificates are signed by a domain CA, the root certificate is installed and there is no certificate warning when accessing OWA (or EWS, for that matter).
    When trying to connect Outlook, I get that "no connection to Exchange - outlook ha to be online" error (like many others ...). When trying to create a new profile, Outlook barfs at "logging on to server" (wording might be different, I'm
    on a german system).
    I've double-checked that AutoDiscoverInternalURI is correct (it's autodiscover.intdom.local/autodiscover/autodiscover.xml) as well as AutodiscoverVirtualDirectory InternalUrl is set and correct.
    Now here is what is really strange: Out of despair, I just clicked "repair account" and I was able to connect. Once. I could send Mails and receive internally. After restarting Outlook, it was and stayed disconnected. But at least I was able to
    run the Outlook Autodiscover diagnostics and what I see: Outlook tries lots of autodiscover.EXTdom.com URIs, but net even tries the internal one. So for testing, I created a host entry on the client pointing autodiscover.EXTdom.com to the internal IP of the
    Exchange-Server. I created a new profile and the ran through the assistant and had a working outlook. Once. After restarting, Outlook was disconnected again andcreating a new profile doesn't help. I've recreated that scenario and I'm able to create a working
    profile just once and it will only work for the first start. 
    With the host entry present, when I open https://autodiscover.EXTdom.com/aut.... , a login prompt appears ...
    I suspect something fishy in the AD, but I have no more ideas where to look after trying to track that down since yesterday morning.
    Any help would be greatly appreciated!
    Chris

    Hi,
    Glad that you have resolved the connectivity issue.
    According to your description, there is something wrong with your OAB. And I recommend the following articles which can help you troubleshoot the OAB issue:
    http://blogs.technet.com/b/exchange/archive/2012/10/26/oab-in-exchange-server-2013.aspx
    http://msexchangeguru.com/2013/12/04/e2013-oab/
    Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make
    sure that you completely understand the risk before retrieving any suggestions from the above link.
    Thanks,
    If you have feedback for TechNet Subscriber Support, contact
    [email protected]
    Angela Shi
    TechNet Community Support

  • Autodiscover issue in exchange 2007

    Hello,
    I had everything setup and working with autodiscover for years now. When I applied Exchange 2007 SP3 Rollup Update 12 now when I create a new user and it should automatically create the profile within outlook 2007. It does not create it. I tested the autodiscover
    from my own outlook and it says everything is fine. I am not sure what has changed to stopit from working.
    I have the following
    Windows 2003 Standard 64bit
    Exchange 2007 SP3
    OUtlook 2007 Clients
    Any ideas?
    Thanks

    When I applied Exchange 2007 SP3 Rollup Update 12 now when I create a new user and it should automatically create the profile within outlook 2007.
    Hi,
    About the content above, I have a different opinion. (If I misunderstand, please correct me.)
    When Outlook runs for the first time (not add a user into Outlook), the profile is created automatically using the name "Default Outlook Profile."
    The created profile runs whenever we start Outlook.
    When we add additional accounts into Outlook, we should create new profiles manually.
    In addition to the profile issue, is there any other issue?
    Something like Outlook cannot connect to Exchange server or etc. ?
    Feel free to contact me if there is any question.
    Thanks
    Mavis 
    Mavis Huang
    TechNet Community Support

  • Outlook Anywhere losing proxy settings, Autodiscover issue?

    I have Exchange Server 2010 in Small Business Server 2011.  I have several remote clients that are not part of the SBS domain, but they use Outlook Anywhere to connect to Exchange.
    We originally started with a self-signed and eventually added a GoDaddy SSL certificate.  Some of the remote clients lose the settings for Outlook Anywhere randomly.  The proxy checkbox is unchecked and the MSSTS settings have all disappeared.
    I investigated this and it seems to point to autodiscover.  Our DNS is hosted externally so I created an A-Host record at Netowork Solutions called autodiscover and resolved it to the static IP address of the server.  When I did this the remote
    clients started to get certificate security warnings.
    Next I tried to create a CNAME called _autodiscover for mail.mydomain.com and this didn't work either, certificate security erros
    Is my Outlook Anywhere issue an 'autodiscover' problem and if it is, what amI doing wrong?  Here are some additional details:
    Self-signed certificate is mail.mydomain.com.  GoDaddy Class 2 certificate authority has identified this site as mail.mydomain.com.  The connection to the server is encrypted.

    Testing RPC/HTTP connectivity.
    The RPC/HTTP test failed.
    Additional Details
    Elapsed Time: 3221 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to test Autodiscover for
    [email protected].
    Autodiscover was tested successfully.
    Additional Details
    Elapsed Time: 3219 ms.
    Test Steps
    Attempting each method of contacting the Autodiscover service.
    The Autodiscover service was tested successfully.
    Additional Details
    Elapsed Time: 3218 ms.
    Test Steps
    Attempting to test potential Autodiscover URL
    https://pickardconstruction.com/AutoDiscover/AutoDiscover.xml
    Testing of this potential Autodiscover URL failed.
    Additional Details
    Elapsed Time: 835 ms.
    Test Steps
    Attempting to resolve the host name pickardconstruction.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 205.204.84.106
    Elapsed Time: 464 ms.
    Testing TCP port 443 on host pickardconstruction.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 164 ms.
    Testing the SSL certificate to make sure it's valid.
    The SSL certificate failed one or more certificate validation checks.
    Additional Details
    Elapsed Time: 205 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server pickardconstruction.com on port 443.
    The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
    Additional Details
    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Elapsed Time: 156 ms.
    Attempting to test potential Autodiscover URL
    https://autodiscover.pickardconstruction.com/AutoDiscover/AutoDiscover.xml
    Testing of this potential Autodiscover URL failed.
    Additional Details
    Elapsed Time: 609 ms.
    Test Steps
    Attempting to resolve the host name autodiscover.pickardconstruction.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 205.204.84.106
    Elapsed Time: 222 ms.
    Testing TCP port 443 on host autodiscover.pickardconstruction.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 185 ms.
    Testing the SSL certificate to make sure it's valid.
    The SSL certificate failed one or more certificate validation checks.
    Additional Details
    Elapsed Time: 200 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover.pickardconstruction.com on port 443.
    The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
    Additional Details
    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
    Elapsed Time: 151 ms.
    Attempting to contact the Autodiscover service using the HTTP redirect method.
    The Autodiscover service was successfully contacted using the HTTP redirect method.
    Additional Details
    Elapsed Time: 1770 ms.
    Test Steps
    Attempting to resolve the host name autodiscover.pickardconstruction.com in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 205.204.84.106
    Elapsed Time: 21 ms.
    Testing TCP port 80 on host autodiscover.pickardconstruction.com to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 100 ms.
    The Microsoft Connectivity Analyzer is checking the host autodiscover.pickardconstruction.com for an HTTP redirect to the Autodiscover service.
    The redirect (HTTP 301/302) response was received successfully.
    Additional Details
    Redirect URL:
    https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml HTTP Response Headers: Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Length: 0 Content-Type: application/xml Date: Fri, 28 Feb 2014 01:49:00 GMT Location:
    https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4
    FrontPage/5.0.2.2635 PHP/5.3.21
    Elapsed Time: 184 ms.
    Attempting to test potential Autodiscover URL
    https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml
    Testing of the Autodiscover URL was successful.
    Additional Details
    Elapsed Time: 1463 ms.
    Test Steps
    Attempting to resolve the host name cpanelemaildiscovery.cpanel.net in DNS.
    The host name resolved successfully.
    Additional Details
    IP addresses returned: 208.74.124.130, 208.74.124.133, 208.74.125.50, 208.74.125.51, 208.74.123.82
    Elapsed Time: 109 ms.
    Testing TCP port 443 on host cpanelemaildiscovery.cpanel.net to ensure it's listening and open.
    The port was opened successfully.
    Additional Details
    Elapsed Time: 135 ms.
    Testing the SSL certificate to make sure it's valid.
    The certificate passed all validation requirements.
    Additional Details
    Elapsed Time: 358 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server cpanelemaildiscovery.cpanel.net on port 443.
    The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
    Additional Details
    Remote Certificate Subject: CN=*.cpanel.net, OU=Domain Control Validated, O=*.cpanel.net, Issuer: SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, S=Arizona,
    C=US.
    Elapsed Time: 278 ms.
    Validating the certificate name.
    The certificate name was validated successfully.
    Additional Details
    The host name that was found, cpanelemaildiscovery.cpanel.net, is a wildcard certificate match for common name *.cpanel.net.
    Elapsed Time: 0 ms.
    Certificate trust is being validated.
    The certificate is trusted and all certificates are present in the chain.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=*.cpanel.net, OU=Domain Control Validated, O=*.cpanel.net.
    One or more certificate chains were constructed successfully.
    Additional Details
    A total of 2 chains were built. The highest quality chain ends in root certificate OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US.
    Elapsed Time: 30 ms.
    Analyzing the certificate chains for compatibility problems with versions of Windows.
    No Windows compatibility problems were identified.
    Additional Details
    The certificate chain has been validated up to a trusted root. Root =
    [email protected], CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network.
    Elapsed Time: 4 ms.
    Testing the certificate date to confirm the certificate is valid.
    Date validation passed. The certificate hasn't expired.
    Additional Details
    The certificate is valid. NotBefore = 8/18/2011 6:11:10 PM, NotAfter = 10/18/2016 5:19:12 AM
    Elapsed Time: 0 ms.
    Checking the IIS configuration for client certificate authentication.
    Client certificate authentication wasn't detected.
    Additional Details
    Accept/Require Client Certificates isn't configured.
    Elapsed Time: 349 ms.
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
    The Microsoft Connectivity Analyzer successfully retrieved Autodiscover settings by sending an Autodiscover POST.
    Additional Details
    Elapsed Time: 509 ms.
    Test Steps
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL
    https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml for user
    [email protected].
    The Autodiscover XML response was successfully retrieved.
    Additional Details
    Autodiscover Account Settings XML response: <?xml version="1.0"?> <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User> <DisplayName>[email protected]</DisplayName> </User> <Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>IMAP</Type> <Server>have02b.have1.com</Server>
    <Port>993</Port> <DirectoryPort>0</DirectoryPort> <ReferralPort>0</ReferralPort> <SSL>on</SSL> <DomainRequired>off</DomainRequired> <SPA>off</SPA> <AuthRequired>on</AuthRequired>
    <LoginName>[email protected]</LoginName> </Protocol> <Protocol> <Type>SMTP</Type> <Server>have02b.have1.com</Server> <Port>465</Port> <DirectoryPort>0</DirectoryPort> <ReferralPort>0</ReferralPort>
    <SSL>on</SSL> <DomainRequired>off</DomainRequired> <SPA>off</SPA> <AuthRequired>on</AuthRequired> <LoginName>[email protected]</LoginName> </Protocol> </Account> </Response>
    </Autodiscover> HTTP Response Headers: Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Length: 1362 Content-Type: text/xml Date: Fri, 28 Feb 2014 01:49:02 GMT Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_perl/2.0.5
    Perl/v5.8.8
    Elapsed Time: 509 ms.
    Autodiscover settings for Outlook Anywhere are being validated.
    The Microsoft Connectivity Analyzer wasn't able to validate Outlook Anywhere Autodiscover settings.
    Tell me more about this issue and how to resolve it
    Additional Details
    The EXCH provider section is missing from the Autodiscover response.
    Elapsed Time: 0 ms.

  • .local domain and autodiscover issues

    I want to preface this by saying I am a new administrator.
    Our SSL cert recently expired, and since .local domains can no longer be on certs, were registered a CA cert with autodiscover.domain.com and mail.domain.com. This new cert was successfully applied, but whenever someones opens their e-mail they get a warning
    about the name on the server not matching the cert. I
    I'm pretty sure this is juts a few DNS records I need to update but I don't know which ones and really need some guidance.
    Thanks for your time.

    So what you are saying is that his current DNS for company.com (which his internal users use for external access) needs to be duplicated internally, then modified to support his internal email access?  I've set up many systems where internal DNS and
    external DNS hosted the same name, and it is far from simple as "a new zone takes less than a minute to create".  How do you handle internal access to external sites (which is currently working just fine with his external DNS)?
    To answer your question, my recommendation is that his internal clients use AutoDiscover to gain their internal settings. Keep in mind that while the Exchange server may be in the .local domain, the SMTP domain they host is a .com domain. And since his servers
    are in a domain, any domain-attached Outlook client will be able to access the mailbox successfully.
    Just create a new DNS record pointing to the external host.  Or get a new domain name that doesn't have external websites, then create a new DNS zone for that.
    Alright, so with your recommendation - he updates his clients to use Autodiscover, which they are likely already using, to gain internal settings.  And then what do you configure the internal URLs as?  
    For example - Autodiscover.
    You set the AutoDiscoverServiceInternalURI to servername.domain.local -> he still gets a cert prompt every time he opens Outlook.
    You set the AutoDiscoverServiceInternalURI to mail.domain.com to match the certificate -> Now ALL autodiscover requests from all clients are going out to the internet, then back into the Public VIP.  
    Same with EWS.  And this is assuming he's using RPC/TCP rather than HTTP.  So then he's either going to get prompts for cert every time he opens outlook and checks OOF or mailtips, or all internal clients are going to use the external VIP for Autodiscover
    and EWS. 

  • Exchange Server 2007 external autodiscover not working

    Dears
    I need help to resolve my autodiscover issue externally. Internally everything works fine like auto discover, free-busy, out of office etc.
    Our Exchange is 2007 CCR clustered with one CAS and HUB server (both in one) and 2 mailbox servers (active & passive) with a mail gateway appliance instead of Edge Server.
    Externally nothing of the above are working but Outlook Anywhere is working and more number of uses are working without any issue. For all these users who connected with Outlook-Anywhere they cannot see free-busy, out of office etc.
    Please let me know how I can check the settings for internal and external settings and what all details need to be provided for external autodiscover through cmdlet or GUI. 

    I am getting a XML file when accessing above link from external source.
    The beginning is as detailed below 
      <?xml
    version="1.0" encoding="utf-8" ?>
    - <wsdl:definitions
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:s="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
    - <wsdl:types>
    - <xs:schema
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:import
    namespace="http://schemas.microsoft.com/exchange/services/2006/messages" schemaLocation="messages.xsd"
    />
      </xs:schema>
      </wsdl:types>
    - <wsdl:message
    name="ConvertIdSoapIn">
      <wsdl:part
    name="request"
    element="tns:ConvertId" />
      <wsdl:part
    name="RequestVersion"
    element="t:RequestServerVersion" />
      </wsdl:message>
    - <wsdl:message
    name="ConvertIdSoapOut">
      <wsdl:part
    name="ConvertIdResult"
    element="tns:ConvertIdResponse" />
      <wsdl:part
    name="ServerVersion"
    element="t:ServerVersionInfo" />
      </wsdl:message>
    - <wsdl:message
    name="GetFolderSoapIn">
      <wsdl:part
    name="request"
    element="tns:GetFolder" />
      <wsdl:part
    name="Impersonation"
    element="t:ExchangeImpersonation" />
      <wsdl:part
    name="S2SAuth"
    element="t:SerializedSecurityContext" />
      <wsdl:part
    name="MailboxCulture"
    element="t:MailboxCulture" />
      <wsdl:part
    name="RequestVersion"
    element="t:RequestServerVersion" />
      </wsdl:message>
    - <wsdl:message
    name="GetFolderSoapOut">
      <wsdl:part
    name="GetFolderResult"
    element="tns:GetFolderResponse" />
      <wsdl:part
    name="ServerVersion"
    element="t:ServerVersionInfo" />
      </wsdl:message>

  • Outlook & Exchange 2010 AutoDiscover and 2008 R2 Terminal Services

    Hi,
    I have a strange issue with Outlook 2010 in Terminal Server 2008 R2 which we don't have on the standard user desktops.
    When setting up a new outlook profile it does not populate the user and server details. The setup has to be done manually. Once the profile is set up it works fine (except that Out of office does not work and Calendars do not show Free/Busy correctly). I
    understand this is a AutoDiscover issue (and I can fix this with putting a DNS entry in, but even without the cname entry in DNS it works fine on the user desktops), and looking at the two environments there is nothing that should be blocking the terminal
    servers in getting this information. 
    On the Terminal Servers if I run the Test E-mail AutoConfiguration the first thing it comes up with in the log tab is :
    Start AD lookup for e-mail address
    AD Lookup for e-mail address Failed (0x80070035)
    This does not happen at all on the user desktops. It finds the email address without issue and populates the E-mail Address field.
    Why is this happening ? What is there on the terminal server that is preventing outlook from correctly retrieving this information ? Is there and LDAP issue from the terminal server to the DC ? What can be done to fix it ?
    Thanks

    OK. I think i sorted it out. There is clearly an issue with LDAP services and IP virtualization on Terminal Servers.
    I found this quote on a page :
    "The Directory Connector works by mapping IP addresses to usernames; any IP address sharing will mean the Directory Connector will not be able to tell theses users apart"
    So I changed the IP Virtualization from per session to per application and specified the application to use that I have done all of this for, and voila.... Outlook stated working and ldp also connected without an
    issue.

  • Autodiscover Error in Outlook 2010

    Hi Guys;
    I have users with a problem when tries to configure a OOF or everything have to be with the autodiscover. I ran the Test E-Mail AutoConfiguration and it returned the following screens.
    If someone have any idea please let me know.
    I will be tring resolve the issues, but i apreciate any help.
    Carlos Sanchez

    Hi,
    If you have resolved the problem with the issue, it will be kind of you to share the resolution with us, thus other users who meet the same problem can benefit from it.
    As for the Autodiscover issue, I also suggest you post the question in Exchange forum to get more specific support:
    http://social.technet.microsoft.com/Forums/exchange/en-US/home?category=exchangeserver
    Thanks,
    Melon Chen
    Forum Support
    Come back and mark the replies as answers if they help and unmark them if they provide no help.
    If you have any feedback on our support, please click
    here

  • Autodiscover not setting outlook anywhere accordingly

    We have installed 2013 Mailbox and CAS Server on separate boxes into our 2010 environment.  We have migrated a few users and it seems autodiscover does not configure Outlook anywhere on the Outlook 2010 client.  If we configure this manually the
    user can connect and view mail.  Outlook web access is fine, certificates appear to be working as we can manually configure Outlook and it is ready mail very well.  We are running Exchange 2013 CU3, and have installed the certificate on the CAS. 
    the autodiscover dns entry has been changed to point to the 2013 CAS.
    Is this a common problem and what can we try to do to resolve this issue ?
    I've read a few different posts and looked at authentication of virtual folders (still default setup), certificates (added new certificate from company CA).  Any ideas ? 

    Hi CompGuy2012,
    To troubleshoot the autodiscover issue, I suggest we refer to the test email auto-configuration:
    [Check AutoConfiguration Status in Outlook]
    ===================================
    a. While Outlook is running, click the CTRL key and then right-click the Outlook icon in the system tray and then select “Test Email Autoconfiguration”.
    b. Confirm that your email address is in the address field, uncheck “Use
    Guessmart” and “secure Guessmart
    authentication” boxes. Then click the “Test” button.
    c. Once it runs, Check the Log tab andResults
    tab.
    Let us know the detailed error message.
    Thanks,
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
    [email protected]
    Simon Wu
    TechNet Community Support

  • Testing Autodiscover failed

    We are running Exchange 2007 on Windows 2008 and planning to move to Office 365. However, we can't do it because Exchange 2007 Autodiscover issue.
    When we test it from
    www.testexchangeconnectivity.com, we receive
    Testing Autodiscover failed wth these details:
    1. The SSL certificate failed one or more certificate validation checks.
    2. Certificate name validation failed.
    We don't have problem to access the OWA. When I check the certificate on OWA website, it is correct. I can login
    https://autodiscover.ourdomain.com/autodiscover/autodiscover.xml. Here is the get-exchangecertificate information:
    [PS] C:\Windows\system32>get-exchangecertificate | fl
    AccessRules       
    : {System.Security.AccessControl.CryptoKeyAccessRule, System
    .Security.AccessControl.CryptoKeyAccessRule, System.Securi
                ty.AccessControl.CryptoKeyAccessRule}
    CertificateDomains : {remote.ourdomain.com, www.remote.ourdomain.com}
    HasPrivateKey     
    : True
    IsSelfSigned      
    : False
    Issuer            
    : SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Au
                    thority, OU=http://certificates.godaddy.com/repository, O=
    "GoDaddy.com, Inc.", L=<st1:city w:st="on">Scottsdale</st1:city>, S=<st1:state w:st="on"><st1:place w:st="on">Arizona</st1:place></st1:state>, C=US
    NotAfter          
    : 4/8/2019 2:47:53 PM
    NotBefore         
    : 4/8/2009 2:47:53 PM
    PublicKeySize     
    : 1024
    RootCAType        
    : ThirdParty
    SerialNumber      
    : 02BFCE2827
    Services          
    : IMAP, POP, IIS, SMTP
    Status            
    : Valid
    Subject           
    : CN=remote.ourdomain.com, OU=Domain Control Validated, O=rem
    ote.ourdomain.com
    Thumbprint        
    : 9BFF2C1C6F99785A97CA19A1B50D942EE4CF3273
    AccessRules       
    : {System.Security.AccessControl.CryptoKeyAccessRule, System
    .Security.AccessControl.CryptoKeyAccessRule, System.Securi
    ty.AccessControl.CryptoKeyAccessRule, System.Security.Acce
    ssControl.CryptoKeyAccessRule}
    CertificateDomains : {DC, DC.ourdomain.local}
    HasPrivateKey     
    : True
    IsSelfSigned      
    : True
    Issuer            
    : CN=DC
    NotAfter      
        : 4/8/2010 2:41:04 PM
    NotBefore         
    : 4/8/2009 2:41:04 PM
    PublicKeySize     
    : 2048
    RootCAType        
    : Unknown
    SerialNumber      
    : 647A4A520EBA0582441BF33F595AE7A0
    Services          
    : SMTP
    Status            
    : Invalid
    Subject           
    : CN=DC
    Thumbprint        
    : 43780186DDBE3034DD6565E932DBF2EC94238950
    How do you verify the certificate and autodiscover are setup correctly?
    Bob Lin, MCSE &amp; CNE Networking, Internet, Routing, VPN Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net How to Install and Configure Windows, VMware, Virtualization and Cisco on http://www.HowToNetworking.com

    Hi,
    According to the result of get-Exchangecertificate, the name autodiscover.domain.com isn't in the certificate( the property CertificateDomains shows the names in one certificate).
    Additionally, I'd like to confirm if there is any SRV record in the Exchange 2007 environment for Autodiscover connection. If there is no SRV record, we need to add the name autodisocver.domain.com in the certificate.
    And if there is no inconvenience for you, I'd like to confirm the result of your ExRCA test.
    Thanks,
    Angela Shi
    TechNet Community Support

  • Autodiscover returns mis-spelt fqdn

    Hi,
    Autodiscover XML returns various nodes with a typo in the FQDN. This breaks move mailbox as MRSProxy as the URL is incorrect.
    I cannot find where this typo is, the XMl nodes are:
    <Type>EXHTTP</Type>
            <Server> wrong FQDN</Server>
    PublicFolderServer>wrong FQDN</PublicFolderServer>
    <Type>EXPR</Type>
            <Server>wrong FQDN</Server>
    Where are these values obtained from? How can these be fixed and rebuilt.
    Thanks

    Hi,
    I think I've resolved this by re-installing the CAS role. For any other person looking at this...
    1) HCW had an exception that was raised with MS; thought it was wildcard certificate, so added new certificate, no change - no fix for some days. (later found 2013 fine with wildcard)
    2) Thought I'd install CU5 to see if this fixed it, but CU5 had issues on the MBX and CAS roles. I had a virtual environment and I added more RAM, CPU maxed out as it was checking CU5 executables. Disabled AV and then this ran quicker.
    3) Running the HCW threw up an autodiscover virtual directory problem which I fixed. Still HCW exception.
    4) Got 2013 CU6 update from MS - fixed exception, then ran into autodiscover issue - server names internal.
    5) Fixed autodiscover issue, but couldn't move mailbox. MRSProxy error. Fix involved setting internal and external URLs, TechNet says yes, other MS article says its a myth -http://blogs.technet.com/b/rmilne/archive/2013/04/02/busting-the-set-autodiscovervirtualdirectory-myth.aspx
    Well for me it wouldn't work until these were set. Maybe the underlying issue got in the way. Does anyone really know?
    6) Autodiscover XML wrong FQDN in some places - looked at cmdlets, ADSIEdit couldn't find issue.
    7) Removed Autodiscover virtual directory, but couldn't re-add  got an obscure cmdlet error reported by others with no resolution.
    8) Removed Exchange on CAS
    9) Tried re-install of CU5,but this can't be a complete installer as gave exception on pre-requisites so installed 2013SP1  - installed OK. Haven't gone to CU5 as yet.
    10) Updated internal and external URL - autodiscover and EWS say working, XML now looks good
    11) HCW fails with old CAS entry in AD; fixed with ADSIEdit
    12) HCW completes but tenant configuration in OAuth timeout exception
    13) ran removehybrid... cmdlet
    14) HCW completes on premise and in the cloud
    15) Test-Migration... cmdlet now says OK
    This is my test lab on 2012 R2, 2013 SP1 with vanilla installs and it has taken me days.... I'm just wondering if I dare run this in production...
    Now for the interesting bit which is what ports/URLs does this actually use. I've been through all the posts but nothing really tells me what it uses. This is for a government client and this has to pass strict compliance. Come on MS lets have some better description
    of the plumbing.
    Hope that helps someone...

  • Getting error while preparing to send sharing message

    I have seen many people post up about this same error, however I am going to share some details in the troubleshooting I have performed.
    Environment: Exchange 2013. Cloud hosted. Internet connectivity using any number of clients. Mostly OWA, but a few Outlook 2010 and Outlook 2013.
    1. User A with Outlook 2010 or Outlook 2013 right clicks on the calendar and clicks "Share" -> "Share Calendar". They look up User B in the Global Address List and click "Send." An error window pop-up states "Error while
    preparing to send sharing message." User A is able to click on Calendar Permissions and add User B to the correct permissions. User A with OWA is able to right click on the calendar and click "Share Calendar" and it will send the message, no
    errors.
    2. User B with Outlook 2010 or Outlook 2013 on the same computer that User A was trying to do this from right clicks on the calendar and clicks "Share" -> "Share Calendar". They look up User A in the Global Address List and click "Send".
    No errors and the message goes through fine. It works correctly with OWA as well.
    I have seen people put up "autodiscover" and "permissions" or other things. This is obviously not a permission issue because the same thing that can be accomplished in OWA can't be accomplished in Outlook. It isn't an autodiscover issue
    because the same thing that one person can accomplish on a computer/Outlook, another cannot. This is the same error that I have seen since the time of Outlook 2007 and have yet to see a valid solution.
    Thanks,
    Don

    Hi Don,
    Hope it is the solution:
    You can't share your calendar in Outlook 2007
    http://support.microsoft.com/kb/2836889
    Thanks
    Mavis
    Mavis Huang
    TechNet Community Support

  • Exchange online and Exchange 2010 on-premise calendar availability

    I am running a hybrid exchange 2010 on-premise and online exchange environment.  The online exchange users cannot see calendar availability of anybody on premise.  The on-premise users can see the online exchange availability.  I can see the
    calendar if the calendar is shared, but trying to setup a meeting or calendar appointment still shows the unavailable through all days.
    All of the users are using office 365 for outlook on premise and exchange online.  If it is only working one way, could it be an autodiscover issue where it is not configured correctly on our on-premise exchange 2010 or online exchange?  Which
    side would be causing the issue?

    I have done a little more research and ran the following in powershell:
    [PS] C:\Windows\system32>Get-FederationInformation -domainname weiman.com
    RunspaceId            : f4af09c7-134a-4fe7-95c0-acd120c63949
    TargetApplicationUri  : outlook.com
    DomainNames           : {Weiman.onmicrosoft.com, weiman.com, Weiman.mail.onmicrosoft.com}
    TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
    TokenIssuerUris       : {urn:federation:MicrosoftOnline}
    IsValid               : True
    [PS] C:\Windows\system32>Get-OrganizationRelationship | FL
    RunspaceId            : f4af09c7-134a-4fe7-95c0-acd120c63949
    DomainNames           : {herbertstanley.com, weiman.com, Weiman.mail.onmicrosoft.com}
    FreeBusyAccessEnabled : True
    FreeBusyAccessLevel   : LimitedDetails
    FreeBusyAccessScope   :
    MailboxMoveEnabled    : True
    DeliveryReportEnabled : True
    MailTipsAccessEnabled : True
    MailTipsAccessLevel   : All
    MailTipsAccessScope   :
    TargetApplicationUri  : outlook.com
    TargetSharingEpr      :
    TargetOwaURL          : http://outlook.com/owa/herbertstanley.com
    TargetAutodiscoverEpr : https://pod51043.outlook.com/autodiscover/autodiscover.svc/WSSecurity
    OrganizationContact   :
    Enabled               : True
    ArchiveAccessEnabled  : True
    AdminDisplayName      :
    ExchangeVersion       : 0.10 (14.0.100.0)
    Name                  : On Premises to Exchange Online Organization Relationship
    DistinguishedName     : CN=On Premises to Exchange Online Organization Relationship,CN=Federation,CN=WEIMAN,CN=Microsof
                            t Exchange,CN=Services,CN=Configuration,DC=herbertstanley,DC=com
    Identity              : On Premises to Exchange Online Organization Relationship
    Guid                  : 26b4ec5d-fe93-473e-b451-1f9aa2e94ebb
    ObjectCategory        : herbertstanley.com/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship
    ObjectClass           : {top, msExchFedSharingRelationship}
    WhenChanged           : 1/13/2014 1:25:54 PM
    WhenCreated           : 12/17/2013 1:04:32 PM
    WhenChangedUTC        : 1/13/2014 7:25:54 PM
    WhenCreatedUTC        : 12/17/2013 7:04:32 PM
    OrganizationId        :
    OriginatingServer     : gemini.herbertstanley.com
    IsValid               : True
    I am not sure why we have that value for the OriginatingServer.  That server is a backup domain controller, not the server that houses the on-premise exchange.
    I then ran the set-OrganizationRelationship and get the below error.
    [PS] C:\Windows\system32>Set-OrganizationRelationship -Identity weiman.mail.onmicrosoft.com -targetapplicationUri outloo
    k.com -TargetAutodiscoverEpr https://pod51043.outlook.com/autodiscover/autodiscover.svc/WSSecurity
    The operation couldn't be performed because object 'weiman.mail.onmicrosoft.com' couldn't be found on 'gemini.herbertst
    anley.com'.
        + CategoryInfo          : NotSpecified: (0:Int32) [Set-OrganizationRelationship], ManagementObjectNotFoundExceptio
       n
        + FullyQualifiedErrorId : F2215CB2,Microsoft.Exchange.Management.SystemConfigurationTasks.SetOrganizationRelations
       hip
    How do I change the originating server to be my exchange server?

  • Best practice to create users - Hybrid scenario

    I would like to know what is the best practice for creating new users in a Hybrid scenario with all mailboxes hosted and no mailboxes on-premise.
    Currently when creating a new user we go to our local EMC and create a 'New Remote Mailbox'.  This creates the mailbox in Office365 and the local user account in one wizard.
    After the new user is created we have to manually add the user to the correct distribution groups, and security groups.
    We would like a way to create new users using a template which already has the correct distribution groups and security groups.  This is how we did it prior to setting up the Hyrbrid scenario.
    Is this possible?  Can we create a user from a template and have the mailbox created in Office365 at the same time?  We do not wish to create the mailbox locally then migrate it.

    Thanks for the response DJStatik.  I think this tool might be useful for creating users in bulk, however we are looking for a user template in the traditional sense.
    Occasionally we have a new user and (prior to O365) would 'copy' the template user to ensure correct groups etc.
    We have tried making users from the existing template we have, but in order to create the mailbox in O365, you need to 'mail enable' the user.  We have noticed that doing this process causes issues with Autodiscover for that particular user.
    To avoid the autodiscover issue, we have found it best to create the user and the mailbox in the same wizard - hence our new process that we would like a template.

  • New Wildcard SSL certificate

    Guys,
    We had a certificate expire on our CAS servers that was used for webmail, autodiscover etc. WE had purchased a wildcard cert for use on the newly installed ADFS servers for our migration to office 365. Rather than renew the original SAN cert, I imported
    the wildcard cert into cas, (same domain name) bound the cert in IIS, then completed an IISRESET. Launched outlook again, it prompted to accept the new wildcard cert. I accepted it. Logged out of outlook, launched again, prompted again for certificate. I then
    installed the certificate via the prompts in outlook. Yet each time I launch outlook, it is still asking to accept certificate. Any thoughts?

    Guys,
    Thanks for the suggestions, but here is the fix.
    I finally received a call from MSFT in regards to the certificate popup in Outlook. From what I had written earlier, I was on the right track, but it was ultimately an autodiscover issue.
    For this conversation, my client’s domain name is Domain.com
    FQDN names of the CAS servers are CAS01.nyc.domain.com / CAS02.nyc.domain.com
    Now, all the steps that were completed, importing the *.domain.com cert into Exchange via EMC, and importing the cert using Certificate manager snap-in were successful. I was curious if the *.domain.com would cover a servers name if the server name was like
    my client, CAS01.nyc.domain.com. Typically it’s just CAS01.Domain.com. You would think so, but I was not totally convinced. MSFT did say that it is fine for the server, but, the AutodiscoverInternalURL CAS01.nyc.domain.com was the underlying problem. Once
    the outlook client tried to login, it used the AutodiscoverInternalURL, which was shown to be
    https://CAS01.nyc.Autodiscover.domain.com/Autodiscover/Autodiscover.xml . Same for CAS02
    So we ran the command below which removed the nyc,
    Set-ClientAccessServer –Identity CAS01 -AutoDiscoverServiceInternalUri
    https://CAS01.autodiscover.domain.com/autodiscover/autodiscover.xml
    Same for CAS02. Completed an IISRESET, all better now…….

Maybe you are looking for