I'm writing a CMS application in PHP and one of the requirements is that it must be able to interface with the customer's Exchange server. I've written up this functionality a few times before and have always used WebDAV to do it, but now I'm leaning away from that.

I will be running the site on IIS OR Apache (no preference) on Windows server 2008. A few things I would need to do include adding contacts to a given user's address book, sending emails as a given user and running reports on contacts for a user.

All of this is pretty easy to do with WebDAV, but if there is a better way that doesn't require any functionality that is likely to be deprecated any time soon.

Any ideas?


Justin, I love the idea of using com objects, I just worry about maintaining a 3rd product to make everything work...

John, I can write a web service in C# to interface with for these functions and access it with my PHP app, but it's also a little bit out of the way.

So far, I'm not 100% convinced that either of these is better than WebDAV... Can anyone show me where I'm being silly?

Thanks, both of you.

+2  A: 

I'm not a PHP dev but Google says that PHP 5+ can instantiate COM components. If you can install Outlook on a box you could write a PHP web service around the COM component to handle the requests you need.

$outlook = COM("Outlook.Application")

Outlook API referance

Justin Walgran
Spelled reference wrong.
+3  A: 

I have not used PHP to do this but have experience in using C# to achieve the same thing.

The Outlook API is a way of automating Outlook rather than connecting to Exchange directly. I have previously taken this approach in a C# application and it does work although can be buggy.

If you wish to connect directly to the Exchange server you will need to research extended MAPI.

In the past I used this wrapper

It is a C# project but I believe you can use some .NET code on a PHP5 Windows server. Alternatively it has a C++ core DLL that you may be a able to use. I have found it to be very good and there are some good example applications.


Sorry for the delay no current way to keep track of posts yet.

I do agree adding more layer on to your application and relying on 3rd party code can be scary (and rightfully so.)

Today I read another interesting post tagged up as MAPI that is on a different subject. The key thing here though is that it has linked to this important MS article. I have been unaware of the issues until now on using managed code to interface to MAPI although the C++ code in the component should be unaffected by this error as it is unmanaged.

This blog entry also suggests other ways to connect to MAPI/Exchange server. In this case due to these new facts may be the answer as suggested by the other user.

+1  A: 

I would look into IMAP

Tim Boland
+6  A: 

Is your customer using Exchange 2007? If so, I'd have a look at Exchange Web Services. If not, as hairy as it can be, I think WebDAV is your best bet.

Personally I don't like using the Outlook.Application COM object route, as its security prompts ("An application is attempting to access your contacts. Allow this?", etc.) can cause problems on a server. I also think it would be difficult to accomplish your impersonation-like tasks using Outlook, such as sending mail as a given user.

Mike Powell
+1  A: 

I can't recommend Dmitry Streblechenko's Redemption Data Objects library highly enough. It's a COM component that provides a sane API to Extended MAPI and is a joy to use. The Exchange API goalposts move from one release to the next: “Use the M: drive! No, use WebDAV! No, use ExOLEDB!… No, use Web Services!” with the only constant being good old MAPI.

Duncan Smart
+2  A: 

Don't use Outlook COM APIs. They are not designed to run in a server environment.