Microsoft Exchange 2010 GRT restore of individual emails fails with error 0xe0000389 - Unable to create a role assignment for ApplicationImpersonation

  • Article ID:100006153
  • Modified Date:
  • Product(s):


Restore from Microsoft Exchange 2010 GRT AVVI backup set or RAWS based backup set for individual email fails with error “unable to create a role assignment for ApplicationImpersonation”

Error Message

Final error: 0xe0000389 - The resource credentials for the restore job were unable to create a role assignment for ApplicationImpersonation. Review the credentials to ensure that it has the rights that are required for ApplicationImpersonation.
Final error category: Resource Errors

For additional information regarding this error refer to link V-79-57344-905


SGMON log from media server shows the following errors:

BEREMOTE: [0000]     [10036] [fsys\mb2]           - Checking Permissions for EWS
BEREMOTE: [0000]     [10036] [fsys\shared]        - EnsureEwsPermissions returned 80131501
BEREMOTE: [0000]     [10036] [fsys\mb2]           - FATAL: failed to aquire EWS ApplicationImpersonation rights
BEREMOTE: [0000]     [10036] [ndmp\loops]         - Error: CreateObj returns extended error e0000389


This issue could occur due to following multiple reasons:

Cause A. If the Backup Exec Service Account/Logon Account is having insufficient rights or does not have an active mailbox associated with it or it is hidden from Global Address list.

Cause B. The role assignment for ApplicationImpersonation is not set on the Backup Exec account. This role should automatically be created when the first restore job is preformed. See the steps below to confirm if the role has been set, and how to configure EWS impersonation if needed.

Cause C. Exchange Web Service (EWS) is not functioning properly.

Cause D. If there are different exchange servers (i.e.: Exchange 2003 and Exchange 2010) in the environment and the migration has not been executed and the Backup Exec Service Account/Logon Account is having active mailbox on the Exchange 2003 server and not in Exchange 2010.

Cause E. If there are some issues with proxy setting on Exchange 2010 CAS server and if Local Bypass (the tick box) in Internet Explorer is not enabled.

Cause F. If the Backup Exec Service Account/Logon Account is Domain\User Name.


Following Solutions should be attempted:

Solution A:
1. Use a logon account in Backup Exec or create a new account that is a Unique account in Active Directory with an activated mailbox on the Exchange server. A unique name is one that does not exist in the organization as a subset of characters in another mailbox name.
2. Ensure that the Backup Exec logon account is added to  Administrators, Domain Admin, and Exchange Organization Admin group on both Media server and Exchange server (s).
3. The Backup Exec logon account should be assigned the Exchange Full Administrators\ Organization Management role in Exchange System Manager\ Exchange Management Console -> Tools/Role Based Access Control. Under Organizational Management, make sure the user account is found in the list of users.
4. Verify that the mailbox for Backup Exec logon account is not hidden in the Global Address list.
6. Make sure the Backup Exec Service Account (BESA) and the System Logon account are same.
7. Give the new user the relevant rights and also activate the mailbox by sending and receiving mail.
8. Restart all Backup Exec services on the media server and the remote server.
9. Re-run the restore job


Solution B:

1.How to check if an account has the proper Role assignment

Run the following command from Exchange Management PowerShell to see if the role has been set:
Get-ManagementRoleAssignment -Role "SymantecEWSImpersonationRole"

This should return information on this role including the "RoleAssineeName" which should list Backup Exec account (See Figure 1). If the role has not been set for the Backup Exec account, EWS impersonation can be configured with the following sample PowerShell commands

Figure 1

This command will create a new role called SymantecEWSImpersonationRole:
New-ManagementRole -Name SymantecEWSImpersonationRole -Parent ApplicationImpersonation

After running this command, a new SymantecEWSImpersonationRoleAssignment will be assigned to user Administrator:
New-ManagementRoleAssignment -Role SymantecEWSImpersonationRole -User Administrator SymantecEWSImpersonationRoleAssignment

The new SymantecEWSImpersonationRoleAssignment has been associated with the user Administrator. After configuring this Role, re-run the restore job.




Confirm that EWS is functioning properly:

If the restore job still fails after confirming the steps above, run the following command to verify that EWS is functioning properly. Logon to the Exchange 2010 that holds the Client Access server (CAS) role using the same account that is used in Backup Exec, and run the following command from a PowerShell prompt:
 test-webservicesconnectivity -MailboxCredential $(get-credential) -TrustAnySSLCertificate  | FL

To see the output in a text file run the following command 

Test-webservicesconnectivity -MailboxCredential $(get-credential) -TrustAnySSLCertificate | FL >C:\EWStest.txt

A PowerShell Credentials window will appear if the command is entered properly. Please enter the credentials for the Backup Exec service account. Review the output for any failures. Microsoft will need to be contacted to help resolve issues with EWS. 

If above command fails with the error The Client Access server wasn't specified. You can use the UseAutodisoverForClientAcces|sServer parameter to use the Aut

odiscover service to locate the Client Access server, run the following command 

test-WebServicesConnectivity -ClientAccessServer servername -MailboxCredential $(get-credential) -TrustAnySSLCertificate | FL


(servername is the name of CAS server)



Solution D:
1. Migrate the Backup Exec Logon Account\BESA to Exchange 2010 server.
2. Re-run the restore job.



Solution E:

1. Reset proxy on Exchange 2010 CAS server(s) and Media server using following command:


2. Now attempt the restore job again.

3. If the job still fails then follow the steps below:

a. On Exchange 2010 CAS server(s) go to Tools - Internet Options - Connections - LAN settings window.
b. Enable the "Use a Proxy server for LAN and add the IP address and Port.
c. Click "Advanced" Tab on same window and set the Proxy address and Port in HTTP box.
d. Under "Exceptions" add the *.domain name and click OK on "Proxy Settings" window.
e. Enable "Bypass proxy server for local addresses" under LAN settings window.
 f. Run the following command using Windows PowerShell:

This results in the following:
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Windows\system32>netsh winhttp show proxy
Current WinHTTP proxy settings:
    Proxy Server(s) : IP ADDRESS:PORT
    Bypass List     :  *.DOMAIN;<local>

g. Now re-run the restore job. 

h. If the issue persists disable proxy settings Exchange 2010 CAS server(s) and Media server, restart Backup Exec services and then re-run the job.

i. If the restore works with proxy disabled then the issue is with network configuration which has to be investigated by the customer.



Solution F:

Change the Backup Exec Service Account/Logon Account from Domain\User Name to FQDN\User Name.

FQDN-Fully Qualified Domain Name.




Related Articles

Exchange 2010 GRT restore of individual emails fails with error “unable to create a role assignment for ApplicationImpersonation”

Was this content helpful?

Get Support