Ist mit Windows Server 2025 das MaxPageSize Problem Geschichte?

Die einen suchen an Ostern nach Süßigkeiten – die anderen nach Neuerungen in W2k25…..

Administratoren und Entwickler kennen das Problem mit großen Datenmengen bei einer entsprechenden LDAP-Abfrage. Das trifft bekannte als auch weniger bekannte Softwareanbieter. Sobald es 4-stellig wird reagieren viele Anwendungen mit einer Fehlermeldung der Art „Partial search results returned: Sizelimit exceeded“. Als Lösung wurde hier immer eine Anpassung der LDAP Policy vorgeschlagen.


Speziell der Wert MaxPageSize galt es auf einen höheren Wert als 1000 (dem Standardwert) einzustellen.


Normalerweise geht die Sache über recht lange Zeit gut. Es kann aber sein, dass eine Anwendung mit einer Abfrage „ins Nirwana läuft“ und dann sehr viel Ressourcen eines DC nutzt. Das zieht wiederum weitere Prozesse nach sich wie Ist-Aufnahme, Bestimmung des „Störenfriedes“, Anschreiben an die Entwickler und so weiter… Hier geht wertvolle Zeit flöten, ganz abgesehen von der Beeinflussung des AD-Betriebs. Als Lösung wurde oft vorgeschlagen, die Entwickler sollten doch einen anderen Abfragemodus programmieren. Das ist leichter gesagt als getan, da das Problem oft erst nach dem Anwachsen der Datenmengen auffällt.

Das Verhalten unter W2k19
Genau das gleiche haben wir bei unserer Software dem Modularen Admin Tool (MAT) festgestellt. Bei bestimmten LDAP-Abfragen, bei denen mehr als 1000 Objekte beteiligt sind, gab es die Einschränkung, dass zur Suche nicht nur ein Buchstabe, sondern gleich mehrere eingegeben werden musste, bevor eine Trefferliste angezeigt wurde. Unten im Text ist so ein Bsp. Bis zum Bindestrich gab es ein Sizelimit exceeded. Nachfolgend das Verhalten eines W2k19 Servers.


<br/>Warning: ldap_search(): Partial search results returned: Sizelimit exceeded in C:\inetpub\wwwroot\engine\livesearch\core\handler.php(1) : eval()'d code(1) : eval()'d code(1) : eval()'d code on line190<br />{
"status": "success",
"message": "<tr><td class='success'>Successful request<\/td><\/tr>",
"result": "{\"html\":\"<tr><th>sAMAccountname<\\\/th><\\\/tr><tr><td>corp05-ek1<\\\/td><\\\/tr><tr><td>corp05-ek2….. usw.
Kam dann ein weiterer Buchstabe zur Einschränkung dazu – und somit eine kleinere Trefferliste – tja dann war die (Such)Welt wieder in Ordnung.


Das Verhalten unter W2k25
Bei einem Test unserer MAT Software unter W2k25 ist uns aufgefallen, dass dieses bekannte Verhalten aus der Vergangenheit nicht mehr auftritt.


Response Text:
"status": "success",
"message": "<tr><td class='success'>Successful request<\/td><\/tr>",
"result": "{\"html\":\"<tr><th>sAMAccountname<\\\/th><\\\/tr><tr><td>corp05_s_MAT-AD<\\\/td><\\\/tr><tr><td>corp05_s_MAT-SQL<\\\/td><\\\/tr><tr><td>corp05-ek1<\\\/td><\\\/tr><tr><td>corp05-ek2<\\\/td><\\\/tr><tr><td>corp05-ek3…….. usw.

Nach x Vergleichen von Systemeinstellungen fand sich ein Anhaltspunkt in der Registry.


So wie es aussieht, hat hier Microsoft ein anderes Verhalten bei der LDAP Abfrage und der gelieferten Ergebnismenge vorgenommen. Achja, da war ja noch der andere Aufbau der ADMX Struktur in der Registry für Wk25 und Win11…….

Der guten Form halber haben wir natürlich auch Win10 & Win11 Clientanfragen gegen unseren W2k25 MAT Server laufen lassen, hier gab es wie erwartet auch keine Probleme. Falls man also noch (krampfhaft) Gründe für den Einsatz von W2k25 benötigt – das oben geschilderte Verhalten ist zwar nicht so bekannt und beworben – hilft aber dem Admin (männlich wie weiblich) bei der Reduzierung der Störfläche.

In Ermangelung der Zeit konnte ich leider keine weiteren Tests unter Splunk oder PingID machen (die haben u.a. auch das Problem). Ihr könnt ja mal berichten, ob Ihr bei Euch in der Umgebung auch so ein Verhalten von dem neuen W2k25 Server beobachtet habt.

Österliche Grüße aus dem Test-Labor
(T)Rainer