Working with Tasks using Exchange Web Services
An integral part of Outlook from its very initial version, Outlook Tasks were always intended to remain that way… an integral part of Outlook. They were not, on the other hand, intended to serve the purposes that they tend to be used for, today.
Outlook Tasks were introduced to give users a cute and nifty tool meant for time management and tracking their personal To-Do items within their favorite Mail client. What Outlook Tasks were not intended to do were to become the core of large-scale Task Management deployments spanning across several corporate offices, office locations, hundreds or thousands of employees and what not. It is possibly for that reason that Tasks weren’t given a lot of priority as far as Server-Side programming API’s were concerned. To be more specific, pre-Exchange 2007, Tasks were given no priority in server-side programming, since they were after all intended to be for personal use by users to plan their day, create Follow-Up alerts, track their activities and so on. Prior to Exchange 2007, all of the Exchange programming API’s concerned Mail, calendaring, contact-management and administrative mailbox management.
The reality, however, is that over time, we would come across customers designing applications that needed to programmatically create Tasks across several mailboxes through code, but could not find API’s that would support the requirement. Hence, when Exchange 2007 came into the picture and we started trying to integrate and build more and more of Exchange-side programming tasks into Exchange Web Services, I suppose it wasn’t the worst thing that we added a bit of love for Task Items! We went to the extent of exposing methods to Create, Read, Modify and Delete task items directly in/from a folder, managing several attributes including Recurrence. The list of members (properties, methods) can be found here: https://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.data.task_members%28v=exchg.80%29.aspx
However, what we didn’t include was the option of assigning tasks, reporting and all that jazz since, as I mentioned a while ago, they were never intended to be part of gigantic server-side automated applications. Hence, customers often approach us looking for options to create Tasks across multiple mailboxes using the same application without having the credentials to each of them at hand.
Now creating, updating Task Items isn’t very difficult through EWS. You can find find code samples to do it using the Proxy Reference over here:
Creating Tasks: https://msdn.microsoft.com/en-us/library/aa563029%28v=exchg.80%29.aspx
Updating Tasks: https://msdn.microsoft.com/en-us/library/aa563020%28v=exchg.80%29.aspx
Deleting Tasks: https://msdn.microsoft.com/en-us/library/aa493936%28v=exchg.80%29.aspx
Using the EWS Managed API makes it even simpler, reducing your code to but a few lines:
Task taskItem = new Task(exchangeService);
taskItem.Subject = "Monthly Review";
taskItem.Body = new MessageBody("Monthly Review from 11th to 20th");
taskItem.StartDate = new DateTime(2012, 04, 11, 10, 00, 00);
taskItem.DueDate = new DateTime(2012, 04, 20, 10, 00, 00);
taskItem.Recurrence = new Recurrence.MonthlyPattern(new DateTime(2012, 04, 11, 10, 0, 0), 1, 11);
taskItem.Recurrence.StartDate = new DateTime(2012, 04, 11, 10, 0, 0);
taskItem.Recurrence.NumberOfOccurrences = 5;
taskItem.Save();
This code is only any good as long as you are creating the Task within the Tasks folder of the user whose credentials the ExchangeService object is configured with. What if one needs to use Tasks to implement details of organizational workflow, to track collaboration on action items with colleagues and numerous other scenarios that you find yourself using Tasks for, apart from creating them in your Outlook to manage your day?
Well, the obvious answer to that is to look to use Sharepoint. The best advantage of using Sharepoint is that it’s meant for these purposes, integrates well with Outlook, stores data in centralized databases (instead of scattering them across Databases) and allows you so much more freedom to customize the workflow (although most of the useful functionalities could be found out-of-the-box).
However, for those who insist on having their EWS app creating Task items across various mailboxes, they find themselves using any of the following workarounds…
1. The first Workaround is to use the credentials of a Service Account that has impersonation rights on the user whose mailbox you need to create the Task items in, or on the mailbox database in which it’s present.
Naturally, the Service Account would have the freedom to not only create Tasks within the Task folder, but to create items within any folder, not to forget the ability to read, modify and delete items within the entire mailbox. Hence, the credentials of such a Service Account is as sensitive as the credentials of your organization’s Administrator, and should be treated that way. Nonetheless, Impersonation is a very popular concept (in EWS… and otherwise, I’m sure) used by developers all over.
You can read more about how to Impersonate over here: https://msdn.microsoft.com/en-us/library/dd633680%28v=exchg.80%29.aspx
2. The second option, which allows us to limit the reach of a designated Service Account to just the Tasks folder of the target mailboxes, is through Delegation.
Suitable as it may sound, delegation comes with additional work. The Service Account would have to be added as a Delegate to each of the target mailboxes.
If the Delegate has to be added to only a few mailboxes, you could keep it simple and provision it through the Outlook UI: https://office.microsoft.com/en-us/outlook-help/allow-someone-else-to-manage-your-mail-and-calendar-HA010075081.aspx
If the Delegate has to be given permissions on the Tasks folder of many users, you might want consider automating the process using EWS: https://msdn.microsoft.com/en-us/library/dd633621%28v=exchg.80%29.aspx
If more users are added to the Exchange Server in the future, and the Delegator needs permissions to create Tasks within their Tasks folder as well, permissions would have to be given additionally. This distinguishes it from Impersonation in which the Service Account could be given Impersonation rights on an entire mailbox database, and would have those permissions on any mailbox added to the same database afterwards.
Heading back to the EWS implementation, with Delegate Permissions in place, instead of simply Saving the created taskItem, one would have to specify where to save it, i.e.,
taskItem.Save();
would become
taskItem.Save(new FolderId(WellKnownFolderName.Tasks, "targetMailbox@domain.com");
What if we’re not on Exchange 2007 or higher?
Well then, we’re evidently missing out on a lot of excellent innovation in Messaging Technology, aren’t we? Keeping in mind that Exchange Server 2003 completes 10 years next year (which is quite a lot in technology), it might be a tad unreasonable to expect too much from it.
Also, there are numerous new products that have developed strongly over the last few years, such as Sharepoint, Dynamics CRM that provide functionality out-of-the-box that developers try to achieve through Outlook, and a lot more.
The Outlook Object Model does expose a lot of functionality (as it has always done) for working with Task items (which makes sense since it’s a Client-Side programming API). One must keep in mind though that server-side automation of OOM is of course unsupported and thoroughly advised against: https://support.microsoft.com/kb/257757