Some people have reported an error when they attempt to add values to some multi-valued attributes in
Active Directory. The error is "The administrative limit for this request was exceeded". It turns out there is a limit to the number of values allowed.
Active Directory limits the total number of values summed across all non-linked multi-valued attributes of any
object. There are no limits on linked multi-valued attributes. The issue was raised in the first forum post linked in the "Other Resources" section below. The error message is shown in the image below. In this case an attempt was made to add a value to
the otherTelephone attribute of User 1 in the first table below, after the limit had already been reached when adding values to the businessCategory attribute.
↑ Return to Top
Multi-valued attributes in Active Directory are similar to arrays. They can have zero, one, or many separate values. Examples are the member attribute of group
objects, the memberOf attribute of users, computers, contacts, and groups, and the proxyAddresses, businessCategory, and otherTelephone attributes.
Linked attributes are pairs of attributes. The forward link is an attribute you can update. The back link is a related attribute that is automatically updated by the system when you update the forward link. For example, the member attribute of groups is
a forward link. When you add a user to a group, the distinguished name of the user is added to the member attribute. Then the system
automatically adds the distinguished name of the group to the memberOf attribute of the corresponding user.
In the case of the member and memberOf attributes, both are multi-valued. However, this is not always the case. For example, the manager and directReports attributes are linked, but the manager attribute is single-valued. The directReports attribute is multi-valued.
Each user can have only one manager, but a manager can have any number of directReports. When you specify a distinguished name as the manager of a user, the system automatically adds the distinguished name of the user to the directReports attribute of the
Linked attributes are specified in Active Directory using the linkID attribute of the attribute object in the
schema. The forward linked attribute, like member or manager, will always have an even integer value for linkID. The corresponding back linked attribute has a value for linkID that is one greater than that of the forward link. The linkID of the back linked
attribute is always an odd integer. For example, linkID for the member attribute is 2, while that of the memberOf attribute is 3. Similarly, linkID for the manager attribute is 42, while that of the directReports attribute is 43. The back linked attribute
is always multi-valued. The forward linked attribute can be either single-valued or multi-valued.
All linked attributes are distinguished names. The syntax can be either DN (distinguished name), DN with String (an octet string that contains a string value and a DN), or DN with Binary (an octet string that contains a binary value and a DN).
When the forest functional level (FFL) is Windows 2000 and a multi-valued attribute is updated, the entire attribute is replicated
to all other domain controllers in the
domain. For example, if a group has 1000 members and you add another, the entire attribute of 1001 distinguished names must be replicated. To reduce replication traffic, groups in Windows 2000 were restricted to about 5000 members.
If the forest functional level is at least Windows Server 2003, linked attributes use link value replication (LVR). Only
the updated values in the multi-valued linked attribute are replicated. If one member is added to a group with 1000 existing members, only the new distinguished name must be replicated. The result is that there is essentially no limit to the number of members
possible in a group. Cases have been reported of groups with several million members.
If a group was created and members added before the forest functional level was at least Windows Server 2003, these older members will not participate in LVR. This fix would be to remove these members from the group and add them back in.
Unfortunately, multi-valued attributes that are not linked cannot use link value replication. This includes all string syntax multi-valued attributes, like proxyAddresses, businessCategory, and otherTelephone.
In a forest at Windows 2000 functional level, non-linked multi-valued attributes are limited to about 800 to 850 entries. If the forest functional
level is at least Windows Server 2003, the limit is about 1200 to 1300 entries. Further, once this limit is reached, you cannot add entries to any other non-linked multi-valued attributes of the same object. The limit actually applies to all such attributes
of the object combined.
These limits are not exact. Several factors might affect the actual limit. Blog posts state that the limit is based on the requirement that records must fit on an ESE
page. ESE (Extensible Storage Engine) is the data storage technology used in Active Directory. The data for each individual object in Active Directory is stored in a single row in the data table in the database (except for linked attributes that use a link
It should be noted that this is not related to the rangeUpper attribute of the attribute object in the schema container. The rangeUpper value applies to any one value of the multi-valued attribute. For example, the rangeUpper attribute of the businessCategory
attribute is 128. Each string value in this multi-valued attribute is limited to 128 characters.
Also, when the FFL is raised from Windows 2000 to at least Windows Server 2003, any objects where the Windows 2000 limit had been reached can now have more values added. All objects are now subject to the greater Windows Server 2003 limitation. This is different
from the situation with linked multi-valued attributes.
A PowerShell Version 2 script called CountValues.ps1 was developed to count the number of values in every non-linked multi-valued attribute
of a specified object in Active Directory. The script is linked here:
Count Values in all Non-Linked Multi-Valued Attributes of Object
The script accepts either the sAMAccountName or the distinguished name of any object in Active Directory. It reports the lDAPDisplayName
of every non-linked multi-valued attribute of the object that has at least one value, with the number of values in parentheses. Then it reports the sum total of all values.
The image below shows the error message raised when an attempt was made to add another value to the otherTelephone attribute of a user (User 6 in the second table below). Then the CountValues.ps1 script was run to document that this user has 1,242 values
in all non-linked multi-valued attributes combined.
Tests were conducted in a lab environment to see how many values could be added to non-linked multi-valued attributes before the "administrative limit" error was raised.
The table below shows how many values were added to all non-linked multi-valued attributes (that have values) of several objects before the "administrative limit" error was raised. In this case, the forest was at Windows 2000 functional level.
The PowerShell script CountValues.ps1 was used to verify the number of values in the table. The dSCorePropagationData attribute is included, but the totals for that attribute are only for the one domain controller that was queried by the script. Other DC's
had different numbers of values for this attribute.
Except for User 1, each of the values added to the businessCategory attribute was 22 characters. The values added to the otherTelephone attribute were each 14 characters. There were no values in either attribute before the test. The dsastat utility was used
to determine the storage requirements on each domain controller for each attribute for each user in the table. The utility did not report any storage requirements for the dSCorePropagationData attribute. The utility reported that the other attributes required
exactly the expected space in bytes on each domain controller. The totals for all non-linked multi-valued attributes except dSCorePropagationData are listed in the last column of the table.
The table below shows how many values were added to all non-linked multi-valued attributes of several objects before the "administrative limit" error was raised. In this case, the forest was at Windows Server 2003 functional level.
Once again the dsastat utility was used to verify the storage requirements listed in the last column of the table. These numbers do not include the dSCorePropagationData attribute. The numbers match what is expected. In all tests there were no other non-linked
multi-valued attributes with any values.
The results indicate that the limit is not strictly due to storage space requirements. Compare User 2 and User 3 in the first table above, and also User 5 and User 7 in the second table. The limit can be reached with fewer values added to otherTelephone
than to businessCategory, even though the individual values were shorter for otherTelephone in all cases. Both of these attributes have the same syntax. The only difference in the schema is that rangeUpper for businessCategory is 128, while for otherTelephone
it is 64.
It should be very rare to reach the limits discussed here. But if it really becomes necessary, the only workarounds are as follows.
A few questions remain that are not answered by the documentation found so far.