How to fix 64bit ACL limit exceeded problem on Sharepoint.

In many cases getting “The Parameter is incorrect” error when searching crawl logs for defining why my search is not working or one site is not to be crawled.This is one specific error that addres us to  64 kb size limit of an Access Control List (ACL). Microsoft says : “This behavior occurs if the size of the access control list (ACL) is larger than 64 kilobytes (KB). The maximum buffer size of the InitializeAcl function is 64 KB. Therefore, the maximum size of an ACL in Windows, including the access control entries (ACEs) that are contained in the ACL, is 64 KB.”

Sharepoint uses ACL on background for securty issues. And this limitation is not actually a sharepoint limit .It is an operating system limit. If the limit is exceeded , calculation of security principals is not working and causes anomalies. One of them is unable to crawl and getting “The Parameter is incorrect” error on crawl logs.

What is the boundries and Limits

For Moss 2007 Security Principal Limit is Approximately 2,000 per ACL (Access Control List) on any securable object (scope)
The total size of the ACL on scopes can be no larger than 64kb. Because each security principal is approximately 32 bytes in size, there can be no more than approximately 2,000 security principals or less for each scope.  If this limit is reached, indexing of items in that scope, and all items below that scope, to fail.
Also, because SharePoint Groups are expanded during the indexing process, having more than 2,000 users or Directory Groups in a SharePoint group and using that group for securing scopes may cause indexing of items secured with these groups, and all items below them, to fail.
This limit only occurs when Windows Integrated Authentication is utilized.”

For Sharepoint 2010 you should consider belowed two limit definition.  

1)”Security Scope: The maximum number of unique security scopes set for a list should not exceed 1,000.
A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to SharePoint Server. The members of an ACL for a scope can include Windows users, user accounts other than Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.”

It is a little confusing.For both version of sharepoint the rule is same don’t exceed 64 Kb limit. For Sharepoint 2010 “exceed 1000 ACE” is just a threshold. Depending of ACE’s size there isnt any strict count limit . It should be between 1820 – 2000 ACEs.

“Except for the 64 KB limit on the ACL, there is no hard-coded limit for the number of users and groups to whom you can grant access to the portal site. You can add as many users and groups to a portal site as you want until the 64 KB limit of the ACL is reached. Because the sizes of individual ACEs vary, the total number of ACEs that can be put in an ACL also varies. Therefore, the exact number of groups and users who you can add to the portal site cannot be determined from the 64 KB limit of the ACL. To avoid this issue, we recommend that you do not add more than 1,000 users and groups to your portal site. ”

Ok . I assume that you understand the ACL and limits . now we return our main issue how to fix that problem. 
Where do we start : Determining which scopes can cause the problem.

Important !  Do not change sharepoint database ! Application of any schema change to the SharePoint database, except as part of a Microsoft-supplied service pack or hot fix, will make the SharePoint environment unsupportable. This type of change should never be applied.

Using this query you can identify the amount of security principals (ACEs) per scope (ACL):

select COUNT(ra.PrincipalId) as [Count],p.ScopeUrl
from RoleAssignment ra with(nolock)
join Perms p with(nolock) on p.SiteId = ra.SiteId and p.ScopeId = ra.ScopeId
group by p.ScopeUrl
order by [Count] desc

As you see in the results that the scope of “planing” contains 370 principals. This can be groups  or directly added users to that scope.
We could not say here if this is exceeding the 64kb ACL Windows Limit.
Look at these scenarios:

               (1) If there are 369 directly added users and one SharePoint group which contains 5.000 users than you would definitely exceed the total limit of that scope! (total principal count would be 5.369!)

               (2) If there are 369 directly added users and one SharePoint group containing an AD group with 400.000 users than you don’t exceed the total limit of that scope! (total principal count would be only 370!)

In general: For each site, or list, or list-item for which you break the permission inheritance from the parent site you will get a new scope and It will use its own ACL.

Using the following query you can identify how many users are in your available SharePoint groups:

select COUNT(m.MemberId) as [Count], g.Title as [Group-Title]
from GroupMembership m with(nolock)
join Groups g with(nolock) on m.GroupId = g.ID and m.SiteId = g.SiteId
group by g.Title
order by [Count] desc

there are two sharepoint group that are in our interest.
1289 Performace Management System.
1050 Quality Team Members .

Using one of these group on any of his sites (= ScopeUrl) can cause the crawl error “The parameter is incorrect” which the customer reported for the site.

Lets consider that we add one of these big groups  (Performance Management System) to an scope for example Operations (280) .The group counts as one principal so there are still 279 principals left or direct.
this mean 279 + 1289 = 1568 principals . it is so close the 1820-2000 limit. Think about a worst scenario to add another group to one of left 279 slot. you will exceed the limit with a big possibility.

So for workaround:
1) Define your big sharepoint groups.
2) Create a AD security group for each one
3) Move users sharepoint group to AD group.
4) Add this ad group to your Sharepoint Group instead of adding user one by one.

And Special thanks to Holger Lutz for these valuable informations .

See you in next articles.


Sharepoint 2010 Misconception with RBS

After Sharepoint 2010 sp1 is released , some new features and improvements has been spreading in several blogs.And one of the most interested the new content database limits. In SP1 , by defining specific requirements for large data storage in SharePoint, Microsoft is able to increase the supported limits for data storage in SharePoint.
Sotware boundaries and limits and the primary changes are:

  1. For a SharePoint content database up to 200 GB there are no special requirements and this limit is included for consistency.
  2. For a SharePoint content database up to 4 TB you need to additionally plan for the following two requirements:
    • Requires disk sub-system performance of 0.25 IOPS per GB, 2 IOPS per GB is recommended for optimal performance.
    • Requires the customer to have plans for high availability, disaster recovery, future capacity, and performance testing.
    • And you need to review additional considerations in the TechNet Boundaries and Limits article.
  3. For a SharePoint content database over 4TB specifically for a Document Archive scenario you are required to additionally plan for the following:
    • SharePoint sites must be based on Document Center or Records Center site templates and must be an archive scenario where less than 5% of content is actively read from each month and less than 1% of content is actively written to.
    • Do not use alerts, workflows, link fix-ups, or item level security on any SharePoint objects in the content database. Note: document archive content databases can be the recipient of documents as a result of Content Routing workflow.
  4. Other specific limits changes being made at the same time:
    • A new limit of 60million items in any one SharePoint content database
    • The specific 5 TB limit per SQL Server instance has been removed.  Instead you should work with a SQL Server professional to plan for database storage.

 Also these new extended limitation is not our artile issue if you need more info see:

And also RBS has some improvements:
The Microsoft SQL Server FILESTREAM RBS provider is now supported allowing for iSCSI connections to lower cost NAS storage. The SQL Server RBS provider is one option for RBS use with SharePoint and there are a number of ISV’s who also have RBS providers.

What about RBS misconception: Misconception is that RBS can provide extra database size limit ? Answer is “No”:

First of all Microsoft Says :
“We are clarifying that Remote Blob Storage (RBS) does not offer a way to increase the SharePoint content database size limits. The content database supported size limits apply to the sum of data stored in SQL Server plus data stored outside of SQL Server using an RBS provider”

Even if you use RBS or not , Sharepoint boundries is strict and you should not able to change it. And this is not only just Content DB size limit. it is also valid for all Sharepoint Limitation,  including Maximum document size limit of 2 GB for one file.

See you in next article…