EWS Managed API Series Part 2 | Connecting to EWS

This is a Part 2 in EWS Managed API Series. Please read previous post in this series before going through this.

In order to connect through EWS Managed API we require an account on Exchange which can authenticate our requests on Exchange. This account is known as “service account”. Since this service will need to read exchange resources information and need to perform operations on their behalf thus it is recommended that service account has an Impersonation Role.

What is Impersonation Role?

As per Microsoft’s explanation, Exchange Impersonation enables a caller to impersonate a given account so that a caller can perform operations by using the permissions that are associated with the impersonated account instead of the permissions that are associated with the caller’s account. Microsoft Exchange Server 2007 provides two Active Directory service extended permissions that are used to determine which callers can perform Exchange Impersonation calls and which accounts can be impersonated by the caller. You can check MSDN to get commands to enable impersonation for service account.

What is Autodiscover service?

The Exchange Autodiscover service provides an easy way for your client application to configure itself with minimal user input. Most users know their email address and password, and with those two pieces of information, you can retrieve all the other details you need to get up and running. For Exchange Web Services (EWS) clients, Autodiscover is typically used to find the EWS endpoint URL, but Autodiscover can also provide information to configure clients that use other protocols. Autodiscover works for client applications that are inside or outside firewalls and will work in resource forest and multiple forest scenarios. More details can be found on MSDN.

How do we use EWS?

All that said let’s take a look at some sample code that will show us how to connect to Exchange using EWS Managed API. For this series we will use Office 365 as our exchange.

var service = new ExchangeService(ExchangeVersion.Exchange2013);
service.Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx");
          
var credentials = new NetworkCredential("service account username", "service account password");
service.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, "sample@sample.com");
 
service.Credentials = credentials;

In above sample code, we have created Exchange service object by providing version as Exchange2013. We have provided Exchange service URL for office 365 (https://outlook.office365.com/EWS/Exchange.asmx). Lastly, we have provided service account details in credential object and the email address of the account which we want to impersonate.

In next post we will discuss about how to synchronize calendar items using EWS Managed APIs.

EWS Managed API Series Part 1 | Overview

Today is the world of APIs and everyone is giving out APIs for their products. You can perform CRUD operations using these API. In this world of APIs, Microsoft Exchange has also provided its APIs to perform various CRUD operations on Exchange, like create meeting, update meeting, synchronize calendar, get resource information, etc. These Exchange APIs are known as EWS (Exchange Web Service) Managed API.

I have started this series to give a basic understanding about EWS Managed API. So let’s start.

Overview of EWS Managed API

  • Microsoft provides EWS managed API DLL which you can refer directly in your project and start using EWS managed APIs.
  • EWS Managed APIs make EWS (Exchange Web Service) call under the hood, thus no additional component is required to use EWS Managed API.
  • EWS Managed APIs are backward compatible. It has backward support till Exchange 2007 SP1.
  • EWS Managed APIs are cloud compatible. You can even connect to your office 365 account using EWS Managed APIs.

How to start with Managed API

  • The EWS Managed API works with all versions of Exchange starting with Exchange 2007 SP1.
  • A mailbox on an Exchange server that is running a version of Exchange starting with Exchange 2007 SP1, or Office 365 or Exchange Online.
  • A version of the .NET Framework starting with the .NET Framework 3.5.
  • Familiarity with web services and managed programming.

What you can do with Managed APIs

  • Use the Autodiscover service to return the EWS endpoint for an email account, and get user and domain settings for the account.
  • Manage the folders that contain your email messages, appointments, and tasks.
  • Search for folders, email messages, appointments, and tasks.
  • Create, send, forward, and reply to email messages.
  • Manage calendar appointments and meetings.

In my next post we will discuss about how to connect to Exchange using EWS Managed APIs and get understanding about basic terminologies used in EWS.

WCF: An unsecured or incorrectly fault error

Microsoft has a habit of hiding complexities and providing user with easier things. This makes user to concentrate on his business logic instead of technicality of the things. That’s a good approach followed by Microsoft, but things get messy when some exception occur. Now since Microsoft buries all  the complexities so most of the time it provides you with generic exception and you have no idea about the actual exception. And it gets worse when exception occurs in Web Services.

Most of the developers face “An unsecured or incorrectly fault error” exception in WCF if they are using any kind of Service Authentication. This problem can occur due to numerous reasons like “key not matched(of client and server)” or “timings of server and client were out of sync.”, etc. So how to know what exactly is the problem.

This can be achieved by “Service Security Audit” at your server side. It is enabled by adding <serviceSecurityAudit> tag in your service behavior. eg. below:

<behaviors>
  <serviceBehaviors>
    <behavior name="DemoService">
    <serviceSecurityAudit auditLogLocation="Application"
     serviceAuthorizationAuditLevel="Failure"
      messageAuthenticationAuditLevel="Failure"
     suppressAuditFailure="true" />
</serviceBehaviors>
</behaviors>

auditLogLocation: Specifies the location of the audit log. The default value is Default. Valid values include the following:

  1. Default: Security events are written to the application log on Windows XP, and to the Event Log on Windows Server 2003 and Windows Vista.
  2. Application: Audit events are written to the Application Event Log.
  3. Security: Audit events are written to the Security Event Log.

serviceAuthorizationAuditLevel: Specifies the types of authorization events that are recorded in the audit log. The default value is None. Valid values include the following:

  1. None: No auditing of service authorization events is performed.
  2. Success: Only successful service authorization events are audited.
  3. Failure: Only failure service authorization events are audited.
  4. SuccessAndFailure: Both success and failure service authorization events are audited.

messageAuthenticationAuditLevel: Specifies the type of message authentication audit events logged. The default value is None.Valid values include the following:

  1. None: No audit events are generated.
  2. Success: Only successful security (full validation including message signature validation, cipher, and token validation) events are logged.
  3. Failure: Only failure events are logged.
  4. SuccessAndFailure: Both success and failure events are logged.

suppressAuditFailure: A Boolean value that specifies the behavior for suppressing failures of writing to the audit log.The default is true.

Once you have done the following you will receive actual error in Event Logs.
I hope this post will help out someone else also. From my personal experience most the time when authentication error occurs(during development) it is due to server and client machine time are out of sync.

SQL Azure Default Language for User

I recently got a chance to work on SQL Azure. There were many problems I faced but one stands out which is how to set Language for the user on SQL Azure.

Problem Statement

Our database has a very strong dependency on the language of the user Login. Reason being that we pass datetime as string from code base and inside Stored Procedures  we just cast them to dates, so we expect that these dates are being passed in specified format which is British English.  Its pretty simple to set handle this in our personal VMs that have SQL installed. We just set user’s default language as British English and it works fine.

But, on SQL Azure you can not change the language of the user. This is an limitation of SQL Azure as mentioned here https://msdn.microsoft.com/en-us/library/azure/ff394108.aspx

Resolution/Work Around

Now, this was a blocker in our dream to migrate our database to SQL Azure. But then came our savior, one of colleague suggested that why not put “SET LANGUAGE [British]” over each Stored Procedure . What it will do is at least for that stored procedure every conversion will happen under language “British English”. And it Worked !!! 

I hope this posts help any other person struggling with Default Language on SQL Azure