Few of our customer reported that they are getting HTTP 404 Error reported; when they tries to use EWS HTTP service endpoint for their application for Exchange Server 2010 . However, the same application work fine with EWS HTTP service endpoint with Exchange Server 2007 without any issue. If we go into Internet Information Services (IIS) on Exchange 2010 RTM and uncheck the box 'Require secure channel (SSL)' on the EWS virtual directory. And then we attempt to make a request using HTTP using EWS

If you are developing using Exchange Web Services Managed API then now you can download @ Microsoft Exchange Web Services (EWS) Managed API 1.0 The Microsoft Exchange Web Services (EWS) Managed API 1.0 provides a managed interface for developing client applications that use Exchange Web Services. The EWS Managed API simplifies the implementation of applications that communicate with Microsoft Exchange Server 2007 Service Pack 1 (SP1) and later versions of Microsoft Exchange. Built on the Exchange

Over the past year I’ve been working with the new Exchange Web Services Managed API and I have to say, it’s a wonderful thing – especially compared to working with the Visual Studio generated proxy classes for Exchange Web Services.  While working with Exchange Web Services (EWS) early in the Exchange 2007 release it became apparent to me that an editor tool in the spirit of MFCMAPI built on top of EWS might be useful.  At the time I started working on such an editor and based it off the

Exchange 2010 is on it way and along with it Exchange Web Services Managed API would be one-in-all interface for developing custom applications. So, If you are developing Exchange related application and interested to know what you can do with the new EWS Managed API and what’s new in Exchange 2010 for developers then, Here are few interesting web casts to learn more:  10/13/2009 - Exchange Server 2010 Development (Part 1 of 6): Migrating Applications to Exchange Web Services 10/14/2009 - Exchange

Prior to Exchange 2007 SP1 an article was published with some specific guidance related to handling time zones in calendar item tasks.  Contrary to Best Practices for Using Exchange Web Services for Calendaring Tasks , specifying just a MeetingTimeZone TimeZoneName when creating a CalendarItem appears to work in Exchange 2007 SP1 and later.  The best practices says not to submit the TimeZoneName in MeetingTimeZone because it will be ignored, though there is a hint that this might not apply

Earlier I linked to a post by Henning Krauses which discusses searching for a meeting using the UID and GlobalObjectId properties. The point of UID is to provide a unique identifier for a meeting across the calendars each attendee to the same meeting. Henning gave some expert advise for using GlobalObjectId instead of UID in a FindItem request to locate instances of a recurring meeting in different user’s calendars. As noted in his article, in Exchange 2007 pre-SP2 the UID property is built from

We can use following Exchange PowerShell cmdlet to grant a Service Account full access to all the mailboxes on Exchange Server 2007 mailboxstore, but do so only in accordance with your organization's security and privacy policies: Get -mailboxserver <servername> | add-adpermission –user <service account> -accessrights GenericRead, GenericWrite -extendedrights Send- As , Receive- As , ms-Exch-Store-Admin .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas,

Fellow developer support engineer, Patrick Creehan , has any interesting post about the delta between the documentation of DeleteItem calls and the actual behavior involving including the ChangeKey in the ItemId of the item you want to delete.  In theory the ChangeKey would be required for DeleteItem requests to ensure that you know you have evaluated the latest version of the item and decided to delete it.  If you pass an ItemId with a stale ChangeKey, you should get a error indicating

I kept forgetting about this so maybe blogging it will help me remember.  As this thread confirms – you can’t call GetUserOofSettings, SetUserOofSettings, or GetUserAvailability when using Exchange Impersonation.  If you try to do this you’ll get an error that the Service Account is not the mailbox owner.

The Exchange API team has a new post to explaining the differences between using Exchange Impersonation vs. Delegate Access to access an Exchange mailbox using Exchange Web Services.  I’ve seen first hand that there is a gap in understanding the difference between the two and when to use one versus the other.  This post goes a long way to address some of the confusion. An important note that some people miss is the differentiation between Windows and Exchange impersonation – they’re not