Exchange Server 2013 : Extending Exchange - Accessing Exchange Programmatically

We will examine how you can use the development interfaces provided by Exchange 2013 to meet the business requirements that you may have for your email system that can't be solved with the standard out-of-the box features of the product. First, we will cover the interfaces that are available to create applications, scripts, and add-ins in Exchange 2013, and then we will cover how you can go about writing application code.

As with many other Microsoft products, Exchange 2013 comes with a rich array of development interfaces that allow you to extend and customize the functionality of the product. For IT professionals, it can be confusing trying to decide when you should consider using these development interfaces, and the very mention of writing code can send some scurrying for cover. However, if you really want to add value to your Exchange Server organization, even some simple PowerShell scripts can save you a lot of money on third-party software and give you a rapid return on investment.

A major reason why you may find yourself turning to the development interfaces occurs when you try to fulfill a request for functionality that cannot be provided using the standard features of the product. Also, those who are managing very large Exchange environments can benefit greatly from the ability to write custom reports for otherwise standard requests, such as mailbox usage, message tracking, or the ability to configure certain mailbox features and settings automatically. Automation of these types of tasks can greatly reduce the number of man-hours required to manage a complex environment while simultaneously making your end users more productive. Another instance when you may want to look at the development interfaces occurs when you have a great idea and need to create a new and innovative client application.

Where do you start and what can you do? As soon as you mention development, many IT professionals think of off-the-shelf product applications. While this is one part of the development ecosystem, the Exchange development space also involves other, more home-brew-type projects. Here are some examples:

• Creating a script to provision new users automatically and configure their mailbox defaults
• Making a script to move data during migrations, or pushing certain data to an archive
• Creating an application that enhances the Outlook and OWA client interfaces
• Creating a transport agent that performs custom routing of emails
• Creating an application to process inbound messages automatically
• Performing custom discoveries of information stored in mailboxes and public folders

Many of these tasks can be performed with a minimal amount of code and development skills, so they are not out of reach for most IT professionals willing to stretch themselves a bit. In the end, any code or script you create is just a list of instructions that you're asking the server to perform on your behalf. What takes time is working out the order and logic of those instructions and then reading the results. While this process can be time consuming, the reward of increased agility in problem solving and the rapid return on investment are well worth it.

Exchange 2013 builds on the existing development interfaces introduced in previous versions of Exchange to provide a richer development experience, particularly focused on using standard Internet protocols such as HTTPS. As already mentioned, EWS has been promoted to the primary API for developing applications that run against an Exchange mailbox in Exchange 2013. EWS uses SOAP (XML) to provide the standard message format for the exchange of information between the Exchange Server and your application client.

While the Outlook client still primarily uses MAPI to access the Exchange store (albeit tunneled through RPC over HTTPS), new Exchange 2013 features, such as in-place eDiscovery and mail apps, use EWS as the endpoint for accessing Exchange.

Where Do I Start?

If you have made the decision to write some Exchange code but you're not a developer, just where to begin can be a little confusing. The first question to ask if you want to do something simple is, “Can I write a PowerShell script that uses EWS to accomplish the tasks I want to perform?” PowerShell scripts require a minimum of investment, and they can be written in a text editor like Notepad or a visual IDE, such as the PowerShell IDE or PowerGUI. Such visual scripting IDEs simplify the process of creating scripts, and they also allow the use of code snippets, which can save you a lot of time. Code snippets are partial or fully formed code blocks that you can copy and paste into your own application code or script. These can greatly reduce the amount of time it takes to prototype an application or script. The next step up from writing a simple script is creating a .NET application. For this, you will need Visual Studio. If you are a first-time developer, Microsoft provides a free version of Visual Studio called Visual Studio Express that you can use to build .NET applications.

Taking EWS for a Test Drive without Writing Any Code

If you are still not sure about EWS and what you can access using it, there is a great tool produced by Matt Stehle, a Microsoft senior application development manager. The tool is called the EWSEditor, and you can download it at http://ewseditor.codeplex.com/. With this simple GUI application, you can execute most of the EWS operations without needing to write any code, as well as view the syntax used in the requests and responses that may be important if you are building code that uses raw SOAP.

How Do You Connect Your Code to Exchange?

All EWS operations are executed through a Client Access Server (CAS) in your Exchange organization. On each CAS, there is a virtual directory in IIS that points to the underlying EWS files, such as exchange.asmx and service.wsdl, which we will discuss later. To allow any piece of EWS code to post requests to Exchange, you need to specify the URL path to the EWS exchange.asmx file. The URL that you would use within your code to connect to Exchange is usually determined using Autodiscover. The URLs that Autodiscover returns are those that are configured via the Set-WebServicesVirtualDirectory EMS cmdlet. If you need to know the URL to use for EWS and you can't obtain it via Autodiscover, you can find it using the Get-WebServicesVirtualDirectory -Identity EMS cmdlet. For example, review the following code snippet:

Get-WebServicesVirtualDirectory -Identity EWS(Default Web Site)

Where Do You Run Your Code?

One of the big advantages of using EWS is that it's designed to be used over HTTPS. Thus, all the code and scripts you write to use it can be run remotely (where port 443 is available). As a general rule, you should avoid running any code directly on your Exchange Servers—there is little advantage to doing this, and errors in your code or scripts may cause your server to become unreliable. Generally, the default EWS throttling setting within Exchange will offer some protection against errant pieces of code causing problems for your Client Access Servers or Mailbox role servers. If you are planning on doing a lot of development work, it is a good idea to build a virtualized development environment in order to avoid testing your beta code and scripts within your production environment.

Considerations for the Cloud

Exchange organizations can now be configured in a number of different ways that may affect which APIs you can use to access an Exchange mailbox. For example, in any one organization, mailboxes can be located on-premises, in the cloud, or in a mixture of the two. This leads us to consider the following: