W10 Outlook Mobile Access

Contents

Overview 1

Lesson 1: Managing Mobile Service Components 2

Lesson 2: Outlook Mobile Access Browse 16

Lesson 3: Beneath the GUI 24

Lesson 4: Troubleshooting 40

Lesson 5: Tools 48

Lab A: Outlook Mobile Access 51

Review 55

Appendix A 56

Appendix B 60

Appendix C 64

Appendix D 70

Appendix E 77

Appendix F 85

Appendix G 92

Appendix H 97

Module 10: Outlook Mobile Access

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. © 2005 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows 2000, Active Directory, ActiveX, BackOffice, FrontPage, Hotmail, Jscript, MSN, NetMeeting, Outlook, PowerPoint, SQL Server, Visual Studio, and Windows Media 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 10: Outlook Mobile Access 1

Overview

*****************************illegal for non-trainer use******************************

Microsoft® Exchange Server 2003 includes built-in mobile functionality, which allows users to access Exchange data by using mobile devices. Exchange Server 2003 offers two services for your mobile users: Microsoft® Exchange ActiveSync® and Microsoft® Outlook® Mobile Access.

After completing this module, you will be able to:

Manage mobile service components.

Understand what Outlook Mobile Access Browse can do.

Know the interworking and how it interacts with other components.

Know how to troubleshoot Outlook Mobile Access and what tools you can use.

Introduction

Objectives

2 Module 10: Outlook Mobile Access

Lesson 1: Managing Mobile Service Components


This lesson introduces you to the mobile service components of Exchange Server 2003. It explains how to administer and secure these mobile service components.

After completing this lesson, you will be able to:

Describe the mobile service components of Exchange Server 2003.

Explain the requirements for Exchange Server 2003 mobile service components.

Explain the utilities that are needed to administer mobile components.

Identify the Mobile Services object properties that you can modify by using Exchange System Manager.

Configure Exchange ActiveSync and up-to-date notifications.

Describe the considerations necessary for securing mobile components.

Introduction

Lesson objectives


What Are the Mobile Service Components of Exchange Server 2003?


Exchange Server 2003 allows users of wireless and small devices, such as mobile phones, personal digital assistants (PDAs), or smart phones (hybrid devices that combine the functionality of mobile phones and PDAs), access to Exchange data. Exchange ActiveSync and Outlook Mobile Access are two of the mobile service components that are built into Exchange Server 2003. These components enable mobile users to browse Exchange information, in addition to synchronizing calendar, contact, and inbox information.

Exchange ActiveSync is a service provided in Exchange Server 2003 that allows users to synchronize their Exchange information (inbox, subfolders, calendar, contacts, and tasks) with their Exchange ActiveSync-enabled mobile device (such as Pocket PC 2002, Smartphone 2002 and Microsoft® Windows Mobile™ 2003 devices).

The two types of client initiated remote synchronizations supported by Exchange ActiveSync are:

Manual end-user driven. Allows users of mobile devices to perform a manual synchronization.

Scheduled. Allows users of mobile devices to schedule synchronization.

In addition, Exchange supports server initiated synchronization through Exchange ActiveSync and up-to-date notifications. Up-to-date notifications allow synchronization of mobile devices to be automated by using an up-to-date notification. This option in the Mobile Services Properties dialog box sends a notification to the mobile device to initiate an automatic synchronization through Exchange ActiveSync.

What Is Exchange ActiveSync?

What are up-to-date notifications?


After a user completes the first successful synchronization from the Pocket PC, the device is automatically populated with the user’s mailbox folder tree, exposing all mailbox folders available for synchronization. Each folder can be selected for an up-to-date notification. After a folder is chosen for an up-to-date notification, an event is set on the folder, which looks for new e-mail to be delivered to the folder. When the new e-mail arrives, an event runs inside the Exchange server mailbox store and creates a Simple Mail Transfer Protocol (SMTP) notification. When the notification on the device is received (devices receive notifications, based on the network type, the notification could be as a Short Message Service–based message), the device will start an Exchange ActiveSync session, enabling the device to become up to date. All this occurs without waking the device.

The up-to-date notification feature is only supported on the Windows Mobile 2003 devices.

Outlook Mobile Access is a service provided in Exchange Server 2003 that allows your users to access their Exchange mailbox by using a browser-enabled mobile device. Devices such as mobile phones and PDAs that use Extensible Hypertext Markup Language (XHTML), compact HTML (cHTML), or standard HTML browsers allow your users to connect to their inbox, calendar, contacts, tasks, and perform global address list (GAL) searches. In addition to mobile phones, Windows Mobile devices using Microsoft Pocket Internet Explorer and desktop personal computers using Microsoft® Internet Explorer 6.0 or later also support Outlook Mobile Access.

If your Exchange server has Device Update 2 installed (the default), Internet Explorer 6.0 will work but it will receive the following error message “The device type you are using is not supported. Press OK to continue.”

This is a partial list of the messaging and collaboration features that Outlook Mobile Access supports:

E-mail: Read, Reply, Forward, Delete, Flag, Compose. Navigate multiple folders. Look up sender or other recipients.

Calendar: Accept, Decline, Tentative meeting requests. Navigate via date picker control. Compose/Edit appointments with attendees’ support.

Contacts: View, Create, Edit personal contacts. Search personal and GAL contacts. Save global address list contacts to personal contacts. E-mail and Call contacts

Tasks: View, Create, Edit tasks

If you have previously used Microsoft® Mobile Information Server 2001 Enterprise Edition or Microsoft® Mobile Information Server 2002 Enterprise Edition to provide mobile access to your users, you need to be aware of the following compatibility issues with Exchange Server 2003 mobile components to determine the requirements for co-existence:

Mobile Information Server can communicate with Microsoft® Exchange 5.5 mailbox servers to provide Outlook Mobile Access (real-time browse access) and with Microsoft® Exchange 2000 Server mailbox servers to provide Exchange ActiveSync and Outlook Mobile Access support for browsing and new e-mail notifications.

How do up-to-date notifications work?

Note

What Is Outlook Mobile Access?

Note

Outlook Mobile Access Features

Compatibility with Microsoft Mobile Information Server


Exchange Server 2003 mobile components can only communicate with Exchange Server 2003 mailbox servers to provide Exchange ActiveSync and Outlook Mobile Access.

Mobile Information Server can be installed in an ‘ActiveSync-only’ configuration. When installed in this manner, Mobile Information Server 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 will have a good migration path to Exchange 2003 is to install Mobile Information Server 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 Mobile Information Server. Of course, this means they will not get the browse and push features of Mobile Information Server. But past experience shows ActiveSync is usually the feature driving Mobile Information Server deployments.

In summary:

Mobile Information Server has not been tested against Exchange 2003 mailboxes. Using Mobile Information Server mobile browse or Mobile Information Server ActiveSync® against Exchange 2003 mailboxes is not a supported scenario.

Coexistence: Mobile Information Server (browse, push, and sync) used against Exchange 2000 mailboxes can co-exist in the same environment as Exchange 2003 Outlook Mobile Access and Exchange ActiveSync used against Exchange 2003 mailboxes. Exchange 2003 does not reuse the Active Directory attributes used by Mobile Information Server, and so they do not 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 a customer wants to use Mobile Information Server for some users and Exchange 2003 mobility for others, then using separate name spaces for each is best.

Mobile Information Server /Exchange 2000 users URL = mis.corp.com

Exchange 2003 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.

In a mixed Exchange environment where you deploy a front-end and back-end topology, you must use Exchange Server 2003 for both the front-end and back-end servers to gain access to mailboxes through Outlook Mobile Access and Exchange ActiveSync.

For more information on Windows Mobile devices, see the Windows Mobile page on the Microsoft Web site at http://www.microsoft.com/windowsmobile.

Integrating Exchange 2003 with Mobile Information Server 2002

Note


What Are the Mobile Service Components of Exchange Server 2003? (continued)


Mobile phones using xHTML (Wireless Application Protocol [WAP] 2.0), cHTML (iMode) or standard HTML browsers will be capable of connecting and rendering inbox, calendar, contacts, tasks and (Global Address List) GAL searches.

In addition to mobile phones, Pocket PC 2002 using Pocket Internet Explorer Version 3.02 or greater and desktop computers using Internet Explorer 6.0 and greater (supported only with Device Update [DU]3.0 and greater) will both support mobile browse.

Outlook Mobile Access Browse does not support devices that are not on this list:

http://www.microsoft.com/exchange/techinfo/outlook/OWA_Mobile.asp

However, if the “Enable Unsupported Devices” option is checked, users will be able to use ANY mobile devices, not just WAP1.x devices.

This will display the following screen. You need to select OK to access your mailbox.

However, they might encounter issues since the devices are not supported and have not been tested.

The Outlook Mobile Access Browse component has been written using managed code (C# in this case). Therefore, to install the wireless support in Exchange Server 2003 the following software is required:

Microsoft® .NET Framework v1.1

Client

Server


ASP.NET Device Update 2 (DU-2) and beyond

The .NET Framework v1.1 is installed automatically on Microsoft® Windows Server™ 2003 servers. For Microsoft® Windows® 2000, this has to be manually installed. The latest version of the .NET Framework is always available from http://www.microsoft.com/windowsupdate.

The ASP.NET Device Update 2 (DU-2) must also be installed before Exchange Server 2003 mobile access support can be installed; however, the Exchange SETUP program will automatically install this component if it is not already installed.

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 Outlook Mobile Access. Mailboxes on Microsoft® Exchange 5.5 or Microsoft® Exchange 2000 require Microsoft® Mobile Information Server 2002.

HTML (HyperText Markup Language) is a collection of formatting commands that create hypertext documents--Web pages, to be exact. When you point your Web browser to a URL, the browser interprets the HTML commands embedded in the page and uses them to format the page's text and graphic elements. HTML commands cover many types of text formatting (bold and italic text, lists, headline fonts in various sizes, and so on), and also have the ability to include graphics and other nontext elements.

XML (Extensible Markup Language) is a system for defining specialized markup languages that are used to transmit formatted data. XML is conceptually related to HTML, but XML is not itself a markup language. Rather it is a meta language, a language used to create other specialized languages.

xHTML (Extensible HyperText Markup Language), also known as HTML version 5. XHTML is a new language that bridges the gap between HTML and XML. XHTML documents are well-formed XML, so they are readily viewed, edited, and validated with standard XML processors. This also makes it much easier for lightweight clients.

cHTML (Compact HyperText Markup Language), is a cHTML document is like an HTML document but contains only one screen. This make, the cHTML rendering model, is identical to the HTML rendering model: one page at a time. It was designed for low memory footprint applications and so excludes things like tables and frames. cHTML has been adapted to the profiles of particular mobile devices by manufacturers.

WML (Wireless Markup Language) is a markup language based on XML, and is intended for use in specifying content and user interface for narrowband devices, including cellular phones and pagers. WML is designed with the constraints of small narrowband devices in mind. These constraints include: 1) Small display and limited user input facilities; 2) Narrowband network connection; 3) Limited memory and computational resources. If a phone or other communications device is said to be Wireless Application Protocol (WAP) capable, this means that it has a piece of software loaded onto it (known as a microbrowser) that fully understands how to handle all entities in the WML 1.1 DTD.

Limitations

Standards


What Are the Requirements for Exchange Server 2003 Mobile Services?


Outlook Mobile Access is designed to take advantage of the Microsoft .NET Framework and Microsoft ASP.NET. The devices that are supported by Exchange Server 2003 for Outlook Mobile Access are determined by the device update package that is installed on the Exchange 2003 server.

The three software components that are required for Outlook Mobile Access in Exchange Server 2003 are:

The .NET Framework 1.1

ASP.NET

ASP.NET Device Update 2

The .NET Framework 1.1 installs automatically on Microsoft Windows Server 2003. For Windows 2000 Servers, SP3 or later, Exchange Setup automatically installs and enables both the .NET Framework and ASP.NET. Exchange Setup also installs the ASP.NET Device Update 2 package.

How are the software components installed?


The following table lists some of the devices supported by Outlook Mobile Access with Device Update 2.

Device Network Rendering language Sony Ericsson T68i Sony Ericsson T68i XHTML

NEC N503is iMode cHTML

Panasonic P503is iMode cHTML

Panasonic P504i iMode cHTML

Fujitsu F504i iMode cHTML

Pocket PC 2002, Pocket PC 2002 Phone Edition, Smartphone 2002, or Windows Mobile 2003 devices

GSM HTML

Sony SO503iS iMode cHTML

Mitsubishi D503iS iMode cHTML

NEC N504i iMode cHTML

Newer versions of the device update package will be available for download from the Internet that will add support for more devices to your Exchange server. For additional information on available updates, see the Microsoft Web site at http://www.asp.net/.

As mentioned before, Outlook Mobile Access Browse only supports devices that are on this list:

http://www.microsoft.com/exchange/techinfo/outlook/OWA_Mobile.asp

The Microsoft Mobile Internet Toolkit, an extension for ASP.NET, provides the utilities that are needed to write mobile Web applications for a wide variety of mobile browsers. The toolkit isolates developers from the challenge of writing and maintaining numerous Web applications, each targeted to a specific browser. The ASP.NET server controls included with the toolkit render the appropriate markup languages, including HTML, wireless markup language (WML) for Wireless Application Protocol (WAP) mobile phones, xHTML and cHTML, while accommodating different screen sizes, orientations, and device capabilities.

For more information about the Microsoft Mobile Internet Toolkit, see the Mobile ASP.NET Web Applications page on the Microsoft Web site at http://www.asp.net/mobile/.

It is impossible to understand the foundation of Outlook Mobile Access without a cursory understanding of the .NET Framework. Outlook Mobile Access 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 Outlook Mobile Access 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:

What devices are supported by Outlook Mobile Access with Device Update 2?

Note

Extending Outlook Mobile Access

Note

.NET Framework


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.

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.

Common Language Runtime (CLR)


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.

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 graphical user interface (GUI) applications (Windows Forms), XML Web services, Windows services, and last but most important to us, ASP.NET applications.

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

.NET Framework Class Library

ASP.NET


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.

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 is 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 three major markup languages used by mobile browsers to date; cHTML, xHTML and HTML. 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, Outlook Mobile Access derives from these base classes. The Device Updates are tentatively scheduled for updates twice a year. 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 Outlook Mobile Access.

ASP.NET Framework 1.1 Mobile Controls

.NET Framework Device Updates


Utilities That You Can Use to Administer Mobile Components


You use utilities such as Exchange System Manager, Internet Information Services (IIS) Manager, and Active Directory Users and Computers to configure Exchange mobile components.

Exchange System Manager is used when configuring Mobile Services objects. These objects are a part of the global settings for the Exchange organization. These objects allow you to define how Exchange ActiveSync and Outlook Mobile Access are enabled for all users in your organization. You can also define the domain name for mobile carriers that are used by up-to-date notifications.

Exchange System Manager is also used to configure an SMTP connector that is used for up-to-date notifications. You define the SMTP connector to connect your corporate SMTP bridgehead server to your mobile carrier, such as Microsoft® MSN® Mobile or your mobile operator.

IIS Manager is used to configure settings such as the security of Outlook Mobile Access and the Exchange ActiveSync virtual directories. Configuring Outlook Mobile Access and Exchange ActiveSync is similar to how you configure options for Microsoft Office Outlook Web Access by using the IIS Manager.

Active Directory Users and Computers allows you to control mobile access on a user-by-user basis. By default, Exchange ActiveSync and Outlook Mobile Access are enabled on all user accounts, but Outlook Mobile Access is disabled globally by default for Exchange Server 2003.

Exchange System Manager

IIS Manager

Active Directory Users and Computers


How to Configure Mobile Services Object Properties Using Exchange System Manager


By default, Exchange Server 2003 global settings for Exchange ActiveSync allow all users to initiate synchronization and receive up-to-date notifications. Outlook Mobile Access Browse can be configured on a Global and Per user basis with the on/off switch in Exchange System Manager and Active Directory Users and Computers.

By default, Outlook Mobile Access Browse is enabled for all users but is disabled globally by default through the Mobile Services object settings.

To modify your global settings for Exchange ActiveSync and Outlook Mobile Access, use the Mobile Services object in Exchange System Manager.

The following table lists the object properties available for Exchange ActiveSync.

Object property Description Enable user-initiated synchronization

Users can use their mobile carrier connection to synchronize their Exchange information to their ActiveSync-enabled device and then access this information while offline.

Enable up-to-date notifications

Mobile devices will be able to receive notifications sent to the device that will initiate synchronization between a user’s device and their Exchange mailbox. (Note: Currently only Windows Mobile 2003 devices support the up-to-date notifications.)

Enable notifications to user-specified SMTP addresses

Users can use any mobile carrier with the wireless synchronization feature of Exchange. Enable this feature if you have users who are using mobile devices to synchronize their Exchange information, and you do not want to specify the mobile carrier in Exchange.

To configure Exchange ActiveSync


The following table lists object properties available to access Exchange through Outlook Mobile Access.

Object property Description Enable Outlook Mobile Access

This feature allows users to use a supported mobile device to access Outlook Mobile Access.

Enable unsupported devices

This feature provides mobile access to Exchange Server from devices that are not supported. These unsupported devices may have unexpected results when using Outlook Mobile Access.

To configure Outlook Mobile Access


Lesson 2: Outlook Mobile Access Browse


This lesson explains how to enable user accounts for mobile access to Exchange Server 2003. Enabling user accounts for mobile access to Exchange will require that the user be enabled for Outlook Mobile Access or Exchange ActiveSync and that their mobile device be configured to access Exchange.

After completing this lesson, you will be able to:

Have a basic understanding of Outlook Mobile Access browse and be familiar with known issues.

Introduction

Lesson objectives


General Overview


Outlook Mobile Access Browse is accessed by going to the Outlook Mobile Access virtual directory on the Exchange 2003 server.

e.g. http://<exchange2003>/oma

Here are some of the features that Outlook Mobile Access Browse enables you to do:

E-mail: Read, Reply, Forward, Delete, Flag, Compose. Navigate multiple folders. Look up sender or other recipients.

Calendar: Accept, Decline, Tentative meeting requests. Navigate via calendar control. Compose/Edit appointments with attendees support.

Contacts: View, Create, Edit personal contacts. Search personal and GAL contacts. Save GAL contacts to personal contacts. E-mail / Call contacts.

Tasks: View, Create, Edit tasks.

Features


Known Issues


Below is a list of popular known issues.

817379 Cannot Access Exchange Server 2003 by Using Outlook Mobile Access When

Outlook Mobile Access does not work when Exchange virtual directory requires SSL or has Forms Based Authentication Enabled

When you attempt to access Outlook Mobile Access, you receive one of the following error messages:

1. Unable to connect to your mailbox on server <servername>. Please try again later. If the problem persists contact your administrator. In the Application Event Log you will see :

Event Type: Error

Event Source: MSExchangeOMA

Event Category: (1000)

Event ID: 1805

Date: 2/20/2003

Time: 6:25:35 PM

User: N/A

Computer: <ServerName>

Description:

Request from user [email protected] resulted in the

Microsoft(R) Exchange back-end server <servername>

returning an HTTP error with status code 403:Forbidden

or

2. A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator. In the Application Event Log you will see :

Single Server and Outlook Web Access Forms Based Authentication and SSL

Symptoms


Event Type: Error

Event Source: MSExchangeOMA

Event Category: (1000)

Event ID: 1507

Date: 2/20/2003

Time: 6:38:28 PM

User: N/A

Computer: <SERVERNAME>

Description:

An unknown error occurred while processing the current

request: Exception of type

Microsoft.Exchange.OMA.DataProviderInterface.ProviderExcept

ion was thrown.

Stack trace:

at

Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(O

bject sender, EventArgs e)

at

System.Web.SessionState.SessionStateModule.CompleteAcquireS

tate()

at

System.Web.SessionState.SessionStateModule.BeginAcquireStat

e(Object source,

EventArgs e, AsyncCallback cb, Object extraData)

At

system.Web.AsyncEventExecutionStep.System.Web.HttpApplicati

on+

IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep

step,

Boolean& completedSynchronously)

Inner Error: Exception has been thrown by the target of an

invocation.

Stack trace:

at

System.Reflection.RuntimeConstructorInfo.InternalInvoke(Bin

dingFlags invokeAttr,

Binder binder, Object[] parameters, CultureInfo culture,

Boolean isBinderDefault)

at

System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlag

s 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(O

bject sender, EventArgs e)

Inner Error: The remote server returned an error: (440)

Login Timeout.

Stack trace:

at

Microsoft.Exchange.OMA.ExchangeDataProvider.OMAWebRequest.G

etRequestStream()

at

Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeService

s.GetSpecialFolders()

at

Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeService

s..ctor(UserInfo user)

Exchange Outlook Mobile Access uses the Exchange virtual directory to access Outlook Web Access templates and DAV on Exchange back-end servers where the user’s mailbox is located.

When the /Exchange virtual directory on an Exchange back-end server is configured to require SSL and/or Forms Based Authentication is enabled, Exchange ActiveSync and Outlook Mobile Access cannot access this virtual directory. This issue does not occur when you enable these settings on the /Exchange virtual directory on a front-end server.

SSL can be required and forms based authentication can be turned on for front-end servers without applying the workaround below.

To resolve this issue, complete the following steps:

1. Start the Exchange System Manager

2. Locate the Servers/<server name>/Protocols/HTTP/Exchange Virtual Server folder. For each of the back-end servers where SSL is required or forms based authentication is enabled for the /Exchange virtual directory.

3. Right-click Exchange Virtual Server, click New, and then click Virtual Directory.

4. Type the name of the new virtual directory that the Exchange ActiveSync and Outlook Mobile Access processes will use (this is not the name of the virtual directory that Outlook Web Access clients will connect to). For example, type Exchange-oma.

5. In the Exchange Path section, verify “Mailboxes for SMTP domain” is selected and that the correct SMTP domain is listed in the text box.

6. Add the following registry entry:

HKLM\System\CurrentControlSet\Services\MasSync\Parameters

Entry: ExchangeVDir

Type: String Value (REG_SZ)

Data: <The virtual directory name created in step 4

proceeded with a forward slash> Example: / Exchange-oma

7. Open Internet Services Manager.

Cause

Resolution


8. Locate the virtual directory created in Step 4.

9. Right-click on this folder and choose Properties.

10. Select the Directory Security tab.

11. Within the “IP address and domain name restrictions” section, click the Edit button.

12. Enable the option “Denied access”.

13. Click the Add button.

14. Select Single computer and in the IP address field, type the IP address of the server being configured and click OK.

15. Click OK on the remaining dialog boxes.

16. Restart the World Wide Web Publishing Service.

You should avoid using Exchange 2000 Exchange System Manager in environments where Exchange 2000 is installed. Not only will you not be able to access new Exchange 2003 features, but there is also the risk of damage to new objects that Exchange 2000 does not understand. If you must continue to use Exchange 2000 Exchange System Manager, apply the latest Exchange 2000 SP3 roll-up to your Admin workstation(s) - http://microsoft.com/downloads/details.aspx?FamilyId=E247C80E-8AFA-4C2A-96B3-F46D1808C790&displaylang=en

The roll-up includes support for the msExchMinAdminVersion attribute (also known as Exchange System Manager versioning). Essentially, each Exchange object in the Active Directory is stamped with a minimum admin version. If Exchange System Manager detects that the data value is greater than the version of Exchange System Manager running, it will not allow edits to that object.

The following objects may become damaged if an unpatched version of Exchange 2000 Exchange System Manager is used in an Exchange 2003 environment:

A Recovery Storage Group (RSG) created by Exchange 2003.

Permissions on Outlook Mobile Access and ActiveSync virtual directories.

These objects will only be damaged if older versions of Exchange System Manager are used to manipulate (i.e. write data) directly on these objects.

Additionally, there may be some options in both Exchange 2000 and Exchange 2003 that fail to work properly if the Exchange System Manager from Exchange 2000 is run against Exchange 2003 servers:

Directory Access tab on the server object returns an error.

Outlook Mobile Access user attributes are stored on the disabled user account in the Exchange resource forest in a cross forest topology. When a user authenticates to Outlook Mobile Access, the corporate user account in the corporate forest is used. So Outlook Mobile Access needs a way of finding the disabled user based on the corporate user account in order to access user attributes in the active directory. Outlook Mobile Access does this by matching the two accounts using SID; “user ID” of the accounts are not necessarily the same. Outlook Mobile Access looks for a disabled account with a MasterAccountSID property set to the SID of the corporate user account. This method is not perfect.

Exchange 2000 Exchange System Manager in new environments

Cross Forest Topologies

Problem:


Corporate user account is moved between domains in the corporate forest, deleted and recreated in some other domain, then the SID mapping between the user accounts is broken and invalid. Outlook Mobile Access and other Exchange components will be broken for this user.

Use Active Directory Users and Computers to set the corporate user account as the ‘associated external account’ associated with the mailbox. To do this, navigate to the user in Active Directory Users and Computers and select the properties of the user. Select the Exchange Advanced Tab, and then click on the Mailbox Rights button. Add the corporate user account and check the “Associated external account” checkbox in the Permissions pane.

Another method could have been taken to look up a disabled account; SIDHistory property of the corporate account. This would help the ‘moved accounts’ issue above, however, corporations (OTG) do not like this property for security purposes and frequently clear it when they move accounts; net result: Outlook Mobile Access does not use SIDHistory.

For more information related to common Outlook Mobile Access Errors see Module 10 Appendix B.

ASP.NET is an integral part of the .NET Framework. Version 1.1 of ASP.NET or later is required for certain Exchange 2003 features; Outlook Mobile Access Browse is one of them.

Under certain circumstances the Access Control Lists (ACLs) set by ASP.NET may be overwritten and need to be restored. There are two common scenarios that cause this to happen.

1. Promoting a server to a domain controller (affects both Windows 2000 and Windows Server 2003).

2. Upgrading a server from Windows 2000 Server to Windows Server 2003.

The ASP.NET component of the .NET Framework is treated differently depending on whether the .NET Framework is installed on a Windows 2000 server or Windows Server 2003.

ASP.NET is installed as part of the .NET Framework on a Windows 2000 server. ASP.NET component is installed via Add/Remove Windows Components in Windows Server 2003. The Web Service Extension for ASP.NET should be allowed by default. You can double-check that it is enabled using the Web Service Extensions node in Internet Services Manager. The ASP.NET v1.1.xxxx Web Service Extension must be set to Allow.

Promoting a server to a domain controller or upgrading a Windows 2000 to Windows Server 2003 resets the ACLs set by ASP.NET. This breaks any applications requiring ASP.NET.

So if you install Exchange 2003 under the following two circumstances, certain Exchange 2003 features will not work.

1. On a server that was promoted to a domain controller after ASP.NET was installed.

2. On a Windows Server 2003 server that was upgraded from a Windows 2000 server with the .NET Framework installed.

Solution:

ASP.NET ACLs become corrupt after dcpromo or upgrading operating system


This problem can be avoided by installing ASP.NET after promoting a domain controller or upgrading from Windows 2000 to Windows Server 2003.

If the ACLs become corrupt, running the aspnet_regiis.exe script with the -i switch will restore the necessary ASP.NET ACLs.

Open a command prompt in the %windir%\Microsoft.NET\Framework\<version of the framework>" [C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322].

Type aspnet_regiis.exe -i and press ENTER.


Lesson 3: Beneath the GUI


This lesson explains what happens under GUI, and covers a number of subjects in-depth. These include:

An overview of Outlook Mobile Access Browse

Session State

Outlook Mobile Access and the Metabase

Forest and User settings

User preferences

In addition, some of the topics may not be covered by the instructor, but are there for your reference.

Introduction


Beneath the GUI: Overview


Basically Outlook Mobile Access browse does the following:

Phone initiates signal to carrier via microwave link.

Carrier converts signal to TCP/IP HTTP(S) request; if required: some phones support TCP/IP stack – DNS option is indicative of these devices

HTTP(S) request routed to http(s)/fqdn/oma

Global.asax Gets Services and caches http(s) request ID in a session object

Mobile Browser request checked against web.config for compatibility

User credentials checked by IIS; Basic Authentication

OMA.aspx calls Services.GetInbox to initialize the data provider

OMA.aspx queries inbox, and retrieves messages

Mobile controls send properly formatted response to mobile device

On a Windows Server 2003 server, Outlook Mobile Access Browse runs in its own process and sits in its own application pool: ExchangeMobileBrowseApplicationPool. This application pool name is legacy. On Windows 2000 servers, Outlook Mobile Access runs in a process together with other ASP.NET applications on the same machine. The user account Outlook Mobile Access runs under is the standard ASP.NET application user, it has very restrictive access rights overall.

On Windows Server 2003, OMA runs under the ‘Network Service’ account in a w3wp.exe process, and on Windows 2000 Outlook Mobile Access runs under the ‘aspnet’ account in an aspnet_wp.exe process.

CDOEX, ASP.Net session state management and ADSI are used inside the Outlook Mobile Access process to reach external sources.

Web.config, the Windows registry and the IIS metabase are used to read configuration.


For Outlook Mobile Access to work, the application has to receive the user credentials in clear text through Basic authentication. Outlook Mobile Access does not work with Windows Integrated Authentication even if the device/browser supports it.

Retrieving data for a user through DAV and Outlook Web Access templates requires Outlook Mobile Access to construct the DAV/OWA URL ‘http://<servername>/<virtualdirectoryname>/<mailbox>’. Outlook Mobile Access cannot use the URL format without the <mailbox> at the end as this is the only way the Outlook Web Access 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:

HKLM\System\CurrentControlSet\Services\MasSync\Parameters\ExchangeVDir

If this does not exist then it will connect to the Exchange Virtual Server

You will get a HTTP_403 if SSL is required on the Exchange Virtual Directory – See Q822177. You will need to create a new Exchange V-dir and point Outlook Mobile Access requests to that one in the registry. Documentation says that turning on Forms Based Authentication will cause Outlook Mobile Access to fail, which is not true. Only applies to Sync.

Extract from: 324306 XADM: How Exchange 2000 Web Storage System and Exchange 2000 Installable.

To be able to retrieve data for a user through DAV and Outlook Web Access templates, Outlook Mobile Access needs to be able to construct the DAV/Outlook Web Access URL on the format ‘http://<servername>/<vdirname>/<mailboxname>’. Outlook Mobile Access cannot use the URL format without the <mailboxname> at the end because only the Outlook Web Access HTML logon form can be reached that way. <servername> is retrieved from the Active Directory User object of the logged on user (attribute [X]) (in cross forest topologies, this information is read from the disabled user account in the Exchange resource forest). <vdirname> is retrieved from the registry ‘ExchangeVDir’ setting described above (the same back-end DAV/Outlook Web Access vdir is used for all users and all Outlook Mobile Access front-end vdirs on the same front-end server)

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 per virtual directory for 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

Retrieving Data

Note

Determining Correct Mailbox


directory represents a unique SMTP Domain. This setting is stored in the directory with one SMTP Domain per virtual directory per Exchange server.

Unfortunately, Outlook Mobile Access, as well as Exchange ActiveSync and Outlook Web Access, 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.

1. Exchange System Manager writes an SMTP Domain value to Active Directory for a certain virtual directory on a certain server (e.g. ‘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. Outlook Mobile Access (as well as Exchange ActiveSync and Outlook Web Access) reads the SMTP Domain for the virtual directory in which they are running.

4. Outlook Mobile Access (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. Outlook Mobile Access (etc.) picks out the SMTP address using the SMTP Domain in the list.

6. The SMTP address is on the format <mailboxname>@<SMTP Domain>; Outlook Mobile Access (etc.) extracts the <mailboxname>.

7. The <servername>, <virtualDirectoryName> and <mailbox> values are concatenated to provide the DAV/Outlook Web Access URL required by the back-end server.


Beneath the GUI: Session State


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.

Outlook Mobile Access 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. Outlook Mobile Access was not tested with Session Server or Microsoft® SQL Server™ session storage models and as such IS NOT SUPPORTED.

Outlook Mobile Access uses the modified URL method of session management and DOES NOT support cookies. You can confirm this by examining the web.config in the Outlook Mobile Access 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".

Session management


<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.

Outlook Mobile Access 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.

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 Outlook Mobile Access cannot 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 Outlook Mobile Access. 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/Outlook Web Access 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 does not automatically use modified URLs if the client does not 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


Session state is data that is retained only for the duration of a user browse session. The state is created when the user first connects, and deleted when the user has not made a browse request for X minutes. The default setting for X is ‘20’, but it can be modified through ASP.NET Session settings in web.config.

Outlook Mobile Access Browse uses the ASP .NET ‘in-proc’ storage model. The session state is used to keep track of user navigation history and to cache edited data before it is saved.

Session State


Beneath the GUI: Metabase


DS2MB update cycle has been changed in Exchange 2003 and affects all Exchange Web-based applications; Outlook Web Access, Outlook Mobile Access, and Exchange ActiveSync.

IIS picks up its configuration from the local metabase. Because Exchange servers need to be managed remotely, IIS-related information is stored in the Active Directory, and then replicated in one-direction from the Active Directory into the metabase. The process responsible for the replication is called DS2MB which runs as part of the System Attendant on each Exchange 2000 and Exchange 2003 server. DS2MB receives notifications of changes in the Active Directory and replicates them to the metabase.

In Exchange 2000, upon start-up of the System Attendant, DS2MB would perform a full replication of Active Directory information into the metabase. This had the side-effect of slowing down Exchange service start-up, especially for hosters who had large numbers of virtual directories or SMTP domains.

In Exchange 2003, full replication is not performed on start-up of the System Attendant; so Exchange service start-up will be faster. However, if you believe that the local metabase has become out-of-sync with the Active Directory, such as a manual change to the virtual directories and need to rectify the problem, you will need to adjust the 'HighWaterMarks' node in the metabase:

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

The guid after the HighWaterMarks\ is going to be different for each machine -

Changing the data for this ID to 0 (zero) or deleting the key and then restarting the Exchange System Attendant will cause DS2MB to perform a full replication of the Active Directory information into the metabase. The key will be added to the Metabase with the default value above when the System Attendant starts.

DS2MB


The metabase can be manipulated through a variety of tools. The best option is to install the IIS 6 resource kit, and use Metabase Explorer.

The sets that explain this have been covered previous under “Beneath the GUI: Overview”.

IIS Metabase and SMTP Domains


Beneath the GUI: Forest wide Active Directory Settings


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

Admin control over what mobile services the user has access to.

0: All 1: Browse and Sync 2: Sync and Up-To-Date Notifications 3: Sync 5: Browse 7: Nothing

The default value set by Exchange Setup is 7.

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

It is important to note that these settings are read from the directory only when a new session is created. This means changing the settings does not impact sessions in progress. For instance, disabling a user for Outlook Mobile Access will not immediately block that user out from an ongoing session. The user will not notice they are disabled until the next time they try to establish a new Outlook Mobile Access session.

The attributes on the User Object inherit three ACLs from the User object container: DA (Domain Admins), SY (Local System on Domain Controllers) and AO (Account Operators). Each of these security principals has full read/write permissions to the user’s settings. In addition, the two attributes are part of the Public-Information property set, which gives Authenticated Users (AU) read access.

The attributes in the Outlook Mobile Access Configuration Container are inherited from the Org Node, and then read access for AU is added.

Outlook Mobile Access

msExchOmaAdminWirelessEnable

msExchOmaExtendedProperties

Changing the values


Beneath the GUI: User Settings


Two user attributes exist for all the mobility functions. They are identical to the forest wide settings:

Admin control over what mobile services the user has access to.

0: All 1: Browse and Sync 2: Sync and Up-To-Date Notifications 3: Sync 5: Browse 7: Nothing

The default value set by Exchange Setup is 7.

For future feature-expansion (without requiring Active Directory schema changes)

msExchOmaAdminWirelessEnable

msExchOmaExtendedProperties


Beneath the GUI: User Preferences


Outlook Mobile Access has six user defined preferences which can be set by the end user to control their Outlook Mobile Access experience and are stored as properties on the root folder of the user’s mailbox in the Exchange store. They are populated with default settings the first time the user accesses Outlook Mobile Access.

These preferences are stored as the following properties. The string ‘Emb’ in this property name is legacy. It refers to an old temporary name of the Outlook Mobile Access component: ‘Exchange Mobile Browse’.

Description: User’s Outlook Mobile Access language/locale preference.

Default Value: The language/locale setting of the Exchange server.

Description: User’s Outlook Mobile Access Date Format preference.

Default Value: The default date format of the language/locale of the user.

Description: Mail folder to be displayed on start page of Outlook Mobile Access.

Default Value: The Inbox of the user (i.e. the folder receiving all incoming mail).

Description: User’s Outlook Mobile Access Time Format preference.

Default Value: The default time format of the language/locale of the user.

Description: User’s Outlook Mobile Access Time Zone.

Default Value: The time zone setting of the Exchange server is retrieved. Since you cannot get the time zone name you then pick the first time zone name (in the list provided by Windows) that matches the time zone data you get. Exceptions:

msExchEmbCultureInfo

msExchEmbDateFormat

msExchEmbDefaultMailFolder

msExchEmbTimeFormat

msExchEmbTimeZone


If the Exchange server language/locale is ko-kr, default to the Korean time zone.

Exch server lang: ja-jp -> Japanese time zone

Exch server lang: zh-cn -> Beijing time zone

Exch server lang: zh-tw -> Taiwanese time zone

Description: True if e-mail read through Outlook Mobile Access is to be marked as read

Default Value: Is set to ‘On’, so that e-mail is marked read.

msExchEmbMarkRead


Beneath the GUI: Other Settings


The configuration parameters mirror the directory.

This is an excerpt from the Metabase dump.

C:\Inetpub\AdminScripts>cscript adsutil.vbs enum

w3svc/1/root/oma

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights

reserved.

KeyType : (STRING) "IIsWebVirtualDir"

AppRoot : (STRING)

"/LM/W3SVC/1/root/OMA"

AppFriendlyName : (STRING)

"/LM/W3SVC/1/root/OMA"

AppIsolated : (INTEGER) 2

DefaultLogonDomain : (STRING) "\"

LogonMethod : (INTEGER) 3

DefaultDoc : (STRING) "oma.aspx"

Path : (STRING) "C:\Program

Files\Exchsrvr\OMA\Browse"

AuthPersistence : (INTEGER) 64

AuthPersistSingleRequest : (BOOLEAN) True

AppPoolId : (STRING)

"ExchangeMobileBrowseApplicationPool"

DoStaticCompression : (BOOLEAN) False

DoDynamicCompression : (BOOLEAN) False

Outlook Mobile Access keeps configuration keys in the Windows Registry. These keys affect the behavior of the Outlook Mobile Access component running on the machine on which they are set. The keys are:

Metabase entries

Note

Windows Registry


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MasSync

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchang

eWEB

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchang

eOMA

Values: ‘/Exchange’ or other string starting with ‘/’

This key is also used by Exchange Server ActiveSync. It specifies what virtual directory Exchange Server ActiveSync and Outlook Mobile Access should use to access Outlook Web Access templates and DAV on the Exchange Back-End servers where user mailboxes are located. If this key does not exist, or is ‘null’, then the default value ‘/Exchange’ is used. Otherwise, this key contains the name of the virtual directory (including the ‘/’).

This configuration opportunity exists to allow customers to require SSL on the Outlook Web Access virtual directory used by end users. The customer can then specify this key to point to a separate Outlook Web Access/DAV vdir that they set up and that does not require SSL but that is IP restricted to accept traffic only from the Exchange machine running Exchange ActiveSync and Outlook Mobile Access. Small Business Server 2003 sets Exchange up this way by default.

Values: 1 or anything

This key is also used by Outlook Web Access. If this key is set to ‘1’, then Outlook Web Access and Outlook Mobile Access use regional charsets when sending e-mail. If it does not exist or is set to anything else, Outlook Web Access and Outlook Mobile Access will use UTF-8 for sending email. The regional charset used is determined based on the client language the user has specified. See ‘Globalization’ below for the translation table used.

Outlook Web Access uses the accept-lang header of the browser request to determine what charset to use.


When set to ‘1’, the character set ‘iso-8859-15’ is used wherever the ‘iso-8859-1’ would have been used according to the Globalization charset table below.


This key is also used by Outlook Web Access. When set to ‘1’, the character set ‘GB18030’ is used wherever the ‘GB2312’ would have been used according to the Globalization charset table below.

Each ASP.NET application needs to have a web.config file. Essentially this file contains all the configuration information for the application. In this case, it has everything for Outlook Mobile Access. Web.Config can be opened in Notepad and is found in \Program Files\Exchsrvr\OMA\browse.

There are a few advanced application settings in the Outlook Mobile Access web.config file.

HKLM\SYSTEM\CurrentControlSet\Services\MasSync\Parameters\ExchangeVDir

HKLM\System\CurrentControlSet\Services\MSExchangeWEB\OWA\UseRegionalCharset

HKLM\System\CurrentControlSet\Services\MSExchangeWEB\OWA\UseISO8859_15

HKLM\System\CurrentControlSet\Services\MSExchangeWEB\OWA\UseGB18030

web.config


<add key="CredentialsTimeout" value="60"></add>

Defines the number of minutes Outlook Mobile Access will keep Kerberos tickets for DAV/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=”http://IT-Web/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.

<sessionState mode="InProc" cookieless="true" timeout="20" />

Specifies the session state configuration used by Outlook Mobile Access. The ‘timeout’ value here indicated for how many minutes the session state is kept in memory after the last request came in for the session.

<mobileControls SessionStateHistorySize="8">

Specifies how many pages ‘back’ the session state should keep track of (allowing the user to user the device back button, and still having the links on pages work).

<globalization requestEncoding="utf-8" responseEncoding="utf-8" />

Defines the default characters set Outlook Mobile Access will use to send HTTP responses and to interpret incoming requests without a character set specified. This would typically be used to specify ‘Shift_JIS’ for Japanese installations (where many devices do not report the charset used in requests and cannot handle the response if it’s ‘utf-8’).

In addition to these keys, there are many other ASP.NET web.config settings that influence Outlook Mobile Access behavior.

It is important to note that the web.config file is always replaced with the original Exchange 2003 web.config file when Exchange setup is run. Any changes made to the file will have to be repeated if setup is re-run.

This file is created when you install Device Update 2.0 and it contains the updated device configuration

web.config: <appSettings> section

web.config: <system.web> section

DeviceUpdate.config


Lesson 4: Troubleshooting


This lesson will look at a number of troubleshooting tips, tricks and techniques that will help you discover what is causing Outlook Mobile Access browse to fail and how to fix it.

Introduction


Troubleshooting: General


With all issues, it would pay to make sure that Outlook Mobile Access is configured correctly. In the following section you will discover some troubleshooting steps for Outlook Mobile Access browse.

To start with it would be advisable to check that the connection is actually getting to IIS. Look at the IIS logs on the Front-End and Back-End to see if request are making it. You should check for any firewalls and if URLScan is being used - Certain verbs need to be allowed, such as Get and Post.

Outlook Mobile Access Browse works in a similar way to Outlook Web Access. Ensure all settings are correctly configured in the “Mobile Services Properties General Tab”.

Make sure that the “Allow unsupported devices” checkbox on the general tab of the wireless services properties in Exchange System Manager.

Next make sure the User is enabled for Outlook Mobile Access Browse.

Next check that Outlook Web Access works using Internet Explorer. Connect to the following Web pages:

http://<Exchange2003-backend>/exchange

http://<Exchange2003-frontend>/exchange

Next check that Outlook Mobile Access works, but using Internet Explorer. Connect to the following Web pages:

http://<Exchange2003-backend>/oma

http://<Exchange2003-frontend>/oma

For additional Outlook Mobile Access Troubleshooting steps see Module 10 Appendix C.

Things to Try

Global Settings

User Settings

Test OWA


Troubleshooting: Debug Tracing


Outlook Mobile Access has extensive tracing capabilities controlled through web.config settings. The fact that they are controlled through web.config means all Outlook Mobile Access session state is reset (all active users loose their session. You can see this if you look at .NETt CLR Networking\Connections Establishes and choose All Instances) as the tracing levels are changed. That happens because ASP.NET automatically resets any application for which a file is updated.

Turning tracing on/off globally is done with the FileLogTracing and DebugOutputTracing keys at the top.

You can open web.config in Notepad. By default the trace levels are all set to 4. All you need to do is change:

<add key="FileLogTracing" value=“false"></add> to

<add key="FileLogTracing" value=“true"></add>

Note: Remember to set this value back to false when you have finished.

Enabling ‘FileLogTracing’ means a tracing file will be created.

The tracing file is created in the %TEMP% folder of the account running Outlook Mobile Access. For Windows Server 2003 this is usually “%SystemRoot%\temp”. For Windows 2000 it is usually "%SystemDrive%\Documents and Settings\<machineName>\ASPNET\Local Settings\Temp". The tracing file name is OMA_<x>.LOG, where <x> is a UTC time in ticks. A new tracing file is created every time the Outlook Mobile Access application is reset (e.g. when the file web.config is saved).

Tracing lines in the trace file start with "(e)" for error, "(w)" for warnings, "(i)" for info, "(v)" for verbose.

The tracing output may contain sensitive data such as email bodies, subjects and any other data that is viewed/edited through Outlook Mobile Access.

Debug Tracing


Enabling ‘DebugOutputTracing’ means tracing will be output to a VS7 debug window (or to Windows Server 2003 dbmon.exe. Windows 2000 dbmon.exe will not work since it does not interoperate with .NET Frameworks).

There are five levels of tracing available in the web.config file. By default Level 4 is set, which is the most verbose and useful. It is not really necessary to change this level, but if you need to here is a brief explanation of the levels and what they trace:

Level 0: off

Level 1: errors only

Level 2: errors and warnings

Level 3: errors, warnings and info

Level 4: errors, warnings, info and verbose

Different levels can be specified for specific code sections and for specific users. The code sections available are listed in the example above. For users, tracing can be set for AllUsers and for individual users. For unauthenticated processing, the AllUsers level applies. To determine what level applies in a certain code section for a particular user the following logic is used:

level = min (srcLevel, max(userLevel, allUsersLevel))

Source Switch Level Resulting Level

OmaPreferencing 4 2 4 2

ExchangeDataProvider 3 2 3 2

oma.aspx 2 2 2 2

oma.aspx:ViewStateCache 1 1 1 1

Global.asax 0 0 0 0

Form 3 2 3 2

User Switch Level 2 4 1

User Switch Name All Users

cn=test1

cn=test2

For more information on Outlook Mobile Access Trace Debugging see Module 10 Appendix D.

Tracing Levels


Troubleshooting: HTTP Error Codes and Counters

For a complete list of HTTP error codes, look at 318380.KB.EN-US IIS Status Codes

Event ID Event Name / Description / Comment

400 HTTP_Status_Bad_Request

The request is not in the expected format. Either request was corrupted or client is not following protocol specs

403 HTTP_Status_Forbidden

The devices had been blocked or disabled from functionality.

Look at Logs and see if this is one user trying to get access or multiple. If multiple and you believe people should be enabled check admin properties.

500 HTTP_Status_Server_Error

Requests are not succeeding. Single instances can recover by themselves but many may point to a problem at some point in the system.

Outlook Mobile Access has a performance counter object that provides very helpful information is determining the status of Outlook Mobile Access and the Exchange server itself. There are also various other counters available that can assist in the diagnosis. This document is meant to introduce those counters and explain how they are used.

Since Outlook Mobile Access is a front-end application, the counters described are all located on the exchange front-end server. Back-end issues will likely be of greater scope than Outlook Mobile Access itself.

Outlook Mobile Access counters are located in the Performance Monitor object MSExchangeOMA. These are not instance counters so they should always be

HTTP Error Codes

Outlook Mobile Access Performance Monitor Counters


available. Reset occurs when the Web service or IIS is reset although values will not be updated until the next request.

Category Identifier Name Help

Perf_BrowseCount Browse count Current total number of browse requests

Perf_BrowsesRate Browse Rate Number of browses per second

Perf_ResponseTime Last response time

The response time of the last request in milliseconds

Perf_Response

TimeAverage

Average response time

Running average of the response time in milliseconds

Perf_InternalResponse

TimeAverage

Cumulative time for all requests

Cumulative time for all requests in milliseconds

Perf_CurrentBrowses Current simultaneous browses

The current number of active browses

General

Perf_MaximumBrowses Maximum simultaneous browses

The maximum number of active browses

Perf_CalendarCount Total Calendar requests

Current number of Calendar requests

Calendar

Perf_CalendarRate Calendar request rate

Calendar requests per second

Perf_InboxCount Total Inbox requests

Current total number of Inbox requests

Inbox

Perf_InboxRate Inbox requests rate

Current total number of Inbox requests per second

Perf_ContactCount Total Contact requests

Current total number of Contact requests

Contacts

Perf_ContactRate Contact request rate

Current total number of Contact requests per second


Perf_TaskCount Total number of Task requests

Current total number of Task requests

Tasks

Perf_TaskRate Task request rate

Current Task requests per second

Perf_Status100Count HTTP status 100 count

Total status 100 codes returned







Errors



Outlook Mobile Access is an ASP.NET application and as such, the performance counters for ASP.NET and the .NET framework are very useful in looking at the state of the server.

One important piece of information is the user session count; located in the ASP.NET Apps v1.1.4322 object. The default instance is _total, which works in the absence of other sources, but the more accurate instance is _LM_W3SVC_1_root_OMA.

An instance counter will not be present until the first request after a restart of the Web service. The applicable counters are Sessions Active and Sessions Timed out. There is also a total counter which is the sum of the other two.

Outlook Mobile Access does not close sessions. The number of active is the number of users who have made a request within the window of the timeout period. The default is 20 minutes. The number of active sessions is important because it is reflective of the amount of memory used by ASP.NET.

Memory is used quite liberally by ASP.NET via Outlook Mobile Access. The .NET Framework is designed to recycle the worker process when the memory use exceeds a threshold set in the web.config file. The default value is 60% of the physical memory in the machine.

This behavior is seen as a failure for Outlook Mobile Access since all the active users will lose their session information and be required to log in again. The memory is used by the ASP.NET worker process and so can be watched using the Performance process object. The instance is the name of the process. A Windows Server 2003 server will use w3wp.exe and a Windows 2000 server will use aspnet_wp.exe.

The most applicable counter is Private Bytes which maps closely with the 60% limit. If memory use is nearing this value performance will be impacted as garbage collection tries to maintain the worker process. This can also be watched with the .NET CLR Memory object. The appropriate counters are Bytes in managed heaps of the memory allocated by ASP.NET. This is a subset of the worker process private bytes and % time in garbage collection which is an indicator of how hard garbage collector is working.

ASP.NET / Frameworks Counters

Memory Usage


When memory use is healthy, yet the server is busy, a typical value may be 30%.

When memory use nears the recycle threshold this value may increase to nearly 100%. The number of worker processes running and the number of worker process restarts can be found in the ASP.NET object.


Lesson 5: Tools


Wfetch.exe enables you to test http requests. See the following Knowledge Base (KB) article for more information: Q284285 HOW TO: Use Wfetch.exe to Troubleshoot HTTP Connections

Wfetch


Tools (continued)

To be honest, you do not really need a phone simulator, as you can use Internet Explorer to connect to the /OMA virtual folder.

However you can get the latest version of openwave’s phone simulator from: http://www.openwave.com/us/products/mobile/developer_products/phone_simulator/index.htm

Phone Simulator


Tools (continued)

For general information about URL Scan, look at: 307608 INFO: Availability of URLScan Version 2.5 Security Tool

The article describes known issues that may occur when you use the Urlscan 2.5 security tool in Microsoft Exchange Server 2003: 823175 Fine-Tuning and Known Issues When You Use the Urlscan Utility in an Exchange 2003 Environment

URL Scan


Lab A: Outlook Mobile Access


Lab A: Outlook Mobile Access

After completing this lab, you will be able to:

Troubleshoot and verify the default settings of OMA.

Use IIS Admin and Event Viewer to watch for errors.

Verify the IIS Settings against the file system settings.

Before working on this lab, you must have:

A running version of Exchange 2003 with OMA functioning.

Objectives

Prerequisites

Estimated time to complete this lab: 20 minutes


Exercise 1 Outlook Mobile Access Break/Fix Contoso Pharmaceuticals requires that all solutions go through a series of disaster prep tests. In this exercise you will go through a break fix scenario for Outlook Mobile Access.

Tasks Detailed steps

Note: All Steps to be performed on Exchange and XP-Client.

1. Open Internet Explorer. a. Logon to Exchange as Administrator with a password of Passw0rd1.

b. Open System Manager. Click Start, All Programs, Microsoft Exchange, System Manager.

c. Expand Global Settings and click on Mobile Services.

d. Right-click Mobile Services and click Properties.

e. Under Outlook Mobile Access, check both boxes and click OK.

• Enable Outlook Mobile Access

• Enable unsupported devices

f. Navigate to http://EX2/oma/

g. Log in to Outlook Mobile Access (OMA) with the username contoso\administrator with password Passw0rd1.

h. Click on Add in the Internet Explorer warning window.

i. Click on Add in the Trusted sites window.

j. Click on Close.

k. Click the OK link when the account has been authenticated.

l. Click on the Inbox and view your e-mail.

m. Close Internet Explorer.

Note: The next step, labbreak.cmd will be run. This script will intentionally break OMA. For maximum learning from this lab, do not view the contents of the file until after you have successfully re-enabled OMA. This break script breaks 3 different things.

2. Break the lab. a. On Exchange, from the task bar click, Start | Run | type C:\LabFiles\Lab 10\LabBreak.cmd.

3. Troubleshoot OMA #1. a. Open Internet Explorer and type http://ex2/oma in the Address bar. You receive the message “The page cannot be displayed.”

Hint: The reason this step fails is IIS Site or Server is not running.

b. From the task bar click, Start | All Programs | Administrative Tools | Services.

c. Locate the World Wide Web Publishing Service. What state is it in? Fix the problem if you find one.

d. From the task bar click, Start | All Programs | Administrative Tools | Internet Information Servers (IIS) Manager.

e. Expand EX2 (Server) | Web Sites.


f. What state is the Default Web Site in? Fix the problem if you find one.

g. Retry logging into OMA on Exchange by typing http://ex2/oma in Internet Explorer Address bar.

4. Troubleshoot OMA #2. a. On Exchange, find the directory that OMA is served from. From the task bar click, Start | All Programs | Administrative Tools | Internet Information Servers (IIS) Manager.

b. Expand EX2 (Server) | Web Sites | Default Web Site.

c. Right click the OMA Virtual Directory and choose Properties. Write down the Local Path on the Virtual Directory tab.

d. Open Windows Explorer and navigate to the directory you wrote down above. Open default.htm. Is this file the problem? Close the Internet Explorer windows.

e. Move the oma.aspx from the parent OMA Virtual Directory to the OMA Virtual Directory.

f. Rename web.cfg to web.config file.

g. Open Internet Explorer and type http://ex2/oma/oma.aspx in the Address bar.

h. OMA is starting to work again, but notice how the URL has to explicitly reference oma.aspx. This is not the way it was before it was broken. Close Internet Explorer.

i. From the task bar click, Start | All Programs | Administrative Tools | Internet Information Servers (IIS) Manager.

j. Expand EX2 (Server) | Web Sites | Default Web Site.

k. Right click the OMA Virtual Directory and choose Properties.

l. Click on the Documents tab.

m. Click default.htm and click the Remove button.

n. Click the Add button, enter oma.aspx and click the OK button.

o. Click OK to close OMA Properties.

p. Try logging in again . Open Internet Explore and type http://ex2/oma in the Address bar.

q. You should be back to normal!

5. Close all Virtual machines and delete the saved states.

a. On each Virtual machine, click Action, Close on the Virtual PC 2004 menu.

b. In the drop down list under What do you want the virtual machine to do? select Turn off and delete changes.

c. Click OK. This will reset the Virtual machines back to their original states.


Review

1. What version of the .NET Framework does Outlook Mobile Access browse need to work?

2. What Device Update is installed with the RTM version of Exchange 2003?

3. Can Outlook Mobile Access Browse look at public folders?

4. What authentication method does Outlook Mobile Access browse need to work?

5. What file do you need to edit to turn on debug logging?

6. What tool can you use instead of a phone simulator?

56 Appendix A

Appendix A

Step-By-Step Configuration of Outlook Mobile Access

Step by Step Walk Through

If Outlook Mobile Access is not enabled on the server

If you are using an unsupported Device

If you using an unsupported device while the “Enable unsupported devices” features is checked

Appendix A 57

This is the main menu

Inbox

Calendar

Contacts

Tasks

58 Appendix A

Find Someone

New

Preferences

Appendix A 59

About

60 Appendix B

Appendix B

Common issues related to Outlook Mobile Access

The following Browser text and application event occur when Anonymous has been added to the authentication methods. Remove all authentication methods except for Basic Authentication.

The following Browser text and application event occur when Anonymous / Integrated Windows Authentication / Digest Authentication has been added to the authentication methods. Remove all authentication methods except for Basic Authentication.

Common Browser errors related to IIS Anonymous access

Authenticated access

Appendix B 61

The following Browser text and application event occur when Integrated Windows Authentication and/or Digest Authentication has been added to the authentication methods. Remove all authentication methods except for Basic Authentication.

Integrated Windows Authentication and / or Digest Authentication

62 Appendix B

If the “aspx” extension is not mapped to the executable, %windir%\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll, the following is displayed in the browser. The only extension required for Outlook Mobile Access to function is “aspx”.

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.

Please try the following:

Make sure that the Web site address displayed in the address bar of your browser is spelled and formatted correctly.

If you reached this page by clicking a link, contact the Web site administrator to alert them that the link is incorrectly formatted.

Click the Back button to try another link.

HTTP Error 404 - File or directory not found. Internet Information Services (IIS) Technical Information (for support personnel) • Go to Microsoft Product Support Services and perform a title search for the words HTTP and 404. • Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled Web Site Setup, Common Administrative Tasks, and Custom Error Messages.

.aspx extension

The page cannot be found

Appendix B 63

The following Browser text is displayed when the default document, oma.aspx, has been disabled in the Documents tab of the Outlook Mobile Access virtual directory.

The only document required for Outlook Mobile Access to function is “oma.aspx”.

Make sure Outlook Mobile Access is enabled for the organization and for the user.

You are not authorized to view this page

64 Appendix C

Appendix C

Additional Outlook Mobile Access Troubleshooting Steps

If they are able to log onto Outlook Mobile Access, then from the main menu, go to option “8 About” and ask them to document everything that is listed.

The default setting from Exchange System Manager should look like this:

The ExchangeMobileBrowseApplicationPool settings from IIS Manager should look like this:

IIS Settings from Exchange System Manager

Application Pool Settings from Internet Service Manager

Appendix C 65

The Outlook Mobile Access virtual server settings should look like this:

Virtual Server Setting from Internet Service Manager

Configuration Button:

66 Appendix C

Authentication Control Button

Appendix C 67

The user credentials checked by IIS need to be Basic Authentication. Outlook Mobile Access does not work with Windows Integrated Authentication even if the device/browser supports it.

Outlook Mobile Access uses Kerberos (NOT SSL) to authenticate to the Back-end Exchange server, also works with Basic auth. It is okay to authenticate the user using SSL to the IIS.

Device support for Outlook Mobile Access Browse is dictated by the Device Update package installed on the Exchange 2003 server. When you run Exchange 2003 Setup today, the DU2 package is silently installed as part of the installation.

Approximately every six months, new Device Update packages are released. This will add support for more devices to your Exchange server.

Device updates are provided as part of the .NET Framework, the latest of which can be found here: http://msdn.microsoft.com/vstudio/device/mobilecontrols/aspmobiledrivers.aspx

The device updates are store in the deviceupdate.config file

Note: Device update 4 is supported but not according to Q828108.

The Network Service must have the following minimum permissions on: HKLM\System\CurrentControlSet\Services\Eventlog

Query and Set key value.

Create and Enumerate sub key(s)

Notify and Read

Supported Devices

Event Log Permissions

68 Appendix C

Exchange 2003 Outlook Mobile Access browse has been totally written in .NET Framework managed code. As a result, Outlook Mobile Access browse does not use the Exchange 2003 DsAccess to locate Windows Domain controllers or Global Catalog servers.

Instead Outlook Mobile Access Browse uses the standard DirectoryEntry and DirectorySearcher classes to search the Active Directory for the corresponding user object. The WIN32 DsGetDcName API is used in order to get the full DNS name for the user's domain.

As a result, normal DsAccess troubleshooting steps are not valid.

The DsGetDcName function is sent to the Netlogon service on the remote computer specified by ComputerName. If ComputerName is NULL, the function is processed on the local computer.

DsGetDcName does not verify that the domain controller name returned is the name of an actual domain controller or global catalog. If mutual authentication is required, the caller must perform the authentication.

DsGetDcName does not require any particular access to the specified domain. By default, this function does not ensure that the returned domain controller is currently available. Instead, the caller should attempt to use the returned domain controller. If the domain controller is not available, the caller should call the DsGetDcName function again, specifying the DS_FORCE_REDISCOVERY flag.

With the DSClient for Windows 95/Windows 98, the DsGetDcName function is exported from Logonsrv.dll and there is no corresponding library file. Be aware that this differs from Windows 2000, where DsGetDcName is exported by Netapi32.dll and the library file is Netapi32.lib.

Outlook Mobile Access code calls DsGetDcName with the following parameter values in order to convert the flat domain name entered by the user when authenticating to a DNS-style domain name:

ComputerName=null so that the local Exchange Server machine processes the request

DomainName=domain name typed by user when authenticating

DomainGUID=null so that no additional domain is queried beyond that specified by DomainName

SiteName=null so that a domain controller from the site closest to the ComputerName site is returned

Flags= DS_IS_FLAT_NAME | DS_RETURN_DNS_NAME to indicate that Exchange is not passing in a DNS-style DomainName and that we want a DNS-style name returned

If DsGetDcName returns ERROR_NO_SUCH_DOMAIN, then it is assumed that the domain is a Windows NT 4 domain (thus having no DNS name) and the flat name continues to be used. Any other error, and an HTTP 401 (Unauthorized) error is returned to the client.

For further troubleshooting steps look at:

314861 How Domain Controllers Are Located in Windows XP

247811 How Domain Controllers Are Located in Windows

DSAccess

Appendix C 69

Troubleshooting FlowChart

70 Appendix D

Appendix D

Outlook Mobile Access Trace Debugging

Outlook Mobile Access operates by servicing requests from a client browser. When tracking down an issue in the Outlook Mobile Access trace file, the first step is identifying which request prompted the error, and which traces are associated with that request. Those traces can then be analyzed to try to determine the error:

Outlook Mobile Access is built on top of ASP.NET, and Outlook Mobile Access code is therefore invoked through ASP.NET.

Before ASP.NET can give Outlook Mobile Access requests to handle, it has to load the Outlook Mobile Access .dlls which invokes Outlook Mobile Access’s initialization code.

Outlook Mobile Access gets loaded when the first request to oma.aspx is made. There are several initialization steps that occur when Outlook Mobile Access initializes. Most of these involve creating performance counters.

After an initialization, Outlook Mobile Access will only trace when it is handling a request. Handling a request involves receiving the request from the client, loading the page that generated the URL that was clicked, and rendering the resulting page to send back to the device, retrieving data from Exchange if necessary.

In a large trace file, it is useful to determine which traces are associated with a given request. By knowing the first trace Outlook Mobile Access makes when it receives a request and the last trace Outlook Mobile Access before sending the response, it is easy to group together the traces from a given request.

The following Outlook Mobile Access trace example log is from a single user log on.

The first trace made by Outlook Mobile Access when it handles a request is made in:

(v)+(163.903)=[,Application_BeginRequest,-

It generally makes 4 traces.

Before Outlook Mobile Access starts handling the request it is initializing the perfmon counters which ends with

OMA Browse Application has started,fPerfEnabled='True'

Analyzing a Trace File

Appendix D 71

The last trace will come from the method

(v)+(163.903)=[,Application_PostRequestHandlerExecute,

and is the last request before response is sent to the browser. It makes at the most two traces.

The PostRequestHandlerExecute is preceded by traces from the Application_EndRequest.

All BeginRequests have a corresponding EndRequest ((v)+(163.903)=[,Application_EndRequest,-).

A request to “http://<server>/oma/oma.aspx” will cause a new session to be created for the user, which will invoke

(v)+(163.903)=[,Session_Start,-1:99],[,CompleteAcquireState,-.

Session_Start will prompt for authentication and retrieves the user credentials via

(i)=(163.903)=[,GetCredentials,-1:1510] and creates the user object based on the credentials.

Once the client is authenticated, it makes a request to “http://<server>/oma/oma.aspx” and is redirected via HTTP 302 to a URL with a session ID http://<server>/oma/(<session_id>)/oma.aspx

Following GetCredentials is the creation of the user object. Loading and activating preferencing (Preferencing.dll) attempts to find the user in the Active Directory, and locates the user’s Exchange server. The user object initialization is complete when this trace is logged:

(v)=(163.903)=[,Session_Start,-1:805],[,CompleteAcquireState,-1:526],(Global.asax,Global),16:46:34.896676 userAsm.FullName='Microsoft.Exchange.OMA.Preferencing, Version=6.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',userType='Microsoft.Exchange.OMA.Preferencing.OmaUserInfo',user.DisplayName='bork'

Next step is to verify if the user is wireless enabled and is done through

(i)=(163.863)=[,get_UserIsWirelesslyEnabled,-

followed be receiving the users domain

(v)=(163.903)=[,get_ExchangeDomain,-1:138],[,Session_Start,-,

followed by the UseRegionalCharSet from the metabase settings for the user

72 Appendix D

(v)=(163.903)=[,GetRegionalCharSetSetting,-1:68],[,Session_Start,-.

The ExchangeDataProvider assembly (in the ExchangeDataProvider.dll)

(v)=(163.903)=[,Session_Start,-1:1056],[,CompleteAcquireState,-1:526],(Global.asax,Global),16:46:34.986806 Loading and activating services, srvTypeName='Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices',srvAssembly='Microsoft.Exchange.OMA.ExchangeDataProvider'

will attempt to find the user’s Mailbox.

This trace indicates that the search is over and successful.

(i)=(163.863)=[,get_MailboxName,-1:718],[,get_Item,-1:246],(OmaPreferencing,AdUserObject),16:46:35.006835 User '[email protected]' has mailbox name 'bork'

If this is the first session created since the server was started, the ExchangeDataProvider (ExchangeDataProvider.dll) will then go through its initialization (note: initialization may also happen prior to finding the mailbox).

The initialization involves generating “default queries” to Exchange. Many of the queries that are used by the data provider are known ahead of time, and are created here as an optimization. This indicates the start of the initialization:

(i)=(163.859)=[,.ctor,-1:117],[,.ctor,-1:11],(ExchangeDataProvider,DAVRequestBuilder),16:46:35.016849 DAVRequestBuilder created

Following this, the “Special Folder” URLs are grabbed from Exchange.

(i)+(163.834)=[,ParseDavResponse,-1:4351],[,GetSpecialFolders,

“Special Folders” are folders that have special aspects to them like, the Inbox, the Drafts folder, the Sent Items folder, the Calendar folder, etc. To get these URLs, the ExchangeDataProvider makes a property request to Exchange that is the same type of request used for getting properties on objects.

Then the user’s time zone index is grabbed from Exchange, which initiates another request to Exchange similar to the last one

(v)=(163.870)=[,get_UserTimeZoneIndex,-1:44],[,Session_Start,-

This call emits a huge trace of all the available time zones.

Appendix D 73

Next it calls

(v)+(163.903)=[,Application_PreRequestHandlerExecute,

and the GetCredentials() method to retrieve the user credentials from the request and look the user up in the directory.

Topology configuration errors or problems with the user object can show up here.

If GetCredentials() succeeds, Application_PreRequestHandlerExecute() will output a trace that looks something like this

New request from user '[email protected]' TYPE='System.Web.HttpRequest',HashCode='825'

It will trace the name of the user, followed by the data requested. It shows all the HTTP headers of the request, the URL the request was made to, whether it was a GET or a POST, and it even shows the body of the post.

Following the request information is the response which should be ignored.

Since the Application_PreRequestHandlerExecute() method occurs before Outlook Mobile Access has done any significant processing on the request, the “response” being traced does not represent what will actually be sent to the device.

The response sent to the device will be traced later, and should not be confused with this trace.

(v)+(163.813)=[,Page_Load,-1:106],[,OnLoad,-1:68],(oma.aspx,),16:46:36.138462

Determines which cached form to load.

It loads the last form that was sent back to the user. Once that form is loaded, it handles performs actions based on the URL the user clicked and switches to the next appropriate form, which is then rendered and sent to the user.

The last trace from Page_Load() before the form is loaded is the trace that indicates which form is to be loaded

(v)+(163.813)=[,Page_Load,-1:1143],[,OnLoad,-1:68],(oma.aspx,),16:46:36.318721 Loading form UnsupportedDevice

Once the form is initialized, Page_Load() will display the device capabilities of the device being used to browse Outlook Mobile Access

(i)=(163.813)=[,TraceCapabilities,-1:143],[,Page_Load,-1:1174],(oma.aspx,),16:46:36.348764 Mobile Capabilities Browser='IE'

74 Appendix D

(v)+(163.813)=[,OnPreRender,-1:51],[,PreRenderRecursiveInternal,

caches states to regenerate forms that where previously viewed.

(v)+(163.903)=[,Application_PostRequestHandlerExecute,- sets the user credentials to NUL so that they are not cached between requests.

(v)+(163.903)=[,Application_EndRequest, updates perf counters if they are enabled.

After these traces are made the response is sent to the client.

Here is a summary of all the functions listed above and a summary of what they do:

Function Description

Outlook Mobile Access Browse Application has started,fPerfEnabled='True'

Ending the perfmon counter initialization

(v)+(163.903)=[,Application_BeginRequest,- First trace made by Outlook Mobile Access when it handles a request

(v)+(163.903)=[,Session_Start,-1:99],[,CompleteAcquireState,-

A request to “http://<server>/oma/oma.aspx” will cause a new session

(i)=(163.903)=[,GetCredentials,-1:1510] Get the user’s credentials

Loading and activating preferencing Using Preferencing.dll to find the user in the Active Directory, and locates the user’s Exchange server

(v)=(163.903)=[,Session_Start,-1:805],[,CompleteAcquireState,-1:526],(Global.asax,Global),16:46:34.896676 userAsm.FullName='Microsoft.Exchange.OMA.Preferencing, Version=6.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',userType='Microsoft.Exchange.OMA.Preferencing.OmaUserInfo',user.DisplayName='bork'

User object initialization is complete

(i)=(163.863)=[,get_UserIsWirelesslyEnabled Is the user’s wireless enabled?

(v)=(163.903)=[,get_ExchangeDomain,-1:138],[,Session_Start

Get the users domain

(v)=(163.903)=[,GetRegionalCharSetSetting,-1:68],[,Session_Start,-

Get the UseRegionalCharSet from the metabase for the user

Function Summary

Appendix D 75


(v)=(163.903)=[,Session_Start,-1:1056],[,CompleteAcquireState,-1:526],(Global.asax,Global),16:46:34.986806 Loading and activating services, srvTypeName='Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices',srvAssembly='Microsoft.Exchange.OMA.ExchangeDataProvider'

Using ExchangeDataProvider.dll and attempting to find the user’s mailbox.

(i)=(163.863)=[,get_MailboxName,-1:718],[,get_Item,-1:246],(OmaPreferencing,AdUserObject),16:46:35.006835 User '[email protected]' has mailbox name 'bork'

The search for the users mailbox is over and successful.

(i)=(163.859)=[,.ctor,-1:117],[,.ctor,-1:11],(ExchangeDataProvider,DAVRequestBuilder),16:46:35.016849 DAVRequestBuilder created

Start of the initialization, default queries” to Exchange. Can happen prior to finding the mailbox

(i)+(163.834)=[,ParseDavResponse,-1:4351],[,GetSpecialFolders,-

Special folders URL are grabbed from Exchange.

(v)=(163.870)=[,get_UserTimeZoneIndex,-1:44],[,Session_Start,-

User’s time zone is grabbed from Exchange. Is called from several places in the code and is probably fixed in SP1 from Exchange 2003.

(v)+(163.903)=[,Application_PreRequestHandlerExecute,-

Retrieve the user credentials from the request and look the user up in the directory.

New request from user '[email protected]' TYPE='System.Web.HttpRequest',HashCode='825'

When GetCredentials() have succeeded

(v)+(163.813)=[,Page_Load,-1:106],[,OnLoad,-1:68],(oma.aspx,),16:46:36.138462

Determines which cached form to load.

(v)+(163.813)=[,Page_Load,-1:1143],[,OnLoad,-1:68],(oma.aspx,),16:46:36.318721 Loading form UnsupportedDevice

Indicates which form is to be loaded

(i)=(163.813)=[,TraceCapabilities,-1:143],[,Page_Load,-1:1174],(oma.aspx,),16:46:36.348764 Mobile Capabilities Browser='IE'

Device capabilities of the device being used.

(v)+(163.813)=[,OnPreRender,-1:51],[,PreRenderRecursiveInternal,-

Caches states to regenerate forms.

(v)+(163.903)=[,Application_PostRequestHandlerExecute

Sets user credentials to NUL so that they are not cached between requests.

(v)+(163.903)=[,Application_EndRequest,- Updates perf counters if they are enabled.

PostRequestHandlerExecute Precede the last trace

76 Appendix D


(v)+(163.903)=[,Application_PostRequestHandlerExecute,-

Last request before the response is sent to the device

If the issue seems to be with the device that is connecting to Outlook Mobile Access, then you can find out the device user agent string from the web.config log.

v)+(37.100)=[,Application_EndRequest,-1:205],[,System.Web.HttpApplication+IExecutionStep.Execute,-1:61],(Global.asax,Global),14:00:54.339180 TYPE='System.Web.HttpRequest',HashCode='143' ContentLength='0' ContentType='' CurrentExecutionFilePath='/oma/oma.aspx' FilePath='/oma/oma.aspx' HttpMethod='GET' IsAuthenticated='True' IsSecureConnection='False' Path='/oma/oma.aspx' PathInfo='' PhysicalPath='C:\Program Files\Exchsrvr\OMA\Browse\oma.aspx' RawUrl='/oma/oma.aspx' RequestType='GET' UserAgent='Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)' UserHostAddress='127.0.0.1' UserHostName='127.0.0.1' Headers.Count='7' Connection='Keep-Alive'; Accept='image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*'; Accept-Encoding='gzip, deflate'; Accept-Language='sv'; Authorization={skipped} Host='localhost'; User-Agent='Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)'; Cookies.Count='0' TotalBytes='0' Stream.CanSeek='True'

The UserAgent field contains the string used to figure out which device is being used.

Discovering the Device ID

Appendix E 77

Appendix E

Outlook Mobile Access Event ID’s

Diagnostic Logging to the Event Log is enabled by default. The following is the list of event log entries that you may see.

Note: This event is fired each time an instance of the Outlook Mobile Access Browse app. is launched. On one server ASP.NET may have multiple instances running simultaneously.

Information

Log_OmaEnd Outlook® Mobile Access Browse Application shut down successfully.

This message is sent when the Outlook Mobile Access Browse app. exits gracefully.

Warning

Log_OmaNoPerfCounters Outlook® Mobile Access Browse Application could not initialize its performance monitor counters due to the following error: {0}

This is caused by a setup failure.

Event ID: 1001

Event ID: 1002

Event ID: 1101

78 Appendix E

Warning

Log_OmaBadUserForSession = User {0} tried to access the session belonging to {1}; request was denied.

This happens if one user sniffs the session of another user and attempts to use their own credentials to go against the session ID of the other user.

Event ID: 1102

Event ID: 1501

Event ID: 1502

Event ID: 1503

Appendix E 79

Error

Log_OmaBadCredentials

Could not successfully parse the Authorization header. The user information {0} is neither a UPN nor a domain\\user format.

This will happen all the time as people mistype their credentials.

Error

Log_OmaNoShortDomain

Could not map short domain {0} to its long counter part, return code from DsGetDcName was {1}

Error

Log_OmaUnknownErrorOneInner

An unknown error occurred while processing the current request: {0}\n\n Stack trace:\n{1}\n\n Inner Error: {2}\n\n Stack trace:\n{3}

This is the most common ‘fall back’ error in Outlook Mobile Access Browse. When this error occurs, the user has found a bug.

Event ID: 1504

Event ID: 1505

Event ID: 1506

80 Appendix E

This is a common ‘fall back’ error in Outlook Mobile Access Browse. When this error occurs, the user has found a bug.

Event ID: 1507

Event ID: 1508

Appendix E 81

Error

Log_OmaErrorNoInfo

An unknown error occurred while processing the current request. No error information was provided by Microsoft® ASP.NET.


Log_OmaNoDefaultDomain

The Outlook® Mobile Access virtual root {0} has not been properly configured. Outlook® Mobile Access was not able to retrieve its configuration from the metabase path {1}. Error: {2}. Please re-create the virtual root using the Microsoft® Exchange administration tool.

Log_OmaMetabaseRead

Reading the Internet Information Services metabase for the Microsoft® Exchange default domain at node {0} failed with error {1}

Error

HTTP authorization header is invalid.

An incoming request has a malformed HTTP authentication header. The header is null or doesn’t have the ‘basic’ prefix.

Error

Event ID: 1509

Event ID: 1510

Event ID: 1511

Event ID: 1512

Event ID: 1513

82 Appendix E

Unable to decode the HTTP authorization header.

An incoming request has a malformed HTTP authentication header. Outlook Mobile Access could not decode the header.

Log_OmaNoServer

Unable to connect to the Microsoft® Exchange server {0}. To fix this problem, verify that there is network connectivity between this server and the Exchange server. Also, verify that the Exchange server that this server is attempting to connect to is functioning properly.

Information

Log_OmaOldServer

User {0} has Microsoft® Exchange server {1} which is not running Exchange Server 2003. That server is not accessible by Outlook® Mobile Access.

Information

Log_OmaNotCreated

User {0} has either changed the password recently or not yet created a mailbox using an advanced client such as Microsoft® Outlook or Outlook Web Access. The back-end server returned a 401 Access Denied error.

Error

Log_OmaNotFound

User {0} tried to access an item {1} that was not found on the Microsoft® Exchange Server. The item may no longer exist on the server.

Event ID: 1801

Event ID: 1802

Event ID: 1803

Event ID: 1804

Appendix E 83


Error

Request from user {0} resulted in the Microsoft(R) Exchange back-end server {1} returning a response with an error:

Error

Log_OmaNotSaved

Request from user {0} to save item {1} resulted in the Microsoft® Exchange back-end server{2} returning a response of {3} for the following properties:\n{4}.

Error

Log_OmaInvalidFwdReply

User {0} attempted to forward or reply with an invalid message.

Log_OmaNoProxy

Event ID: 1805

Event ID: 1806

Event ID: 1807

Event ID: 1808

Event ID: 1901

84 Appendix E

User {0} does not have a valid mailbox that ends with the SMTP proxy address {1}. Please make sure that the correct SMTP proxy address is set on the Outlook® Mobile Access virtual directory in Internet Information Services.

This error should not really happen any more since the design was changed (SMTP proxy address is not stored in web.config any more).

Log_OmaNoMailbox

User {0} does not have a mailbox. Please create a mailbox for the user using Microsoft® Exchange Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. After you create a mailbox for the user, the user must then access this mailbox using a client such as Outlook® or Outlook Web Access.

Log_OmaNoAD

Unable to connect to the domain controller servicing path {0}. To fix this problem, verify that network connectivity exists between this server and the domain controllers. Also, verify that the domain controllers are working properly.

Log_OmaNoGC

Unable to connect to the global catalog server. To fix this problem, verify that network connectivity exists between this server and the global catalog servers. Also, verify that the global catalog servers are working properly.

Event ID: 1902

Event ID: 1903

Event ID: 1904

Appendix F 85

Appendix F

Authentication

Authentication

• SecureID

IIS

Browser Caps

Language Support

Data Sources

ASP.NET Security *****************************illegal for non-trainer use******************************

There are about five ways to authenticate against IIS:

1. username only (works when IIS machine and user are both part of the same domain)

2. SDN\user (SDN = short domain name)

3. user@SDN

4. user@LDN

5. UPN (most of the time UPN is the same as #4, but can be different if set explicitly.)

The “\” (not the “/”) in the default domain name on the vdir allows IIS to authenticate via #s 3-5.

Outlook Mobile Access Browse will support UPN logins in following scenarios only:

Authentication

86 Appendix F

1. In single-forest topologies, with user is authenticating to Windows 2000 or Windows Server 2003 domain controller. The UPN may be in explicit (user@domain) or implicit (user@FQDN) format; or

2. In cross-forest topologies, with both authentication and resource forest domain controllers running in Windows Server 2003 native mode. The UPN must be in implicit (user@FQDN) format.

RSA SecurID is a third-party product used by a significant number of Exchange customers primarily in Europe. Outlook Mobile Access Browse is compatible with RSA SecurID. The RSA SecurID filters for IIS and ISA both work with Outlook Mobile Access. The device types supported by RSA and Microsoft Exchange OMA are not the same. To use RSA SecurID with Outlook Mobile Access, please ensure the devices/browsers you intend to use are supported by both products.’

Outlook Mobile Access /SecurID interoperability testing has revealed most browsers/devices work fine (PPC, Smartphone, IE6, T68m) and some device types have minor usability problems (eg. T68i).

Outlook Mobile Access requires Basic as the Authentication method, oma.aspx as the default document, and the Outlook Mobile Access 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 Outlook Mobile Access 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 Outlook Mobile Access, sync and ActiveSync.

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.

Note: Anonymous, Integrated, digest, and .NET Passport authentication are not supported.

Outlook Mobile Access Browser Caps entries use the form below.

OMA Capability Name

Type

Description

SecurID

IIS

Outlook Mobile Access Browser Caps included in Device Update (DU-n)

Appendix F 87

The following are examples of entries used in the web.config file.

supportsBackNavWithExpiresHeader

string

Determines whether Outlook Mobile Access will send the Expires header back on all requests with a value of "10/08/2000 10:28". The purpose of sending back a data/time in the past is to force expiration of content.

preferredResponseEncoding

integer

Sets Response.ContentEncoding to the specified integer. Should be set along with ResponseCharset.

preferredRequestEncoding

integer

Sets Request.ContentEncoding to the specified integer. Should be set along with ResponseCharset.

supportsOpenwaveUniversalLocalSrc

boolean

Tells Outlook Mobile Access to insert accesskeys before links, e.g. "<img src="" localsrc="325"/>".

defaultTextboxMaxBytes

integer

Will set the MaxLength in bytes allowed in TextBox controls.

MSONLY: Outlook Mobile Access also has the following capabilities:

displaysAccessKeysAutomatically: this property when false will tell Outlook Mobile Access to insert access keys before links. Similar to older capability supportsOpenwaveUniversalLocalSrc.

ExchangeOmaSupported: set when the device is Outlook Mobile Access supported.

In addition to these keys, there are many other ASP.NET web.config settings that influence Outlook Mobile Access behavior.

It is important to note that the web.config file is always replaced with the original Exchange 2003 web.config file when Exchange setup is run. Any changes made to the file will have to be repeated if setup is re-run.

These are the languages and cultures supported by the client side of Outlook Mobile Access. The user can configure what language is to be used for them.

88 Appendix F

The languages are only supported on devices that support the necessary character sets.

Language Locale Hex Code

Display String

Chinese Simplified

China 0x0804 Chinese Simplified (China)

Chinese Simplified

Taiwan Hong Kong

Chinese (CHT)

Chinese Simplified

Singapore 0x1004 Chinese Simplified (Singapore)

Danish Denmark 0x0406 Danish

Dutch Netherlands 0x0413 Dutch (Netherlands)

Dutch Belgium 0x0813 Dutch (Belgium)

English US 0x0409 English (United States)

English UK 0x0809 English (United Kingdom)

English South Africa

0x1c09 English (South Africa)

English Australia 0x0c09 English (Australian)

English Canada 0x1009 English (Canadian)

French France 0x040c French (Standard)

French Belgium 0x080c French (Belgian)

French Canada 0x0c0c French (Canadian)

German Germany 0x0407 German (Standard)

German Switzerland 0x0807 German (Switzerland)

German Austria 0x0c07 German (Austria)

Italian Italy 0x0410 Italian (Standard)

Japanese Japan 0x0411 Japanese

Korean South Korea

0x0412 Korean

Portuguese Brazil 0x0416 Portuguese (Brazil)

Portuguese Portugal 0x0816 Portuguese (Portugal)

Spanish Spain 0x040a Spanish (Spain, Traditional Sort)

Spanish Mexico 0x080a Spanish (Mexican)

Spanish Argentina 02c0a Spanish (Argentina)

Language Support

Appendix F 89

Note: Service Pack 1 Will add the following additional languages: Czech, Hungarian, Polish, Russian, Basque, Catalan, Finnish, Greek, Norwegian (Bokmal dialect), Turkish, and Swedish.

Outlook Mobile Access supports two modes for sending messages. Always use UTF-8 encoding or the regional charset chosen based on the language the sending user has defined for their client. The choice is stored as a preference; msExchEmbCultureInfo. The Regional character sets used for the languages/locales are:

Charsets in Sent Messages

90 Appendix F

Language Locale Charset

zh-tw Chinese (Taiwan)

Chinese (Hong Kong SAR) big5

zh-cn Chinese (China) gb2312

zh-sg Chinese (Singapore) gb2312

da-dk Danish iso-8859-1

nl-nl Dutch (Netherlands) iso-8859-1

nl-be Dutch (Belgium) iso-8859-1

en-us English (United States) iso-8859-1

en-gb English (United Kingdom) iso-8859-1

en-au English (Australia) iso-8859-1

en-ca English (Canada) iso-8859-1

en-za English (South Africa) iso-8859-1

fr-fr French (France) iso-8859-1

fr-be French (Belgium) iso-8859-1

fr-ca French (Canada) iso-8859-1

de-de German (Germany) iso-8859-1

de-ch German (Switzerland) iso-8859-1

de-at German (Austria) iso-8859-1

it-it Italian (Italy) iso-8859-1

ja-jp Japanese iso-2022-jp

ko-kr Korean ks_c_5601-1987

pt-br Portuguese (Brazil) iso-8859-1

pt-pt Portuguese (Portugal) iso-8859-1

es-es Spanish (Traditional Sort) iso-8859-1

es-mx Spanish (Mexico) iso-8859-1

es-ar Spanish (Argentina) iso-8859-1

These character sets are the same as those returned by Windows’ MLang library for regional charsets for these languages/locales.

The languages supported on the server side (for event log messages etc.) are CHT, CHS, KOR, JPN, FRN, ITA, GER, and SPA.

Server Languages

Appendix F 91

Language Specific

Time Zone

Time zone is stored as a zero based index in an array, you will see time zone determination occur at the beginning of any browser trace. The index corresponds to the CDO number associated with that time zone. The following are invalid time zones and are not supported by Outlook Mobile Access.

//** 52 used for floating time zone-- not used by Outlook Mobile Access

//** 76 is used for Sydney2000, not used --CDO gives it an invalid index

//** 77 is Chihuahua/La Paza/Mazatlan – no windows equivalent

Indexes 0, 52 and 76 or greater are invalid and will cause system errors. The default value for the time zone is the server time zone. Some time zones are exactly the same except for their names (such as the Korean and Japanese time zones). In those cases the user might get a different name for the time zone from the server as their default time zone. To combat this, if the server’s time zone is Korean/Japanese/China/Singapore/Taiwan, then time zone name is selected based on the server’s language.

The default mail folder is the inbox folder that the user has selected. It is stored as a path relative to the root folder of the user’s mailbox. If the path is invalid, it will be reset to the user’s inbox. The default value is the user’s inbox folder.

The Mark Read preference tells Outlook Mobile Access whether or not to mark viewed messaged as read. It is stored as a case sensitive string “true” or “false” and defaults to “true”.

Time & Date Format

Default Mail Folder

Mark Read

92 Appendix G

Appendix G

Data Sources OWA Templates

DAV Exchange Data Provider

PropfindBuilder: DavRequestBuilder

SearchBuilder: DavRequestBuilder

CDOEX

HTTP *****************************illegal for non-trainer use******************************

DAV provides “raw” access to most of the data hosted on Exchange. However, some very common tasks are difficult to implement using DAV. Accepting a meeting request, creating a meeting request, and resolving an ambiguous e-mail recipient are all quite difficult to do with DAV.

The Web client team solved these rather difficult problems when they were building Outlook Web Access. Generally Outlook Web Access responds to a user request with an HTML page. The format of the response page is determined by templates.

Outlook Mobile Access leverages some of this Outlook Web Access functionality. Outlook Mobile Access uses custom templates to control the information and the format of the information returned from the Outlook Web Access functions. These templates return data in a format very similar to a DAV response. This provides unification of the data format returned by functions using Outlook Web Access for data retrieval and those using DAV.

Search GAL

Resolve recipient addresses

Accept/Tentative accept/Decline meeting requests

Compose meeting requests

Edit/Update appointments and meeting requests

Get recurrence information about an appointment

Get free/busy status of recipients

All use Outlook Web Access to retrieve the data and then parses it with Outlook Mobile Access templates to produce a return in a format very similar to DAV.

DAV is the foundation for most operations in the Outlook Mobile Access Exchange Data Provider. The DAV protocol, designed for general data access,

Outlook Web Access Templates

DAV – Exchange Data Provider

Appendix G 93

extends HTTP to HTTP 1.1. This allows for data storage on the server but retrieval by the HTTP client; http://webdav. The fundamental operations are:

Folder Navigation

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 gleaned from Outlook Web Access.

This class builds a frequently used DAV request – PROPFIND. The PROPFIND method retrieves properties defined on the resource identified by the Request-Universal Resource Identifier (URI), if the resource does not have any internal members or if the resource is a collection that has internal member URIs. For details of PROPFIND, please refer to RFC2518.

Other classes use this class to request a pre-defined set of properties from an item. Third party developer can also use this class to create a customized request to get further info on messages, contacts, calendar, or tasks.

This class builds a frequently used DAV request – SEARCH. The client invokes the SEARCH method to initiate a server-side search. Other classes use this class to search for qualifying items and retrieve a pre-defined set of properties from each item. Third-party developer can also use this class to create a customized request to get further info or set different search criteria.

Design

PropfindBuilder: DAVRequestBuilder

SearchBuilder: DAVRequestBuilder

94 Appendix G

RFC 2518: HTTP Extension for Distributed Authoring – WEBDAV http://www.ics.uci.edu/pub/ietf/webdav/protocol/rfc2518.html

CDOEX is a dynamic link library (DLL) designed to provide e-mail functions. This DLL is used strictly as a MIME parser. However, as CDOEX is an unmanaged DLL, a managed wrapper was written. CDOEX is used for the following:

Forward, Reply, ReplyAll for either a message or meeting request

The Microsoft .NET Framework provides a layered, extensible and managed implementation of Internet services that can be integrated quickly and easily into applications. The supplied Internet access classes in the System.Net namespace have all the capabilities needed for browser interoperability.

The .NET Framework provides the three pieces required to access Internet resources through a request/response model as classes:

URI class - contains a URI (Universal Resource Identifier) that identifies the Internet resource.

WebRequest class - contains a request for the resource.

WebResponse class - provides a container for the incoming response.

WebRequest and WebResponse classes use Secure Sockets Layer (SSL) automatically. The decision to use SSL is made by the WebRequest class based on the URI it is given. If the URI begins with "https:" then SSL will be used.

When client authorization for Internet requests is required, the credentials necessary for authorization are contained in the Credentials property of the WebRequest. Basic credentials are used by Outlook Mobile Access and are stored in a NetworkCredentials instance. Multiple credentials can be stored at once in a CredentialCache instance. When storing credentials in a CredentialCache, the credentials sent to the server are chosen based on the URI of the request and the authentication scheme the server supports.

Applications that use HTTP to connect to data resources can use the .NET Framework’s ServicePoint and ServicePointManager classes to manage connections to the Internet and to help them achieve optimum scale and performance.

The ServicePoint class provides an application with an end point to which the application can connect to access Internet resources. Each ServicePoint instance contains information that helps optimize connections with an Internet server by sharing optimization information between connections to improve performance.

Each ServicePoint is identified by a URI and is categorized according to the scheme identifier and host fragments of the URI. For example, the same ServicePoint instance would provide requests to the URIs http://www.de.mo/index.htm and http://www.de.mo/news.htm?date=today since they have the same scheme identifier (http) and host fragments (www.de.mo). If the application already has a persistent connection to the server www.de.mo, it uses that connection to retrieve both requests, avoiding the need to create two connections. Thus, all users for Outlook Mobile Access will use the same service point.

CDOEX

HTTP

SSL

Authentication

Connection Pooling

Appendix G 95

ServicePointManager is a static class that manages the creation and destruction of ServicePoint instances. The ServicePointManager creates a ServicePoint instance when the application requests an Internet resource that is not in the collection of existing ServicePoint instances. ServicePoint instances are destroyed when they have exceeded their maximum idle time or when the number of existing ServicePoint instances exceeds the maximum number of ServicePoint instances for the application. You can control both the default maximum idle time and the maximum number of ServicePoint instances by setting the MaxServicePointIdleTime and MaxServicePoints properties on the ServicePointManager.

You can change the number of connections that an application uses by changing the static DefaultConnectionLimit property on the ServicePointManager class at application initialization. The number of connections between a client and server can have a dramatic impact on application throughput. By default, an application using the HttpWebRequest class uses a maximum of two persistent connections to a given server, but you can set the maximum number of connections on a per-application basis.

The HTTP/1.1 specification limits the number of connections from an application to two connections per server.

// Set the maximum number of connections per server to 4.

ServicePointManager.DefaultConnectionLimit = 4;

// set connection limit for an individual URI

Uri uri = new Uri("http://www.de.mo/");

ServicePoint sp = ServicePointManager.FindServicePoint(uri);

sp.ConnectionLimit = newLimit;

Connection grouping associates specific requests within a single application to a defined connection pool. For example, say a user, Joe, visits an internal Web site that displays his payroll information. After authenticating Joe, the middle-tier application server uses Joe's credentials to connect to the back-end server to retrieve his payroll information. Next, Susan visits the site and requests her payroll information. Because the middle-tier application has already made a connection using Joe's credentials, though, the back-end server responds with Joe's information. However, if the application assigns each request to the back-end server to a connection group formed from the user name, then each user belongs to a separate connection pool and cannot accidentally share authentication information with another user.

Assigning a request to a specific connection group requires you assign a name to the ConnectionGroupName property of your WebRequest instance before making the request.

// Create the WebRequest object.

WebRequest WReq = WebRequest.Create("http://www.de.mo/");

96 Appendix G

WReq.Credentials = new SingleCredential(username, password, domain);

WReq.ConnectionGroupName = username;

WebResponse WResp = WReq.GetResponse();

Assigning a different value to the username variable on subsequent requests produces a new server connection, using the proper credentials.

Appendix H 97

Appendix H

ASP.NET Security Architecture Outlook Mobile Access Security Overview

• Windows Server 2003, Windows 2000

• ASP.NET Client Authentication

• IIS

• ASP.Net

• Windows ACLS and Resources

• ASP.NET settings

• Credentials

• Accessing System Credentials

• Accessing the Event Log *****************************illegal for non-trainer use******************************

Exchange Server

IIS processUser

Outlook Mobile Access Process

CDOEX – DAV – Outlook Web Access Templates

ASP.NET Session Mgmt

System.directory services

Active Directory

Mailbox Server

Basic Auth -SSL or not

IIS Metabase

Web.configRegistry

Basic credential handed over with request

Authentication

Global Outlook Mobile Access enabled?User Outlook Mobile Access enabled?

Kerberos, DAV/Outlook Web AccessUser CredentialsNO SSL

Outlook Mobile Access runs in its own process in a dedicated application pool: ExchangeMobileBrowseApplicationPool. Outlook Mobile Access runs as the ‘Network Service’ account in a w3wp.exe process

Outlook Mobile Access runs in a process together with other ASP.NET applications on the same machine. Outlook Mobile Access runs as the ‘aspnet’ account in an aspnet_wp.exe process.

CDOEX, World Wide Web Document Authoring and Versioning (DAV), Outlook Web Access Templates and system.directory services are used inside the Outlook Mobile Access process to reach external sources.

Overview of OMA Security Architecture

Microsoft® Windows Server™ 2003

Microsoft® Windows® 2000

Outlook Mobile Access Data Access and processing

98 Appendix H

Active Directory, the registry, the IIS metabase and the web.config file are read to obtain configuration settings.

Outlook Mobile Access has to receive the user credentials in clear text through Basic authentication. Outlook Mobile Access 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 Outlook Mobile Access 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

Outlook Mobile Access 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

Details

ASP.NET Authenticates the Client

Appendix H 99

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 Outlook Mobile Access enforces by explicitly setting <identity impersonate=”false”> in the default web.config.

As in the case of Outlook Mobile Access, 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 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.

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

IIS

ASP.NET

100 Appendix H

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.

Application level configuration settings are maintained in Web.config located in the Outlook Mobile Access 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.

Windows ACLs and Resources

ASP.NET Settings

Validating Credentials

Appendix H 101

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.

Outlook Mobile Access does not use the highly-privileged SYSTEM account to run ASP.NET. The ExchangeMobileBrowseApplicationPool runs as Network Service.

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, Outlook Mobile Access 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.

ASP Credentials

Accessing System Resources

Accessing the Event Log