locked
Mailbox move: Unable to translate principals to the target mailbox RRS feed

  • Question

  • Configured a hybrid configuration using Exchange2010, during a move to Office365 it fails:

    Running Exchange 2010

    14.03.0279.002 Update Rollup 12 for Exchange Server 2010 SP3 (KB3096066) 2015, December 10)

    Downloaded report user:

    Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: S-1-5-21-409026243-1077712498-396310352-28217; ObjectGuid: c687e8c5-5f63-4855-8069-b7c46ef24377;

    Skipped item details:

    CorruptMailboxSecurityDescriptor

    The error message above appears 7 times, it has something to do with the groups that are not migrated. The mailbox move itself works, it's able to copy the content, folder hierarchy, convert the user and so on. The only problem seems to be that it can find the groups in the target forest (office 365). I've checked it and the groups are there. A few groups are:

    Exchange trusted subsystem group (Inherited)

    Organization Management group (Inherited)

    CAS server computer account (Inherited)

    delegated setup group (Inherited)

    Microsoft Exchange Domain Servers group (Inherited)

    Public Folder Management group (Inherited)

    The test account i'm testing with matches (objectguid --> immutableID).

    I've updated azure ad connect to the latest version, and disabled the sync for those groups and checked if they were removed from office365. After that i've enabled the sync and checked if they were synced again. 

    Any ideas? I think it has something to do with the inherited permissions as these are not migrated as mentioned in the documentation, but would it generate the errors above? Shouldn't it just skip them instead of displaying an error message?

    These are the full mailbox permissions:

    NT Authority\Self

    NT Authority\System

    Domain\Exchange Domain Server

    Domain\Exchange Servers

    Domain\Exchange Trusted Subsystem

    I'm not sure if these should be assigned as a full access permission to the mailbox?





    • Edited by Marc-1983 Tuesday, June 7, 2016 12:23 PM
    Tuesday, June 7, 2016 8:39 AM

Answers

  • It seems that Microsoft fixed the issue by rolling out a new update on their platform. Below a reply from a Microsoft support engineer:

    As we've discussed, this issue occurs because of some code changes on the cloud side for the remote move requests, causing some final checks on the source mailbox to fail and as a results these actions generate some bad items.

    This is the description for the bad item limit during migration:

    The BadItemLimit parameter specifies the maximum number of bad items that are allowed before the request fails. A bad item is a corrupt item in the source mailbox that can't be copied to the target mailbox. Also included in the bad item limit are missing items. Missing items are items in the source mailbox that can't be found in the target mailbox when the request is ready to complete.

    These bad items detected during and are not referring to a specific data from the user mailbox, are just some failed system checks. Our Product Group team is already implementing some code changes to ignore this "TargetPrincipals" errors automatically during the migration, like it used to work before.

    • Marked as answer by Marc-1983 Monday, July 11, 2016 7:30 PM
    Monday, July 11, 2016 7:29 PM

All replies

  • Hi there.

    Actually I'm not trying to answer your question because my issue is different, but the only reference I found on "CorruptMailboxSecurityDescriptor" was on this page.

    Yesterday I tried to migrate one user to Office365, the mailbox migrated but it was 100% empty. All other 9 users migrated normally. the only unusual thing I could find was 14 "CorruptMailboxSecurityDescriptor" skipped items in the details (under column 'KIND').

    I opened a SR with Microsoft, hopefully they will resolve it.

    JAM ADMIN

    Tuesday, June 7, 2016 10:59 AM
  • Hi there.

    Actually I'm not trying to answer your question because my issue is different, but the only reference I found on "CorruptMailboxSecurityDescriptor" was on this page.

    Yesterday I tried to migrate one user to Office365, the mailbox migrated but it was 100% empty. All other 9 users migrated normally. the only unusual thing I could find was 14 "CorruptMailboxSecurityDescriptor" skipped items in the details (under column 'KIND').

    I opened a SR with Microsoft, hopefully they will resolve it.

    JAM ADMIN

    Same issue with an empty mailbox, could you please update with the response?
    Tuesday, June 7, 2016 11:11 AM
  • Hi,

    I have a similar issue and I think the problem started after applying rollup 13 for Exchange 2010.

    Before the issue started most of the mailboxes were moved to Exchange Online with none skipped Items. AAD Connect is running on the latest version.

    The move request log file shows several of the following message (All SIDs is related to Exchange Groups):

    A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: S-1……..

    The “Skipped Items details” under column 'KIND') shows the following message:

    16 Skipped Items

    "CorruptMailboxSecurityDescriptor" (18)


    • Edited by glennaa70 Tuesday, June 7, 2016 12:48 PM
    Tuesday, June 7, 2016 12:03 PM
  • Hi,

    I have a similar issue and I think the problem started after applying rollup 13 for Exchange 2010.

    Before the issue started most of the mailboxes were moved to Exchange Online with none skipped Items. AAD Connect is running on the latest version.

    The move request log file shows several of the following message (All SIDs is related to Exchange Groups):

    A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: S-1……..

    The “Skipped Items details” under column 'KIND') shows the following message:
    "CorruptMailboxSecurityDescriptor"

    exactly the same error, received 7 corrupted items. Also running the latest version of Azure AD connect. 
    Tuesday, June 7, 2016 12:20 PM
  • When setting the BadItemLimit to higher than 16 in my case, then the mailboxes are suscessfully moved to Exchange online.
    Tuesday, June 7, 2016 12:55 PM
  • When setting the BadItemLimit to higher than 16 in my case, then the mailboxes are suscessfully moved to Exchange online.
    The problem is we need to move over 8000 mailboxes, makes it difficult to view which items are skipped. 
    Tuesday, June 7, 2016 1:06 PM
  • I have got the same problem.
    Juste created a new mailbox, 5 mails in it. The log file showes:
    Final sync has started
    7-6-201615:08:34 [SERVER4] 7-6-2016 13:07:59 [AM3PR01MB341] A corrupted item was
    encountered: Unable to translate principals to the target mailbox: Failed to
    find a principal in the target forest that corresponds to the following source
    forest principal values: SID: S-1-5-21-....

    There are no errors on the Office 365 platform.

    Any news?


    • Edited by Dimitri_S Tuesday, June 7, 2016 1:42 PM
    Tuesday, June 7, 2016 1:23 PM
  • Exact same issue here as well and it started a few weeks ago. Seemed like it was limited to migration batches created within the O365 portal, but now it's happening on individual moves created in PowerShell via the New-MoveRequest.
    Tuesday, June 7, 2016 5:25 PM
  • Hi.

    i have same problem, but i have Hybrid deployment EXchange 2007 SP3 CU 11 - Exchnage 2013 CU7.

    When i migrate mailbox, show error that folderpermissions and timeout error.


    Jorge Muñoz

    Tuesday, June 7, 2016 7:26 PM
  • Hi, 

    Same issue with our exchange hybrid environment. We have recently patched our Exch 2010 server and this error occurs when we attempt to migrate an account from on-prem to the cloud. 

    Thanks

    Tuesday, June 7, 2016 10:49 PM
  • Stil got the same problem.

    My workaround is to migrate the mailbox from the Exchange online console.
    So in Office365 choose your Exchange tab, and the migrate option.

    Works like a charme ;)


    • Proposed as answer by Dimitri_S Wednesday, June 8, 2016 8:49 AM
    • Unproposed as answer by Dimitri_S Wednesday, June 8, 2016 9:05 AM
    • Edited by Dimitri_S Wednesday, June 8, 2016 11:41 AM
    Wednesday, June 8, 2016 8:26 AM
  • When performing a move through the Online ECP the error will be the same, only thing is that maybe you will not hit the baditemlimit.

    Curious what Microsoft support their statement will be regarding this matter.

    We are facing the same issue, only in our case the Service PrincipalName is resolved to an active account. This account is however not synced to Azure AD.


    Wednesday, June 8, 2016 8:50 AM
  • Stil got the same problem.

    My workaround is to migrate the users from the Exchange online console.
    So in Office365 choose your Exchange tab, and the migrate option.

    Works like a charme ;)

    Performing the migration from Office 365/Exchange Online, so unfortunately that's not the solution. 
    Wednesday, June 8, 2016 9:38 AM
  • Stil got the same problem.

    My workaround is to migrate the users from the Exchange online console.
    So in Office365 choose your Exchange tab, and the migrate option.

    Works like a charme ;)

    Performing the migration from Office 365/Exchange Online, so unfortunately that's not the solution. 

    Do you get an error when you perform the migration with the ECP online option?

    (My error was not bad items in the mailbox itself but with mailbox rights.)

    Wednesday, June 8, 2016 11:49 AM
  • This is error show me on detail migration by users.This is error show me on ECP Exchnage Online Migration

    Jorge Muñoz


    • Edited by Jorge LM Wednesday, June 8, 2016 2:16 PM Informatio incomplete
    Wednesday, June 8, 2016 2:16 PM
  • I was having this problem as well and just got off the phone with support with a solution that worked for me.

    On the left, Ckick on Hybrid. Download and run the hybrid setup wizard (from your exchange server). This redoes the link between on-prem and Exchange Online. Give it a few minutes after running the wizard. After cleaning up all the move requests and creating a new migration batch, the migrations completed successfully. 

    I believe something happened in the past few weeks that caused hybrid connections to go wonky. Re-running the wizard reconnects and allows the mailbox moves to work again.

    • Proposed as answer by bfoley407 Wednesday, June 8, 2016 10:11 PM
    Wednesday, June 8, 2016 10:10 PM
  • Did anyone find a fix to this? 

    We started our office 365 migration this week. Prior to this week we upgraded our Exchange 2010 to SP3 RU13.

    No office 365 configurations were made until this week. 

    We created an office 2016 exchange VM to run the migrations.

    We ran the hybrid configuration wizard on 6/8/16. No issues came up.

    Trying to migrate any mailboxes that were on the 2010 environment fail.

    It currently fails with the same error as this.

    A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values

    Increasing the error count, does not resolve the issue. It just continues to retry until it eventually fails.

    Anybody have a fix yet? 

    Thursday, June 9, 2016 7:13 PM
  • We are having same issues..
    Friday, June 10, 2016 4:52 AM
  • We are having same issues too.

    Started about too weeks ago. Been already through O365 support and creating partner incidents. The problem is still there. Really no one at Microsoft knows why the remote move migration telling us that it can not see the objects in our forest that are obviously there ????

    A corrupted item was encountered: Unable to translate principals for folder "Top of Information Store"/"FolderNTSD": Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: - "the SID is corresponding in our case to AD computer object of exchange 2010 like EXCHANGE2010SERVERNAME$

    Same for all mailbox folders:

    Sent Items"/"FolderNTSD

    "Tasks"/"FolderNTSD"

    etc.


    Thursday, June 16, 2016 12:29 PM
  • We are seeing the same issue on Exchange 2010  RU 11.  Same errors as well.  We are getting 16 of them as another person mentioned.

    Someone in this thread has mentioned that MS has had them re-run the HCW and it resolved the issue.

    I'm not in a position today to test this myself, but I'd like to know if anyone else has done so?

    Edit: Someone in my Org just suggested the following: "Missing full access admins in DirSync scope..."  Will be looking into this as well.


    Thursday, June 16, 2016 2:38 PM
  • We are seeing the same issue on Exchange 2010  RU 11.  Same errors as well.  We are getting 16 of them as another person mentioned.

    Someone in this thread has mentioned that MS has had them re-run the HCW and it resolved the issue.

    I'm not in a position today to test this myself, but I'd like to know if anyone else has done so?

    Edit: Someone in my Org just suggested the following: "Missing full access admins in DirSync scope..."  Will be looking into this as well.


    We had been through re-run HCW with Microsoft Exchange Support Engineer. That did not help in our case.
    Dirsync IMHO is out of scope, since we sync only user accounts and then SID that the migration process can not translate belongs (in our case) to exchange$ computer object in on-premises AD.
    Friday, June 17, 2016 3:04 PM
  • Re-running the HCW did not resolve the issues for us either. I also have problems with Exchange system objects and orphaned accounts that would never error in the past. This started about three weeks ago for us and matches the same scenario you guys are detailing. Exchange 2007 SP3 with Exchange 2010 Rollup 12 as the hybrid. This issue was restricted to batch moves initiated from within the portal, but now I am seeing it on individual "New-MoveRequest" moves completed via Exchange Online PowerShell as well.
    • Edited by mderosia Wednesday, June 22, 2016 2:17 PM typo
    Friday, June 17, 2016 3:28 PM
  • Been on the phone with a Microsoft engineer and according to him Microsoft is having issues with there infrastructure for a couple of weeks now (the 3rd engineer who confirms this). Unfortunately they're leaving their customers in the dark.

    He advised to increase the BadItem limit, or use PowerShell to move the mailbox.

    Microsoft is aware of the problem and they've assigned it the highest priority, so just have to wait until Microsoft fixes the problem. (Do note: this applies to the problem I'm having)

    Also noticed that Microsoft initiated a move request from a Exchange Online database to another Exchange Online database, however 90% was stuck at 95% for about 1 to 2 days, the mailbox itself was 1,2 MB in size, so it seems they're having performance problems as well.



    • Edited by Marc-1983 Friday, June 17, 2016 3:46 PM
    Friday, June 17, 2016 3:42 PM
  • Been on the phone with a Microsoft engineer and according to him Microsoft is having issues with there infrastructure for a couple of weeks now (the 3rd engineer who confirms this). Unfortunately they're leaving their customers in the dark.

    He advised to increase the BadItem limit, or use PowerShell to move the mailbox.

    Microsoft is aware of the problem and they've assigned it the highest priority, so just have to wait until Microsoft fixes the problem. (Do note: this applies to the problem I'm having)

    Also noticed that Microsoft initiated a move request from a Exchange Online database to another Exchange Online database, however 90% was stuck at 95% for about 1 to 2 days, the mailbox itself was 1,2 MB in size, so it seems they're having performance problems as well.



    I was facing the same issues, contacted Microsoft about it too. I got advised to increase the BadItemLimit as well, with the warranty that no items would be skipped during the migration.
    Wednesday, June 22, 2016 2:10 PM
  • Great thread.  Ran into this same issue starting about a month ago, also have installed latest SP3 rollups they released in the past two months on the 2010 Server, hybrid setup for like nearly 2yrs now.

    I found by just upping the bad count limit to 100, it works/finalizes fine as well.

    No idea what the real issue is, and apparently Microsoft (as usual) doesn't know either.

    So try that, and good luck.

    Side note, also had some other craziness related to using the EMC on the server, with the Hybrid expanded, look at the move request section, the old request will stay there and not remove themselves even after deleting the batch online.  Have to right click/manually remove the request.

    Also out of nowhere, the Move Request field will show a user is in the process of migrating, that has been moved for over a year?!?!  Refresh the screen, hey, another user is now moving.  But they were migrated a year ago.  Bizarre.  Found I just manually delete the move request if/when it finishes this ghost move, and nothing is effected by it.

    Could this be some back-end thing that is happening automatically due to some issue with the O365 infrastructure that it is moving a user to a new DB for some weird maintenance and I just happened to see it at the exact moment when refreshing?  Nutty man.



    • Edited by Foil1 Monday, June 27, 2016 3:39 PM
    Monday, June 27, 2016 3:33 PM
  • Had this issue in Exchange 2010 RU13 hybrid. Had a discussion with support, and here are the relevant parts:

    Since the latest updates (issue seen also in Exchange 2010 SP3 UR11), issues in Access Control List are counted as Corrupted Items. These types of issues are:

    -        Permissions on mailboxes for users that no longer exist in Active Directory; this can be traced by making a LDAP query for the ObjectID counted as corrupted item;

    -        Mail-disabled security groups that have permissions on mailboxes

    -        Inactive-mailboxes

    -        Soft-deleted mailboxes

    -        Soft-deleted users with permissions on mailboxes

    1. Workaround : increase the BadItem limit
    2. Permanent Fix: keeping the Access Control List clean and healthy, by purging or recovering soft-deleted users and mailboxes, mail enable the security groups, avoid inactive-mailboxes and remove permissions for users that no longer exists (e.g. users that leave the company)

    No fixes will be delivered according to support, as this is new expected behavior.


    Arttu Arstila

    Friday, July 1, 2016 1:32 PM
  • It seems that Microsoft fixed the issue by rolling out a new update on their platform. Below a reply from a Microsoft support engineer:

    As we've discussed, this issue occurs because of some code changes on the cloud side for the remote move requests, causing some final checks on the source mailbox to fail and as a results these actions generate some bad items.

    This is the description for the bad item limit during migration:

    The BadItemLimit parameter specifies the maximum number of bad items that are allowed before the request fails. A bad item is a corrupt item in the source mailbox that can't be copied to the target mailbox. Also included in the bad item limit are missing items. Missing items are items in the source mailbox that can't be found in the target mailbox when the request is ready to complete.

    These bad items detected during and are not referring to a specific data from the user mailbox, are just some failed system checks. Our Product Group team is already implementing some code changes to ignore this "TargetPrincipals" errors automatically during the migration, like it used to work before.

    • Marked as answer by Marc-1983 Monday, July 11, 2016 7:30 PM
    Monday, July 11, 2016 7:29 PM
  • I got this error on a new batch that I just attempted to complete on 7/27.

    Anybody else still having this issue?

    Thursday, July 28, 2016 12:55 PM
  • Windows Server 08 R2 | Exchange 2010 rollup 11 | hybrid configuration

    This same error presented in todays migration batch generated from both EAC and PowerShell.

    A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values:

    Microsoft support pointed me toward this article. Seems like this is still happening.


    • Edited by enable365 Friday, August 12, 2016 1:03 PM additional info
    Thursday, August 11, 2016 6:00 PM
  • Microsoft provided me this response:

    Since the latest update (issue seen also in Exchange 2010 SP3 UR11), issues in Access Control List are counted as Corrupted Items. These types of issues are:

    -        Permissions on mailboxes for users that no longer exist in Active Directory; this can be traced by making a LDAP query for the ObjectID counted as corrupted item;

    -        Mail-disabled security groups that have permissions on mailboxes

    -        Inactive-mailboxes

    -        Soft-deleted mailboxes

    -        Soft-deleted users with permissions on mailboxes


    • Edited by enable365 Tuesday, August 16, 2016 3:44 PM a word
    Tuesday, August 16, 2016 3:44 PM