locked
Unresolved ObjectType on all newly created or migrated 2013 Mailboxes RRS feed

  • Question

  • When migrating or adding a new user to Exchange 2013, I get the following error when going into the Mailbox Delegation section in the Exchange Admin Center.

    The object <Object CN> has been corrupted, and it's in an inconsistent state. The following validation errors happened:

    The access control entry defines the ObjectType 'Object GUID' that can't be resolved.

    I have done the following to try and resolve the GUID

    Searched via LDP, ADSI, ADUC, Repadmin, with nothing found. I've converted the GUID from string to hex and searched with still no luck.

    I get the identical error when running a Get-ADPermissions on the object as well.

    There are no inheritance blocks on the object or OUs.

    I've opened a Premier case, but wanted to ask the community if they have seen this or had any suggestions. As of right now, Exchange 2013 is the only app that can see this orphaned object.

    Tuesday, September 3, 2013 3:54 PM

All replies

  • Hello,

    Usually, the affected SID objects are referring to deleted objects, or they fail to be resolved in some cross domain circumstances. We can first use the PsGetSid tool to try to resolve them.

    For your reference, I have provided the steps below:

     ==========================================================

    1. Download PsGetSid from http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx

    2. Extract the package to any executable path, such as Desktop.

    3. Launch a command prompt and switch to the path.

    4. Run the command below (psgetsid + SID) to resolve the SID.

    Psgetsid Object GUID

    If the tool returns "No mapping between account names and security IDs was done", it can be safely removed.

    To remove it, run the following command:

    Remove-ADPermission -Identity "user name" -User "GUID” -ExtendedRights "send as"

    If you have any feedback on our support, please click here


    Cara Chen
    TechNet Community Support

    Wednesday, September 4, 2013 5:52 AM
  • While the GUID doesn't map, when trying to remove it against a user, it errors saying that it cannot resolve the GUID.
    Wednesday, September 4, 2013 3:19 PM
  • Hello,

    I recommend you use the following cmdlet to retrieve mailbox objects and attributes.

    Get-Mailbox –identity “xxx”-DomainController “xxx” | fl name,guid

    If you have any feedback on our support, please click here


    Cara Chen
    TechNet Community Support

    Thursday, September 5, 2013 2:21 AM
  • I have 36,000 mailbox objects in my environment, are you suggesting I look for this unknown GUID one at a time, in the hopes that it matches a mailbox GUID? Exchange 2013 is the only application that can see this unknown object type. I don't see it in Active Directory or Exchange 2007.



    Thursday, September 5, 2013 7:12 AM
  • Hello,

    Sorry for delayed response.

    Please use netdiag to check the communication between exchange server and DC.

    Please use test-servicehealth cmdlet to check if all required services are started.

    If you have any feedback on our support, please click here


    Cara Chen
    TechNet Community Support

    Wednesday, September 11, 2013 12:02 PM
  • Working with premier it appears to be a bug in the product. The GUID in in reference to a schemaIDGuid for a custom schema attribute that has the confidential bit set. Since there are explicit denies on the attribute Exchange 2013 doesn't know how to handle the error.
    Thursday, September 26, 2013 6:16 PM
  • Mike - I'm having this exact issue.  I have been searching the web for a week looking for a solution, tried the same things as you, and I just keep coming up empty handed.  Even though there doesn't seem to be a solution right now, I'll bookmark this thread for updates.  Thanks for posting the results of your premier call.  I was about to set up a call myself but you have saved me the hassle.  

    Did they say if this will affect functionality in the meantime?  It seems like my delegation permissions are actually ok on my migrated 2013 users, I just want to make sure before I migrate the rest of my company.

    My exact error is below and it appears only when I select "Mailbox Delegation" on a mailbox user from the EAC.  When I search AD for these objecttype guids they cannot be found.  I'm hoping it doesn't have anything to do with Lync attributes from a past deployment although if it did I'm sure it wouldn't harm anything.

    The object company.com/user/username has been corrupted, and it's in an inconsistent state. The following validation errors happened:

    The access control entry defines the ObjectType 'd819615a-3b9b-4738-b47e-f1bd8ee3aea4' that can't be resolved..

    The access control entry defines the ObjectType 'e2d6986b-2c7f-4cda-9851-d5b5f3fb6706' that can't be resolved..

    Monday, November 18, 2013 4:21 PM
  • When migrating or adding a new user to Exchange 2013, I get the following error when going into the Mailbox Delegation section in the Exchange Admin Center.

    The object <Object CN> has been corrupted, and it's in an inconsistent state. The following validation errors happened:

    The access control entry defines the ObjectType 'Object GUID' that can't be resolved.

    I also have this error. No progress so far.
    Tuesday, November 26, 2013 9:11 AM
  • Any update on this?

    I have the same issue & unable to determine where it is stemming from

    The access control entry defines the ObjectType 'd819615a-3b9b-4738-b47e-f1bd8ee3aea4' that can't be resolved.. 

    --------------------------------------------------------------------------------
     
    The access control entry defines the ObjectType 'e2d6986b-2c7f-4cda-9851-d5b5f3fb6706' that can't be resolved.. 

    --------------------------------------------------------------------------------
     
    The access control entry defines the ObjectType '9b51a1ef-79b7-4ae5-9ac8-d14c47daca46' that can't be resolved.. 

    Monday, January 20, 2014 9:52 PM
  • Hello ,

    Have you try to restart your exchange server 2013 ?

    Thursday, May 22, 2014 1:11 PM
  • the GUID specified is NOT objectGUID. It is the schemaIDGUID from the attribute definition in the schema. I think the attribute has been or is configured with ControlAccess permission. It appers that Get-ADPermission cannot deal with the ControlAccess permission


    Cheers,

    Jorge de Almeida Pinto

    Principal Consultant | MVP Directory Services | IAM Technologies

    COMMUNITY...:

    DISCLAIMER: This post is provided "AS IS" with no warranties of any kind, either expressed or implied, and confers no rights! Always evaluate/test yourself before using/implementing this!

    Tuesday, November 10, 2015 10:56 PM
  • Having the same issue - after Lync 2013 deployment I have errors saying the access control entry defines the ObjectType [SchemGuiD] that can't be resolved.. This may be correct for protocol settings but is all I can see about the users that makes no sense (besides the error I am getting as described above):

    Monday, December 7, 2015 3:44 PM
  • Sorry it wont even paste the text - it shows HTTP (GARBAGE TEXT FOLLOWS - then OWA - (more  garbage text)
    Monday, December 7, 2015 3:46 PM
  • Any update to this issue?  I have a new Exchange 2013 cu11 install with users migrated.
    Monday, April 4, 2016 11:18 PM
  • I have the same problem with my 2013 Exchange environment.  Started with my fresh install using CU8, I have since upgraded to CU12 but the issue remains.

    The access control entry defines the ObjectType 'e2d6986b-2c7f-4cda-9851-d5b5f3fb6706' that can't be resolved..

    Very frustrating.  I also get the same message right away when I open a distribution group, and if I make a change to the group and hit save, I get it again.   However the update to the group does indeed save.

    I recall getting multiple ObjectType messages like most of you are, but after using a tool called "Liza" I removed some old SID's in AD that were set on my OU's from the past.  Likely some accounts that were setup, then deleted out of AD (before my time here).   I inherited this environment so I'm not sure what happened before me, but a lot of Googling seems to point to Lync permissions.

    There seems to be a lot of people having this issue, we did not see this in Exchange 2003 or 2007, so something new in 2013 is making it flag this.

    Please post if you find a fix for this as we can all benefit.

    Thanks!

    Tuesday, August 30, 2016 2:18 PM
  • I finally found the fix for this, it was remnants of Lync in my domain root permissions.  I removed the Lync groups and it resolved the Exchange issue:

    Solution:

    1. Finding the Corrupted ObjectType in the Exchange 2013.

    Get-AdPermission "dc=example,dc=edu"

         After executing the Above command it will display the ACL entries for that object and also it will display the corrupted objectType. The sample output is given below:

    example.edu     Everyone             True  False
    example.edu     Everyone             False False
    example.edu     NT AUTHORITY\ENTE... False False
    example.edu     NT AUTHORITY\Auth... False False
    example.edu     NT AUTHORITY\SYSTEM  False False
    example.edu     BUILTIN\Administr... False False
    example.edu     S-1-5-32-554         False False
    example.edu     S-1-5-32-554         False False 


    WARNING: The object example.edu has been corrupted, and it's in an inconsistent state. The following validation happened:
    WARNING: The access control entry defines the ObjectType 'acd46e6d7-8d45-4516-a4b3-61c0e509b5be' that can't be resolved..

    2. Finding the Corrupted ACL Entry

    Get-ACl "AD:\Dc=example,dc=edu" | Select Access -ExpandProperty Access | Where-Object {$_.ObjectType -eq "'acd46e6d7-8d45-4516-a4b3-61c0e509b5be"} | Export-csv "acl.csv"

    "ActiveDirectoryRights","InheritanceType","ObjectType","InheritedObjectType","ObjectFlags","AccessControlType","IdentityReference","IsInherited","InheritanceFlags","PropagationFlags"

    "ExtendedRight","All","acd46e6d7-8d45-4516-a4b3-61c0e509b5be","00000000-0000-0000-0000-000000000000","ObjectAceTypePresent","Allow","example\testGroup","False","ContainerInherit","None"


    3. Finding the Corresponding Corrupted Permissions

    Get-ADPermission "dc=example,dc=edu" | Where-Object {$_.User -like "*testGroup"} ft identity,user,extendedrights,accessrights

    Identity                      User                          ExtendedRights                AccessRights
    --------                      ----                          --------------                ------------
    example.edu              example\testGroup          {Change Password}  {ExtendedRight}
    example.edu              example\testGroup                                           {ExtendedRight}

    I have highlighted the corrupted ACL entry in the example.edu container.

    4. Removing the Corrupted ACL entry in ADUC User Interface.

    Login as as a domain admin and remove the acl entry as follows:

    Right Click on example.ed domain --> Properties --> Security -->  Advanced --> Select the Corrupted ACL Entry --> Remove

    The issue will be resolved after removing the corrupted acl entry.

    Origin of fix:  http://idmoim.blogspot.com/2015/10/warning-access-control-entry-defines.html


    Crystal Chadwick Sr. Exchange Administrator

    Tuesday, August 30, 2016 2:24 PM
  • Hi,

    I found it to be the "BUILTIN\Administrators" generating the issue. How do I proceed as I really do not want to break the system by tampering with "BUILTIN\Administrators"!!!

    PS C:\> Get-Acl "AD:\dc=domian,dc=co,dc=uk" | select access -ExpandProperty Access | where-object {$_.ObjectType -eq "c4d2c392-5593-46d5-9dfa-4d1a47b0413d"}


    Access                : {System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule,
                            System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule...}
    ActiveDirectoryRights : ExtendedRight
    InheritanceType       : All
    ObjectType            : c4d2c392-5593-46d5-9dfa-4d1a47b0413d
    InheritedObjectType   : 4e564995-0bb3-4c0c-bfeb-1897074db5b5
    ObjectFlags           : ObjectAceTypePresent, InheritedObjectAceTypePresent
    AccessControlType     : Allow
    IdentityReference     : BUILTIN\Administrators
    IsInherited           : False
    InheritanceFlags      : ContainerInherit
    PropagationFlags      : None

    Thursday, January 12, 2017 7:45 AM
  • IISRESET on all servers can help resolve this issue. This could be caused due to cached information in the application pool which will flush after the IISRESET.

    Imran

    Tuesday, November 7, 2017 12:54 PM
  • Yes, somehow my result from the ACL returns:

    IdentityReference
    CREATOR OWNER
    NT AUTHORITY\SELF

    Any idea what is the safest way to remove it from random 20,000+ mailboxes in the Exchange server?


    /* Server Support Specialist */

    Monday, December 4, 2017 2:29 AM
  • Thanks! Saved me from a LOT of trouble - just a simple IISReset did it.
    Friday, March 9, 2018 8:36 PM
  • Just wanted to thank you for posting, we had the same problem and this was the EXACT fix for us.  We had just removed Lync 2010 from our environment and the permissions for the Lync RTC groups at the domain level were the culprit.  If anyone else is in the same boat - removed Lync from your environment, try going to the last step:  Right Click on example.ed domain --> Properties --> Security -->  Advanced and remove permissions for all of the groups that start with RTC (in our case it was RTCHSDomainServices, RTCDomainUserAdmins and RTCDomainServcerAdmins)
    Friday, November 2, 2018 12:15 AM