I have seen a few cases now where people are trying to implement custom forms for Public Folder Items under Outlook Web Access (Exchange 2007 Sp1, see here for more details on this functionality).
One problem arises when you run into an item that includes “%2B” in the value for the Id that is passed to the custom form on the Query String. When you use the typical methods of retrieving the value of this field, such as retrieving the value from the QueryString collection that is a member of the System.Web.HttpRequest object, .NET helpfully UrlDecodes the value that is returned. When you turn around and use this value to populate an AlternatePublicFolderItemIdType, which in turn is used to populate a ConvertIdType, which is then used to call ConvertId, you will receive an error indicating that the item could not be found.
The simple solution for this issue is to UrlEncode the Id value before placing it into the AlternatePublicFolderItemIdType, like this:
AlternatePublicFolderItemIdType id = new AlternatePublicFolderItemIdType(); id.Format = IdFormatType.OwaId; id.ItemId = HttpUtility.UrlEncode(Request.QueryString["Id"]);
One of my colleagues correctly pointed out that this round trip UrlDecode/UrlEncode could possibly return a different value than was originally on the raw query string, but I have not found any cases yet where this happens.
A second nuance of this scenario is that the schema for the AlternatePublicFolderItemId Type requires a value for the FolderId field, but when the source type is IdFormatType.OwaId, this value is ignored. Simply populate this field with an empty string and it will pass schema validation.