Glen's Exchange and Office 365 Dev Blog

If your going to Tech-Ed in Australia next week I'll be doing a 30 minute presentation in the MVP theatre https://aunz.msteched.com/au/public/mvptheatre.aspx mine is MVP401 9:15-9:45 on Friday 5th. I'm going to be covering how you can go about building Advanced Exchange Management Shell Powershell scripts and also covering crossover scripting with Exchange Web Services and EMS and all the other stuff you see covered on this blog. For the last 5 minutes if the demo gods allow I'm going to do a 5 minute OWA custom form tv chef demo. There's a maximum of 20 seats in the theatre so hopefully I'll have a few takers the one thing i can promise is some unique content you wont see anywhere else so come pay me a visit if your interested.

One of the shiny new features of the Exchange 2007 Antispam agents is the ability to set a quarantine threshold and have any messages that get a SCL value that matches or exceeds that threshold sent to a Quarantine Mailbox where they can be evaluated and either released or deleted by an Administrator. One of the stock features of a lot antispam systems these days is the ability to digest the quarantine folder/mailbox and then send a digest of the quarantined messages to Admins or users on a scheduled basis. This relieves the need to constantly check this mailbox to see what has been quarantined and allows you to easily spot and take action on any false positives that might happen. I’ve come up with 2 methods of doing this on Exchange 2007 for creating Admin digests. For User digests this method could also be used but before you go down that track you should really have a automated release mechanism for the users. This could be done using a small ASP application and using Exchange Web

One important and potentially frustrating point for anybody who wants to set permissions on the calendar folder in a mailbox with any Exchange API that allows you to modify the folder DACL’s is that you also need add the same ACE your adding (or modifying) to the FreeBusy Data folder which is one the NON_IPM_Subtree Root folders in a mailbox explained in this KB . Exchange Web Services is no exception to this rule and accessing the NON_IPM_Subtree folders isn’t as straight forward as normal mailbox folders but here’s a method for accessing the freebusy folder and modifying the DACL. The highest level you can get to easily with EWS is the DistinguishedFolderIdNameType.msgfolderroot which in the basically the Root of the IPM_Subtree if you get the parentfolderID of this folder using a GetFolder Operation this will represent the Root of the NON_IPM_Subtree you can then use this ID in FindFolder operation to discover all the NON_IPM_Subtree folder in this case I’ve used a restriction to

Message Tracking from an operation perspective is one of the most useful windows you have into what's happening on your Exchange server. Used skillfully these logs can tell you firstly that your server is operating correctly eg you are receiving messages and people are sending messages, how much data is coming in, going between, and going out of your network via Email. And when the inevitable problem happens and a message is delayed or not delivered message tracking becomes one of the most import tools for diagnosis. But Message tracking logs are only a fraction of the information that is contained on a message at the point of time it was traversing the Transport pipeline. But if you combine Message Tracking with an Exchange Store API like Exchange Web Services you suddenly have a very powerful tool that can give you an unlimited amount of flexibility to audit,analysis and take action on your environment. Okay I maybe getting a little over enthusiastic but this is one area i thin