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.
Office365: First Impressions
After months of trying to get into playing with Office365, I finally got access to the BETA this week to start playing around with it. (Really my access game through because it went Public Beta, but that's ok). My first impression is that Office365 is very slick, very well put together and real simple to use. When I received my email I immediately dove in and setup some users for email, created some documents and most importantly started playing around with Lync. I didn't really focus much on the Office part as I have already played around with this with SkyDrive and it seemed pretty similar.
By far - this has been the simplest Lync setup I have ever done in my life. On the first day I had some issues, which I don't know if they were a result of me missing a step, but this weekend I went in and tried again. After configuring the user for Lync, downloading the client install, I was pretty much done, I logged into my client and was ready to take IM/phone calls. In some cases I had to download the Microsoft Online Assistant to enable logins to Lync to work (which, on the main Lync Client SDK install, when it can't log you in the first time it prompts you for the install and then you're good to go). I have easily setup 4 users in a matter of minutes with little to no battles with certificates and DNS. The only thing I am trying to figure out now is if I can federate with other users and include them in my profile list and if that even can be done.
From a developer's standpoint, there is a ton of information out there on the topic of Sharepoint, Exchange and Lync. In Exchange, you get the Exchange Managed Service API (which wraps Exchange Web Services) and with Lync you get access to the Lync Client SDK (no UCMA or server-side code available yet), but I'm sure if you wrote a little UCMA app to sit on your server you might be able to have it talk to those SIP URIs. That's all conjecture at this point as really all I have been doing is play around with the interface to see what I can and can't do.
So for the above reasons, I did not get the blog updated this weekend. Lesson for me - don't announce a public change to your site when you get access to a brand-new Beta!