The content of this blog stands true as of 13th of June, 2012. The behavior described towards the end of the article may be corrected through a subsequent product update.

Out-of-the-box Custom Attributes were introduced starting Exchange Server 2007 to save you the trouble of having to modify your Active Directory Schema, as you had to in Exchange 2003 and earlier, to store custom information against AD users, such as EmployeeID etc. that Exchange doesn’t already provide for.

Usage of these in-built Custom Attributes over ones added by extending the AD Schema come with many advantages, all of which are documented here: https://technet.microsoft.com/en-us/library/ee423541.aspx

You might come across many a situation where you need to fetch information stored in one of the Custom Attributes in your code that uses the Outlook Object Model or the Outlook Interop Assemblies.

Values of custom attributes (among other extended properties) can be easily be read through the PropertyAccessor member (https://msdn.microsoft.com/en-us/library/bb147680%28v=office.12%29) of the ExchangeUser object.

You would need to specify the Schema Names for each of the Custom Attributes, which would be of the format:

https://schemas.microsoft.com/mapi/proptag/<Property Tag>

The property tags for ExtensionAttribute1 to ExtensionAttribute10 can be found here: https://support.microsoft.com/kb/178553 but I’ve provided a code excerpt for you that fetches the values of all 15 custom attributes associated with the logged on user, below:

               Outlook.Recipient curUser = this.Application.Session.CurrentUser;
               ExchangeUser exchUserObj = curUser.AddressEntry.GetExchangeUser();
               String[] propNames = new String[] { "https://schemas.microsoft.com/mapi/proptag/0x802D001F",
                                                "https://schemas.microsoft.com/mapi/proptag/0x802E001F",
                                                "https://schemas.microsoft.com/mapi/proptag/0x802F001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8030001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8031001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8032001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8033001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8034001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8035001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8036001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C57001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C58001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C59001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C60001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C61001E" };

                           object resultCustomAttributes; //An array to retrieve the values stored in each of the 15 Custom Attributes
                           resultCustomAttributes = exchUserObj.PropertyAccessor.GetProperties(propNames);

Unfortunately, it isn’t a mere gaffe on my part that I’ve marked the first 2 schema names corresponding to ExtensionAttribute1 and ExtensionAttribute2. It so happens that the values of these 2 specific attributes seem to be inaccessible via OOM at the moment. I’ve tested this behavior against the latest patched builds of Exchange Server 2007 and 2010.

The issue seems to be confined to OOM alone, since the values of the 2 attributes can be read successfully using Extended MAPI (which can be verified using tools that make Extended MAPI calls such as MFCMapi).

If you happen to be using such an implementation and you’re observing the issue, I’d recommend that you avoid using ExtensionAttribute1 and ExtensionAttribute2, until the issue is resolved.

Cheers!

Update: As on 25th May 2012, Roll Up 3 for Exchange Server 2010 SP2 addresses this issue. You can install this update from: https://www.microsoft.com/en-us/download/details.aspx?id=29899

You can read a description of the issue here: https://support.microsoft.com/kb/2689810

_____________________________

Disclaimer: The contents of this article stand true at the time of writing it, which is on the 18th of May, 2012. The last release to Exchange Server 2010 at this point is Rollup 2 for Service Pack 2. Behavior is expected to change (for better) in subsequent updates.

 
So we’ve uncovered a rather peculiar issue existing in Exchange 2010 whereby if you use an Exchange Web Services application to generate and send out a meeting request whose body contains HTML formatting, you’ll observe that when you open the meeting item in Outlook, you might find that the HTML formatting of the text is missing. Interestingly, this behavior is observed when Outlook is running in Online Mode, though the content will be nice and HTML-formatted when Outlook is in Cached mode or you’re viewing it through Outlook Web Access.

Poof! Magic? Err… guess not.

This is due to a known issue that has been identified and fixed, and will in all probability be rolled out in a subsequent update to Exchange Server.

What we have done, though, is fixed this specific issue for Recurring items in Rollup 2 for Exchange 2010 Service Pack 2. So if you think this specific issue is going to cause a lot of controversy at your end, we have identified a possible work-around for you…

To implement this work-around:

1. Have your organization’s Exchange Server 2010 patched to Service Pack 2 Rollup 2 (https://www.microsoft.com/en-us/download/details.aspx?id=29427)
   
2. Alter the code in the EWS application that you’ve written so as to make the meeting item Recurring. Naturally, the question is “Why would I make it recurring if it’s going to take place only once?”
   The answer is that you’re going down that road because you need HTML formatted e-mails generated out of your Exchange Web Services application to be accurately viewable in Outlook clients running specifically in Online Mode, and it cannot wait till the issue is addressed in a subsequent rollup/service pack.
   Also, we don’t really need to create multiple recurrences of a meeting item which has to take place only once. We create once recurring instance, and trick Outlook into thinking that it’s a recurring series.

So while traditionally, your code would’ve looked like this…

Appointment appointment = new Appointment(service);
appointment.Subject = "Recurring with proper HTML";

appointment.Body = "<html><body><bold>Recurring Item</BOLD><br /><A href='https://www.bing.com'>Bing</a><p /><Font face='Arial' size=15>HTML formatted Body</font></body></html>";

appointment.Body.BodyType = BodyType.HTML;
appointment.Start = DateTime.Now.AddDays(1);
appointment.End = appointment.Start.AddHours(2);
appointment.Location = "Conference Room";
appointment.RequiredAttendees.Add(“recipient@domain.com”);

appointment.Save(SendInvitationsMode.SendToAllAndSaveCopy);

now it would have to read this…

Appointment appointment = new Appointment(service);
appointment.Subject = "Recurring with proper HTML";

appointment.Body = "<html><body><bold>Recurring Item</BOLD><br /><A href='https://www.bing.com'>Bing</a><p /><Font face='Arial' size=15>HTML formatted Body</font></body></html>";

appointment.Body.BodyType = BodyType.HTML;
appointment.Start = DateTime.Now.AddDays(1);
appointment.End = appointment.Start.AddHours(2);
appointment.Location = "Conference Room";
appointment.RequiredAttendees.Add("recipient@domain.com");

//Here, we pretend that it's recurring... Though the number of occurrences is just 1!
appointment.Recurrence = new Recurrence.DailyPattern(appointment.Start, 1);
appointment.Recurrence.NumberOfOccurrences = 1;

appointment.Save(SendInvitationsMode.SendToAllAndSaveCopy);

The only catch is that Outlook would be telling you that the meeting item is recurring, when it really isn’t. And that’s where you figure out which of the 2 options suits you better.

Cheers!

A known behavior of Outlook and the Object Model (documented in this KB) is that if you import an Outlook item into your mailbox or a PST from an MSG file, either by dragging and dropping, or through the CreateItemFromTemplate() (documentation) OOM call, it’s pretty much a known fact that you would find the UserProperties collection (documentation) of the item to be empty, in spite of however many entries may have been contained within it beforehand.

The UserProperties collection can be extremely useful to organizations which have customized their forms to store user-specific information under the hood. Thus, one would definitely not want to find it completely empty, right?

The good news is that when you export an item into an MSG or an OFT file, those UserProperties entries aren’t deleted. Nor are they disposed of when you import that item back into your mailbox. To be able to read those properties back into your items, you can make use of an extremely nifty object called PropertyAccessor, that allows you to read properties that aren’t directly exposed by the Object Model. (The PropertyAccessor object is available only Outlook 2007 onwards, hence consider that one very small part of a ton of excellent reasons to upgrade from prior versions of Office to Office 2010!)

Assuming that you’ve created the Mail Item and assigned it to a variable called oMail, your code would look something like…

Dim myOlApp As Outlook.Application
Dim MyItem As Outlook.MailItem
Dim propName, propValue As String
Dim oPA As Outlook.PropertyAccessor

Set myOlApp = CreateObject("Outlook.Application")




Set oMail = myOlApp.CreateItemFromTemplate("C:\SampleMailItem.oft",  _
            myOlApp.Session.GetDefaultFolder(olFolderInbox))
'Get a Reference to the PropertyAccessor object
Set oPA = oMail.PropertyAccessor
'Call GetProperty
propName = “CustomProperty1”
propValue = oPA.GetProperty(PropName)

And lo behold, we’re in business!

When we introduced ribbons  in various Office applications with Office 2007 (and expanded it further in 2010), we also brought to you a quick and easy GUI tool, called the Ribbon Designer, to help you design your custom ribbons via Visual Studio, in a manner in which WYSIWYG.

Unfortunately, come Office 2010, as far as the Ribbon Designer is concerned,in very specific scenario, WYS is not always WYG.

I can’t emphasize that the scenario is indeed very specific, and if you find your users encountering it, this blog is just right for you!

Let’s assume your users tend to do quite a bit of e-mailing, hence Outlook is almost always running in the background. Let’s also assume that they work a lot with Excel or Word documents, and tend to email them out directly from within Excel/Word by navigating to “File –> Save & Send –> Send As Attachment”. Finally, let’s assume that you’ve customized the ribbon of the Outlook Compose inspector (i.e. Microsoft.Outlook.Mail.Compose) and have used the Ribbon Designer to accomplish this purpose.

Given that all of the above assumptions are true, i.e. while Outlook is running in the background, a user creates a new Excel/Word document, then tries to email it through File->Save&Send->SendAsAttachment and you’ve customized the compose editor ribbon, your user will tragically find that on trying to Save the document after e-mailing it out, the Save/SaveAs dialog box is lost somewhere behind the Word/Excel document window, and quite inaccessible (until you navigate to Start –> Run –> Outlook /reportleakedrenitems) which somehow exorcises the ghost that is suppressing that Save/SaveAs dialog window.

The short version of the story is that this is due to a known issue with ribbons designed using the Ribbon Designer. (You won’t encounter the issue if your ribbon isn’t customized, in which case you can close this webpage and move on to something more interesting).

The long version of the story is that this is our unusual way of introducing you to the beauty of…

RibbonXML!

Or in more sober terms, the easiest way for you to avoiding this issue is exporting your custom ribbon to use RibbonXML.

One could write pages about how RibbonXML gives you more control over the appearance, functionality and flexibility you can exercise with your custom ribbon. In fact, we’ve written a few pages on it over here: https://msdn.microsoft.com/en-us/library/bb386097(v=vs.90).aspx

Additionally, we’ve also done our best to to make this transition from Ribbon Designer to RibbonXML by publishing this article to get you kick-started: https://msdn.microsoft.com/en-us/library/bb386297(v=vs.90).aspx

The bigger challenge is understanding how RibbonXML works. Naturally, this article would perform the job to some extent for you:https://msdn.microsoft.com/en-us/library/aa942866(v=vs.90).aspx

To compare the 2 in a nutshell though, when you dump the Ribbon Designer in favour of the super-fabulous RibbonXML, you’ll find that every entity in the RibbonXML (buttons, toggle buttons, groups, tabs, check-boxes, drop-down boxes etc.) comes with its own set of attributes. Each of these attributes allows you to determine its appearance and behavior… whether it’s visible/invisible, enabled/disabled, or what happens when you perform an associated action.

For instance, you have the option of pre-defining whether an element is visible at all times, i.e.

<tab id=”New Tab” visible=true />

or whether you want an element to be either visible or invisible depending on a certain condition which may change dynamically, i.e.

<tab id=”New Tab” getVisible=”getElementVisibility” />

and subsequently define the corresponding callback as such:

bool getElementVisibility(IRibbonControl control)
{

            if(control.Id = “New Tab”)
                      return newTabVisible;

}

There’s an excellent compilation of callbacks associated with each type of element, along with descriptions and their signatures in Part 3 of a 30part series on how to develop ribbons, accessible here: https://msdn.microsoft.com/en-us/library/aa722523%28v=office.12%29.aspx

For example, the onAction callback is usually the most useful in executing logic that is to be triggered when a certain control is modified. Similarly, the getSelectedItemId and getSelectedItemIndex callbacks come in handy for determining the selected value in a drop-down box.

The trickier part can be to dynamically modify the contents of a Combo Box/DropDown list, but the getItemCount, getItemLabel and getItemId callbacks can come in handy here, although one must remember to call the Invalidate() method on the ribbon (or the InvalidateControl(ctrl.Id) method on a specific control) for those changes to reflect.

Another excellent resource to read if you’re creating a Ribbon that should change depending on user action/input, or be dependent on any other factors can be found here: https://msdn.microsoft.com/en-us/library/dd548010%28v=office.12%29.aspx
Although written around programming for Access, it’s a great way to learn concepts.

Delay not further in ridding yourself of Visual Designer limitations and discovering the versatility and sheer power of RibbonXML programming! Dive write in and enjoy the power of customization!

Until next time!

Through the magic of Powershell automation that was introduced for Exchange Management, it so happens that Exchange 2007 and 2010 come with quite a few built-in scripts that attempt to make your life easier, (not to forget all the custom scripts that you could write yourself, to automate tasks that are frequent to you).

While there are several ways of automating execution of Exchange Cmdlets through powershell (documented here [link] for 2007 and here [link] for 2010), there may be scenarios in which all you really want to do is execute a nifty PS1 script that runs very efficiently when executed via Powershell, and all you really need to do is figure out how to execute that PS1 script, you could possibly use this sample [Link].

But sometimes, as it so happens, PS1 scripts refer other resource files, and seem to be dependent on other parameters, which makes them a bit tricky to execute outside of Powershell. For instance, the RedistributeActiveDatabases.ps1 (documentation) which comes with Exchange 2010 SP1, and does a marvellous job of balancing active mailbox database copies across a Database Access Group, really only seems to work when executed directly within the context of Powershell. Coupled with the fact that quite a lot of cmdlets would be executed in a single run through the script, piping each cmdlet to a Remote Powershell runspace would cause the script to take painfully longer to complete.

In such circumstances, the best approach is to automate the loading of the PS1 script through powershell. But how?

Well, it’s quite simple, really, if we go back to the basics. All we need to do is create a process of command prompt and execute powershell.exe through it, providing it the path of the PS1 script as a parameter (appending the parameters to the script in the process), and capturing the output returned.

This is how I managed to execute the elusive RedistributeActiveDatabases.ps1 script, providing my own custom DAG name, and the “ShowDatabaseDistributionByServer” switch to organize the output. In brief, the input to powershell looks something like this:

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer

The same thing, when executed via C#, giving us the flexibility to modify the DAG name through user-input, would look like this:

 void callPS1Script(dagName)
        {
            string filePath = Environment.GetEnvironmentVariable("ExchangeInstallPath") + "Scripts\\RedistributeActiveDatabases.ps1";
            string command = "powershell.exe -file \"" + filePath + "\" -DagName \"" + dagName + "\" -ShowDatabaseDistributionByServer";
            try
            {
                // Create a ProcessStartInfo object specifying "cmd" as the target program.
                // The switch /c tells cmd that the command that follows is to be executed

                System.Diagnostics.ProcessStartInfo objPSI = new System.Diagnostics.ProcessStartInfo("cmd", "/c " + command);

                // This specifies that standard output will be redirected to Process.StandardOutput StreamReader.
                objPSI.RedirectStandardOutput = true;
                objPSI.UseShellExecute = false;
                objPSI.CreateNoWindow = true; //Optional: To avoid the window that comes with cmd prompt

                // Create a process, assign its ProcessStartInfo and execute
                System.Diagnostics.Process objProc = new System.Diagnostics.Process();
                objProc.StartInfo = objPSI;
                objProc.Start();
 
               // Retrieve output
                string objOutput = objProc.StandardOutput.ReadToEnd();
 
               // Display Output
                Console.WriteLine(objOutput);
            }

            catch (Exception e)
            {
                Console.WriteLine(e.Message);
            }

        }
 

This was tried out in a ConsoleApp by me, and in an ASP.NET application by the customer I was working with, so it seems good to go. For in-built Exchange Scripts to work, you’ll naturally want Exchange Management Tools for the relevant version of Exchange Server installed.

Cheers!

To make sure that the Autodiscovery service is accessible from the WebServer, you could download the EWSEditor Tool (Link) and use that to test Autodiscover:

Fact is that unless your credentials are passed successfully to the Exchange Server through the ExchangeService object, Autodiscover is likely to throw tantrums, even one as misleading as '”The Autodiscover service couldn’t be located”. A quick way to make sure that the issue isn’t indeed because of inavailability of Autodiscovery, is by hardcoding credentials of a mailbox in the ASP.NET application (for diagnostic purposes), and see whether autodiscover works in that scenario and mailbox items are fetched for the mailbox whose credentials are hardcoded, when you browse the ASP.NET application from a client machine.

//Original Code        

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP1);

service.UseDefaultCredentials = true;

         service.AutodiscoverUrl("<sampleMailbox@domain.com>");

//Diagnostic Code

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP1);

         service.Credentials = new WebCredentials("<sampleMailbox>", "<password>", "<domain>");

         service.AutodiscoverUrl("<sampleMailbox@domain.com>");

So the obvious question is… what are we doing wrong? The IIS application should be running under the identity of the logged on user and ought to be passing his/her credentials onwards to Exchange to fetch his mailbox items via EWS, right?

Ideally, yes. (And in this context, the ideal isn’t impossible to achieve).

What we’re observing here is a double-hop scenario. The user who’s browsing the application from a client machine passes his credentials to the IIS server, i.e. the credentials of the user hop from the client to the IIS server. Subsequent to that, when the IIS application executes EWS calls, it is supposed to pass those same credentials to the Exchange server, to authenticate the logged on user. This works fine in the ideal scenario, and falters in alternative scenarios.

Ideal scenario: Kerberos authentication method is being used within the organization 
Frequent Scenarios: The non-ideal scenario is not being observed, i.e. NTLM might be the active authentication mechanism, or Kerberos could be failing and the application falls back on attempting authentication via NTLM which would eventually fail in a double-hop situation.

Here are the action items that you'd have to implement to allow end-to-end authentication in this context (i.e. they ought to be comprehensive for most scenarios): 

1. Enable your ASP.NET application to use Kerberos ("Negotiate") authentication, along with NTLM: https://support.microsoft.com/kb/215383

2. Additionally, ensure that the ASP.NET application is allowed to impersonate: https://support.microsoft.com/kb/306158

3. Enable Kerberos authentication on your Exchange Client Access Servers: https://technet.microsoft.com/en-us/library/ff808312.aspx
    For this specific step, relevant SPN's need to be set for the services involved. However, presence of duplicate SPN's can disrupt access to the service, and this step should be executed carefully, involving Microsoft Support if required. (https://blogs.technet.com/b/askds/archive/2008/06/09/kerberos-authentication-problems-service-principal-name-spn-issues-part-2.aspx)

4. Enable the Service Account configured for the AppPool your ASP.NET application is running under, for Delegation: https://technet.microsoft.com/en-us/library/cc784032(v=ws.10) (Similar steps need to be followed for Windows Server 2008 and 2008 R2).
Factor to consider... General Delegation vs. Constrained Delegation: https://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

The entire process is rather complex, and would require collaboration from your application developers, Exchange Admins and Admins who manage Active Directory and the Application Server.
If you feel the need to reach out to Microsoft Support to address this issue, be sure to quote this article so that we can assist you in an efficient manner.

Cheerio!

So back in 2003, when we introduced the world to Outlook 2003, there was a nifty feature that allowed you to create hyperlinks that you could type into your Internet Explorer Address bar, and it would launch Outlook and take you to a specific folder (or mail item or such and such).

Come Outlook 2007, we were a little more concerned about the security of our Office products, and in an attempt to prevent unauthorized access by all those risky applications out there, we semi-limited the facility to use those hyperlinks to navigate to your favourite items at the drop of a hat.

I say “semi-limited” because we didn’t take it away altogether. We took it away to some extent because, lets face it, it wasn’t the most popular feature of Outlook and not used by so many. However, we didn’t take it away altogether because we really don’t want to deny our customers something that once was.

So if you’re really keen on wanting to click on a hyper-link that looks like this:

Outlook:Inbox

which takes you to your Inbox when you click on it, or a more hardcore

outlook:0000000089D557774599D7468A4A47E129F996EF07005818FE9CC903F8418B813D98D476……………

which opens the item associated with that particular identifier, all you have to do is register a custom URL protocol on your machine.

You can figure out how to register an application (any application… could be one of your own) to a URL protocol over here: https://msdn.microsoft.com/en-us/library/aa767914%28v=vs.85%29.aspx

To make it even simpler for you all (as I always like to do), this is what it would look like on an Outlook 2010 machine running on a 64-bit OS:

[HKEY_CLASSES_ROOT\outlook]

@="URL:Outlook"

"URL Protocol"=""

[HKEY_CLASSES_ROOT\outlook\DefaultIcon]

@="\"C:\\Program Files (x86)\\Microsoft Office\\Office14\\Outlook.exe\""

[HKEY_CLASSES_ROOT\outlook\shell]

@="open"

[HKEY_CLASSES_ROOT\outlook\shell\open]

[HKEY_CLASSES_ROOT\outlook\shell\open\command]

@="\"C:\\Program Files (x86)\\Microsoft Office\\Office14\\Outlook.exe\" /select \"%1\""

To use that against Outlook 2007, the path to Outlook.exe would contain Outlook12 instead of Outlook14, and if you’re on a 32-bit OS, then… well, you know the drill.

Do be wary of the Security dialogs you’ll have to handle once you click on the URL… after all, application security is supreme and we don’t want a malicious application going ahead and deleting all your valuable (or not so valuable) communication, no do we!

Happy Developing, folks!

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

The request failed schema validation: The element <CalendarItem/Contact/…> in namespace 'https://schemas.microsoft.com/exchange/services/2006/types' has invalid child element 'ReminderMinutesBeforeStart/ExtendedProperty/…' in namespace 'https://schemas.microsoft.com/exchange/services/2006/types'. List of possible elements expected: <List of elements related to your ItemType> in namespace  'https://schemas.microsoft.com/exchange/services/2006/types'.

*Text in this colour may vary from one situation to another

Let’s say this was the request that you had sent:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:CreateItem MessageDisposition="SendOnly">
      <m:Items>
        <t:Message>
          <t:ToRecipients>
            <t:Mailbox>
              <t:EmailAddress>user1@org1.com</t:EmailAddress>
            </t:Mailbox>
            <t:Mailbox>
              <t:EmailAddress>user2@org2.com</t:EmailAddress>
            </t:Mailbox>
          </t:ToRecipients>
          <t:Subject>Subject of Email</t:Subject>
          <t:Body BodyType="HTML">This is the Body</t:Body>
        </t:Message>
      </m:Items>
    </m:CreateItem>
  </soap:Body>
</soap:Envelope>

and the response you received wasn’t quite the CreateItemResponse with the blissful “NoError” Response Code but instead a  “The request failed schema validation”…

If you were to attempt performing the same action but leveraging an API such as the Exchange Web Services Managed API, you’d find a very similar looking call generated.

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <m:CreateItem MessageDisposition="SendOnly">
      <m:Items>
        <t:Message>
          <t:Subject>Subject of Email</t:Subject>
          <t:Body BodyType="HTML">This is the Body</t:Body>
          <t:ToRecipients>
            <t:Mailbox>
              <t:EmailAddress>user1@org1.com</t:EmailAddress>
            </t:Mailbox>
            <t:Mailbox>
              <t:EmailAddress>user2@org2.com</t:EmailAddress>
            </t:Mailbox>
          </t:ToRecipients>
        </t:Message>
      </m:Items>
    </m:CreateItem>
  </soap:Body>
</soap:Envelope>

So what’s different, really? The answer is hidden in the subtlety of the ordering of the elements in your call. Specifically, whereas in the manually authored XML request, we specified our elements of choice in the sequence ToRecipients, Subject and Body, EWS Managed API decided to re-order it to Subject, Body and ToRecipients.

So who/what is it that decides which ordering is correct and which isn’t? What happens if we decide to include other elements, such as CCRecipients, BCCRecipients, Attachments? Where do we fit them in?

The answer to the above question lies in… Documentation!

Glance through the XML syntax for an Exchange e-mail message, and you’ll find that the XML elements in XML Request 2 corresponds more closely to the ones in XML Request 1. Moreover, if you sift through the XML Response of a successful call that returns some items, you’ll find them in the exact ordering as in the documentation.

You can find the orderings for Contact, Calendar Items, Task and many more in the MSDN documentation.

So should you come across this error message, fret not. The solution is as simple as 1 – 2 – 3 (instead of 1 – 3 – 2 or 2 – 1 – 3 or… well, you get the idea…)

Cheers!

So your organization migrated to Exchange Server 2010, and you thought you’d take that opportunity to leverage Role Based Access Control to limit Impersonation rights of your service account to a select set of users by creating a ManagementScope that would filtering the relevant users on the basis of, say, their membership to a Service/Distribution Group, or any other relevant filterable properties, by executing the elementary set of cmdlets here.

So you went ahead and created a Security Group, say “Impersonated Users”, and created a Management Scope called “ImpersonationScope” to filter out all the users who are members of “Impersonated Users”, say with something like this:

New-ManagementScope -Name:ImpersonationScope -RecipientRestrictionFilter: {MemberOfGroup -eq "Impersonated Users"}

Then you went ahead and provisioned impersonation rights to your Service Account, say ServAccount, allowing him to impersonate all the members within the above scope, with something like this:

New-ManagementRoleAssignment –Name:impersonationAssignment –Role:ApplicationImpersonation –User:ServAccount –CustomRecipientWriteScope:ImpersonationScope

Then you went ahead and fired up your good old, super-reliable, tried and tested application, and lo behold, it tells you…

Message: The account does not have permission to impersonate the requested user.
Type: Microsoft.Exchange.WebServices.Data.ServiceResponseException
Source: Microsoft.Exchange.WebServices
ErrorCode: ErrorImpersonateUserDenied
ErrorMessage: The account does not have permission to impersonate the requested user.

*Grrrr*! What could we possibly be doing wrong here? You go ahead and repeat the entire process, just to be very sure, but nothing helps.

Then you fire up your browser, and open up your favourite Search Engine, type in a random assortment of keywords, say “Impersonation Exchange 2010 RBAC Security Group Awesome Blog” and lo behold, you land up here.

So what exactly could we be doing wrong?

It so happens that in the process of enhancing the awesomeness of Exchange Server 2010 (with the uber-cool RBAC), we sort-of, kind-of didn’t configure it to completely comprehend what [Insert-Your-Equivalent-of-Security-Group-Impersonated-Users-Here] is referring to, as documented here. In light of this, umm, situation the work-around (not so much of a work-around but a rather perfectionist way of approaching it) would be to specify the Active Directory Distinguished Name of the group while creating the Management Scope (This elusive ADDN can be found through a pretty nifty tool called ADSI Edit).

The revised New-ManagemetScope cmdlet would look as follows:

New-ManagementScope -Name:ImpersonationScope -RecipientRestrictionFilter: {MemberOfGroup -eq "CN=Impersonated Users,CN=Users,DC=yourserver,DC=com"}

And lo behold, it works!

So give it a run, and have a bit of fun.
Holler in the comments if your deed isn’t done.