Exchange 2013 public folders not avaliable via Exchange using HTTP connection.

Process of elimination question.

So, I've been through a couple of Exchange 2013 migrations.  Not many but a few.  The last few have been Office 365 so hopefully I want confuse the two but it is a interesting problem for sure.

So, you stated 2008 to 2013.  I'm not familiar with 2008 Exchange but I've done 5.5, 2007, 2010, and 2013.

The biggest issues are obvious when moving to Exchange 2013 and leaving the customers on Outlook 2003 and not upgrading the CAS servers.  

And I've been there where you look at something long enough it might be right in front of you and someone else come along and hit the nail on the head.

The first thing I would look at, if me, is the no errors.  And if you are like me, Exchange is not my primary job all day.  I never wanted that, I made it a goal to become a polymath and scholar of all technology.  

Sometimes, pointing out the obvious is taken as insult but I'm just going through the process of elimination because I think the worst thing we can do is assume something was done.  My role forces me not to assume it was done right.  I assume worse case like you might have inherited this or brought in too late.  I still have a checklist of things that would need validation.

For Public Folders to work period, in 2013, requires AutoDiscover on and having the record defined so it resolves internal or external which I know as split-DNS.

You are having the opposite problem in some cases where you expect it to work internal if it works external.

On the errors thing, first thing I do is having Outlook open hold down CTRL Key and go all the way right were the clock is and right-click on the little Outlook icon.

Depending on the client, I have 2013 Outlook, the first thing I do is run the Autodiscover Test but right before that I make sure the error options at top are all checked.

Then, in the test tool I just enter my email address and password but I would have made sure the record existed first.  

But forget that for a moment.  I know for sure that if you are looking a the Advanced Tab for your Exchange configuration if the Download Shared Folders is greyed out it is Group Policy 100% if that is a domain joined computer.

I know that I have Exchange 2013 SP1 and Outlook 2013 SP1 so I can use the HTTP which is merely encapsulating RPC.  But it requires SP 1 on both if I want MAPI over HTTP and Outlook Anywhere to work.

For Outlook 2010 if I want the same requires Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015).

Anything else less I get Outlook Anywhere only.

And some of these things should have caused errors but when that MAPI virtual directory is defined it requires a SSL Certificate that resolves to the same exact name internal or external and it must be trusted by the Outlook client which is why we used Verisign.  

I know that we could not
Set-OrganizationConfig -MapiHttpEnabled $true

Until all public folders were migrated.  You can still have 2010 and 2007 Exchange servers and in the same Forest but if anything was left on 2010 or 2007 the Outlook 2013 SP 1 Client cannot access those and the recommendation is to not enable HTTP MAPI until after all Public Folders have been transitioned.  If that happens and stuff was left behind you could not migrate after the fact, anything migrated after turning MAPI HTTP on was not going to work.

There is a Powershell command you might like right away.  I found it handy
https://technet.microsoft.com/en-us/library/dd638082%28v=exchg.150%29.aspx

It is called Test-OutlookConnectivity and is the same as monitoring probes, essentially.

So, back to Test Email Autoconfig.  I actually had more issues with using Outlook 2013 SP1 on non-domain joined computer.  Like home office.  

I did not work on that piece but it requires me to use my userID@UPN

So, at home I am logging on as userID@adchild2.adchild1.root

Not my DOMAIN\USERID like with standard NTLM.  

So I run the Test and there is a Results Tab, Log Tab, and XML Tab.

When you run it, I have to provide my credentials again despite being connected with Outlook.

That first tab has pretty much everything you need.

I verify that the external OWA and internal OWA URL is the same, they must match
Protocol: Exchange RPC
LoginName:UserID (no UPN Suffix)

Then it validates every service required
Availability Service URL
OOF URL
OAB URL
Unified Message Service
Exchange Control Panel (ecp)

Keep scrolling down
Protocol: HTTP
Auth Package: NTLM

Here is where I see the Certificate principle name for first time starting with mssstd:matching FQDN

So, every service the matching FQDN is the same.  And in the same domain namespace that is registered external.

So if you register the domain mycompany.com the FQDN is not a single host it would be myportal for example.  So everything is https://myportal.mycompany.com

And those must actually resolve to the same IP every time.  Does not allow for split-DNS scenario on that one.  Internal or external that is a public IP address and maybe you have it bound to a content switch and use rewrite rules to direct traffic by virtual directory path.

So when autodiscover begins that might be a registration that is in the root of DNS.

Like https://mycompany.com/autodiscover/autodiscovery.xml starting now....

If you watch the log, it starts off with IMAP then POP3 and so forth but where I have seen failures is the first part.

Mine even now fails the first one and redirects to https://autodiscover.mycompany.com/autodiscover/autodiscovery.xml but it has to match https://myportal.mycompany.com/autodiscover/autodiscovery.xml.  That is where I've seen the failures is until it hits myportal that same base starting domain it will fail and it also requires a SRV record not just A-Record.

This is right because for some reason by default it does not start with the record.  This happens every time but then it hits https://myportal.mycompany.com/autodiscover/autodiscovery.xml and SRV lookup everything works.

If you examine the XML Tab, everything must match.  Public folders is myportal.mycompany.com

ASURL, EWS, EMWS, ECP all start with myportal.mycompany.com and then a virtual path

If you want a next step I would start with that tool.  You can control the logging, like I usually turn off GuessSmart Auth because that is all the IMAP and POP3 stuff.

I just don't want to throw a lot of stuff at you and you have already done all this, and then I would use the Powershell script to find out more going on internal.

A lot of the Internal Stuff, sounds a lot like Group Policy because they had a lot of functionality turned off for some reason.  iCalendar, all that stuff was disabled.

But, were I work requires DoD Security Clearance.  Most people don't know about Autodiscover to use it External.  And on the domain, some of these things were disabled.

You can rule this out easy.

Command Prompt

GPRESULT /H C;\Temp\grouppolicies.html

You probably already know but the /H is a verbose output to an HTML file and I usually create a directory first and it does require the entire drive and path and name with html suffix.

Does this get you started or have you done all these things?

Because there are other things you can do with the CTRL right-clcik on Icon I did not discuss.

There are ways to force Outlook to log entries to Event Log as well.  UNLESS they disable that in GPO, which happens a lot.

Figured it out on my own.