new managementroleassignment applicationimpersonation

• IT Administration Forum
• PowerShell Forum
• Community Forum
• PowerShell Group
• Earning as 4sysops member
• Member Ranks
• Member Leaderboard – This Month
• Member Leaderboard – This Year
• Member Leaderboard – All-time
• Author Leaderboard – 30 Days
• Author Leaderboard – 365 Days
• Cloud Computing
• Write for 4sysops

Exchange impersonation: Grant permissions to service accounts

4sysops - The online community for SysAdmins and DevOps

Options for granting permissions

Use impersonation roles.

• Recent Posts

• Microsoft Graph: A single (PowerShell) API for Microsoft’s cloud services - Tue, Aug 23 2022
• Exchange impersonation: Grant permissions to service accounts - Mon, Aug 8 2022
• Send Microsoft Teams meeting invitations in multiple languages - Thu, Jul 21 2022

An example of applications that require permissions to Exchange resources is dispatching used to plan the deployment and availability of personnel. The software in question should be able to write directly to the user's calendar for appointment management. Mail archiving solutions also have similar requirements.

Basically, Exchange provides three options to grant users permissions to other users' mailboxes:

• Folder permissions, when you want to grant a user access to a folder, but you don't want that user to be able to "send on behalf of" another user.
• Delegation, when you want a user to perform work on behalf of another user (for example, an executive assistant handling the manager's calendar). This can also be done centrally using PowerShell .
• Impersonation in a service application that needs to access multiple mailboxes and act as the owner of the mailbox.

For our requirement, an impersonation role can be configured centrally on the Exchange Server. This works on both Exchange on-prem and Exchange Online.

For security reasons, the service account will not be authorized to access the entire organization. This would automatically affect critical positions, such as a CxO. Instead, you can use filters to adjust identity roles accordingly.

you can first check to see if there are already any impersonation roles.

Display currently configured impersonation roles

To create a new impersonation role, use the following cmdlet:

Creating a new impersonation role using PowerShell

Now you can further restrict the permissions of the service user with the RecipientTypeDetails parameter, in this example, to rooms:

Restrict service account permissions to room mailboxes

Further filtering would also be possible for all user mailboxes, for example:

The following example shows the restriction of permissions to the members of a group:

More detailed information on the filtering options can be found on Microsoft Docs .

However, if you are planning to migrate to Exchange Online and have created on-prem filters at the organization level (OU) or directly for servers, they will not work in Exchange Online because there are no OUs there.

Basically, the configuration of an impersonation role is now complete. In practice, however, it often happens that different service users need to access calendars. In this case, it is more efficient to give permissions to a group that then contains the service users:

Grant permissions to service users via group membership

All users who are members of the GroupImpersonation group are thus allowed to access the users contained in ManagementScope .

Subscribe to 4sysops newsletter!

IT Administration News

• Windows Server 2025 Insider Build 26280 has a new Sept. 15, 2025 expiration date – Neowin
• Microsoft confirms Windows 11 0xC1900101 update error in recent Canary builds – Neowin
• Elon Musk’s X could still face sanctions for training Grok on Europeans’ data | TechCrunch
• Understanding RAG: How to integrate generative AI LLMs with your business knowledge | ZDNET
• OpenAI co-founder’s Safe Superintelligence startup inhales $1B in funding

Read All IT Administration News

Join our IT community and read articles without ads!

Do you want to write for 4sysops? We are looking for new authors.

Recover data from corrupted BitLocker drives with repair-bde and key packages

How not to block AI crawlers: robots.txt, authentication, CAPTCHA

Determine effective password policy for AD users with PowerShell

Microsoft Purview AI Hub – Monitor and block AI applications

High Volume Email in Microsoft 365: Overcoming sending limits

Send email notifications about expiring Active Directory passwords with a PowerShell script

Unifying endpoint management and security: An overview of ManageEngine Endpoint Central

E-MailRelay: Free SMTP server for Windows

Receive critical Microsoft security alerts by email

Addressing OpenSSH vulnerabilities CVE-2024-6387 and CVE-2024-6409

Authenticator backup: Microsoft, Google, Amazon, Authy

Delegated Managed Service Accounts in Windows Server 2025

List groups in Linux

Install Let’s Encrypt certificates on Windows with Certbot and export as PFX

Create and remove group in Linux, add user, switch primary group

Audit and disable NTLMv1

Enable FIDO passkey authentication for IAM users in AWS

Enable Microsoft Entra ID passkey authentication

KeePassXC: A free cross-platform password manager for Windows, macOS and Linux

Configuring external authentication methods in Microsoft 365 with Microsoft Entra ID

Leave a reply click here to cancel the reply.

Please enclose code in pre tags: <pre></pre>

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Receive new post notifications

Subscribe to Newsletter

Follow 4sysops.

Please ask IT administration questions in the forums . Any other messages are welcome.

Log in with your credentials

or      Create an account

Forgot your details?

Create account.

Configure impersonation roles for Exchange service accounts

• Exchange 2010+
• Admin access to Exchange
• Under 5 minutes

This is a common issue

If you're having trouble connecting to Exchange calendars in Robin or getting "Cannot find calendar" errors, 90% of the time it's because your service account does not have impersonation rights for room calendars yet. This guide walks you through how to fix it fast.

Once you're done, you can test the results quickly using a connectivity tool from Microsoft via this guide.

We need to make sure the connected service account has the ability to create, edit, and delete meetings. Robin will use these permissions to do things like end meetings early via the room display, or remove abandoned events automatically.

Exchange Impersonation allows the service account to manage events on behalf of your office's room resource calendars, regardless of who originally created the event, and gives you auditable logs for reference.

Via Microsoft's Exchange Impersonation vs. Delegate Access:

Exchange Impersonation is used in scenarios in which a single account needs to access many accounts. Line-of-business applications that work with mail typically use Exchange Impersonation.

Wondering why we don't use account delegation instead?

Assign the ApplicationImpersonation role

This applies to Exchange 2010, 2013 and 2016. Exchange 2007 handles Impersonation a little differently. This MSDN article will help you run the equivalents.

Robin recommends limiting the scope of access based on your team's security needs.  Before assigning your service account the  ApplicationImpersonation role, take a moment to update which accounts Robin can impersonate. At a minimum, we recommend including all room resource accounts you plan on managing with Robin.

If you need more specific groups, this article shows how to configure Exchange Impersonation and limit access to custom set of users or account types. 

The easy way: No management scope

The service account will have access to all calendars , regardless of type.

Remember to replace the "User" in the command to match your service account .

The advanced way: Limited management scope

With a limited scope, the service account has access to room and equipment calendars only .

This creates a new management scope for only  rooms/equipment to act as a filter for the impersonation.

Extra limited options

Only interested in allowing access to rooms? Just remove the EquipmentMailbox filter from the above command:

If you need more control, you can create a dedicated Role Group in Exchange that contains the mailboxes you want Robin to manage. Then assign the service account a management scope for mailboxes inside that group. This allows you to hand-select mailbox access one by one.

Extra References

• MSDN - How to Configure Impersonation
• MSDN - Impersonation and EWS in Exchange
• MSDN - New-ManagementScope

• Engineering References
• How-tos and Common Features

Setting up Application Impersonation for Microsoft Exchange

Application Impersonation can be used by the CloudM Migrate to impersonate users so knowledge of their credentials is not required. In order to setup Application Impersonation using PowerShell, the following steps should be carried out.

To apply the Application Impersonation role to your admin account, run the following command in a PowerShell session on your Exchange server. Replace ADMIN with the email address of your admin user.

Enabling Basic Authentication

It often useful to enable Basic authentication for the Exchange Web Services endpoint, as to use Ntlm you must be logged into the workstation running the migration tool as the migration admin user. Run the following to enable Basic authentication, replacing the name of the site if required.

Exchange 2007

• Start the Exchange PowerShell Console
• Run the following commands in the PowerShell session, replacing the admin email with the email address of the user you will use to perform migrations

Application Impersonation Management Role (Office 365) & Complete Guide - alishaaleart/office365 GitHub Wiki

Office 365 provides a role/ right named as application impersonation. This feature allows admin to impersonate another user in an organization to perform any task in his place. When one with a single user account needs to manage multiple user accounts, it becomes essential to have Office 365 application impersonation rights (if you are not an admin).

Impersonation role allows a user, such as an application engineer, to grant certain rights of the admin to a user account. Using this feature, a user can perform any operations that are granted to impersonated account, instead of the permission granted to their own account. This post is a complete guide for the ones who want to explore about this feature. In the further sections, why there is need to impersonate Office 365 user mailboxes and different methods to set and remove impersonation rights in Office 365 and how to grant application impersonation rights in Office 365 are discussed.

Need to Impose Office 365 Application Impersonation Rights

Microsoft Office 365 Impersonation management role is a great feature that allows the admin to represent a user account like an admin and perform any task based on as an authenticated user (but does not provide all the rights of the admin). Below mentioned are the reasons and benefits of impersonating a user’s account:

• Allow a single user account to manage or handle two or more user accounts.
• A user is allowed to export multiple mailboxes from Office 365 simultaneously with the help of impersonation role.
• In a large organization, it becomes really difficult for admin to handle everything individually, in this case there is a need to impose the impersonation role to reduce the workload from a single person.
• It is completely an admin managed feature i.e, other than admin no one can remove/ set impersonation rights in Office 365.
• It is originally designed to access one-to-many mailboxes that decrease the complexity and overhead of managing new users that are to be added to the application scope.

How to Grant Application Impersonation Rights in Office 365

**There are various benefits of application impersonation management role (Office 365) available. Below mentioned are the methods that a user can use to set application impersonation rights in Office 365: **

By using Powershell

By using Exchange Admin Centre

Grant Application Impersonation Rights in Office 365 using Powershell To add application impersonation rights in Office 365 using Powershell, a user need to follow the below mentioned steps:

** First, you need to run the Powershell and check its latest version by typing:** cmdlet:$PSVersionTable

*** If the response is empty that means you are using version 1.0.** *** See the detailed answer for newer versions**

To avoid the issues related compatibility, keep the Powershell updated always

If you wants to handle the roles or permissions locally then, you need to execute the commands in Exchange Management Shell (EMS)

To check the impersonation roles are granted or not, execute the command:

Get-ManagementRoleAssigment-RoleAssignee “”-Role ApplicationImpersonation -Role ApplicationImpersonation- RoleAssigneeType user

here, means name of administrator account that you want to check on the target server

Now, to add mailbox impersonation role, you need to write the following command:

New-ManagementRoleAssignment -Name: -Role:ApplicationImpersonation -User: “”

Here, is the name of user’s choice that must be unique

• Remove Impersonation Rights in Office 365 Using Powershell If a user wants to remove the impersonation roles, a user need to write the following command:

Get-ManagementRoleAssignment -RoleAssignee “” -Role Applicationimpersonation -Role AssigneeType user | Remove- ManagementRoleAssignment

• Set Impersonation Rights In Office 365 Using Exchange Admin Centre (EAC)

To assign application impersonation management role in Office 365, you need to follow the stepwise instruction mentioned below:

• Using Exchange Admin Center or an admin account, log in to your Microsoft Office 365 account
• Now, on Office 365 access the Exchange tab and go to Permissions in the left pane under Dashboard
• After that click on admin roles and then select Discovery management by double-clicking it in the right pane
• In Discovery Management Window, click on + button to set application impersonation
• Now, from the drop down list select “ApplicationImpersonation” and click on add button then, click on OK button
• To verify, check ApplicationImpersonation has been added under the roles or not
• Now, go to Members section and click on + option, a new Window get appears
• Choose the user name and click on add button --> click OK
• To verify, check the Member section for the user name, if user name is in the list click on Save button, otherwise go to step 7

Note: For a small scale business, according to Microsoft Office 365 one can not grant impersonation rights manually. All such permissions are managed by the default admin only.

Conclusion Office 365 application impersonation rights are basically used to represent any user as an admin in his absence. There are various benefits of impersonating rights in office 365 that we have discussed. Now, to solve the problems how to assign application impersonation management role manually, we have discussed two procedures; one is using Powershell and other is by using Exchange Admin Centre. A user can use any of them of the two according to their preference.

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Microsoft Exchange 2016 - ApplicationImpersonation

I want an application (e.g. application123) to write a mail on behalf of all users. For this purpose a user is configured within the application (e.g. myImpersoUser).

I want to realize this via ApplicationImpersonation, unfortunately it does not work yet. If I assign the "send_As" permission manually, it works (so SMTP and authentication on the part of the application seems to be ok).

Current setting:

• AD Security Group (universal) -> App_Mailsender (is a mail-enabled AD group, the same game already tested with a distribution list).

-Management Scope created, which refers to the AD group

-then RoleAsignment performed

Unfortunately I get the message "550 5.7.60 SMTP; Client does not have permissions to send as this sender" .

Where is the error?

Please check if you have configured your application in order to identify the account to impersonate after configuring impersonation for the specific user: Identify the account to impersonate

However, when I tried to get a list of the dynamic distribution group "DDG02", the output didn't show any results:

Based on the test result, it seems that the MemberOfGroup is not valid in the recipient filter.

If your application has identified the account to impersonate, I think you could add a custom attribute to all members which locate in the group, and use the custom attributes to add these members in the recipient filter of your custom management scope, then create a management scope to include these members and run the New-ManagementRoleAssignment cmdlet to add the permission to impersonate the members of the specified scope:

After that, try using the application to write a mail on behalf of all users and see if there is any difference.

• thanks for your post. Why doesn't the "MemberOfGroup" function work if Microsoft intended it to? Or in which constellations does it work? I don't want to go the way you described, because otherwise I would have to build another script, which regularly checks if new mailboxes exist and have / don't have the attribute. I would prefer a central place (AD group etc.), which regulates the function. –  user612985 Commented Jan 19, 2021 at 7:29
• Hi, based on my knowledge and research, the parameters "-RecipientRestrictionFilter"( docs.microsoft.com/en-us/powershell/module/exchange/… ) and "-RecipientFilter"( docs.microsoft.com/en-us/powershell/module/exchange/… ) use the same OPath filter syntax and filterable properties, I just to use another command to preview the members in group and see if I could get the group members. –  Ivan_Wang Commented Jan 19, 2021 at 9:29
• Hello, thank you. But how can I realize this in my way? Without having to resort to the AD attributes (as you described). –  user612985 Commented Jan 19, 2021 at 10:00
• Hi, @user612985, please use the same account that you used to post the question, it's misleading to see two accounts from the same person to interact in the same question. If you need help for your account let me know. –  yagmoth555 ♦ Commented Jan 19, 2021 at 18:54

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged exchange microsoft ..

• The Overflow Blog
• The hidden cost of speed
• The creator of Jenkins discusses CI/CD and balancing business with open source
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• Cardinality of connected LOTS
• How to connect 20 plus external hard drives to a computer?
• Remove an edge from the Hasse diagram of a finite lattice
• Why isn't a confidence level of anything >50% "good enough"?
• Websites assume the wrong country after using a VPN
• Geometry nodes: spline random
• How to raise and lower indices as a physicist would handle it?
• Fusion September 2024: Where are we with respect to "engineering break even"?
• Approximations for a Fibonacci-Like Sequence
• Romeo & Juliet laws and age of consent laws
• Is there a way to prove ownership of church land?
• What would be a good weapon to use with size changing spell
• help to grep a string from a site
• Where is this railroad track as seen in Rocky II during the training montage?
• An instructor is being added to co-teach a course for questionable reasons, against the course author's wishes—what can be done?
• Breaker trips when plugging into wall outlet(receptacle) directly, but not when using extension
• Best approach to make lasagna fill pan
• Is my magic enough to keep a person without skin alive for a month?
• PCA to help select variables?
• No displayport over USBC with lenovo ideapad gaming 3 (15IHU6)
• How high does the ocean tide rise every 90 minutes due to the gravitational pull of the space station?
• Investigate why packages are held back, and stop release upgrade
• Applying to faculty jobs in universities without a research group in your area
• \ExplSyntaxOn problem with new paragraph

Help Center

• BitTitan Help Center
• Perform a Migration
• Migration Planning

MigrationWiz Impersonation and Delegation for Microsoft 365 & Exchange Migrations

When migrating a large number of users in Exchange or Microsoft 365, log-in credentials are required for each user. This is a slow and error-prone process, especially for very large migrations.

Impersonation and delegation offer an easier system for bulk user migrations. Impersonation allows for the use of a single administrative account - created specifically for the migration process - to impersonate and access the user accounts. Delegation is a process where the user grants their authentication credentials to that administrative account.

In short, Impersonation allows for the collection of user information without user input, while delegation collects the data through user input. Both methods allow the migration manager to significantly reduce the time and redundancy necessary to prepare users for migration. 

Please note that Microsoft is planning to phase out RBAC Application Impersonation in Exchange Online . As a result, MigrationWiz Impersonation will also be deprecated . However, you can continue to use this method while it is no longer supported. If you would like more information on our new approach, please review the following KB article to add the necessary API permissions to the Modern Authentication app you are using for your O365 mailbox or archive mailbox endpoint.

Delegation vs. Impersonation

Delegation   means that a mailbox admin user has been set up with delegated full access rights to each user's mailbox. MigrationWiz will then use delegated rights to log in to individual user mailboxes when performing their migration. 

Impersonation   means that the admin account will actually impersonate each mailbox user when performing the migration. This produces a faster migration since the admin account will not be restricted by having to share the throttling quota and connection limits associated with a single administrative account. Instead, the throttling quota of each user is used independently on each user mailbox. You can also disable the throttling quota of each user. This will result in even faster migrations. 

Which process should I use?

If the migration source or destination is Exchange, then we recommend using delegation. This requires fewer steps to configure, and migration speeds are very similar. Setting up delegation is straightforward, as you simply set up the administrator account, disable throttling on the account, and then add the administrator account to the MigrationWiz project.

If the source or destination is Microsoft 365, we recommend using impersonation. The steps to enable impersonation on Microsoft 365 are much more straightforward, you don't have the ability to disable throttling against the admin account on Microsoft 365, so delegation would result in very poor migration speeds.

Using impersonation on Microsoft 365 also provides the following advantages:

• Eliminates most "Connection did not succeed" errors.
• Allows migration of more mailboxes concurrently.
• Reduces the impact of throttling and connection limits.
• Uses an admin account without assigning a license to it.

Setting up Delegation

Any user account that is a part of the domain administrator, schema administrator, or enterprise administrator groups will not have any administrative rights to mailboxes, no matter how many permissions are granted. A security default of Exchange Server is to explicitly deny any user that is a member of these groups. This is why we recommend creating a new user account specific for migration.

• Set up the 'admin' account to be used for migration, and apply the necessary permissions so that the account has full access to each mailbox. 
• Disable throttling against this account, if using Exchange 2010+. This step is not required with Exchange 2003 or Exchange 2007, since those versions do not support throttling.
• Set up the MigrationWiz project, and select   Use admin credentials . Enter the username and password of the account that was set up under Step 1 above.

Set up the administrator account to be used for migration, and then apply the necessary permissions so that the account has full access to each mailbox on the source.

• To create an administrator account (e.g., MigrationWiz), perform the following steps when logged into the Exchange Server.
• Open the Exchange Management Console.
• Expand the  Recipient Configuration  node.
• Right-click on the  Mailbox  node.
• Click on  New Mailbox .
• Click on  Next .
• Enter "MigrationWiz" as the first name.
• Enter "MigrationWiz" as the user logon name, and optionally select a user principal name (UPN) domain.
• Enter a password and confirm the password.
• Click on  Browse  to select a Mailbox database.
• Click on  New .
• Click on  Finish .
• To grant the account access, perform the following from the Exchange Server machine:
• Open the Exchange Management Shell.
• Enter the following command: Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -User MigrationWiz
• The above command needs to be applied each time a new mailbox is created since permissions are set directly on each mailbox. The administrative account will not have access until the permissions are applied.
• In the above script, the username "MigrationWiz" should be replaced with the name of the administrative account that was set up, by following the earlier instructions in this article.
• This username is the Administrative Username that needs to be entered under project source or destination settings, within MigrationWiz, when check marking the box labeled: Use Administrative Login.

Setting up Impersonation

Enable the Application Impersonation role for the admin account. (This step is only required if enabling impersonation on Exchange; it is not required for Microsoft 365.)

Under your MigrationWiz project Advanced Options, select the check box to use impersonation, then complete the following:

• Make sure to use admin credentials at the Destination.
• Sign in to the MigrationWiz account .
• Edit the Project and click on  Advanced Options .
• If migrating from Microsoft 365, under Source, select the check box Use impersonation to authenticate .
• If migrating to Microsoft 365, under Destination, select the check box Use impersonation to authenticate .
• Click  Save Options .

This option is under both Source and Destination. Refer to the section "Which should be used for different migration scenarios?" above to determine if you should be using impersonation at the Source and/or Destination.

If the above Advanced Options are set to use impersonation on a project, these settings will only become effective for those migrations that are started after saving the settings. Migrations that are already running will be unaffected by any such changes.

• If using impersonation against Microsoft 365 (either at Source or Destination), then when mailboxes are submitted we automatically run a PowerShell script to enable the application impersonation role against this account. Therefore, it is unnecessary to run any scripts yourself.
• Following is the remote PowerShell command (on Microsoft 365) that we execute when you submit a mailbox for migration: Enable-OrganizationCustomization New-ManagementRoleAssignment -Role ApplicationImpersonation -User
• If using impersonation against Exchange (either at Source or Destination), an extra step is required since on-premises PowerShell is not available for access over the internet, and thus the impersonation cmdlets cannot be run. Therefore, it is necessary to run this script against the on-premises Exchange environment, using an admin account: New-ManagementRoleAssignment -Role ApplicationImpersonation -User

Disable throttling against all mailboxes, to improve the speed of migration. (This step is only required if using impersonation from/to Exchange 2010+; it is not required for Microsoft 365.)

• On a computer that hosts the Microsoft Exchange Management Shell, open the Microsoft Exchange Management Shell type the following command, then press Enter . New-ThrottlingPolicy MigrationWizPolicy
• Type the following command and press  Enter. Set-ThrottlingPolicy MigrationWizPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null -EWSMaxConcurrency $null -EWSPercentTimeInAD $null -EWSPercentTimeInCAS $null -EWSPercentTimeInMailboxRPC $null -EWSMaxSubscriptions $null -EWSFastSearchTimeoutInSeconds $null -EWSFindCountLimit $null -CPAMaxConcurrency $null -CPAPercentTimeInCAS $null -CPAPercentTimeInMailboxRPC $null -CPUStartPercent $null
• Type the following command and press  Enter Get-Mailbox | Set-Mailbox -ThrottlingPolicy MigrationWizPolicy
• This Microsoft TechNet article presents an alternative cmdlet that can also be used to change the throttling policy association:  Set-ThrottlingPolicyAssociation .
• Set up the MigrationWiz project, and checkmark the box to use admin credentials. Enter the username and password of the account that was set up under Step 1 above.

Scoped Impersonation with EWS

When using MigrationWiz and Exchange Web Services (EWS) to migrate to or from Exchange Online, you should use impersonation (not delegation) when accessing user mailboxes. Using impersonation not only solves some potential throttling issues but more importantly, allows you to scope the impersonation to a specific set of user mailboxes.

The objective is to limit the scope of mailboxes that are migrated using impersonation rights. You accomplish this by implementing an impersonation scope filter. This is a common requirement in migrations where only a subset of an organization's mailboxes are scheduled for migration, for example, in migrations related to mergers and acquisitions.

Setting impersonation scope is a three-step process:

Create a Mail Enabled Security Group

Create a management scope, create the management role assignment.

While you can accomplish this task using either the Microsoft 365 Management Console or PowerShell, the instructions that follow use the PowerShell approach.

To create an impersonation scope filter, you first create a special distribution group that defines the filter scope.

• Connect to Exchange Online using PowerShell.
• Create a new Microsoft 365 mail enabled security Group and name it recognizably.
• Add to the new security Group all of the user mailbox accounts that you intend to migrate. If this group is being used only for scoping impersonation, we recommend hiding the group from the Global Address list.

Retrieve the   DistinguishedName   property of the Group by using the   Get-DistributionGroup   command:

Get-DistributionGroup -Identity "YourGroupName" |fl name, dist*

This PowerShell command returns the group name (name) and   DistinguishedName   (in this instance using the wild card format,   dist* ), which enables creating the management scope. Where you see " YourGroupName ", insert the name you have assigned to your distribution group.

Using the   DistinguishedName   property retrieved in the previous step, along with the   RecipientRestrictionFilter   and   MemberOfGroup   filtering parameters, create a management scope by running the following PowerShell command:

To run the following command, you may need to enable the   Organization   customization on your Microsoft 365 tenant.

New-ManagementScope "YourScopeName" -RecipientRestrictionFilter {MemberOfGroup -eq 'YourGroupDistinguisedName'}

Where you see " YourScopeName ", provide the name you've assigned to your management scope; and, where you see " YourGroupDistinguisedName ", provide the group's   DistinguisedName   value, for example:

CN=AllowImpersonationDistributionGroup,OU=tenantname.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURP193A002,DC=PROD,DC=OUTLOOK,DC=COM

The final step is to create a management role assignment and then associate it with the migration account that has administrative privileges.

Create the management role assignment by issuing the following PowerShell command:

New-ManagementRoleAssignment -Name "YourMigrationProject" -Role "ApplicationImpersonation" -User "YourAdminAccountName" -CustomRecipientWriteScope "YourManagementScope"

Where the following values are provided or returned:

• Name   is the name of your migration project YourMigrationProject
• Role   is the value   ApplicationImpersonation.
• User   is the migration account that has administrative privileges. YourAdminAccountName
• CustomRecipientWriteScope   is the name you assigned to the management scope you created YourManagementScope

Delegation in Microsoft 365

Having administrative access to the Microsoft 365 control panel to manage users does not necessarily mean that the same account has permission to access all mailboxes for migration. In order to have administrative permissions to migrate mailbox data, it is necessary to grant the account permissions on each mailbox.

To manually grant administrative access for migration, execute the following remote PowerShell command:

$LiveCred = Get-Credential

Install-Module -Name ExchangeOnlineManagement Import-Module -Name ExchangeOnlineManagement Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred

Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -Automapping $false -User MigrationWiz

The above command needs to be applied each time a new mailbox is created, as permissions are set directly on the mailbox. The administrative account will not have access until the permissions are applied.​

The global admin account does have the necessary rights for delegation. However, again, we recommend using impersonation for migrations​ from and/or to Microsoft 365.

If connecting to GCC High with powershell, use Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -ExchangeEnvironmentName O365USGovGCCHigh

Articles in this section

• Adding & Managing Items for Migration
• Azure for MigrationWiz
• Azure Identity considerations
• Azure Storage for MigrationWiz
• Configuring Rackspace as a migration endpoint
• Document Migrations
• Getting Started with MigrationWiz
• Migration Planning & Strategy Guide
• Migration Strategies - Types & Best Practices
• MigrationWiz Endpoints

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Hosted Exchange Impersonation ManagementRole

I tried to create an New-ManagementRoleAssignment

Next i tried to set/change RecipientOrganizationalUnitScope Organisation

But Impersonation doesn`t work for Administrator@domain and an User from Organization with EWS...

Allways get SoapException was unhandled "The impersonation principal name is invalid."

• exchange-server
• impersonation

Has the administrator full access to all the users in the organization? Have you checked that the administator may impersonate?

• Thx ;) I found the problem, the exchange was installed in hosted mode. so impersonation only works in the appropriate organisational unit. –  electronico Commented Sep 5, 2012 at 15:53

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged email exchange-server contacts impersonation or ask your own question .

• The Overflow Blog
• The hidden cost of speed
• The creator of Jenkins discusses CI/CD and balancing business with open source
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites
• What does a new user need in a homepage experience on Stack Overflow?
• Feedback requested: How do you use tag hover descriptions for curating and do...
• Staging Ground Reviewer Motivation

Hot Network Questions

• How to raise and lower indices as a physicist would handle it?
• Nausea during high altitude cycling climbs
• "Mixture, Pitch then Power" - why?
• How does the phrase "a longe" meaning "from far away" make sense syntactically? Shouldn't it be "a longo"?
• In which town of Europe (Germany ?) were this 2 photos taken during WWII?
• Approximations for a Fibonacci-Like Sequence
• No displayport over USBC with lenovo ideapad gaming 3 (15IHU6)
• Wien's displacement law
• Is the 2024 Ukrainian invasion of the Kursk region the first time since WW2 Russia was invaded?
• Could a lawyer agree not to take any further cases against a company?
• Websites assume the wrong country after using a VPN
• What's the purpose of scanning the area before opening the portal?
• Enumitem + color labels + multiline = bug?
• Show that an operator is not compact.
• Are others allowed to use my copyrighted figures in theses, without asking?
• What`s this? (Found among circulating tumor cells)
• how do I fix apt-file? - not working and added extra repos
• What was the typical amount of disk storage for a mainframe installation in the 1980s?
• Does a party have to wait 1d4 hours to start a Short Rest if no healing is available and an ally is only stabilized?
• Is it helpful to use a thicker gauge wire for only part of a long circuit run that could have higher loads?
• Does the average income in the US drop by $9,500 if you exclude the ten richest Americans?
• Simulate Minecraft Redstone | Where to start?
• Is my magic enough to keep a person without skin alive for a month?
• What is the first work of fiction to feature a vampire-human hybrid or dhampir vampire hunter as a protagonist?

• Knowledge Base

For Admins: How do I configure the Impersonation Role for Exchange Calendar Sync?

The following information was sourced from Microsoft's how-to guide here:

Microsoft - How to: Configure impersonation

Impersonation enables a caller, such as a service application, to impersonate a user account. The caller can perform operations by using the permissions that are associated with the impersonated account instead of the permissions associated with the caller’s account.

Exchange Online, Exchange Online as part of Office 365, and versions of Exchange starting with Exchange 2013 use role-based access control (RBAC) to assign permissions to accounts. Your Exchange server administrator will need to grant any service account that will be impersonating other users the ApplicationImpersonation role by using the New-ManagementRoleAssignment cmdlet.

Configuring the Application Impersonation role

When you or your Exchanger server administrator assigns the ApplicationImpersonation role, use the following parameters of the New-ManagementRoleAssignment cmdlet:

• Name — The friendly name of the role assignment. Each time that you assign a role, an entry is made in the RBAC roles list. You can verify role assignments by using the Get-ManagementRoleAssignment cmdlet.
• Role — The RBAC role to assign. When you set up impersonation, you assign the ApplicationImpersonation role.
• User — The service account.
• CustomRecipientScope — The scope of users that the service account can impersonate. The service account will only be allowed to impersonate other users within the specified scope. If no scope is specified, the service account is granted the ApplicationImpersonation role over all users in an organization. You can create custom management scopes by using the New-ManagementScope cmdlet.

Before you can configure impersonation, you need:

• Administrative credentials for the Exchange server.
• Domain Administrator credentials, or other credentials with the permission to create and assign roles and scopes.
• Exchange management tools. These are installed on the computer from which you will run the commands.

To configure impersonation for all users in an organization:

• Open the Exchange Management Shell. From the Start menu, choose All Programs > Microsoft Exchange Server 2013.

Run the New-ManagementRoleAssignment cmdlet to add the impersonation permission to the specified user. The following example shows how to configure impersonation to enable a service account to impersonate all other users in an organization.

Windows PowerShell

New-ManagementRoleAssignment –name:impersonationAssignmentName –Role:ApplicationImpersonation –User:serviceAccount 

To configure impersonation for specific users or groups of users:

• Run the New-ManagementScope cmdlet to create a scope to which the impersonation role can be assigned. If an existing scope is available, you can skip this step. The following example shows how to create a management scope for a specific group.

Windows PowerShell   New-ManagementScope –Name:scopeName –RecipientRestrictionFilter:recipientFilter

The RecipientRestrictionFilter parameter of the New-ManagementScope cmdlet defines the members of the scope. You can use the properties of the Identity object to create the filter. The following example is a filter that restricts the result to a single user with the user name "john."

Windows PowerShell   Name –eq "john"

Run the New-ManagementRoleAssignment cmdlet to add the permission to impersonate the members of the specified scope. The following example shows how to configure a service account to impersonate all users in a scope.

Windows PowerShell   New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:serviceAccount –CustomRecipientWriteScope:scopeName

After your administrator grants impersonation permissions, you can use the service account to make calls against other users’ accounts. You can verify role assignments by using the Get-ManagementRoleAssignment cmdlet.

Related Articles

For Admins: How do I upgrade my org to the new Cirrus Insight?

The new Cirrus Insight brings all the best features from Cirrus Insight 2019 into a more refined, reliable, and easy-to-use offering that reduces CRM friction and helps close deals.

January 2021 Release Notes

In order to maintain performance and stability while also reducing customer resource drain, the default sync interval will be increased from 5 minutes to 2 hours as of 4/21/2021.

For Admins: Why are users missing from the Admin-Managed Sync list?

What sales tax will I be charged?

Based on your address, you may be charged local/state sales tax on Cirrus Insight purchases.

For Admins: How do I access payment history to download receipts?

Learn how to access payment history and download receipts.

• Account Management
• Add to Salesforce
• Book Meeting
• Calendar Sync
• Specifications

• Knowledgebase
• Pinned  

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Get-Management Role Assignment

This cmdlet is available in on-premises Exchange and in the cloud-based service. Some parameters and settings may be exclusive to one environment or the other.

Use the Get-ManagementRoleAssignment cmdlet to retrieve management role assignments.

For information about the parameter sets in the Syntax section below, see Exchange cmdlet syntax .

Description

You can retrieve role assignments in a variety of ways including by assignment type, scope type, or name, and whether the assignment is enabled or disabled. You can also view a list of role assignments that provide access to a specified recipient, server, or database.

For more information about management role assignments, see Understanding management role assignments .

You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet .

This example retrieves the Denver Help Desk role assignment using the Get-ManagementRoleAssignment cmdlet and pipes the output to the Format-List cmdlet. For more information about the Format-List cmdlet, see Working with command output .

This example retrieves all the role assignments that are enabled and have been designated as delegating role assignments.

This example retrieves all the role assignments that include the MyGAL recipient-based scope restriction type.

This example retrieves all the role assignments associated with the Mail Recipients management role.

This example retrieves a list of all the users and the role assignments that can modify the recipient Bob.

This example retrieves a list of all exclusive scopes that can modify server objects that match Redmond Executive Servers. The command also lists the users who are effectively assigned the role assignments through role groups or USGs.

This example retrieves all the role assignments that can modify the database Contoso Sales.

-AssignmentMethod

The AssignmentMethod parameter specifies the type of role assignment to include in the results returned by the cmdlet. You can specify one or more of the following values:

• SecurityGroup
• RoleAssignmentPolicy

If you provide more than one value, separate each value with a comma.

You must specify a value with the RoleAssignee parameter if you use the AssignmentMethod parameter.

-ConfigWriteScope

The ConfigWriteScope parameter specifies the type of management configuration scope to include in the results returned by the cmdlet. The valid values are None, OrganizationConfig, CustomConfigScope, and ExclusiveConfigScope.

-CustomConfigWriteScope

This parameter is available only in on-premises Exchange.

The CustomConfigWriteScope parameter returns only the regular role assignments that include the specified configuration-based regular scope.

This parameter can only be used to retrieve regular configuration-based scopes. To retrieve a list of exclusive configuration-based scopes, use the ExclusiveConfigWriteScope parameter instead.

If the scope name contains spaces, enclose it in quotation marks (").

-CustomRecipientWriteScope

The CustomRecipientWriteScope parameter returns only the regular role assignments that include the specified recipient-based regular scope.

This parameter can only be used to retrieve regular recipient-based scopes. To retrieve a list of exclusive recipient-based scopes, use the ExclusiveRecipientWriteScope parameter instead.

-Delegating

The Delegating parameter specifies whether delegating or regular role assignments should be returned.

By default, both delegating and regular scopes are returned. To return only delegating role assignments, specify a value of $true. To return only regular role assignments, specify a value of $false.

-DomainController

The DomainController parameter specifies the domain controller that's used by this cmdlet to read data from or write data to Active Directory. You identify the domain controller by its fully qualified domain name (FQDN). For example, dc01.contoso.com.

The Enabled parameter specifies whether enabled or disabled role assignments should be returned. To return enabled role assignments, specify a value of $true. To return disabled role assignments, specify a value of $false.

The Exclusive parameter specifies whether exclusive or regular role assignments should be returned.

By default, both exclusive and regular scopes are returned. To return only exclusive role assignments, specify a value of $true. To return only regular role assignments, specify a value of $false.

-ExclusiveConfigWriteScope

The ExclusiveConfigWriteScope parameter returns only the exclusive role assignments that include the specified configuration-based exclusive scope.

This parameter can only be used to retrieve exclusive configuration-based scopes. To retrieve a list of regular configuration-based scopes, use the CustomConfigWriteScope parameter instead.

-ExclusiveRecipientWriteScope

The ExclusiveRecipientWriteScope parameter returns only the exclusive role assignments that include the specified recipient-based exclusive scope.

This parameter can only be used to retrieve exclusive recipient-based scopes. To retrieve a list of regular recipient-based scopes, use the CustomRecipientWriteScope parameter instead.

-GetEffectiveUsers

The GetEffectiveUsers switch specifies that the command should show the list of users in the role groups, role assignment policies, or USGs that are associated with the role assignment. You don't need to specify a value with this switch.

Effectively, users are associated with the role assignment through their role group, role assignment policy, or USG memberships.

The Identity parameter specifies the name of the role assignment to retrieve. If the name of the role assignment contains spaces, enclose it in quotation marks ("). If the RoleAssignee parameter is used, you can't use the Identity parameter.

-RecipientAdministrativeUnitScope

This parameter is functional only in the cloud-based service.

The RecipientAdministrativeUnitScope parameter returns only the role assignments that include the specified administrative unit.

Administrative units are Microsoft Entra containers of resources. You can view the available administrative units by using the Get-AdministrativeUnit cmdlet.

-RecipientGroupScope

This parameter is available only in the cloud-based service.

The RecipientGroupScope parameter returns only the role assignments that are scoped to groups. You can use any value that uniquely identifies the group: Name, DistinguishedName, GUID, DisplayName.

-RecipientOrganizationalUnitScope

The RecipientOrganizationalUnitScope parameter returns only the role assignments that include the specified organizational unit (OU). If the OU tree contains spaces, enclose it in quotation marks (").

-RecipientWriteScope

The RecipientWriteScope parameter returns only the role assignments associated with the recipient scope restriction type specified. The valid values are None, MyGAL, Self, OU, CustomRecipientScope, MyDistributionGroups and ExclusiveRecipientScope.

The Role parameter returns only the role assignments associated with the specified management role. If the name of the role contains spaces, enclose it in quotation marks (").

-RoleAssignee

The RoleAssignee parameter specifies the role group, assignment policy, user, or universal security group (USG) for which you want to view role assignments. If the RoleAssignee parameter is used, you can't use the Identity parameter.

By default, the command returns both direct role assignments to the role assignee and indirect role assignments granted to a role assignee through role groups or assignment policies.

If the name of the user or USG contains spaces, enclose it in quotation marks (").

-RoleAssigneeType

The RoleAssigneeType parameter specifies the type of role assignee to return. The valid values are User, SecurityGroup, RoleAssignmentPolicy, ForeignSecurityPrincipal, RoleGroup, LinkedRoleGroup and Computer.

-WritableDatabase

The WritableDatabase parameter specifies the database object you want to test to determine which role assignments allow it to be modified. The command takes into account the roles and scopes associated with each role assignment. You can use any value that uniquely identifies the database. For example:

• Distinguished name (DN)

If you use this parameter with the GetEffectiveUsers switch, all the users who can modify the database object indirectly through role groups and USGs are also returned. Without the GetEffectiveUsers switch, only the role groups, users and USGs directly assigned the role assignment are returned.

-WritableRecipient

The WritableRecipient parameter specifies the recipient object you want to test to determine which role assignments allow it to be modified. The command takes into account the roles and scopes associated with each role assignment. If the recipient name contains spaces, enclose it in quotation marks (").

If this parameter is used with the GetEffectiveUsers switch, all of the users who can modify the recipient object indirectly through role groups and USGs are also returned. Without the GetEffectiveUsers switch, only the role groups, users and USGs directly assigned the role assignment are returned.

-WritableServer

The WritableServer parameter specifies the server object you want to test to determine which role assignments allow it to be modified. The command takes into account the roles and scopes associated with each role assignment.

You can use any value that uniquely identifies the server. For example:

• Exchange Legacy DN

If this parameter is used with the GetEffectiveUsers switch, all of the users who can modify the server object indirectly through role groups and USGs are also returned. Without the GetEffectiveUsers switch, only the role groups, users and USGs directly assigned the role assignment are returned.

Input types

To see the input types that this cmdlet accepts, see Cmdlet Input and Output Types . If the Input Type field for a cmdlet is blank, the cmdlet doesn't accept input data.

Output types

To see the return types, which are also known as output types, that this cmdlet accepts, see Cmdlet Input and Output Types . If the Output Type field is blank, the cmdlet doesn't return data.

Was this page helpful?

Additional resources