The following article details some of the limitations of Exchange Server Event Scripting (available in Exchange 5.5). With the availability of Exchange Event Sinks in Exchange 2000/2003 it is really hard to rationalize continued use of this technology. Especially for mission critical applications...
181036 INFO: Suitable Applications for Exchange Server Event Scripting http://support.microsoft.com/default.aspx?scid=kb;EN-US;181036
Most notable from this article are the following...
"There is no guarantee that a script will see every message."
"The Event Service is single-threaded. No matter how many scripts are registered, only one can run at a time."
"The Scripting Agent is not a safe, general purpose replacement for the Inbox Assistant rules because it allows new code to be installed and run on your servers."
One major consideration between Event Scripts and Event Sinks is that Scripts use CDO 1.21 as their API while Sinks use CDOEX. It is often suprising have minor the code changes can be for simple script migration. CDOEX is a better performing and more robust API, adding to the list of reasons to make the switch.
...NOTE: This is what I refer to as Event Scripts in this article...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexch55/html/msdn_eventscr.asp
...You can create Exchange Event Sinks using VBScript, these scripts wouldn't have the limitations listed above. The KB article below provides a sample event sink script...
http://support.microsoft.com/?kbid=324021
Updated 1/22/2009 – Noted a broken link.
...I added a new category for this post called "KB" which is for noting KB articles that are new or important...
The Outlook Object Model does not provide full access to all the features of the application. The following KB article details some of the limitations of the object model.
294869 Description of limitations in Outlook object modelhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;294869
...This article was written for Outlook 2003's version of the object model. It also provides links to some of the earlier versions of Outlook as well. It is always important to research the limitations of any API you choice to implement a messaging solution. Some of the other office products give you an API which will essentially give you access to everything the UI will. Outlook is not one of them...
...Another point that is not noted in the article is that the Outlook Object Model is only supported for interactive use and not in background processes. This means that OOM code is not supported in server side script in web pages or within a Windows service or COM+ component. If you need to use OOM in a web application it would have to be in client side script and preferrably in an ActiveX Control...
FYI IMO there a lot of TLA's out there these days. Some acronyms get pronounced phonetically like ISAPI ("eye-sap-ee") and MAPI ("map-ee") while others are enunciated simply by reading the letters like ESM ("E-S-M") and NTFS ("N-T-F-S"). Usually the presence of vowels in acronyms or resemblance to an actual word determines this. However there are some cases where a precedent forbids this rule...
Let's look at CDONTS. I humorously use it in the title of this blog as a play on one of the common mispronunciations. Obviously CDO is pronounced by reading the letters ("C-D-O") and CDONTS is known as CDO for NT Server or CDONTS ("C-D-O-N-T-S"). Pronouncing each letter here keeps its association with CDO in tact. Unfortunately CDONTS looks a lot like "C-don'ts" or the most unfortunate pronunciation, "C-donuts"...
As a support professional that is still relatively new to this gig, I recognized CDONTS as "C-D-O-N-T-S". You can imagine my confusion when I got my first "C-DONUTS" case, haha...
Oh and BTW, CDOSYS is half and half of course, just to keep it interesting, "C-D-O-sis"...
A couple days ago I posted a link to upcoming Outlook Object Model changes and new features, I wanted to go back and note that the Exchange team posted about their developer roadmap as well. This post mentions three new ways of interfacing with Exchange in version 12 that you should be really excited about: web services, agent scripts, and the Monad shell. From what I have seen and heard about E12, I can't help but get excited. The Exchange team has done a great job of listening to the community and delivering product features and enhancements that go a long way towards addressing our wish lists as well as things we never knew to ask for.
...I paid particular attention to the following line about web services in E12, "Our new Web Services will offer remotely-accessible Outlook-compatible business logic for all PIM types." Obviously this sentence is intentionally vague but you should be thinking about a remoteable API that would allow access to Outlook item types like Appointments and Contacts. I don't have specifics on which item types will or will not be supported by the E12 web services, you'll have to keep checking with the Exchange team or my blog to get updates in the coming months.
With the new additions there are things that are being de-emphasized and others that will not be available. Note that WebDAV, CDOEX, and EXOLEDB are the three de-emphasized API's. As they suggest agents will replace CDOEX and EXOLEDB for Exchange server eventing, however Event Sinks will still work against E12.
...It is important to understand the support impact of the word "de-emphasized". From my perspective it means that I will support the use of WebDAV, CDOEX, and EXOLEDB against E12 for entire lifecycle of the product, however the product team will not accept design changes or feature enhancements submitted by me on your behalf regarding these API's. It does mean that these API's will have full break/fix support in which the product team will provide with hotfixes and workarounds. It also means that E13+ will most likely not ship support for these API's.
For every new day there is one that has drawn to a close and with that in mind there are a couple existing API's and developer features not continuing to E12. They are listed in the blog post as well. The most common technologies listed here are Web Forms (custom ASP forms in OWA, much like custom forms in Outlook) and CDOWF (Workflow for Exchange apparently will not be supported in E12). The other technologies are less common but I don't doubt that this will impact many of you.
...Most of the technologies listed here that are going away in E12 will have a much better alternative or had some supportability issues to begin with. For example, ExWin32 or the M: drive, isn't considered an API or development technology at all, we don't support doing any development against it in the current versions of Exchange. Web Forms in OWA are almost always better handled through a custom web application or Sharepoint. Workflow application in Exchange can be better served through BizTalk or the new Windows Workflow Foundation...
The Exchange Team's Blog has a great post on how certain time zones with variable daylight time shifting affect Outlook...
...Time zones are an important thing to keep in mind when working with appointments. We get cases sometimes related to preceived bugs in CDO 1.21 or Outlook Object Model were appointments appear to be off their scheduled times. This is more often than not related to one of the time zones mentioned in this post...
WebDAV is a protocol, not an API. It is an extension of HTTP and provides more request methods to allow us to get information out of Exchange and change information within it.
Here are some WebDAV samples on MSDN...
310283 How to retrieve and to modify properties on items by using WebDAV in Visual C# .NET http://support.microsoft.com/default.aspx?scid=kb;EN-US;310283
308373 How to send a meeting request by using WebDAV http://support.microsoft.com/default.aspx?scid=kb;EN-US;308373
296126 How to create, modify, and delete contact items by using WebDAV (PROPPATCH) http://support.microsoft.com/default.aspx?scid=kb;EN-US;296126
We have a lot of technologies at our disposal for Messaging developments so it is always important to be reminded of when to use what technology. Here are some scenarios of when to use WebDAV...
Managed Code and Exchange
If you are writing managed (.NET) code and want to work with data in the Exchange store you will need to know WebDAV. MAPI and CDO 1.21 are NOT supported from managed code as they were not tested or designed to work in that environment. CDOEX is supported in managed code but only when the code runs ON the Exchange that hosts the folders and items you are working with. WebDAV is the only technology that is supported in managed code that will work remotely.
ASP Middle Tier and Kerberos
As I mentioned in a previous post, CDO 1.21 is not supported for use with Kerberos authentication. This means that if you are running an ASP web application that uses integrated authentication to leverage the current user’s credentials to access resources like their Exchange mailbox or a public folder via CDO 1.21 and this application is hosted on a separate IIS box, you will get a MAPI_E_LOGON_FAILED exception. Even though the web application may be running in the context of a user that has access to the Exchange resource, since CDO doesn't support Kerberos there is no mechanism for passing credentials from the IIS server to the Exchange server.
This is where WebDAV comes in. Since WebDAV works simply through HTTP requests and responses you can manage the type of authentication you use at a very granular level. If you are implementing a middle tier web application that accesses Exchange as a backend store, whether you are using ASP.NET or ASP web applications, you need to use WebDAV.
Non-PC Systems Accessing Exchange Data
I recently had a case with a customer implementing a Java web application hosted on Linux that he wanted to integrate with Exchange. Our API's won't help in this scenario because they are all based on COM which I understand is hard if not impossible to get Linux to talk to. WebDAV to the rescue! Since WebDAV is based on HTTP requests and responses and uses XML to communicate any programmer can communicate with Exchange as long as they have some mechanism for sending requests and reading responses.
...When I talk about Outlook Item types I'll come back to some more areas where WebDAV is particularly helpful. Truth be told I used to avoid WebDAV like the plague because it wasn't an API set rather a bunch of XML communication back and forth. However, I've gotten over my initial fears and become more and more a fan of WebDAV every time I use it...
...Here is some of the standard information I send out to customers when they are getting started with WebDAV...
MSDN WebDAV Reference
http://msdn.microsoft.com/en-us/library/aa486282(EXCHG.65).aspx
This is a general introduction/reference for WebDAV in Exchange
Properties by Namespace
http://msdn.microsoft.com/en-us/library/aa581579.aspx
Searching Exchange with WebDAV is all about finding the right property and namespace. Here is a list of properties organized by namespace. Use Exchange Explorer (see below) to identify which properties are available on items.
Searching Folders with WebDAV
http://msdn.microsoft.com/en-us/library/aa123571.aspx
These articles give details on searching Exchange with WebDAV.
SQL in the Exchange Store
http://msdn.microsoft.com/en-us/library/aa123647(EXCHG.65).aspx
This article details the SQL commands available with WebDAV against Exchange and what they do.
Exchange Explorer Download
http://www.microsoft.com/downloads/details.aspx?FamilyID=4AFE3504-C209-4A73-AC5D-FF2A4A3B48B7&displaylang=en
Exchange Explorer is a very helpful tool to view properties on items and folders. It displays the full name of the properties available on an item along with their values.
Update 1-20-2006: Adding some more links here that are quite relevant...
Be sure to check out my post related to Exchange Store Event Sink programming that covers CDOEX. It talks in depth about the Exchange store and relates directly to WebDAV. Lots of good links there.
Here are some more MSDN links that very helpful...
WebDAV Methods
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_webdav_methods.asp
It is important to familiarize yourself with these methods in order to understand what functionality you have available to you.
WebDAV Protocol Status Codes
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_webstore_http_webdav_protocol_errors.asp
Understand what WebDAV gives back to you if there are errors.
Updated 1/22/2009 – Updated and noted some broken links.
...I added a new category to the blog, you will see it is called OUTBOX. As a support engineer I send out a lot of mail that could be useful to everyone. You shouldn't have to open a support case just to get this information. So here I'll provide some email excerpts that I think might be helpful...
The issue you’re experiencing is that you are having trouble deploying a VBA macro for Outlook. As we discussed on the phone, there is no supported method for deploying VBA projects. The best way to create a deployable addition to Outlook is by developing a COM AddIn. Fortunately, the COM AddIns are implemented in a similar fashion to the VBA code used in Outlook macros. In most cases this is a simple copy and paste with very few modifications.
Here are some of the MSDN links that explain VBA deployment issues and COM AddIns in more detail:
229911 OL2000: Managing and Distributing Outlook VBA Projectshttp://support.microsoft.com/default.aspx?scid=kb;EN-US;229911"IMPORTANT: Although you can do this, Microsoft Product Support Services cannot support deploying solutions in this way."
290780 OL2002: Code Does Not Work After You Distribute a VBA Projecthttp://support.microsoft.com/default.aspx?scid=kb;EN-US;290780
316983 OL: A Sample COM Add-in That Uses the Visual Basic 6.0 Add-in Template
http://support.microsoft.com/default.aspx?scid=kb;EN-US;316983
291163 How to create a COM Add-in for Outlook 2002http://support.microsoft.com/default.aspx?scid=kb;EN-US;291163
Some of these articles make reference to specific versions of Outlook but they are all relevant to Outlook 2003 as well.
...Many customers call in on this issue. It is usually a pretty easy case to solve because COM Addin code and VBA code are nearly identical. However, this could be avoided with a little developer education, so I'm just trying to get the word out...