locked
The administrative limit for this request was exceeded RRS feed

  • Question

  • Hi folks,

     

    We have an AD MA that we're using to populate posix groups into AD with, using the memberUid attribute. However the export for one of our groups, with around 2100 member, fails with the following error:

     

    Error: cd-error
    Connected data source error: The administrative limit for this request was exceeded.

     

    Here's what we're running:

    ILM 2007 FP1 (v3.3.118.0)

    AD server is Windows 2003 Enterprise R2

     

    We've tried adjusting things like the PageSize on the AD server and the Batch size and Page size in the ILM run profile without success. It seems like it's an issue with the AD MA not knowing to break up adds to AD, not sure. We'd also prefer not to manually populate the group just to get it into AD, as that we can have large fluctuations in the size of the group in production and we don't want to leave complications for others in the future.

     

    Does anyone have any suggestions?

     

    Thanks!

     

    Cove

    Monday, August 18, 2008 10:50 PM

Answers

  • So, I would recommend against adjusting any of the policies on the AD side - make sure that you are not requesting more than the policy allows, but traditionally this has never been an issue with the ADMA to do large group or object updates.

     

    I would turn on the Export log and then examine the DSML output and you can use DSDE to run the export manually to see if you can repro it.  You can find the info on DSDE here:

     

    http://msdn.microsoft.com/en-us/library/aa813598(VS.85).aspx

     

    Tuesday, August 19, 2008 12:17 AM
  • Interesting, so that rules out ILM for sure - I would try one of the Directory Services forums next and failing that open a ticket with PSS.

     

    Wednesday, August 20, 2008 4:40 AM

All replies

  • So, I would recommend against adjusting any of the policies on the AD side - make sure that you are not requesting more than the policy allows, but traditionally this has never been an issue with the ADMA to do large group or object updates.

     

    I would turn on the Export log and then examine the DSML output and you can use DSDE to run the export manually to see if you can repro it.  You can find the info on DSDE here:

     

    http://msdn.microsoft.com/en-us/library/aa813598(VS.85).aspx

     

    Tuesday, August 19, 2008 12:17 AM
  • I created an LDIF file from the AD MA drop log file, with aprox the same number of memberUid attributes, when I tried to do the import, I got the same error from ldifde as I saw with the AD MA.

    ldifde error:
    The server side error is "The administrative limit for this request was exceeded."

    Cove
    Wednesday, August 20, 2008 1:05 AM
  • Interesting, so that rules out ILM for sure - I would try one of the Directory Services forums next and failing that open a ticket with PSS.

     

    Wednesday, August 20, 2008 4:40 AM
  • It doesn't really seem like a directory issue to me, AD returned a legitimate error that the single add operation exceeded a set internal limit. The AD MA on the other hand is called an "agent", and as far as I understand, the meaning of agent suggests that it has some smarts and knows how to translate ILM's intentions to AD, including breaking up operations if needed. In theory at least. If the LDIF add operation is broken up into multiple adds, AD accepts it just fine for example. So it doesn't appear to be a limit on the members of the group, but the size of the single add operation.

    We actually do have a ticket open, though honestly we don't really have our hopes up for a fix or a workaround that doesn't involve a complex vbs script outside of ILM. We'll see what happens.

    Thanks for you help!

    Cove

    Wednesday, August 20, 2008 6:54 AM
  • How did you solve it?
    Thursday, February 12, 2009 1:46 PM
  • I had this issue recently and posted a query to the Directory Services forum, where I got an answer.  The culprit was a multi-value attribute that had a large number of values attached to it.  In my case, I didn't need the object anymore (it was an ID for a terminated employee), so I just deleted the object from AD.  But the answer did have a solution for the problem.

    Here is the post: http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/83087f21-ba51-414d-9202-badea56ba83b

    Wow, first time I've been able to answer a question here! Whoo hoo!!
    Ed Bell - Specialist, Network Services, Convergys
    Friday, February 20, 2009 3:22 AM
  • It turns out that there is a limit on the number of attributes an AD object can have, if you need more you have to use linked DNs (my terminology may not be right). In our case we had to switch from using "memberUid" on Unix groups, to "member" which takes a DN. On our Linux systems we then remapped memberUid to member and added "nss_schema rfc2307bis" to /etc/ldap.conf and it appears to be working fine -- we don't have it in full prod yet though. One unexpected benefit of this was that we can have nested Unix groups now.

    The odd thing is how our current ADAM servers don't seem to care about the attribute limit... they take groups that AD refused.

    cs
    Monday, February 23, 2009 7:23 PM
  • I just ran into this and answered on another post:

    Ok, found the source of this issue - you are writing to a multi-valued attribute and there are too many entries for AD to handle.  There is a limitation within the AD database for non-linked multi-valued attributes.  The number depends on some things I don't quite understand, one of which is an 8k total size limit on an any AD object, but essentially you have the following options to resolve this:

    • Break the object into several objects so that the total number of entries are below the threshold you're hitting - you can't split the attribute because the limitation is *per object*
    • Convert the entries to references (use the Group:member attribute) - only feasible if the entries actually refer to another object in AD however
    • Create a new objectClass to hold the information, a custom class could reduce the overall size of the object and allow you to stuff more entries into it

    There doesn't appear to be any other alternatives here - I just ran into this moving an object from ADAM to AD.  The ADAM object is a custom objectClass that has over 1200 email addresses in a multi-valued attribute.  Trying to populate a standard AD user object with the same data resulted in the same error you are seeing.


    Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com
    • Proposed as answer by Brad Turner Saturday, May 16, 2009 10:23 PM
    Friday, May 15, 2009 8:23 PM