none
AD Connect - LargeObject

    Question

  • Hello,

    I am having an issue on the AD Connect with a "LargeObject" error message for 5 users.

    Not sure what has changed, and how I could fix this.

    The error looks like this:

    The provisioned object is too large. Trim the number of attribute values on this object. The operation will be retried in the next synchronization cycle.

    Tracking Id: 2a11f3bd-7083-4719-b385-edd8c192458b
    ExtraErrorDetails:
    [{"Key":"ObjectId","Value":["a4cf2c5a-96fe-4520-86cd-2029a738c025"]}]

    Any help would be much appreciated!

    Florent

    Tuesday, April 11, 2017 8:23 AM

Answers

  • Yes, UserCertificate can also contribute to the size. How many values do you have on the attribute?

    Is it possible that you have expired certificates on the attribute?

    Thanks,

    Chun Yong

    • Marked as answer by Flo Tougoud Friday, April 21, 2017 9:19 AM
    Tuesday, April 18, 2017 4:57 PM

All replies

  • Hi Guys,

    I also have this error occurring on a number of contacts that are synced into our AD via trust. I have checked the contacts attributes and nothing seems out of the ordinary. These contacts have only just been provisioned.

    Any ideas would be greatly appreciated.

    Thanks,

    Zanotti


    Wednesday, April 12, 2017 2:01 AM
  • @Florent and Zanotti, which version of Azure AD Connect is installed on your machine? Make sure you have the latest version (1.1.484.0).

    Refer to Azure AD Connect version release history - https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history

    Thursday, April 13, 2017 4:09 PM
    Moderator
  • Hi,

    This isn't an Azure AD Connect (client) issue. Rather, Azure AD puts a cap on the number of attribute values a given object can have. If Azure AD Connect tries to sync such an object across to Azure AD, Azure AD will return the LargeObject error.

    You can find out more about this error in this article section. The most common ones I see which contribute to this is proxy addresses.

    Thanks,

    Chun Yong

    Thursday, April 13, 2017 4:25 PM
  • Hello,

    Thanks for the replies.

    The version is 1.1.484.0.

    The proxyaddresses field looks just fine but i am seeing that the UserCertificate attribute could be the issue.

    Any idea how I could amend this field on the AD users side, without impacting anything?

    THank you

    Florent

    Tuesday, April 18, 2017 8:35 AM
  • Yes, UserCertificate can also contribute to the size. How many values do you have on the attribute?

    Is it possible that you have expired certificates on the attribute?

    Thanks,

    Chun Yong

    • Marked as answer by Flo Tougoud Friday, April 21, 2017 9:19 AM
    Tuesday, April 18, 2017 4:57 PM
  • I am having the same issue with an object that has the UserCertificate length too long. Tried moving the object to an OU not being synched as well as stopping the attribute from being synched, but the error still occurs because it's coming from the tenant/Azure side as an export, not an import from AD at this point. 

    EDIT: As the offending object did not actually need to be synced I moved it to an OU which was not being synced, and reran as initial sync with powershell to remove it.

    • Edited by mikalcas Thursday, April 20, 2017 3:43 PM
    Thursday, April 20, 2017 2:49 PM
  • Can you elaborate on this?

    Just began experiencing this with one of my clients over the last few days.

    Was running older version of Azure AD Connection, now running 1.1.486.0 and experiencing the same issue.

    Specifically, the UserCertificate length is too long for a few Windows 10 Computer Accounts

    The provisioned object is too large. Trim the number of attribute values on this object. The operation will be retried in the next synchronization cycle.

    Tracking Id: 3e28e53f-4619-4f6a-bc93-cd1bd2fa69b1
    ExtraErrorDetails:
    [{"Key":"ObjectId","Value":["538aecba-0740-4ab5-94c5-5e09ce2175bf"]}]



    • Edited by Will Fulmer Thursday, April 20, 2017 5:43 PM
    Thursday, April 20, 2017 5:36 PM
  • Hi,

    Moving an object to a different OU should not require initial sync. Incremental sync should suffice. May I ask how many values do you have for userCertificate on these 5 users please? Is there a specific reason/scenario as to why they have more than a handful of values?

    Thanks,

    Chun Yong

    Thursday, April 20, 2017 5:42 PM
  • Hi,

    Azure AD only permits 15 values on the userCertificate property. Enforcement is made on the service side. It is not related to the upgrade (just coincidence on the timing).

    Thanks,

    Chun Yong

    Thursday, April 20, 2017 5:55 PM
  • I am unsure but this sync is coming FROM Azure to the local domain.

    And this is an example

    30 82 02 E8 30 82 01 D0 A0 03 02 01 02 02 10 4D F5 AC 76 2C E9 F1 85 49 74 85 7A 83 42 5D 9B 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 2F 31 2D 30 2B 06 03 55 04 03 13 24 65 33 65 30 35 33 62 66 2D 34 31 35 39 2D 34 36 65 63 2D 62 32 30 38 2D 34 66 65 65 65 36 36 38 31 39 35 35 30 20 17 0D 31 37 30 34 32 30 31 37 31 32 31 31 5A 18 0F 32 31 31 37 30 34 32 30 31 37 31 32 31 31 5A 30 2F 31 2D 30 2B 06 03 55 04 03 13 24 65 33 65 30 35 33 62 66 2D 34 31 35 39 2D 34 36 65 63 2D 62 32 30 38 2D 34 66 65 65 65 36 36 38 31 39 35 35 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01 00 AC 83 C9 12 0D 89 76 14 F7 C5 CC 8D 5C 02 99 BF E9 B3 28 01 C0 EF 59 56 1A 2B 02 16 31 B5 D9 A0 E5 2B 99 56 42 E5 4C 2F 27 6B B9 F0 27 C3 10 5B 84 31 EC E3 AE 3B 93 06 63 9A 6A 78 CC C6 7E A8 1F 48 CC 79 5F 8F 7F DD 53 C3 F6 F1 C1 B0 91 B4 DA 87 D1 23 A2 A7 F4 C0 5F B5 28 1A EC 18 2E 2D FC BD 3B A3 21 D3 A5 60 3A F6 92 CD BE 31 58 23 DD E8 18 C3 5E AE 9A 38 D3 15 4C 10 54 BF 0D 7C 45 36 BA 39 0A 79 D3 E4 66 83 37 87 37 CE 33 2F 5F A7 64 11 2A 13 4D 32 E4 B5 A6 08 98 FF CB 9B 77 32 F8 CC 28 C6 69 95 85 12 23 F9 60 BA 8B 54 6B 57 D8 8B 18 B7 5E 44 86 14 0A B5 35 31 91 E6 99 0C 94 19 61 3F 4A 1F 0D E7 91 4B 5B 53 3E C0 12 E0 62 02 9C 8C 88 38 76 5A 3B FD 46 87 CB 79 25 FE 38 BE 30 58 A1 2E 3E 06 A9 B2 DE 39 10 83 37 B8 C1 10 FB BE ED 35 8D C3 35 AD 34 2E D4 05 02 03 01 00 01 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 82 01 01 00 02 AB AC 27 C9 4B CE CC E0 34 33 0C CB FE F2 BB E4 A3 C9 8C C7 99 EE CF B6 10 01 13 08 71 84 74 B7 77 C4 F4 16 FA E8 05 F4 5A FA F5 FB D4 16 18 9D D0 C8 6C B7 97 30 92 6C 09 BE 14 7D B6 17 B3 7C 2A 33 6A 6E 2A 8D 05 87 F5 60 2F 37 91 1B C4 D9 19 97 48 1A E0 1B 57 16 8C 07 2F 3B 2B 3E CB 39 BC C5 15 D7 64 8F EE 08 2B F9 28 0C 51 3C FA 7B 40 73 69 BD B3 04 D4 EE 9E 3E 7F EA 72 C7 6B 0A 6D F7 5D 5B 8A F9 91 19 7E 17 27 21 1D 18 DC A9 3C 75 FF 58 F9 05 4B C5 99 68 19 6C 76 78 43 79 14 63 C2 9C 43 B9 34 68 0D 47 41 48 12 CD 1E 68 16 90 F6 38 B4 73 B5 B5 0D CF B2 4F 02 49 6D 72 A4 6A F8 ED 26 80 59 F1 34 0B 33 05 93 FF 4E 78 12 9B 3E 75 6E C7 6D 99 B3 B8 F6 FA BF 03 4F 25 FA 30 5A 46 54 E6 6D 1E F2 0E D3 81 0B 78 BD 33 00 47 AB CB 4E 15 DB 6B D5 E8 57 C7 85 A1 FA

    Thursday, April 20, 2017 9:03 PM
  • I too am having the exact same issue. Sync from AD is  completing with errors because the userCertificate attribute contains more than 15 values. This is has come from being a school, with common machines, and running EAP-TLS wireless. So everytime a student logs onto a different machine, a user certificate is created.

    Running Azure AD Connect 1.1.180.0

    Have disabled the userCertificate attribute syncing, however as previously stated, it seems to be coming from Azure AD. Not an option to move them to a non syncing OU, as they are active users, and there are currently around 200 accounts with this sync error.

    Friday, April 21, 2017 2:25 AM
  • Hi,

    Sorry to hear about the issue. Just to confirm, for these 200 accounts, are they User objects or Computer objects?

    Do they have certificates that need to be used for any Azure/O365/cloud scenarios? Or they are all EAP-TLS certs?

    If I can prescribe you a sync rule that will block export the userCertificate attribute for objects with > 15 values to Azure AD without error, will that help?

    Thanks,

    Chun Yong

    Friday, April 21, 2017 2:56 AM
  • Hi Chun,

    They are user objects. We are running in hybrid environment so we haven't deployed any certs for the online scenarios, only for the EAP-TLS. If we could block the export that would be fantastic.

    Regards

    Chris

    • Edited by SJCIT Friday, April 21, 2017 3:09 AM
    Friday, April 21, 2017 3:08 AM
  • Thanks for the clarification, Chris. I am testing the sync rule. I will update the thread once I am ready to share.

    Thanks,
    Chun Yong

    Friday, April 21, 2017 3:15 AM
  • You can use AD attribute filtering to omit those users from the sync. I have done this and it works perfectly. 

    https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-configure-filtering

    My issue is with contacts that are synced via overseas parent company. ie. global contacts that are synced into the GAL

    I have the ability to change the contacts, but the overseas sync replaces my changes. I have requested overseas to change objects to no avail.

    Omitting the contacts from sync, stops the error spam emails every 30 mins, but not really a solution. 

    Regards,

    Zanotti


    • Proposed as answer by Zanotti78 Friday, April 21, 2017 9:21 AM
    Friday, April 21, 2017 4:05 AM
  • After removing expired certificates, the users can sync OK now.

    MS has published an article yesterday: 

    Problem detected: Azure AD LargeObject synchronization error
    MC99314 

    Thanks for the help.

    Florent

    Friday, April 21, 2017 9:19 AM
  • Do you have a link to the article?

    I could not find it.

    Friday, April 21, 2017 11:58 AM
  • Hi Steve,

    Logon on to Office 365 Portal > Go to Health > Under Health Message Centre

    You will find MC99314.

    Please snap shot for the same:


    Shreedhar Ette

    Saturday, April 22, 2017 4:03 PM
  • Florent,

    How did you remove the expired certificates?  When I look at them under attributes they are only hex entries.

    We have about 25+ users that have this issue.  

    I am unaware of any reason to sync the userCertificate attribute in our environment as such that might be an easier fix for us.  School district only using O365 not full AzureAD.

    Thanks for any help.

    • Proposed as answer by ChrisLee1107 Sunday, April 23, 2017 2:06 PM
    Saturday, April 22, 2017 8:34 PM
  • For those of us who are new to the AD sync, how do you find which object is too large, as the error message doesn't say in plain language?
    Monday, April 24, 2017 2:50 PM
  • When you look at the error in AAD Connect (click on the CN={number} and not the "AttributeValueTooLarge" error message, sort by the operation column.  It will say "Add" ... it's going to be one of those attributes.

    In my experience, the attributes most likely to cause this problem are:

    - ProxyAddresses (more than about 330 proxies will cause this error)

    - UserCertificate

    You may have a corrupt on-premises object which causes AAD Connect to attempt to re-provision an O=ExchangeLabs x500 address (I've seen objects with a few hundred added).  You can delete all of those proxies and try for a successful synchronization of that user object. 

    If the large attribute error is in the UserCertificate, you can modify AD connector (right-click > Properties), select the Attributes tab, and then clear the checkbox for "userCertificate".

    After making that change, you'll need to do a full import and full sync on your AD connector. 

    If have a script here https://blogs.technet.microsoft.com/undocumentedfeatures/2017/02/10/removing-proxy-addresses-from-exchange-recipients/ that may help you in bulk removing the proxy addresses for your errored users.
    23 hours 36 minutes ago
  • ChrisLee1107,

    I found this script that was just published on 4/21/2017.  Can someone review it and verify if this will work.

    Remove Expired Certificates from AD objects

    1 hour 37 minutes ago