Exchange 2007 and 2010 differ in how to configure Impersonation to allow users to send as other users via EWS.
This link is the 2007 way:
This link is the 2010 way:
The user to give impersonation rights to is the user id the application or service is being run with, not the primary mailbox used to connect to the Exchange service.
Microsoft SQL server has built-in security which prevents the dynamic loading of serialized assemblies. What this basically means is that an assembly which utilises Webservices and XML.Serialization will dynamically load the code and compile at runtime and SQL Server doesn't like that. This is the error you will receive when running functions or procedures in such an assembly.
If you try and load the Microsoft Exchange Web Services dll (Microsoft.Exchange.WebServices.dll) as an assembly in Microsoft SQL Server, you will receive errors relating to dependent assemblies not being loaded in the SQL catalog.
The MSDN article for CREATE ASSEMBLY states
Besides the root assembly specified by assembly_name, SQL Server tries to upload any assemblies that are referenced by the root assembly being uploaded. If a referenced assembly is already uploaded to the database because of an earlier CREATE ASSEMBLY statement, this assembly is not uploaded but is available to the root assembly. If a dependent assembly was not previously uploaded, but SQL Server cannot locate its manifest file in the source directory, CREATE ASSEMBLY returns an error.
BUT this isn't always the case. The first rule is