The EWSFastSearchTimeoutInSeconds policy element specifies the amount of time, in seconds, that EWS fast searches run before they time out. A fast search is a search made by using an Advanced Query Syntax (AQS) query string in a FindItem operation.

The default value of this policy in Exchange Online is 60 seconds. If a query takes longer than 60 seconds to return results, an error is returned.

You can search an Exchange Online mailbox folder in two ways:

• By using an Exchange store search, which performs a sequential scan of all messages in the target search scope.

• By using the Exchange Search service (content indexing).

Both of these types of searches can result in timeouts. When possible, use the Exchange Search service because these searches are often targeted against mailbox indexes and use AQS queries. The following example shows how to perform an AQS search of the Inbox using EWS and the Exchange Search service.

ItemView iv = new ItemView(1000);
FindItemsResults<Item> fiitems = service.FindItems(WellKnownFolderName.Inbox, "subject:football", iv);

If you can't use an AQS search, avoid using overly complex search filters. Also try to avoid creating search filters based on computed values if the query involves extended MAPI properties.

Note:

The first time you run an Exchange store search query, it runs very slowly and may time out. After that, the query will respond more quickly. For more information about the backend Exchange server processes that occur during Exchange store search queries, see Understanding the Performance Impact of High Item Counts and Restricted Views on Microsoft TechNet. Using a SearchFilter creates a dynamic restriction that helps similar queries in the future, but because these restrictions are dynamic in nature, they are not permanent or reliable, and are deleted after a maximum of three days.

The EWSFindCounteLimit policy element specifies the maximum number of items from the results of a FindItem or FindFolder operation that can exist in memory on a Client Access server at the same time for one user. Every item or folder that EWS processes in a FindItem or FindFolder request is counted against the budget specified in the EWSFindCountLimit element. When the response is sent back to the requester, the find count charge for the current call is released. The response the server returns to a requester when the budget is exceeded is based on the RequestServerVersion element value and whether the requester specified paging. When the value of the RequestServerVersion element indicates Exchange 2010 or an earlier version of Exchange, the server sends a failure response with error code ErrorServerBusy. If the value of the RequestServerVersion element indicates Exchange 2010 or a later version of Exchange and the client is using paging, EWS returns a partial result set instead of an error. Your application should expect that EWS might not return all items. If the value of the IncludesLastItemInRange element is false, the application should make another FindItem or FindFolder request with the new offset and continue until the IncludesLastItemInRange element returns true.

EWSFindCountLimit best practices

When you use a FindItem or FindFolder operation, it is important to use paging. The EWS Managed API enforces the use of paging, but if you are using other methods, such as EWS proxy objects or raw SOAP, you need to explicitly set paging. The following example shows how to use paging in the EWS Managed API.

C#

Copy

ItemView iv = new ItemView(1000);
FindItemsResults<Item> fiFindItemResults = service.FindItems(WellKnownFolderName.Inbox, iv);

The following example shows how to use paging with EWS proxy objects.

C#

Copy

IndexedPageViewType indexedPageView = new IndexedPageViewType();
indexedPageView.BasePoint = IndexBasePointType.Beginning;
indexedPageView.Offset = 0;
indexedPageView.MaxEntriesReturned = 100;
indexedPageView.MaxEntriesReturnedSpecified = true;
FindItemType findItemrequest = new FindItemType();
findItemrequest.Item = indexedPageView;

Note:
The default policy in Exchange Online limits the page size to 1000 items. Setting the page size to a value that is greater than this number has no practical effect.

Applications should also account for the fact that the EWSFindCountLimit throttling parameter value may result in a partial result set being returned for applications that make concurrent requests. The following example shows how to use the MoreAvailable property in the EWS Managed API to ensure that all results are included in a query.

C#

Copy

ItemView iv = new ItemView(1000);
service.TraceEnabled = false;
FindItemsResults<Item> fiResults = null;
Do 
{
    fiResults = service.FindItems(WellKnownFolderName.Inbox, iv);
    PropertySet itItemPropSet = new PropertySet(BasePropertySet.IdOnly) { EmailMessageSchema.Body };
    //Process Items in Result Set
    iv.Offset += fiResults.Items.Count;
}
while (fiResults.MoreAvailable == true);

The EWSMaxConcurrency throttling policy element sets the number of concurrent connections that a specific user can have against an Exchange server at one time. To determine the maximum number of concurrent connections to allow, consider the connections that Outlook clients will use. Office Outlook 2007 and Outlook 2010 use EWS to access availability and Out of Office (OOF) information. Mac Outlook 2001 uses EWS for all client access functionality. Depending on the number of Outlook clients that are actively connecting to a user’s mailbox, the number of concurrent connections available for a user might be limited. Additionally, if your application has to connect to multiple mailboxes simultaneously while using a single security context, it is important to take the value of the EWSMaxConcurency policy into account.

Avoiding problems caused by the EWSMaxConcurrency policy

The EWSFindCountLimit policy element specifies the maximum result size a FindItem or FindFolder operation can use on a Client Access server at the same time for one user. If an application (or potentially multiple applications) makes two concurrent EWS FindItem requests that return 100 items each for a specific user, the EWSFindCountLimit charge against that specific user’s budget will be 200. When the first request returns, the budget drops to 100, and when the second request returns the budget drops to zero. If the same application were to make two simultaneous requests for 1000 items, the budget value would be 2000 items, which exceeds the EWSFindCountLimit value. If the user's budget for items drops below zero, the next request results in an error until the user's budget recharges to one or more.

The EWSMaxSubscriptions policy element specifies the maximum number of active push and pull subscriptions that a user can have on a specific Client Access server at the same time. By default, this is set to 20, which means that one user cannot have more than 20 active subscriptions. A user can subscribe to all folders in a mailbox by using the SubscribeToAllFolders property, or users can subscribe to up to 20 folders at a time (for example, users can subscribe to 20 calendar folders in different mailboxes). For companies that have a large user base and want to build applications that monitor a large number of mailboxes, this is a potential limitation. In this case, you might want to consider alternative application architectures; for example, you might use polled synchronization of folders, journaling, or transport rules to route copies of messages to application-specific mailboxes.

The EWSMaxConcurrency policy element can also be an issue for EWS notifications; for example:

• When EWS increments the connection count for the owner of the subscription while the notification is being generated by a push subscription.

• When an application is designed to listen to multiple users' mailboxes, and users receive simultaneous notifications for an instance of a message that is sent to a distribution list.

If the notification application is multithreaded and makes simultaneous connection requests to get more information about a particular message that was received by a user account, the EWSMaxConcurrency policy limit can be exceeded. To account for this, consider monitoring the concurrent connections in your application, including those that might be used by the server, and implementing request queuing at the client side.

The values specified in the PercentTimeIn policy elements indicate the amount of time that one thread making one request is allocated. For example, if a process makes two concurrent requests that spend 54 seconds each running code on the Client Access server, the process uses 108 seconds in a 60 second window. This represents an EWSPercentTimeInCAS element value of 180 percent.

Note:

The EWSPercentTimeInCAS element value is an overlapping superset of the EWSPercentTimeInAD and EWSPercentTimeInMailboxRPC element values. This means that the expenditure in Client Access server processing time will always be larger than the expenditures in EWSPercentTimeInAD and EWSPercentTimeInMailboxRPC. This is because for the Exchange component to make an Active Directory or RPC call, it must already be running Client Access server code. In addition, the expenditure in processing time for EWSPercentTimeInCAS doesn't stop while LDAP or RPC calls are being made. Although the request might be synchronously waiting for a response from Active Directory or the Exchange store, the process is still consuming a thread on the server, and therefore the thread should continue to be charged for that usage.

The amount of CPU time an application may take in a 60-second period might exceed these throttling limits; therefore, it is important to consider the volume and type of requests that are being made. For example, a large batch of ResolveNames operations that are made simultaneously can exceed the EWSPercentTimeInAD policy element value. The policy values that are contained in the default throttling policy are designed to allow most EWS applications to function without issue; however, when multithreaded high-volume applications place a large volume of requests on one particular Client Access server, this can create problems. To avoid this, consider limiting the size of batches that are going to execute against the server.

The MessageRateLimit policy specifies the number of messages per minute that can be submitted by any Exchange client, including EWS. By default, this policy is set to 30 messages per minute. For ordinary users, this is generally sufficient. However, applications that send large batches of email messages, for example as part of an invoicing program, can run into problems. When this policy limit is exceeded, message delivery for the mailbox is delayed. Specifically, messages will appear in the Outbox or Drafts folder for longer periods of time when a user or application submits a larger number of messages than the value specified by the MessageRateLimit policy. Be sure to consider this when you are developing a delivery tracking system, especially if your application uses a mailbox that users connect to via Outlook. When deferred items are stored in the Outbox or drafts folder, users might interpret that as an error.

The RecipientRateLimit policy specifies the limit on the number of recipients that a user can address in a 24-hour period. By default, this policy is set to 500. This means that a single Exchange Online account can send messages to no more than 500 recipients each day. This limit applies to messages to recipients that are inside and outside the organization. This default limit might cause problems for some line-of-business applications that do end-of-month invoice runs and need to send messages to more than this number of recipients. You can use external services that enable batch processing of messages or separate on-premise outbound relay solutions to work around this limitation.

The ForwardeeLimit policy specifies the maximum number of recipients that messages can be forwarded or redirected to by means of Inbox rules. This parameter doesn't limit the number of messages that can be forwarded or redirected to the recipients.