Recently I was assigned the job of getting Exchange Direct Push working for one of my customers. Essentially the place I work for was not prepared to go down the Blackberry route but still wished to give people access to both their mail and calendar whilst out and about using 3G compatible handsets or PDAs.

Now, I began researching this nearly six months ago, and I was astounded to see how many people had experienced great problems in getting the “Direct Push” or indeed the whole synchronization using Active Sync to work – and when I began to trial this in my test lab I could see why.

In essence my test lab reflected my production domain (for example two clustered back-end Exchange Servers running Exchange 2003 Ent SP2) with a single Front End Server running Exchange 2003 Std SP2) built with the same organizational settings as my production environment.

At the top of the Labs Exchange organizational hierarchy I enabled pretty much all of the Mobility settings on all the Exchange servers (the single front-end and the two back-ends);

Ensuring that I ticked the “Enable user initiated synchronization“, “Enable up-to-date notifications via SMTP and Text Messages“, “Enable notifications to user specified SMTP addresses“, “Enable Direct Push over HTTP(s)“.

As this was a test lab, rather than production I did not configure any Device Security as when trailing new technologies I like to keep it as simple as possible to avoid adding in problems which could be encountered later.

I also ticked the “Enable Outlook Mobile Access” and “Enable Unsupported Devices“

In terms of my Front-End / Back-End server configuration I opted for the Dual Authentication Model and based my FE / BE configuration as per Here.

Admittedly the setup that I am discussing would not be considered for any kind of deployment in production, however the objective of the lab was to prove that I could get ActiveSync on a Windows Mobile 5 based PDA to connect to an Exchange FES which in turn would proxy the requests for mail data from the relevant mailbox on one of the BES.

In my company we are using T-Mobile based PDA’s and Smart Phones - for example the MDA PRO, Vario and and SDA which have all recently (with the exception I think of the SDA) had Firmware Updates released to allow the devices to take advantage of the MSFP (which adds in full support for Direct Push and remote wipe), however for the purposes of the lab I decided to use the Windows Standalone Device Emulator as my client of choice.

Now that I was ready to test ActiveSync using the SDE I found that I could not get ActiveSync to connect or synchronize - I would continuously get HTTP_500 (or the error code 0×85010014) which was a real pain in the neck.

I tried every solution I could find - as per below:

• I tried changing the Exchange directories to support using Kerberos and NTLM (as per the article Here)
• I tried adding the SMTPProxy registry key - using Regedt32 I added the following value to HKLM\System\CurrentControlSet\Services\MasSync\Parameters.

Under the Parameters key I created a Reg_SZ value called SMTPProxy.

I then Set this value to the domain defined by the default recipient policy and then restarted the IIS Admin service.

As I was using a front-end/back-end configuration this registry key only needed to be added on the front-end server.

Occasionally I would get a different message (this would usually result if I made a change to the IIS host headers on the Back-End servers) but no matter what I tried it still would not work.

I was at my wits end (especially after nearly a week of tracing through logs on the PDA and on the Exchange Server but still no joy).

One Friday night, I had a couple of beers and decided to get creative. I had been reading Henrik Walther’s book CYA Securing Exchange Server 2003 and Outlook Web Access (sad I know - Friday night getting drunk and read Exchange books) and I began reading a section of the book which detailed the operation of the DS2MB service.

Now - I was (once upon a time) familiar with this process from the Exchange training courses that I had attended, but as time goes by you sometime forget the operation of this rather critical service.

For those of you (like me) that have forgotten what it does

The function of DS2MB is to replicate configuration information from Active Directory to the IIS metabase.

DS2MB is implemented as a process in DS2MB.dll and the primary function is to synchronize a number of Exchange configuration settings in Active Directory with its counterpart settings in the IIS metabase.

The DS2MB is a one way process. Only settings from Active Directory are copied to the IIS Metabase - nothing from the Metabase is sent back to AD.

The metabase update is launched when the System Attendant is started (or restarted).

The operation of SMTP, POP3, IMAP4, Outlook Web Access and OMA are all dependent on the replication by DS2MB. DS2MB registers with the config domain controller after startup, enabling the config domain controller to notify DS2MB of any changes that are made to the Exchange configuration. This notification occurs within 15 minutes of the change.

Now you maybe thinking, what has this got to do with why ActiveSync isn’t working - well the answer I found was like so.

During the configuration of the HTTP virtual servers (on all the Exchange Servers - FE and BE) in my lab I had - at times changed various settings in IIS rather than using the Exchange system manager (naughty I know) such as IIS host headers and in some cases permissions settings.

I was now pretty such that all of my problems were coming down to the way in which data had been replicated from AD into IIS (essentially data from AD was overwriting the information in the Metabase) and causing issues.

I decided that in order to return to a clean slate I would perform the process detailed in this Article and then start again - but this time only change settings via the ESM.

After I had recreated all of the folders for OWA / OMA and ActiveSync on each of the Machines in the test lab I started to play around with various permissions in the test lab, via the Exchange System Manager.

To Cut a (very, very) long story short I found that by applying a certain combination of permissions on the FES and the BES and also by playing around with the Host Headers ActiveSync, OWA and OMA worked perfectly, the following table details the changes;

NOTE: All Changes are made from the ESM ** NOT ** IIS admin:

Permissions On the Front End Server(s)

Exadmin VDIR = Should all be grayed out

Exchange VDIR = Anonymous access - not ticked (Account inherited from parent object), Basic authentication (Default domain should be set to “\”), Digest authentication should not be ticked, Integrated Windows Authentication should be grayed out)

Microsoft-Server-ActiveSync VDIR = No access to the authentication settings should be allowed (all should be grayed out).

OMA VDIR = Anonymous access - should be grayed out, Basic Authentication - the tick box should be grayed out but the default domain should be set to “\”, both Digest authentication and integrated authentication should be grayed out.

Permissions On the Back End Server(s)

In both my production environment and my lab Environment all of my back end servers are Clustered which according to Microsoft you need to assign host headers to the IIS in some instances.

I found that by adding Hosts headers that severely interfered with the operation of OWA / OMA / ActiveSync via the Front-End Server therefore I removed ALL traces of host headers from both the ESM and IIS system manager (which bizarrely seemed to work just a well as when configured with them - perhaps a fix in SP2?).

I then applied the following permission (via the ESM) to the HTTP virtual directories;

Exadmin VDIR = Should all be grayed out

Exchange VDIR = Anonymous access - not ticked (Account inherited from parent object), Basic authentication - should not be ticked, Digest authentication should not be ticked, Integrated Windows Authentication should be ticked.

Microsoft-Server-ActiveSync VDIR = No access to the authentication settings should be allowed (all should be grayed out).

OMA VDIR = Anonymous access - should be grayed out, Basic Authentication - the tick box should be grayed out but the default domain should be set to “\”, both Digest authentication and integrated authentication should be grayed out.

After implementing the above I tested OWA / OMA and ActiveSync - via the SDE and it all worked, however there is a problem with the configuration as it stands - its not inherently secure.

In the next part of the article I will go through how I transferred all of the above from my test lab to my production environment.