A few years ago I attended an Exchange Server 2003 overview presented by Microsoft UK and Conchango (where I subsequently worked for a while) and got to play with Outlook Mobile Access (OMA) using an emulated mobile phone connection. I was pretty impressed (these were the days before smartphones became a reality) but haven’t used the functionality since. Until last night that was, when (inspired by a mobility presentation which Jason Langridge gave at the Microsoft UK Security Summit a couple of days back) I was tweaking a few settings on my Exchange server and decided to enable OMA.

For those who are not familiar with OMA, it supports mobile microbrowser access to Exchange Server 2003 for browsers that use HTML, extensible HTML (XHTML), wireless application protocol (WAP) 2.x or compressed HTML (CHTML) with access to Inbox, Calendar, Contacts, and Tasks as well as a searchable global address list and searchable Inbox folders .

My handset is a fairly simple Nokia 6021 (but it does everything that I need it to) and is not on the list of supported handsets but there’s an option in Exchange System Manager to enable unsupported devices. After enabling OMA in the mobile services global settings (and optionally enabling unsupported devices) browsing to the server and reading my messages should be as simple as initiating a GPRS connection from my phone to my Exchange server (but with /oma instead of /exchange) and logging on (SMTP forwarding is also available but it requires the use of a WAP gateway and additional settings to define the mobile carrier).

Unfortunately my browse request was greeted with the following error message:

A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.

Additionally, Exchange Server logged the following error in the application event log:

Event Type: Error
Event Source: MSExchangeOMA
Event Category: (1000)
Event ID: 1503
Date: 06/07/2006
Time: 23:36:57
User: N/A
Computer: servername
Description:
An unknown error occurred while processing the current request:
Message: The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider
Stack trace:
at Microsoft.Exchange.OMA.ExchangeDataProvider.OmaWebRequest.GetRequestStream()
at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices.GetSpecialFolders()
at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices..ctor(UserInfo user)

Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack trace:
at System.Reflection.RuntimeConstructorInfo.InternalInvoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)

Message: Exception of type Microsoft.Exchange.OMA.DataProviderInterface.ProviderException was thrown.
EventMessage:
UserMessage: A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
Source: Microsoft.Exchange.OMA.UserInterface
Stack trace:
at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)
at System.Web.SessionState.SessionStateModule.RaiseOnStart(EventArgs e)
at System.Web.SessionState.SessionStateModule.CompleteAcquireState()
at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
at System.Web.AsyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Microsoft knowledge base article 898131 suggested that the on-screen error may have been related to multiple server identities and incorrect host headers for the OMA website; however I didn’t find that to be the case (that is to say that the resolution I found works regardless of whether or not I change the host headers to include the NetBIOS name of my server, which is accessed externally using a totally different name). Microsoft knowledge base article 817379 was much more useful as it seems the issue is related to the fact that my server is only accessible using an SSL connection, forms-based authentication is enabled and I don’t have a dedicated front-end server. Following Microsoft’s advice to create a secondary virtual directory for Exchange that does not require SSL (/exchange-oma), and then adding a registry value to point to the new virtual directory resolved the issue for me.

I still access the server using HTTPS to https://exchangeservername/oma (external HTTP connections cannot reach my Exchange server) but this fix resolves the internal operations between OMA, the OWA templates and DAV on the mailbox server.

To read more about configuring OMA, an OMA 2003 tutorial is available at MSExchange.org. It’s also possible to test OMA using the Nokia mobile browser and WAP gateway simulators (which is what I used for the screenshot shown above).

Apart from a short post announcing the arrival of Exchange Server 2003 service pack 2 (SP2), I haven’t written much on the topic. Often the first service pack for a product brings functionality that didn’t quite make it in time for the release. Second service packs are more likely to include features that have become significant in the market – for Windows XP that was security and for Exchange, that’s mobile messaging and tackling UCE – but SP2 also brings a number of other improvements:

• Probably the most significant change for small businesses (and branch office deployments) is the increased storage potential for Exchange Server 2003 standard edition (now limited to 75GB, rather than the 16GB limit that existed previously). Of course, enterprise edition is still “unlimited”, but for those organisations running the standard edition, 16GB might only have been a few mailboxes!
• SP2 also enhances some of the management tools – particularly with a “panic button” to prevent public folder replication (a lengthy process that was previously difficult to stop once started).
• The Exchange Server 2003 intelligent message filter (IMF) – previously a separate download, it is now included in SP2. SP2 also supports SenderID – the proposal from Microsoft and others for validation that a message did actually originate from the organisation from which it claims to be.
• Finally, on the mobile messaging front, SP2 adds direct push support, device and message security, and support for device policy provisioning.

I’m planning a separate post on tacking unsolicited commercial e-mail (UCE – commonly known as spam) using the IMF so here I’ll concentrate on the mobile messaging improvements in SP2.

At last week’s IT Forum ’05 highlights (part 2) event, Ewan Dalton (one of the Microsoft Exchange team members) demonstrated some of the new mobile technologies. I was quite impressed – up until now, Windows Mobile users only really had POP/IMAP/HTTP e-mail whilst Blackberry users were bragging about their instant delivery (“push” e-mail). Actually, none of it is instant – there’s actually a polling mechanism in place and push does involve some pulling (as does it for Blackberry), but even so it’s pretty good.

The ActiveSync direct push process works as follows:

1. The mobile device sends a request to the Exchange Server front end server.
2. The server holds the request pending until the heartbeat interval expires (default 15 minutes) – effectively keeping a connection open, but with no traffic).
3. If no mail arrives before the heartbeat interval expires, the device sends another request but if new mail arrives in the meantime, the server notifies the device that changes have occurred in the mailbox.
4. Upon receiving a response from the server, the device immediately issues a synchronisation request to pull e-mail. Once synchronised, the process restarts at step 1.

In practice, I’m told that mail will probably be on the mobile device before it would arrive in Outlook in cached mode.

When asked about the cost of keeping the device connection open using the heartbeats, Microsoft replied that their testing indicates an extra 1MB of traffic per month; however, because the new ActiveSync is using GZIP compression, traffic levels have dropped by 50%, so it could actually result in lower bandwidth charges.

Another improvement with SP2 is the new mobile device policy functionality, allowing organisations to enforce device security requirements, e.g. password length, complexity, inactivity timeout, refresh interval and also the ability to wipe the device after a specified number of attempts (the handset would still be usable, but it would no longer contain any data). All of this can optionally be overridden with exceptions (e.g. for older devices which do not support the policy). Certificates are also supported in place of username and password/PIN combinations; however these need to be provisioned over a corporate network (not the mobile operator’s network).

Microsoft also demonstrated the ability to wipe a device when chosen from a list of devices associated with a user, sending a dummy contact which effectively applies a new policy and wipes the device. Because this is a notification, not an SMS message, it is effective immediately.

Using a traditional middleware approach (e.g. BlackBerry Server for Microsoft Exchange), device support is limited and the network operator has to be involved in mail delivery:

With Windows Mobile and Exchange Server 2003 SP2, there is no middleware and devices connect via HTTPS straight into the corporate infrastructure:

In practice, this looks something like the following:

Microsoft recommend using a domain-joined ISA Server with one NIC in the corporate network and another in a DMZ (i.e. behind another firewall) to pre-authenticate user requests. In this manner the front-end server no longer has to be located inside the DMZ and there are less firewall ports to be opened for Active Directory connectivity, decreasing the attack surface for the corporate network.

For scalability, Microsoft quote their own metrics from internal deployment.

• Worldwide, the software giant has 106,000 user mailboxes with four front end hubs. About 25% of these mailboxes use mobile devices – and two thirds of these are smart phones with the remaining third running Pocket PC Phone Edition.
• In Redmond alone, there are 60,000 mailboxes with all mobile services running on three Exchange Server 2003 SP2 servers (dual CPU and 2GB RAM). This breaks down to 20,000 simultaneous HTTP sessions per server (although they do concede that a more realistic benchmark would be 10-15,000 sessions). The same servers are used for Outlook Web Access (OWA) and Outlook RPC over HTTP.

• ActiveSync uses a single HTTPS connection.
• OWA uses 3 or 4 connections.
• RPC over HTTP typically uses between 10 and 12 connections.

In order to use the new Exchange Server mobile functionality there are some device and server requirements:

• The device must be running Windows Mobile 5.0 (older devices will work, but will not benefit from the SP2 improvements). Also, the messaging security feature pack (MSFP) is required for much of the new functionality – this is part of the adoption kit ROM update 2 (AKU2), currently being tested by network operators and expected to ship during March/April 2006. Device manufacturers can use an image update to refresh older Windows Mobile 5.0 devices that are already on the market.
• The front end server needs to have Exchange Server 2003 SP2 installed. In addition, Microsoft recommend that the IIS and firewall HTTPS timeout is increased for the ActiveSync virtual directory (to between 15 and 30 minutes).

Other OEMs are licensing Exchange technologies so the new features will be supported on a broader range of devices (Palm, Nokia, Motorola, etc.). Another option is the use of third-party software, like the Java-based DataViz RoadSync.

Unusually feature-packed (for a service pack), SP2 is expected to be the last major functional improvement for Exchange Server 2003 but it brings a whole host of valuable functionality. Watch this space for more about the next version of Exchange Server (codenamed Exchange 12).