To configure impersonation in Exchange Online, you need to be able to run a Windows PowerShell script against your Exchange Online environment. You also need to have permission to run the New-ManagementRoleAssignment cmdlet; Note that tenancy administrators are granted this permission by default. When working with an on-premises Microsoft Exchange Server deployment, you can use the Exchange Management Shell to run Windows PowerShell scripts against the Microsoft Exchange deployment. However, to run Windows PowerShell scripts against Exchange Online, you first need to establish a remote Windows PowerShell session to the Exchange Online environment.

To establish a remote Windows PowerShell session to Exchange Online, use the New-PSSession Windows PowerShell cmdlet to connect to the generic remote Windows PowerShell endpoint at http://ps.outlook.com/powershell. After authenticating with the Windows PowerShell endpoint, the server uses the supplied credentials to determine which Windows PowerShell endpoint to redirect the connection to. Be sure to set the AllowRedirection parameter to allow the generic Windows PowerShell endpoint to redirect you to the appropriate endpoint for your Exchange Online tenancy. The following code example shows the script to use to establish a remote Windows PowerShell connection to Exchange Online.

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

As you can see in the following figure, after authenticating, the Windows PowerShell connection is redirected multiple times until it connects to the appropriate remote Windows PowerShell endpoint for the authenticated user’s Exchange Online tenancy.

To configure a service account to be able to impersonate a set of users, you need to grant the service account the ApplicationImpersonation role for an organizational unit (OU), a security group, or a set of users that is defined by a Microsoft Exchange management scope role filter. This enables the service account to impersonate the specified user accounts and perform mailbox operations by using their rights.

The following example uses the New-ManagementRoleAssignment Exchange Management Shell cmdlet to grant the service account permission to impersonate all the users in the organization. The Name parameter specifies the name of the new role assignment. The Role parameter indicates that the ApplicationImpersonation role is assigned to the user specified by the User parameter.

New-ManagementRoleAssignment –Name "Impersonation-MyApp" –Role "ApplicationImpersonation" –User serviceaccount@contoso.com

You can also use the New-ManagementRoleAssignment cmdlet to grant the ApplicationImpersonation role to a security group that contains a set of service accounts, as in the following example.

New-ManagementRoleAssignment –Name "Impersonation-MyApp-Group" –Role "ApplicationImpersonation" –SecurityGroup "Service Accounts"

In addition, you can use a management scope filter to grant the ApplicationImpersonation role to a service account — or to a security group that contains a set of service accounts — so that the service account can impersonate the collection of user accounts specified by the filter.

The following example creates a management scope filter called Sales Users that includes all the users in the Sales department, and it grants the ApplicationImpersonation role to serviceaccount@contoso.com over the users that are defined by the scope.

New-ManagementScope -Name "Sales Users" -RecipientRestrictionFilter { Department -Eq "Sales" }

New-ManagementRoleAssignment –Name "Impersonation-MyApp-Scope" –Role "ApplicationImpersonation" –User serviceaccount@contoso.com -CustomRecipientWriteScope "Sales Users"

Note:
For more information about how to create a Microsoft Exchange management scope filter, see Understanding Management Role Scope Filters on Microsoft TechNet.

After connecting to EWS by using the credentials of the service account that has been granted the ApplicationImpersonation role, you can impersonate an account by setting the ImpersonatedUserId property of the ExchangeService class to an instance of the ImpersonatedUserId class that represents the account you want to impersonate.

In the following example, the ExchangeService instance is set to impersonate the user karenb@contoso.com. Any subsequent mailbox operations are performed using the rights associated with the impersonated account.

// Create an instance of ExchangeService for a specific version of Microsoft Exchange. 
_exchangeService = new ExchangeService(ExchangeVersion.Exchange2010_SP1);
            
// Set the credentials to the user who is to connect to Exchange Online.
_exchangeService.Credentials = new NetworkCredential() 
    { 
        UserName = _serviceAccountName, 
        Password = _serviceAccountPassword
    };

// Set the SMTP address of the impersonated account.
string _impersonatedUserSMTPAddress = "karenb@contoso.com";

// Call Autodiscover to return the URL of the most efficient Client Access server for the given email address.
_exchangeService.AutodiscoverUrl(_impersonatedUserSMTPAddress, UrlValidationCallback);   

// Set the impersonated account.
_exchangeService.ImpersonatedUserId =
    new ImpersonatedUserId(
        ConnectingIdType.SmtpAddress,
        _impersonatedUserSMTPAddress);

// Create an appointment.
var appointment = new Appointment(_exchangeService);
appointment.Subject = "Appointment with Adventure Works";
appointment.Start = DateTime.Now;
appointment.End = appointment.Start.AddHours(1);
appointment.RequiredAttendees.Add("amya@contoso.com");

try
{
    appointment.Save(SendInvitationsMode.SendToAllAndSaveCopy);
}
catch (Microsoft.Exchange.WebServices.Data.ServiceResponseException ex)
{
    throw ex;               
}
 
// Clear impersonation.
_exchangeService.ImpersonatedUserId = null;

Because the appointment with Adventure Works was created by using impersonation, the invitation that Amy Alberts receives will come from Karen Berg.

When you try to perform the mailbox operation —such as creating an appointment, as shown in the previous example —a Microsoft.Exchange.WebServices.Data.ServiceResponseException exception is raised if the service account doesn’t have permission to impersonate the specified account. The exception error message is the following: "The account does not have permission to impersonate the requested user."

Note:
If you don’t set the ImpersonatedUserId property of the ExchangeService instance back to null, all subsequent operations will be performed by using the impersonated account’s rights. You should always set ImpersonatedUserId property back to null after you complete operations that require impersonation.