mstehle: The CDOs and CDONTS of Messaging Development

Dedicated to Exchange and Outlook development topics of all kinds
Search Form
  • Advanced search options...
Options
Tags
Archive
Archives

January, 2006

MSDN Blogs > mstehle: The CDOs and CDONTS of Messaging Development > January, 2006
Posts
Sort by: Most Recent | Most Views | Most Comments
Excerpt View | Full Post View
  • mstehle: The CDOs and CDONTS of Messaging Development

    FYI: Exchange Team Blog: Minimum permissions necessary to access mailbox data

    Posted over 6 years ago
    by
    • 0 Comments
    For those of use who have fought with Exchange account permissions, here is a concise description of the minimum requirements for service account setup to access mailboxes...
     
    To learn more about the "Exchange View Only Administrator" role, check out this KB article...
     
    A number of our issues involving Exchange Event Service Scripts specifically deal with proper service account setup rather than coding changes.  Proper service account setup that provides MINIMUM access needed for your application to function is a part of most every solution written for Exchange.  This is good stuff to know...
  • mstehle: The CDOs and CDONTS of Messaging Development

    OUTBOX: Introduction to Exchange Store Event Sinks Part 2

    Posted over 6 years ago
    by
    • 5 Comments
    Coming from Exchange 5.5 Event Service Scripts to Exchange Store Event Sinks involves more than just understanding the new events available and the registration process.  Exchange 5.5 event scripts are written in VBScript with CDO 1.21 as the API to interact with Exchange data.  Store Event Sinks can be written in VBScript, VB6, managed (.NET) code, and C++ they use ExOLEDB with ADO and CDOEX to interact with Exchange data.  This is greatly improves scalability and performance but requires a bit of retooling for the developer to be comfortable in their new surrounds.  The following information discusses what you need to know about the web store how to interact with data using CDOEX and ExOLEDB.
     
    Exchange Store
     
    One important distinction to make between Exchange 5.5 and Exchange 200x is the storage architecture.  This is an important consideration when looking at the new API's available in Exchange 2000 and 2003 because many of the new API's relate to what is called Web Store or stream database that is added to the Exchange storage system.  Exchange store event sinks, WebDAV, CDOEX, and ExOLEDB with ADO all work against the web store primarily as opposed to CDO 1.21 and MAPI which work against the ESE database (which was part of Exchange 5.5 as well and is commonly referred to as the MAPI database).  We will talk about ExOLEDB and CDOEX mainly because that is what you will use in an Exchange Store Event Sink.
     
    Exchange Storage Architecture
     
     
    CDOEX, ADO, Properties, and Exchange SQL
     
    The web store uses native intermittent content such as MIME which allows access through ExOLEDB with ADO and WebDAV and the use of SQL-like queries to find information.  This is quite helpful and a little more intuitive for the database programmer.  Each item (folders and messages) in the store can be created, modified, and searched like a row in a database were item properties are columns. 
     
    Folders can be used like tables and rows, for example to query the subfolders of a given root folder you would select the URL from all items in the root folder where the item "isFolder" column is "true"...
    Select "DAV:href" from scope('shallow traversal of <ROOT FOLDER URL>) Where "DAV:isfolder" = True
    The following link provides a description of the SQL predicates supported against the web store.
     
    Exchange Store SQL
     
    Add just like in a database when you write a query like the one of above you need to know two key pieces of data specific to your store, the table name and the available columns.  The table name is pretty easy to identify as it is the folder you what to query from.  The column names differ for each item type with some overlap.  For example appointment items and contact items have most of the same properties of a basic message but they also have their own unique properties that relate to their functions.
     
    The following link provides a listing of properties available on different items organized by namespace.  You will use the full namespace and property name when pulling fields from the Fields collection of a CDOEX object or querying in WebDAV or ADO.
     
    Properties by Namespace
     
    The interesting thing about this paradigm is that it is often quite easy for a database developer to walk in and start using ExOLEDB with ADO and WebDAV to execute these kind of queries against Exchange.  However, a developer coming from MAPI or CDO 1.21 is usually left looking for the objFolder.Folders collection.  ExOLEDB with ADO and WebDAV provide a way to retrieve raw information from the server, they are not an object model.  CDOEX provides some interfaces and CoClasses to provide a bit of an object model for interacting with the web store.
     
    MSDN Reference for CDOEX CoClasses, Interfaces, etc.
     
    In event sink development you will typically stay within the interfaces of the CDOEX object you open with the URL passed into the event interface.  Especially when working with meetings and contacts note that CDOEX provides a supported way for working with these item types.  ExOLEDB with ADO and much of WebDAV offers you raw access to the items in the web store, complex item types like appointments and contacts require CDOEX or special WebDAV commands to ensure that all the appropriate properties are being set to ensure that end user clients display and use the information appropriately.
     
    It is important to understand the limitations of each API and where you should use which.  CDOEX and ExOLEDB with ADO should only be used on an Exchange server, specifically they can only be used the Exchange server which hosts the mailboxes or public folders you want to access.  WebDAV should be used to remotely access Exchange mailboxes and folders that may not reside on the server it is running on, it can also be executed on a non-Exchange server.  All of these technologies are supported with managed (.NET) code, CDO 1.21 and MAPI are NOT supported with managed code.
     
    813349 Support policy for Microsoft Exchange APIs with the .NET Framework applications
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;813349
     
    Examples
     
    Exchange Tasks
    This is a great starting place when you are looking to see what you can do with Exchange API's.  There are all kinds of great code samples here to allow you to do all kinds of stuff against the store.  I have pulled a couple samples out that relate to some common tasks developers do inside event sinks.
     
    Adding an Appointment to the Calendar
     
    Responding to a Meeting Request
     
    Listing Inbox Contents Using ADO
  • mstehle: The CDOs and CDONTS of Messaging Development

    OUTBOX: Introduction to Exchange Store Event Sinks Part 1

    Posted over 6 years ago
    by
    • 6 Comments
    This is the first part of a two part series on getting started with and understanding Exchange Store Event Sinks.  This is especially important for all of those people moving from Exchange 5.5 to Exchange 2003, there is a lot to learn with store events versus Exchange Event Service Scripts.
     
    Building Applications Using Web Storage System Events: Overview
    This is a must read to understand the basics of the web store, what events are available, and how registration items are created.
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmes2k/html/webstoreevents.asp
     
    Types of Events
     
    The above article talks about synchronous and asynchronous event sinks, these are two of the three types of event sinks: synchronous, asynchronous, and system event sinks.  It is important to drive home the impact of deciding between synchronous and synchronous event sinks, this is one of the first things you should consider when you start planning your event sink solution. 
     
    Synchronous sinks (OnSyncSave, OnSyncDelete) can be very draining on your Exchange server resources as they block until finished (hence synchronous), you want to keep these sinks as quick and simple as possible.  They are typically used in cases where you want to validate an item before a save or prevent a delete.  You can access items before they are actually committed to a folder using these sinks.  You can also abort save and delete operations initiated from other clients and code using these sinks.
     
    Asynchronous sinks (OnSave, OnDelete) don't block any Exchange threads and impact the server far less.  The trade off here is that you are given read-only access to the item, this is more for a reactionary type of solution.  If an item is saved to this folder with a certain set of criteria, then do something.  Many logging or archiving sinks are implementing asynchronously because they don't need to happen before a commit or happen in real time.
     
    System sinks (OnTimer, OnMdbStartup, OnMdbShutdown), the most common being OnTimer, are used for non-item related firing.  Timer events are typically used for processing items that may have aged out.  If you are doing a workflow application and want to sent notification on expired items you could use an OnTimer event sink to fire every so often and check a folder.  You also have events for OnMdbStartup and OnMdbShutdown which fire when the store is started and stopped.  Typically you will see these to check the integrity of an items on start up.  Note that these events are fired asynchronously as well.
     
    Store Event Sink Bit Flags
     
    Whenever you are processing events (especially the Save events) you will want to know why the event fired.  Is this a new item? Is the item being updated?  Was the item moved?  You can determine this by doing a bitwise comparison on the event sink bit flags which are passed to each of the event sink interfaces.  This is especially important to OnSyncSave which is an event that can get fired a lot so you want to make sure you do processing when you need to and do a minimum about to determine whether the event is important or not.  Below is a description of the bit masks and what they mean.
     
     
    Registering Event Sinks
     
    Understanding how and where to register your event sink is also very important.  Again this is especially noteworthy for synchronous events.  With the bit flags once an event has fired you can determine in your event sink code whether or not that event is meaningful to you, however making this determination requires the event to fire which has some expense on the Exchange.  You will want to leverage registration scope, priority, and criteria to ensure that your event sink has the least impact possible on your Exchange server.  Regevent.vbs is a very helpful VBScript that encapsulates the code behind creating, deleting, and enumerating event registrations, you interact with it through command line parameters.
     
    Event Registration Overview
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_exch2k_event_registration.asp
     
    Event Registration Items
     
    Managing Event Registrations with RegEvent.vbs
     
    Step By Step Guides
     
    Creating a COM+ Event Sink Application
     
    Building Managed Event Sink DLLs
     
    Examples
     
    288156 How To Create an Exchange 2000 Store Event Sink in Visual C++
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;288156
    There are examples of implementing each of the event sinks on MSDN.  Below are links to the OnSave event implemented in managed and unmanaged VB code.  Look in the navigation in the left pane for more implementations of the other events.
     
    Implementing a Managed OnSave Event Sink
     
    Implementing an OnSave Event Sink
     
    Exchange Store Event Sink Criteria
    This article provides some quick notes about Exchange Event Sinks, the technologies that they support and their limitations.  This is a very good quick reference for a lot of different implementation questions.
     
    > Note development criteria, sinks can be developed in nearly any Microsoft programming language including VBScript, VB6, C/C++, and managed (.NET) code.
    > Note security criteria, sinks must run within a COM+ application and always run in the context of the user specified in the COM+ configuration.  The user running the event sink must have permission to read and write to the folders where the sink will run.
    > Note deployment criteria, event sink are deployed by setting up the COM+ application and creating a registration item that resides hidden in the folder that the sink is to run.  Sinks cannot be run across servers.
     
    Unsupported Exchange Store Event Interfaces
     
    Looking through our libraries shipped with the Exchange SDK you might come across some event interfaces not discussed here.  They are listed in the link below and are not supported or recommended to be implemented.
     

    This information should give you a good start towards understanding Exchange Store Event Sinks and be a good reference for the useful links on MSDN.  The key is to start playing with it in a test environment to understand how all this works together.  I will follow up with a part two tomorrow which will include information on CDOEX, ADO, and working calendaring items.

    Updated 1/22/2009 – Fixed and removed some broken links.

  • mstehle: The CDOs and CDONTS of Messaging Development

    FYI: Exchange 5.5 has Retired

    Posted over 6 years ago
    by
    • 0 Comments

    Well all good things must come to an end, on December 31, 2005 Exchange 5.5 reached the end of its lifecycle.  For me it is the server that started it all, I started my career in Messaging Development against Exchange 5.5 in the consulting world.  It is nice to know we are moving on to such greater things, I'm very excited about Exchange 12 and you should be too.  So while providing the link that announces the end of Ex5.5, I provide you with the preview for Ex12.

    ...It is also important to note that Exchange 2000 has entered its extended support cycle which means that customers will have to pay for an extended support contract to get support for the product.  So get your free Ex03 trial and start planning your migration!

    Updated 1/22/2009 – Fixed broken links.

Page 1 of 1 (4 items)