Error report: EWS Managed API, sudden connection trouble & solution

Today I was working on an Exchange Web Services project that I have been working on for some time. During the development of this project I had been testing code against a virtualized Windows Server 08 R2 and Exchange Server 2007 SP1. The project uses impersonation to manipulate items in user mailboxes and had worked fine up until this point, but had trouble making a connection suddenly today.

At first I thought it was a problem with the virtualized server and I rebooted it to see if the service would become accessible and it did not. I tried switching from autodiscover for the EWS endpoint to specifying the URI and it made no difference.

 

Error: Using autodiscover

The autodiscover service couldn't be located.


Error: Using a URI

Request failed. The remote server returned an error: (401) Unauthorized.

 

Problem properties

These errors prevented me from using EWS in the project that had been working fine. Nothing significant had changed in the project and backups that worked prior did not work anymore. The impersonation account was still valid in active directory and using the  Test-ExchangeWebServices cmdlet the Exchange Management Console confirmed an accessible and functioning autodiscovery service and endpoints for the target email address.  Changing authentication settings (Anonymous Authentication) in IIS resulted in the URI error for EWS becoming

Request failed. The remote server returned an error: (403) Forbidden.

It was clear it was a security issue with the impersonation account. At first glance the impersonation account properties were fine and (still) correctly setup, so what was the problem?

 

The Solution

The problem was that the account had been set to have its password expire. The password had expired for the impersonation account and this was pretty much invisible to me as it was not shown anywhere in the active directory administrative user property panes.  So I reset the password to what it was and set it not to expire. That fixed the problem.

 

Further comments

I had thought that the problem could have been related to how I’ve been authenticating. Up until now I’ve been using the an authentication object like the following:

ExchangeService.Url = new NetworkCredential(ImpersonationUsername,ImpersonationPassword)


Online there is a lot of  comments about including a domain as the third parameter and I had considered this as being the problem, but it was not. My project has been functioning fine without specifying a domain parameter. In addition this is using a NetworkCredential object as opposed to a WebCredential object which is also suggested in some places. It is worth considering if the above solution doesn’t fix your issue. You can also try making sure the authentication settings are correct in your IIS (where the EWS API is hosted) however be careful if you do that. This problem normally suggests there is an authentication problem somewhere.

 

My project: Present and Future

I didn’t totally get my project as polished as I would have liked on my last day (which was today, the 1st of November). But that won’t be as much of a problem as I thought and you’ll find out why if you read on…

Get functionality – Scope creep?

If you read the post title and thought ‘scope creep’ you would be justified. But hang on a minute, lets think about this for a moment: it is one thing to add an item to someone’s outlook account from a seperate system, but what about when it gets deleted or edited in the original system?

XML, my savior or timewaster?

In my last post I described how I decided to change the input method to support XML as the properties were getting incredibly complex. What I didn’t mention is that I didn’t fully abandon the idea of command-line parameters: I wanted support for both. This meant developing the capabilities for both command-line parameters and XML files into the solution I was developing.

Command-line solution: A new approach and some considerations

The focus of my last post was based on how I would extract parameters from the command-line, and what those parameters might be. As I developed a solution with help from the command-line arguments parser, it became clear that extracting the information in this manner could only ever be somewhat suitable for a single item.

Solution Implementation Plan: Exchange Web Services via command-line

So I decided on using Exchange Web Services as a tool to achieve the end goal: placing appointments in user’s calendars. But how will it integrate with the rest of the Nimbus system?

Solution Test Run: Exchange Web Services

So I put my proposed solution to the test. I wanted to be confident while heading into development that my solution did in fact work. The way this was done? Writing a quick windows form application; not necessarily the solution that it will end up being, but suitable for rapid, repeated testing of my concept once some short amount of code was done.

Potential Solution Analysis: Exchange Web Services

My work at Nimbus started off with a client-based solution to getting calendar items into user accounts. This worked well but was not very scalable and was dependent on the client having the specific functionality installed into their version of Outlook. What about web based users? What about users checking email from home? A client-based solution worked well when it fit the very narrow operating criteria it required..

Enter Exchange Web Services Managed API (EWS).

The approach: Exchange Web Services Managed API

It has been a busy month for me so far. My research into development options for Exchange Server led me to several options, each not quite so straightforward as making an Outlook add-in – but still workable.

To put development options into context for Exchange Server, there are numerous solutions available for development targeting Exchange server; however these solutions affect different aspects of Exchange Server. There were only three that really stood out to me as potential solutions for my goal – manipulating items in user mailboxes. Those three options were:

1. Messaging API (MAPI) [This is the first standard Microsoft used for Exchange functionality]
2. Exchange Web Services Managed API (EWS) [This is a new standard Microsoft is using for Exchange functionality]
3. Exchange Management Console (EMC) [Powershell interface to Exchange Server]

The best solution (at least at first) appeared to be Exchange Management Console. It looked to give the exact functionality I needed: the ability to push new items into Exchange Mailboxes programmatically. However this solution didn’t seem to fly with the senior I pitched the idea to. I didn’t like the idea of having to interface through PowerShell either so I explored other options.

I looked at MAPI and it had functionality for what I needed, particularly through Collaboration Data Objects (CDO). However CDO seemed to be getting phased out as it was taken out of the base Exchange Server install configuration starting with Exchange 2007. MAPI itself looked to have the potential to do what was needed; that changed however when I came across a blog post on the Microsoft Developer Network (MSDN) that neither CDO or MAPI is supported in .Net managed code.

So that left the Exchange Web Services Managed API. It looked to be largely the solution encouraged from Microsoft, and it had good documentation on MSDN. So I started looking into that. My next post tomorrow will outline what I found.

The new plan: Exchange server

I met with some of the senior developers at work yesterday. They were happy to see what I had done up until this point, which was:

Code a DB controller app:

• Connect to a DB, at first through a SqlConnection object but potentially allowing a future expansion (ie. WebServices)
• Find the appropriate tables in the database for the scheduler (which was interesting due to quite a few tables in the system database)
• Connect scheduler tasks with several other database tables in the system to gather related info which is important (like the Job location for example)
• Grab the schema for the resulting view and send it to the add-in, allowing for the user to select which fields they wanted
• Delivered information as per the schema the user requested

This provided a data access layer for the add-in, allowing for the controller app to decide how it wants to get the information.

The add-in simply:

• Asks for tasks for a specific user
• Formats them into AppointmentItems
• Populates the AppointmentItems fields with information related to the desired schema, and a primary key to prevent duplicates
• Provides an interface to view the schema and choose appropriate fields
• Adds a right click context menu to allow specific actions and links back to the Nimbus system specifically for Outlook appointments gathered from the scheduler

The meeting was originally for me to inform them of the software restrictions and thus what version we could support; as well as asking about the data access layer the system already had. What ended up happening was a discussion the benefits and drawbacks to my potential implementation, which lead us down a path of wondering about working with an exchange server directly. This has limitations on only working with an Exchange server obviously, but has benefits of being applicable to any interface (ie. the appointments would show in any version of Outlook, including web interfaces which have a very different add-in architecture).

Much to my excitement I was given the task to research an implementation such as this. The research I have done to this stage has found most of the documentation for coding against Exchange server relates to coding against its publicly accessible email interfaces rather than working with its internal functioning (ie. directly with user mailboxes being hosted by the server). It will be a much more difficult challenge to get something that will work with every configuration, but the research I have done so far has hinted at the possibility of it being done albeit with some very specific configurations and prerequisites which may be achievable programmatically.

My goal for the next few days is to get a virtualized test server ready and to code some possible solutions I have found from my research. I will test each solution and see what works and what doesn’t, particularly in the context of differing configurations – it needs to be as universally applicable as possible.