How can I create an EWS certificate

Exchange Web Services (EWS)

Microsoft Consultant Exchange & Skype for Business (m / f)
Come to Net at Work. We have exciting projects with innovative customers. Our team works in a collegial and cooperative manner - constant exchange and further training are standard with us.
http://www.netatwork.de/karriere

In the past, MAPI / CDO was the preferred way of accessing the contents of an Exchange server (mailbox and public folders). However, this route has various limitations in modern times. As a 16/32 bit application or COM-DLL, the way into the future is not easy. In addition, communication takes place via RPC against the mailbox server. HTTPS would be much better though. With Exchange 2000/2003 there was an intermediate step, as the WebDAV protocol made it possible to access content via HTTPS. However, this was not particularly elegant either and with Exchange 2007 the web services were provided for the first time, which are to replace all other APIs (WebDAV, CDO, ExOLEDB and OWA URL Commands) in the future. With Exchange 2010 a ManagedAPI for .NET was made available that developers can work much more easily.

Attention: EWS with Exchange Online and Oct 13, 2020: BasicAuth not applicable, OAUTH required
Upcoming changes to Exchange Web Services (EWS) API for Office 365
https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/

Starting today, Exchange Web Services (EWS) will no longer receive feature updates "Zukunft ist Graoh October 13th, 2020 we will stop supporting and fully decommission the Basic Authentication for EWS to access Exchange Online.
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Upcoming-changes-to-Exchange-Web-Services-EWS-API-for-Office-365/ba-p/608055 "

Range of functions

A diagram shows what you can already cover with web services today. It shows very well which functions were already included in Exchange 2007 and that Exchange 2007 SP1 has virtually completed the Exchange 2007 range of functions. Of course, the web services were expanded again with Exchange 2010.


Source: TechEd UNC324 What's New in Exchange Web Services in Microsoft Exchange Server 2010, author Albert Kooiman

The seriousness of using Exchange Web Services from Microsoft is clear and clear: A lot of products and programs now rely on EWS, e.g. Entourage for Mac Web Service Edition, the TransporterSuite, Project Server 2010 for tasks and more and more other tools from Microsoft and third-party manufacturers . The separate Web service page provides a general description.

The Exchange Web Services therefore enable simple, internet-compatible, platform-independent access to content. Your program can even be informed via web service if something changes in a folder. However, this only works asynchronously and only per folder. It is therefore not a substitute for the Exchange 2000/2003 storesinks. However, changes can be very easily identified and responded to using the Synchronization API.

Use Exchange Web Services

Before Microsoft released the "Managed API" for Exchange WebServices, you still have to get the WSDL file yourself, write proxy classes and check very carefully which parameters should be used where. I have moved all links to use without managed API to the end of the page. (See Exchange 2007 Web Services Without Managed API). They are still important if you want to access Exchange with programs that do not support .NET, e.g. Java, Unix etc. Otherwise, I would advise beginners to use the Managed API.

But first you have to download them and install them on the client so that you can use them.

Microsoft Exchange Web Services Managed API
Version 2.2: http://www.microsoft.com/en-us/download/details.aspx?id=42951
Version 2.1: http://www.microsoft.com/en-us/download/details.aspx?id=42022
Version 2.0: http://www.microsoft.com/en-us/download/details.aspx?id=35371
Version 1.2 http://www.microsoft.com/download/en/details.aspx?id=28952

The development is currently being continued on GITHUB
https://github.com/officedev/ews-managed-api

Exchange 2010 Service Pack 1 (SP1) Web Services Software Development Kit (SDK)
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=d55dcd05-1dd6-4f44-956f-82f052ee7d82

Exchange API spotting Exchange 2010 SDK March Update
http://blogs.msdn.com/exchangedev/archive/2010/03/03/Thom-Randolph.aspx

The installation must be carried out on the system from which the data is to be accessed. It is no longer necessary to install an application or additional API on the Exchange Server.

After completing the installation, however, there is no icon in the start menu or similar.You can then simply integrate the new DLLs into your project and then create a new instance of an object based on this and activate tracing for diagnostic purposes.

using Microsoft.Exchange.WebSerivces.Data; using Microsoft.Exchange.WebSerivces.Autodiscover; / * initialize ewsserver * / ExchangeService ewsservice = new ExchangeService; / * Initialize ewsserver if the target is Exchange 2007 * / ExchangeService ewsservice = new ExchangeService (Exchange2007_SP1); / * Optionally specify credentials * / ewsservice.Credentials = new NetworkCredential ("name", "pwd", "domain"); / * switch on a trace for debugging if necessary * / ewsservice.traceEnabled = true; / * Define the URL OR determine it via Autodiscover * / service.URL = new uri ("https: //servername/EWS/Exchange.asmx"); service.AutodiscoverURL ("[email protected]");

Exchange Web Services Overview
https://www.youtube.com/watch?v=wOQMJhrp6GQ

EWS filter: Control access from Exchange 2010 SP1

Since Exchange 2010 SP1, an administrator can also make more settings here so that not every client romps around in the store with a known user name via EWS and freely available tools. The following two commandlets are relevant for this. The SP1 for Exchange 2010 has enhanced two commands:

As of SP1, both commandlets can have the following parameters:

  • EWSEnable
    This generally controls whether EWS should be accessible
  • EwsAllowMacOutlook ".
    This can be used to control whether Outlook 2011 for Mac can access Exchange via EWS.
  • EwsAllowEntourage
    The same is possible for entourage.
  • EwsAllowOutlook
    Controls whether Outlook 2007 and later can access via EWS
  • "EwsApplicationAccessPolicy" and "EwsBlockList" and EwsAllowList
    Depending on the policy setting (EnforceAllowList or EnforceBlockList), you can use the list to allow certain clients (/ whitelist) or block certain entries (blacklist)

The fields do not have to be filled with "true" or "false", but can also be "empty". In my experience, parameters set "per user" overrode the organization-wide settings. If nothing is set, then everything is "allowed". (I couldn't test that yet, e.g. due to the lack of a Mac.

PowerShell and EWS

With the Test-EWS script, I have created a framework with which you can very quickly run through an initial EWS access to your mailbox.

It is not possible to simply call managed code from VBScript. But PowerShell makes this very easy to do. the following lines establish a connection to the Exchange Server via EWS.

# Loading the Manages API DLLs into the process space [void] [Reflection.Assembly] :: LoadFile ("C: \ Program Files \ Microsoft \ Exchange \ Web Services \ 2.2 \ Microsoft.Exchange.WebServices.dll") # ews- Instantiating class # If you access Exchange 2007, you must specify this with $ ews = new-object Microsoft.Exchange.WebServices.Data.ExchangeService # $ ews = new-object Microsoft.Exchange.WebServices.Data.ExchangeService ([Microsoft. Exchange.WebServices.Data.ExchangeVersion] :: Exchange2007_SP1) # Then you have to enter the EWS URL or have it determined by Autodicsover based on the email address. # Determine with mail address $ ews.AutodiscoverURL ($ mailbox) # alternatively: Use current user # $ windowsIdentity = [System.Security.Principal.WindowsIdentity] :: GetCurrent () # $ sidbind = "LDAP: // " # [adsi] $ aceUser = [ADSI] $ sidbind # $ ews.AutodiscoverURL ($ aceUser.mail.ToString ()) # Fixed alternative URL $ ews.URL = [system.URI] "https: //casserver/ews/exchange.asmx" # Optionally log in with other user data $ ews.Credentials = New-Object System.Net.NetworkCredential ("Username", "password", "domain" )

The class is then available for further use.

Send mail via EWS

Of course, I can also simply send an email via SMTP. This can be done by sending a Blat or by sending an e-mail via CDO, but SMTP and port 25 are always required for this. Many firewalls, virus scanners etc. block this and and with HTTP and EWS you are more flexible here on the one hand and the mail also ends up in "sent objects".

Import-Module -Name 'C: \ Program Files \ Microsoft \ Exchange \ Web Services \ 2.2 \ Microsoft.Exchange.WebServices.dll' $ Credential = Get-Credential $ exchService = New-Object -TypeName Microsoft.Exchange.WebServices.Data .ExchangeService $ exchService.Credentials = New-Object `-TypeName Microsoft.Exchange.WebServices.Data.WebCredentials` -ArgumentList $ Credential.UserName, $ Credential.GetNetworkCredential (). Password $ exchService.AutodiscoverUrl ($ Credential.UserName, {$ true}) $ eMail = New-Object -TypeName Microsoft.Exchange.WebServices.Data.EmailMessage -ArgumentList $ exchService $ eMail.Subject = 'Test EWS' $ eMail.Body = 'Test EWS' $ eMail.ToRecipients.Add (' [email protected] ') | Out-Null $ eMail.SendAndSaveCopy ()

Of course, you can add attachments, format templates, etc. to the mail.

Read out incoming mail via EWS

Retrieving emails from the inbox and other folders has also become very easy with the Managed API. Here, too, you need the initialization part and then it goes on very easily. What is unusual here is that you first have to define a "view" next to the folder so that you can get the data you want. But this is very helpful, because if you know what you are looking for, then you do not need to request all the content and filter it on the client; the server can filter it.

Write-Host "Binding Inbox" $ inbox = [Microsoft.Exchange.WebServices.Data.Folder] :: Bind ($ ews, `[Microsoft.Exchange.WebServices.Data.WellKnownFolderName] :: Inbox) write-host" Number or unread Messages: "+ $ inbox.UnreadCount $ view = New-Object Microsoft.Exchange.WebServices.Data.ItemView (1) $ findResults = $ ews.FindItems ([Microsoft.Exchange.WebServices.Data.WellKnownFolderName] :: Inbox, $ view) "" "Last Mail From:" + $ findResults.Items [0] .From.Name "Subject:" + $ findResults.Items [0] .Subject "Sent:" + $ findResults.Items [0]. DateTimeSent

The first mail displays these lines.

  • Test EWS
    Simple EWS function tests with PowerShell

Calendar access via EWS

Appointments can also be accessed via EWS. Here are a few links to further sites:

Autodiscover and redirection

Before Outlook 2007 SP1 could also work with SRV records, an admin could only configure one certificate for "autodiscover.maildomain.tld" or make an HTTP redirect without SSL. This works very well with Outlook 2007, but if you want to access it via Exchange Web Services, you have to set up a "callback" function that handles the query regarding the "redirection".

This is definitely not possible with PowerShell 1.0 and with 2.0 the complexity for the MSXFAQ is rather high. You should then just provide the URL manually.

$ ewsservice.URL = "https: //exchangeserver/EWS/exchange.asmx

You can also surf to this URL via your browser. After authentication, you will get the following page for Exchange 2016

Do not be confused by the fact that the "real server name" appears in the example and the internal port (444) also appears in Exchange 2016 with a combined frontend / backend role. As a programmer, you should of course use the correct public name with HTTPS over 443. If, the URL visible here is only accessible internally but never externally. You should then rewrite the URL accordingly:

https: //exchangeserver/EWS/services.wsdl

After authentication, the Exchange Server replies with an XML file for the API description, which a browser can also display

These URLs are therefore a first test of whether EWS can already be reached in general. They are also suitable for monitoring within limits.

EWS and impersonation

Please see the separate EWS Impersonation page

EWS header: X-AnchorMailbox and others

EWS uses HTTPS and even if EWS just works like that, there are headers that a developer should set. Some are optional, but X-AnchorMailbox is essential in many places.

  • User agent
    For troubleshooting on the server it is useful if your own script reports to the web server with its own UserAgent. This is very easy, but the "UserAgent" property in the EWSService object and allows the admin to search directly in the IISLog on the server
  • X-ClientStatistics
    The programmer can use the EWS property SendClientLatencies of the class to set up EWS to send corresponding performance indicators back to the server. Currently, however, only Exchange Online collects this data so that Microsoft can improve its service.
  • X-AnchorMailbox
    X-AnchorMailbox
    This header is anything but optional and should be actively used by developers. This is especially true if a process addresses several mailboxes via impersonation. The reference to the same backend server is tied down via the address in the X-AnchorMailbox. Otherwise, a different server could be used for each request, which means additional work in connection establishment, authentication, etc. and costs performance.

A high scale EWS-based application / service that uses impersonation needs to manage affinity with the backend Exchange server by adding an HTTP header called "X-AnchorMailbox" to requests with the ExchangeImpersonation SOAP header. The values ​​of the X-AnchorMailbox HTTP header and the ExchangeImpesonation SOAP header on the request should match.
Source: https://blogs.msdn.microsoft.com/mstehle/2013/07/25/managing-affinity-for-ews-impersonation-in-exchange-2013-and-exchange-online-w15/

Further information can be found on the following pages.

EWS for OOF

OOF settings can also be reached via EWS. Here are a few starting addresses:

EWS and element sizes

Have you ever tried to move a mailbox from Notes or Exchange to Exchange 2007/2010 in which there was a mail> 50 MB? Right, that is not possible because the migration takes place via EWS. Microsoft has built in "protection" against attacks that prevents larger elements from being uploaded. It would be a shame if a malicious process "started" an upload of 20 GB (but never finished it anyway) and Exchange had to reserve space / RAM for it. Therefore there is a limit, which you can set higher.

The "problem" does not only concern migrations but any kind of access to EWS.

An attachment "enlarges" when using EWS
20 MB: file size on disc
30 MB file after MIME conversion (+ 33%)
43 MB file encoded within the XML / SOAP message (+ 36%)
The individual sizes can vary.

Accordingly, you can "hit" several places where the IIS can control over limits. Ultimately, there are changes to the "web.config".

<configuration> <system.web> <httpRuntime maxRequestLength="10240" /> <system.web> <configuration>

The value is given in "kilobytes".

Danger
This is an XML file and typing errors mean that the corresponding application pool no longer starts. You can also make many settings in the IIS manager.

Then the IIS has to be restarted with an IISRESET so that the settings become active.

Here is an incomplete list of the parameters I've been confronted with.

parameter IIS20072010

maxRequestLength

web.config

4KB

13280KB

2097151KB

MaxReceiveMessageSize

web.config

n / A ?

n / A ?

RTM: 13600000
SP1: 35000000
Attention: 8x available

maxAllowedContentLength

web.config

30 MB

30 MB

35 MB

executionTimeout

web.config

110 sec

 

 

There are other limit values ​​(e.g. connectionTimeout), which only come into effect in very large systems with very slow lines. Functions such as "connection filtering" or an upstream firewall can of course implement their own limits and in the end

EWS and Notification Services

The web services open another nice way: an application can set a "push notification" via web services, i.e. the Exchange server informs the application if something happens in a mailbox, for example. For this purpose, the application itself must also provide a web service, which Exchange then calls "backwards". As a programmer, I instruct Exchange to call the web service offered by my application in certain situations. Are you looking for

Attention: The function to wait for push notifications was introduced in 2007 but was replaced by "Streaming Notifications" in 2010. In jan 2019, the push notification was misused for attacks and adapted by Microsoft.
Exchange Fail Jan 2019 - CVE-2018-8581

SubscribePullNotification

But you have to develop a listener, which is then called by Exchange (also WebService). You can also find details here:

If you have done everything correctly but your web service is still not addressed, then you should take a look at the event log:

Event Type: Warning Event Source: MSExchange Web Services Event Category: Core Event ID: 6 Description: unable to send a notification for subscription fsdfllkn4325kjbzuvjdj2sj1jshj2dk2kj3s1fefh13g4g4sjg34as3244 =. (Send attempts: 3) Event Type: Error Event Source: MSExchange Web Services Event Category: Core Event ID: 7 Description: After 8 unsuccessful attempts to send a notification for subscription fsdfllkn4325kjbzuvjdj2sj1jshj2dk2kj3s1fefh13g4g4sjg34as3244 = K8 =, subscription has been removed Event Source: MSExchange Web Services Event Category: Core Event ID: 5 Description: unable to send a notification for subscription fsdfllkn4325kjbzuvjdj2sj1jshj2dk2kj3s1fefh13g4g4sjg34as3244 = K8 =. Will retry.

The long character string is in reality a Base64-encoded binary file that can be decoded, but you don't see much more than the server name and a few cryptic characters. But it is at least an indication of where the sink should go. By the way, the entries are stored on the CAS server and if I may believe the developers there is no easy way to generate a list of active notifications.

However, you can search the IIS logs to find out who is "subscribing" to the Exchange Web Services and when, i.e. simply looking for "ews / exchange.asmx? SoapAction = Subscribe" in the IIS log.

https://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=931885&SiteID=17
For push notifications, you need to write your own web service that implements the NotificationService.wsdl interface. Then you subscribe to receive notifications using the EWS Subscribe web method with a PushSubscriptionRequest sub-element. You will notice that the PushSubscriptionRequestType surfaces a status frequency (how often you want to be alerted of changes) and a URL which is the URL of YOUR web service. Then EWS will call the SendNotification web method on your service with the changes. You can unsubscribe by responding to the SendNotification web method with a subscription status of "Unsubscribe".

EWS performance analysis via the IISLog

You now know that the web services are part of the IIS web server. This means that the corresponding inquiries also land in the IISLog. Here are three exemplary lines that have been shortened for readability.

POST /ews/Exchange.asmx - - 401 2
POST /ews/Exchange.asmx - Domain \ User 500 0
POST /ews/Exchange.asmx SoapAction = FindItem; Version = 0; RpcC = 27; RpcL = 137; LdapC = 10; LdapL = 58; Domain \ User - 200 0

The first line shows an anonymous request, which the server naturally acknowledges with a 401.2 error. The second line, on the other hand, shows that there is probably no valid query but with a valid user and is answered with a 500. A NETMON recording would be conceivable here in order to see the XML request and the details of the response.

The line of a successful EWS request is particularly interesting. Not only is the "FindItem" command visible here, but also a few values ​​for internal processing. So far I haven't got any confirmation, but the numbers should be the milliseconds that are dwelled in the corresponding routine.

Unfortunately there is no parser that evaluates these details more precisely.

EWS server log

The Exchange Server itself also logs a lot of information in its own log files in addition to the IIS. This also includes EWS. The logs are available by default

C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ Logging \ Ews

With PowerShell you can, for example, quickly determine which methods the clients generally use:

get-item "C: \ Program Files \ Microsoft \ Exchange Server \ V15 \ Logging \ Ews \ ews_20190102 * - *.

Of course, you can also carry out your own evaluations based on the other fields and content, e.g. determine EWS requests for client IP or users and thus limit misuse or overuse.

EWS throttling

New in Exchange 2010 is the function that a client does not fill up the server via web services. So whoever works too "gnawed" with EWS will be slowed down. It makes sense to take this into account when developing the code and to use "paged searches".

NOTE: Even after the EWS Throttling Policy has been updated, EWS imports will still be limited to 150MB per 5 minutes per mailbox; to achieve higher migration throughput speeds, please migrate more users concurrently.
https://docs.microsoft.com/de-de/exchange/client-developer/exchange-web-services/ews-throttling-in-exchange

You can find more information on:

Throttling

Exchange 2007 web services without managed API

Real-time processing with the option of preventing a change in the client or performing other functions synchronously is apparently not possible with web services.

Here is just a small selection of links. The MSDN site is sure to be the best resource.