Exchange admins tend to come in one of two varieties. Some come to Exchange Server with messaging experience outside of Microsoft's ecosystem, and then there are the folks who were "born and raised" with Microsoft and aren't as familiar with what lies outside.
I've found members of the first group better versed in PHP, Perl and Python. They are also more interested in accessing Exchange message stores through these languages. There are a couple reasons for this:
- These IT pros can create a custom interface to Exchange Server that only runs on non-Microsoft hardware.
- They might be working on getting something else that runs outside the Microsoft ecosystem to read Exchange mail stores.
WebDAV is no longer supported in Exchange 2010; the new
Let's look at how these three languages can speak to Microsoft Exchange.
Using PHP with Exchange Server
Hypertext preprocessor, more commonly known as PHP, is easily the Web's most ubiquitous programming language. This is largely because it is easy to use, and scripters can write programs with it. However, it's also rife with inconsistencies, security problems, and backward-compatibility gotchas. Among its architectural flaws is a lack of support for Unicode, although Version 6 will allegedly fix this once and for all.
Despite these issues, PHP remains widely used and deeply entrenched, which is why admins may want to use PHP to access Microsoft Exchange Server. I have found a few ways to do that.
Blogger Troy Wolf approached the problem of using PHP to access Exchange via WebDAV by creating a couple of PHP class files (class_http and class_xml) to do most of the heavy lifting. Administrators can use the two classes to "screen-scrape" the results from an OWA session.
Wolf has not updated the code in a while, but in a more recent project, James Armes has been working on implementing a robust range of Exchange Web Services functionality -- including Exchange 2007 and Exchange 2010 -- via PHP 5.2 or higher. For a more advanced look at working with EWS, Erik Cederstrand provides some code that is a helpful starting point.
Using Python with Exchange Server
Python has gained popularity because of its readable code and efficiency. It's extremely easy to use, even for beginners. Python isn't as ubiquitous as PHP, but its breadth of powerful implementations -- such as IronPython, which integrates Python closely with .NET -- makes it worthy of attention, especially on Windows.
Weboutlook is a Python library that screen-scrapes email from Outlook Web Access (OWA), but it doesn't access other Exchange resources like calendars. A fork of the project has been created for future improvement, but you may be better off with something that uses EWS, such as this example from Alexander Dutton.
There is also a Python library that allows admins to perform management functions in Exchange. Note that it must run directly on the Exchange server itself.
Using Perl with Exchange Server
Perl's usefulness is thanks to the rich culture of third-party libraries written for the language. They are maintained in a central repository. Perl is particularly attractive because the two major programs that talk to Exchange are kept up to date (they work with Exchange 2010 via EWS).
The first program is Email-Folder-Exchange-2.0. It allows access to Exchange email (including all versions from Exchange 2000 through Exchange 2010) via Perl and includes two libraries:
You can use either library to access Exchange, depending on your needs.
As antiquated as WebDAV is, it's still extremely useful in plenty of environments, so it's handy to have both libraries.
A second program, EWS-Client-1.113000, allows access to calendar entries and contracts via EWS.
Note: If you simply want to send email through Exchange, you can do that without excessive overhead via Perl. Also, if you want to use a generic Lightweight Directory Access Protocol (LDAP) interface to Exchange, a generic LDAP module is actively being developed for Perl.
Final thoughts on using PHP, Perl and Python
In the past, the only way to talk to Exchange message stores outside of Microsoft's own technology was through screen-scraping or something similar. This proved to be a messy and potentially brittle method. With the advent of EWS, it's now easier for programmers who want to talk to late-model versions of Exchange and gather the information they need without resorting to such tricks.
Support for these and other languages in future versions of Exchange Server should make it easier to access Exchange from the non-Microsoft world.
ABOUT THE AUTHOR:
Serdar Yegulalp has been writing about personal computing and IT for more than 15 years for a variety of publications, including (among others) Windows Magazine, InformationWeek and the TechTarget family of sites.
This was first published in September 2012