This post is part of an ongoing series that covers Microsoft Exchange ActiveSync for developers.

Microsoft Exchange ActiveSync policies are the primary tool by which IT administrators can manage devices that connect to Microsoft Exchange mailboxes. Administrators can create policy settings to manage security settings such as PIN length, data encryption, and so on. Policies define the terms by which a client can synchronize mailbox data. The provisioning process is a communication that occurs between the client and server that indicates whether the client can enforces the required policies.

In addition to policies, Microsoft Exchange Server 2010 introduces another tool for administrators, known as Allow/Block/Quarantine (ABQ). ABQ enables administrators to control which devices or families of devices can synchronize data with Exchange ActiveSync. Administrators can also use ABQ to block certain devices or all unknown devices from synchronizing data.

Both ABQ and policies help administrators control how and whether data is synchronized onto a device. Remote Wipe is another Exchange ActiveSync feature that is used to remove data from a device. This feature is important when, for example, individuals leave the company, or a device is lost or stolen.

If you are creating an enterprise-class Exchange ActiveSync client, it is important for you to understand and support provisioning and policies, ABQ, and remote wipe. This post provides the information you need to know about these features, in the following sections:

• Provisioning
• Policies
• Remote wipe
• ABQ

Provisioning

The client’s goal in provisioning is to obtain a policy key from the Exchange server. This policy key enables the client to synchronize with a mailbox. Provisioning involves the following steps:

• The client sends information to the server to identify itself.
• The server sends security policies to the client that the client must enforce.
• The client indicates whether it is able to enforce the security policies.
• If the policies are applied successfully, the client is given a policy key that it then submits with subsequent requests to synchronize the mailbox.

For a detailed description of this process, see [MS-ASPROV]: ActiveSync Provisioning Protocol Specification section 3.1.5.1.

The following figure shows the two-step provisioning process.

Figure 1: Two-step provisioning process

Provisioning step 1: policy exchange between client and server

The policy exchange process involves a client Provision command request and a server Provision command response.

Client provisioning request

In its first request to the Exchange server, the client sends a Provision command request, as shown in the following example.

POST /Microsoft-Server-ActiveSync?User=deviceuser&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=Provision HTTP/1.1

Accept-Language: en-us

MS-ASProtocolVersion: 14.0

Content-Type: application/vnd.ms-sync.wbxml

X-MS-PolicyKey: 0

User-Agent: ASOM

Host: EXCH-B-003

 

<?xml version="1.0" encoding="utf-8"?>

<Provision xmlns="Provision:" xmlns:settings="Settings:">

    <settings:DeviceInformation>

        <settings:Set>

            <settings:Model>… </settings:Model>

            <settings:IMEI>...</settings:IMEI>

            <settings:FriendlyName>...</settings:FriendlyName>

            <settings:OS>...</settings:OS>

            <settings:OSLanguage>...</settings:OSLanguage>

            <settings:PhoneNumber>...</settings:PhoneNumber>

            <settings:MobileOperator>...</settings:MobileOperator>

            <settings:UserAgent>...</settings:UserAgent>

        </settings:Set>

    </settings:DeviceInformation>

     <Policies>

          <Policy>

               <PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>

          </Policy>

     </Policies>

</Provision>

The client Provision command request includes information contained within two parent elements:

• settings:DeviceInformation element
• Policies element

I will discuss the settings.DeviceInformation element in more detail in the "ABQ" section later in this post.

In the Policies element section, the client indicates in the PolicyType element the format of the policy information that the client wants the server to use. The client should always send the “MS-EAS-Provisioning-WBXML” value, as described in [MS-ASPROV] section 2.2.2.42.

Provisioning request for different Exchange ActiveSync protocol versions

The use of the settings:DeviceInformation element in the provisioning request varies based on the version of the Exchange ActiveSync protocol the client is using, as described in the following table.

For more information about the differences between Exchange ActiveSync protocol versions in client provisioning requests, see [MS-ASPROV] section 6.

Server provisioning response

The following example shows a server response to a client provisioning request.

Note: The policies listed in this example do not represent all the possible policies that the server might send. For a complete list of policies, see [MS-ASPROV] section 2.2.2.

HTTP/1.1 200 OK

Connection: Keep-Alive

Content-Length: 1069

Date: Mon, 01 May 2006 20:15:15 GMT

Content-Type: application/vnd.ms-sync.wbxml

Server: Microsoft-IIS/6.0

X-Powered-By: ASP.NET

X-AspNet-Version: 2.0.50727

MS-Server-ActiveSync: 8.0

Cache-Control: private

 

<?xml version="1.0" encoding="utf-8"?>

<Provision xmlns:A0="AirSync:" xmlns:A1="POOMCONTACTS:" xmlns:A2="POOMMAIL:" xmlns:A3="AirNotify:" xmlns:A4="POOMCAL:" xmlns:A5="Move:" xmlns:A6="GetItemEstimate:" xmlns:A7="FolderHierarchy:" xmlns:A8="MeetingResponse:" xmlns:A9="POOMTASKS:" xmlns:A10="ResolveRecipients:" xmlns:A11="ValidateCert:" xmlns:A12="POOMCONTACTS2:" xmlns:A13="Ping:" xmlns:A15="Search:" xmlns:A16="Gal:" xmlns:A17="AirSyncBase:" xmlns:A18="Settings:" xmlns:A19="DocumentLibrary:" xmlns:A20="ItemOperations:" xmlns:A21="ComposeMail:" xmlns:A22="POOMMAIL2:" xmlns:A23="Notes:" xmlns:A24="RightsManagement:" xmlns="Provision:">

  <Status>1 Success</Status>

  <Policies>

    <Policy>

      <PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>

      <Status>1 Success</Status>

      <PolicyKey>2488355417</PolicyKey>

      <Data>

        <eas-provisioningdoc>

          <DevicePasswordEnabled>1</DevicePasswordEnabled>

          <AlphanumericDevicePasswordRequired>0</AlphanumericDevicePasswordRequired>

          <PasswordRecoveryEnabled>0</PasswordRecoveryEnabled>

          <RequireStorageCardEncryption>0</RequireStorageCardEncryption>

          <AttachmentsEnabled>1</AttachmentsEnabled>

          <MinDevicePasswordLength>4</MinDevicePasswordLength>

          <MaxInactivityTimeDeviceLock>900</MaxInactivityTimeDeviceLock>

          <MaxDevicePasswordFailedAttempts>8</MaxDevicePasswordFailedAttempts>

          <MaxAttachmentSize/>

          <AllowSimpleDevicePassword>1</AllowSimpleDevicePassword>

          <DevicePasswordExpiration/>

          <DevicePasswordHistory>0</DevicePasswordHistory>

          <AllowStorageCard>1</AllowStorageCard>

          <AllowCamera>1</AllowCamera>

          <RequireDeviceEncryption>0</RequireDeviceEncryption>

          <AllowUnsignedApplications>1</AllowUnsignedApplications>

          <AllowUnsignedInstallationPackages>1</AllowUnsignedInstallationPackages>

          <MinDevicePasswordComplexCharacters>1</MinDevicePasswordComplexCharacters>

          <AllowWiFi>1</AllowWiFi>

          <AllowTextMessaging>1</AllowTextMessaging>

          <AllowPOPIMAPEmail>1</AllowPOPIMAPEmail>

          <AllowBluetooth>2</AllowBluetooth>

          <AllowIrDA>1</AllowIrDA>

          <RequireManualSyncWhenRoaming>0</RequireManualSyncWhenRoaming>

          <AllowDesktopSync>1</AllowDesktopSync>

          <MaxCalendarAgeFilter>0</MaxCalendarAgeFilter>

          <AllowHTMLEmail>1</AllowHTMLEmail>

          <MaxEmailAgeFilter>0</MaxEmailAgeFilter>

          <MaxEmailBodyTruncationSize>-1</MaxEmailBodyTruncationSize>

          <MaxEmailHTMLBodyTruncationSize>-1</MaxEmailHTMLBodyTruncationSize>

          <RequireSignedSMIMEMessages>0</RequireSignedSMIMEMessages>

          <RequireEncryptedSMIMEMessages>0</RequireEncryptedSMIMEMessages>

          <RequireSignedSMIMEAlgorithm>0</RequireSignedSMIMEAlgorithm>

          <RequireEncryptionSMIMEAlgorithm>0</RequireEncryptionSMIMEAlgorithm>

          <AllowSMIMEEncryptionAlgorithmNegotiation>2</AllowSMIMEEncryptionAlgorithmNegotiation>

          <AllowSMIMESoftCerts>1</AllowSMIMESoftCerts>

          <AllowBrowser>1</AllowBrowser>

          <AllowConsumerEmail>1</AllowConsumerEmail>

          <AllowRemoteDesktop>1</AllowRemoteDesktop>

          <AllowInternetSharing>1</AllowInternetSharing>

          <UnapprovedInROMApplicationList/>

          <ApprovedApplicationList/>

        </eas-provisioningdoc>

      </Data>

    </Policy>

  </Policies>

</Provision>

The response includes the following:

• A PolicyKey element, which contains a policy key that the client should retain and submit to the server with its next request.
• A Data element and its child elements, which contain the policy settings that the server requires the client to apply. For more information about individual policy settings, see "Policies" later in this blog post.

Notice that the response contains two Status elements. The first Status element is a child of the Provision element and indicates the general status of the Exchange server’s ability to process the client’s request. The following table lists the possible values for the first Status element.

The second Status element is a child of the Policy element and indicates whether the policy settings were applied correctly. The following table lists the possible values for the Status element.

Provisioning step 2: client acknowledges and applies policies

At this point, the server relies on the client to apply the policies as requested. After applying the security policy settings, the client sends another Provision command request to the server to acknowledge the policies and indicate its ability to apply them on the device.

The following example shows the second Provision request that the client sends to the server.

POST /Microsoft-Server-ActiveSync?User=deviceuser&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=Provision HTTP/1.1

Accept-Language: en-us

MS-ASProtocolVersion: 14.0

Content-Type: application/vnd.ms-sync.wbxml

X-MS-PolicyKey: 1307199584

User-Agent: ASOM

Host: EXCH-B-003

 

<?xml version="1.0" encoding="utf-8"?>

<Provision xmlns="Provision:">

     <Policies>

          <Policy>

               <PolicyType>MS-EAS-Provisioning-WBXML</PolicyType>

 <PolicyKey>1307199584</PolicyKey>

               <Status>1</Status>

          </Policy>

     </Policies>

</Provision>

This request contains the policy key value that the server sent to the client in step 1. It also contains a Status element that indicates whether the client was able to apply the policy settings. The following table lists the possible values of the Status element.

Note: If a Microsoft Exchange administrator sets the "Allow non-provisionable devices" option in the Exchange ActiveSync policy, the server will allow all clients to synchronize mailbox data regardless of whether the client asked for policy settings or applied them successfully. However, if the administrator chooses to disable the "Allow non-provisionable devices" option, only clients that respond with "Success" are allowed to connect to the mailbox.

Note: If the DevicePasswordEnabled policy is set to true, and the device is not able to enforce the password, it must return "failure" in response to the Provision command, regardless of whether it can enforce any other policy. The client can return "partial success" if it cannot enforce any other policies. For example, if the client enabled a password but failed to encrypt the device, it can return "partial success" rather than "failure".

The following example shows the server's response to the second client Provision request.

HTTP/1.1 200 OK

Connection: Keep-Alive

Content-Length: 63

Date: Mon, 01 May 2006 20:15:17 GMT

Content-Type: application/vnd.ms-sync.wbxml

Server: Microsoft-IIS/6.0

X-Powered-By: ASP.NET

X-AspNet-Version: 2.0.50727

MS-Server-ActiveSync: 8.0

Cache-Control: private

 

<?xml version="1.0" encoding="utf-8"?>

<Provision xmlns="Provision:">

     <Status>1</Status>

     <Policies>

          <Policy>

               <PolicyType> MS-EAS-Provisioning-WBXML </PolicyType>

               <Status>1</Status>

               <PolicyKey>3942919513</PolicyKey>

          </Policy>

     </Policies>

</Provision>

This response does not include a Data element that contains the list of policy settings. The server simply responds with a Status element (the values for which are listed in the "Server provisioning response" section) and a new policy key. This new policy key is the permanent key that the client should save and resubmit when it sends subsequent requests to the server.

Client handling of the policy key

The policy key represents the current security policy settings that are applied on the client. It can be up to 64 characters long and can contain any of the characters that are allowed in an HTTP header. The client should retain only the latest policy key that it has received from the server and submit it with all requests.

Note: Submitting the policy key is optional the Ping command and the HTTP OPTIONS commands.

The following example shows a client request that includes the policy key.

POST /Microsoft-Server-ActiveSync?User=deviceuser&DeviceId=6F24CAD599A5BF1A690246B8C68FAE8D&DeviceType=PocketPC&Cmd=FolderSync HTTP/1.1

Accept-Language: en-us

MS-ASProtocolVersion: 14.0

Content-Type: application/vnd.ms-sync.wbxml

X-MS-PolicyKey: 3942919513

User-Agent: ASOM

Host: EXCH-B-003

 

<?xml version="1.0" encoding="utf-8"?>

<FolderSync xmlns="FolderHierarchy:">

     <SyncKey>0</SyncKey>

</FolderSync>

When should a client provision?

Clients should send a Provision command request when they first contact the server. In some scenarios, the server may require the client to provision again, after an initial provision sequence. The server indicates this by sending a 449 HTTP error response or a success response with one of the status codes listed in the following table in response to any client request. The client should immediately send a Provision command request after receiving one of these statuses in a response.

In version 12.1 of the Exchange ActiveSync protocol, the server only sends an HTTP 449 response to inform the client that it needs to provision; it does not send the status codes listed in the previous table. Because this error response does not enable the client to distinguish between transient and potentially nontransient provisioning errors, the client should try to provision. If subsequent requests fail with additional HTTP 449 error respon ses, the client should suggest that the user contact their administrator. At that point, the client may choose to try to provision once per hour to determine whether the policy has changed.

Policies

Because it is up to the client to enforce policies, it is important to understand the effects that each policy will have on the device when applied. For a list of the elements that contain policy information, see [MS-ASPROV] section 2.2.2. This information will help you to determine acceptable values and expected results for each policy. For more information about policies in general, see Understanding Exchange ActiveSync Mailbox Policies on Microsoft TechNet.

This section lists and describes some of the policies that are available; it does not provide a comprehensive list of all policies. For more information about policies, see [MS-ASPROV].

The following table lists policies that clients can ignore and describes the conditions in which they can be ignored. If the conditions apply, the client can return "success" although the policy is not applied. Policies that are not listed in this table cannot be ignored under any conditions.

The following table lists additional policies and describes the expected behavior:

Remote Wipe

The remote wipe process enables administrators to request that the client erase all data from a device. Remote wipe is used in scenarios in which a device is lost or stolen or when a user has left the company or no longer has permission to synchronize corporate data. Administrators can use the Exchange Management Shell or the Exchange Management Console (EMC) to request a remote wipe. For more information, see Understanding Remote Device Wipe on Microsoft TechNet.

After an administrator requests a remote wipe, the next time the client sends a request to the server, the server will respond with status code 140, RemoteWipeRequested. The client should then submit a Provision command request. If the server's response contains a RemoteWipe element, the client should send an acknowledgement that it is about to wipe the device first. Because the wipe will erase all data from memory and storage, the client sends the acknowledgement first because it will not have the information it needs to send requests after it wipes the device. For examples of the requests and responses that are sent during the remote wipe process, see [MS-ASPROV] section 4.2.

The following is an example of a server response to a Provision command request that includes a RemoteWipe element.

Content-Type: application/vnd.ms-sync.wbxml

Date: Wed, 25 Mar 2009 01:23:58 GMT

Content-Length: 14

 

<?xml version="1.0" encoding="utf-8"?>

<Provision>

<Status>1</Status>

<RemoteWipe />

</Provision>

The following example shows a Provision command request from the client that contains the remote wipe status.

POST /Microsoft-Server-ActiveSync?Cmd=Provision&User=T0SyncUser1v14.0&DeviceId=Device1&DeviceType=PocketPC HTTP/1.1

Content-Type: application/vnd.ms-sync.wbxml

MS-ASProtocolVersion: 14.0

X-MS-PolicyKey: 0

User-Agent: ASOM

Host: EXCH-B-003

 

<?xml version="1.0" encoding="utf-8"?>

<Provision xmlns="Provision:">

    <RemoteWipe>

        <Status>1</Status>

    </RemoteWipe>

</Provision>

The client should include one of the following values in the Status element:

• 1 (Success) — Indicates that the client will wipe the device shortly after sending.
• 2 (Failure) — Indicates that the client could not wipe the device.

ABQ

Allow/Block/Quarantine (ABQ) is a new feature introduced in Exchange 2010 that enables administrators to control device access to mailboxes based on device type. While provisioning and policies focus on managing device features such as passwords, cameras, encryption, and so on, ABQ simply controls access to the mailbox. Administrators use ABQ along with policies to manage Exchange ActiveSync clients. For more information, see Controlling Exchange ActiveSync device access using the Allow/Block/Quarantine list on the Exchange Team Blog.

Microsoft Exchange manages access to the mailbox through ABQ by using device information that it relies on the client to provide. The client sends this information in the Provision command request or as part of the Settings command, as shown in the following example.

<?xml version="1.0" encoding="utf-8"?>

<Settings xmlns="Settings:">

    <DeviceInformation>

        <Set>

            <Model>CONTOSO</Model>

            <IMEI>123456789012345</IMEI>

            <FriendlyName>Matt's Phone</FriendlyName>

            <OS>Contoso Phone1.0.1234</OS>

            <OSLanguage>English</OSLanguage>

            <PhoneNumber>555-555-1234</PhoneNumber>

            <MobileOperator>ContosoTelecom</MobileOperator>

            <UserAgent>ContosoPhone1</UserAgent>

            <EnableOutboundSMS>1</EnableOutboundSMS>

        </Set>

    </DeviceInformation>

</Settings>

The elements set by the client are listed in the following table:

Related Resources

[MS-ASCMD]: ActiveSync Command Reference Protocol Specification

[MS-ASPROV]: ActiveSync Provisioning Protocol Specification

Understanding Exchange ActiveSync Mailbox Policies

Understanding Remote Device Wipe

Controlling Exchange ActiveSync device access using the Allow/Block/Quarantine list

Post authored by: Matt Stehle, Microsoft Corporation

The JET_ERRINFOBASIC_W API includes a group of constants, a structure, and a function, as defined in the header file Esent.h. These are described in this blog post.

Note: This documentation is based on a preliminary release of the Extensible Storage Engine. This information is subject to change.

JET_ERRCAT Constants

The JET_ERRCAT group of constants describes higher-level classifications or categories of errors. This group of constants enables applications to define default treatment for a classification of errors, rather than handling each error case individually. It also ensures that the application does not have to handle new error conditions that are included in existing classifications.

The JET_ERRCAT constants are arranged in a specific hierarchy of conditions and subconditions, as follows:

|--- Error
|--- Operation(al)
| |--- Fatal
| |--- IO
| |--- Resource
| |--- Memory
| |--- Quota
| |--- Disk
|
|--- Data
| |--- Corruption
| |--- Inconsistent
| |--- Fragmentation
|
|--- Api
|--- Usage
|--- State

The following table lists the JET_ERRCAT constants and provides a description and recovery information, as applicable.

Requirements

JET_ERRINFOBASIC_W Structure

The JET_ERRINFOBASIC_W structure defines the data that is returned from the JetGetErrorInfo() method when the JET_ErrorInfoSpecificErr InfoLevel [LG1] is passed in.

typedef struct {
         unsigned long    cbStruct;
         JET_ERR          errValue;
         JET_ERRCAT       errcatMostSpecific;
         unsigned char    rgCategoricalHierarchy[8];
         unsigned long    lSourceLine;
         WCHAR            rgszSourceFile[64];
} JET_ERRINFOBASIC_W;

Members

cbStruct
The size of the structure, in bytes. It must be set to sizeof( JET_ERRINFOBASIC ).

errValue
The error value that was evaluated, as passed in for the pvResult argument to JetGetErrorInfo().

errcatMostSpecific
The lowest-level JET_errcat constant that is associated with the error; that is, the leaf-level category in the category hierarchy documented in JET_ERRCAT.

rgCategoricalHierarchy[8]
The hierarchy of error categories that is associated with the error. Position 0 is the highest level in the hierarchy of JET_ERRCAT, and the rest are subcategories until the most specific category is set, after which all categories are JET_errcatUnknown.

lSourceLine
Reserved.

rgszSourceFile[64]
Reserved.

Requirements

JetGetErrorInfoW Function

The JetGetErrorInfoW function BAS_ of the database engine.

JET_ERR JET_API JetGetErrorInfoW(
         _In_opt_ void *                    pvContext,
         _Out_writes_bytes_( cbMax ) void * pvResult,
         _In_ unsigned long                 cbMax,
         _In_ unsigned long                 InfoLevel,
         _In_ JET_GRBIT                     grbit );

Parameters

pvContext
The context or error value for which the extended error information is needed. The value passed in depends on the InfoLevel parameter value.

pvResult
A pointer to a buffer that will receive the information. The type of the buffer depends on the InfoLevel parameter value. The caller must be configured to align the buffer appropriately.

cbMax
The maximum size of the pvResult structure that is passed in.

InfoLevel
The type of information that will be retrieved for the error info/context is specified by the pvContext parameter. The format of the data that is stored in pvResult is dependent on InfoLevel.

The following table lists the possible values for this parameter.

grbit
Reserved.

Return Value

This function returns the JET_ERR data type with one of the return codes listed in the following table. For more information about the possible ESE errors, see Extensible Storage Engine Errors and Error Handling Parameters.

On success, the output buffer that is appropriate for the requested error context/value will be set to the extended error info requested.

On failure, the state of the output buffers will be undefined.

Remarks

The JET_ERRINFOBASIC_W function and JET_ERRCAT group of constants contain documentation about the extended error information that is returned for InfoLevel = JET_ErrorInfoSpecificErr.

Requirements

Exchange Web Services (EWS) is a robust API that exposes many Exchange client access features. Many popular clients use this API on many different platforms. What if you want to limit client access via EWS, however? You do have an option. In Exchange 2010, you can use the Set-CASMailbox command to modify EWS access.

Note:   The Set-CASMailbox command in Exchange 2007 does not provide options for limiting EWS access.

The following options that the Set-CASMailbox command exposes enable you to change the settings on a per-user basis:

• Turn EWS on/off
• Turn EWS on/off for Outlook, Mac Outlook, and Entourage
• Turn EWS on/off using allow/block lists for user agent filtering

These options make use of the user agent header to filter access. While useful in many scenarios, user agent filtering has one  inherent disadvantage: User agent strings can easily be written to represent agents on an allowed list, including Outlook, Mac Outlook, and Entourage. Of equal importance is the fact that specific EWS features can’t be blocked. EWS feature access is not segmented to allow access to particular EWS operations — it’s all or nothing. Turning off EWS will affect clients that use the OOF settings, availability, mail tips, and so on. It is important to take this into consideration when planning the client-server interaction part of your system architecture.

Are you ready? The EWS Managed API 1.2 documentation is now available, so let the preparation, planning, and architecting begin. The new EWS Managed API will have some updates that you may want to incorporate into your application. Take a look at the What’s New topic to learn more about the new content that is available to support the new EWS Managed API 1.2 functionality. Take a look at the Exchange Web Services Managed API 1.2 SDK topic to learn about the new EWS Managed API 1.2 functionality. 

Did you say “Where is the API download?” It’s coming soon. We are releasing the documentation earlier than usual so that you can get a jump on your planning for the next update of your EWS client application. So go have a feature review, maybe update your design specs, and get ready to implement your next update to your EWS client application.

In November and December 2011, Exchange content made its debut on the Learn Open Specifications and Interoperability page in the Open Specifications Developer Center:

The updates include nine new Microsoft Exchange Learning Modules:

• Getting Started
• The Mailbox, Folders, and Public Storage
• Messages and Attachments
• Calendars
• Contacts and Address Books
• Tasks, Documents, and Notes
• Inbox Rules and Spam Filtering
• Synchronization
• Search and Miscellaneous

While you’re on the Learn tab exploring the new Exchange learning modules, don’t miss the Open Specifications Interactive Pivot, which also includes Exchange open specifications documents. We’re very excited about the Pivot, which makes it easy to find the open specifications documents you need in a visual, intuitive way. The Pivot uses Silverlight Deep zoom technology, which lets you visually search and filter the open specifications documents. Once you use it, you’ll see why we’re excited.

Several times we’ve heard people ask what the maximum size is for the EWS identifier. This question usually comes up when developers are designing a database schema that will store the EWS identifier in a fixed-width column. Our answer is that the EWS item identifier should be contained in a fixed-width column of 512 characters. So, how confident should you feel about defining your field at 512 characters? Well, of course we reserve the right to change the format, and the resulting maximum length of the EWS identifier. The chances of that occurring, however, are very slim. The EWS identifier format has been changed once between Exchange 2007 and 2007 SP1, early on in the adoption of EWS, but we acknowledge that changing the format at this point would have unwelcome effects on both customer and Microsoft applications that interoperate with Exchange. In short, we do not expect the EWS identifier format to change.

We have made a change to the way that Exchange Online accounts for the number of subscriptions against the EWSMaxSubscriptions throttling limit.

In earlier versions of Exchange Online, the throttling limit was calculated against the calling account. A calling account, which can be one or many client applications or a service account targeting many mailboxes, was limited to 20 notification subscriptions. This subscription limit restricted Exchange Impersonation scenarios in which a service account accesses a large number of mailboxes. It limited a service account to at most access to 20 different mailboxes, assuming one subscription per mailbox, or 20 subscriptions on one mailbox. This was not very scalable. For example, if a service account had to access 5000 mailboxes, you had to have 250 service accounts to account for this limitation.

Starting with service mailbox versions 14.16.0135 and 14.15.0057.000, this limit has changed. Now, the charges are counted against the target mailbox rather than the calling account. This way, a service account can create subscriptions against many more than 20 mailboxes. One benefit of this change is that you can now design a service application that targets Exchange Online and Exchange on-premises using a similar code base for subscription management. A single service account can now service up to 5000 subscriptions.

Customers, you asked for this change, and now you have it. Subscribe on!  

In my last post, Exchange Online EWSMaxSubscriptions throttling budget calculation has been updated!, I wrote about a recent change to the EWSMaxSubscriptions throttling setting. Although useful, that information is just one part of the story. Now I’m here to fill you in on the rest.

We have made changes to the way that throttling budgets are counted for application impersonation calls. Now, the calls are charged against the target mailbox instead of the service account that makes the application impersonation calls. More specifically, the charges are counted against a copy of the target mailbox quota. This means that the impersonated service account access is not charged against the target mailbox account owner’s throttling budget. It is important to note that the copied budget is shared across all service accounts that are using application impersonation. This information is important when you are enabling many application impersonation scenarios against mailboxes. In summary, each throttling setting represents two budgets: one for the user account, and one for all service applications that use application impersonation against a specific user mailbox.

Here is a complete list of the throttling settings that have been updated with the new budget accounting:

• EWSMaxConcurrency                    
• EWSPercentTimeInAD                       
• EWSPercentTimeInCAS                      
• EWSPercentTimeInMailboxRPC     
• EWSMaxSubscriptions                      
• EWSFastSearchTimeoutInSeconds            
• EWSFindCountLimit

I’d expect this to be welcome news. With that said, there is one exception to the change. The EWSMaxConcurrency setting limit does have some variation in how it is implemented for different types of connections. EWS streaming notifications have a separate budget from all other EWS client connections. For example, if EWSMaxConcurrency is set to the value of 10, it means that a user account (and all service applications using application impersonation) can have up 10 concurrent streaming notification subscriptions and 10 other concurrent EWS connections while targeting a single mailbox.

What does this mean for Exchange Online and streaming subscriptions? In short, this means that a service account can monitor up to 2000 mailboxes. Allow me to explain how this works. A service account application using application impersonation performs Subscribe operations using impersonation to set up subscriptions for each of the target mailboxes. Then, the service account application would bundle all the SubscriptionIds, up to 200 per GetStreamingEvents request, from all the mailboxes and include them in one GetStreamingEvents request. (NOTE: GetStreamingEvents and GetEvents operations do not have to use the impersonation header to get the notification events for the impersonated email messages. As long as the service account has a valid SubscriptionId, it can access the event notifications.) A service account can have at most 10 open GetStreamingEvents requests open at any one time. We recommend that there are no more than 200 SubscriptionIds in each GetStreamingEvents request. This effectively means that a single service account can monitor up to 2000 subscriptions, or 2000 mailboxes if you assume one subscription per mailbox. We expect that this should scale fairly well.

As with my last post, these changes have taken effect as of service mailbox versions 14.16.0135 and 14.15.0057.000 and later. These are customer-driven changes and we do appreciate the feedback. Code on!

The latest release of the EWS Managed API, version 1.2.1, is now available. The EWS Managed API 1.2.1 includes new Exchange Web Services (EWS) client logging features for Exchange Online as part of Office 365, as well as some minor bug fixes. You can download the EWS Managed API 1.2.1 from the Microsoft Download Center.

What’s new in the EWS Managed API 1.2.1

The EWS Managed API 1.2.1 includes new Exchange Online–specific functionality for logging client access and client latencies. This new functionality is implemented by means of two new HTTP headers: RequestId and X-ClientStatistics. Starting with the EWS Managed API 1.2.1, this functionality is enabled by default.  You can enable this functionality in previous versions of the EWS Managed API by accessing the HttpHeaders and HttpResponseHeaders collection on the ExchangeService object.

This change allows for the debugging of communication issues that occur between Exchange Online and the EWS Managed API. In fact, this functionality should be implemented by any EWS client that will be targeting Exchange Online.

The new RequestId header is returned in every response from EWS in versions of Exchange starting with Exchange Server 2010 SP2 RU2, and in Exchange Online. While this header is available for both an on-premise Exchange deployment and Exchange Online, it is particularly relevant for Exchange Online. The RequestId header contains a GUID value that uniquely identifies your request in the Office 365 server-side logs across all the Office 365 data centers. Essentially, you should log these requests with the client. If a support incident does occur, you can provide the RequestId to the Office 365 support engineers to help them identify issues related to request.

You can use the new X-ClientStatistics header to provide additional logging information for Exchange Online. You can enable additional performance logging for Exchange Online by providing the following information in your requests:

• The RequestId received from a previous request
• The client-logged roundtrip time between the request and response
• The SOAP action

Note that the X-ClientStatistics header can be used to report data back to Office 365 at any time and that it can batch multiple latencies in a single header. This is another useful resource for Office 365 support engineers.

Important: The X-ClientStatistics functionality is not available for on-premise Exchange deployments.

The RequestId and X-ClientStatistics headers are both implemented in the EWS Managed API 1.2.1. The RequestId header is sent by Exchange with every response. You can disable the X-ClientStatistics functionality on the ExchangeService object by setting the new SendClientLatencies properties to false.

• RequestId: <GUID>; where <GUID> is the unique request identifier.
• X-ClientStatistics: MessageId=<RequestIdFromPreviousResponse>,ResponseTime=<EndToEndLatencyInMiliseconds>,SoapAction<operation>; where <RequestIdFromPreviousResponse> is a request identifier from a previous response, <EndToEndLatencyInMiliseconds> is the client-logged round trip time between when the request was submitted and when the response was received for the request-response identified by the RequestId, and <operation> identifies the SOAPAction header for the request identified by the RequestId header. If you are sending multiple client latency reports back to the server, you must separate the latencies with a semicolon.

The EWS Managed API 1.2.1 fixes two Autodiscover redirect issues for scenarios in which an Exchange Server 2013 Preview user targets a request to an Exchange 2010 server.

While not a large set of changes, they are still interesting. These updates will primarily help Office 365 support engineers help you if your application experiences issues communicating with the server. This should help make our service perform better, and your problems to be solved in a shorter amount of time.

Now that Exchange Server 2013 Preview is available, here's a quick summary of what you'll find on MSDN to help you learn more about the latest new features. For a detailed look at what's new in Exchange 2013 Preview, see the Exchange Team Blog.

Developer roadmap for Exchange

We created a new Developer roadmap for Exchange that provides an overview of what's new in Exchange development, and is designed to help you determine the best way to develop your Exchange applications. It covers the technologies that are available in each version of Exchange and the evaluation criteria that you can use to select the right development technology for your application. If you're planning to migrate to Exchange 2013 Preview, you'll find information about migrating your applications from earlier versions of Exchange to the new version in the article Migrate from earlier technologies to Exchange 2013. Feel free to leave us a comment to let us know which migration scenarios are important to you.

Changes to the EWS APIs

Exchange Web Services (EWS) and the EWS Managed API have been updated to provide programmatic access to the new features in Exchange 2013 Preview. We’ve added documentation to support the following new features:

· eDiscovery — Enables you to preserve and discover data across your organization to ensure internal and regulatory compliance.

· Archiving — Enables you to move mail items from a primary mailbox to an archive mailbox for long-term storage.

· Retention policies — Enables you to group retention tags, apply retention settings to folders and individual items, and apply retention settings to a mailbox.

· Block senders and mark email as junk — Enables you to keep junk email messages out of users' Inboxes.

· Getting user photos — Gets the photo that is associated with an email account from an Exchange server by using a simple HTTP GET request.

· Personas (EWS only) — Enables you to link to, search for, and browse for information about a person from multiple sources.

· Unified Contact Store (EWS only) — Enables you to store, manage, and access contact information from any application.

For more information about these new features, see New features in the EWS Managed API and New features in EWS in Exchange 2013.

Mail apps for Outlook

One of the exciting new features of Microsoft Office 2013 Preview is apps for Office. Apps for Office enable you to extend the power of Office applications by using standard web technologies to create individual apps. Exchange server supports mail apps for Outlook and Outlook Web App to add contextual information to email messages and calendar appointments. For information about migrating from a customized Outlook Web App to mail apps for Outlook, see Migrate to mail apps for Outlook Web App customization. For information about how to create mail apps for Outlook and Outlook Web App, see Mail apps for Outlook. See also the new blog dedicated to apps for Office, the Apps for Office and SharePoint blog.

Exchange 2013 101 code samples

Want code samples? New for Exchange 2013 Preview is the Exchange 2013 101 code samples package, which includes code samples that will help you to develop Exchange 2013 Preview applications by using the EWS Managed API. The package currently includes 38 code samples, and we’ll add more. You can download them all, or you can select just the ones that you want and download them individually. For a list of all the code samples that are currently available, see EWS Managed API code samples.

Join the conversation

Finally, we invite you to take advantage of the Community feature to give us feedback on our Exchange 2013 Preview documentation. Let us know how we can improve our content to better meet your needs. We’ll also be updating the documentation periodically, so keep an eye out for new content announcements.

The wait is over. If you have been working with the EWS Managed API 2.0 Technical Preview, you can now get the new 2.0 version and check out the latest updates. You can download the EWS Managed API 2.0 from the Microsoft Download Center.

What's new in the EWS Managed API 2.0

The EWS Managed API has been updated to support some of the latest features that are available in Exchange Web Services (EWS) in Exchange Server 2013, including the following:

• eDiscovery
• Archiving
• Retention policies
• Mail apps for Outlook

For more information about these features, see the article New features in the EWS Managed API.

In addition to these features, the EWS Managed API 2.0 introduces the ServerBusyException class. This class represents a server busy exception that can be found in a service response. You can use the BackOffMilliseconds property of this class to set the number of milliseconds to wait before the service attempts a request again, or you can set it to zero if there is no suggested back off time.

If you have been using the EWS Managed API 2.0 Technical Preview, you might have noticed a new requirement. The EWS Managed API 2.0 Technical Preview required the .NET Framework 4, which might not be compatible with applications that you wrote with earlier versions of the EWS Managed API. That requirement has been rolled back in the EWS Managed API 2.0, which requires the .NET Framework 3.5.

The EWS Managed API 2.0 download also includes the Exchange Server 2013 token validation library. You can use the EWS Managed API and the library to build mail apps for Outlook that can be authenticated by the identity tokens issued by Exchange 2013. For more information about the EWS Managed API 2.0 and the token validation library, see Authenticating a mail app by using Exchange 2013 identity tokens.

Don’t forget to check out our collection of code samples that will help you develop Exchange 2013 applications by using EWS Managed API. Currently 38 code samples are available; check back for more. For a list of the current code samples, see EWS Managed API code samples.

The new EWS Managed API 2.0 is ready forprime time, and discovering how to use all the new Exchange Server 2013 features just got easier.

The EWS Managed API developer reference content has been updated to include descriptions, summaries, return values, and applicability statements for all new members.
In most cases, the updated member topics are for features that are new in Exchange 2013, but some existing members have been updated to reflect new functionality as well.  

For a list of new and updated types and member topics, see New EWS Managed API content. To find the EWS Managed API developer reference content, see EWS Managed API  namespaces.

The new and updated EWS Managed API reference content supports the following new Exchange 2013 features:

• eDiscovery
• Archiving
• Retention policies
• Mail apps for Outlook

For more information about these features, see the article New features in the EWS Managed API.

For information about the EWS Managed API 2.0, see the Exchange API-spotting post,
EWS Managed API 2.0 – now released!

For a great article that explains how to get conversation items from an Exchange mailbox by using the EWS Managed API,
check out How to: Get conversation items by using the EWS Managed API.

Don’t forget to check out our collection of code samples to help you develop Exchange 2013 applications by
using EWS Managed API. Currently, 38 code samples are available; check back for more. For a list of the current code samples, 
see EWS Managed API code samples.

The EWS Java API 1.2 is now available, with added support for functionality in Exchange Server 2010 SP2. It also includes an important update to the license terms that affects what you can do with the source code and the redistribution terms.

Feature-wise, we’ve implemented the following updates to the EWS Java API, which might be of interest to you:

• The API now targets the Exchange 2010 SP2 version of the schema.
• We've added synchronous request-response pattern implemented for handling communication with the service.
• The FullContactData option of the ResolveNames operation now includes new directory properties.
• Streaming notifications includes the following updates :
• Subscription creation no longer causes a deadlock.
• The StreamingSubscription object no longer causes a crash when the Microsoft.Exchange.Data.Storage.MailboxSession object is disposed.
• Get password expiration date functionality has been implemented.
• Logging capability for the HTTP headers is now included.
• The HTTPHeader collection now correctly populates with the response HTTP headers.

For more information about what's new in the EWS Java API 1.2, see the release notes included in the download.

In some ways, the biggest change is that we have updated the license terms to give you a bit more freedom to customize the EWS Java API. The license updates enable you, the licensee, to do the following:

1. Modify the source code to fix bugs and make improvements in your own private branch of the code.
2. Redistribute in binary format only, as part of your application, the EWS Java API, with any changes that you have made to the original source code.
3. Submit bug fixes or source code to Microsoft. We can incorporate the fixes into future API releases, at our discretion.

As always, be sure to review the authoritative license terms for details.

Hopefully, these more flexible terms will open more possibilities for you to incorporate Exchange integration into your products. This update has been a long time coming, so start up your IDE, rev up your (private) code repository, and take off using the latest EWS Java API!

Exchange 2010 SP3 does not introduce any changes to the EWS schema or WSDL files. This means that you can use the RequestServerVersion element value of Exchange2010_SP2 to target Exchange 2010 SP3. That said, two changes in Exchange 2010 SP3 do affect EWS clients.

First, the throttling budget for Exchange impersonation scenarios uses a clone of the EWSMaxConcurrency throttling budget. This means that a user has a separate throttling budget than an account that is impersonating that user.. For more information, read the Throttling considerations for applications that use EWS impersonation section of the EWS Throttling in Exchange 2013 article.

The second change involves Exchange 2010 and Exchange 2013 coexistence. In versions of Exchange earlier than Exchange 2010 SP3, the Client Access server version has to match the Mailbox server version. Starting with Exchange 2010 SP3, a client that sends EWS requests to an Exchange 2010 Client Access server can target an Exchange 2013 mailbox.

Interested in learning more about the Exchange Server RPC protocols? The Exchange Server Interoperability team is pleased to announce that presentations from the Exchange RPC Protocols Plugfest event (January 2011) are now available on Channel 9. Plugfest events are part of the Microsoft Open Specifications Program which helps developers create solutions by providing open access to technical specifications and support through a variety of channels.

If you’re working with the Microsoft Exchange protocols, check out the Exchange RPC Protocols Plugfest January 2011 series on Channel 9 for valuable information about the following topics:

• Exchange Fast Transfer and Incremental Change Synchronization ([MS-OXCFXICS])
• Exchange RPC and ROPs ([MS-OXCROPS])
• Exchange Protocol Test Suite Architecture
• Exchange Protocol Objects and Properties ([MS-OXCPRPT])

Kim Brandl
Exchange Interoperability
Microsoft Corporation

Microsoft Exchange Online as part of Microsoft Office 365 provides many of the same app-development capabilities that are available for Microsoft Exchange Server running on-site. The Exchange Developer Documentation team is pleased to announce the release of a new Exchange Online Developer Center page that will be your portal for information about Exchange Online development.

If you’re not quite up to the rock-star level as an Exchange programmer, or if Exchange Online is the only flavor of Exchange you’ve ever known, this is the place for you! And even if you’re already an experienced Exchange developer, we want to make it really easy to use that Exchange knowledge as you create apps for the Cloud.

Along with the new Exchange Online page, we have an article to help you get started writing apps that use Exchange Web Services (EWS) and EWS Managed API. This article explains the important first steps to get things running smoothly and quickly.

We have more articles coming in the near future, including one about configuring and using Exchange Autodiscover, so come back to the site often to find new information. We plan to provide great information for programming with Exchange Online for all types of developers, from experienced corporate and ISV developers to total newbies.

A bunch of articles, of course, can’t tell the whole story. As the Office 365 Beta progresses, and as the service officially becomes available, we’ll continue posting articles, blog posts, podcasts, and even videos. Because we know you’ll have questions, the writing team will also be helping out in the forums.

We look forward to hearing from you more than ever, and to helping your Exchange development projects succeed.

Best regards to our new and current readers,

Thom Randolph
Exchange Developer Documentation
Microsoft Corporation

We are pleased to announce the availability of the Microsoft Office 2010 Developer Map. Whether you are new to developing with Microsoft Exchange, or a seasoned veteran, this map will guide you through the tools, applications, platforms, and services you can use to develop your application. The interactive map is a living document that provides links to MSDN Library documentation. You can also download the poster and print it out to hang on your wall.

Start visualizing the applications, services like Exchange Online, client/server data-access technologies like Exchange Web Services, on-premise servers, platform products and technologies, and tools that can help you build multiple line-of-business solutions. 

• Interactive map: http://msdn.microsoft.com/office2010devmap
• Poster download: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e92d8703-342e-4bd6-8877-d22b888ff29b

Bob Bunn
Exchange Developer Documentation
Microsoft Corporation

We are specifically focused on throttling of Exchange Web Services (EWS) and MAPI with RPC over HTTP (as used by Microsoft Outlook) and with hard limits set by the Exchange Online system. Any mention of specific setting values were obtained for the service version 14.0.100.0. You will want to have your tenant admin obtain and confirm setting values.

Note   An on-premise Microsoft Exchange deployment may have a different throttling policy. Administrators can modify throttling settings for Microsoft Exchange on-premises. Administrators cannot configure throttling policies for Exchange Online.

What is the impact of exceeding throttling budgets?

Exchange throttling is based on the amount of Active Directory, Exchange store, and other resources a client consumes. A budget is allocated to each client to limit the resources a particular user consumes. This budget is recharged every minute.

EWS clients can exceed their budgets by sending too many concurrent requests, or by requesting too many resources on the server. When this occurs, additional requests are queued until one of two things happen:

• The application is under budget. The request is then processed and the client experiences an increase in latency.
• The request has been queued for more than 60 seconds, after which time the server sends an error response to the application.

When MAPI clients exceed their budgets, additional requests are returned with an error, until the application is under budget. There is no queuing of requests.

How do I get throttling settings?

Tenant administrators can view throttling settings by using Remote PowerShell and the Get-ThrottlingPolicy cmdlet. For information about how to connect Remote PowerShell for your tenant, see Install and Configure Windows PowerShell and Connect Windows PowerShell to the Service on Microsoft TechNet.

Use the Get-ThrottlingPolicy cmdlet (without arguments) to get all the throttling policy settings. Throttling policies might change to enhance service performance, so you should confirm throttling policies. We suggest that you make your client applications configurable to adjust for potential changes in throttling policy for Exchange Online. Additionally, because Exchange Online and Exchange on-premises might have different throttling policies, you may want to account for this when you design your client applications.

What are the common throttling settings?

The following throttling settings are common to both EWS and MAPI (RPC over HTTP) clients:

• MessageRateLimit– Identifies the maximum number of messages that can be sent per minute. This is configured to count sent messages on a per IP address basis.
• RecipientRateLimit– Identifies the maximum number of recipients that a sender can send to in a 24-hour period.
• ForwardeeLimit– Identifies the maximum number of recipients that can be configured for Inbox rules when the user account is using the forward or redirect action.

What are the MAPI with RPC over HTTP throttling settings?

The prefix RCA in the MAPI RPC/HTTP settings represents RPC Client Access. The following throttling settings are specific to MAPI RPC over HTTP:

• RCAMaxConcurrency– Identifies the maximum number of concurrent connections that can be maintained by MAPI RPC/HTTP clients (such as Microsoft Outlook) at any one time. Attempts to open more than the maximum number of connections will fail. Existing connections will remain unaffected. Active Directory calls count toward the number of concurrent connections. 
• RCAPercentTimeInAD– Identifies the maximum amount of time that can be spent by a Client Access server when accessing Active Directory resources on behalf of a client, per minute. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the result by 60 seconds. For example, an RCAPercentTimeInAD throttling value of 5 results in a throttling threshold of 3 seconds (5/100 * 60 seconds).
• RCAPercentTimeInCAS– Identifies how much time all concurrent MAPI RPC/HTTP connections can consume on the Client Access server per minute. This is calculated on a per user basis. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, an RCAPercentTimeInCAS throttling value of 205 results in a throttling threshold of 123 seconds (205/100 * 60 seconds). If the setting is 123 seconds, two concurrent MAPI RPC/HTTP connections can be open on a Client Access server for a full 60 seconds, thus using up 120 seconds per minute. A third connection can only use the remaining 3 seconds per minute, assuming all three connections occur concurrently and are initiated at the same time. 
• RCAPercentTImeInMailboxRPC– Identifies how much time all concurrent MAPI RPC/HTTP connections can consume for accessing the mailbox per minute. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, an RCAPercentTimeInMailboxRPC throttling value of 200 results in a throttling threshold of 120 seconds (200/100 * 60 seconds). This means that two connections can consume 60 seconds per minute (120 seconds total per minute) as long as there are no other connections.

What are the Exchange Web Services throttling settings?

The following throttling settings are specific to Exchange Web Services:

• EWSFastSearchTimeoutInSeconds– Identifies how long an Exchange Search (indexed search) request will continue until it times out.
• EWSFindCountLimit– Identifies the maximum number of search results in concurrent requests. For more information, see Throttling Policies and the EWS FindCountLimit. We suggest that searches all be paged and that the page size not exceed 1000 results.
• EWSMaxConcurrency– Identifies the maximum number of concurrent connections that can be maintained by EWS clients at any one time. Attempts to open more than the maximum number of connections will fail. Existing connections will remain unaffected. Active Directory calls count toward the number of concurrent connections. 
• EWSMaxSubscriptions– Identifies the maximum number of push, pull, or streaming notification subscriptions. If a server has too many notification subscriptions, it will start returning server busy errors. The server starts to return errors when the number of open connections reaches approximately 20 for a user. The charges for EWSMaxSubscription are calculated as follows:
  • Client – charged against the caller, also called the mailbox owner.
  • Intra-forest ExchangeImpersonation – charged against the caller.
  • Server-to-Server – charged against the underlying effective caller.
• EWSPercentTimeInAD– Identifies the maximum amount of time that can be spent by a Client Access server when accessing Active Directory resources on behalf of a client account, per minute. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the result by 60 seconds. For example, a EWSPercentTimeInAD throttling value of 50 results in a throttling threshold of 30 seconds (50/100 * 60 seconds).
• EWSPercentTimeInCAS– Identifies how much time all concurrent EWS connections can consume on the Client Access server per minute. This is calculated on a per user basis. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, a EWSPercentTimeInCAS throttling value of 90 results in a throttling threshold of 54 seconds (90/100 * 60 seconds).
• EWSPercentTimeInMailboxRPC– Identifies how much time all concurrent EWS connections can consume while accessing a mailbox via RPC requests, per minute. This is calculated on a per-user basis. This budget is calculated by dividing the throttling value for this setting by 100 and then multiplying the results by 60 seconds. For example, a EWSPercentTimeInMailboxRPC throttling value of 60 results in a throttling threshold of 36 seconds (60/100 * 60 seconds). This means that a single connection can consume 36 seconds per minute as long as there are no other connections. Two connections that started at the same time can only consume 18 seconds each per minute. This is based on a threshold setting of 60.

For more information about EWS throttling policy, see EWS Best Practices: Understanding Throttling Policies.

What are the specific Exchange Web Services limits?

The following are the specific EWS throttling limits:

• maxAllowedContentLength (IIS7) – Identifies the maximum accepted content length of HTTP requests. This maximum length is 35,000,000 bytes, which translates to 25 MB of base64-encoded data.
• maxReceivedMessageSize (WCF) – Identifies the maximum message size that is accepted by EWS. This maximum message size is 35,000,000 bytes, which translates to 25 MB of base64-encoded data.

Note   The values for this limit differ for an on-premise Exchange 2010 deployment. In the initial release version of Exchange 2010, the message size limit is 10 MB. In Exchange 2010 Service Pack 1 (SP1), the message size limit is 35 MB.

• maxRequestLength (ASP.Net)– Not used.

The Exchange Interoperability documentation team is pleased to announce the launch of Exchange Server Interoperability Guidance that supplements the information available in the Microsoft Exchange Server protocol documentation and the Microsoft Exchange Server and Outlook Standards documentation. Whether you’re an Exchange interoperability expert, just getting started, or somewhere in between, we’re confident that this supplemental information will be a valuable resource for you.

In the first article, Exploring the Microsoft Exchange Server Open Specifications, Kim Brandl reviews the types of protocols, structures, algorithms, and standards that the Microsoft Exchange Server Open Specifications define, discusses how to get started using the specifications, explores the kinds of content that you’ll find in the various types of specifications, and addresses some key points to help you derive the maximize benefit from the specifications. Check out Exploring the Microsoft Exchange Server Open Specifications now, and stay tuned for additional technical articles coming soon!

Kim Brandl
Exchange Interoperability
Microsoft Corporation