Category Archives: Managed Availability

How to Enable MAPI over HTTP (MAPI/HTTP) in Exchange Server 2013 SP1

Client Access, Exchange 2013, Managed Availability, Netscaler, Security

Decided to take the new SP1 for a spin tonight in the lab, and the first thing I wanted to play with was the new MAPI over HTTP functionality introduced in SP1 for Exchange Server 2013.  There are a couple of things we are going to need to get this setup:

There are a couple of things to note. 

  • Currently the ONLY Outlook clients that support this are Outlook 2013 SP1
  • There CAN be issues connecting to Public Folders if they are NOT running on Exchange 2013 Modern Public Folders (more on that later)
  • There can be issues connecting BACK to Exchange 2010 mailboxes through Exchange 2013 SP1 CAS servers if you JUST have MAPI/HTTP enabled.  RPC over HTTPS or Outlook Anywhere is here to stay for a bit.

Alright, so let’s set this up.  It’s actually really simple.  First, on your Exchange 2013 SP1 CAS servers, note that we have a new virtual directory named MAPI:

image

Okay, so open up the Exchange Management Shell.  We can inspect the setup of the MAPI virtual directory with the new Get-MapiVirtualDirectory command:

Get-MapiVirtualDirectory

image

So, the first thing we need to do is configure the directory.  We need to set the URL’s and the authentication method.  In our case, we will set both the internal and external url’s to https://mapi.accessabacus.com/mapi and the IISAuthenticationMethods to NTLM and Negotiate.  In my lab the name of my CAS server is PHDC-SOAE13CAS1.  So my command looks like the following command:

Set-MapiVirtualDirectory –Identity “PHDC-SOAE13CAS1\mapi (Default Web Site)” -InternalUrl https://mapi.accessabacus.com/mapi –ExternalUrl https://mapi.accessabacus.com/mapi -IISAuthenticationMethods NTLM,Negotiate

 

image

Next thing we should do is reset IIS.  Remember this will cause a disconnect so run it after hours:

IISRESET /noforce

After that is completed, we need to enable MAPI/HTTP for the organization.  Ensure that this will not cause issues in your Exchange Organization before you do it.

From the Exchange Management Shell run the following command:

Set-OrganizationConfig -MapiHttpEnabled $true

image

If you have an existing Outlook 2013 SP1 session open, you will most likely see the message: “An Exchange Administrator has made a change that requires you to restart your outlook”.

After you restart it, and go to connection status (hold the Control Key and right click the Outlook icon) you should see a set of connections using “HTTP” instead of “RPC/HTTP”.  RPC/HTTP is Outlook Anywhere, where HTTP is MAPI/HTTP.

image

image

Notice all my connections are going to Server name https://mapi.accessabacus.com and using the Protocol HTTP.

If you check the Autodiscover Log we will see there is a new provider from Autodiscovery:

image

Notice the Protocol is Exchange MAPI HTTP.  You can see the Exchange HTTP below it.  Exchange HTTP is Outlook Anywhere, where Exchange MAPI HTTP is the new MAPI/HTTP.

What else is interesting is if we go to the Outlook Anywhere Settings we see the screen is now removed from Outlook:

Outlook 2013 SP1 using MAPI/HTTP:

 

image

Outlook 2010 using Outlook Anywhere:

image

Note that the connection tab is missing.

Also, remember how I said you MAY have connection issues to legacy based Public Folders?  Well in my lab, I still have Exchange 2010 running public folders.  And since I have Outlook Anywhere, Outlook actually created one Outlook Anywhere connection for Public Folders:

image

Notice how the proxy server is “email-ph.lab.accessabacus.com”, the server name is PHDC-SOAEXC01, which is my Exchange 2010 Mailbox Server with a legacy public folder database.  Lastly note the protocol is RPC/HTTP.  Now, I in NO way think this is ideal, as we are straddling not only two protocols (MAPI/HTTP and Outlook Anywhere), two namespaces (email-ph.lab.accessabacus.com and mapi.accessabacus.com), but look at the screenshot.  We are using two separate authentication methods where MAPI/HTTP is Negotiating, where Outlook Anywhere is using NTLM.  Care should be taken again to ensure your organization can properly support connections so that they are using one or the other.

I also checked and of course the new MAPI virtual directory does respond to the Managed Availability URL check.  This can help when using load balancers that do health checks like the Citrix Netscalers.  I outline that in my article here (http://port25guy.com/2013/07/24/how-to-use-managed-availability-in-exchange-2013-with-your-load-balancer/)  If you go to https://hostnameofyourcas/mapi/healthcheck.htm and everything is working, you should get a 200 OK response back:

image

Lastly, if you want to disable Outlook 2013 SP1 from using the new MAPI/HTTP for any reason, you can do so using the registry.  Create the following key:

HKCU\Software\Microsoft\Exchange

Create a new DWORD value named MapiHttpDisabled and set the value to 1

You can also use that to troubleshoot.  If for some reason MAPI/HTTP is not working, check that key.  If its set to value 1 and you want to ENABLE it, you can do so by setting the value to 0.  If you need to mass deploy this you can so with a script, or Group Policy.

We will see how the performance of the new protocol works, as well as any other changes that need to happen as a result of this new architecture.

How to Use Managed Availability in Exchange 2013 with your Load Balancer

Exchange 2013, High Availability, Managed Availability, Netscaler

One of the major changes in Exchange 2013 is the concept of Managed Availability.  I wont go too deep into it, but it is the ability of Exchange 2013 to monitor itself, detect problems and attempt to resolve them.  One of the added bonuses of this, is that Managed Availability then knows when a particular application is working and able to serve data.  One of these specific instances where we can use it with third party tools is with hardware based load balancers.

One of the jobs of the hardware load balancer is to detect the health of the server that it is load balancing, something that Managed Availability is already doing itself!  Hardware load balancers can detect the health through a variety of different ways.  The basic is ping, which just checks if the host is responding to ping.  The obvious problem here is that the host could be up, but none of the services!  The next would be to check if a port is accessible.  Here you configure the load balancer to check if say port 443 is alive.  This is better than ping, but doesn’t check if the application is actually working behind the scenes, just that it can telnet to 443.  We can use Managed Availability with our hardware load balancer to check if the application itself is actually healthy.

How do we do that?  Say we want a HLB to check if OWA is healthy on a server.  The normal http path would be https://servername/owa right?  Well, if you navigate to https://servername/owa/healthcheck.htm, you will get a page generated on the stop indicating if OWA is working on that server.

For example, say we have two Exchange 2013 servers:

PHDC-SOAE13CAS1 – 10.220.10.3

PHDC-SOAE13CAS2 – 10.220.10.4

And we want to publish OWA through a HLB to email.company.com at ip address 10.220.10.1

If we navigate to https://PHDC-SOAE13CAS1/owa/healthcheck.htm on this server with working OWA, we get the following page:

image

Not a lot too it, but essentially its returning a 200 OK message indicating the service is working. If the service was not working, this page would not generate.  So we can have our HLB check to see if it gets a 200 OK response from a particular server.

We want to configure these in our load balancer for services such as OWA, Activesync, Outlook Anywhere etc.  So, we will configure Exchange 2013 using Citrix’s Netscaler in this example.  The configuration will be similar for other HLB, but we’ll go through the steps here.

On the Netscaler go to Load Balancing->Monitors and click add to create a new monitor.  Here, we will create a custom monitor for the Netscaler, so that it can poll that web page.  Name the monitor MONITOR-EXCHANGE2013_OWA and set the type to HTTP-ECV.  Ensure to select the Secure check box at the bottom as this will be over SSL.  Leave the other options default:

image

Next, click on the Special Parameters tab.  In the Send String box enter in GET /owa/healthcheck.htm.  In the Receive String box, enter in 200 OK:

image

Click create to save, and navigate over to Load Balancing –>Service Groups

Add a new Service Group, and name it Exchange2013-OWA and set the protocol to SSL.  Enter in the IP addresses of your CAS servers, and set their ports to 443

image

Next, click on the Monitors tab.  Find the Monitor_Exchange2013_OWA monitor we created above and add it to the configured Monitors selection

image

Click on the SSL Settings tab and select the SSL certificate that you will use to publish the Netscaler service to the internet.  I have a preloaded one named Lab-2013 that I will be using:

image

Click Create to save the Service Group.

If we check, our service group should be reporting up, that’s good, it means our monitor is working!

image

Next lets go to Load Balancing->Virtual Servers

Create a new Virtual Server and name it Exchange2013_OWA, Set the Protocol to SSL, and assign it an IP, in our case 10.220.10.1. Leave the SSL Port at 443.

image

Select the Service Groups tab and select the service group Exchange2013-OWA we created earlier:

image

Then click on the SSL Settings tab and select the same certificate as you did on the service group, in our case Lab-2013:

image

Click Create to save the virtual server.

Next, make sure your DNS address is pointing to the IP address of the virtual server and lets try to login:

image

There we go!  There is are OWA page!  But, the question is how do we test that our monitor is working.  That’s easy.  On PHDC-SOACAS2, lets go into IIS Manager and stop the MsExchangeOWAAppPool:

image

If we check our Netscaler, we see that one of the servers is now being reported as down:

image

If we try to telnet to that server on port 443:

image

We can see it works fine:

image

I know it doesn’t show much, but it shows that the server is still listening on port 443.  This also proves that using Managed Availability for your HLB is much better.  Here, the standard checks would have said the server was working fine, sent user requests to it, but in fact OWA isn’t working.  But since we are using Managed Availability, we are passing that knowledge on an application layer to our HLB.

If we try to go back to OWA:

image

The HLB sees that one server is down, and runs everything to the server that’s still up.  But, if both servers have their application pools stopped:

We get a HTTP Error, The Service is unavailable:

image

This works for all of the Exchange web services.  So that means you can create separate monitors just be appending healthcheck.htm at the end of the URL.  So for ActiveSync its https://servername/Microsoft-Server-ActiveSync/healthcheck.htm.  The only one that has a stipulation is OWA, which requires Forms Based Authentication to be enabled for it to provide a HealthCheck.htm page.

I hoped you have found this helpful, and hopefully it will save you some configuration steps (and some uptime!) on your hardware load balancer