MrCocktail 192 Geschrieben 8. März 2017 Melden Teilen Geschrieben 8. März 2017 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 Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 8. März 2017 Melden Teilen Geschrieben 8. März 2017 Wie groß waren denn diese Kunden, oder ging es nur um die "Möglichkeit", dass immer irgendwas schiefgehen kann und diese schonmal davon gehört haben? ;) Zitieren Link zu diesem Kommentar
Doso 77 Geschrieben 8. März 2017 Melden Teilen Geschrieben 8. März 2017 Das ist dafür da das man das im laufenden Betrieb bearbeitet und erweitert. Wir haben verschiedene Erweiterungen, paar Mal Exchange, SCCM, Bitlocker und was eigenes. Nie Probleme gehabt. Zitieren Link zu diesem Kommentar
substyle 20 Geschrieben 8. März 2017 Melden Teilen Geschrieben 8. März 2017 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 Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 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 Zitieren Link zu diesem Kommentar
Nobbyaushb 1.471 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 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 ;) Zitieren Link zu diesem Kommentar
MrCocktail 192 Geschrieben 9. März 2017 Autor Melden Teilen Geschrieben 9. März 2017 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 Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 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 Zitieren Link zu diesem Kommentar
Nobbyaushb 1.471 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 Moin Nils, weiß ich auch alles, war bei dem Kunden auch nur 2-3 Mal, dann nicht mehr. Und ist ja auch schon recht lange her, ich wollte es halt nur erwähnen. ;) Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 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. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 (bearbeitet) 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 9. März 2017 von NilsK Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 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. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 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 Zitieren Link zu diesem Kommentar
blub 115 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 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. Zitieren Link zu diesem Kommentar
NorbertFe 2.034 Geschrieben 9. März 2017 Melden Teilen Geschrieben 9. März 2017 Dann stimmt die Aussage "darf nicht" aber trotzdem nicht, es sei denn die hat der Kunde aus welchen Gründen auch immer getroffen. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.