If you dig around in the EWS documentation, you’ll find this element: WebClientReadFormQueryString, which should give you a URL for an item in OWA. When Exchange Server 2013 shipped, we had some EWS developers who noticed this element was still giving out URLs in Exchange Server 2010’s OWA URL format, which no longer works with Exchange 2013. If you look in the Remarks for the WebClientReadFormQueryString article, you’ll see we‘ve added documentation to allow you to build URLs for 2013 by hand.
So – what happened? As Kristian describes it, Outlook Web Access in Exchange 2013 is a complete rewrite from the previous versions of OWA. This means a whole lot of new features (like Office Mail Apps), but it also means some features got left out. This article gives the highlights. In that article, you’ll note that Outlook Web App customization, as it existed in earlier versions, is not available in Exchange 2013. Part of this includes the old 2010 style URLs that could be used to create and access different types of items.
So – with Exchange 2013, you can use the format given in the documentation for WebClientReadFormQueryString to create a URL to view an existing email message. We do not have a similar URL format for other types of items, such as Appointments, Contacts, or Tasks. We also do not have a URL format for creation of items.
Now that MAPICDO has been updated to support connecting to Exchange 2013 using RPC/HTTP, and the guidance for programmatically building profiles has been published, Dave has published a pair of articles which will be very helpful for customers using MFCMAPI in such environments. The first covers using the guidance to build a profile for connecting to Exchange 2013:
The second article covers a scenario likely to be encountered during migrations/upgrades, building a profile that works against both Exchange 2013 and Exchange 2010:
It;’s here! It’s finally here! The May 2013 update of MAPICDO is live here:
At that same link, you’ll also find the long awaited configuration guidance. It’s not immediately obvious it’s there. Just hit the Download link and it will be offered to you. As a reminder, this configuration guidance will help you in configuring an RPC/HTTP (aka ROH) profile using this MAPI/CDO download package. These instructions do NOT apply equally to Outlook’s implementation of MAPI. Attempting to use these guidelines to build a profile for Outlook’s MAPI, or attempting to “port” a profile between the two implementations WILL lead to failure.
Recently, I’ve had a few different customers coming to me asking about Outlook’s interaction with the Credential Manager. If you’ve not looked at the Credential Manager before, you can read a bit about it here. Interaction with the Credential Manager is fairly straightforward. There’s one function, CredWrite, which is used to store credentials, and another, CredRead, which is used to retrieve them. The customers who contacted me both had the same goal: use CredWrite to cache a set of credentials for Outlook to use so the user isn’t prompted for a password.
While this seems a simple request, it turns out that once you start considering all the various scenarios for which Outlook has to cache credentials (O365, Exchange on-Premise, machine in the domain versus out of the domain, multiple profiles, multiple credentials for a single profile), it gets complicated real fast. Even if you figure out how to cache credentials for Outlook to use for one scenario, a slight change to that scenario means the credentials have to be cached differently. So while the set of functions to be used in managing credentials is simple, the logic that goes into making these calls is very complex. We ran this by development just to make sure, but the results were as we expected: We cannot support any third party manipulation of the credentials used by Outlook. If a user wants to cache credentials, they need to enter them at the credential prompt.
Anybody remember that Message Header Analyzer App for Office I wrote about last month? Well, the folks who do support for Exchange and Office 365 caught wind of it and liked it. In fact, they liked it so much they asked me to port the code into their Remove Connectivity Analyzer. Here’s the blog entry they just put up yesterday announcing this:
So even if you don’t have Exchange 2013, you can still use the Message Header Analyzer by going to https://testconnectivity.microsoft.com/?tabid=mha. Feature requests and bug reports can either be directed through the feedback link on that site or by contacting me.