In my first article about custom forms for Outlook WebAccess I wrote about the difficulties that are associated with the development of custom forms. Thanks to a hint from reader Ciusso I was able to come up with another solutions that makes the whole stuff a lot easier. Here is a walkthrough to create custom forms the easy way – with support for standard postback, AJAX… the whole enchilada. As a prerequisite, download the EWS Managed API. It’s much simpler to use than the Exchange Web Services.
First, start with a new WebProject. If you are developing directly on an Exchange 2007 server (which is hopefully a test machine and not production – don’t do that!), the new solution can be created directly under the directory for custom OWA forms: %ProgramFiles%\Microsoft\Exchange Server\ClientAccess\Owa\forms. This simplifies development because no files have to be deployed after each build.
The problems I outlined in the first article are caused by an HTTP module, which is defined in the web.config file of Outlook WebAccess. The web.config file of Outlook Web Access is located in the folder %ProgramFiles%\Microsoft\Exchange Server\ClientAccess\Owa:
When you open the web.config file, you’ll see that Outlook Web Access adds two assemblies, one HTTP module and two HTTP handlers.
Since the custom form is located beneath the OWA folder, it inherits all its configuration settings from the Outlook Web Access configuration. The trick is to remove the artifacts introduced by Outlook Web Access. For the HTTP module and the two HTTP handlers this is an easy task: As shown in the next picture, just add “remove” tags for each artifact.
Things get more complicated with the assemblies, however. The two assemblies can not be removed via “remove tags”. It seems to be necessary to clear the entire collection of assemblies with a “clear” tag. But this has a nasty side effect: The assembly of the custom form is also removed and needs to be re-added.
The next step is to configure the web application in the IIS Manager: Open the IIS snapin and navigate to the owa virtual directory and then select the directory of the custom form:
Open the properties of the CustomForm directory configure a Web Applicaton by clicking on the “Create” button. Ensure that the application pool is MSExchangeOWAAppPool.
Next, ensure that the ASP.NET version of the application is set to 2.0:
Close the dialog and return to Visual Studio.
The custom form will not be loaded by Outlook Web Access until it finds a registry.xml describing a mapping from an item class to the custom forms. Here is the registry.xml from this example:
1: <Registry xmlns="http://schemas.microsoft.com/exchange/2004/02/formsregistry.xsd" Name="PremiumExtensions" InheritsFrom="Premium" IsRichClient="true">
2: <Experience Name="Premium">
3: <Client Application="MSIE" MinimumVersion="6" Platform="Windows NT" />
4: <Client Application="MSIE" MinimumVersion="6" Platform="Windows 2000" />
5: <Client Application="MSIE" MinimumVersion="6" Platform="Windows 98; Win 9x 4.90" />
6: <ApplicationElement Name="Item">
7: <ElementClass Value="IPM.Note.CustomClass">
8: <Mapping Action="New" Form="https://w2k3x64/owa/forms/CustomForm/EditItem.aspx"/>
9: <Mapping Action="Open" Form="https://w2k3x64/owa/forms/CustomForm/EditItem.aspx"/>
10: <Mapping Action="Preview" Form="https://w2k3x64/owa/forms/CustomForm/ViewItem.aspx"/>
11: <Mapping Action="Reply" Form="https://w2k3x64/owa/forms/CustomForm/EditItem.aspx"/>
12: <Mapping Action="ReplyAll" Form="https://w2k3x64/owa/forms/CustomForm/EditItem.aspx"/>
13: <Mapping Action="Forward" Form="https://w2k3x64/owa/forms/CustomForm/EditItem.aspx"/>
14: </ElementClass>
15: </ApplicationElement>
16: <ApplicationElement Name="PreFormAction">
17: <ElementClass Value="IPM.Note.CustomClass">
18: <Mapping Action="Open" Form="Microsoft.Exchange.Clients.Owa.Premium.Controls.CustomFormRedirectPreFormAction,Microsoft.Exchange.Clients.Owa"/>
19: <Mapping Action="Preview" Form="Microsoft.Exchange.Clients.Owa.Premium.Controls.CustomFormRedirectPreFormAction,Microsoft.Exchange.Clients.Owa"/>
20: <Mapping Action="Reply" Form="Microsoft.Exchange.Clients.Owa.Premium.Controls.CustomFormRedirectPreFormAction,Microsoft.Exchange.Clients.Owa"/>
21: <Mapping Action="ReplyAll" Form="Microsoft.Exchange.Clients.Owa.Premium.Controls.CustomFormRedirectPreFormAction,Microsoft.Exchange.Clients.Owa"/>
22: <Mapping Action="Forward" Form="Microsoft.Exchange.Clients.Owa.Premium.Controls.CustomFormRedirectPreFormAction,Microsoft.Exchange.Clients.Owa"/>
23: <Mapping Action="New" Form="Microsoft.Exchange.Clients.Owa.Premium.Controls.CustomFormRedirectPreFormAction,Microsoft.Exchange.Clients.Owa"/>
24: </ElementClass>
25: </ApplicationElement>
26: </Experience>
27: </Registry>
The mapping above is for the message class “IPM.Note.CustomClass”. It seems that it’s necessary to specify a full-qualified name for the address of the formulars – relative path will not work.
Now, add a reference to the Managed API and the System.DirectoryServices.AccountManagement. Create a new form named “ViewItem.aspx”.
For the sake of simplicity, just add this fragment to the page below the scriptmanager reference:
1: <div>
2: <asp:Label runat="server" ID="Label1" Text="Subject: " />
3: <asp:Label runat="server" ID="SubjectLabel" Text="Subject" />
4: </div>
In the code behind file, add the following code:
1: using System;
2: using System.DirectoryServices.AccountManagement;
3: using System.Net;
4: using System.Security.Principal;
5: using System.Web;
6: using System.Web.UI;
7: using Microsoft.Exchange.WebServices.Data;
8:
9: namespace CustomForm
10: {
11: public partial class ViewItem : Page
12: {
13: static ViewItem()
14: {
15: ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, errors) => true;
16: }
17:
18: protected string OwaItemId
19: {
20: get { return HttpUtility.UrlEncode(Request["id"]); }
21: }
22:
23: protected string ContentClass
24: {
25: get { return Request["t"]; }
26: }
27:
28: protected string State
29: {
30: get { return Request["s"]; }
31: }
32:
33: protected string Action
34: {
35: get { return Request["a"]; }
36: }
37:
38: protected void Page_Load(object sender, EventArgs e)
39: {
40: Item item = LoadItem();
41: SubjectLabel.Text = item.Subject;
42: }
43:
44: private Item LoadItem()
45: {
46: using (((WindowsIdentity) HttpContext.Current.User.Identity).Impersonate())
47: {
48: string emailAddress = UserPrincipal.Current.EmailAddress;
49: var exchangeService = new ExchangeService(ExchangeVersion.Exchange2007_SP1)
50: {
51: Url = new Uri("https://localhost/ews/exchange.asmx"),
52: UseDefaultCredentials = true
53: };
54: ServiceResponseCollection<ConvertIdResponse> convertIds =
55: exchangeService.ConvertIds(new[] {new AlternateId(IdFormat.OwaId, OwaItemId, emailAddress)},
56: IdFormat.EwsId);
57: ServiceResponseCollection<GetItemResponse> items =
58: exchangeService.BindToItems(new[] {new ItemId(((AlternateId) convertIds[0].ConvertedId).UniqueId)},
59: new PropertySet(BasePropertySet.FirstClassProperties));
60: return items[0].Item;
61: }
62: }
63: }
64: }
In the static constructor, SSL certificate checking is effectively disabled. Since this example binds to the Exchange Server with the hostname "localhost”, certificate would fail regardless of the certificate used.
All the heavy lifting is done in the LoadItems method. In the first line the code impersonates the user logged on to OWA. The next step requires a prerequisite: The website gets the OWA id of the item. this id cannot directly be used with the Exchange Web Services (or the EWS Managed API, for that matter). The ExchangeService.ConvertIds method is used here. But that method requires the primary email address of the user the OWA id belongs to. For simple environments (read: the mail attribute of the user object in Active Directory contains the primary email address), the method used here can be used. The System.DirectoryServices.AccountManagement.UserPrincipal class was introduced with .NET 3.5 and offers a very simple way to get the required information. After the ID has been converted to an EWS id, the item can finally be loaded from the store. In this example, only the subject of the item is displayed on the form.
Finally, you need to restart the IIS – contrary to what to official documentation states, Outlook Web Access only scans for new custom forms on startup and not periodically. You need to keep this in mind when deploying your solution. After the IIS has been restarted, you can check wether the custom form has been loaded by taking a look at the EventLog. If the form was loaded successfully, you’ll find an entry similar to this one:
The form created here will be used to preview every item with the message class of IPM.Post.Custom.
The solution containing the relevant files for this example is attached to this post. The file has a digital signature to ensure it’s not modified.
The FindItem operation (or the corresponding ExchangeService.FindItems method) does not return the body of an email by default. And when trying to explicitly request them via a custom propertyset, the call fails. Consider this method, which uses the EWS Managed API to execute a FindItems method to get every message from the inbox folder of a mailbox, fetching only the item id and the body:
1: private static void GetAllItems(ExchangeService exchangeService)
2: {
3: var offset = 0;
4: const int pageSize = 100;
5:
6: FindItemsResults<Item> result;
7: do
8: {
9: var view = new ItemView(pageSize, offset)
10: {
11: PropertySet = new PropertySet(BasePropertySet.IdOnly)
12: {
13: ItemSchema.Body
14: }
15: };
16:
17: result = exchangeService.FindItems(WellKnownFolderName.Inbox, view);
18:
19: foreach (var item in result)
20: {
21: ProcessItem(item);
22: }
23: offset += pageSize;
24: } while (result.MoreAvailable);
25: }
When executed, the ExchangeService instance throws a ServiceValidationException stating “The property Body cannot be used in FindItem requests”. The official workaround proposed by Microsoft is to use a FindItem request to get the item ids of the items in a folder and afterward issue a GetItem request containing all the item ids and request the body property. However, there is another solution: The body properties can be fetched by requesting the MAPI properties containing the body:
1: private static ExtendedPropertyDefinition TextBodyProperty = new ExtendedPropertyDefinition(0x1000, MapiPropertyType.String);
2: private static ExtendedPropertyDefinition HtmlBodyProperty = new ExtendedPropertyDefinition(0x1013, MapiPropertyType.Binary);
The first property definition can be used to fetch the text body of a mail. The second one fetches the Html body. The new GetAllItemsMethod now looks like this:
1: private static void GetAllItems(ExchangeService exchangeService)
2: {
3: var offset = 0;
4: const int pageSize = 100;
5:
6: FindItemsResults<Item> result;
7: do
8: {
9: var view = new ItemView(pageSize, offset)
10: {
11: PropertySet = new PropertySet(BasePropertySet.IdOnly)
12: {
13: HtmlBodyProperty
14: }
15: };
16:
17: result = exchangeService.FindItems(WellKnownFolderName.Inbox, view);
18:
19: foreach (var item in result)
20: {
21: object body;
22: if (item.ExtendedProperties.TryGetValue(HtmlBodyProperty, out body))
23: {
24: Console.Out.WriteLine("item.Body = {0}", Encoding.UTF8.GetString(Convert.FromBase64String((string)body)));
25: }
26: }
27: offset += pageSize;
28: } while (result.MoreAvailable);
29: }
The HtmlBody is requested with the addtion of the HtmlBodyProperty to the ItemView in line 13. Since the Html body is stored in binary form and returned in Base64 encoded format, it needs to be decoded before it can be displayed. This is done in line 24. If the plaintext body is requested, the value of the body property in line 24 can simply be converted to a string.
Currently rated 5.0 by 1 people
- Currently 5/5 Stars.
- 1
- 2
- 3
- 4
- 5