MVP Henning Krause has some good posts about various different tips and tricks with EWS that are worth looking at…

Searching a meeting with a specific UID using Exchange Web Services 2007

Resolving the primary email address with Exchange WebServices ResolveNames operation

Saving custom data on Exchange elements with The Exchange WebServices

…The UID and custom data posts are particularly insightful.  A key takeaway of the UID post is that “schema properties” or “first-class properties” such as UID often are calculated from or directly relate to “extended properties” or “MAPI properties”.  Often times you can workaround a limitation of schema properties by using the related extended property as Henning does with UID and GlobalObjectID.  In the saving custom data post, Henning gives some good background on named properties as well as why choosing the right property set is important…

"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.”

On the Outlook team blog it was announced recently that Exchange Client Extensions (ECEs) will not work with Outlook 2010.  This shouldn’t come as a big surprise, they haven’t been a primary extensibility model for Outlook since Outlook 97-98 days.  However, many Outlook developers have continued to maintain their ECEs and Microsoft supports them to work on Outlook versions up to Outlook 2007.  Here are the suggestions from the blog post about how to move forward…

“To redesign your solution, you should consider the following options:

• Rewrite your ECE as a COM Add-in using native or managed code. Unlike ECEs, an add-in represents a strategic extensibility technology that is fully supported in Outlook 2010. Using an Outlook add-in, you can build Outlook form regions and extend the Office Fluent User Interface. For additional information, please visit the Outlook Developer Portal on MSDN.
• Rewrite your ECE as a Windows service application using native code and MAPI. If you are writing a Windows service application, you must use MAPI to access Outlook items rather than the Outlook object model.”

The Exchange team announced that Exchange 2010 will not have a 32-bit version – not even for evaluations.  The post focuses on mainly the non-developer related impact of this change.  The key points for developers are:

> Applications that automate Exchange cmdlets locally will need to be compiled for 64-bit.

> 32-bit or 64-bit applications could leverage the remote Powershell capabilities in Powershell 2.0 to invoke the Exchange cmdlets remotely.