Tag Archives: Exchange 2013

Exchange 2013 Error: This computer is a member of a cluster

Uncategorized

Had an issue in the lab today.  Went to uninstall an Exchange 2013 server that I had previously removed from a DAG, yet when I went to uninstall Exchange 2013, kept getting an error message that “this computer is a member of a cluster”, even though it was not.  It was an easy enough fix, ran cluster.exe node /force and then tried the uninstall again.

Worked like a charm.

Configure an Exchange 2013 DAG on Windows Server 2012 R2 With No Administrative Access Point

DAG, Exchange 2013, High Availability

Exchange 2013 SP1 introduced support for Windows Server 2012 R2, and also introduced support for a new feature in Windows Server 2012 R2, Failover Clusters without an Administrative Access Point.  You can now create a DAG, that does not need separate IP’s on each subnet for the DAG itself.  It also no longer creates the CNO which is seen as the computer account in Active Directory.  The benefit of this feature is that you reduce complexity, no longer need to manage the computer account for the DAG, and no longer need to assign IP addresses for each subnet on which the cluster operates.  There are some downsides, but it shouldn’t affect Exchange admins much.  Mainly, since there is no ip address and no CNO, you cannot leverage Windows Failover Cluster admin tools to connect to it.  You need to leverage local PowerShell against a cluster node directly.  With Exchange, this shouldn’t be too much of a problem as almost all of the management of the cluster is handled with Exchange tools through management of the DAG itself.

In our example, we have two servers in separate AD sites that we are going to configure in our DAG:

PHDC-SOAE13MBX2

SFDC-SOAE13MBX2

We will create a DAG named SOA-DAG-2013.  Now, previously this would be the name of the CNO that Exchange would create underneath.  This is changed to essentially be a label that is stamped on all the nodes for management, but will no longer create the CNO.

If we login to EAC and navigate to Servers->Database Availability Groups, we can create the DAG by click on the plus sign:

image

Enter in the information for the DAG, and remember to specify your Witness Server.  It should be another Exchange 2013 Server in your primary datacenter location that is not also a member of the DAG.  We will specify one IP address of 255.255.255.255:

image

If we are doing this in PowerShell, the syntax is different:

New-DatabaseAvailabilityGroup –Name SOA-DAG-2013 –DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) –WitnessServer NYDC-SOAE13CAS1.soa.corp –WitnessDirectory c:\WitnessDirectory\SOA-DAG-2013

 

image

 

Now, from here, building the DAG should have the same steps.  Lets add the mailbox servers to the DAG.  If you don’t already have Windows Failover Clustering installed, these steps will install it for you.

From the EAC:, under Database Availability Groups select the DAG name, and click on the Server with the gearbox icon:

image

 

 

 

 

 

 

 

 

 

 

Add your servers to the DAG and click Save:

 

image

From the Exchange Management Shell:

Add-DatabaseAvailabilityGroupServer -Identity SOA-DAG-2013 -MailboxServer SFDC-SOAE13MBX2

image

And your all set.  The DAG has been configured with no Administrative Access. 

If we check the properties of the DAG in the EAC we can see the IP address is listed as 255.255.255.255:

 

image

And even though we had that string in the PowerShell command, if we check the IP address in PowerShell, we only have 255.255.255.255 listed as an IP address:

 

image

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

5.3.2 STOREDRV.Deliver: Missing or bad StoreDriver MDB Properties When Using Address Book Policy Routing in Exchange 2013

Exchange 2013, Hosting, hub transport

 

If your using the new Address Book Policy Routing Agent to assist in separating your tenant organizations, you may run into a situation where a user is not able to receive email sent to them.  If you check the message tracking logs with:

Get-MessageTrackingLog –Recipients emailaddress@company.com

You may get a result similar to this one below:

9

As we can see, our original email to SOA-User1@accessabac.us generated an Undeliverable.

Of particular note is the Recipient Status where it lists 532 5.3.2 STOREDRV.Deliver: Missing or bad StoreDriver MDB properties.

There are two causes of this.  The first seems to be a bug where the mailbox is hidden from address lists:

image

This appears to be fixed in Exchange 2013 CU2.  A workaround is to uncheck the hide from address lists box.  See this forum post by Greg Taylor of Microsoft:

http://social.technet.microsoft.com/Forums/exchange/en-us/69a3e303-f848-4729-b818-ea1acaeb43d2/exchange-2013-address-book-policy-routing-agent-issue-with-mailboxes-hidden-from-the-address-lists

The second cause, is not a bug but expected behavior. If the user you are trying to email to, is not a member of the GAL that is in their Address Book Policy, the email routing will fail.  I’ll give you an example.

In our case, we tried to email SOA-User1@accessabac.us.

The user has an Address Book Policy applied to him called ABP-Soa

image

If we check that address book policy with Get-AddressBookPolicy ABP-Soa we can see that the Default Global Address List is GAL-SOA

image

If we check the filter of that Global Address list with Get-GlobalAddressList GAL-SOA | select RecipientFilter:

image

We can see that the GAL is filtering for all recipients that are of the type UserMailbox that also has CustomAttribute1 set to value SOA.

If we check the mailbox soa-user1@accessabac.us:

image

So, there is our problem.  SOA-User1 has the Address Book Policy ABP-SOA assigned to him, which forces him to get the Global Address List GAL-SOA.  But since we failed to set CustomAttribute1 to SOA on his mailbox, he is actually not even showing up in his own GAL.  This is causing the routing issue.  We can simply fix this by ensuring the user is presented in his own GAL, in this case adding CustomAttribute1 with a value of SOA:

image

And you should be all set.