The Exchange API-spotting blog, which is run by the Exchange MSDN content and Exchange API product folks, as a new post about the transition from store event sinks to Exchange Web Service notifications. The aim is to provide some more detail about notifications and try to directly answer some questions that have been posed by developers about how notifications can realistically replace store event sinks when they go away.
...If you have feedback for the product team about the transition or any scenarios that you are concerned about, please comment on their blog post. These posts are going up well before the next release of Exchange in order to keep you informed but also to hear what you have to say. The nice thing about Exchange 2007 is that you have EWS notifications already available to test with so while your store sinks might work now, you should begin thinking about and testing the migration of your sink solution to one based on EWS notifications. If you hit roadblocks now my team can work with you on Exchange 2007 and get answers before the upcoming release where Exchange store sinks are not a fallback option...
In fact, the Exchange MSDN content team has been very busy spreading the word about what the transition from the gang of de-emphasized APIs (CDO 1.21, CDOEX, WebDAV, etc.) to the new ones (EWS and Agents) will look like...
Migrating from Exchange 2007 Legacy APIs
Migrating to Exchange Web Services, Part 1: Messaging
Exchange 2007 Legacy API Property Mapping
I was reviewing a customer's case today and it reminded me of a topic I meant to blog about a while ago...
Ever since Exchange 2000/2003 customers have tried to apply the disclaimer SMTP sink sample to internal mail and found that the disclaimer text is not stamped on these messages. Of course in Exchange 2000/2003 this won't work. This is further described in the Exchange 2003 documentation on TechNet about The Advanced Queuing Engine...
"...the CDO interface does not support changing the content of store-submitted messages. This is a limitation that CDO_OnArrival event sinks share with all other event sinks. This limitation exists because Exchange converts a store-submitted message to a temporary SMTP version for the event sink to handle, and then discards the temporary version after the sink finishes processing... ...Because Exchange discards the temporary copy of a store-submitted message, you cannot use an event sink to add a disclaimer or other modifications to all outbound messages, unless you force all messages to be received through SMTP. To do this, you must install the event sink on a bridgehead server that is separate from the mailbox servers in your organization."
"...the CDO interface does not support changing the content of store-submitted messages. This is a limitation that CDO_OnArrival event sinks share with all other event sinks. This limitation exists because Exchange converts a store-submitted message to a temporary SMTP version for the event sink to handle, and then discards the temporary version after the sink finishes processing...
...Because Exchange discards the temporary copy of a store-submitted message, you cannot use an event sink to add a disclaimer or other modifications to all outbound messages, unless you force all messages to be received through SMTP. To do this, you must install the event sink on a bridgehead server that is separate from the mailbox servers in your organization."
This is one of the better explanations about why disclaimers don't work for internal mail in Exchange 2000/2003 and provides more detail than the KB article. What you don't get from the KB article or the TechNet documentation is that in Exchange 2007 this all changes...
The entire transport process is redone to the point that not only can internal messages have disclaimers added to them but there is no scripting or coding involved in doing so. Exchange 2007 has built in transport rules that an administrator can turn on and configure as needed without writing code. The impact on Exchange development here is that the Exchange 2000/2003 experience leads many of us to assume that tasks like adding disclaimers, prepending text to the subject lines, adding headers, adding recipients, or redirecting messages requires code but in Exchange 2007 it does not.
...Of course not every solution fits within the fixed set of conditions and actions defined for these transport rules - in those cases a custom transport agent can be used to implement whatever business logic is needed. However, it is important to remember this functionality exists in Exchange 2007 before setting out on developing a custom solution as to not reinvent the wheel....
Recently I was working with a customer who was concerned about Exchange Web Services performance. He was testing some EWS code whose purpose was to retrieve all properties of every item in a mailbox. The code was structured like this...
This first thing to take note of is that there is too much information being requested in the base shapes of these requests. Each of these requests is done requesting an AllProperties base shape. A very simple change to improve speed would be us to use IdOnly base shapes on the requests until making the GetItem calls on the items themselves at which point all properties are desired...
This code is still very chatty, it currently makes one FindFolder and one FindItem for each folder plus one GetItem for each item in the folders. That is a lot of requests and responses going back and forth. Fortunately, these calls can be restructured and combined to reduce chattiness. Notice that FindFolder has the option for a deep traversal in its shape, this makes it possible to retrieve all the FolderIds for all folders underneath the mailbox root in a single request and response. There is no deep traversal option in the base shape of a FindItem request and there is no ParentFolderIds property on the GetItem request but GetItem requests can request multiple ItemIds. So while there still needs to be one FindItem request per folder, the GetItem calls can be batched instead of doing one per item...
This greatly reduces the number of requests made and in turn increases the performance of the code. Notice that for the GetItem call it says, "approximately one call per folder". Just because an ItemId array of 1500 items can be sent with a GetItem request doesn't mean it is the best idea. Certainly batching the GetItem calls help performance but this should be broken up into a "reasonable" amount of items per request - large requests can take minutes to process and return. The ideal threshold can be determined by taking into account the deployment environment, application requirements, and testing results for each application.
...Just to illustrate the point, here is some data from tests I did. In this test I'm simply calling GetItem|AllProperties on every item in a test account's inbox. The folder has about 1500 items in it of vary sizes, some of the items are pretty large. There is just one Exchange server with all roles installed on it. The time recorded here is the time it takes to get through all the GetItem requests and responses for the items in the inbox. "Items per Request" is the number of ItemIds included in each GetItem request. Remember, these results are specific to my environment and what I'm doing in my code, your mileage may vary...
...This is part one of a two part series, click here to read part two.
As I have often pointed out and linked to there are several members of my team at Microsoft that have active blogs with interesting content. We've often thought about creating a team blog, much like the Exchange team or Outlook team or even the Exchange Developer team. However, those seemed like time consuming solutions that would create yet another place to get our posts from.
Instead we decided to create a common tag among all our common Exchange and Outlook developer support blogs posts (DevMsgTeam) so that there is one URL for all the posts on the team. Enjoy!
The feed will aggregate here.
You can subscribe to the RSS feed here.
Steve posted a link to the MSDN protocol documentation. He talks about them here and here as well.