Glen's Exchange and Office 365 Dev Blog

I’ve been playing around further with microformats this week and I decided to come up with something practical I could use to transfer contact information between apps. As a starting point because most of my contact information is stored in active directory I wanted something that would be able to convert an Active Directory user object into a hCard contact. As a conduit I decided to go with a WebService as this was something that could be easily integrated into everything from a script to a fully blown windows application. There are some good tools already out there that can deal with the information once its in hCard form like Tails for Firefox or Technorati Contacts Feed Service . The webservice itself is pretty basic it takes the useraccount name as an input parameter for which account you want to convert and then it returns a XML document that contains the user account information that has been extracted from various active directory attributes using the System.directoryservice

A few years ago I came up with this simple RSS feed for a Exchange calendar that used an Exchange store event sink to generate a feed of calendar items for a certain number of days. This was a fun thing to do at the time maybe not that useful at the end of the day because it lacks the ability to be able to integrate it into anything really live. The other day someone asked me about SSE which is “The objective of Simple Sharing Extensions (SSE) is to define the minimum extensions necessary to enable loosely-cooperating apps”. Put basically its about creating wiring or a method that will allow too endpoints (whatever they are) to exchange and share data easily. For example you could syndicate your family’s calendars so In Outlook you would have side-by-side or maybe in a different calendar appointments from family members etc that you subscribed to via a normal RSS feed you can then syndicate this information to other people in a combined RSS etc. Now that sounds really simple by like

Somebody sparked my interest to this last week, one of the functions of Outlook is the ability to delegate your calendar and forward the meeting invitations you receive to another user. What Outlook does in the background is creates a rule in the inbox to forward any Calendar request messages to this delegate user. A problem can occur if this delegate user is deleted or disabled and the original user doesn’t modify or delete their delegate rules. In this case anyone sending this person a meeting invitation may suddenly start receiving NDR’s because the account the delegate rule is forwarding to no longer exists or is no longer accepting messages something like what described by KB253557 To detect and report on forwarding rules what you can use is CDO 1.2 and the rule.dll component which you can download from here . The rule.dll com object is good for creating rules but it can also be used to report on rules that already exist(a good thing to keep in mind is that this can’t be used to

Someone asked me about auditing System polices today I’m not a big user of these myself but a lot of the routines I’ve used before in scripts posted to this blog can be applied to get this information. In Exchange 2003 there are three system polices for Mailbox Stores, Public Folders and Servers. Exchange system policys can have a number of property pages which is turn affect the configuration of whatever mailbox store, public folder store or server you apply them to. All the information is stored in Active Directory so if you want to report on it via a script you can use ADSI as an entry point for accessing this information. So what I’ve come up with is a script that first queries for all the msExchPrivateMDBPolicy objects in Active Directory. It then uses the msExchPolicyOptionList attribute which stores the property pages that this policy will apply to. This attribute in an octant array so a function is included to convert this to a hex value so it can be used in a case statement