Years ago, I gave a presentation to a conference entitled "Top 10 ways Windows 2000 allows you to shoot yourself in the foot." If I were to do that presentation today, I would place near the top of the list the ability to modify the MaxPageSize attribute.
Most administrators experience the effects of this parameter without even knowing why. For example, if you have ever attempted a search for an Active Directory object via an application or a command line search, but only received a partial list as if there was a limit to the search results returned -- well, there is a limit. It's called MaxPageSize.
Microsoft's KB315071 explains how to view and set LDAP policy in Active Directory by using Ntdsutil.exe. The article defines MaxPageSize like this:
By default, MaxPageSize is set at 1,000. That means if you perform an LDAP search from the command line or an application, you will be limited to 1,000 results.
MaxPageSize is one of several values defined in a default LDAP policy, called default query policy, which applies to the forest. The distinguished name (DN) tells you where the policy lives. The DN is
and can be found via ADSI Edit as shown in Figure 1. Although you can see the Default Query Policy object, the values -- such as the one for MaxPageSize -- are not visible via ADSI Edit.
Figure 1
[IMAGE]
Why MaxPageSize is important
Poorly constructed LDAP queries can literally bring a domain controller to its knees by flooding port 389. It is basically a self-inflicted denial of service. The DC becomes unresponsive to other LDAP requests (authentication, etc.) because it's so busy servicing the query. An administrator who knows enough to be dangerous and performs a query on say (objectClass=User) in a large environment could do that, just as well as an application.
MaxPageSize, then, guarantees that you won't get more than 1,000 entries in a single search result. You can get the r
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
');
// -->

esults you want by using paged search controls, which group the results in MaxPageSize limits. I have seen a number of cases where a well meaning admin has expanded this value to large numbers. This is extremely dangerous and can cause all sorts of errors and failures caused by a DC being unresponsive for a period of time.
Active Directory tools for MaxPageSize
While KB315071 details how to view the policy values via Ntdsutil.exe , Microsoft MVP Joe Richards developed the ADFind utility, which is much simpler and easier to use. To expose the value of MaxPageSize and other LDAP limits, use the following command (results follow):
Microsoft's ExBPA (Exchange Best Practices Analyzer) tool checks for MaxPageSize and flags it as a critical issue if the value is more that 1,000. In another case, we found that MaxPageSize had been set to 50,000. This caused Exchange to break because the Global Catalog server was so overwhelmed with LDAP traffic that the Exchange server couldn't locate a GC. Remember, MaxPageSize is forest-wide and affects all LDAP servers.
The best practice for setting MaxPageSize is to leave it alone. However, if someone does set it to a high value, you can easily reset it by using Joe Richard's AdMod tool from www.joeware.net.
First, use the ADFind command noted previously in this article to determine the value of MaxPageSize. Then use the following command to set MaxPageSize back to 1,000:
If you suspect a DC of becoming unavailable or unresponsive, you should probably check to see if MaxPageSize has been modified. I have seen this show up when running DCDiag on a DC and receiving an LDAP error with no data. This same error appears when you run DCDiag on a non-DC. However, when I ran it again, DCDiag gave the results. This was indicative of LDAP traffic running unabated, enabled by a large MaxPageSize value.
Do you have an Active Directory issue or problem that you'd like Gary to write an article about? Email him at glo11749@yahoo.com. Note: Gary cannot answer each query personally or guarantee that all will be answered. However those queries that have widespread interest or involve common AD issues will be addressed.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.