Jump to content

Schema Erweiterung - Probleme zu erwarten


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hi,

 

heute habe ich gleich bei 2 Kunden Diskussionen gehabt, dass das Schema nicht während des normalen Betriebes erweitert / hoch gehoben werden darf.

Im Normalfall führe ich die Änderungen durch und erwarte keine Probleme (Exchange Admin)

 

Also einmal die Frage in die Runde:

 

Habt ihr in den letzten 5 Jahren Probleme gehabt, wenn ihr ein AD mittels Exchange oder Skype / Lync Setup erweitert habt oder von 2003 auf 2008 (2012) gehoben habt?

Mir persönlich sind da schon lange keine mehr untergekommen.

 

Und ja, ich achte denoch drauf, dass ich ein aktuelles Backup habe, habe es aber lange nicht mehr gehabt, dass es bei den normalen Tätigkeiten so aufwendig war, dass zu planen und umzusetzen.

 

Gruß

J

Link zu diesem Kommentar

Kommt für uns auf die Größe / Risiko an. Im Zweifel VM Clone einger DCs erzeugen und dort testen. Wenn der Kunde es zahlt, kein Problem, oder? Rate der Schema Probleme - 1x aus gefühlt über 200 - und da war scho vorher klar dass das AD ein Problem hatte. Gründliche Vorprüfung ist halt wichtig eine guter Punkt zum Starten z.B. hier: https://gallery.technet.microsoft.com/Active-Directory-Health-e3271083

Link zu diesem Kommentar

Moin,

 

ich habe nicht nur in den letzten fünf Jahren keine Probleme mit sowas festgestellt, sondern in den vergangenen 17 Jahren.

 

Wenn du die ganze Diskussion im Überblick haben willst:

 

[AD-Schemaerweiterung: Ein paar Hinweise | faq-o-matic.net]
https://www.faq-o-matic.net/2009/04/08/ad-schemaerweiterung-ein-paar-hinweise/

 

Gerade bei Standards, die vom Hersteller gut getestet sind (Exchange, neue AD-Version, Cisco ...) sind keine Probleme zu erwarten. Sollte das Update wirklich mal abbrechen (was ich auch noch nie gesehen habe), kann man es in aller Regel sogar einfach neu starten.

 

Die einzigen Fehler, die ich selbst gesehen habe, waren auf schlecht gemachte eigene Erweiterungen zurückzuführen (z.B. doppelte Object-ID). Selbst das ließ sich aber beheben und hatte keine direkten Auswirkungen.

 

Gruß, Nils

Link zu diesem Kommentar

Moinsen,

 

ich hatte das mal in der Vergangenheit, als Windows 7 noch recht "frisch" bei den Firmen angekommen war.

 

Folge war damals (mehrfach), das Clients ohne erkennbaren Grund die Vertrauensstellung zur Domäne verloren haben,

aber nicht alle und kein erkennbares Muster.

War zu der Zeit, als die DC´s mit 2003 raugenommen wurden und das Domänenlevel auf 2008 angehoben wurde.

 

Seit dem nichts mehr gehabt, beim letzten Kunden im laufenden Betrieb 2016er Server rein genommen und den Level auf 2012R2 angehoben - bei 10 DC´s und knapp 4.500 Clients

 

;)

Link zu diesem Kommentar

Hallo zusammen,

 

vielen Dank schon einmal für eure Rückmeldung, ich hatte in den vergangenen Jahren auch keine Probleme, das letzte mal von 2000 nach 2003 bei einem Kunden, aber da war auch die ganze Domain so verbugt, dass selbst Microsoft einen neu Aufbau empfohlen hat.

 

Kunden sind einmal klein, 3 DCs, einmal größer (>30DCs)

 

Gruß

J

Link zu diesem Kommentar

Moin,

 

Folge war damals (mehrfach), das Clients ohne erkennbaren Grund die Vertrauensstellung zur Domäne verloren haben,

aber nicht alle und kein erkennbares Muster.

War zu der Zeit, als die DC´s mit 2003 raugenommen wurden und das Domänenlevel auf 2008 angehoben wurde.

 

da würde ich aber mal ganz heftig auf eine andere Ursache tippen. Weder das Schema noch der Domänenlevel können damit zu tun haben.

Allenfalls der Wechsel der Verschlüsselung beim Anheben des Domänenmodus von 2003 nach "höher", aber da kenne ich auch maximal Exchange-Probleme, die nach einem Serverneustart behoben sind.

 

Gruß, Nils

Link zu diesem Kommentar

Kunden sind einmal klein, 3 DCs, einmal größer (>30DCs)

 

Es wird die lokale AD Datenbank auf jedem DC neu aufgebaut und indiziert. d.h. bei großen ADs mit vielen Objekten bzw. schwächeren DCs können diese DCs mehrere Minuten bis zu ein paar Stunden durch diesen Neuaufbau zu 100% ausgelastet sein. Wenn das auf mehreren DCs unkontrolliert bzw. gleichzeitig passiert, meldet sich in dieser Zeit niemand mehr am AD an. Es gibt zwei Eventlogeinträge auf jedem DC, wenn die Neuinitialisierung der DB beginnt bzw. abgeschlossen ist.

Also ja, wenn man sich unsicher ist, besser den Schemaupdate außerhalb der Geschäftszeiten ausführen oder das Update kontrolliert auf einem DC nach dem anderen durchführen lassen. Dafür gibt es Artikel bzw. Regkeys zum Steuern. Einfacher ist es aber, der Umgebung einfach ein paar Stunden Zeit nach dem Update einzuräumen. Dann hast du auch ein Gefühl für das nächste Mal. 

Link zu diesem Kommentar

Moin,

 

das ist so nicht ganz richtig. Eine Schema-Erweiterung führt nicht dazu, dass die Datenbank "neu aufgebaut" wird. Auch die Indizierung der vorhandenen Daten ändert sich i.d.R. nicht. Es kommen neue Felder hinzu, was das AD aufgrund seiner Datenbankstruktur sehr einfach durchführen kann. Anders als bei klassichen SQL-Datenbanken müssen dafür keine Tabellen neu definiert werden. Es findet auch keine Vollreplikation des AD statt, das gab es nur in der ersten Version von Windows 2000.

 

Zwar finden sich Artikel im Web, die vor großem Aufwand bei der Änderung der Indizes warnen. Dabei ist das Szenario aber ein anderes: In diesen Fällen geht es um vorhandene, bislang nicht indizierte Felder, die nachträglich indiziert werden, um bestimmte Abfragen zu beschleunigen. In dem Fall gibt es bereits Werte für diese Attribute, was natürlich Aufwand für das Erzeugen des Index bedeutet. Bei einer Schema-Erweiterung passiert das aber auch dann nicht, wenn man indizierte Felder hinzufügt, denn die haben ja noch keine Werte.

 

Aus der Praxis kann ich sagen, dass auch in Umgebungen mit mehreren tausend Usern die Schema-Erweiterung keine nennenswerte Last erzeugt, sodass sie meist problemlos während der Arbeitszeit gemacht werden kann. Eine 100%-Auslastung für bemerkbare Zeiträume habe ich noch nie beobachtet. Natürlich ist immer anzuraten, das nicht während der Hauptzeit zu machen, sondern in lastarmer Zeit - allerdings eher als Vorsichtsmaßnahme à la "auf Nummer sicher gehen".

 

Meine generelle Empfehlung: Man nehme ein Schema-Update ernst, bereite es sorgfältig vor und führe es aufmerksam und sorgfältig durch, vorzugsweise in lastarmer Zeit. Hinweise dazu gibt mein oben verlinkter Artikel.

Man muss aber eben keine Angst vor dem Vorgang haben - diese hält Kunden in der Praxis oft davon ab, was nicht angemessen ist.

 

Gruß, Nils

bearbeitet von NilsK
Link zu diesem Kommentar

https://technet.microsoft.com/en-us/library/cc756561(v=ws.10).aspx

 

Schema operations include the following:Updating the schema cache

  • Updating the schema index
  • Implementing schema modifications
  • Maintaining schema integrity

 

Vielleicht ist Wortwahl "neu aufgebaut und indiziert" in den Ohren eines Datenbank-Experten nicht korrekt. Jedenfalls den möglichen Effekt einer 95-100% igen länger dauernden Prozessorlast auf DCs (2008R2) kann ich dir aus eigener Erfahrung und mit Bestätigung durch Microsoft versichern.

Eine Umgebung mit 30 DCs ist auch nicht mehr ganz klein.

Link zu diesem Kommentar

Moin,

 

der Schema Index ist nur der Index auf dem Schema. Nicht der AD-Index.

 

Es mag ja auch durchaus sein, dass es zu solchen Situationen kommen kann. Das ist aber eindeutig die Ausnahme und betrifft i.d.R. auch "mittelgroße" Umgebungen nicht in der geschilderten Art. Vorsichtig sollte man sein, klar.

Vielleicht war in eurer Situation ja auch ein Index auf Attributen betroffen, die eben schon Daten hatten.

 

Was ich nur ungern stehen lassen möchte, sind pauschale Warnungen, die noch mehr Administratoren davon abhalten, nötige Updates einzuspielen. Das Thema betrifft ja nicht nur AD-Updates, sondern vor allem Exchange, und da gern mal alle drei Monate.

 

Gruß, Nils

Link zu diesem Kommentar

Hi,

 

heute habe ich gleich bei 2 Kunden Diskussionen gehabt, dass das Schema nicht während des normalen Betriebes erweitert / hoch gehoben werden darf.

Im Normalfall führe ich die Änderungen durch und erwarte keine Probleme (Exchange Admin)

 

Also einmal die Frage in die Runde:

 

Habt ihr in den letzten 5 Jahren Probleme gehabt, wenn ihr ein AD mittels Exchange oder Skype / Lync Setup erweitert habt oder von 2003 auf 2008 (2012) gehoben habt?

Mir persönlich sind da schon lange keine mehr untergekommen.

 

Meine Antwort ist: Ja, ich habe reproduzierbar -nicht nur einmalig- den oben beschriebenen, bei Microsoft bekannten, technisch nachvollziehbaren Effekt gehabt, so dass ich zu einem Schemaupdate außerhalb der Geschäftszeiten rate.

Mehr will ich dazu nicht mehr schreiben, außer der To selbst hat noch Fragen.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...