mstehle: The CDOs and CDONTS of Messaging Development : Exchange General

Exchange API Team Blog: Exchange Impersonation vs. Delegate Access…

mstehle — Tue, 16 Jun 2009 17:34:14 GMT

The Exchange API team has a new post to explaining the differences between using Exchange Impersonation vs. Delegate Access to access an Exchange mailbox using Exchange Web Services. I’ve seen first hand that there is a gap in understanding the difference between the two and when to use one versus the other. This post goes a long way to address some of the confusion.

An important note that some people miss is the differentiation between Windows and Exchange impersonation – they’re not the same thing and more importantly, they aren’t even related…

“Exchange Impersonation is different than Windows Impersonation. Windows Impersonation is an operating system concept that requires you to set Kerberos constrained delegation. Exchange Impersonation is a simpler authorization mechanism that is designed for use only within Exchange Web Services (EWS). For more information about Windows Impersonation, see Client Impersonation on MSDN.”

Conversely, the posts describes delegate access as…

“Delegate access is used in scenarios in which there needs to be a one-to-one relationship between users. One common application of delegate access is the sharing of calendars between users, such as when an admin manages an executive’s calendar, or a when handful of individuals working on a project need to coordinate calendars…

…Individual users can grant and remove delegate access to their own mailboxes through several mailbox clients, such as Microsoft Outlook, Outlook Web Access, or Exchange Web Services-based clients. A mailbox owner does not need administrator rights to grant another user delegate access to their mailbox.”

…To be clear, delegate access can be granted by an administrator on an entire mailbox (but not to specific folders within the mailbox) using the Add-MailboxPermission cmdlet but as the above statement points out individuals can also grant delegate access for other users to access specific folders in their mailbox or the entire mailbox.

A major difference between impersonation and delegation is that as far as Exchange Web Services and Outlook Web Access are concerned there is no way to assign a single delegate access to multiple mailboxes expect by establishing the delegate relationship for each individual mailbox. I’ve talked about this before, the Exchange team describes it this way…

“For delegate access, there is no option to set up a single delegate for multiple mailboxes. A relationship must be established for each user who needs to access a given mailbox…

…You must explicitly grant delegate access for any new users who are added.”

…This is a great post and a worthwhile read but from working with many customers to help them understand these concepts, I’d like to add some additional information and emphasize some key points…

Understanding the Requests

To emphasize a side point in the blog post there are three methods of mailbox to access a mailbox: Exchange Impersonation, Delegate Access, and Direct Logon. The article doesn’t provide examples of what the XML looks like in each type of access request using Exchange Web Services. For understanding, I’ve provided them below…

Direct Logon

<GetFolder>
<FolderShape>
    <t:BaseShape>AllProperties</t:BaseShape>
</FolderShape>
<FolderIds>
    <t:DistinguishedFolderId Id="inbox"/>
</FolderIds>
</GetFolder>

Delegate Access

<GetFolder>
<FolderShape>
    <t:BaseShape>AllProperties</t:BaseShape>
</FolderShape>
<FolderIds>
    <t:DistinguishedFolderId Id="inbox">
      <t:Mailbox>
        <t:EmailAddress>
          someoneelse@contoso.com
        </t:EmailAddress>
      </t:Mailbox>
    </t:DistinguishedFolderId>
</FolderIds>
</GetFolder>

Exchange Impersonation

<soap:Header>
<t:ExchangeImpersonation>
    <t:ConnectingSID>
      <t:PrimarySmtpAddress>
        someone@contoso.com
      </t:PrimarySmtpAddress>
    </t:ConnectingSID>
</t:ExchangeImpersonation>
</soap:Header>
<soap:Body>
<GetFolder>
    <FolderShape>
      <t:BaseShape>AllProperties</t:BaseShape>
    </FolderShape>
    <FolderIds>
      <t:DistinguishedFolderId Id="inbox"/>
    </FolderIds>
</GetFolder>
</soap:Body>

…The example above is for explicit delegate access. You can also access a mailbox using implicit delegate access by specifying a FolderId which links to another mailbox. All Ids returned by EWS embed their mailbox information in them so requesting them without explicitly specifying a mailbox will also work.

Putting It All Together

The terms used here come from the way Exchange Impersonation (also called Server-to-Server or S2S Authentication) is explained in the Inside Exchange Web Services book. The book describes three types of accounts that come into play when accessing a mailbox: the Service account, the Act As account, and the Mailbox account. Understanding how these accounts are affected by different mailbox access types is important. The Service account is the account used to generate the XML requests and authenticate to the virtual directory, the Act As account is the account which will be used to authorize actions taken against a mailbox, and the Mailbox account is the actual resource you are trying to access. In the grid below suppose you have an EWS application which runs as a user called ApplicationAccount, here is how the different access types affect each account context…

Access Type	Service Account	Act As Account	Mailbox Account
Exchange Impersonation	ApplicationAccount	the impersonated account as specified in the ExchangeImpersonation property of the request	any mailbox that the Act As account has mailbox rights to through Add-MailboxPermission or through permissions granted through Outlook, OWA, or EWS directly on a mailbox folder.
Delegate Access	ApplicationAccount	always ApplicationAccount	any account or mailbox folder that ApplicationAccount has mailbox rights to through Add-MailboxPermission or through permissions granted through Outlook, OWA, or EWS directly on a mailbox folder.
Direct Logon	ApplicationAccount	always ApplicationAccount	always ApplicationAccount

FYI: Exchange 2007 SP2 Announced…

mstehle — Mon, 01 Jun 2009 16:35:09 GMT

The Exchange team announced the upcoming service pack for Exchange 2007 recently. The primary focus of this service pack is preparing Exchange 2007 for interoperability with Exchange 2010 but there are also fixes and changes to existing components and technologies that make this update worth installing when it comes out. Here are some developer related points of interest that were announced:

“Exchange Volume Snapshot Backup Functionality - A new backup plug-in has been added to the product that will enable customers to create Exchange backups when a backup is invoked through the Windows Server 2008 Backup tool. Exchange Server 2007 didn't have this capability on Windows Server 2008 and additional solutions were required to perform this task.

Named Properties cmdlets - SP2 enables Exchange administrators to monitor their named property usage per database.”

…Both of these are most useful to developers as debugging tools but they are valuable nonetheless.

FYI: Unlike Exchange 2007, Exchange 2010 will not ship a 32-bit version

mstehle — Thu, 21 May 2009 22:06:00 GMT

The Exchange team announced that Exchange 2010 will not have a 32-bit version – not even for evaluations. The post focuses on mainly the non-developer related impact of this change. The key points for developers are:

> Applications that automate Exchange cmdlets locally will need to be compiled for 64-bit.

> 32-bit or 64-bit applications could leverage the remote Powershell capabilities in Powershell 2.0 to invoke the Exchange cmdlets remotely.

Jason Henderson: A Brief History and Exciting Future for Exchange Development

mstehle — Fri, 12 Dec 2008 18:42:00 GMT

It took me forever to get around to watching this but this is just a great presentation about Exchange development’s future at PDC. He does a great job of explaining where we’ve been as well…

Learn about the Exchange Web Services Managed API and how Exchange is getting “Cloud Ready” at PDC’08

This is an absolute must watch for any Exchange developer!

Take Notice of Exchange Web Service Notifications

mstehle — Fri, 25 Jul 2008 00:11:50 GMT

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

Disclaimer: This post is about Disclaimers...

mstehle — Wed, 23 Jul 2008 21:31:40 GMT

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."

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....

FYI: MSDN Protocol Docs...

mstehle — Tue, 01 Jul 2008 17:50:56 GMT

Steve posted a link to the MSDN protocol documentation. He talks about them here and here as well.

FYI: After Installing Exchange 2007 SP1 32-bit CDOSYS Might Not Be Registered...

mstehle — Tue, 11 Dec 2007 18:42:00 GMT

Exchange 2007 only adds 64-bit components in a 64-bit install, when you install Exchange it will register CDOEX.DLL which will replace CDOSYS.DLL and be used when you instantiate CDO.Message. So you will see CDO.Message pointing to "C:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.DLL" in the 64-bit registry and you will see CDO.Message pointing to "C:\WINNT\SysWow64\cdosys.dll" in the 32-bit registry. If your application is a 64-bit process it will load up CDOEX.DLL when you instantiate CDO.Message. If your application is a 32-bit process it will load up CDOSYS.DLL when you instantiate CDO.Message.

After installing 64-bit Exchange 2007 you may notice that 32-bit scripts and applications get a "Library not found" error when using CDOSYS. This appears to be a side effect of registering the 64-bit CDOEX.dll. To resolve the issue simply open a 32-bit instance of cmd.exe from the SysWow64 directory and run "regsvr32 cdosys.dll" to re-register the 32-bit CDOSYS.

OUTBOX: Programming Exchange 2007 Foreign Connectors - The Exchange EDK Gateway Connector Replacement

mstehle — Fri, 25 May 2007 19:16:00 GMT

...We have had a few customers looking for information on writing a custom foreign connector for Exchange 2007 and I finally got around to combining all my information into one document so that I could reuse it. I thought I would share it here as well to maybe save a few calls to our team...

What is a gateway connector?

“Gateway connectors generally use non-standard protocols, or proprietary APIs to connect Exchange to non-Exchange messaging systems” – [TechNet]Gateway Messaging Connectors Architecture

One of the most common examples of a gateway connector is an Exchange fax gateway that many ISVs have implemented for Exchange 2000/2003/2007. These gateway connectors allow a user to send faxes from Exchange clients by sending mail to a special address space like, 8001234567@MyFaxServer.com. Additionally when a fax is received the ISVs product could allow for delivery of the fax through the gateway connector to an Exchange client by converting the inbound fax to a mail message.

There are two key tasks that an Exchange gateway must perform…

Ø Receive outbound messages from Exchange

Ø Send inbound messages to Exchange

What is new in Exchange 2007?

Exchange 2007 does not support the same gateway model that Exchange 2000/2003 used. Rather than using MAPI and watching queues, the Exchange 2007 solution is file system based. To receive outbound messages from Exchange to be sent via the gateway service, you configure a foreign connector on the Hub Transport server which drops messages to a directory which the gateway service monitors. Conversely to send inbound messages from a non-Exchange to Exchange mailboxes the gateway services would create a file in a directory which Exchange monitors.

Receiving outbound messages from Exchange

The gateway service monitors a drop directory on an Exchange Hub Transport server to receive messages sent from Exchange clients that are to be sent via the non-Exchange gateway service. Address spaces which may be SMTP or non-SMTP are configured for each foreign connector to route messages to a particular drop directory.

Foreign connectors are created and configured using Exchange Powershell cmdlets.

“To use the interactive mode of the Exchange Management Shell to create a new Foreign connector

1. At the Exchange Management Shell command prompt, type New-ForeignConnector, and then press ENTER.

2. At the Address Spaces (0): prompt, type the address space to which this connector will send messages, for example, contoso.com, and then press ENTER.

3. Enter additional address spaces if this connector will send messages to more than one domain. After you enter all the address spaces, press ENTER to continue.

4. At the Name: prompt, type a name for this connector, and then press ENTER. The connector summary is displayed.” – [TechNet] How to Create a New Foreign Connector

Messages dropped in this directory will be in MIME format with TNEF (winmail.dat) attachments. The basic MIME data contains the header fields like TO and CC fields but you will not see the BCC, attachments, and body content. This information and other MAPI data are in the TNEF data which is in the winmail.dat attachment. The Exchange.Data.ContentTypes.TNEF namespace is used to iterate through the TNEF parts and extract the data from the winmail.dat that could be used by the gateway service for routing.

Send inbound messages to Exchange

The gateway service sends messages to Exchange by creating files in a replay directory. These are MIME formatted messages which are created using the new managed Exchange.Data namespaces.

The replay directory is monitored by Exchange. It checks for new messages every 5 seconds (this interval cannot be changed). Once a message is processed the file is renamed from *.eml to *.tmp. After the *.tmp file is converted to an SMTP message the *.tmp file is locked until the message is successfully queued for delivery. If the transport service is restarted then all the *.tmp files are renamed to *.eml and the processing starts over again. Messages dropped to the replay directory have some prerequisites which must be taken into account.

“A message file that is copied into the Replay directory must meet the following requirements for successful delivery:

· The message file must be a text file that complies with the basic SMTP message format. Multipurpose Internet Mail Extensions (MIME) message header fields and content are supported.

· The message file must have an .eml file name extension.

· X-Headers must occur before all regular header fields.

· A blank line must exist between the header fields and the message body.”

What is the difference between the Replay directory and the Pickup directory?

“Exchange Server 2003 uses a single Pickup directory for creating and submitting text message files. Exchange 2007 splits this functionality into separate Pickup and Replay directories. The Pickup directory is intended for users or applications to manually create new message files. The Replay directory is intended for the re-submission of exported Exchange e-mail messages and for receiving messages from non-SMTP connectors. This separation of duties allows for the appropriate security to be applied to one directory without affecting the functionality of the other directory.”

[TechNet] Managing the Replay Directory

FYI: Combining Exchange 2007 Web Services and SQL 2005 Table-Valued User Definied Functions

mstehle — Fri, 18 May 2007 04:15:00 GMT

Reading this kind of stuff almost makes we wish I was a consultant again...I say almost because then I think about requirement gathering, deadlines, budgets, debating the merits of agile development, etc...

The Exchange SDK team linked to this article on their blog the other day and I just had a chance to read through it. Exchange development seems like such a niche expertise sometimes and in the past the "tribal" knowledge it took to understand how to work with and extract data from Exchange could be intimidating for any developer. Yet there are so many possibilities to integrate the data in Exchange with all kinds of applications (CRM, IT management applications, scheduling, etc.) and Exchange 2007 Web Services start to change the game of Exchange integration because they are far easier to use and can be leveraged in so many different ways...

This article illustrates how to expose Exchange data through SQL so that any SQL developer can work with Exchange data just like they were working with a SQL view. The only Exchange development is using Exchange Web Services as a data access layer for populating SQL Server table-valued user defined functions...

"When you combine these technologies, you have a formidable new way to integrate, search, and analyze your Microsoft Exchange messaging data by using the full power of SQL Server, and to combine that messaging data with virtually any other data managed by, or available from, SQL Server."

...There are far more SQL developers out there so exposing Exchange data through SQL is a very empowering proposition. Especially the thought of expanding these samples to abstract dynamic views of Exchange folders and items through these SQL views could open up Exchange data to a whole new group of developers...

"...This sample is intended to educate and inspire you in your Microsoft Exchange development..."

...My wheels are turning, man this is cool stuff...So with Exchange 2007 Web Services the game is changed, instead of talking MAPI, COM, or .NET we are simply talking HTTP, XML, and in this case now we can talk SQL...Who can't integrate with that?

FYI: The Exchange Dev Product Team is Blogging!!

mstehle — Thu, 17 May 2007 17:12:00 GMT

Here is some exciting news...The Exchange SDK team is blogging now at http://blogs.msdn.com/exchangedev/! This a great opportunity to get some direct access to the members of the product team who are responsible for API development and SDK documentation...

"...We (the Exchange SDK UE team) coordinate the Microsoft Exchange Development Blog and are made up of our Documentation Manager, Thom Randolph, two Programming Writers, Michael Mainer and, me, Ray Dixon, and our editor, Laura Graham. However, we aren't the only people who will post here. Contributers will also include Microsoft Exchange developers, testers, program managers, and more. In the near future, you will see content that describes techniques used in Microsoft Exchange application development, coding tips, and code samples, among other things..."

...They are looking for feedback too, please let them know what you want to see posted and provide feedback on how we are doing. These folks are very interested in what goes on in the "real world" of Exchange development..

"...please send us your ideas for blog posts. This helps us tailor the content to you. To share your blog post idea with us, just send an e-mail describing your idea to exsdkfb@microsoft.com..."

OUTBOX: Introduction to Exchange Powershell Automation Part 2

mstehle — Thu, 25 Jan 2007 22:48:00 GMT

Naturally the first case I had was how to create a mailbox using Powershell cmdlets from ASP.NET given that CDOEXM is no longer available. From there we have had other bridges to cross as customers are upgrading 32-bit applications to work on Exchange 2007 (which is 64-bit) and replacing old CDOEXM code with Exchange Management Shell cmdlet automation. Through these early cases I identified a couple common themes and created some sample code that I thought might be helpful to share here…

Exchange Cmdlets and Impersonation

Much like we saw with CDOEXM, currently we don’t recommend or support using Exchange Powershell cmdlets with impersonation. In the case of creating a mailbox in an ASP.NET application we would recommend that you use COM+ or .NET Remoting to host your Powershell code, have that code run as a service account with permissions to execute the Powershell cmdlets and then implement authorization logic to evaluate if the caller has permission to execute the code. Click here for more information.

Exchange Management Shell Snap-in and 32-bit Applications

This typically isn’t a problem when writing an application in VB.NET or C# because the projects default to 64-bit on 64-bit machines but if you are trying to load the Exchange Management Shell Snap-in in a 32-bit instance of Powershell you will get the following error…

"No Windows PowerShell Snap-ins are available for version 1"

…This is because Exchange 2007 is a 64-bit application and therefore the snap-in is also 64-bit and cannot be loaded into a 32-bit instance of the shell. Click here for more information.

C# Sample – New-Mailbox

Here is sample of a function which takes input to create a new mailbox using the New-Mailbox cmdlet…

public static void CreateUserMailbox(string domain, string ou,

string database, string alias, string name,

string displayName, SecureString password)

{

string upn = string.Format("{0}@{1}", alias, domain);

ICollection<PSObject> results;

// Create a runspace. We can't use the RunspaceInvoke class this time

// because we need to get at the underlying runspace to explicitly

// add the commands.

RunspaceConfiguration rc = RunspaceConfiguration.Create();

PSSnapInException snapEx = null;

PSSnapInInfo info = rc.AddPSSnapIn(

"Microsoft.Exchange.Management.PowerShell.Admin",

out snapEx);

Runspace myRunSpace = RunspaceFactory.CreateRunspace(rc);

myRunSpace.Open();

// Create a pipeline...

Pipeline pipeLine = myRunSpace.CreatePipeline();

using (pipeLine)

{

// Create a command object so we can set some parameters

// for this command.

Command newMbx = new Command("new-mailbox");

newMbx.Parameters.Add("alias", alias);

newMbx.Parameters.Add("database", database);

newMbx.Parameters.Add("password", password);

newMbx.Parameters.Add("Name", name);

newMbx.Parameters.Add("DisplayName", displayName);

newMbx.Parameters.Add("UserPrincipalName", upn);

newMbx.Parameters.Add("OrganizationalUnit", ou);

// Add the command we've constructed

pipeLine.Commands.Add(newMbx);

// Execute the pipeline and save the objects returned.

results = pipeLine.Invoke();

// Print out any errors in the pipeline execution

// NOTE: These error are NOT thrown as exceptions!

// Be sure to check this to ensure that no errors

// happened while executing the command.

if (pipeLine.Error != null && pipeLine.Error.Count > 0)

{

Trace.WriteLine("ERROR: There were pipeline errors...\n");

foreach (object item in pipeLine.Error.ReadToEnd())

{

Trace.WriteLine("Error: " + item.ToString() + "\n");

}

// Print out the results of the pipeline execution

if (results != null && results.Count > 0)

{

Trace.WriteLine("MAILBOXES CREATED: Created the following mailboxes...\n");

foreach (PSObject ps in results)

{

if (ps.Members["UserPrincipalName"].Value != null)

{

Trace.WriteLine("UserPrincipalName: "

+ ps.Members["UserPrincipalName"].Value + "\n");

}

pipeLine = null;

myRunSpace.Close();

myRunSpace = null;

}

Notice that I use a Pipeline instead of RunspaceInvoke (like Vivek did). RunspaceInvoke works fine in a lot of cases but the advantage I found with the Pipeline is that it is quite easy to add non-string parameters like the SecureString object to the cmdlet call. Also, note that while the Invoke method returns a result array of PSObjects there is also an Error property which has an array of exceptions. This error information is generally going to be validation type errors, for instance in the case of New-Mailbox I might get an error that the mailbox already in this property but I would get an exception if I misspelled New-Mailbox.

Sample Code on the Web

Vivek Sharma: Sample Code: Calling Exchange cmdlets from .NET Code

http://www.viveksharma.com/techlog/2006/07/27/sample-code-calling-exchange-cmdlets-from-net-code

Glen Scales: Quick Create Mailbox Powershell Form for Exchange 2007

http://gsexdev.blogspot.com/2006/12/quick-create-mailbox-powershell-form.html

Glen Scales: Scripting Exchange Web Services (2007) with VBS and Powershell

http://gsexdev.blogspot.com/2006/12/scripting-exchange-web-services-2007.html

Glen Scales: Exchange SMTP Log file DNS Test tool Powershell script

http://gsexdev.blogspot.com/2006/12/exchange-smtp-log-file-dns-test-tool.html

…this isn’t necessarily related but I had to include it because it is just so cool…

Glen Scales: Geolocating Exchange Message Tracking with Powershell (Exchange 2000/2003) (Seeing what countries your messages/Spam are coming from)

http://gsexdev.blogspot.com/2006/11/geolocationing-exchange-message.html

FYI: Looking for input on the next release of Exchange...

mstehle — Mon, 15 Jan 2007 17:22:00 GMT

The Exchange team is looking for input on the next release of Exchange, although we just released Exchange 2007 the cycle never ends. Here is a chance to influence the next release...

FYI: Better Together: A look at how Exchange 2007 and Outlook 2007 work together...

mstehle — Mon, 04 Dec 2006 19:17:00 GMT

There is a new technet article written by Michael Khalili, an Exchange PM, which talks about some of the ways that Exchange 2007 and Outlook 2007 play together better than their older relatives did. The most exciting piece mentioned in this article for me, as an Outlook/Exchange developer, is the Calendaring piece. Of all the APIs we support it seems to me that most of our questions and bugs center around calendaring, any improvements/simplifications in this area are very welcome. Here is an excerpt from the article about prior problems with Free/Busy data...

"In the past, most calendar logic resided in Outlook. Each meeting update was treated as a separate meeting invitation, which meant the notifications could be accepted out of order. If two meeting updates were sent in quick succession, and a recipient accepted the second meeting update before the first, he might have out-of-date information on his calendar. Furthermore, accessing Outlook information from Smartphones or PDAs could lead to differing free/busy information according to the method by which users viewed the data."

...been there, done that...

"The solution was to move all calendar logic from the Outlook client to Exchange Server 2007. When a meeting request is received by the server the meeting is automatically placed on the calendar as tentative until the user chooses to accept or decline the appointment. If a time or location change to the meeting is received, the meeting will be automatically updated and the old invitation marked out of date so users will not accidentally accept it. This logic is consistent among all clients—Office Outlook, Outlook Web Access, Outlook Mobile, or another third-party client—so only the correct, most up-to-date meetings are present."

...very nice. As Outlook/Exchange developers we are dependant on the information returned from APIs (which in turn comes from the application's proprietary business logic) to present accurate information to the user in our applications. The more Exchange understands or centralizes Outlook's business logic as it relates to calendaring, the more accurate that data, and therefore our applications become...

FYI: Glen's Exchange Dev Blog is awesome...

mstehle — Wed, 29 Nov 2006 00:51:00 GMT

If you are an Exchange developer and haven't checked out Glen Scales's blog then you are missing out. Chances are he has written part of your project for you and posted it on his blog. Check out his latest post for a script which generates a report of mailbox size broken down by the age of messages...