Outlook Anywhere: enabling, testing and troubleshooting
Although Outlook Anywhere, enabled on the onsite Client Access Server(s), is a requirement for migration to Exchange Online, many organizations will have already enabled it for simple client access onsite. In that case, there is no need to enable it, since it already is enabled, and probably no need to test or troubleshoot either.
Nevertheless, I've decided to post the following instructions for those who may not use Outlook Anywhere but are planning a migration to Exchange Online. I'll also share my solution to a problem with Outlook Anywhere, apparently related to IPv6, and that I was able to resolve without having to disable IPv6 entirely.
If you have already enabled Outlook Anywhere, and if it is perfectly functional, you could skip to "Part 3" of this series on a staged Exchange 2007 to Office 365 migration without reading the rest of this post.
Enable Outlook Anywhere
First, let's just enable Outlook Anywhere. The following cmdlet, entered at the EMS command line, is probably the most simple way to enable Outlook Anywhere:
Enable-OutlookAnywhere -Server 'Server1' -ExternalHostname 'mail.mydomain.net' -DefaultAuthenticationMethod 'Basic' -SSLOffloading $false
Note: if you do use SSLOffloading, change the value to "true".
If you really prefer the GUI, here is the equivalent procedure:
1. Right click on the server icon as shown below ("Server Configuration" section, "Client Access") and select the option "Enable Outlook Anywhere:
2. Enter the external host name. If your domain was contoso.com and you use mail.contoso.com for external access (to OWA, for example), that is what you would enter. I have concealed my domain name for privacy. In reality, you would enter the complete domain name.
3. You can verify that Outlook Anywhere has been enabled in Event Viewer. There should be an Event ID 3006 entry in the Application Log.
Test and troubleshoot Outlook Anywhere (optional)
In case of a problem with connectivity, especially outside the LAN, the Exchange Remote Connectivity Analyzer, or ExRCA, is one of the most useful troubleshooting tools available.
It can be found at the following URL:
www.testexchangeconnectivity.com
It can be found at the following URL:
www.testexchangeconnectivity.com
In case the URL ever changes, you could also look for "ExRCA" using your preferred search engine (Bing, Google, etc.).
One pre-requisite is the creation of a user account whose credentials can be used for the various tests. It is recommended to create such an account for testing purposes and then delete the account afterwards so the credentials cannot be reused or misused, presumably by someone who could conceivably access them one way or another.
On the ExRCA homepage, we can select from several tests: ActiveSync, Web Services, Outlook Anywhere, Autodiscover as well as Inbound and Outbound SMTP message flow.
In the context of my migration to Exchange Online, which requires Outlook Anywhere, I'll select the "Outlook Anywhere" test.
I enter the credentials of my test user:
The tool requires us to enter a "verification code" as well. The verification is valid for 30 minutes, after which another verification code must be entered:
I then click on "Perform Test" (in the lower right-hand corner).
The results are displayed...
And I have the option to "Start Over" or "Run Test Again".
The Outlook Anywhere test is successful in this case but let's create a situation where it would fail and then resolve the problem (this is, in fact, the problem I encountered when I performed the test for the first time).
***
In this scenario, we are running Exchange 2007 (SP3) on a Windows 2008 (SP2) server. By default, a component known as the RPCProxy attempts to connect, preferably with IPv6, to a component known as the DSProxy that... does not listen for IPv6 connections.
This produces the following error message:
Note: this was the case for Exchange 2007. I have SP3 with Rollup 10 installed so, even at that patch level, the problem apparently requires the modification that follows.
I was able to resolve this problem by simply adding a DWORD value ("DisabledComponents") at the following location in the registry of the Exchange 2007 server and entering "20" (without quotes) for the value data (hexadecimal):
HKEY_Local_Machine\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
This makes IPv4 the preferred protocol.
It was not necessary to disable IPv6, using the more "extreme" settings below, or on a particular network interface.
- Type 0 to enable all IPv6 components. (Windows default setting)
- Type 0xffffffff to disable all IPv6 components except the IPv6 loopback interface. This value also configures Windows to prefer using IPv4 over IPv6 by changing entries in the prefix policy table.
- Type 0x20 to prefer IPv4 over IPv6 by changing entries in the prefix policy table.
- Type 0x10 to disable IPv6 on all nontunnel interfaces (both LAN and Point-to-Point Protocol [PPP] interfaces).
- Type 0x01 to disable IPv6 on all tunnel interfaces. These include Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4, and Teredo.
- Type 0x11 to disable all IPv6 interfaces except for the IPv6 loopback interface.
Note: the "0x" indicates the value is hexadecimal. It is not necessary to enter "0x" and the registry editor may not even allow this.
Source:
Thank you for reading the article about Exchange 2007 (SP3) - migration (staged) - Exchange Online (Office 365) - Part 2 - Outlook Anywhere on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.