Exchange API-spotting : Announcements

The December SDK is Here!

Ray Dixon — Wed, 10 Dec 2008 23:45:00 GMT

I am happy to announce that the December 2008 release of the Exchange Server 2007 SP1 SDK is available. And now, a Haiku for you.

Released new content.
Updated topics for you.
Go get the goods here.

Learn about the Exchange Web Services Managed API and how Exchange is getting “Cloud Ready” at PDC’08

JasonHen — Thu, 16 Oct 2008 00:23:00 GMT

Those of you who have already made plans to catch PDC ’08 in L.A. at the end of October be sure to catch the Exchange Web Services Managed API: Unified Communications Development for Exchange session. This exciting talk will be the coming out party for the managed API; it will be the first time that the API has been shown in public. We’ll have live coding, demo’s, and of course answer your questions on everything Exchange development. I’m looking forward to seeing you in L.A.!

Jason Henderson

Exchange Web Services Update Rollup 4 Roundup

JasonHen — Tue, 07 Oct 2008 22:32:00 GMT

We have just released update rollup 4 (RU4) for Exchange 2007 SP1. This rollup fixes some bugs in Exchange Web Services (EWS), and introduces some behavior changes to EWS to allow customers and partners the flexibility to accomplish some key scenarios. If you have written code against Exchange Web Services, we definitely recommend that you take a look at RU4. The following are the biggest changes that will be coming in the rollup:

- Item IDs are now returned after MoveItem/CopyItem calls.

- Unknown/unsupported item types are returned as Messages.

- Updating tasks can now have correct behavior for Start and Complete Date values.

ItemId of Item Is Returned After a MoveItem/CopyItem Call

Some of our observant developers have noticed that Exchange creates new destination item IDs for items when they are moved between folders. We created a place in the schema to return the destination ID of an item, and in the early stages of Exchange development, this ID was returned. We pulled it out late in the Exchange 2007 development cycle after we determined that the method of determining the destination ID was too resource-intensive. After consistent feedback from customers that this feature was needed so that items could be tracked as they were moved between folders, we implemented a much more performant solution. Now, if you call MoveItem/CopyItem, you’ll be able to identify the new item in the destination folder by looking at the destination ID that is returned by the MoveItem/CopyItem call.

Note: Cross-mailbox or mailbox-to-public folder CopyItem/MoveItem calls will not return destination IDs and RU4 must be applied to both the Client Access Server and the Mailbox Server Role for this feature to work.

Non-IPM.Note.* Items Are Returned as Messages

EWS in Exchange 2007 SP1 uses the <Item> type as the base class for items that are not strongly typed. This design has caused problems for customers who want to reply to item types that have a custom item class, or item types that EWS does not yet support, like IPM.Sharing or IPM.InfoPath. In RU4, all item types that we do not support natively in Exchange Web Services, like Journal, Sharing Requests, InfoPath forms, are returned as <Message> instead of <Item>. This means that you can see all the recipient information on the item, mark it as unread, reply to it, or forward it just like you would a normal item (assuming that the object supports forwarding/replying).

<Item> type still exists as a base class for <Message>, so most applications built on the auto-generated proxy classes will not be affected; however, applications that parse the XML directly could break if they are expecting <Item> rather than <Message>. To minimize the risk of breaking applications, this behavior is only applied when the Exchange2007_SP1 version header is specified.

We don’t take making changes in a rollup that could break applications lightly; our goal is to only change protocol behavior with the introduction of a new version header. However, we felt that this functionality is critical for some of our partners and customers, has a minimal impact on the majority of applications, is the way EWS should have worked in the first place, and can’t wait for the next service pack for Exchange, which could introduce a schema change for a new version header. For more details about this topic, see Robin’s June post that describes the proposed change and asks for feedback.

Updating Recurring Tasks Now Works Correctly

In Exchange 2007 and Exchange 2007 SP1, when a task is updated, such as by marking CompleteDate, the Client Access server shifts the date specified as the complete date according to the offset of its time zone. This is bad because clients are rarely aware of the time zone that the server is operating in. If the Client Access server and the client time zones are far enough apart, tasks could be marked as completed on the wrong day — not good!

The problem is that no time zone information is passed to EWS in tasks, yet a time zone is required when saving/updating/getting tasks to make sure that the task is marked as completed on the correct day. To fix this problem, with RU4, EWS can treat offset date times in a special way when they are the Complete Date, Due Date, or Start Date elements of a task. The offset, for example 10:00:00T-08:00, is used to create a time zone for that offset. This time zone is used when the task is saved so that the date the task was completed is always the date intended.

This post only covers the changes in RU4 that we think are most interesting to Exchange Web Services developers. We will be posting this and additional information in KB articles shortly. We hope you find this information useful and as always appreciate your feedback.

Jason Henderson and Andrew Salamatov

Erratum - Exchange Server 2007 SP1 SDK November 2007 Readme

Ray Dixon — Tue, 15 Jan 2008 00:44:00 GMT

The Readme for the November 2007 release of the Exchange Server 2007 SP1 SDK include an error. The following statement in the Readme is incorrect:

By default, the Setup wizard installs the Exchange Server 2007 SP1 SDK Documentation and Samples on the drive that contains the operating system (usually drive C), in the folder \Program Files\Exchange Server 2007 SP1 SDK\.

The statement should read as follows:

By default, the Setup wizard installs the Exchange Server 2007 SP1 SDK Documentation and Samples on the drive that contains the operating system (usually drive C), in the folder \Program Files\Microsoft\Exchange Server 2007 SP1 SDK\November 2007.

This error is fixed in the online version of the Readme, but is still exists in the Readme that is included in the downloadable version of the SDK.

Exchange Server 2007 SDK has been updated!

Michael.Mainer — Wed, 25 Jul 2007 22:15:12 GMT

The Exchange Developer Documentation Team is happy to announce the July 2007 release of the Exchange Server 2007 SDK. Read the What's New topic to find out what we added in this release. If you’re working with Exchange Web Services, review the new documentation that covers some of the autogenerated proxy types. And if you like installing the SDK and samples locally, download the SDK here.

Thanks again for stopping by our blog.

Michael Mainer
Microsoft Corporation

New and improved - We updated the TechReady 2007 Talk article download

Ray Dixon — Wed, 25 Jul 2007 20:52:49 GMT

If you downloaded the code samples for the Exchange Server Developer Center article TechReady 2007 Talk: Developing With Exchange Web Services, you probably had some problems building the projects, because some of the files didn't make it into the download packages.

We've corrected that and the updated download packages now contain all the files you need to successfully build the projects. We also updated the Readme file with instructions about how to replace the reference to the Exchange Web Services end point, so the projects use your Exchange Web Services installation.

You can find both the English (TechReady2007EWS-en.exe) and French (TechReady2007EWS-fr.exe) download packages on the TechReady 2007 Exchange Web Services Samples download page.

Exchange Developer Documentation Team Wants YOU!

Thomr — Thu, 17 May 2007 21:49:04 GMT

If you’re reading this, you’re VERY likely a developer with at least some Exchange experience. Well, we need you. Really. The Exchange Developer Documentation team has an open position for a Programming Writer. If you want to help improve the Exchange Developer Center, if you want to write cool code samples and clear documentation, if you want a direct connection with both the product team and the developer community, contact me (thomr@microsoft.com) today!

To get an idea what it’s like to work in my team, let’s just say a healthy sense of humor is a plus. The team enjoys working together, we encourage finding innovative ways to create and present developer-focused materials, and we are given the freedom to implement those ideas. We publish the SDKs every few months, technical articles every month, and blog posts like this one at random intervals. We work very closely with the product team, as well as Marketing, and our dear friends in MSDN.

If you like what we’re doing, and want to help us add more information and try new ways of reaching out to the Exchange developer community, give us a ring. We’re looking for someone with a well-balanced mix of writing ability (good writing, excellent organizational skills), development experience (VS.NET, a variety of languages, Web services), and knowledge about one or more Exchange programming technologies. Yeah, sure we’re flexible on those. You do NOT need to be a professional writer with a bunch of books in your name. You do NOT need to be a guru-level Exchange solution developer. But, let’s face it: if you ARE those things, we'd love to hear from you! You will definitely need to learn quickly and understand complex technologies clearly enough to explain them to others.

On a daily basis we all do a bit of writing, programming, debugging, looking at product source code to understand how an API works, planning for the next release, and answering questions from a variety of good-natured people. We sit in meetings, we go to lunch, and do all the normal things of working for a living at Microsoft.

To get the official scoop on the position, check it out here . Give me a call (425-705-8271) or e-mail your resume (thomr@microsoft.com) if you think you might fit well here. Ray, Laura, Michael and I would like to meet you! And of course, if you know someone else who might fit our needs, be sure to send them our way!

Thom Randolph
Documentation Manager
Exchange Developer Documentation
Microsoft Corporation

Microsoft Office Workflow Designer for Exchange is no longer available

Thomr — Wed, 16 May 2007 00:47:51 GMT

Starting in May 2007, the Workflow Designer for Exchange, and the Exchange SDK Workflow Application Templates will no longer be available for download. Support for existing installations of the Workflow Designer for Exchange (ExWFD) and templates will continue until support for Microsoft Exchange Server 2003 ends.

Contact Microsoft CSS if you need the ExWFD installation package. You can find a complete list of Microsoft Customer Support Services telephone numbers and other information http://support.microsoft.com/contactus/?ws=support.

If you’re creating new workflow-based applications, we recommend using the Windows Workflow Foundation. If you’re maintaining existing applications based on Exchange workflow, consider moving to the Workflow Foundation if the application needs to stay in service for more than a couple years.

What is this WF thing?

Windows Workflow Foundation (WF) is a programming model, orchestration engine, and design tools for quickly building workflow-enabled applications on Windows. WF consists of a .NET Framework namespace, an in-process workflow engine, and designers for Visual Studio 2005. Windows Workflow Foundation applications can be developed and run on Windows Vista, Windows XP, and the Windows Server 2003 family. Windows Workflow Foundation includes support for both system workflow and human workflow across a variety of scenarios. Line-of-business applications, user interface page-flow, document-centric workflow, human workflow, service-oriented composite workflows, business rule-driven workflows, and workflow for systems management are only a few of the applications where WF excels.

Yeah, but Exchange Workflow worked fine for my needs…

There are several reasons why moving away from Exchange Workflow and the Workflow Designer for Exchange, and moving to WF is the right thing:

- WF is Microsoft’s strategic direction for workflow applications.

- WF leverages current technology and a better programming model.

- WF can be used in managed code (ExWFD and CDOWF cannot).

- WF will also be used in other Microsoft applications.

- ExWFD and CDOWF are not compatible with Microsoft Exchange Server 2007.

Need some links?

These links provide more information on the Windows Workflow Foundation.

Windows Workflow Foundation Overview:
http://msdn2.microsoft.com/en-us/library/ms734631.aspx

Windows Workflow Foundation Programming Guide:
http://msdn2.microsoft.com/en-us/library/ms734702.aspx

Windows Workflow Foundation Tutorials:
http://msdn2.microsoft.com/en-us/library/ms735927.aspx

Windows Workflow Foundation Samples:
http://msdn2.microsoft.com/en-us/library/ms741723.aspx

Visual Studio 2005 Designer for Windows Workflow Foundation Overview:
http://msdn2.microsoft.com/en-us/library/ms441543.aspx

Windows Workflow Foundation Developer Center:
http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx

Introduction to workflows on the Microsoft Office SharePoint Server site:
http://office.microsoft.com/en-us/sharepointserver/HA101544241033.aspx?pid=CH101782961033

Understanding Workflow in Windows SharePoint Services and the 2007 Microsoft Office System (5Mb Word Format):
http://www.microsoft.com/downloads/details.aspx?FamilyId=DBBD82C7-9BDE-4974-8443-67B8F30126A8&displaylang=en

Using SQL Server Table-Valued User-defined Functions with Exchange Web Services

Thomr — Wed, 09 May 2007 01:41:33 GMT

A just-posted technical article by Jim Kleewein and Ray Dixon describes how to combine the SQL Server Tables and Exchange Web Services to access your Microsoft® Exchange Server 2007 Inbox data from Microsoft SQL Server™ 2005. This cool integration enables you to provide data from both Microsoft Exchange and SQL Server to client applications so that the data appears as if it were stored in SQL Server. As the article show, this creates some exciting development scenarios. You can find the article here.

Welcome to the Microsoft Exchange Development Blog

Ray Dixon — Wed, 18 Apr 2007 23:32:38 GMT

Hi, and welcome to the Microsoft Exchange Development Blog. This post kicks off a new avenue for getting information to you about Microsoft Exchange development.

We (the Exchange SDK UE team) coordinate the Microsoft Exchange Development Blog and are made up of our Documentation Manager, Thom Randolph, two Programming Writers, Michael Mainer and, me, Ray Dixon, and our editor, Laura Graham. However, we aren't the only people who will post here. Contributers will also include Microsoft Exchange developers, testers, program managers, and more. In the near future, you will see content that describes techniques used in Microsoft Exchange application development, coding tips, and code samples, among other things.

We also want to hear what you have to say and want to know what content you would like to see. Please comment on posts if you have suggestions, questions, criticisms, or kudos. Also, please send us your ideas for blog posts. This helps us tailor the content to you. To share your blog post idea with us, just send an e-mail describing your idea to exsdkfb@microsoft.com.

Thanks for stopping by the Microsoft Exchange Development Blog. We hope you enjoy your (current and future) visit!