Part 1 : Developer Roadmap – Development Technologies for Exchange Server 2010

This two part article is targeted for the developer audience, if you’re the developer who want to create a develop custom application for Exchange Server 2010 or already has custom application designed for previous versions of Exchange Server 2010.

Some Exchange programming technologies that are available in versions of Exchange earlier than Microsoft Exchange Server 2010 are obsolete and have been replaced with other technologies. Per MSDN article, the programming technologies and APIs stated below have either been removed from Exchange 2010 or earlier versions of Exchange, are no longer supported for use with the current version of Exchange, or are no longer the recommended API to use to access Exchange.

• Active Directory Services Interface still exists, but we do not recommend that you access Exchange data in Active Directory Domain Services (AD DS) by using ADSI.

Recommendation: We recommend that you use Exchange PowerShell commands to administer Exchange configuration data.

• Collaboration Data Objects for Exchange (CDOEX) is not included in Exchange 2010.

Recommendation: We recommend that you migrate your applications that use CDOEX to Exchange Web Services.

• Collaboration Data Objects for Exchange Management (CDOEXM) is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate your applications that use CDOEXM to use Exchange PowerShell commands.

• Collaboration Data Objects for Exchange Workflow (CDOWF) is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate your applications that use CDOWF to use Windows Workflow Foundation Services.

• Collaboration Data Objects for Windows 2000 (CDOSYS) is included in current versions of Windows. The functionality in CDOSYS is now available in the Microsoft .NET Framework.
• Collaboration Data Objects for Windows (CDOSYS) SMTP/NNTP Event Sinks are included in current versions of Windows.

Recommendation: Notification-based applications that work with Exchange 2010 should use transport agents.

• Collaboration Data Objects (CDO) version 1.2.1 is available for download for applications that continue to require it. CDO 1.2.1 is a de-emphasized API, and support is only available under an Extended Support agreement.

Recommendation: We recommend that you migrate any CDO 1.2.1 applications to use Exchange Web Services.

• Exchange Incremental Change Synchronization (ICS) is a MAPI-based interface, and is still supported against Exchange 2010.

Recommendation: To ensure continued future compatibility, we recommend that you consider migrating your ICS applications to use Exchange Web Services notifications.

• Exchange OLE Database Provider (ExOLEDB) is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate applications that use ExOLEDB to use Exchange Web Services.

• Exchange Rules DLL is part of the sample code that shipped with the Exchange 5.5 and Exchange 2000 SDKs.

Recommendation: We recommend that you migrate applications that use the Exchange Rules DLL to use either MAPI or Exchange Web Services notifications.

• Exchange Store Event Sinks are not available in Exchange 2010.

Recommendation: Where possible, we recommend that applications that use Exchange Store Event sinks be migrated to use either transport agents or Exchange Web Services notifications.

• Exchange Streaming Backup and Restore API is not included in Exchange 2010.

Recommendation: We recommend that you migrate backup and restore applications that use streaming backup to use the Windows Volume Shadow Copy Service (VSS).

• Exchange WebDAV is not included in Exchange 2010.

Recommendation: We recommend that you migrate applications that use Exchange WebDAV to use the Exchange Web Services.

• Exchange WebDAV Notifications are not included in Exchange 2010.

Recommendation: We recommend that you migrate applications that use Exchange WebDAV notifications to use Exchange Web Services notifications.

• Exchange Web Forms is not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate applications that use Exchange Web Forms to use either Windows SharePoint Services, or Active Server Pages.

• Lightweight Directory Access Protocol (LDAP) still exists, but accessing Exchange data in AD DS by using LDAP is not recommended.

Recommendation: We recommend that you use Exchange PowerShell commands to administer Exchange configuration data.

• Windows Management Instrumentation (WMI) Providers are not included in Exchange 2007 or Exchange 2010.

Recommendation: We recommend that you migrate applications that used WMI to use the Exchange PowerShell commands.

Happy Programming!!

Update : Technologies not available with Exchange 2010 & their migration reference(s)

Some development technologies that shipped/available in earlier versions of Exchange Server are not included in Exchange 2010.

The following technologies were removed from Exchange 2007:

• Exchange providers for Windows Management Instrumentation (WMI)
• Collaboration Data Objects for Exchange Management (CDOEXM)
• Collaboration Data Objects for Exchange Workflow (CDOWF)
• Exchange Web Forms
• At Functions
• DAPI.DLL

The following technologies were removed from Exchange 2010:

• Exchange OLE DB Provider (ExOLEDB)
• Exchange store Event Sinks
• World Wide Web Distributed Authoring and Versioning (WebDAV)
• CDO 3.0 (CDOEx)
• Item-level permissions
• Exchange Store custom item types

These technologies are not documented in the Exchange 2010 Web Services SDK. Any references to these technologies in the documentation are in error.

For migration information, you can refer the Guide to Exchange Server 2010 Development Technologies.

CDOEXM & C#.Net : How to mail-disable public folders in Exchange Server 2003 SP2 – Native Mode?

I created this code snippet, which helps us to mail-disable in the Exchange Server 2003 SP2 (Native mode) – public folders. For this i tried this, i used C#.Net & CDOEXM. In this below code, i try to mail-disable the public folder named “publicfolder1”. I used Visual Studio.Net 2008, C#.Net and CDOEXM – Collaboration Data Objects for Exchange Management – 2003 to do this:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using CDO;

using CDOEXM;

using System.Collections; 

namespace MailDisableCSharp

{

    class Program

    {

        static void Main(string[] args)

        { 

            try

            {

                CDO.Folder objFolder = new CDO.Folder();

                CDOEXM.IMailRecipient objRecip;

                string fullurl;

                fullurl = "http://domain/public/publicfolder1";

                objFolder.DataSource.Open(

                                fullurl,

                                null,

                                ADODB.ConnectModeEnum.adModeReadWrite,

                                ADODB.RecordCreateOptionsEnum.adFailIfNotExists,

                                ADODB.RecordOpenOptionsEnum.adOpenExecuteCommand,

                                "Administrator",

                                "Password"); 

                objRecip = (CDOEXM.IMailRecipient)objFolder;

                objRecip.MailDisable();

                objFolder.DataSource.Save();

                Console.Write("Success");

             }

            catch (Exception e1)

            {

                Console.WriteLine(e1.Message);

           } 

        }

    }

}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Note:

+ To execute this code, you may try with VS.Net 2005 or VS.Net 2008, C#.Net.

+ Make sure you need to use the following references: CDOEXM – Microsoft CDO for Exchange Management 2000 & CDOEX – Microsoft CDO for Exchange 2000.

+ This code helps us to mail-disable the public folder “public folder1”.

+ Also we need to make sure to pass valid credentials username(Administrator) & password(Password) to execute this, along with valid fullURL – the public folder needs to be mail-disabled & domain – exchange domain.

Hope this helps. Happy programming!!

Migrating CDOEXM based custom applications

As you know Collaboration Data Objects for Exchange Management or CDOEXM is used to create applications that manage Exchange servers, databases, public folders, and user mailboxes. It provides the fundamental Component Object Model (COM) classes and interfaces that are used to manage the Exchange store.

From Exchange 2007 onwards…

From Exchange Server 2007 onwards you can’t use the CDOEXM functionalities, because Exchange Server 2007 doesn’t include CDOEXM i.e., CDOEXM does not ship in and is not supported by Microsoft Exchange Server 2007. CDOEXM that runs on Exchange 2000 Server or Exchange Server 2003 computers cannot be used to manage computers that are running Exchange 2007.

So what will happen to my existing application which uses CDOEXM…any replacement in Exchange Server 2007?

Well, in Exchange Server 2007 onwards you can use Microsoft Exchange Management Shell (EMS) commands that work with Exchange replace CDOEXM in Exchange 2007. It is easy to migrate applications that use CDOEXM to Windows PowerShell commands. The Windows PowerShell commands that control Exchange 2007 servers, storage groups, databases, and users are simpler to use than the corresponding CDOEXM APIs; but it won’t be a straight forward migration though…

You will have to redesign applications that were created by using CDOEXM to use Exchange Management Shell. Consider redesigning custom applications as early as possible, as starting from Exchange 2007 and its future versions of Microsoft Exchange not contain the CDOEXM API.

Test and troubleshooting tools for various Exchange technologies

I tried to compose the test and troubleshooting tools for various exchange technologies. This initial list upto Exchange Server 2003. 

 

Technology	Tools for test and troubleshooting tools
Active Directory Services Interfaces (ADSI)	All standard test and debugging tools, as well as other Microsoft and third-party test and debugging tools, can be used.
Collaboration Data Objects for Windows 2000 (CDOSYS)	No special debugging tools are needed to debug applications that use CDOSYS.
CDOSYS SMTP/NNTP Event Sinks	No special debugging tools are needed to debug applications that use CDOSYS. For particularly difficult protocol-interaction issues, a network monitoring utility may prove helpful, but is typically not required.
Collaboration Data Objects for Exchange 2000 Server (CDOEX)	No special debugging tools are needed to debug applications that use CDOEX.
Collaboration Data Objects for Exchange Management (CDOEXM)	No special debugging tools are needed to debug applications that use CDOEXM.
Collaboration Data Objects for Exchange Workflow (CDOWF)	No special debugging tools are needed to debug applications that use CDOWF. Custom applications might be created to analyze the process audit logs created during process execution. If you are using the Workflow Designer for Exchange 2000 Server, enable Just-In-Time (JIT) script debugging. JIT starts the Microsoft Script Debugger when the error occurs. The debugger starts on the server, so you need to have access to the server.
Exchange OLE DB Provider (ExOLEDB)	No special debugging tools are needed to debug applications that use ExOLEDB.
Exchange Store Event Sinks	No special debugging tools are needed to debug applications that use Exchange store event sinks.
Exchange Web Forms	No special debugging tools are needed to debug applications that use Exchange Web forms. Note, however, that because the forms execute on the computer running Microsoft Exchange Server 2003, debugging may require the developer have access to the Exchange server. Always use caution when allowing anyone direct access to the Exchange server.
HTTP/Web Distributed Authoring and Versioning (WebDAV)	No special debugging tools are required to debug applications that use WebDAV. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful. The NETMON.EXE tool can be very useful in debugging WebDAV protocol interactions. Because WebDAV queries are sometimes sensitive to minor syntactical differences, a WebDAV query tool can also be helpful.
WebDAV Notifications	No special debugging tools are needed to debug applications that use WebDAV Notifications. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful, but is typically not required.
Incremental Change Synchronization (ICS)	No special debugging tools are needed to debug applications that use ICS.
Lightweight Directory Access Protocol (LDAP)	No special debugging tools are needed to debug applications that use LDAP. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful, but is typically not required.
Messaging Application Programming Interface (MAPI)	No special debugging tools are needed to debug applications that use MAPI.
Outlook Object Model (OOM)	No special debugging tools are needed to use OOM.
Outlook Web Access	No tools are available for debugging calls to Microsoft Outlook® Web Access, because the internal architecture is not available for debugging, and the URL calls required to access Outlook Web Access programmatically are not documented or supported.
Exchange Rules	No special debugging tools are needed to debug applications that use Exchange rules. Client-side rules require Outlook for proper testing.
SMTP Event Sinks	No special debugging tools are needed to debug applications that use SMTP event sinks. For particularly difficult protocol-interaction issues, a network monitoring tool may prove helpful, but is typically not required.
Windows Management Instrumentation providers for Exchange (WMI)	No special tools are required to debug applications that use WMI.
Exchange Backup & Restore API	No special tools are required to debug applications that use the Exchange Backup and Restore API.
Exchange writer for the Windows Volume Shadow Copy Service	No special tools are required to debug applications that use the Windows Volume Shadow Copy Service.

API’s that are not included in Exchange Server 2007 ?

When you migrated from Microsoft Exchange 2000 & 2003, where they provide several API’s that are not included in Microsoft Exchange Server 2007. Please find the following API’s that are not included in the Exchange Server 2007 environment & the recommended technologies to migrate to.

APIs that are not included in Exchange 2007

API	Status in Exchange 2007	Replacement Technology
CDOEX	De-emphasized but still supported.	Exchange Web Services
CDOEXM	Not included in Exchange 2007.	Microsoft Windows PowerShell and Exchange 2007 commands
CDOWF	Not included in Exchange 2007.	Windows Workflow Foundation (WWF) and Microsoft BizTalk Server 2006
EXOLEDB	De-emphasized but still supported.	Exchange Web Services
MAPI	De-emphasized but still supported.	Exchange Web Services
Public Folders	De-emphasized but still supported.	Exchange Web Services
Store Events	De-emphasized but still supported.	Exchange Web Services
WebDAV	De-emphasized but still supported.	Exchange Web Services
Web Forms	Not included in Exchange 2007.	ASP.NET
WMI Providers	Not included in Exchange 2007.	Windows PowerShell and Exchange Server 2007 commands.

 

Nutshell: CDO 1.21 not supported in .Net environment

Per the Microsoft support policy specified in the following KB, CDO 1.21 is not supported in a .NET Framework environment.

Instead it recommends, to make use one of the following technologies to build the .NET Framework application, the supported options for accessing Exchange data are:

• WebDAV

• CDO for Exchange 2000 Server (CDOEX) and  ExOLEDB through an interop assembly.

• Windows Management Instrumentation (WMI).

• Collaboration Data Objects for Exchange Management (CDOEXM)

Many of the messaging developers asked us the question, why it’s not supported under the .Net environment. With regards to the issue, please find the detailed article by Mstehle.

Also find the one more related article where many messaging professionals gets confused what does “unsupported” mean? by pcreehan.

KB : Where to get the CDO libraries for all the versions?

As you know that the Collaboration Data Objects (all versions) Libraries are used to implement Messaging and Collaboration functionality into a custom application.

Please find this article contains information on where these libraries can be found. http://support.microsoft.com/kb/171440

MAPI : Do you know why MAPI is not suitable for HTML messages?

Do you know why MAPI is not suitable for HTML messages?

 

MAPI 1.0 was written before HTML mail was developed and does not reliably support the creation of HTML-formatted messages. As you know, MAPI 1.0 is the version supported by all versions of Microsoft Exchange through version 5.5 (and all Service Packs). This includes the following subordinate technologies:

•Simple MAPI
•Extended MAPI
•OLE Messaging
•Active Messaging (Collaboration Data Objects (CDO) 1.1)
•CDO versions 1.2 and 1.21
•MAPI controls (Msmapi32.ocx)

Extended Messaging Application Programming Interface (MAPI) should not be used to generate HTML-formatted messages.

What is needed?

If messages are needed in HTML format, such as for sending text formatted in other languages, alternative technologies that provide more reliable support for HTML messages are recommended:

•CDONTS
•CDO for Windows 2000 (CDOSYS)
•CDO for Exchange 2000 (CDOEX)
•Outlook Object Model of Microsoft Outlook 98 or later
•SMTP-capable ActiveX controls obtained from third-party vendors

In short, as an alternative, we should consider using the Microsoft Outlook Object Model, CDONTS, CDOSYS, CDOEX, or a third-party SMTP control.

Exchange Server – Technologies – FAQ

Exchange Server – Frequently Asked Questions 

When we do Exchange programming with client and server versions of the Exchange Server Providers, MAPI32, EMSMDB, EMSABP and MSPST32 almost or always causes confusion. In this article, we’ll discuss about the common terminologies: 

What is MAPI? 

MAPI will generally mean MAPI32.dll, or the APIs contained. It’s an API, implemented largely in MAPI32.dll (Messaging Application Programming Interface, 32 bit build). By using this, developers implement a series of Providers. Providers come in three major types, Transport Providers, Message Store Providers, and Address Book Providers. Providers are DLLs that implement a specific pseudo COM API, such as IMessageStore, and the underlying required interfaces, such as IMAPIProp.

Then, what is a MAPI Application?
It means any application that uses the MAPI calls. MAPI applications work against sets of data sources grouped into Profiles. Profiles are created, saved, and deleted by the Profile Provider. The Profile Provider is implemented in MAPI32.dll in two forms:

• The temporary profile provider, which stores profile data in temp files.
  
• The normal profile provider, which stores profile data in the registry.

An empty profile gives a MAPI application no data access, so MAPI applications add Providers (also called Services) to the profile. A common thing for MAPI applications to do is add services for EMSMDB and EMSABP to a profile, granting the ability to access data from Exchange Server. Providers do all of the actual work in MAPI. When you submit a message, although the call might pass through MAPI32, it is EMSMDB (or your provider) that does the actual work for sending. When saving a message, it is not MAPI32 that saved the message; it’s the message store provider (usually EMSMDB for Exchange Server). When you resolve a recipient, it is not MAPI32 that searches for the user in the address book. It is the Address Book Provider, implementing the IAddrBook interface (probably EMSABP). 

What do you meant by CDO or Colloboration Data Objects?  Does CDONTS, CDOSRV, CDOSYS, CDOEX, EXCDO, or CDOEXM all are same jargons?

Collaboration Data Objects (CDO) refers to CDO.DLL, not CDONTS, CDOSRV, CDOSYS, CDOEX, EXCDO, or CDOEXM. CDO and Outlook are both MAPI applications, meaning that they use MAPI APIs to access their data and, therefore, the underlying providers. CDO and Outlook share a common set of Properties that, when taken together, define different classes of messages and different functionality. This works similar to the schema in a database; however, MAPI32 does not implement the storage. The Message Store Provider does. In the case of Exchange Server, this provider is EMSMDB, and Exchange Server is mostly agnostic about the semantics of the data that applications choose to store. Exchange Server 5.5 has almost no knowledge of individual named property meanings. Exchange 2000 Server and Exchange Server 2003 are considerably more aware of the significance of particular named properties on different message classes, in particular, calendar items. This logic is implemented in EXOLEDB and EXCDO. In general, it is up to users of a particular set of properties to agree on what those properties mean and how they are manipulated.

CDO implements an API to manipulate sets of properties together to accomplish tasks, such as scheduling a meeting. Outlook also implements APIs to manipulate sets of properties, and does presentation of that data to the end user. If CDO and Outlook don’t agree on what particular properties mean, or on the mechanisms used to control processing logic (for instance, when an appointment has been updated), potential for problems interoperating between Outlook and CDO exist. Although Outlook continues to be updated and expanded with every version, CDO.dll is more or less static at the same level of functionality it has possessed for years. Newer libraries for manipulating calendar data, such as CDOEX, are considerably more up to date.

What do you meant by EMSMDB or EMSMDB32 or Exchange Transport Provider? 

EMSMDB refers to the Exchange transport provider, EMSMDB32. One example of a provider is EMSMDB2, the “Electronic Messaging System Microsoft Data Base, 32 bit build” provider. EMSMDB implements both a transport and a message store and, as such, is a dual provider.
The transport is the ability to submit messages to Exchange Server; the message store is the ability to read (and possible write) messages to an Exchange store process.

What do you meant by EMSABP or EMSABP32 or Exchange Address Book provider? 

EMSABP refers to the Exchange address book provider, EMSABP32. The other common provider involved with Exchange Server is EMSABP, which is an Address Book Provider (Electronic Messaging System Address Book Provider, 32 bit build). EMSABP implements IAddrBook and allows access to the Exchange global address list through Name Service Provider Interface (NSPI).