Outlook Mobile Access and Exchange 2003

Article
07/25/2014

Microsoft Exchange Server 2003 provides a mobile browse solution, named Outlook Mobile Access. Outlook Mobile Access generates HTML, xHTML, and cHTML markup for display on mobile devices on the approved device list. Wireless Markup Language (WML) is also generated, but Microsoft has not tested WML for all device and gateway configurations. Therefore, WML is not supported. However, most devices work with Outlook Mobile Access.

Outlook Mobile Access is installed by default but disabled globally (although all users are enabled for mobile access). The user experience is similar to Microsoft Outlook Web Access. Connection with Outlook Mobile Access is through a URL, typically, https://server-name/oma. Unlike Microsoft Outlook Web Access, however, you cannot specify a specific user account in the URL. This is because Outlook Mobile Access adds a unique identifier to the URL as part of session state management.

Outlook Mobile Access supports the following messaging and collaboration features:

**E-mail **Read, Reply, Forward, Delete, Flag, Compose messages, navigate multiple folders, and look up sender or other recipients.
Calendar Accept, Decline, Tentative meeting requests, navigate through date picker control, and compose and edit appointments with attendees support.
Contacts View, Create, Edit personal contacts, search personal and global address list (GAL) contacts, save GAL contacts to personal contacts, and e-mail and call contacts.
Tasks View, Create, and Edit tasks.

Outlook Mobile Access Dependencies

Outlook Mobile Access has several dependencies, including .NET Framework, IIS, Session State management, and a modified URL Session ID. The Outlook Mobile Access program is built on the .NET framework. By default, Windows Server 2003 installs the .NET framework, whereas Windows 2000 Server requires the addition of the framework. This is handled by Exchange setup if the framework is not installed. Outlook Mobile Access also requires Basic as the Authentication method, OMA.ASPX as the default document, and the Outlook Mobile Access virtual directory executable path configured as

aspx,C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll,1,GET,HEAD,POST,DEBUG.

Outlook Mobile Access and .NET

Outlook Mobile Access is the only Exchange 2003 component that uses the .NET Framework. It is impossible to understand the foundation of Outlook Mobile Access without a cursory understanding of the .NET Framework. Outlook Mobile Access enables you to view your mailbox with a mobile browser. This section provides a basic explanation of the .NET Framework and ASP.NET, as they apply to Exchange 2003 Outlook Mobile Access and to mobility as a whole.

.NET Framework

.NET Framework has two main components: the common language runtime and the .NET Framework class library. The common language runtime is the foundation of .NET Framework. The runtime is an agent that manages code at run time. It provides core services, such as memory management and thread management, while it enforces strict type safety and other forms of code accuracy that assist with security and robustness issues. In fact, the concept of code management is a fundamental principle of the runtime. Code that targets the runtime is named managed code, while code that does not target the runtime is named unmanaged code.

The class library is a comprehensive, object-oriented collection of reusable types that are used to develop applications ranging from conventional command-line or graphical user interface (GUI) applications to applications based on the latest innovations provided by ASP.NET Web Forms and XML Web services.

ASP.NET

ASP.NET enables developers to use the .NET Framework to target Web-based applications. ASP.NET is more than a runtime host. ASP.NET is a complete architecture for developing Web sites and Internet-distributed objects using managed code. Both Web Forms and XML Web services use IIS and ASP.NET as the publishing mechanism for applications. Both have a collection of supporting classes in the .NET Framework.

The .NET Framework also provides a collection of classes and tools to assist in development of mobile controls. Mobile controls are used to develop applications for handheld devices and are device-specific. Mobile controls reduce development time and make sure that the correct markup is returned to the client device.

ASP.NET Framework 1.1 provides an abstraction of a user interface with objects representing the fundamental components of a visual display, such as text labels and input boxes. It is the runtime's task to convert this abstract representation to device-specific markup.

ASP.NET provides mobile Web Form controls that represent individual components of the user interface. These components are used to define a user interface in a Web page. ASP.NET delivers the content in the markup language appropriate to the requesting device.

There are two major client protocols that are used by browsers to date: cHTML and xHTML. ASP.NET automatically renders the correct elements for the specified wireless device.

Session Management

As mentioned at the beginning of this section, Outlook Mobile Access requires Session State management to operate correctly. The HTTP protocol is effectively stateless, as it provides no mechanism for identifying or maintaining sessions between a Web server and a client. This problem is addressed in ASP by providing a Session object that enables you to uniquely identify a user and store information specific to his or her interactions with a Web server.

ASP.NET offers an updated and improved version of the Session object. This object enables you to perform the following tasks:

Identify a user through a unique session ID
Store information specific to a user's session
Manage a session lifetime through event handler methods
Release session data after a specified timeout

Outlook Mobile Access uses ASP.NET default, in-process session state handling, and the modified URL method of session management.

Modified URL Session ID

A modified URL is a URL that contains a session ID. The session ID takes the form of the standard URL with a unique identifier added between the application and the Web page (such as https://server/oma/(a5db038hclb4b1g5ukhrsu55)/oma.aspx). When the Web server receives the request, it parses the session ID from the modified URL. The runtime then uses the session ID just as it would use a session ID obtained from a cookie. If the client does not support cookies, runtime does not automatically use modified URLs.

Note

There is a potential problem with mobile devices that do not support modified URLs for session ID. Some wireless browsers experience difficulties dealing with relative URLs after they have been redirected to a modified URL. The problem occurs because they support URL lengths much shorter than those supported by desktop browsers. An application in a deeply nested hierarchy might require URLs with lengths that exceed what is supported by some browsers.

ASP.NET Device Updates

Mobile device updates are incorporated into the .NET Framework Device Updates. After all, Outlook Mobile Access derives from these base classes. The Device Updates (DUs) are tentatively scheduled for quarterly updates. Any modifications required to provide proper rendering on a specific device are included in the web.config in the root of the browse directory. The web.config is updated as part of the device updates. Any customization will be overwritten.

Administrators and developers are discouraged from modifying web.config settings for a device Microsoft has not tested. In many cases, there will be no interoperability problems between the mobile device and Exchange. However, there is no support for such modifications, and the end result may remove the ability to debug Outlook Mobile Access.

Outlook Mobile Access Architecture

For data access and processing, CDOEX, DAV, Microsoft Outlook Web Access Templates and system.directory services are used inside the Outlook Mobile Access process. Active Directory, the registry, the IIS metabase, and the web.config file are read to obtain configuration settings.

Outlook Mobile Access must receive the user credentials in clear text through Basic authentication. Outlook Mobile Access does not support or work with Windows Integrated Authentication even if the device/browser supports it.

ASP.NET works in conjunction with IIS, the .NET Framework, and the underlying security services provided by the operating system, to provide a range of authentication and authorization mechanisms.

Outlook Mobile Access and Microsoft Outlook Web Access Templates

Web Distributed Authoring and Versioning (WebDAV) provides raw access to most data hosted on Exchange. Some common tasks, such as accepting a meeting request, creating a meeting request, and resolving an ambiguous e-mail recipient, are difficult to implement using WebDAV. Generally, Microsoft Outlook Web Access responds to a user request with an HTML page. The runtime does not automatically use modified URLs if the client does not support cookies.

The format of the response page is determined by templates. Outlook Mobile Access leverages Microsoft Outlook Web Access functionality. Outlook Mobile Access uses custom templates to control the information and the format of the information returned from the Microsoft Outlook Web Access functions. These templates return data in a format that is similar to a WebDAV response. This provides unification of the data format returned by functions using Microsoft Outlook Web Access for data retrieval and those using WebDAV.

WebDAV is the foundation for most operations in the Outlook Mobile Access Exchange Data Provider. The WebDAV protocol, designed for general data access, extends HTTP to HTTP 1.1. This enables data storage on the server and retrieval by the HTTP client. The fundamental operations are:

Navigate folder
Enumerate folder items
Search folder for items
Get item details
Modify attributes of message, contact, and task
Submit composed message

The Exchange Data Provider classes provide the interface with Exchange Server for those functions not obtained from Microsoft Outlook Web Access.

Outlook Mobile Access Data Sources

Outlook Mobile Access retrieves configuration and other data from a variety of sources, including Active Directory, the IIS metabase, the Windows registry and Web.config. Retrieving data for a user through WebDAV and Microsoft Outlook Web Access templates requires Outlook Mobile Access to construct the WebDAV/OWA URL as follows: https://<servername>/<virtualdirectoryname>/<mailbox>. In this case, the value for <servername> is retrieved from the User object of the user who is logged on. In cross forest topologies, this information is read from the disabled user account in the resource forest. The <virutaldirectoryname> is retrieved from the ExchangeVDir registry.

Determining the correct <mailbox> is more complex. The only way to determine a user mailbox name is to find the user's SMTP address for the mailbox. You can find this value from the User object. However, there is a problem with this method. The attribute might contain more than one SMTP address for the user.

The correct SMTP address is determined by the SMTP Domain of the mailbox in question. The SMTP Domain is configured through Exchange System Manager per virtual directory for Microsoft Outlook Web Access, Outlook Mobile Access and Exchange ActiveSync. This facilitates hosting as the same front-end server can have multiple Outlook Mobile Access virtual directories and each virtual directory represents a unique SMTP Domain. This setting is stored in the directory with one SMTP Domain per virtual directory per Exchange server.

Outlook Mobile Access, in addition to Exchange ActiveSync and Microsoft Outlook Web Access, do not have read access to this attribute. Access rights are restrictive because it is an administrator setting. The DS2MB process does have read access. The mailbox resolution process is as follows:

Exchange System Manager writes an SMTP Domain value to Active Directory for a certain virtual directory on a certain server.
DS2MB on that server picks the setting up and replicates it to the IIS metabase on the computer.
Outlook Mobile Access reads the SMTP Domain for the virtual directory in which they are running.
Outlook Mobile Access looks up the SMTP addresses on the Active Directory User object (in cross-forest topologies, this information is read from the disabled user account in the Exchange resource forest).
Outlook Mobile Access picks out the SMTP address using the SMTP Domain in the list.
The SMTP address is on the format <mailboxname>@<SMTP Domain>, Outlook Mobile Access extracts the <mailboxname>.

The <servername>, <virtualDirectoryName>, and <mailbox> values are then linked together to provide the DAV/OWA URL that the back-end server requires.

Outlook Mobile Access Directory Settings

Outlook Mobile Access reads configuration settings from Active Directory whenever a new session is created (and only when a new session is created). The following two tables describe the forest-wide and user-specific Outlook Mobile Access configuration settings in Active Directory.

Forest-wide Outlook Mobile Access directory settings

Directory Setting	Description
Outlook Mobile Access	Outlook Mobile Access root node under Exchange Active Directory settings. Contains Outlook Mobile Access-global attributes and containers for more Outlook Mobile Access settings.
msExchOmaAdminWirelessEnable	Admin control for available mobile services: Bit 0:OMA Push Bit 1:OMA Browse Bit 2:OMA Sync Bit 30: Browse-with-untested-devices Bit 31: Push-via-user-specified-SMTP-address 0 = Enabled. 1 = Disabled. The default value set by the Exchange Setup program is disabled.
msExchOmaExtendedProperties	Reserved for future feature-expansion (without requiring Active Directory schema changes).

Outlook Mobile Access

Outlook Mobile Access root node under Exchange Active Directory settings. Contains Outlook Mobile Access-global attributes and containers for more Outlook Mobile Access settings.

msExchOmaAdminWirelessEnable

Admin control for available mobile services:

Bit 0:OMA Push

Bit 1:OMA Browse

Bit 2:OMA Sync

Bit 30: Browse-with-untested-devices

Bit 31: Push-via-user-specified-SMTP-address

0 = Enabled. 1 = Disabled.

The default value set by the Exchange Setup program is disabled.

msExchOmaExtendedProperties

Reserved for future feature-expansion (without requiring Active Directory schema changes).

Per-user Outlook Mobile Access directory settings

Directory Setting	Description
msExchOmaAdminExtendedSettings	Space for admin controlled settings for a user. Example: Allow/disallow access to features such as calendar or contacts in Outlook Mobile Access.
msExchOmaExtendedProperties	Reserved for future feature-expansion (without requiring Active Directory schema changes).

The attributes on the User object inherit three access control lists (ACLs) from the User object container: Domain Admins, Local System on Domain Controllers, and Account Operators. Each of these security principals have full read/write permissions to the user's settings. Additionally, the two attributes listed in Table 9.8 are part of the Public-Information property set, which gives Authenticated Users read access. The attributes in the Outlook Mobile Access Configuration Container are inherited from the Organization Node, and then read access for Authenticated Users is added.

Because these directory settings are only read at the beginning of a new session, changing the settings does not affect sessions in progress. For example, disabling a user for Outlook Mobile Access does not immediately block that user from an ongoing session. A user won't notice that access is disabled until the next time that user tries to establish a new Outlook Mobile Access session.

Outlook Mobile Access and DS2MB

DS2MB in Exchange 2003 affects all Exchange Web-based applications. These include Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync. Outlook Mobile Access has some configuration values that depend on the directory, but deleting the Outlook Mobile Access virtual directory is a common method of troubleshooting directory to metabase replication.

IIS obtains the correct configuration from the local metabase. IIS related information is stored in Active Directory and replicated in one direction from the directory to the metabase by the DS2MB process. DS2MB runs as part of System Attendant on each computer running Exchange 2000 or later. DS2MB receives notifications of changes in the directory and directs DS2MB to do the work.

If you discover that the local metabase is not synchronized with the directory, you can force a manual update of the directory by manipulating the metabase key below.

LM\DS2MB\HighWaterMarks\{056BE186-E73F-4EBD-A92D-2D985BC97C63}\61472

Changing the data for this value to 0 (zero) or deleting the key and then restarting System Attendant causes a full replication of the directory information to the metabase. When System Attendant starts, the key is added to the metabase with the default value. The metabase can be manipulated through a variety of tools. If Exchange 2003 is running on Windows Server 2003, the built-in IISCNFG tool can be used. If Exchange is running on Windows 2000, MetaEdit 2.2 or later can be used.

Outlook Mobile Access and the Windows Registry

Outlook Mobile Access uses five registry keys. One is used for performance counters, and four others are used for configuration. One key is shared with Exchange ActiveSync, and three others are shared with Outlook Web Access. These keys can be found under HKLM\SYSTEM\CurrentControlSet\Services. The registry keys are described in the following table.

Important Outlook Mobile Access registry values

Key	Value	Description
MasSync\Parameters\ExchangeVDir	/Exchange or other string that starts with /	Specifies what virtual directory ActiveSync and Outlook Mobile Access must use to access Outlook Web Access templates and WebDAV on the Exchange back-end servers where user mailboxes are located. If this key does not exist, or is null, the default value /Exchange is used. Otherwise, this key contains the name of the virtual directory, including the forward slash (/).
MSExchangeWEB\OWA\UseRegionalCharset	1 or anything	If this key is set to '1', then Outlook Web Access and Outlook Mobile Access use regional charsets when sending e-mail. If it doesn't exist or is set to anything else, Outlook Web Access and Outlook Mobile Access use UTF-8 for sending e-mail. The regional charset used is determined based on the client language the user specifies.
MSExchangeWEB\OWA\UseISO8859_15	1 or anything	When set to '1', the character set iso-8859-15 is used wherever the iso-8859-1 would have been used.
MSExchangeWEB\OWA\UseGB18030	1 or anything	When set to '1', the character set GB18030 is used wherever the GB2312 would have been used.
MSExchangeOMA\Performance	N/A	Used to publish Outlook Mobile Access performance objects and counters.

Outlook Mobile Access and Web.Config

Under the <browserCaps> section of the Web.config file are Outlook Mobile Access settings for various mobile browsers and versions of Internet Explorer. Do not adjust these settings, as they are included in .NET Framework Device Updates.

There are some user configurable settings in web.config file, which are described in the following table.

Web.config settings for Outlook Mobile Access

Section	Setting	Description
<appSettings>	<add key="CredentialsTimeout" value="60"></add>	Defines the number of minutes Outlook Mobile Access keeps Kerberos tickets for DAV and Outlook Web Access template access cached.
	<add key="DefaultConnectionLimit" value="500"></add>	Defines the maximum number of simultaneous connections Outlook Mobile Access can open to an individual back-end server.
	<add key="MaxServicePointIdleTime" value="60000"></add>	Tells Outlook Mobile Access how many milliseconds to wait for replies from the back-end server before timing out.
	<add key="UnsupportedMessage" value="https://<server>/OMADevices"></add>	When this message is defined, additional text shows up on the unsupported warning and unsupported error pages. By default this key is null.
<system.web>	<sessionState mode="InProc" cookieless="true" timeout="20" />	Specifies the session state configuration that is used by Outlook Mobile Access. The timeout value indicated for how many minutes the session state is kept in memory after the last request arrives for the session.
	<mobileControls SessionStateHistorySize="8">	Specifies how many previous pages the session state must track (enabling the user to set the device back button and still have the links on pages work).
	<globalization requestEncoding="utf-8" responseEncoding="utf-8" />	Defines the default characters set Outlook Mobile Access uses to send HTTP responses and interpret incoming requests without a character set specified.
<browserCAPs>	supportsBackNavWithExpiresHeader	Determines whether Outlook Mobile Access sends the Expires header back on all requests with a value of 10/08/2000 10:28. The purpose of sending back a date and time in the past is to force expiration of content.
	preferredResponseCharset	Sets Response.Charset to this value for all requests.
	preferredResponseCodePage	Sets Response.ContentEncoding to the specified integer. Set at the same time as Response.Charset.
	preferredRequestCodePage	Sets Request.ContentEncoding to the specified integer. Should be set at the same time as Response.Charset.
	supportsOpenwaveUniversalLocalSrc	Tells Outlook Mobile Access to insert access keys before links.
	defaultTextboxMaxlength	Sets the MaxLength of strings permitted in TextBox controls. The P800, for example, will default to 64 without this set.

Outlook Mobile Access Client Requests

When an Outlook Mobile Access client issues a Web request, the following sequence of authentication and authorization events occurs:

The HTTP(S) Web request is received from the network. SSL can be used to verify the server identity. SSL also provides a security channel to help protect sensitive data passed between client and server.
IIS authenticates the caller by using Basic authentication. IIS creates a Windows access token for the authenticated user.
IIS authorizes the caller to access the requested resource. NTFS file system permissions defined by access control lists (ACLs) attached to the requested resource are used to authorize access.
IIS passes the authenticated caller's Windows Server access token to ASP.NET.

Outlook Mobile Access Security Architecture

The underlying security architecture of Outlook Mobile Access depends on whether Exchange 2003 is running on Windows Server 2003 or Windows 2000 Server. On Windows Server 2003, Outlook Mobile Access runs in its own process in a dedicated program pool, ExchangeMobileBrowseApplicationPool. Outlook Mobile Access runs as the Network Service account in an ASP.NET worker process (W3WP.EXE). On a Windows 2000-based computer, Outlook Mobile Access runs in a process together with other ASP.Net applications on the same computer. Outlook Mobile Access runs as the ASPNET account in an ASP.NET worker process (ASPNET_WP.EXE).

The ASP.NET ISAPI extension, ASPNET_ISAPI.DLL, runs in a process under Inetinfo.exe. This is controlled by the InProcessIsapiApps Metabase entry. ASPNET_ISAPI.DLL is responsible for routing requests to the ASP.NET worker process. ASP.NET programs then run in the ASP.NET worker process, in which program domains provide isolation boundaries. IIS 6.0 isolates ASP.NET programs by configuring program pools, in which each pool has its own application instance (Outlook Mobile Access is placed in the ExchangeMobileBrowseApplication pool).