Tài liệu Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) docx

Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 1





Module 3:
Troubleshooting
Microsoft® Outlook®
Mobile Access (OMA)
Contents
Introduction ............................................................................................................. 3

General Overview.................................................................................................... 5

OMA, a .NET Application ...................................................................................... 8

ASP.NET Security Architecture............................................................................ 13

OMA Dependencies .............................................................................................. 19

OMA Capabilities.................................................................................................. 22

User preferences.................................................................................................... 36

OMA, behind the GUI........................................................................................... 42

Supported Devices................................................................................................. 48

Using http(s)://fqdn/oma ....................................................................................... 49

Counters ................................................................................................................ 52

Known Issues ........................................................................................................ 56

Troubleshooting .................................................................................................... 62

Troubleshooting Diagram...................................................................................... 86

Tools...................................................................................................................... 88

Lab: Restoring OMA Functionality....................................................................... 92


2 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2003 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, ActiveSync®, ActiveX®, Microsoft® Exchange
2000, Microsoft® Exchange Server 2003, Microsoft® Exchange 5.5, Microsoft® Internet
Explorer, Microsoft® Internet Information Services, Microsoft® Mobile Information Server 2002,
Microsoft® .NET, Microsoft® Notepad, Microsoft® Outlook® Mobile Access, Microsoft®
Outlook® Web Access, Microsoft® SQL Server™, Microsoft® Windows®, Microsoft®
Windows® 2000, Microsoft® Windows® 2003 are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.

Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 3

Introduction


Microsoft® Exchange Server 2003 provides a mobile browse solution that is
ready worldwide; including the Asian-Pacific region. Exchange 2003 browse
generates HTML, xHTML, and cHTML markup. This has been tested and is
supported for a subset of HTML, xHTML, and cHTML devices on the
approved device list. WML is generated but is not tested for all device/gateway
configurations and as such is not supported, though most devices will work as
expected.

Mobile Access is installed by default but disabled in the Mobile Services
Global Setting while all users are enabled for mobile access. The user
experience is very similar to Microsoft® Outlook® Web Access (OWA).
Access to Microsoft® Outlook® Mobile Access (OMA) is via a URL;
http://server-name/oma
. Unlike OWA, you can not specify the user account in
the URL as OMA adds a unique identifier to the URL as part of session state
management.

I
I
S
S
A
A
/
/


F
F
i
i
r
r
e
e

w
w
a
a
l
l


AD Domain
F
F
E
E




Internet / Wireless
Cloud
B
B
E
E


FE/BE is not required; Exchange 2003 is required.
4 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

Demonstration using Openwave Emulator

Start the Openwave emulator.
Enter />.
Login using concsi\administrator and P@ssword.
Click “ OK” to continue when notified that the device is unsupported.
Click “About” to show students the valuable information displayed in
the about box.
Microsoft®.NET Framework build.
Server build
Server name
User name
Etc
Click back and then click “Preferences .
Step through each of the preferences to show the student user
preferences.
Remind the student that size of a real device display may vary from the
emulator, but the emulator is a good tool to get a feel for what the
mobile user is experiencing.

Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 5

General Overview


OMA supports the following messaging and collaboration features.

E-mail: Read, Reply, Forward, Delete, Flag, Compose. Navigate multiple
folders. Lookup sender or other recipients

Calendar: Accept, Decline, Tentative meeting requests. Navigate via date
picker control. Compose/Edit appointments w/attendees support


Contacts: View, Create, Edit personal contacts. Search personal and GAL
contacts. Save global address list (GAL) contacts to personal contacts. E-
mail and Call contacts

Tasks: View, Create, Edit tasks
In a mixed Exchange environment, you must use Exchange 2003 for both the
front-end and back-end servers to gain access to mailboxes through OMA.
Mailboxes on Microsoft® Exchange 5.5 or Microsoft® Exchange 2000 require
Microsoft® Mobile Information Server (MIS) 2002.
Features
Limitations
6 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

Integrating Exchange 2003 with MIS 2002

MIS can be installed in an ‘ActiveSync-only’ configuration. When installed in
this manner, MIS does not require an Active Directory schema change or any
complicated auxiliary forest topologies.
The recommended path for customers that want mobility on Exchange 2000
and want to ensure they’ll have a good migration path to Exchange 2003 is to
install MIS in the ‘ActiveSync only’ configuration for Exchange 2000. Then the
same devices, PPC Phone and Smartphone, will work with Exchange 2003
when they migrate. Then they do not have to be concerned with a complex
Active Directory schema change and auxiliary forest scenarios pertinent to
MIS. Of course, this means they won’t get the browse and push features of
MIS. But past experience shows ActiveSync is usually the feature driving MIS
deployments.
In summary:


MIS has not been tested against Exchange 2003 mailboxes. Using MIS
mobile browse or MIS ActiveSync® against Exchange 2003 mailboxes is
not a supported scenario.

Coexistence: MIS (browse, push and sync) used against Exchange 2000
mailboxes can co-exist in the same environment as Exchange 2003 OMA
and EAS (Exchange ActiveSync) used against Exchange 2003 mailboxes.
Exchange 2003 does not reuse the Active Directory attributes used by MIS,
and so they don’t conflict. For exact details about what Active Directory
attributes are used by Exchange 2003 Mobility, see the documentation that
will be available by launch. If you need information faster, SandraMa
(EAS), AlexI (OMA) and PLimont (AUTD) are the PM contacts.


If a customer desires to use MIS for some users and Exchange 2003
mobility for others, then using separate name spaces for each is best.
MIS/E2k users URL = mis.corp.com
Ti users URL = oma.corp.com
Exchange 2003 Mobile Browse is the only Exchange component that uses the
.NET Framework. The specifics of the other components, sync and Up To
Date, which complete the Exchange 2003 Mobile experience, will be covered in
detail in the specific component modules.
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 7

8 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

OMA, a .NET Application


It is impossible to understand the foundation of OMA without a cursory

understanding of the .NET Framework. OMA gives you the ability 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 OMA
and Mobility as a whole.
The .NET Framework is a new development platform that simplifies
application development in the highly distributed environment of the Internet.
The .NET Framework is designed to fulfill the following objectives:

Provide a consistent object-oriented programming environment whether
object code is stored and executed locally, executed locally but Internet-
distributed, or executed remotely.

Provide a code-execution environment that minimizes software deployment
and versioning conflicts.

Provide a code-execution environment that guarantees safe execution of
code, including code created by an unknown or semi-trusted third party.

Provide a code-execution environment that eliminates the performance
problems of scripted or interpreted environments.

Make the developer experience consistent across widely varying types of
applications, such as Microsoft® Windows®-based applications and Web-
based applications.

Build all communication on industry standards to ensure that code based on
the .NET Framework can integrate with any other code.

The .NET Framework has two main components: the common language
runtime and the .NET Framework class library.

.NET Framework
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 9

The common language runtime is the foundation of the .NET Framework. You
can think of the runtime as an agent that manages code at execution time,
providing core services such as memory management, thread management
while enforcing strict type safety and other forms of code accuracy that ensure
security and robustness. In fact, the concept of code management is a
fundamental principle of the runtime. Code that targets the runtime is known as
managed code, while code that does not target the runtime is known as
unmanaged code.
The class library, the other main component of the .NET Framework, is a
comprehensive, object-oriented collection of reusable types that are used to
develop applications ranging from traditional command-line or graphical user
interface (GUI) applications to applications based on the latest innovations
provided by ASP.NET; Web Forms and Extensible Markup Language (XML)
Web services.
Microsoft® Internet Explorer is an example of an unmanaged application that
hosts the runtime; in the form of a MIME type extension. Using Internet
Explorer to host the runtime enables you to embed managed components or
Windows Forms controls in HTML documents. Hosting the runtime in this
way makes managed mobile code, similar to ActiveX® controls possible, but
with significant improvements that only managed code can offer, such as semi-
trusted execution and secure isolated file storage.
The CLR manages memory, thread execution, code execution, code safety
verification, compilation, and other system services. These features are intrinsic
to all managed code.
With regards to security, managed components are awarded varying degrees of
trust, depending on a number of factors that include their origin; the Internet,
enterprise network, or local computer. Thus, a managed component might or

might not be able to perform file-access operations, registry-access operations,
or other sensitive functions, even if it is being used in the same active
application.
The runtime enforces code access security. Users can trust that an executable
embedded in a Web page can play an animation on screen or sing a song, but
cannot access their personal data, file system, or network. The security features
of the runtime enable legitimate Internet-deployed software to have
exceptionally rich features.
In addition, the managed environment runtime eliminates many common
software issues. The runtime automatically handles object layout and manages
references to objects, releasing them when they are no longer being used. This
automatic memory management, garbage collection, resolves the two most
common application errors; memory leaks (pointer released before memory
free) and invalid memory references (pointer).
The runtime is designed to enhance performance. Although the common
language runtime provides many standard runtime services, managed code is
never interpreted. A feature called just-in-time (JIT) compiling enables all
managed code to run in the native machine language of the system on which it
is executing.
Meanwhile, the memory manager removes the possibilities of fragmented
memory and increases memory locality-of-reference to further increase
performance. The runtime compiles the code the first time the code is called
and reuses the complied version thereafter.
Common Language
Runtime
(CLR)
10 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)


The .NET Framework class library is a collection of reusable object oriented

types that tightly integrate with the common language runtime. Developers use
these base types to develop their own types; inheritance. This reduces the time
associated with learning new features of the .NET Framework. In addition to
these common tasks, the class library includes types that support a variety of
specialized development scenarios. The .NET Framework can be used to
develop console applications, scripted or hosted applications, Windows GUI
applications (Windows Forms), XML Web services, Windows services, and last
but most important to us, ASP.NET applications.
.NET Framework Class
Librar
y
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 11

ASP.NET

ASP.NET is the component that enables developers to use the .NET Framework
to target Web-based applications. ASP.NET is more than a runtime host; it is a
complete architecture for developing Web sites and Internet-distributed objects
using managed code. Both Web Forms and XML Web services use Microsoft®
Internet Information Services (IIS) and ASP.NET as the publishing mechanism
for applications. Both have a collection of supporting classes in the .NET
Framework.
XML Web services, an important evolution in Web-based technology, are
distributed, server-side application components similar to common Web sites.
Unlike Web-based applications, XML Web service components have no user
interface (UI) and are not targeted for browsers such as Internet Explorer. XML
Web services consist of reusable software components designed to be
consumed by other applications; Web-based applications or other XML Web
services. XML Web services technology is rapidly moving application
development and deployment into the highly distributed environment of the

Internet.
If you have used earlier versions of ASP technology, you will immediately
notice the improvements that ASP.NET and Web Forms offers. A developer
can produce Web Forms pages in any language that supports the .NET
Framework. The code no longer needs to share the same file with your HTTP
text; code behind (although it can continue to do so if you prefer). Web Forms
pages execute in native machine language like any other managed application.
ASP.NET pages are faster, more functional, and easier to develop than
unmanaged ASP pages because they interact with the runtime unlike ASP pages
which are interpreted.

12 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

ASP.NET Framework 1.1 Mobile Controls

The .NET Framework also provides a collection of classes and tools to aid in
development of Mobile Controls. Mobile controls are used to develop
applications for handheld devices and are device specific. This reduces
development time and ensures 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; text
labels, input boxes, etc. It's the runtime's responsibility to take this abstract
representation and turn it into 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 within a web page. ASP.NET will deliver the content in the markup
language appropriate for the requesting device.
There are two major client protocols used by browsers to date; cHTML and
xHTML. ASP.NET automatically renders the correct elements for the given

supported wireless device.
Mobile Device Updates are incorporated into the .NET Framework Device
Updates. After all, OMA derives from these base classes. The Device Updates
are tentatively scheduled for quarterly updates. Any modifications required to
provide proper rendering on a specific device is 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 the 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 our ability to debug OMA.
.NET Framework Device
Updates
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 13

ASP.NET Security Architecture



Overview of OMA Security Architecture




OMA runs in its own process in a dedicated application pool:
ExchangeMobileBrowseApplicationPool. OMA runs as the ‘Network Service’
account in a w3wp.exe process
OMA runs in a process together with other ASP.Net applications on the same
machine. OMA runs as the ‘aspnet’ account in an aspnet_wp.exe process.

Microsoft® Windows
®
2003
Microsoft® Windows
®
2000
Exchange Server
IIS process
User
OMA Process
CDOEX – DAV – OWA Templates
ASP.Net Session
System.directory services
AD
Mailbox
Server
Basic Auth
-
IIS Metabase
Web.config
Registry
Basic
credential
handed over
Authenticationn
Global OMA enabled
User OMA enabled
Kerberos, DAV/OWA
User Credentials
NO SSL

14 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

CDOEX, World Wide Web Document Authoring and Versioning (DAV),
OWA Templates and system.directory services are used inside the OMA
process to reach external sources.
Active Directory, the registry, the IIS metabase and the web.config file are read
to obtain configuration settings.
OMA has to receive the user credentials in clear text through Basic
authentication. OMA DOES NOT 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. These are summarized
in Figure 1.1.


Figure 1.1. ASP.NET security services
When an OMA client issues a Web request, the following sequence of
authentication and authorization events occurs:
1. The HTTP(S) Web request is received from the network.
a. SSL can be used to ensure the server identity. SSL also provides a secure
channel to protect sensitive data passed between client and server.
2. IIS authenticates the caller by using Basic authentication. IIS creates a
Windows access token for the authenticated user.
3. IIS authorizes the caller to access the requested resource. NTFS permissions
defined by access control lists (ACLs) attached to the requested resource are
used to authorize access.
4. IIS passes the authenticated caller's Windows access token to ASP.NET

OMA Data Access and
processin
g
Details
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 15

OMA configures ASP.Net for Windows authentication; shown below in an
excerpt from the default web.config. No additional authentication occurs at
this point. ASP.NET will accept any token it receives from IIS.
<!-- AUTHENTICATION: This section sets the authentication policies of
the application. Possible modes are "Windows", "Forms", "Passport" and
"None"
<authentication mode="Windows" />

ASP.NET authorizes access to the requested resource or operation. The
UrlAuthorizationModule, a system provided HTTP module, uses
authorization rules configured in Web.config, the <authorization> element,
to ensure that the caller can access the requested file or folder.
With Windows authentication, the FileAuthorizationModule, another HTTP
module, checks that the caller has the necessary permission to access the
requested resource. The caller's access token is compared against the ACL
that protects the resource. ASP.NET does no impersonation by default and
OMA enforces by explicitly setting <identity impersonate=”false”> in the
default web.config.

As in the case of OMA, Anonymous Authentication is disabled, and IIS permits
requests only from users that it can authenticate either in its domain or in a
trusted domain. IIS uses the NTFS file system (NTFS) permissions associated
with the requested file to perform access control for static file types; e.g. .jpg,
.gif and .htm files—files that are not mapped to an Internet Server Application

Programming Interface (ISAPI) extension.

ASP.NET gatekeepers include the UrlAuthorizationModule,
FileAuthorizationModule, Principal permission demands and role checks.
FileAuthorizationModule is used for file types mapped by IIS to the ASP.NET
ISAPI extension Aspnet_isapi.dll. Automatic access checks are performed
using the authenticated user's Windows access token against the ACL attached
to the requested ASP.NET file. Impersonation is not required for file
authorization to work. The FileAuthorizationModule class only performs access
checks against the requested file, and not for files accessed by the code in the
requested page, although these are access checked by IIS. The following
paragraph provides an example.
A client requests Default.aspx and it contains an embedded user control
(Usercontrol.ascx), which in turn includes an image tag pointing to Image.gif,
the FileAuthorizationModule performs an access check for Default.aspx and
Usercontrol.ascx, because these file types are mapped by IIS to the ASP.NET
ISAPI extension. The FileAuthorizationModule does not perform a check for
Image.gif, because this is a static file handled internally by IIS. However, as
access checks for static files are performed by IIS, the authenticated user must
still be granted read permission to the file with an appropriately configured
ACL. This scenario is shown in Figure 1.2.

ASP.NET Authenticates
the Client
IIS
ASP.NET
16 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)


Figure 1.2. IIS and ASP.NET interoperability

Remember, the authenticated user requires NTFS read permissions to all of the
files involved in the scenario. The only variable is regarding which gatekeeper
is used to enforce access control. The ASP.NET process account only requires
read access to the ASP.NET registered file types.
In this scenario you can prevent access at the file authentication point. If you
configure the ACL attached to default.aspx and deny access to a particular user,
the user control or any embedded images will not get a chance to be sent to the
client by the code in default.aspx. If the user requests the images directly, IIS
performs the access checks itself.
Using Windows authentication in ASP.NET automatically attaches a
WindowsPrincipal object that represents the authenticated user to the current
Web request, using HttpContext.User.

The ASP.NET FileAuthorizationModule performs access checks for requested
file types that are mapped to the ASP.NET ISAPI. It uses the original caller's
access token and ACL attached to requested resources in order to perform
access checks.
Static files types are not mapped to an ISAPI extension, IIS performs access
checks using the caller's access token and ACL attached to the file. Windows
ACLs are configured on resources accessed by your application (files, folders,
registry keys, Active Directory objects) using the ASP.NET process identity.
Impersonation is not required because users have Windows accounts that can be
authenticated by the server.
IIS security is enabled via IIS authentication and optionally installing a
certificate to provide secure, Secure Sockets Layer (SSL), communication
between client and server. Customers should use SSL to secure
communications between client and server. Furthermore, ActiveSync requires
SSL.
Windows ACLs and

Resources
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 17


Application level configuration settings are maintained in Web.config located
in the OMA virtual root directory. When you have <authentication
mode="Windows" /> you are authorizing access to Windows user and group
accounts. User names take the form "DomainName\WindowsUserName”.
Windows authentication validates credentials using the underlying services of
the operating system. IIS performs user authentication by using the configured
IIS authentication mechanism. This is shown in Figure 1.3.

Figure 1.3. Windows authentication uses IIS to authenticate

The access token of the authenticated user is made available to the ASP.NET
application.

This allows the ASP.NET FileAuthorizationModule to perform access
checks against requested ASP.NET files using the original caller's access
token.


ASP.NET File authorization only performs access checks against file types
that are mapped to Aspnet_isapi.dll.
ASP.NET associates a WindowsPrincipal object with the current Web request.
This contains the identity of the authenticated Windows user together with a list
of roles associated with the user credentials obtained from the directory that
corresponds to the set of Windows groups to which the user belongs.

OMA does not use the highly-privileged SYSTEM account to run ASP.NET.

The ExchangeMobileBrowseApplicationPool runs as Network Service.

ASP.NET Settin
gs
Validatin
g Credentials
ASP Credentials
18 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

ASP.NET requests sent to IIS are directly routed to the ASP.NET worker
process, Aspnet_wp.exe. The ASP.NET ISAPI extension, Aspnet_isapi.dll,
runs in process under Inetinfo.exe. This is controlled by the
InProcessIsapiApps Metabase entry which should not be modified.
Aspnet_isapi.dll is responsible for routing requests to the ASP.NET worker
process. ASP.NET applications then run in the ASP.NET worker process,
where application domains provide isolation boundaries. IIS 6 isolates
ASP.NET applications by configuring application pools, where each pool
will have its own application instance. Browse is placed in the
ExchangeMobileBrowseApplication pool.

ASP.NET performs no impersonation by default and is hard coded to prevent
impersonation in web.config. As a result, OMA accesses local system
resources using the security context associated with the Aspnet_wp.exe worker
process. The security context is determined by the account used to run the
worker process; Network Service.

The Network Service must have the following minimum permissions on
HKLM\SYSTEM\CurrentControlSet\Services\Eventlog.
Query key value, Set key value, Create subkey, Enumerate subkeys , Notify and
Read.

Accessing System
Resources
Accessing the Event
Lo
g
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 19

OMA Dependencies


OMA requires the .NET Framework as the application itself is built on the
framework. Windows 2003 has the framework installed by default where
Windows 2000 requires the addition of the framework; this is handled by
Exchange setup if the framework is not installed.
OMA requires Basic as the Authentication method, oma.aspx as the default
document, and the OMA virtual directory executable path be configured as
.aspx,C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll,1,GET
,HEAD,POST,DEBUG.

Remember that OMA supports only Basic Authentication and propagating the
Authentication methods from the root web through the hierarchy will result in
the client receiving a message in the browser other than the Inbox. The specific
messages are covered in Fault Analysis later in this document.
If the IIS configuration of either becomes corrupt or in question, you can use
aspnet_iisreg – i to reinstall IIS and properly restore the configuration to
support OMA, sync and active-sync.
If you change the ASP.NET user account password to a known value, the
password in the LSA will no longer match the SAM account password. To
correct this problem and revert to the "AutoGenerate" default, run
Aspnet_regiis.exe -i, to reset ASP.NET to its default configuration. Consult

KB 306005, HOWTO: Repair IIS Mapping After You Remove and Reinstall
IIS in the Microsoft Knowledge Base.
In short, you need, “aspx” mapped to aspnet_isapi.dll, Basic authentication and
the Default document enabled and oma.aspx as the default document to expect
OMA to function normally.
Anonymous, Integrated, digest, and .NET Passport authentication are not
supported.
.NET Framework
IIS
20 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

The HTTP protocol is effectively stateless as it provides no mechanism for
identifying or maintaining sessions between a Web server and a client.
Microsoft addressed this problem in ASP by providing a Session object that
allowed 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 allows 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.
OMA utilizes the ASP.NET default; in-process session state handling. This
mirrors ASP and results in server affinity; a client session will be directed to a
particular server. In-process session state cannot be used in a Web farm
scenario. OMA was not tested with Session Server or Microsoft® SQL

Server™ session storage models and as such IS NOT SUPPORTED. However,
customers may choose one of these methods and experience no problems.
OMA uses the modified URL method of session management and DOES NOT
support cookies. You can confirm this by examining the web.config in the
OMA directory; you will find a section like the following.

<!-- SESSION STATE SETTINGS

By default ASP.NET uses cookies to identify which requests belong to a
particular session. If cookies are not available, a session can be tracked by
adding a session identifier to the URL. To disable cookies, set sessionState
cookieless="true".
-->
<sessionState mode="InProc" cookieless="true" timeout="20" />

The default setting for “timeout” is ‘20’, minutes, but can be modified by
changing the value in the web.config.
OMA tracks the last ‘n’ pages the user has visited. The excerpt from
web.config below shows the entry that controls ‘n’; the default is eight.
<!-- specifies how many pages ‘back’ the session state will retain; this allows
the device back button to provide functional links for previous pages.
<mobileControls SessionStateHistorySize="n">

This allows ‘Close’ and ‘Cancel’ actions to work and facilitates the following
scenarios:
The user uses the device Back button to go back to pages in
the device cache, without notifying the server. For links in
those cached pages to work, we need the session state to be
kept for them.
Session management

Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 21

Multi-clicking; the users clicks several links in the same page,
while waiting for the response to the first click to come back to
the device. In this scenario OMA can’t tell what page the user
ended up with, and needs to keep the state of all the potential
pages in memory.
Edit data is cached in user sessions to accommodate the method the edit pages
are implemented in OMA. All data being edited for an e-mail isn’t edited in the
same form. There are multiple forms/pages used to edit one e-mail. The session
keeps all this data until ‘Save’ or ‘Send’ is selected.
No credentials, user credentials, or Kerberos tickets for DAV/OWA template
access are cached in the session. This sensitive data is stored in regular process
memory and can not be moved out-of-proc by reconfiguring ASP.NET. This
accommodates use of non-in-proc session state management in future releases
should it be necessary.
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 ID and the web page.
http://exchange-server/oma/(dcdb0uvhclb2b145ukpyrr55)/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 the same way as it would
use a session ID obtained from a cookie. The runtime doesn't automatically use
modified URLs if the client doesn't support cookies. As seen in the excerpt
from the web.config, cookies must be explicitly disabled to make the runtime
use modified URLs.
There is potential for problems with mobile devices that do not support
modified URLs for session ID. Some wireless browsers can experience
difficulties dealing with relative URLs after they have been redirected to a

modified URL 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.
Modified URL session ID
22 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)


OMA Capabilities


OMA supports many of the features associated with Personal Information
Managers.
Personal Information Manager (PIM) Specific Features

Enumerate messages according time received

Read, Delete, Forward, Reply, and Compose E-mail

Enumerate attachments and Display attachment name

Access parent folder

Enumerate subfolders

Access contents of a particular folder

Display meeting requests as normal message

Read, Create, Delete, Accept, Decline or Tentative Accept meeting requests


Enumerate appointments of a given day

Read and Edit appointments

Navigate between days

Enumerate contacts

View, Create, Edit, Delete, e-mail, and call contacts

View and lookup GAL entries
Application Wide Features
URL based session management; connection to same server is maintained for
the entire connection.
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 23

Lookup contacts or users in directory by clicking on:

E-mail sender

Recipient

Meeting organizer

Attendee.

24 Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA)

Configuration Sources

Retrieving data for a user through DAV and OWA templates requires OMA to
construct the DAV/OWA URL
‘http://<servername>/<virtualdirectoryname>/<mailbox>’. OMA can’t use the
URL format without the <mailbox> at the end as this is the only way the OWA
HTML logon form can be reached.
The <servername> is retrieved from the User object of the logged on user; in
cross forest topologies, this information is read from the disabled user account
in the resource forest.
The <virutaldirectoryname> is retrieved from the registry ‘ExchangeVDir’
setting described above.
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. There is a problem with
this method however; the attribute may 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 via Exchange System Manager
(ESM) per virtual directory for OWA, OMA and ActiveSync. This facilitates
hosting as the same front-end server can have multiple OMA 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.
Unfortunately, OMA, as well as ActiveSync and OWA, does not have read
access for this attribute. Since it is an administrator setting, the access rights are
very restrictive. However, the Microsoft Exchange Directory Service to
Metabase Replication (DS2MB) process does have read access.

Retrievin

g Data
Determining Correct
Mailbox
Module 3: Troubleshooting Microsoft® Outlook® Mobile Access (OMA) 25

1. ESM writes an SMTP Domain value to Active Directory for a certain virtual
directory on a certain server (eg. ‘microsoft.com’ for the ‘microsoft/oma’
virtual directory and ‘corp2.com’ for the ‘corp2/oma’ virtual directory).
2. DS2MB on that server picks the setting up and replicates it to the IIS
Metabase on the machine.
3. OMA (as well as ActiveSync and OWA) reads the SMTP Domain for the
virtual directory in which they are running.
4. OMA (etc.) 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).
5. OMA (etc.) picks out the SMTP address using the SMTP Domain in the list.
6. The SMTP address is on the format <mailboxname>@<SMTP Domain>,
OMA (etc.) extracts the <mailboxname>.

The <servername>, <virtualDirectoryName> and <mailbox> values are
concatenated to provide the DAV/OWA URL required by the back-dnd server.