Shulou(Shulou.com)06/02 Report--

API Features for Exchange Versions

The Exchange Web Services API, including EWS and AutoDiscovery, was developed with multiversion compatibility in mind. Therefore, applications for Exchange 2007 also work with versions of Exchange starting with Exchange 2013, including Exchange Online and Exchange Online as part of Office 365.

https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/web-service-api-feature-availability-in-exchange-and-the-ews-managed-api

The EWS schema defines the structure of data that can be sent to and returned by Exchange. Every new version of Exchange that includes significant changes to EWS functionality will include a new architecture. Both EWS and EWS patterns are backward and, in some cases, forward compatible-applications designed for earlier versions of EWS will work with later versions of EWS in most cases, and applications designed for later versions of EWS will work in the same cases features were included in earlier versions.

Consider the current version of Exchange when designing EWS applications

https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/ews-schema-versions-in-exchange

Some differences between internal and online deployments for the EWS API

On-premises deployments can only use NTLM or Basic authentication, while online deployments can use Oauth authentication;

On-premises deployment of EWS provides rich log information, while online deployment limits access to EWS logs;

On-premises auto-discovery types support SOAP, SCP, POX; online does not support SCP;

EWS Restrictions in Exchange

Limiting is a responsive response to excessive use of system resources that may affect service reliability and functionality. Exchange continuously monitors the health of critical infrastructure resources, such as mailbox databases. When high load factors are detected that degrade the performance of these resources, EWS connections are scaled based on how much each caller contributes to this high load condition.

Every client access protocol in Exchange, including EWS, has a restriction policy. When designing applications that use EWS, you must consider throttling policies to help ensure application reliability and Exchange server health.

If you are an application developer, you need to incorporate constraints into your application design.

Restriction policies in Exchange affect not only EWS, but all client connections to Exchange servers, including the protocols used by Office Outlook, Outlook Web App, and Exchange ActiveSync. Here is an example:

This CPUStartPercent restriction policy may affect EWS performance when running Exchange 2010. When the average CPU utilization of Exchange processes running on client access servers, including but not limited to EWS processes, exceeds the value specified by this policy, inbound requests are delayed to reduce CPU utilization. You cannot change the value of this policy, but understanding it can help you resolve performance issues. The sampling logic performed by the Client Access Server for this value is the average over a rolling window of 10 seconds. This allows processes to respond appropriately to rapid spikes in CPU utilization. When this threshold is exceeded, inbound connections to EWS are delayed. At a theoretical 100% CPU usage per EWS request, the upper limit for this delay is 500 milliseconds (msecs). If a batch EWS request gets 100 items, the server checks CPU usage 100 times (once per item) with a maximum delay of 50 seconds. Delay time is linearly proportional to CPU usage. Latency is 0 (thread yield) at CPUStartPercent and increases linearly to 500 ms at 100% CPU usage. Because throttling policies apply to all Exchange users, CPU usage cannot exceed the CPUStartPercent limit on Exchange Client Access servers because individual users or applications cannot achieve sufficient CPU utilization to affect server operations.

You can use the following cmdlets to display throttling policies for an on-premises Exchange Server deployment:

Get-ThrottlingPolicy -Gets client throttling settings for one or more throttling policies.

Get-ThrottlingPolicyAssociation -Enables you to view the relationship between an object and its associated restriction policy. Objects can be users with mailboxes, users without mailboxes, or contacts.

Limiting impact on EWS batch requests

EWS enables you to batch multiple item requests into a single request executed by the Client Access server. This improves efficiency and performance. When Exchange Server executes batch requests, it checks the user's budget after each item in the batch executes. If the application exceeds budget, processing of the next item in the batch is delayed until the user's budget has been replenished. To ensure that applications that use batch operations run successfully, limit the number of item requests that can be included in a single batch and divide large batches into smaller batches to improve the reliability of the results. The impact of a batch operation on a particular limit threshold depends on the type of request, the size of the item being processed (for example, UploadItems or ExportItems operations), and the mailbox contents. Restricting policies can cause requests to take longer to process, affecting batch operations. As a result, the caller must wait longer to respond, and since EWS limits the execution time of batch requests to one minute, the call may time out.

Note: EWS concurrency limits may be exceeded when sending a large number of emails

Number of MessageRateLimits specifies the number of messages that can be submitted per minute through any Exchange client, including EWS. By default, this policy is set to 30 messages per minute. For ordinary users, this is usually enough. However, applications that send bulk e-mail (for example, as part of a billing schedule) may experience problems. Mail delivery to mailboxes is delayed when this policy limit is exceeded. Specifically, when the number of messages submitted by a user or application is greater than the value specified by MessageRateLimit, the message appears in the Outbox or Drafts folder for a longer time parameter. When developing a delivery tracking system, be sure to consider this, especially if your application uses mailboxes that users connect to through Outlook. When delayed items are stored in the Outbox or Drafts folder, users may interpret them as errors.

The RecipientRateLimit parameter specifies a limit on the number of recipients that the user can resolve within 24 hours. For example, if this value is set to 500, it means that a single Exchange mailbox account can send messages to no more than 500 recipients per day. This restriction applies to messages for recipients both internal and external to the organization. This default limit may cause problems with some line-of-business applications that perform month-end invoice runs and need to send messages to more than this number of recipients. You can work around this limitation by using an external service that enables batch messaging or a separate local outbound relay solution.

For more information on client restrictions, see docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/ews-throttling-in-exchange

For more information, please pay attention to Weixin Official Accounts below

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.