EWS impersonation not working when accessing resource mailboxes in a different site in Exchange Server 2010 SP3

Consider the following scenario:

• You deploy Exchange Server 2010 Service Pack 3 (SP3) in two Active Directory sites (Site A and Site B). Both sites have different internal URLs for Exchange Web Services (EWS).
• You install Update Rollup 19, Update Rollup 20, or Update Rollup 21 for Exchange Server 2010 SP3 on both sites.
• You create a room mailbox, and then you set up a service account that has impersonation configured in Site A.
• In EWS Editor, you set the Service URL to the FQDN EWS URL for Site B's Client Access server (CAS), and then you set the credential of the service account by selecting the Use the following credentials instead of the default Windows credentials check box. Then, you select the Check if using EWS Impersonation check box, select SmtpAddress in Id Type, input the SMTP address of the room mailbox, and then click OK.
• After you connect to the room mailbox that uses impersonation, you try to expand the folders.

In this scenario, you cannot expand the folders. Additionally, you receive an "http 500 internal error" error message.

To work around this issue, do one of the following:

• Connect to the same site as the resource rooms for EWS calls to avoid the proxy calling to a different CAS. 
• Enable the resource room's Active Directory account. For more information, see Enable AD-Account.

Microsoft has confirmed that this is a problem in Update Rollup 19, Update Rollup 20, and Update Rollup 21 for Exchange Server 2010 SP3.

For more information about EWS Editor impersonation, see Testing Impersonation Permission with EWS Editor.

Learn about the terminology that Microsoft uses to describe software updates.