none
Cannot open your default e-mail folders. You must connect to Microsoft Exchange with the current profile before you can synchronize your folders with your Outlook data file (.ost)

    Question

  • Fresh installation of Exchange Server 2013 on Windows Server 2012.

    Our first test account cannot access their email via Outlook but can access fine through OWA. The following message appears - "Cannot open your default e-mail folders. You must connect to Microsoft Exchange with the current profile before you can synchronize your folders with your Outlook data file (.ost)" is displayed.

    If I turn off cached Exchange mode, setting the email account to not cache does not resolve the issue and i get a new error message - "Cannot open your default e-mail folders. The file (path\profile name).ost is not an Outlook data file (.ost). Very odd since it creates its own .ost file when you run it for the first time.

    I cleared the appdata local Outlook folder and I tested on a new laptop that has never connected to Outlook, same error message on any system.

    Microsoft Exchange RPC Client Access service is running.

    No warning, error or critical messages in the eventlog, it's like the healthiest server alive.

    Any help would be greatly appreciated. I haven't encountered this issue with previous versions of Exchange.

    Saturday, December 08, 2012 4:57 AM

All replies

  • Hello,

    For this issue, I suggest you follow these steps to troubleshoot the issue:

    <1>Use another user to test, check whether he can use Outlook to access his mailbox or not?

    <2>If this user also cannot connect to his mailbox, I suggest you go to check whether all the Exchange services are started, make sure RPC client access service is started.

    If only that user have this issue, I suggest you disconnect that mailbox and reconnect to have a try.

    Thanks,

    Evan Liu

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tnmff@microsoft.com


    Evan Liu
    TechNet Community Support

    Monday, December 10, 2012 4:19 AM
  • Evan, thank you for the response.

    1. All users have this issue on any PC. I created a fresh user and same error message.

    2. All Exchange services are started which includes Microsoft Exchange RPC Client Access, the only exception being the Exchange services that are off by default (IMAP4 and POP3).

    The server's been restarted multiple times since the installation so services have been restarted as well.

    Monday, December 10, 2012 2:39 PM
  • For kicks, I installed Office 2013 onto the server to determine if this is some kind of older Office or server communication problem but the issue still exists.

    Terribly unfortunate that Exchange 2013 doesn't work on a fresh, out of the box installation of Windows Server 2012. Also extremely frustrating.

    Tuesday, December 11, 2012 10:06 PM
  • Hi,
    Have you replaced the Self-Signed certificate on the Server (=you need to)?
    The clients needs to trust the certificate installed on the server in order to be able to connect, since the connections is not only made with RPC/HTTPS.

    See Step 4: Configure Mail Flow and Client Access

    I have seen new installation of EX13 having SSLOffloading turned on causing the problems. Turn if off if you do.

    Example:
    Set-OutlookAnywhere -Identity 'SERVERNAME\rpc (Default Web Site)' -SSLOffloading $false



    Martina Miskovic

    Wednesday, December 12, 2012 4:40 AM
  • Can you not use a self signed cert here? (That's what we have in place here) 

    If this is a trust issue it agitates me to no end that i have no such errors, simply just an obscure 'cannot open your default e-mail folders' error.

    Thursday, December 13, 2012 3:41 AM
  • Can you not use a self signed cert here? (That's what we have in place here) 

    If this is a trust issue it agitates me to no end that i have no such errors, simply just an obscure 'cannot open your default e-mail folders' error.



    The client must trust the certificate you have installed and that is not the case with the self-signed certificate.
    If you have one internal CA, you can use a certificate issued from that one if you don't want to buy one from a Third-Party Issuers like GoDaddy or Digicert (just two of many Public Issuer/CA Authority)


    Martina Miskovic

    Thursday, December 13, 2012 4:49 AM
  • Evan, thank you for the response.

    1. All users have this issue on any PC. I created a fresh user and same error message.

    2. All Exchange services are started which includes Microsoft Exchange RPC Client Access, the only exception being the Exchange services that are off by default (IMAP4 and POP3).

    The server's been restarted multiple times since the installation so services have been restarted as well.

    If so, did you check whether there is any related error in your event log?

    Thanks,

    Evan Liu

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tnmff@microsoft.com


    Evan Liu
    TechNet Community Support


    Sunday, December 16, 2012 1:53 PM
  • No warning, error or critical messages in the eventlog, it's like the healthiest server alive.

    The quote above is from my first post.

    Since those days, I've noticed some warnings in my eventlog experienced since along the same as these guys: http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/43dc86c2-d35c-45c4-bbed-fe13f6e9d060

    However I've seen the same non-descriptive warnings on working Exchange 2013 so I believe them to be unrelated to my issue.

    Ignoring all this, I was skeptical of the earlier suggestion that an SSL certificate was required and was the cause of my problem so I installed Windows Server 2012 and Exchange Server 2013 into a VM, configured it the same as the system that encouraged this thread, and then installed Microsoft Outlook 2007 and sure enough it works just fine without an SSL certificate. So the earlier suggestion that this was my problem is incorrect, it is not.


    Moving forward, I wiped the intended production system I'd originally created this thread for and then freshly installed Windows Server 2012 and Exchange Server 2013... and this problem exists. I can connect my Outlook to my VM installed Exchange 2013 but I cannot connect it to the physical server as it gives me this error message. I don't understand!


    There's something odd, some step that I didn't or did do in the VM that I didn't on the production system. Based on the spelling mistakes seen during install and the source code / script error message that's dumped out if someone disables IPv6, it's starting to look like Exchange 2013 isn't a completed product and the issue may not be on my end.

    Monday, December 17, 2012 4:38 AM
  • No warning, error or critical messages in the eventlog, it's like the healthiest server alive.

    The quote above is from my first post.

    Since those days, I've noticed some warnings in my eventlog experienced since along the same as these guys: http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/43dc86c2-d35c-45c4-bbed-fe13f6e9d060

    However I've seen the same non-descriptive warnings on working Exchange 2013 so I believe them to be unrelated to my issue.

    Ignoring all this, I was skeptical of the earlier suggestion that an SSL certificate was required and was the cause of my problem so I installed Windows Server 2012 and Exchange Server 2013 into a VM, configured it the same as the system that encouraged this thread, and then installed Microsoft Outlook 2007 and sure enough it works just fine without an SSL certificate. So the earlier suggestion that this was my problem is incorrect, it is not.


    Moving forward, I wiped the intended production system I'd originally created this thread for and then freshly installed Windows Server 2012 and Exchange Server 2013... and this problem exists. I can connect my Outlook to my VM installed Exchange 2013 but I cannot connect it to the physical server as it gives me this error message. I don't understand!


    There's something odd, some step that I didn't or did do in the VM that I didn't on the production system. Based on the spelling mistakes seen during install and the source code / script error message that's dumped out if someone disables IPv6, it's starting to look like Exchange 2013 isn't a completed product and the issue may not be on my end.

    Monday, December 17, 2012 4:38 AM
  • No warning, error or critical messages in the eventlog, it's like the healthiest server alive.

    The quote above is from my first post.

    Since those days, I've noticed some warnings in my eventlog experienced since along the same as these guys: http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/43dc86c2-d35c-45c4-bbed-fe13f6e9d060

    However I've seen the same non-descriptive warnings on working Exchange 2013 so I believe them to be unrelated to my issue.

    Ignoring all this, I was skeptical of the earlier suggestion that an SSL certificate was required and was the cause of my problem so I installed Windows Server 2012 and Exchange Server 2013 into a VM, configured it the same as the system that encouraged this thread, and then installed Microsoft Outlook 2007 and sure enough it works just fine without an SSL certificate. So the earlier suggestion that this was my problem is incorrect, it is not, Outlook will connect fine on another system that does not have a certificate configured.


    Moving forward, I wiped the intended production system I'd originally created this thread for and then freshly installed Windows Server 2012 and Exchange Server 2013... and this problem exists. I can connect my Outlook to my VM installed Exchange 2013 but I cannot connect it to the physical server as it gives me this error message. I don't understand!


    There's something odd, some step that I didn't or did do in the VM that I didn't on the production system. Based on the spelling mistakes seen during install and the source code / script error message that's dumped out if someone disables IPv6, it's starting to look like Exchange 2013 isn't a completed product and the issue may not be on my end.



    Monday, December 17, 2012 4:38 AM
  • Hi,
    You do need to replace the self-signed certificate.
    If you don't want to buy a certificate from a Third-Party Issuer, then install Windows CA and issue a certificate from there.

    Even if it does work with the self-signed certificate using Outlook 2007, it is not a supported configuration and you will not be able to connect with Outlook 2010/2013.

    Did you check if SSLOffloading was enabled?


    Martina Miskovic

    Monday, December 17, 2012 6:47 AM
  • I apologize, you may be totally right after all. I was tired and frustrated during my last experience and the outcome is different this time around from my first post.

    Round 1 of fresh install of Server + Exchange, could not open Outlook on client or server.

    Round 2 of fresh install of Server + Exchange on different server, could open on server so I figured case closed.

    Round 3 of fresh install of Server + Exchange on first server, could not open Outlook on client but could on server. Then tried to connect Outlook to second system and discovered it was a no-go so that means the outcome is really the same between trial 2 and 3, trial 1 is the only issue.

    Not sure why it didn't work on round one, I went through the same steps but since the server's a CA and has its own cert, it's allowing it to work whereas the client PC isn't connected via AD so hasn't received the certificate.

    I'm going to try a few things then update this thread with the outcome in the event anyone else googles this problem and the solution aids them. Thanks to both of you for motivating me to correctly resolve my problem!

    Monday, December 17, 2012 8:03 PM
  • Sigh. Even after importing the certificates, I still can't access my Exchange mail account on a client PC the Exchange server on any other systems, I still receive the same error message.

    "Cannot open your default e-mail folders. You must connect to Microsoft Exchange with the current profile before you can synchronize your folders with your Outlook data file (.ost)."

    I can access it just fine ON the server, in an RDP session with Outlook but I can't access it on a client PC.


    Monday, December 17, 2012 10:59 PM
  • Have you replaced the self-signed certificate now using the instructions in the TechNet Article
    Configure Mail Flow and Client Access (Step 4) ?

    Martina Miskovic

    Tuesday, December 18, 2012 5:23 AM
  • Yes. And then I decided to try an experiment and delete all certificates on the server to see what the behaviour would be using Outlook there and it's not the same situation. On the server, if I delete all certs, the system basically won't authenticate my username and password. I do not receive the same 'cannot open your default e-mail folders' message I receive on the clients and rather, I receive an authentication issue.
    Tuesday, December 18, 2012 3:42 PM
  • This entire experience is frustrating and currently I'm raging on Windows Server 2012 + Exchange Server 2013, this hasn't been as easy an out-of-the-box experience as previous combinations of Windows and Exchange.

    I discussed this with the tech that's working on this task and it turns out he was not able to follow your linked directions because the CA won't accept the certification request so my 'yes' response wasn't accurate in the sense that it was attempted but it would not work.

    ---

    The first attempt to import the request in CA resulted in:

    "The request contains no certificate template information. 0x80094801

    (-2146875391)

    Denied by Policy Module 0x80094801, The request does not contain a certificate template extension or the CertificateTemplate request attribute."

    -----

    So then I tried to certreq -submit -attrib "CertificateTemplate:myserver" certrequest.req and received the following error:

    "The requested certificate template is not supported by this CA.

    0x80094800 (-2146875392)

    Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate policy: myserver."

    ----

    Since Microsoft has upped the difficulty level in deploying Windows + Exchange, are there any detailed guides that give you step by step cohesive instructions on installing this combination? I bold cohesive as following the Technet guide for Exchange 2013 by itself will lead to an inaccessible server.

    I really just want to get Exchange 2013 up and running on Server 2012 and I can't believe they've made it so difficult compared to previous versions.

    Wednesday, December 19, 2012 4:07 PM
  • Hi,
    I saw a similar error once when trying to generate a certificate from a Windows CA and the problem was that the Root Certificate had expired.

    If you need help to troubleshoot your Windows CA, I suggest that you post in the Windows Security Forum
    http://social.technet.microsoft.com/Forums/en-US/winserversecurity/threads


    Martina Miskovic

    Wednesday, December 19, 2012 4:15 PM
  • the root certificate is still good for another year. In the event there was something up with it, I deleted it and created another one and that didn't resolve my issue.

    I'm going to wipe the server for a third time and have another go at it. I simply can't believe Microsoft would release new products that don't work so smoothly, together, out of the box without a great deal of effort since previous combinations of Windows + Exchange have almost always worked fine out of the box, maybe needing a schema update or a few other minor tweaks. I'll follow the guide to the letter to see if I'm missing a crucial step.

    In my previous post I'd asked if there are any detailed guides that provide a step by step instruction on installing Exchange 2013 on Server 2012; if anyone has such an online area or book to buy, I'd be interested in viewing it so we can get this going.

    Wednesday, December 19, 2012 6:40 PM
  • I was googling the same error message with Outlook 2013 and came across this article, which resolved it for me.  Not sure if you have the same issue ... good luck

    http://www.expta.com/2012/10/rpc-client-encryption-in-exchange-2013.html

    Wednesday, December 19, 2012 8:34 PM
  • Unfortunately this setting, on or off, offers no change in my experience. But I appreciate the suggestion!

    Wednesday, December 19, 2012 10:29 PM
  • Make certain that all appropriate services are running - in particular 'MS Exchange RPC Client Access'.

    In the EMC -> Server Configuration - If you receive the following error message, make sure the 'MS Exchange Service Host' service is running and/or restart it.

    If your VM worked fine and you installed directly from an ISO\Image, than this is suspicion of a bad installation of Windows and\or Exchange occurring.

    Make certain that you are not looking at a hardware failure at this point and run diagnostics on RAM, Hard Disk, DVD Drive.

    Also make certain that your installation media is good.

    Kyle

    Friday, January 11, 2013 10:16 AM
  • Hi William,

    Did you find a resolution to this issue? im having the same problem and im pulling out my hair here :(, ive spent a week on this and its getting extreamlly frustrating.

    hope you did find the issue and can point me in the right direction.

    regards

    Ajay

    Tuesday, February 12, 2013 11:20 AM
  • Hi William,

    Did you find the solution of this issue, i too have the same problem and not able to find any solution for this. 

    can you help us if you find any solution for this issue 

    waiting for your response 

    thanks 

    Junaid 

    Saturday, February 16, 2013 1:35 PM
  • Hi Evan,

    We are also facing the same problem. The outlook 2010 gives the same error while connecting to exchange server 2013 standard. i tried all the solutions you provided below but nothing help me out. 

    Do you have any fixed solution for this problem please let us now as i have to move the new exchange server in the production ASAP.

    I really appreciate your help.

    Thanks in advance 

    Mohammed Junaid Ahmed

    Sunday, February 17, 2013 5:06 AM
  • We are also facing the same problem. The outlook 2010 gives the same error while connecting to exchange server 2013 standard. i tried all the solutions you provided below but nothing help me out. 


    Hi,
    If you get the error message "Cannot open your default e-mail folders. You must connect to Microsoft Exchange with the current profile before you can synchronize your folders with your Outlook data file (.ost)" It very likely that you haven't changed the self-signed Certificate and you need to (as already mentioned above)

    See Step 4: Configure Mail Flow and Client Access


    Martina Miskovic

    Sunday, February 17, 2013 5:11 AM
  • Thanks Martina. I have been searching for a solution for this error all week. I will try to reconfigure the Mail flow and client access tomorrow. Seems like a solution. Thanks for your help. i will update late tomorrow. Desh
    • Edited by Sunblesser Monday, February 18, 2013 6:45 PM
    Monday, February 18, 2013 6:45 PM
  • Hi Martina,

    Thanks for the information you provided above, I changed the Self-Signed Certificate with the new SSL Certificate which i generated from godaddy. but still i am getting the same error while connecting client outlook 2010 to exchange server 2013. and i check the services of exchange and i found all the services of exchange server is running fine.

    Please can you give some to solve this problem.

    Waiting for your reply.

    Thanks

    Mohammed Junaid

    Thursday, February 21, 2013 11:45 AM
  • This worked for me;

    You need to set authenticationmethod to basic, Ntlm, Negotiate on the outlook anywhere.

    Set-OutlookAnywhere "<Client Access server name>\RPC (Default Web Site)" -IISAuthenticationMethods Basic, Ntlm, Negotiate

    Set-OutlookProvider EXPR -CertPrincipalName none

    Then restart the MSExchangeServiceHost

    Configure Outlook to use rpc over http and remove the selection for Connect only to Proxy...

    B.r,Rudi



    • Proposed as answer by lotrudi Thursday, February 21, 2013 9:46 PM
    • Unproposed as answer by lotrudi Thursday, February 21, 2013 9:46 PM
    • Proposed as answer by lotrudi Thursday, February 21, 2013 9:54 PM
    • Edited by lotrudi Friday, February 22, 2013 9:28 AM
    Thursday, February 21, 2013 9:23 PM
  • Hi Martina,

    Thanks for the information you provided above, I changed the Self-Signed Certificate with the new SSL Certificate which i generated from godaddy. but still i am getting the same error while connecting client outlook 2010 to exchange server 2013. and i check the services of exchange and i found all the services of exchange server is running fine.

    Please can you give some to solve this problem.

    Waiting for your reply.

    Thanks

    Mohammed Junaid

    Hi Mohammed,
    Can you please create a new thread for your problem?
    Post the link to it here when you have so it will be easier for me to find it:)

    Add information about:

    1. The names you included in your certificate
    2. The output you get when running Test-OutlookWebServices.
    3. The output you get when running Get-OutlookAnywhere | fl *hostname,*auth*


    PS. Good choose to replace the Self-Signed Certificate!!


    Martina Miskovic

    Friday, February 22, 2013 5:35 AM
  • Configure Outlook to use rpc over http and remove the selection for Connect only to Proxy...

    Looks like that's what did it for me!  I'm also learning Exchange 2013 in a testing environment.  Deleted the original self-signed certificate after creating a new self-signed certificate that represented the server's names & IP.  Assigned the new self-signed certificate to IIS and SMTP.  Exported that self-signed certificate to a PFX file on a shared folder and installed that on the testing client as a trusted root certification authority.  Then configuring the Outlook 2013 client that's part of this testing domain to use RPC over HTTP and pointed it to the Exchange server's hostname/IP.  And it looks like that finally worked!  Outlook 2013 finally logged in! 

    • Proposed as answer by Access Genius Saturday, March 02, 2013 5:21 PM
    Tuesday, February 26, 2013 5:08 PM
  • AdamZ 1977 solution works.  My previous experience with Exchange was Exchange 2003.  I also found the setup requirements to connect an Outlook 2007 client on my network to Exchange 2013 to very frustrating.  But if you follow his steps it works just fine.

    Martina said many time to do Step 4.  DO STEP 4!  Thank you Martina, you were very patient with us.

    I still have to test web access.  I still want to use an SSL from my internal Certificate Authority Server (proving to be its own set of challenges) but Adamz simple set of steps now has my clients connecting.  And all of it is with Exchange tools.  Now I can enjoy my weekend.

    Thank all of you again.

    Saturday, March 02, 2013 5:34 PM
  • Same problem. But I'm using Class 2 wildcard SSL for external domain. My CA does not provide for internal domain for SSL.

    How do I to do?

    Thursday, March 28, 2013 6:33 AM
  • So it looks like a lot of people are having this issue and seeing how Exchange 2013 is still new (relatively to the world) there isn't much data around to answer this. I've spend ALOT of time trying to figure this out.

    Here is the answer. :) - No I don't know all but I'm going to try to give you the most reasonable answer to this issue, in a most logical way.

    First thing I did when I was troubleshooting this issue is that I ignored Martina Miskovic's suggestion for Step4 http://technet.microsoft.com/library/jj218640(EXCHG.150)because it didn't make sense to me because I was trying to connect Outlook not outside the LAN but actually inside. However, Martina's suggestion does fix the issue if it's applied in the correct context.

    This is where the plot thickens (it's stew). She failed to mention that things like SSL (which I configure practically useless - anyone who ever worked in a business environment where the owner pretty much trusts anyone in the company, otherwise they don't work there - very good business practice in my eyes btw, can confirm that...) are some sort of fetish with Microsoft lately. Exchange 2013 was no exception.

    In exchange 2003, exchange 2007 and exchange 2010 - you could install it and then go to outlook and set it up. And when outlook manual Microsoft Exchange profile would ask you for server name, you would give it and give the name of the person who you setting up - as long as machine is on the domain, not much more is needed. IT JUST WORKS! :) What a concept, if the person already on premises of the business - GIVE HIM ACCESS. I guess that was too logical for Microsoft. Now if you're off premises you can use things like OutlookAnywhere - which I might add had their place under that scenario.

    In Exchange 2013, the world changed. Ofcourse Microsoft doesn't feel like telling it in a plain english to people - I'm sure there is an article somewhere but I didn't find it. Exchange 2013 does not support direct configuration of Outlook like all of it's previous versions. Did you jaw drop? Mine did when I realized it. So now when you are asked for your server name in manual outlook set up and you give it Exchange2013.yourdomain.local - it says cannot connect to it. This happens because ALL - INTERNAL AND EXTERNAL connection are now handled via OutlookAnywhere. You can't even disable that feature and have it function the reasonable way.

    So now the question still remains - how do you configure outlook. Well under server properties there is this nice section called Outlook anywhere. You have a chance to configure it's External and Internal address. This is another thing that should be logical but it didn't work that way for me. When I configured the external address different from the internal - it didn't work. So I strongly suggest you get it working with the same internal address first and then ponder how you want to make it work for the outside users.

    Now that you have this set up you have to go to virtual directories and configure the external and internal address there - this is actually what the Step 4 that Martina was refering to has you do.

    Both external and internal address are now the same and you think you can configure your outlook manually - think again. One of the most lovely features of Outlook Anywhere, and the reason why I had never used it in the past is that it requires a TRUSTED certificate.

    See so it's not that exchange 2013 requires a trusted certificate - it's that exchange 2013 lacks the feature that was there since Windows 2000 and Exchange 5.5.

    So it's time for you to install an Active Direction Certificate Authority. Refer to this wonderful article for exact steps - http://careexchange.in/how-to-install-certificate-authority-on-windows-server-2012/

    Now even after you do that - it won't work because you have to add the base private key certificate, which you can download now from your internal certsrv site, to Default Domain Policy (AND yes some people claim NEVER mess with the Default Domain Policy, always make an addition one... it's up to you - I don't see direct harm if you know what you want to accomplish) see this: http://technet.microsoft.com/en-us/library/cc738131%28v=ws.10%29.aspx if you want to know exact steps.

    This is the moment of ZEN! :) Do you feel the excitement? After all it is your first time. Before we get too excited lets first request and then install the certificate to actual Exchange via the gui and assign it to all the services you can (IIS, SMTP and there is a 3rd - I forgot, but you get the idea).

    Now go to your client machine where you have the outlook open, browse to your exchange server via https://exchang2013/ in IE and if you don't get any certificate errors - it's good. If you do run on hte client and the server: gpupdate /force This will refresh the policy. Don't try to manually install the certificate from Exchange's website on the client. If you wanna do something manually to it to the base certificate from the private key but if you added it to the domain policy you shouldn't have to do it.

    Basically the idea is to make sure you have CA and that CA allows you to browse to exchange and you get no cert error and you can look at the cert and see that's from a domain CA.

    NOW, you can configure your outlook. EASY grasshoppa - not the manual way. WHY? Cause the automatic way will now work. :) Let it discover that exachange and populate it all - and tell you I'm happy! :)

    Open Outlook - BOOM! It works... Was it as good for you as it was for me?

    You may ask, why can't I just configure it by manual - you CAN. It's just a nightmare. Go ahead and open the settings of the account that got auto configed... How do you like that server name? It should read something like 8e45e992-a5ff-41f8-9868-0e02fd800b80@myemail.com and if you go to advanced and then connection tab - you'll see Outlook Anywhere is checked as well. Look at the settings - there is the name of the server, FQDN I might add. It's there in 2 places and one has that Mtdd-something:Exchange2013.yourdomain.local.

    So what is that GUID in the server name and where does it come from. It's the identity of the user's mailbox so for every user that setting will be different but you can figure it out via the console on the Exchange server itself - if you wish.

    Also a note, if your SSL certs have any trouble - it will just act like outlook can't connect to the exchange server even though it just declines the connection cause the cert/cert authority is not trusted.

    So in short Outlook Anywhere is EVERYWHERE! And it has barely any gui or config and you just supposed to magically know that kind of generic error messages mean what... Server names are now GUIDs of the mailboxes@publicdomainname.com - THAT MAKES PERFECT SENSE MICROSOFT! ...and you have to manage certs... and the only place where you gonna find the name of the server is inside the d*** Outlook Anywhere settings in the config tab, un it's own config button - CAN WE PUT THE CONFIG ANY FURTHER!

    Frustrating beyond reason - that should be Exchange's new slogan...

    Hope this will help people in the future and won't get delete because it's bad PR for Microsoft.

    PS

    ALSO if you want to pick a fight with me about how SSL is more secure... I don't wanna hear it - go somewhere else...

    • Proposed as answer by C.Rice Thursday, July 25, 2013 10:45 AM
    Friday, July 05, 2013 6:08 PM
  • THANK YOU! Worked like a charm.
    • Edited by C.Rice Thursday, July 25, 2013 10:46 AM spelling error
    Thursday, July 25, 2013 10:45 AM
  • Hello! 

    I also had this problem. When I was check service "Microsoft Exchange RPC client access". Was disabled. After enabling service worked.

    Thanx a lot for your reply.

    Saturday, January 04, 2014 1:10 PM
  • Hi, just to add to this you dont actually need to buy or add any new certificates to the server to get Outlook clients (Outlook 2007, 2010 or 2013) to work properly with Exchange 2013 if you are on Windows 7 (not XP).

    As long as the client PC has joned the domain:

    1. On the PC to use Outlook navigate to your OWA login page using Internet Explorer (no other browser)

    2. Click where it says 'Certificate Error' next to the URL and select View Certificate

    3. Click 'Install Certificate' and manually browse to store it in Trusted Root Certificates

    4. Start the Outlook client and it will setup and connect properly without error

    ---

    Thursday, April 10, 2014 12:14 PM
  • Same problem with Exchange 2013 running on Server 2012 and then trying to connect with Outlook 2007 running on Windows 8 client on same domain in home network. I can use OWA on client OK to access Exchange. Many hours spent on this so far.

    Server details:

    Microsoft Information Store Service, Microsoft RPC Client Access services running OK

    Using Certificate generated by server with Certificate Authority feature as per instructions at

    http://inside.exchangeserverpro.com/members/exchange-2013-boot-camp/module-1/

    Get-OutlookAnywhere | fl *hostname*,*auth* returns

    External Hostname:server2012a.waratah.local

    Internal Hostname:server2012a.waratah.local

    ExternalClientAuthenticationMethod : Negotiate

    InternalClientAuthenticationMethod: Ntlm

    IISAuthenticationMethods               :{Basic, Ntlm, Negotiate}

    Client details:

    Certificate error when using OWA removed by installing from IE via View Certificate

    No addition to hosts file (adding IP address and name of Exchange server didn't work)

    Tried Exchange cached and non-cached modes when setting up profile from Mail in Control Panel

    Deleting OST files from User\Appdata\Microsoft\Outlook folder didn't work

    Wednesday, May 07, 2014 1:03 PM
  • Here's what you need to do to resolve this issue ...

    1. Hit OWA (https://exchange2013server/owa) from a browser on client machine where you have Outlook installed

    2. Establish connection by trusting self-signed certificate, install that certificate into local 'trusted root authorities' container

    3. Launch Outlook, configure profile manually (not using autodiscover - assuming you're testing on a standalone machine, not domain-joined and namespace is also not configured properly), enter server name and user name manually, check name, etc. This will not fail, if it fails, you got some other issue ...

    4. Once profile successfully configured, go into profile settings (Control Panel : Mailsigned certificate in the Connection settings 'Use this URL ...' field, check 'Connect using SSL only', leave 'Only connect to proxy ...' unchecked, check the two boxes 'on fast' and 'on slow' networks, leave the authentication set to NTLM .. you're all done ...

    Get out of there and launch Outlook, it should connect!

    So basically with E2013 RPC/HTTPs is the default way to connect, the s in HTTPs requires SSL, so you need a cert, we install self-signed cert by default, to establish SSL, you need to trust that cert - once that's done, you need to configure Outlook profile manually (for the reason mentioned in #3 above) to set those proxy settings to make sure Outlook is configured appropriately to connect ...


    Sr. Program Manager, Product Quality, Exchange Client Access Server

    Thursday, June 19, 2014 11:21 PM