Setting up Impersonation for the Exchange Web Services API in Exchange 2010
What is often seen as the most difficult pieces to get setup in using the Exchange Web Services SDK (or it's companion, the Managed API) is not so.
Impersonation is the means by which the account you are connecting to Exchange with to act as somebody else. What is beautitful about Impersonation is that this user does not even need to be an Exchange User or have their own mailbox. Nope they can be just a regular joe in Active Directory.
Setting up Impersonation can be done in two ways, both involve using Powershell. On a side-note - connecting to Powershell via a local account can create some very wierd experiences in access cmdlets, always log into Powershell as an authorized domain user.
Wide-Open
New-ManagementRoleAssignment -Name:MyImpersonationGroup -Role:ApplicationImpersonation -User:mydomain\exservice
The above code, creates a new ManagementRoleAssignment, aptly named "MyImpersonationGroup" which I add to the ApplicationImpersonation role and then grant rights to the mydomain\exservice user. At this point, I have enabled Impersonation, "mydomain\exservice" now has full-blown rights to go around and impersonate users. Now let's move on to limiting the user scope.
Limited Impersonation
Chances are you are not going to want to do what I did in the Wide-Open scenario but would rather control who our "Impersonator" can Impersonate. This is accomplished by creating a scope and assignming that scope to the Management Role Assignment cmdlet.
New-ManagementScope –Name:MyExchangeScope -RecipientRestrictionFilter {Title –Like “Developer”}
New-ManagementRoleAssignment -Name:impersonationAssignmentName -Role:ApplicationImpersonation -User:mydomain\exservice –CustomRecipientWriteScope:MyExchangeScope
So, the tricky thing about creating a Management Scope is determining the restriction filter. I don't have a complete list of all the names of Active Directory fields, but in this example what I have done is create a scope whereby anyone with the Title of Developer will be allowed to be impersonated. Next, when I create my Management Role Assignment I now append the additional flag "-CustomRecipientWriteScope" and drop in the name that I gave my ManagementScope in the first step.
Now I will caution you, not being an Active Directory expert, that I did notice a delay from when I published changes to users (i.e., changed their titles to "Developer") to when I could impersonate them in my code. I would think this is based on AD publishing its data on some kind of pre-defined schedule? I know OCS/Lync has this issue with Address book changes coming down to it if you have AD groups in your Lync contact list.
So that's it that's all, now that you have impersonation all setup and running, go forth and crank out that EWS Code.