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.


Introduction

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

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.

↑ Return to Top


Linked 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 corresponding manager.

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).

↑ Return to Top


Link Value Replication (LVR)

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.

↑ Return to Top


Limits for Non-Linked Multi-Valued Attributes

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 table).

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.

↑ Return to Top


Script to Count Values

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.

↑ Return to Top


Lab Test Results

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.

Windows 2000 Forest Functional Level

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.

User businessCategory otherTelephone dSCorePropagationData Total Bytes/DC
User 1 831 0 3 834 17,343
User 2 828 0 1 829 18,216
User 3 414 414 1 829 14,904
User 4 823 0 5 828 18,106

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.

↑ Return to Top


Windows Server 2003 Forest Functional Level

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.

User businessCategory otherTelephone dSCorePropagationData Total Bytes/DC
User 5 1,242 0 1 1,243 27,324
User 6 621 620 1 1,242 22,342
User 7 0 1237 1 1,238 17,318

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.

↑ Return to Top


Workarounds

It should be very rare to reach the limits discussed here. But if it really becomes necessary, the only workarounds are as follows.

  • If the Forest Functional Level is Windows 2000, raise it to at least Windows Server 2003.
  • Remove values from other non-linked multi-valued attributes. The PowerShell script CountValues.ps1 would be useful to identify candidate attributes.
  • Add a pair of linked attributes to the schema to use for the purpose. Syntax DN with String might be a good choice, with the string for relevant data in the forward link, and the distinguishedName used to link to the back linked attribute.

 

↑ Return to Top


Remaining Questions

A few questions remain that are not answered by the documentation found so far.

  • It is assumed that operational attributes, also called constructed, do not count in the limits discussed above. These attribute values are not actually saved in Active Directory. They are calculated by the domain controller on request. An example would be the tokenGroups attribute.
  • What about non-linked multi-valued attributes that are not replicated? For example, the dsCorePropagationData attribute is not replicated to all DC's. The number of values in this attribute can be different on different domain controllers.

↑ Return to Top


See Also

↑ Return to Top


Other Resources

↑ Return to Top