Administrative Limits beim Speichern im AD überschritten

[Tauchkuh 10]

Moin zusammen!

 

Zum Speichern von anwendungsspezifischen Berechtigungsinformationen haben wir eine Schemaanpassung vorgenommen. Hierfür wurde die Klasse organizationalUnit um mehrere Attribute erweitert. Bei diesen zusätzlichen Attributen handelt es sich um Multi-Valued Distinguished Names.

Grundsätzlich funktioniert das Speichern von Werten in den entsprechenden Attributen (z.B. unter Verwendung von adsiedit) wie erwartet. Überschreitet jedoch die Anzahl von Werten einen Grenzwert, kann das Objekt nicht gespeichert werden und der Fehler "Administration limit on the server has exceeded." wird angezeigt. Hierbei spielt es im wesentlichen keine Rolle, ob die Werte alle in einem Attribut gespeichert oder auf mehrere Attribute verteilt werden. Allerdings scheint sich die Gesamtzahl von speicherbaren Werten zu ändern, bevor der Fehler auftritt.

 

Welche Limits werden hier verletzt? Ist die Gesamtgröße des Objektes limitiert? Oder besteht ein Limit, wieviele Werte in einem Multi-Valued Attribut bzw. in dem gesamten Objekt gespeichert werden können?

Gibt es Möglichkeiten, diese Grenzen anzupassen bzw. die Grenzen zu umgehen?

 

Für Hinweise wäre ich dankbar.

[IThome 10]

Ich kenne dieses Problem nicht, habe aber mal gegoogled und folgendes gefunden (wenn Du 2000 Server hast) ...

Festlegen des Attributs MaxActiveQueries

How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

[Daim 12]

Servus,

 

ich kenne ähnliche Fälle (z.B. bei diversen Abfragen), bei denen ähnliche Fehlermeldungen bezgl. "Limit exceeded" erscheinen.

Leider sind diese Grenzen nirgends dokumentiert und in deinem Fall denke ich, dass dir höchstens der Microsoft Produkt Support Service (MS-PSS) dazu etwas sagen kann :( .

 

Ihr habt doch sicherlich die Schemaänderung sauber (im Sinne von Microsoft) ausgeführt.

Was man vielleicht in Frage stellen könnte, ob das AD, dass richtige Werkzeug in eurem Falle ist...

[Daim 12]

Aloha,

 

How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

 

das ist der einzigste Artikel, der überhaupt irgendwelche Grenzen aufzeigt.

Das sind bei weitem nicht alle :( .

[IThome 10]

Aber er zeigt welche ... ;) :D

[Tauchkuh 10]

Ihr habt doch sicherlich die Schemaänderung sauber (im Sinne von Microsoft) ausgeführt.

Was man vielleicht in Frage stellen könnte, ob das AD, dass richtige Werkzeug in eurem Falle ist...

 

Die Schemaerweiterung ist wohl so, wie sich MS das gedacht hat. ;)

Die Frage mit dem passenden Werkzeug ist sicher berechtigt. Ist aber leider so vom Kunden gesetzt. :rolleyes:

 

Die per ntdsutil zu konfigurierenden Parameter befassen sich wohl nur mit Queries. Wir vermuten allerdings, dass wir schon beim Speichern der Werte scheitern ....

[Daim 12]

Die Frage mit dem passenden Werkzeug ist sicher berechtigt. Ist aber leider so vom Kunden gesetzt. :rolleyes:

 

Dann sollte sich mal der Kunde erneut durch den Kopf gehen lassen.

Aber lassen wir das...

 

Die per ntdsutil zu konfigurierenden Parameter befassen sich wohl nur mit Queries.

 

Ja.

 

Wir vermuten allerdings, dass wir schon beim Speichern der Werte scheitern ....

 

Da vermutet ihr nach meiner Meinung völlig korrekt.

Deshalb hatte ich auch den MS-PSS erwähnt. Denn wenn euch dazu jemand eine klare Antwort liefern kann, noch dazu bei der getätigten Schemaänderung, dann kann es nur der MS-PSS. Der Anruf liegt bei 199 Euro.

 

Falls ihr da anruft, würden mich (und sicher einige mehr) die Infos sehr interessieren ;) .

[olc 18]

Hallo,

 

es erst ab Windows Server 2003 Forestmodus ist es (theoretisch) möglich, mehr als 5.000 Werte in einer Datenbanktransaktion ein Attribut zu schreiben, siehe Microsoft Corporation

 

In welchem Forestmodus ist die Domäne?

Wie viele Werte schreibt Ihr in das Attribut?

 

Grundsätzlich widersprechen sich jedoch die Quellen diesbezüglich: Auf der einen Seite wird bestätigt, daß die 5.000er Grenze ab Forestlevel Windows Server 2003 (bzw. Windows Server 2003 interim) gefallen ist, auf der anderen Seite gilt die Grenze jedoch weiterhin in Bezug auf LDAP-Queries (auch Add oder Modify):

 

Originating Updates: Initiating Changes

 

As a Lightweight Directory Access Protocol (LDAP) directory service, Active Directory supports the following four types of update requests:

- Add an object to the directory.

- Modify (add, delete, or replace) attribute values of an object in the directory.

- Move an object by changing the name or parent of the object.

- Delete an object from the directory.

 

Each LDAP request generates a separate write transaction. An LDAP directory service processes each write request as an atomic transaction; that is, the transaction is either completed in full or not applied at all. The practical limit to the number of values that can be written in one LDAP transaction is approximately 5,000 values added, modified, or deleted at the same time.

A write request either commits and all its effects are durable, or it fails before completion and has no effect. A write request that commits is called an originating update. An originating update is initiated and committed at a specific replica. The absolute success or failure of an update applies even for requests that might affect several attributes of a single object, such as Add or Modify. In this case, if one attribute update fails, they all fail and the object is not updated.

 

Außerdem werden scheinbar nicht alle Attribute (in dem Beispiel in Bezug auf Gruppenmitgliedschaften) automatisch nach dem Anheben des Funktionmodus konvertiert:

 

Effect of Raising the Forest Functional Level on Existing Linked, Multivalued Attributes

 

Existing linked, multivalued attributes are not directly affected when you raise the forest functional level to enable linked-value replication. These attribute values are converted to replicate as single values only when they are modified. This design avoids the performance effects that would potentially result from rewriting the existing member attribute values of all group objects in the forest at the same time.

 

Because the member attribute is not converted until it is modified, a group that exceeded the 5,000-member limit in Windows 2000 continues to represent a replication issue because the original set of members continues to replicate as a unit under the new forest functional level. New members that are added and any member values that are updated replicate separately thereafter. Therefore, if the groups that were created in Windows 2000 do not exceed the 5,000-member limit, no replication issues are associated with the group.

 

Was kannst Du also tun?

 

Keine Ahnung. :D

 

Entweder - wie von Daim vorgeschlagen - direkt an den Microsoft Support wenden oder überprüfen, wie viele Werte in einem Query in die Datenbank geschrieben werden sollen --> denn die 5000er (LDAP-) Grenze scheint weiterhin zu bestehen.

 

Gruß olc

[Daim 12]

Servus,

 

ja, die 5.000 Grenze soll zwar zu Zeiten von Windows Server 2003 behoben sein (was sie auch tatsächlich "mindestens in Bezug auf Gruppen" ist), aber für Microsoft gelten diese 5.000 als "supportet". Je mehr diese Zahl übertroffen wird, desto höher besteht die Gefahr in ein "Out-of-Version-Store" Fehler zu laufen.

 

Die Rede unter Windows Server 2003 ist vom Linked Value Replication (LVR).

 

Hat aber jetzt nicht direkt mit dem Problem des OP zu tun ;) .

[olc 18]

AAAARRRRGGGHHHHH..... Habe mir nach Deinem Post den Thread noch einmal durchgelesen. Oh man, es passiert mir immer wieder: Erst lesen, dann schreiben. :(

Für mich las es sich auf den ersten Blick so, als wenn das "Bulk-Hinzufügen" von vielen Daten fehlschlägt.

Aber es geht um die Gesamtanzahl an Attributwerten für ein Objekt.

 

Entschuldigt - ich gelobe Besserung.

 

Gruß olc

[Tauchkuh 10]

Erst mal danke für die Antworten.

Jetzt haben wir ja erst mal was zum Lesen. Könnte sein, dass das schon was bringt.

Aber ich fürchte, um den Anruf bei MS werden wir nicht rumkommen. Schaunmermal.

Ich werde berichten. Oder auch der Kollege, wenn er es denn endlich geschafft hat, sich hier nen Account einzurichten. ;)

[olc 18]

Hallo,

 

um mein "Mißgeschick" von oben wieder gut zu machen, habe ich noch ein wenig herumgestöbert. ;)

 

Das Limit liegt unter Funktionsmodus Windows 2000 grob bei 910 "non-linked" multivalue Attributen pro Objekt, von denen in der Praxis ca. 850 nutzbar sind, siehe MS Exchange Blog : Message Filtering Limits .

 

Microsoft gibt offiziell 800 für Windows 2000 an:

 

Object Size vs. Maximum Database Record Size

 

Each object in the directory is represented as one record, or row, in the database, and each attribute is represented as one column in the row. The only exceptions are certain attributes whose values are stored separately as links. The limit for record size in the database is 800 non-linked values across all attributes. Attributes that represent links do not count in this value. (For more information about linked attributes, see "Linked Attributes" later in this chapter.) The size of objects is not a problem if you use the recommended guidelines described in "Data Characteristics" earlier in this chapter.

 

Unter den Windows 2003 Funktionmodi haben sich die Werte noch einmal geändert:

 

The limit for the multivalued object in a non-linked attribute in the Active Directory directory service is defined by the operating system version and by its forest functional level. Windows Server 2003 increases the maximum numeric value that can be stored in a non-linked attribute.

 

The following table contains estimates of the maximum value that can be stored in a non-linked attribute in Windows 2000 Server and in Windows Server 2003.

 

Windows 2000 Server Mixed mode or native mode: 800

Windows Server 2003 Windows 2000 Server (default): 800

Windows Server 2003 Windows Server 2003 interim: 1300

Windows Server 2003 Windows Server 2003: 1300

 

Note: The actual value of a non-linked attribute varies depending on the length of characters and on the length of character sets in Active Directory.

 

Offensichtlich variieren die Werte (verständlicherweise) ein wenig, je nachdem was für Werte in den nicht verlinkten Attributen gespeichert werden bzw. wieviel Platz dadurch belegt wird.

 

Nichts genaues weiß man nicht. ;)

 

[EDIT] Hoffe dieses mal liege ich richtig mit meinem Verständnis des Threads. :D :D :D [/EDIT]

 

Gruß olc

[Daim 12]

Servus,

 

nach meinem Kenntnis-Stand liegt unter Windows 2000 sowie Windows Server 2003 das Abfrage-Limit bei 1000.

Also jeder Abfrage werden 1000 Ergebnisse/Werte geliefert. Daher sollte im vornherein, eine Seitenweise Abfrage gestellt werden.

 

Das hängt mit der Hardwareanforderung ab. Wenn z.B. 200 Clients zur gleichen Zeit eine größere Abfrage starten würden, wäre der DC damit überfordert, wenn er die vollen Ergebnisse liefern müsste. Denn eine Abfrage könnte ja schließlich 5.000.000 Werte liefern :suspect: .

 

Daher hat man das ganze eingegrenzt, was ja auch Sinn macht, wenn man die Hardware (hauptsächlich den RAM) mit einbezieht..

 

Retrieving Large Results Sets (Windows)

[olc 18]

Hallo Daim,

 

dieses Mal bist Du aber im Thread verrutscht oder? ;)

Meine Antwort war auf das Thread-Thema mit dem "Administration limit on the server has exceeded." gemünzt und sollte meinen Fauxpas auf Seite 1 beheben. ;)

 

 

Das Range Retrieval Thema hatten wir hier: http://www.mcseboard.de/windows-forum-ms-backoffice-31/max-gruppenanzahl-ad-121793.html#post750985

Windows Server 2000 hat 1.000, 2003 kann 1.500.

 

Gruß olc

[Daim 12]

dieses Mal bist Du aber im Thread verrutscht oder? ;)

 

Nö, ich bin schon im richtigen Thread.

Ich bin lediglich - aus mir noch nicht erklärlichen Gründen - vom OP abgewichen ;) .