To access another users mailbox with Exchange WebServices, the primary email address of that mailbox is required. Secondary email addresses just don’t work. But if that all one’s got, the secondary email address needs to be resolved to the primary email address. The ResolveNames operation seems a good candidate for that job. But feeding that operation with a secondary email address will yield no results.

The ResolveNames operation executes an ANR search (Ambiguous name resolution) request on Active Directory, which translates (at least in part) to: (|(…)(proxyAddresses=address*)(…)). But the syntax of the proxyAddresses field is different: It is a multi-valued field where each entry has the form protocol:address. For normal email addresses, an entry looks like this: smtp:jdoe@contoso.com.

To resolve a secondary email address, the ResolveNames operation has to be called with something like smtp:jdoe@contoso.com.

2009-04-18: Microsoft has indeed a knowledgebase article on this topic and there is a hotfix availbe.

The .NET Framework has a nice class called X509Certificate2 that simplifies the handling of X.509 certificates. Specifically, it has a constructor that takes a byte array that allows a developer to load a certificate from an arbitrary storage like a database. The class uses some Win32 to parse the byte array, and one of the used functions contain a bug: During the load process, two empty temporary files are created in the temporary files directory of the user running the code. Unfortunately, these files are never cleaned up, so they accumulate over time. What’s worse, they seem to be created by the GetTempFilename function. This function creates an empty file in a specific directory with a name guaranteed to be unique. These files have a prefix (up to three letters) and a number. The number is generated by the GetTempFilename function in a sequential manner. Since the two files are never deleted by the Win32 function, the call to GetTempFilename takes longer and longer. In my case, I had over 65.000 files in the temporary files directory and the X509Certificate2 constructor took several seconds to complete.

Microsoft knows about this bug, but they don’t seem eager to fix it. More details can be found on this connect link: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=284551.

Since there will be no fix in the near future, you can use this workaround: Instead of loading the certificate from a byte array, dump it to a file and read it from there. The following snippet demonstrates this workaround:

   1: public static X509Certificate2 LoadCertificate(byte[] buffer)

   2: {

   3:     if (buffer == null) throw new ArgumentNullException("buffer");

   4:  

   5:     string filename = Path.GetTempFileName();

   6:     try

   7:     {

   8:         File.WriteAllBytes(filename, buffer);

   9:         return new X509Certificate2(filename);

  10:     }

  11:     finally

  12:     {

  13:         try

  14:         {

  15:             File.Delete(filename);

  16:         }

  17:         catch

  18:         {

  19:             // This is ok - the file is in the temporary files directory. No harm done.

  20:         }

  21:     }

  22: }

Hotfix

The knowledgebase article 931908 deals with this problem and offers a hotfix. The hot fix can be requested directly from the article.

The database used by Exchange is quite a versatile one. A developer can save custom data on each item by creating additional properties.

Generally, there are two types of identification for a property: Either, a property id used (for example PR_ENTRYID which has an id of 0x0fff) or a name. Additionally, some properties live in so called property sets, like most of the task fields. There are some predefined property sets, but a developer can choose to create his own. Since property sets are identified by a GUID, it is rather unlikely that two developers select a property set which collide with each other. In addition to the property name, a property also has a data type. The valid types are defined in the MapiPropertyTypeType enumeration.

One property set is of particular interest, namely the one called PublicStrings. All custom properties created with Outlook are stored in this set. If a custom property is designed to be used by custom Outlook formulas, the developer must choose this property set. In any other case, it is better to create a random GUID and use that property set to prevent collisions with other applications.

So, how are these properties accessed? The answer can be found in the PathToExtendedFieldType. The following code reads the custom Outlook property “CustomOutlookProperty”, which has a data type of string from a given item:

   1: public void GetRequest(ItemIdType itemId)

   2: {

   3:     using (var binding = CreateEwsBinding())

   4:     {

   5:         var customOutlookPropertyPath = new PathToExtendedFieldType

   6:             {

   7:                 DistinguishedPropertySetId = DistinguishedPropertySetType.PublicStrings,

   8:                 DistinguishedPropertySetIdSpecified = true,

   9:                 PropertyName = "CustomOutlookProperty",

  10:                 PropertyType = MapiPropertyTypeType.String

  11:             };

  12:         var request = new GetItemType

  13:               {

  14:                   ItemIds = new[] {itemId},

  15:                   ItemShape = new ItemResponseShapeType

  16:                     {

  17:                         AdditionalProperties = new[]

  18:                                {

  19:                                    customOutlookPropertyPath

  20:                                }

  21:                     }

  22:               };

  23:  

  24:         var response = binding.GetItem(request);

  25:  

  26:         // Need to check response for errors. Ommited for clarity

  27:  

  28:         var item = ((ItemInfoResponseMessageType) response.ResponseMessages.Items[0]).Items.Items[0];

  29:         var customOutlookPropertyValue =

  30:             (from extendedProperty in item.ExtendedProperty

  31:              where

  32:                  extendedProperty.ExtendedFieldURI.DistinguishedPropertySetId == DistinguishedPropertySetType.PublicStrings &&

  33:                  extendedProperty.ExtendedFieldURI.PropertyName == "CustomOutlookProperty"

  34:              select (string) extendedProperty.Item).FirstOrDefault();

  35:     }

  36: }

The important thing happens in lines 5 through 11. Theses lines define the path to the custom outlook property.

If you want to access a custom property that should not be directly available via Outlook, create a custom GUID for your application. For this example, I use this code:

   1: private static readonly Guid PrivatePropertySetId = new Guid("9C24B417-DDC1-4F5F-974D-E35FCF6E9FE2");

Then, replace the lines 5 through 11 with this code:

   1: var customOutlookPropertyPath = new PathToExtendedFieldType

   2:     {

   3:         PropertySetId = PrivatePropertySetId.ToString(),

   4:         PropertyName = "CustomProperty",

   5:         PropertyType = MapiPropertyTypeType.String

   6:     };

To extract the property from the response, use this snippet:

   1: var item = ((ItemInfoResponseMessageType) response.ResponseMessages.Items[0]).Items.Items[0];

   2: var customPropertyValue =

   3:     (from extendedProperty in item.ExtendedProperty

   4:      where

   5:         PrivatePropertySetId.ToString().Equals(extendedProperty.ExtendedFieldURI.PropertySetId, StringComparison.OrdinalIgnoreCase) &&

   6:          extendedProperty.ExtendedFieldURI.PropertyName == "CustomProperty"))

   7:      select (string) extendedProperty.Item).FirstOrDefault();

Note, that I used the the Equals method along with the comparison mode OrdinalIgnoreCase to compare the two property set ids.

This is some sort of follow up to yesterdays post about custom OWA forms. If a user opens an OWA form for editing, OWA opens the edit form for the item in a new window. In most forms, a click on the “Save” button will also close this window and OWA will reload the preview window as well as the items list via a custom AJAX call. Unfortunately, Microsoft has not documented how to do this for custom forms, so the method described here is to be considered totally unsupported, and it may stop to work with any future service pack or roll-up.

Two javascript functions have to be called to execute a refresh of both the preview pane and the items list:

   1: window.opener.ref();      // refresh the list view

   2: window.opener.udRP(1);    // refresh the reading pane

   3: window.close();           // close the edit window

If you followed my steps from the last post, you can use a standard button (or link button) to create your own save button. In that case, use the following code to emit the required script:

   1: protected void SaveButton_Click(object sender, EventArgs e)

   2: {

   3:     if (!Page.IsValid)

   4:     {

   5:         return;

   6:     }

   7:  

   8:     // Do what is necessary to save the changes made by the user

   9:         

  10:     Response.ClearContent();

  11:     Response.Write("<script language='javascript'>window.opener.ref(); window.opener.udRP(1); window.close();</script>");

  12:     Response.End();

  13: }

With Service Pack 1, Microsoft introduced some features with Outlook Web Access that allows a developer to create custom forms. These custom forms can be used to display and edit items with custom message classes, much like Outlook does. Details of these features can be found on MSDN here and here and fellow MVP Glen Scales has an example here. Basically, all one needs to do is creating some formulas (in the form of .aspx files) and a registry.xml, describing the mapping of IPM message classes (say IPM.Note.Custom) to these formulas. Simple enough. And since aspx files are easy to develop, it should be a piece of cake to create a full-fledged solution.

So, here is the catch – To retain a single-sign on experience, all the forms have to be put in a directory beneath the directory C:\Program Files\Microsoft\Exchange Server\ClientAccess\Owa\forms. Then, a web-application has to be created that runs in the default OWA application pool (MSExchangeOWAAppPool). This way, OWA will handle all the authentication stuff and you can use it to call Exchange WebServices. The problem with this approach is this: OWA uses an HttpModule (Microsoft.Exchange.Clients.Owa.Core.OwaModule, implemented in the assembly Microsoft.Exchange.Clients.Owa.dll) that inspects every request that is made to a file beneath the /owa virtual directory. At least, every file that is controlled by the ASP.NET runtime. Any direct request will be rejected. This leads to two problems:

1. When the custom form is rendered in the client browsers, the forms action attribute will point to something like “/owa/forms/customform/editform.aspx”. Any attempt to post back to this location will fail.
2. ASP.NET uses a javascript to execute the post back. Even just a standard HTML button is used. But part of the required javascript is loaded from an external script. And since .NET 2.0, a handler called WebResource.axd is used to serve this script. Again, OWA will block any attempt to load this script.

The solution to the first problem is quite simple: ASP.NET allows the modification of the form tag from a code-behind file:

   1: protected override void OnLoad(EventArgs e)

   2: {

   3:     base.OnLoad(e);

   4:     if (Form.Action.IsNullOrEmpty())

   5:     {

   6:         Form.Action = "/owa/" + Request.Url.Query;

   7:     }

   8:     Response.Cache.SetExpires(DateTime.Now);

   9:     Response.Cache.SetLastModified(DateTime.Now);

  10: }

The important part is implemented in lines 4 to 7. This adjusts the action attribute of the form element to point to a direction OWA accepts. The lines 8 and 9 ensure that the form is always executed again. When omitted, OWA will gladly cache the files for quite some time – even if the underlying element changes.

The second problem does not have such an elegant solution. In fact, it now gets quite messy. Since OWA blocks access to the WebResource.axd handler, the only solution I found is to create a new web application project, start it up and manually download the script referenced in the standard aspx file. Once done, give the script a frindly name (something like DefaultScript.js) and put it in the folder of your custom forms and reference the script file from within your custom form with a <script> tag:

   1: <script language="javascript" src="/owa/forms/crmproject/DefaultScript.js"></script>

If you try to set the owner of a task using Exchange WebServices, the server will tell you that this is not allowed. To circumvent this restriction, you’ll have to set the MAPI property directly. This is done by creating an ExtendedPropertyType instance and adding that to an UpdateItemType.

   1: var modification = new PathToExtendedFieldType

   2:     {

   3:         DistinguishedPropertySetId = DistinguishedPropertySetType.Task,

   4:         DistinguishedPropertySetIdSpecified = true,

   5:         PropertyId = 0x811f,

   6:         PropertyIdSpecified = true,

   7:         PropertyType = MapiPropertyTypeType.String

   8:     }, value);

However, this won’t work when creating new items. Exchange will return an error complaining about an invalid PropertySet id. The only solution I found is to issue a CreateItem request first. On this request, the task owner is omitted. After the item has been created, use the ItemId from the CreateItem response and execute an UpdateItem request setting only the task owner.

This is the fourth article about the .NET component I published at CodePlex recently. To all related articles, click here.

If you subscribe to a folder on an Exchange mailbox or public folder, the server will try to send notifications to the registered endpoint of yours upon every modification. If your application is shutdown, Exchange will try to reach it for a certain amount of time. Once this time span has elapsed, it will delete the subscription. If the application is restarted and a new subscription is created, it will be notified about all subsequent events. But for certain use cases, it is imperative that no events are missed – even events which occurred between application downtime must be catched. One example for this is a synchronization applications which keeps a sql server database (like a CRM application) and Exchange folders in sync.

For these types of scenarios, all Exchange events carry a watermark with them. This watermark is opaque to the client, but for the Exchange server it contains enough information to reconstruct changes made since the watermark was received. To use this features, an application has to save each watermark it gets. The watermark can be sent to the Exchange server along with the subscription request for a folder. Exchange will then replay the events which happened since that watermark has been generated.

I’ve implemented this feature in my Push Notification component in the SubscriptionCollection class. It can be serialized to either a System.IO.Stream or System.Xml.XmlWriter. The latter one uses the System.Runtime.Serialization.DataContractSerializer to perform the serialization. And the way it is used, it requires .NET Framework 3.5 Service Pack 1. If you cannot rely on having this version installed on your clients machines, you should probably use the binary serialization instead.

Here is a small code sample on how to use the serialization feature (this is an example only, so the exception handling is far from optimal…)

   1: using System;

   2: using System.ComponentModel;

   3: using System.IO;

   4: using System.Net;

   5: using InfiniTec.Exchange.Notifications;

   6: using InfiniTec.Threading;

   7:  

   8: namespace NewMailNotificationExample

   9: {

  10:     internal class Program

  11:     {

  12:         private const string _StateSaverFilename = "notificationstate.bin";

  13:  

  14:         private static void Main()

  15:         {

  16:             // Ignore any certificate errors

  17:             ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

  18:             

  19:             // Setup the adapter which will be used to call into the Exchange WebService  

  20:             var adapter = new ExchangeWebServicesAdapter(new Uri("https://w2k3x64/ews/exchange.asmx"),

  21:                                                          new NetworkCredential("administrator", "password", "contoso"));

  22:  

  23:  

  24:             // Setup a listener that listens on port 80 on the local computer          

  25:  

  26:             using (var listener = new PushNotificationListener())

  27:             {

  28:                 Console.Out.WriteLine("Starting Notification Service...");

  29:                 listener.Start();

  30:  

  31:                 SubscriptionCollection subscriptionCollection;

  32:  

  33:                 if (File.Exists(_StateSaverFilename))

  34:                 {

  35:                     using (var stream = File.OpenRead(_StateSaverFilename))

  36:                     {

  37:                         subscriptionCollection = SubscriptionCollection.Deserialize(stream);

  38:                         subscriptionCollection.SubscriptionRestartCompleted += 

  39:                             SubscriptionCollection_OnSubscriptionRestartCompleted;

  40:                         subscriptionCollection.SubscriptionRestartProgressChanged +=

  41:                             SubscriptionCollection_OnSubscriptionRestartProgressChanged;

  42:  

  43:                         subscriptionCollection.RestartAsync(listener, adapter);

  44:                     }

  45:                 }

  46:                 else

  47:                 {

  48:                     // Create a new subscription collection to manage all the subscriptions  

  49:                     // Register for a NewMail notification on the inbox of the administrator

  50:                     subscriptionCollection = new SubscriptionCollection(adapter)

  51:                                                  {

  52:                                                      {new[] {new FolderReference(WellKnownFolderId.Inbox)}, EventTypes.NewMail}

  53:                                                  };

  54:                 }

  55:  

  56:                 Console.Out.WriteLine("Creating subscription");

  57:                 foreach (var subscription in subscriptionCollection)

  58:                 {

  59:                     // Write a line to the console for each new mail received  38:  

  60:                     subscription.NewMail += (sender, e) =>

  61:                                             Console.Out.WriteLine(string.Format("{0}: New Mail arrived in your inbox", e.Timestamp));

  62:                     subscription.Start(listener);

  63:                 }

  64:                 Console.Out.WriteLine("Waiting for notifications... Hit [Enter] to quit...");

  65:                 Console.ReadLine();

  66:  

  67:                 Console.Out.WriteLine("Saving the current state of the notification listener...");

  68:                 using (var stream = File.OpenWrite(_StateSaverFilename))

  69:                 {

  70:                     subscriptionCollection.Serialize(stream);

  71:                 }

  72:                 Console.Out.WriteLine("State saved to {0}", Path.GetFullPath(_StateSaverFilename));

  73:             }

  74:         }

  75:  

  76:         private static void SubscriptionCollection_OnSubscriptionRestartProgressChanged(object sender, ProgressChangedEventArgs args)

  77:         {

  78:             Console.Out.WriteLine("Subscription restart {0}% complete.", args.ProgressPercentage);

  79:         }

  80:  

  81:         private static void SubscriptionCollection_OnSubscriptionRestartCompleted(object sender, AsyncCompletedEventArgs<SubscriptionRestartErrorSummary> args)

  82:         {

  83:             Console.Out.WriteLine("Subscription restart is complete. {0} subscriptions could not be restarted.", args.Result.Errors.Count);

  84:         }

  85:     }

  86: }

This essentially is the sample from my first blog post in this series, but enhanced to take advantages of the restart capabilities of the SubscriptionCollection class. The program checks to see if there is a saved state from a previous run available. If found, it is deserialized and restarted (lines 35 to 43). Otherwise a new instance is created. Finally, the events are wired to the individual subscriptions (line 57 to 62). And once the application stops, the current state is serialized to a file.

Since the subscriptions are restarted asynchronously in the background, the SubscriptionRestartCompleted and SubscriptionRestartProgressChanged events are used to keep track of the deserialization process. The progress changed event handler is raised for each subscription restarted. Once complete, the SubscriptionRestartCompleted handler is raise. The event args this event handler contain information about all failed restart attempts.

This is the third article about the .NET component I published at CodePlex recently. To all related articles, click here.

The PushNotificationListener I created for that component uses a WCF endpoint to receive notifications. This means that it needs to open an TCP endpoint of some sort. Thanks to WCF, all the hard stuff is done by the WCF infrastructure. There are, however, two issues which must be resolved before you can receive notifications from your Exchange Server: The Windows Firewall, which blocks all incoming traffic by default and the WCF permission system. To deal with the former, you need to setup an exception for a specific port or for your executable. If you are using Windows Installer Xml, you can use the Firewall Extension to create such an exception during the setup of your application. If you want to do this directly from your application, you will need administrative rights and perform some interop stuff (see the links at the end of the article).

To open an WCF endpoint, you need administrative permissions too, by default. Because this is a very nasty requirement, the system allows you to create so-called reservations which can be tied to specific users. You can use nethsh.exe to manipulate these permissions. You can also use the httpcfg.exe tool. Or, you save you the headache that comes with these tools and head over to Paul Wheelers blog and take a look at this blog post of him: AddressAccessDeniedException: HTTP could not register URL http://+:8080/<…>. He has published a small tool (full source included) to enumerate and manage WCF port reservations.

Here is a screenshot of the reservations on my machine:

The really only real interesting endpoint here is the second from the bottom: http://+:80/Temporary_Listen_Addresses. This is a reservation in the form of an UrlPrefix String (more about that here on MSDN) that can be used by everyone (and Dominick Baier on leastprivilege.com has a nice post about the security ramifications here). However, the reservation is there and we can use it for the PushNotificationListener. This is the reason why the default port is 80 and the RelativePath property is set to a folder below the Temporary_Listen_Addresses. If you need to use another relative path or even another port, you’ll have to create a reservation for it. You can take a look at the source code of the HttpNamespaceManager tool from Paul Wheelers Blog on how to do this. Again, this is probably best done during setup. Again, if you are using Windows Installer Xml, you can use a managed custom action (using the DTF Framework) to create the necessary reservation during the setup of your application.

Controlling the Windows Firewall with C#

Here are a few links I just found on the internet. I have tested none of them, but they might give you a hint:

http://www.shafqatahmed.com/2008/01/controlling-win.html

http://www.codeproject.com/KB/winsdk/WinXPSP2Firewall.aspx

I just noticed that the contact form was not working correctly since I upgraded to new version of the blog software. Anyone trying to get in touch with me through the contact form - please retry now, I’ll get back to you as soon as possible.

As I wrote in my earlier post, I recently published a component on CodePlex that simplifies using push notifications in your applications. Since I’ve not published a full fledged sample application, I will start with a series of blog posts. I will tag all related articles on this topic with “push notifications”, and you can get a list of all articles with this link: http://www.infinitec.de/?tag=/push+notifications.

I’ll start with a very simple application: A console application that creates one subscription get notifications about new mails arriving in the mailbox of the current user.

   1: using System;

   2: using System.Net;

   3: using InfiniTec.Exchange.Notifications;

   4:  

   5: namespace ExchangeNotificationTestClient

   6: {

   7:     internal class Program

   8:     {

   9:         private static void Main()

  10:         {

  11:             // Ignore any certificate errors

  12:             ServicePointManager.ServerCertificateValidationCallback += 

  13:                 (sender, certificate, chain, sslPolicyErrors) => true;

  14:  

  15:             // Setup the adapter which will be used to call into the Exchange WebService

  16:             var adapter = new ExchangeWebServicesAdapter(

  17:                 new Uri("https://casserver/ews/exchange.asmx"), 

  18:                 new NetworkCredential("administrator", "password", "contoso"));

  19:  

  20:             // Create a new subscription collection to manage all the subscriptions

  21:             var subscriptionCollection = new SubscriptionCollection(adapter);

  22:  

  23:             // Setup a listener that listens on port 80 on the local computer

  24:             using (var listener = new PushNotificationListener())

  25:             {

  26:                 // Register for a NewMail notification on the inbox of the administrator

  27:                 subscriptionCollection.Add(

  28:                     new[] {new FolderReference(WellKnownFolderId.Inbox)}, 

  29:                     EventTypes.NewMail);

  30:                 Console.Out.WriteLine("Starting Notification Service...");

  31:                 listener.Start();

  32:  

  33:                 Console.Out.WriteLine("Creating subscription");

  34:  

  35:                 foreach (var subscription in subscriptionCollection)

  36:                 {

  37:                     // Write a line to the console for each new mail received

  38:                     subscription.NewMail += (sender, e) => 

  39:                         Console.Out.WriteLine(string.Format("{0}: New Mail arrived in your inbox", e.Timestamp));

  40:                     subscription.Start(listener);

  41:                 }

  42:  

  43:                 Console.Out.WriteLine("Waiting for notifications... Hit [Enter] to quit...");

  44:  

  45:                 Console.ReadLine();

  46:             }

  47:         }

  48:     }

  49: }

There are four important classes used in this example:

1. The ExchangeServiceAdapter (created in line 16) is used to actually perform the Web Services calls to the Exchange Server (CAS Role). It’s a rather simple implementation, as it does not support AutoDiscover. You have to specify the Exchange server manually. It does, however, support Exchange Impersonation. And if you want to subscribe to events on public folders, you’ll have to enable this feature by setting the ExchangeServiceAdapter.IsPublicFolderAccessEnabled to true. Your Exchange Server must have Service Pack 1 installed to use this feature.
2. The PushNotificationListener (created in line 24): This class does all the necessary WCF plumbing to setup a host, receives the notifications and channels them to the right subscription.
3. The SubscriptionCollection: (created in line 21) It’s not really necessary, but it makes is more easy to handle multiple subscriptions.
4. The Subscription (created in line 27). You can either create a subscription by calling SubscriptionCollection.Add(), or create a subscription directly via “new Subscription()”.

Both, the PushNotificationListener and the Subscription need to be started to do some actual work. And that’s all you need to do to get a simple notification client up and running. However, there are some security settings to consider, because WCF doesn’t let you run around and open endpoints on your users machines. Additionally, the Windows Firewall needs to be configured correctly to let the notifications through. I’ll discuss this in a separate post.