New Programmability Features in Exchange Server 2007
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
Topic Last Modified: 2007-07-26
By Thom Randolph, Content Publishing Manager
A new, major release of Exchange is coming in early December, bringing many new features that make e-mail even more essential to business. Microsoft® Exchange Server 2007 offers built-in protective technologies to keep business moving, reduces spam and viruses, and enables confidential communication. With Exchange 2007, employees get anywhere access to their e-mail, voice mail, calendars, and contacts from a variety of clients and devices. Exchange 2007 enhances operational efficiency through features like the Exchange Management Shell, based on the new Microsoft Windows PowerShell.
These features definitely make Exchange 2007 the best version of Exchange for information workers and the IT Professionals who manage those servers. But what about us developers? Yes, we get some shiny new toys to play with too! Exchange 2007 includes new technologies that enable custom applications to go further and connect wider—something that was just not possible in Exchange Server 2003. This article describes some—but not all—of the new programmability features and offers pointers for getting started with them.
What Types of Applications Do People Make for Exchange?
Custom applications that work with Exchange have traditionally been grouped into three categories, based on what they do: manage servers and recipients, work with mailbox-based content, and customize mail flow. Exchange 2007 provides some great improvements for each application type.
Managing Servers and Recipients in Exchange 2007
Exchange 2000 Server and Exchange Server 2003 include the Collaboration Data Objects for Exchange Management (CDOEXM) for directly configuring things like Exchange mailbox and public folders, storage groups and databases, mailboxes, and addresses. CDOEXM has to be run on either an Exchange server or a computer on which the Administrative Tools are installed. Even with CDOEXM, some settings in Exchange Server 2003 had to be done through Active Directory Services Interface (ADSI), and yet other settings made their way to Internet Information Services (IIS) by way of the Metabase Update Service. CDOEXM is a COM API and isn’t supported in managed applications, making it very difficult to take advantage of the latest Microsoft Visual Studio® development environment and the Microsoft .NET Framework.
Exchange 2007 replaces CDOEXM with an enhanced version of the Windows PowerShell. There are Exchange Management Shell commands for virtually every configuration setting that is available in Exchange 2007, so you no longer have to deal with multiple APIs. In fact, you can do more with the management shell than you can in the management GUI. And, you can call Windows PowerShell commands from .NET-managed applications. All the Exchange commands were written by using the .NET Framework 2.0, so they are compatible with current technologies, greatly improving your development and debugging experience.
The Windows PowerShell is also a great scripting environment. Finally you get object-oriented features in a command-line environment that’s part of the Microsoft Windows Server® operating system. What this means for developers is that many, if not most, of the day-to-day tools you’ve had to write as compiled applications for Exchange administrators can be done as scripts. If you’ve ever had to write a 50-line routine by using CDOEXM, crafting a two-line script to do the same thing will bring tears of joy to your eyes. Really.
Because the Exchange Management Shell is so powerful, and because of the limitations of CDOEXM, Exchange 2007 doesn’t include CDOEXM. Also, don’t try to use a CDOEXM application against an Exchange 2007 server.
Exchange Server 2003 also includes a large set of Windows Management Instrumentation (WMI) objects, enabling a wide range of health-monitoring applications. These functions have been removed and replaced by management shell commands. Now, all Exchange 2007 server and recipient management is performed by using one command-line interactive, scriptable, .NET-compatible API.
Working with Your Inbox
It’s difficult to even grasp the number of ways you can access your mailbox with Exchange Server 2003. If you can get an administrator to let you install code on the server, you can use Collaborative Data Objects for Exchange (CDOEX), or the OLE DB provider for Exchange (EXOLEDB). You can use the Outlook Object Model (OOM) from the desktop, but not on the server. You can use WebDAV from anywhere, if it was enabled and available through your company’s firewalls. You can use MAPI too, if you were a strong programmer and liked C/C++. But only WebDAV is directly supported in .NET managed code. Many of the other development technologies are only supported by using a COM interop assembly. And the only way to deal with Microsoft Office Outlook® tasks is through OOM.
Welcome to the new world, my friends. Exchange 2007 will make you stand up and cheer. Yes, cheer. Right there in your cubicle. Exchange Web Services is here to put a stop to all that API confusion and difficulty. Your administrator won’t let you install code on the Exchange server? Then don’t run it on the Exchange server. Need to write applications that run on non-Microsoft platforms or languages? You can do that with Exchange Web Services. Want to work with Tasks as well as Contacts and messages and calendar items? You can do that too. Want your application to work from the Internet as it does inside the network? Want to write applications that receive notifications from the server instead of having to constantly poll for status? Want to have Exchange figure out FOR YOU which mailbox server the user should connect to? Want easier access to user’s free/busy information? Yes, the new Web services were built with you in mind.
The new Web services that ship in Exchange 2007 are provided in two minor parts (Autodiscover and Unified Messaging), and one big part (Exchange Web Services, or EWS).
The Autodiscover Web service is extremely important if your application will have to get information from anything but the smallest Exchange deployments. Indeed, we recommend always using the Autodiscover Web service. By supplying the user’s e-mail address to a standardized URL within your organization or Internet domain, the Autodiscover service returns the URLs to servers that your application should use to access that user’s mailbox. One simple call, choose the proper URL, and your application can get to the right server for that user. Almost TOO easy.
Exchange 2007 has many features that are intended to solidly combine e-mail with voice mail and mobile devices. One key feature of this enables the Exchange server to play a voice mail message that is stored in your mailbox on your phone. The Unified Messaging Web service enables your client application to read and change the settings for the play-on-phone features, and to initiate a phone call to do that.
But, the largest and most powerful Web service in Exchange 2007 is Exchange Web Services. Developers should use this API whenever possible. Migrate your applications to it, and definitely build them on it if at all possible. It doesn’t have to be run on the Exchange server; it’s possible to access it from the Internet, and you can access the new organizational folders. And yes, you can finally manage Tasks!
One part of Exchange Web Services that your applications may have been screaming for is notifications. By using Exchange Web Services you can subscribe as either a push- or a pull-client. If you’re using the pull method, your application can poll Exchange and get the list of changes that have occurred in the subscribed folder. To use push notifications, your application implements and registers a small Web service, and Exchange calls it when necessary.
EWS is poised to become the favored way to get to mailbox data for the future, so if you’re not up on programming for Web services, now’s the time to learn. The RTM SDK will provide lots of information to get you started. As always, be sure to tell us where we can improve both the documentation and the APIs.
If Web services won’t do what you need, there’s still MAPI and the older COM-based APIs. But, those might be gone in the next major version of Exchange, so don’t expect them to be around forever. No final decisions have been made, but programming against COM interfaces that can’t even be used under managed code is going the way of Windows 95.
Customizing Mail Flow
The third type of application is one that has to work on messages while they’re being moved or stored. In Exchange 2000 Server and Exchange Server 2003, applications register protocol event sinks and store event sinks that are called when the appropriate event occurs. You can attach events to the protocol handler to do things like address rewriting, checking, or even spam filtering. Store event sinks can be registered on mailboxes and folders, and are sometimes used for simple workflow processing. Of course, both protocol and store event sinks in Exchange Server 2003 run on the Exchange server.
Things have changed a lot for the protocol servers. Because Exchange 2007 has a completely new protocol stack and mail-flow processing system, a new way of working with events was required. The new term is “agent”, replacing “event sink” on the protocol side. Agents are typically small chunks of code that are called when a message is coming into the Edge Transport or Hub Transport server role. Like event sinks, agents should be small because they need to be fast. But, in Exchange 2007, you can write them by using the CLR and the .NET Framework. Yes, managed code!
Inside the runtime environment, the agent uses the Microsoft.Exchange.Data.Transport .NET namespace for full and easy access to all information about the message envelope, headers, body content, attachments, MIME stream, everything. There’s even an object model for accessing and working with the message recipients. No more figuring out how to safely call CDO to get to the message parts. Now it’s all wrapped up in a robust and feature-filled .NET object model.
It’s much easier to register and deploy your agents too. You can register and install a new agent with just a few Exchange Management Shell commands. You can even give your administrator a script that will install it for her. Just remember: the agents still run on the Exchange server.
We recommend moving all your event-based applications to use the new agents. They’re easier to program, control, monitor, and debug. But what about store event sinks? Some of you might still remember the problem of MAPI-submitted messages bypassing the protocol event sinks. Though store event sinks could do some interesting things, the MAPI “problem” was really the only case when you HAD to use them. Well, all transport inside Exchange 2007 is now SMTP-based, so there’s really no strong need for store event sinks. Yes, they’re still there, and you can still use them, if you can get your custom code installed on the mailbox servers. But, like the other COM-based interfaces, the next major Exchange version might not have them at all.
Parsing and Converting Message Content
Over the years, we’ve had many people ask us to allow their custom applications to use the MIME parser that Exchange uses. Although third-party MIME parsers are available, and the MIME RFCs have been out there for a good long time, there always seemed to be subtle differences in how the different MIME parsers worked. Exchange 2007 goes a long way toward solving that dilemma. In Exchange 2007, customized applications can use the same MIME parser that the server uses.
What would a MIME parser be without the ability to convert the various text formats that are handled by Exchange? In Exchange 2007, we’re also making it easier for custom application developers to access message content by using the same text converters that are used in Exchange. The MIME parser and the text converters are all written in managed code by using the .NET Framework 2.0. By using these classes, you can convert between HTML, plain text, RTF, and enriched text.
APIs that Got Left Behind
Sad to say, sometimes it’s best to just let old things go away. And so it is with Exchange 2007: some of the older, less-used, not-state-of-the-art APIs weren’t carried forward. But, that doesn’t mean you’re out in the cold. For every API that went away, a better, more-modern API is available in the Windows operating system.
For example, the workflow engine and CDO for Exchange Workflow (CDOWF) are not shipped in Exchange 2007. If you can’t keep an Exchange Server 2003 box around to support those applications, your best bet is to migrate to Windows Workflow Foundation. The programming model is more up-to-date, and the technology is part of the Windows platform. CDOWF can’t be used in managed code, but as you’d expect, Windows Workflow Foundation can.
Similarly, Exchange Web Forms were not carried forward into Exchange 2007. If you need that type of functionality, go with ASP.NET. The ASP applications should pull the data from the Exchange servers, and display it for the Web-based client.
Another change coming from the march toward progress was the 32-bit MAPI client and CDO 1.2.1. Instead of shipping those with the Exchange server, they’re now available for download.
One very important thing to remember is that the Exchange 2007 APIs are not redistributable, nor are the MAPI and CDO downloads. You can’t just package them with your application and ship it. A valid license is required on all computers where the APIs are used.
Get Out There and Program!
Between the new Windows PowerShell, Exchange Web Services, transport agents, the MIME parser, and text converters, Exchange 2007 includes many new technologies to enhance even your own custom applications.