Public Folder Migration Error

So when I tried to migrate public folders from Exchange 2007 to 2013, I encountered the following error:

Error: Property expression "xxx xxx" isn't valid.

It appears that for some reason, some mail enabled Public Folders had Alias properties with blanks in them. As we all know, blank or spaces are not allowed in Alias field.

The easiest way to fix this is to launch Public Folder Management Console (from mmc.exe, add snap-in), locate all mail enabled public folder and correct the Alias field.

Sigh - Outlook Anywhere Exchange 2007 not playing nice with Exchange 2013

OK, now it's Outlook Anywhere's turn to go wonky. Users on Ex2007 is reporting that they cannot access Outlook externally.

exRCA returned an error:

RPC Proxy can't be pinged.

Additional Details An unexpected network-level exception was encountered. Exception details: Message: The remote server returned an error: (401) Unauthorized. Type: Microsoft.Exchange.Tools.ExRca.Extensions.MapiTransportException Stack trace: at Microsoft.Exchange.Tools.ExRca.Extensions.MapiRpcTestClient.PingProtocolProxy(String endpointIdentifier) at Microsoft.Exchange.Tools.ExRca.Tests.MapiPingProxyTest.PerformTestReally() Exception details: Message: The remote server returned an error: (401) Unauthorized. Type: System.Net.WebException Stack trace: at System.Net.HttpWebRequest.GetResponse() at RpcPingLib.RpcPing.PingProxy(String internalServerFqdn, String endpoint) at Microsoft.Exchange.Tools.ExRca.Extensions.MapiRpcTestClient.PingProtocolProxy(String endpointIdentifier) Elapsed Time: 280 ms.

To make the long story short, the authentication method for Outlook Anywhere has to be set to NTLM on both Ex2013 and Ex2007. Again, just like the previously mentioned ActiveSync and OWA virtual directory issues, I had to reconfigure Outlook Anywhere.

1. Disable Outlook Anywhere (http://technet.microsoft.com/en-us/library/bb124537(v=exchg.80).aspx)
2. Enable Outlook Anywhere - only performing the step under "To use the Exchange Management Console to enable Outlook Anywhere" (http://technet.microsoft.com/en-us/library/bb123889(v=exchg.80).aspx)

Re configuring Outlook Anywhere will need 15 minutes to take effect. Watch the event viewer for the following entry:

Event Type: Information
Event Source: MSExchange RPC Over HTTP Autoconfig
Event Category: General 
Event ID: 3003
Date: 6/10/2014
Time: 10:50:51 AM
User: N/A
Computer: EXCHANGESERVER
Description:
The Outlook Anywhere authentication settings have been updated.

Old settings: Ntlm
New settings: Basic

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This article provides an extremely friendly insight that I could not find elsewhere:

http://blogs.technet.com/b/rmilne/archive/2014/03/19/exchange-2007-2013-outlook-anywhere-coexistence.aspx

The parts that struck me was:

1. Note the two different authentication settings that are listed.  ClientAuthenticationMethod and IISAuthenticationMethods.   For the detail oriented people out there, you saw that one was plural and the other singular.
2. Client authentication, which is used to allow clients like Outlook 2013 to authenticate with Exchange is properly configured.  The same consistent OA client authentication scheme should be deployed on legacy CAS and CAS 2013. 
3. Internet Information Services (IIS) authentication, which is used to allow Exchange servers to communicate MUST include NTLM auth.

Therefore, I have also additionally set the IISAuthenticationMethods to NTLM as well (it was Basic only for some reason)

Set-OutlookAnywhere -Identity 'ExchangeServer\Rpc (Default Web Site)' -ClientAuthenticationMethod Basic -SSLOffloading $False –ExternalHostName http://webmail.company.com -IISAuthenticationMethods NTLM, Basic

Exchange 2007 OWA not playing nice with Exchange 2013 for redirection

As part of Exchange 2007 & 2013 co-existence, to provide seamless OWA login for both users having mailboxes in either Exchange environment, the typical Microsoft prescribed method of OWA redirection was deployed  - http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

As the customer was using ISA Server 2006, the first thing is to bypass that and change Exchange 2007 OWA into Forms Based Authentication (FBA). It was set to Basic Authentication previously to support ISA 2006 publishing.

Here comes the trouble, after logging in from OWA 2013, the following error message was displayed:

440 Login Timeout

We tried numerous things, including changing the authentication methods in IIS7 for OWA, but none worked.

The only way that we managed to get it working is to re-create the OWA virtual directories following the article (http://support2.microsoft.com/kb/941201). Only trouble is, although all the virtual directories were deleted and recreated successfully, the /OWA virtual directory would not come up! When the PowerShell cmdllet was ran, an obscure error message popped out (sorry I didn't have screenshot), basically saying that is has no access to Active Directory.

Did a few things and none worked (including forceing AD replication "repadmin /syncall"),

More Internet searching came out with this solution  (http://blogs.dirteam.com/blogs/davestork/archive/2010/12/23/fixing-a-broken-owa-2010-virtual-directory.aspx) - but just as I was going to recreate the OWA container, I tried re-running the New-OWAVirtualDirectory cmdlet (not retyping it, just running the command history to repeat the command) and it worked.

I have no idea why only the /OWA virtual directory have this problem (/Exchange, /public/ and /exchweb had no such issue) - but I guess sometime button meshing does make sense.

Oh well, onward we go.

Exchange 2007 ActiveSync not playing nice with co-existence with Exchange 2013

This project that I am working on is giving me one gold nugget after another...  Anyway, so we are trying to setup co-existence between Exchange 2013 and 2007, and we stumbled into this issue.

Exchange 2013 does not seem want to proxy ActiveSync request for users still having mailbox on Exchange 2007. When testing Exchange Connectivity Test (https://testconnectivity.microsoft.com/), the error returned was:

An HTTP 500 response was returned from IIS7.

It seems that it's Exchange 2007 at fault here. The only way to fix it is to recreate the ActiveSync virtual directory on Exchange 2007, using the following PowerShell commands:


Remove-ActiveSyncVirtualDirectory -Identity "EXCHANGEServer\Microsoft-Server-ActiveSync (Default Web Site)" -Confirm:$false


New-ActiveSyncVirtualDirectory -WebsiteName "Default Web Site" -InternalUrl "https://webmail.company.com/Microsoft-Server-ActiveSync" -ExternalAuthenticationMethods Basic -InternalAuthenticationMethods Basic

The Exchange 2007 Microsoft-Server-ActiveSync virtual directory must be corrupted along the way.