January, 2008

MAPI Architecture 

MAPI is a messaging architecture that enables multiple applications to interact with multiple messaging systems seamlessly across a variety of hardware platforms.

MAPI Objects and General Architecture

All of the objects defined by MAPI fall into one or more layers in the MAPI architecture.

• The client interface layer is made up of all the objects that a client application, form viewer, or form server can implement.
• The service provider interface layer contains the objects that a service provider of any type can implement.
• This layer includes objects implemented by address book, message store, transport, form library, and messaging hook providers.
• The layer that represents the MAPI subsystem is positioned between the client and service provider interface layers.
• The MAPI layer contains all of the objects that MAPI implements for clients or service providers to use 

The following article shows where each of the MAPI objects fits into the MAPI architecture. The objects are represented with the names of their derived interfaces.

In general,

• MAPI is made up of a set of common application programming interfaces and a dynamic-link library (DLL) component.
• The interfaces are used to create and access diverse messaging applications and messaging systems, offering a uniform environment for development and use and providing true independence for both.  
• The DLL contains the MAPI subsystem, which manages the interaction between front-end messaging applications and back-end messaging systems and provides a common user interface for frequent tasks.
• The MAPI subsystem acts as a central clearing house to unify the various messaging systems and shield clients from their differences.

MAPI Subsystem 

The MAPI subsystem is made up of the MAPI spooler, a common user interface, and the programming interfaces. The MAPI spooler is a separate process responsible for sending messages to and receiving messages from a messaging system. The common user interface is a set of dialog boxes that gives client applications a consistent look and users a consistent way to work.

The above article shows how Simple MAPI, CMC, and the CDO Library are layered between MAPI and client applications. Messaging-based clients call directly into MAPI while messaging-aware and messaging-enabled clients call into Simple MAPI, the CDO Library or CMC. Calls to these higher level APIs are forwarded to MAPI.

MAPI - Programming interfaces 

MAPI has programming interfaces that are used by the MAPI subsystem, by client application writers, and by service provider writers. The main programming interface is an object-based interface known as the MAPI programming interface. Based on the OLE Component Object Model, the MAPI programming interface is used by the MAPI subsystem and by messaging-based client applications and service providers written in C or C++.

Client Application Writers 

Client application writers have a choice of three other interfaces:

• Simple MAPI
•  An API function-based client interface for applications written in C, Microsoft Visual C++, or Microsoft Visual Basic.
• Common Messaging Calls (CMC)
• An API function-based client interface for applications written in C or C++.
• CDO Library
•  An object-based client interface for applications written in C, C++, Visual Basic, or Visual Basic for Applications. 

Note:

• Simple MAPI, CMC, and CDO Library client interfaces are primarily for messaging-aware and messaging-enabled client applications.
• These interfaces are less complex.
• Applications that require fewer messaging features can use Simple MAPI, CMC, or the CDO Library to implement these features quickly and easily.

MAPI client application

• A MAPI client application is any application that uses one of the three MAPI client interfaces (Simple MAPI, CMC, and the CDO Library) or the MAPI programming interface.
• Client applications implement messaging tasks as either their primary or secondary focus.
• Messaging client applications, such as applications that send and receive electronic mail, implement messaging as their primary focus while for non-messaging client applications, such as inventory or configuration applications, it is a secondary feature.

Client application categories 

Client applications can be organized into one of the following three categories:

• Messaging-aware applications
• Messaging-enabled applications
• Messaging-based work group applications

i) Messaging-aware applications 

A messaging-aware application does not require the services of a messaging system, but includes messaging options as an additional feature.

Example: A word processing application that includes a Send command in its File menu to allow documents to be sent is considered messaging-aware.

ii) Messaging-enabled applications 

A messaging-enabled application requires the services of a messaging system and typically runs on a network or an online service.

Example: A messaging-enabled application is Microsoft Mail.

iii) Messaging-based work group applications 

A more advanced client application is the messaging-based work group application. The work group application requires full access to a wide range of messaging system services, including storage, addressing, and transport services. These applications are designed to operate over a network without users having to manage the applications' network interaction.

Example: Such applications include work flow automation programs and bulletin board services.

EXOLEDB Overview

• Exchange Server 2007 provides a new, high-performance OLE DB provider that you can use on the local server to access Exchange store items: the Exchange OLE DB (ExOLEDB) provider.
• Through the ExOLEDB provider, programmers can access the Exchange store using OLE DB, Microsoft ActiveX Data Objects (ADO), and Collaboration Data Objects (CDO).

EXOLEDB Architecture

• ExOLEDB provider is a server-side component, and is therefore used only to access public stores and mailbox stores that reside on the same server.
• We can access data on the server remotely by wrapping functionality into Component Object Model (COM) components, which can be utilized by ASP and other Web applications.
• ExOLEDB provider is also ideal for use in COM+ components and Exchange store event and workflow sinks that run on the server.
• To access remote public stores and mailbox stores, use the WebDAV protocol, MAPI, or CDO 1.2.1.

Exchange Web Services 

Exchange Web Services is deployed with the Client Access server role. Microsoft Exchange Server 2007 clients connect to the computer that is running Exchange 2007 that has the Client Access server role installed in an Active Directory directory service site by using an HTTPS connection.

For more information refer this article

Delegates & Exchange Web Services 

In Microsoft Exchange Server 2007 SP1, you can use Exchange Web Services to add, update, and remove delegates.

Code sample

Please find the code example that shows you how to add delegates that can take actions on behalf of a principal. In this code it shows how to add two delegate users to an account.

static void AddDelegate()
{
    // Set the version, credentials, and Client Access server on ExchangeServiceBinding.
    ExchangeServiceBinding esb = new ExchangeServiceBinding();
    esb.RequestServerVersionValue = new RequestServerVersion();
    esb.RequestServerVersionValue.Version = ExchangeVersionType.Exchange2007_SP1;
    esb.Credentials = new NetworkCredential("username", "password", "domain");
    esb.Url = "https://example.com/ews/exchange.asmx";

    // Create the request.
    AddDelegateType request = new AddDelegateType();

    // Identify the principal's mailbox.
    request.Mailbox = new EmailAddressType();
    request.Mailbox.EmailAddress = "user1@example.com";

    // Identify the delegates who are given access to the principal's mailbox.
    request.DelegateUsers = new DelegateUserType[2];
    request.DelegateUsers[0] = new DelegateUserType();
    request.DelegateUsers[0].UserId = new UserIdType();
    request.DelegateUsers[0].UserId.PrimarySmtpAddress = "user2@example.com";
    request.DelegateUsers[1] = new DelegateUserType();
    request.DelegateUsers[1].UserId = new UserIdType();
    request.DelegateUsers[1].UserId.PrimarySmtpAddress = "user3@example.com";
   
    // Specify the permissions that are granted to each delegate.
    request.DelegateUsers[0].DelegatePermissions = new DelegatePermissionsType();
    request.DelegateUsers[0].DelegatePermissions.CalendarFolderPermissionLevel = DelegateFolderPermissionLevelType.Reviewer;
    request.DelegateUsers[0].DelegatePermissions.CalendarFolderPermissionLevelSpecified = true;
    request.DelegateUsers[1].DelegatePermissions = new DelegatePermissionsType();
    request.DelegateUsers[1].DelegatePermissions.TasksFolderPermissionLevel = DelegateFolderPermissionLevelType.Author;
    request.DelegateUsers[1].DelegatePermissions.TasksFolderPermissionLevelSpecified = true;
    request.DelegateUsers[1].DelegatePermissions.InboxFolderPermissionLevel = DelegateFolderPermissionLevelType.Editor;
    request.DelegateUsers[1].DelegatePermissions.InboxFolderPermissionLevelSpecified = true;

    // Specify whether the principal recieves meeting requests.
    request.DeliverMeetingRequests = DeliverMeetingRequestsType.DelegatesAndSendInformationToMe;
    request.DeliverMeetingRequestsSpecified = true;

    try
    {
        // Send the request and get the response.
        AddDelegateResponseMessageType response = esb.AddDelegate(request);
        DelegateUserResponseMessageType[] responseMessages = response.ResponseMessages;

        // One DelegateUserResponseMessageType exists for each attempt to add a delegate user to an account.
        foreach (DelegateUserResponseMessageType user in responseMessages)
        {
            Console.WriteLine("Results of adding user: " + user.ResponseClass.ToString());
            Console.WriteLine(user.DelegateUser.UserId.DisplayName);
            Console.WriteLine(user.DelegateUser.UserId.PrimarySmtpAddress);
            Console.WriteLine(user.DelegateUser.UserId.SID);
            if (user.DelegateUser.ReceiveCopiesOfMeetingMessagesSpecified)
            {
                Console.WriteLine("Does the delegate receive copies of meeting related messages: " + user.DelegateUser.ReceiveCopiesOfMeetingMessages);
            }
            if (user.DelegateUser.ViewPrivateItemsSpecified)
            {
                Console.WriteLine("Can the delegate view private items in the principal's mailbox: " + user.DelegateUser.ViewPrivateItems);
            }
        }
        Console.ReadLine();
    }
    catch (Exception e)
    {
        Console.WriteLine(e.Message);
        Console.ReadLine();
    }
}

For more information refer this article

• The GetFolder operation will return the permissions that are set on the folder when the AllProperties shape is specified.
  
• The SyncFolderHierarchy operation synchronizes PermissionSets.
  
• The UpdateFolder operation will fail if multiple Permission entries are provided for the same user. The UpdateFolder response will return the ErrorDuplicateUserIdsSpecified response code.
  
• The AppendToFolderField option of the UpdateFolder operation will append a permission entry for a user if the user does not already have a permission entry in the access control list (ACL) of the folder. If the user that is specified already has a permission entry, an ErrorUserAlreadyExists response code will be returned.
  
• The SetFolderField option of the UpdateFolder operation will overwrite all the permission settings on the folder. The client cannot change the permissions for each user.
  
• The DeleteFolderField option of the UpdateFolder operation will delete all the permission settings on the folder. 

Sample Code:

The following code example shows you how to set folder-level permissions when a folder is created. The authenticated user grants user3 the Editor permission level on a new folder named NewFolderWithPermissionsSet that is created in the Inbox default folder. 

static void CreateFolderLevelPermissions()
{
    // Set the version, credentials, and the Client Access server on ExchangeServiceBinding.
    ExchangeServiceBinding esb = new ExchangeServiceBinding();
    esb.RequestServerVersionValue = new RequestServerVersion();
    esb.RequestServerVersionValue.Version = ExchangeVersionType.Exchange2007_SP1;
    esb.Credentials = new NetworkCredential("username", "password", "domain");
    esb.Url = "https://CAS.example.com/ews/exchange.asmx";

    // Create user identifier.
    UserIdType user = new UserIdType();
    user.PrimarySmtpAddress = "user3@example.com.com";

    // Set the folder permission level to Editor.
    PermissionSetType permissionSet = new PermissionSetType();
    permissionSet.Permissions = new PermissionType[] { new PermissionType() };
    //permissionSet.Permissions[0] = new PermissionType();
    permissionSet.Permissions[0].PermissionLevel = PermissionLevelType.Editor;
    permissionSet.Permissions[0].UserId = user;

    FolderType folder = new FolderType();
    folder.DisplayName = "NewFolderWithPermissionsSet";
    folder.PermissionSet = permissionSet;

    // Specify the target folder.
    DistinguishedFolderIdType inbox = new DistinguishedFolderIdType();
    inbox.Id = DistinguishedFolderIdNameType.inbox;
    TargetFolderIdType targetFolder = new TargetFolderIdType();
    targetFolder.Item = inbox;

    CreateFolderType request = new CreateFolderType();
    request.Folders = new FolderType[] { folder };
    request.ParentFolderId = targetFolder;

    try
    {
        // Send the request and get the response.
        CreateFolderResponseType response = esb.CreateFolder(request);

        // Get the response messages.
        ResponseMessageType[] rmta = response.ResponseMessages.Items;

        // Cast to appropriate response message type.
        if (((FolderInfoResponseMessageType)rmta[0]).ResponseClass == ResponseClassType.Success)
        {
            // Continue.
        }
       
    }

    catch
    {
        // Handle errors.
    }
}

For more information refer this article

Technical Architecture of Exchange Server 2007 

In Exchange Server 2007 introduces several architectural changes from previous versions of Exchange. Many features and components have been redesigned, some features have been removed, and several new features have been added.

This document discusses the technical architecture of Exchange 2007, including descriptions of server roles, topologies, and the transport architecture. It is a compilation of several Exchange 2007 Help topics and is provided as a convenience for customers.

Please find the following documentation here

When i dealt with one of my customer, whose application dealt with Calendaring solution, i made this facility. Even in most of the scenarios, when we deal with Microsoft Office Outlook based calendaring solutions, what're the user action or what're the changes has made. But we have quick & smart solution for that.

By making use of logging calendar transactions feature in the MS Outlook. Because of the Calendar logging feature, calendar transactions that are generated by client features, by user actions, by the object model, or by the MAPI Calendar Table are written to a log file.

1) So what the log file will contain? 

The log file contains the following information:

2) What is the main goal of the logging feature?

The main goal of the Calendar logging feature is to quickly identify situations where, for example, meetings are inexplicably deleted from a Calendar folder

For more information, please view the following article

Guide to Public Folders in Exchange Server 2007

Please find the following articles, which guides us "how-to" deal with Public folders in Exchange Server 2007.

• Connect to Server                    :   How to Connect to a Server by Using the Public Folder Management Console
• Update Hierarchy                     :   How to Update a Public Folder Hierarchy
• New Public Folder                   :  How to Create Public Folders
• Export List                               :  How to Export Lists from the Exchange Management Console
• View                                        :  How to Customize the Exchange Management Console
• Update Content                        :  How to Update Public Folders
• Mail Enable                             :  How to Mail-Enable Public Folders
• Mail Disable                             :  How to Mail-Disable Public Folders
• Remove                                   :   How to Remove Public Folders
• Manage Send As Permission   : How to Grant the Send As Permission for a Mail-Enabled Public Folder
• View/configure the Public folder Properties:    

• How to View or Configure the Settings of Public Folders
• How to View or Configure the Settings of Mail-Enabled Public Folders

Transport Architecture - Exchange Server 2007

• I found this wonderful article, which gives heads up to Exchange Server 2007 with respect to Transport Architecture.
• When we work with Exchange Server 2007, it's must to know how internally the messages are getting routed.
• In Exchange Server 2007, the transport is collection of various server roles, connections, components and queus that work together to route the messages.

Exchange Server 2007 - Database Architecture changes 

The Exchange database architecture has changed in four significant respects in Exchange Server 2007:

• The streaming database (.stm) file has been removed from Exchange 2007.
• Longer log file names are used, thereby enabling each storage group to generate as many as 2 billion log files before log file generation must be reset.
• Transaction log file size has been reduced from 5 MB to 1 MB to support the new continuous replication features in Exchange 2007.
• The database page size has increased from 4 KB to 8 KB.