Search This Blog

Wednesday 31 August 2011

Exchange 2010 MAPI not working - Only Outlook Anywhere works!

Recently I had an issue during an EX2003 - EX2010 migration where MAPI appeared not to work but Outlook Anywhere did!!

The symptoms were this:

An outlook profile would refuse to connect first time but upon a restart of Outlook you would get a standard username/password dialog box. Once the credentials were entered Outlook would connect and the user would be happy. A quick look at the connection status showed that Outlook was connected over HTTPS ie. Outlook Anywhere - But this had not been configured for the client so how was this happening?

One look at the Outlook profile showed that Outlook Anywhere was indeed enabled, indeed if you disabled this it would immediately re apply itself next time Outlook was launched.

All the ususal suspects were examined in turn as we thought it must be a GPO or dodgy Outlook .PRF file, the onsite guys even thought it was some new Exchange 2010 security feature that forces all connection to be made by HTTPS!!


The Exchange CAS array was behind a hardware load balancer so this was bypassed but the result was the same. So that ruled out the load balancer...So we thought :-)

Basically I had made a schoolboy error and had neglected to add the RPC Endpoint Mapper (TCP:135) to the Exchange Virtual IP. The result was that Exchange treated all client connections as remote and using a bit of autodiscover wizardry it established a HTTPS connection and modified the Outlook profile to reflect a HTTPS connection.

Closer examination of the load balancer showed the error and once RPC traffic was added to the load balancer front end everything started working properly.

But why did it still fail when I bypassed the loadbalancer? Simple - I had a peaky hosts file directing the CAS array name to the load balancer so changing the CAS array 'A' record had no effect!

Moral of the story is to check the simple things first I guess!



Wednesday 24 August 2011

You must close all dialog boxes before you can close Exchange Management Console

I thought it was just me but a bit of research shows that loads of people are getting the annoying error above when they try to close the Exchange 2010 EMC.

There is a massive thread here: http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/ea4e1ffe-472e-4508-9a14-0735ac6322ca/ but to save you the trouble of reading it in full there is a simple fix...

Uninstall Internet Explorer 9 and the EMC will work correctly again.

Then I suggest keeping an eye on IE9 hotfixes to see when the bug is fixed.

Tuesday 23 August 2011

Install Exchange 2010 without 64bit DCs

No 64bit Domain Controllers in Forest Root Domain


Recently a customer wanted Exchange 2010 installed into a multi domain environment where the forest root domain had no 64 bit servers. As the Exchange 2010 setup program will only run on a 64 bit machine you will need either a 64bit DC or 64bit member server in the forest root domain to run the necessary preparation routines.


This can easily be addressed but it requires some thought beforehand - ie, don't get caught out by bad planning and have to rush the procedure through change control!


Basically the machine that you use to prepare the Active Directory must be in the same domain and site as the schema master and if it is not a domain controller it will need the RSAT (Remote Server Admin Tools) installed.


According to Technet topic article - 
Forest/Domain Preparation - With Exchange Server 2010, you will need to leverage a 64-bit operating system to perform the schema extension and forest/domain preparation work. Hopefully you have 64-bit Active Directory servers deployed (or are planning to deploy them) and this won't be an issue. In the event that you do not have 64-bit Active Directory servers, you can install a 64-bit member server (physical or virtual) into the forest root domain, place it in the schema master's AD site, and apply the schema and forest preparations; for domain preparation, you can either update all domains by leveraging the /preparealldomains setup switch, or by removing/joining the 64-bit member server to each domain in the forest that you need to update.

When Exchange 2010 is installed into an organisation with more than one domain the setup process needs to make certain changes to the directory schema and AD structure. This process is normally handled seamlessly by the Exchange setup program and if you have only one domain then regardless of the DCs in use the Exchange 2010 server must be a 64 bit machine so assuming it is in the same AD site as the schema master your setup will proceed directly from the new exchange server itself.


If your forest root domain does not have any suitable 64bit DCs I have found the easiest thing to do is to move a potential exchange 2010 server into the Forest Root domain (ensuring it is in the same site as the schema master), run the exchange setup program as follows:

  1. Move suitable server into Root Domain
  2. Open Powershell as Administrator
  3. Import-Module ServerManager - to allow you to add windows features
  4. Add-WindowsFeature RSAT (& restart) If you don't do this setup will fail
Once you have got the server ready we need to use an elevated command prompt and use the Exchange 2010 CLI setup program to prepare the Schema, Exchange2010 permissions and AD itself. See http://technet.microsoft.com/en-us/library/bb125224.aspx for the full explanation.

So, from the command line we need to run the following commands:

setup /prepareAD This command prepare AD as a whole (sub features like legacy permissions are automatically prepared)

setup /pad This will prepare ALL domains in the forest

Once you have taken these steps you should check to ensure that the relevant security groups etc have been created in both the top level and child domains. Assuming they have you can proceed to move the 64 bit server back out of the root domain and continue to install exchange 2010 into the organisation.