Glen's Exchange and Office 365 Dev Blog

This blog has been a little quiet over the last month as I've been putting all my efforts into my MEC Talk which is now only a week away, but I should have a number of new posts soon after that. In addition to this talk I am going to be moderating the Experts Unplugged: Exchange Extensibility  session at MEC. If your interested in Exchange extensibility in any way this should be a really good session to attend, as we will be able to discuss exchange extensibility as a whole across EWS, Transport, Apps and Powershell and not just the individual components. The Panel for this session is made up of Subject matter experts from Microsoft who are responsible for designing,building, and directing the future of extensibility in Exchange. So this will be great opportunity for the community to come together and discuss where we are at with extensibility, some of new exciting stuff in SP1 and where we are going in the future. More importantly its your opportunity if you are attending MEC t...

One of the most important learning points when thinking about programing or designing Transport agents is to understand the different between a P1 (Delivery Envelope) and P2 (Display Envelope) The P1 (Delivery Envelope) contains the recipient To and From information that is transmitted to the MTA server be it Exchange or any other SMTP server in the SMTP conversation and is the actual information that will be used for delivery of the message. Eg the Evaluating MTA will only examine the P1 recipients to determine what recipients a message would be delivered to. The P2(Display Envelope) contains all the information that that the user will see when they receive the message this includes the From, To ,CC and Subject of a message. The important point to understand is that the MTA that is processing the message doesn’t look at these headers to determine whom to deliver the message to. BCC’s One of the things that confuses a lot of people when they look at messages via an API or within an Tr...

In Exchange 2007 and 2010 all mail that is sent and received must transit its way through a Hub server where if your a developer you can create a transport agent to perform additional tasks on those messages before the are passed out of your org or into a mailbox. Sometimes these tasks may involve custom mapi properties that you may have created by using customized forms in Outlook or OWA or possibly a custom EWS application. When it comes to accessing these custom properties in a Transport Agent it involves using the TNEFReader in a transport agent to parse TNEF part of a message. TNEF for those uninitiated stands for Transport Neutral Encapsulation Format which is a serialization format that Exchange uses to send the Mapi properties of a Item via email there is a protocol document that covers this http://msdn.microsoft.com/en-us/library/cc425498%28v=EXCHG.80%29.aspx . What the TNEFReader does is allows a Transport Agent to parse all the different property structures and data-types co...

The ability to rewrite the from address of emails can be exceedingly useful if you are working with consolidating or migrating email systems especially if you have two (or more) companies merging or you're trying to consolidate disparate email system across orgs. Exchange 2007 has a great address rewriting agent that runs on a Edge server which is explained in http://technet.microsoft.com/en-us/library/aa996806.aspx . If you aren't implementing an Edge server as part of your Exchange org then unfortunately you cant use this agent on a Hub server. One solution to this is that you write your own agent to do this which is what this post is about. Now that link I just pointed to has some very important information about the fields you should and shouldn't rewrite in an address rewriting Agent and the reason you shouldn't rewrite particular fields. The Return-Path is probably the one of most note and maybe the one people will tend to want to rewrite because of the visibility...

SharePoint servers these days are multiplying like rabbits while Sharepoint is a great place to put and index information breaking habits and making sure you have a central repository of things is always a challenge. What this agent does is looks at any email which has any Pdf attachments that have the word “quote” in the filename if these emails have any external recipients this document will get uploaded into a specific SharePoint’s sites shared documents library. So this allows me in this case to have a central repository of all the quotes sent out via email. To make sure the documents that are being uploaded have a unique filename the processing time is added to the filename of the document at the time it’s uploaded to SharePoint. Because programmatically uploading a document into SharePoint isn’t that straight forward To upload the document into the SharePoint Document library itself I’ve use the S.S. Ahmed cool WSUploadservice which is free,easy to install and use you can get...

This is a quick post to give an example of something that from the outset I would have thought would be easy but for some reason took me a little time to get my head around. Having been using CDOSYS/EX for a number of years adding a attachment to a message Is as easy as just using the addattachment method and specifying the filepath and the class will do the rest and add that attachment to the message. When working in a transport agent with the Microsoft.Exchange.Data.Transport.Email class to add an attachment you can use the attachment collections add method . There is an overload for this method that allows you to specify the filename which I thought would mean that this would work like CDOSYS’s addattachment method which didn’t turn out to be the case. Using this overload just gives you a blank attachment object with the filename property set. So to add an attachment within a Transport agent you first need to open the file in question and read-in the stream of bytes from the file ...

Continuing on from my other post last week this is a little bit more of an advanced Transport agent that can process attachments within embedded messages down to any depth. Most of the code is the same as last week except that the structure of the code has been changed so each message and embedded message is processed by the routine. To see if a attachment has an assoiciated embeeded message all you need to do is check the EmbeddedMessage property on each message. The one thing that I found interesting is when processing an embedded message vs. just processing the message that caused the Agent to fire is that there is no underlying MIME document so the code I had that was saving out the message to a separate directory using the MIME document in this case wouldn’t work for an embedded message. As I was really only interested in processing attachments this was not so much of a problem but its one thing to be careful of if you do what to processes embedded messages. For details of what th...

I’ve been continuing on with building and learning about Transport Agents over the past couple of weeks and thought I’d share an agent I’ve found useful. The following agent is a simple archiving agent it saves the serialized version of the message from the Mimedocument class to an eml file in a directory assigning it a GUID as a filename to make sure its unique. It also enumerates though the attachments of a message and saves them to a separate directory using the attachment filename and the message guid to link the message and attachments. I also added some code into to delete pdf files that where smaller than 20 KB this was for testing purposes but it’s something I’ve used in the past in SMTP sinks to overcome certain issues. Like the last Agent I posted this is a Routing agent I’m running on Hub Server the code is relatively simple to follow. To do the attachment processing I’ve used the new EmailMessage class that’s part of the Microsoft.Exchange.Data.Transport.Email namespace. ...

This week I’ve been looking at Transport Agents which are the replacement to Transport Event Sinks in Exchange 2007. After the initial struggle of finding some decent information to get going these Agents are surprising easy to code and have a bunch of powerful functions that are more readily available then they were when compared to SMTP transport Event Sinks. Getting Start info If you’re looking for info on getting start the first place is this simple sample . One piece of advice is before you look at installing a Transport Agent making sure you know how to disable or remove one first. There are two types of Transport Agents Routing and SMTP which one you use really depends where in the Transport Pipeline you want to intercept the message. I choose a Routing Transport agent because I wanted to be able to add an X-header to a message regardless of whether the message arrived via SMTP or if it was sent locally on a Mailbox server (if you are looking to do this in a SMTP Transpor...