Jump to content

AD Backup / Restore


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

Empfohlene Beiträge

Hallo zusammen

 

Ich plane einen Domain Prep meiner W2K3 Umgebung auf 2008. Soweit ich weiss, sollte ich das Event Log und netdiag / dcdiag auf jedem DC prüfen. Doch was mache ich, falls was schiefgehen sollte? Was muss ich gesichert haben damit ich einen Restore machen kann? Gibt es allenfalls Tools, welche einem helfen?

 

Ist eigentlich ein Schema Update für Exchange 2007 (von EXC2003) genauso heikel wie bei 2003 auf 2008?

 

Danke

Sunny

Link zu diesem Kommentar

Schemaupdates sind eigentlich nicht heikel, vorallem dann nicht wenn du keine eigenen Schema-Erweiterungen oder 3rd Party Schema-Erweiterungen einsetzt.

 

Was du brauchst ist eine System-State Sicherung jeder AD-Partition(Also, AD-Partitionen, nicht Festplatten). In einer kleinen Umgebung mit einer Domain in einem Forest in welcher alle DCs auch DNS Server sind reicht also ein normales System-State Backup eines beliebigen DCs.

 

Allerdings kannst du das Schema nicht restoren:

 

How to perform an authoritative restore to a domain controller in Windows 2000

Link zu diesem Kommentar

Servus,

 

Ich plane einen Domain Prep meiner W2K3 Umgebung auf 2008.

 

dann solltest du zuerst ein /FORESTPREP mit einplanen. ;)

 

http://blog.dikmenoglu.de/PermaLink,guid,58a3c79f-f34e-4635-bc5f-0bfc67045b91.aspx

 

 

Soweit ich weiss, sollte ich das Event Log und netdiag / dcdiag auf jedem DC prüfen.

 

Ja, die Ausgangssituation sollte schon in Ordnung sein.

 

 

Doch was mache ich, falls was schiefgehen sollte?

 

Du rufst die Seelenfürsorge an. :D

Nein, im Ernst. Wenn im Schema des AD alles Standard ist, brauchst du dir keine Gedanken zu machen. Es kommt ja auch auf das Tool an mit dem du die Schemaaktualisierung durchführst. Das ADPREP das ja von Microsoft stammt, ist so intelligent genug um bei einem Abbruch von dort weiter zu Verfahren, wo es stehen geblieben ist.

 

Wenn du trotzdem das ganze noch sicherer handhaben möchtest, kannst du den Träger der FSMO-Rollen und einen weiteren DC in ein eigenes Subnetz stecken und die Schemaerweiterung dort ausführen. Wenn dann die Schemaaktualisierung auf den anderen DC repliziert wurde, hängst du beide DCs erneut ins Netzwerk zurück.

 

 

Was muss ich gesichert haben damit ich einen Restore machen kann? Gibt es allenfalls Tools, welche einem helfen?

 

Mit dem ADPREP musst du dir keine Gedanken machen, wenn im Schema nichts gepfuscht wurde.

 

 

Ist eigentlich ein Schema Update für Exchange 2007 (von EXC2003) genauso heikel wie bei 2003 auf 2008?

 

Heikel? Du musst wissen was du tust, mehr nicht. ;)

Link zu diesem Kommentar

Moin,

 

Das ADPREP das ja von Microsoft stammt, ist so intelligent genug um bei einem Abbruch von dort weiter zu Verfahren, wo es stehen geblieben ist.

 

man kann sogar noch weiter gehen: Der empfohlene Weg, ein Schemaupdate in der Produktionsumgebung auszuführen, ist (neben dem etwaigen Tool eines Herstellers) ldifde.exe. Das Schemaupdate selbst ist dann eine LDIF-Datei. Da man ldifde.exe anweisen kann, bei einem existierenden Objekt mit der nächsten Anweisung fortzufahren (standardmäßig würde es abbrechen), ist diese "Intelligenz" also auch bei einem simplen Verfahren erreichbar.

 

Wenn du trotzdem das ganze noch sicherer handhaben möchtest, kannst du den Träger der FSMO-Rollen und einen weiteren DC in ein eigenes Subnetz stecken und die Schemaerweiterung dort ausführen. Wenn dann die Schemaaktualisierung auf den anderen DC repliziert wurde, hängst du beide DCs erneut ins Netzwerk zurück.

 

Hm. Ja. Kann man machen. Das wichtige ist aber eher: Was genau tut man, wenn es fehlschlägt? Das ist dann nicht ganz trivial.

 

Danke für die Infos! Es wurden allerdings AD Erweiterungen vorgenommen, eine für die Faxlösung und eine für den Remote Zugang Tokens. Sehe ich anhand von deren Einträge, ob das Probleme bereiten kann?

 

Das vorhandene Schema wird keine Probleme bereiten, es läuft ja bereits erfolgreich. Das einzige, was in dem Fall passieren könnte, wäre ein Namens- oder OID-Konflikt. Der könnte aber nur dann auftreten, wenn einer der Schema-Hersteller ganz derb geschlampt hätte. Da es hier um kommerzielle Software geht, ist nicht damit zu rechnen.

 

Du kannst natürlich hingehen und einen Export deiner Schema-Erweiterungen machen und die Namen und OIDs mit denen in dem nun anstehenden Update vergleichen. Ich wage aber zu prognostizieren, dass dieser Aufwand unnötig ist.

 

faq-o-matic.net » Schema-Versionen vergleichen

 

Gruß, Nils

Link zu diesem Kommentar

Hi,

 

ich möchte jetzt hier keinen Flamewar anzetteln, bei dem jeder seine ganz persönliche Meinung zum Thema kund tut - aber trotzdem ein, zwei Zeilen dazu:

 

man kann sogar noch weiter gehen: Der empfohlene Weg, ein Schemaupdate in der Produktionsumgebung auszuführen, ist (neben dem etwaigen Tool eines Herstellers) ldifde.exe. Das Schemaupdate selbst ist dann eine LDIF-Datei. Da man ldifde.exe anweisen kann, bei einem existierenden Objekt mit der nächsten Anweisung fortzufahren (standardmäßig würde es abbrechen), ist diese "Intelligenz" also auch bei einem simplen Verfahren erreichbar.

 

Du sprichst von "der empfohlene Weg". Wer empfiehlt diesen Weg? Sicher nicht Microsoft.

 

Natürlich kann man a) jede LDIF-Datei einzeln importieren und b) wie von Dir beschriebnen den Import mittels LDIFDE manuell durchführen und Fehler überspringen, um diese danach gegenzuprüfen und zu beheben. Mit ziemlicher Sicherheit ist das jedoch nur erfahrenen "Tiefenkennern" zu empfehlen, nicht dem normalen AD-Admin, auch wenn er sich "recht gut" auskennt. Es mag Szenarien geben wo das Sinn macht, im Normalfall jedoch definitiv nicht.

 

Hm. Ja. Kann man machen. Das wichtige ist aber eher: Was genau tut man, wenn es fehlschlägt? Das ist dann nicht ganz trivial.

 

Genau darum hebst Du den Schema-Master ggf. in eine eigene Site mit einem Schedule, der zum Zeitpunkt der Schema-Erweiterung nicht geöffnet ist oder nimmst die beiden angesprochen DCs, also den Schema-Master und einen Replikationspartner, lieber gleich aus dem Netz in einen abgeschotteten Bereich.

Schlägt dann etwas fehl, kannst Du die beiden DCs schlichtweg wieder herstellen, ohne dabei einen Forest-Recovery fahren zu müssen. Genau aus diesem Grund ist das genannte Vorgehen das korrekte.

Siehe auch Aktives Verzeichnis Blog : Schema Erweiterungen - Riskant oder unkritisch? .

 

Viele Grüße

olc

Link zu diesem Kommentar

Moin,

 

Du sprichst von "der empfohlene Weg". Wer empfiehlt diesen Weg? Sicher nicht Microsoft.

 

doch, neben Äußerungen von vielen AD-Experten wirst du diese Empfehlung auch bei Microsoft finden, wenn du dich näher mit Schemaerweiterungen befasst. Beispielsweise in einem Blog-Artikel, der in diesem Board vor sehr kurzer Zeit zitiert wurde.

 

Mit ziemlicher Sicherheit ist das jedoch nur erfahrenen "Tiefenkennern" zu empfehlen, nicht dem normalen AD-Admin, auch wenn er sich "recht gut" auskennt. Es mag Szenarien geben wo das Sinn macht, im Normalfall jedoch definitiv nicht.

 

Du redest jetzt offenbar von anderen Dingen als ich. Ich spreche nicht von einer Schemaerweiterung, die mit einer kommerziellen Applikation wie Exchange kommt. Da nimmt man selbstverständlich das mitgelieferte Werkzeug, wie ich in meinem von dir zitierten Beitrag übrigens deutlich schrieb.

 

Wenn man aber selbst eine Erweiterung des Schemas vornimmt - ja, das ist nicht der Normalfall -, besteht die Empfehlung eben genau darin, ein LDIF-File mit der Erweiterung bzw. den Erweiterungen zu erzeugen und dies per ldifde zu importieren. Dadurch erspart man sich nämlich den Aufwand, selbst ein eigenes Werkzeug mit Prüfintelligenz für den Import zu erzeugen, weil ldfide.exe das eben schon kann.

 

Nun Clara?

 

Schlägt dann etwas fehl, kannst Du die beiden DCs schlichtweg wieder herstellen

 

Tja, ganz so einfach ist es nämlich nicht. Da in dem Szenario ja das Schemaupdate fehlgeschlagen ist, muss ich ja verhindern, dass die Erweiterungen über die normale Replikation ins produktive AD geschrieben werden - auf den isolierten DCs sind sie ja drauf. Trivial? Oder ich muss mich, je nachdem, was ich getan habe, um den Schema-Master kümmern, der evtl. offline verschoben werden muss, weil ich die isolierte Maschine plattmachen musste. Trivial?

 

Nicht dass wir uns missverstehen: Ich sage ja gar nicht, dass das Verfahren falsch ist. Es ist nur nicht vollständig, weil es den Hinweg beschreibt, den Rückweg aber auslässt.

 

 

Schöner Artikel. Wenn du ihn liest, wirst du feststellen, dass er mir in meinem wesentlichen Punkt Recht gibt und dass er ebenso den Rückweg des Verfahrens ausblendet. In sofern taugt er also nicht so recht, um mich zu widerlegen.

 

Gruß, Nils

Link zu diesem Kommentar

Hi Nils,

 

wie oben angemerkt wollte ich den Thread hier nicht kapern, aber scheinbar geht es halt nicht anders. :rolleyes:

 

doch, neben Äußerungen von vielen AD-Experten wirst du diese Empfehlung auch bei Microsoft finden, wenn du dich näher mit Schemaerweiterungen befasst. Beispielsweise in einem Blog-Artikel, der in diesem Board vor sehr kurzer Zeit zitiert wurde.

 

Sei mir nicht sauer, wenn ich solchen Aussagen keinerlei Bedeutung zugestehe.

 

  1. Du sprichst von AD-Experten, gibst jedoch keinerlei Quellen an. BTW: Was sind AD-Experten - ist ein weites Feld, in dem es viele Graustufen und Spezialisierungen gibt. Aber scheinbar haben wir verschiedene Dinge gemeint (siehe unten).
     
     
  2. "wenn du dich näher mit Schemaerweiterungen befasst"
    Das setzt voraus, daß Du weißt womit ich mich befasse. Das möchte ich bezweifeln und diese Aussage führt in eine vollkommen falsche Richtung, wenn Sie nicht gleich vollkommen obsolet ist. Wer sagt dem Leser, daß Du der "besser qualifizierte AD-Experte" bist?
     
     
  3. Du sprichst wieder von einem Blog-Artikel, den Du nicht weiter benennst. Ich (und sicherlich auch andere, die diesen Eintrag hier lesen), werden jetzt wahrscheinlich nicht "dieses Board" / das gesamte Board nach irgend einem Blog-Artikel durchsuchen. Oder meintest Du den oben verlinkten Artikel - dann wäre eine andere Wortwahl klasse gewesen.

 

Du redest jetzt offenbar von anderen Dingen als ich. Ich spreche nicht von einer Schemaerweiterung, die mit einer kommerziellen Applikation wie Exchange kommt. Da nimmt man selbstverständlich das mitgelieferte Werkzeug, wie ich in meinem von dir zitierten Beitrag übrigens deutlich schrieb.

 

Ja, da stimme ich Dir in zweierlei Hinsicht zu:

 

  1. Wir sprachen scheinbar tatsächlich von unterschiedlichen Dingen. Da Du oben als Zitat die Aussage von Daim direkt beantwortet hast, in der es ganz offensichtlich und ohne jeden Zweifel um die Microsoft-eigenen Schema Erweiterungen mittels ADPREP ging, konnte man von nichts anderem ausgehen als von dem, wovon ich schrieb.
     
  2. "wie ich in meinem von dir zitierten Beitrag übrigens deutlich schrieb."
    Entschuldige wenn ich nachfrage, aber ich habe es scheinbar überlesen (und auch gerade beim nochmaligen Lesen nicht finden können): Wo genau hast Du das eindeutig geschrieben?

 

Fortsetzung folgt...

Link zu diesem Kommentar
Wenn man aber selbst eine Erweiterung des Schemas vornimmt - ja, das ist nicht der Normalfall -, besteht die Empfehlung eben genau darin, ein LDIF-File mit der Erweiterung bzw. den Erweiterungen zu erzeugen und dies per ldifde zu importieren. Dadurch erspart man sich nämlich den Aufwand, selbst ein eigenes Werkzeug mit Prüfintelligenz für den Import zu erzeugen, weil ldfide.exe das eben schon kann.

 

Da stimme ich mit Dir vollkommen überein - nur war das eben überhaupt nicht Thema dieses Threads.

 

Nun Clara?

 

Ich überlese jetzt mal den Unterton.

 

Tja, ganz so einfach ist es nämlich nicht. Da in dem Szenario ja das Schemaupdate fehlgeschlagen ist, muss ich ja verhindern, dass die Erweiterungen über die normale Replikation ins produktive AD geschrieben werden - auf den isolierten DCs sind sie ja drauf. Trivial?

 

Ja, vollkommen trivial. Wenn der Schema-Master in einem abgetrennten Netz steht oder der Schedule geschlossen ist, ist genau dies der Fall - keine Änderungen werden nach "draußen" repliziert. Genau das war es, was oben mehrfach gesagt wurde. Ich verstehe also das Problem nicht.

 

Oder ich muss mich, je nachdem, was ich getan habe, um den Schema-Master kümmern, der evtl. offline verschoben werden muss, weil ich die isolierte Maschine plattmachen musste. Trivial?

 

Er muß nicht mehr verschoben werden, das wurde ja schon vorher erledigt. Also wieder verstehe ich das Problem nicht?

Und da ich ein Systemstate Backup habe, welches bei der Rücksicherung neben anderen Komponenten die Registry und die NTDS.DIT + Logfiles zurücksichert (und das auf beiden verschobenen / offline DCs), ist das ganze überhaupt kein Thema mehr.

Und selbst wenn das nicht möglich wäre: Dann nehme ich das System im worst case Szenario (Achtung: Ich betone ausdrücklich "worst case") endgültig vom Netz und seize den Schema Master auf einen anderen DC. Durch die Trennung vom "Restnetz" tut das im Normalfall nicht weh.

 

Nicht dass wir uns missverstehen: Ich sage ja gar nicht, dass das Verfahren falsch ist. Es ist nur nicht vollständig, weil es den Hinweg beschreibt, den Rückweg aber auslässt.

 

Ok, da gebe ich Dir Recht. Darauf hätte man noch einmal explizit hinweisen können.

 

Schöner Artikel. Wenn du ihn liest, wirst du feststellen, dass er mir in meinem wesentlichen Punkt Recht gibt und dass er ebenso den Rückweg des Verfahrens ausblendet. In sofern taugt er also nicht so recht, um mich zu widerlegen.

 

Ich weiß wieder nicht genau, worauf Du hinaus willst. Ich habe den Artikel natürlich gelesen (langsam werde ich Deinen in den Raum geworfenen, nicht greifbaren Behauptungen bzw. Untertönen überdrüssig), sonst hätte ich ihn nicht verlinkt. Du hast Recht, vom "Rückweg" wird dort nicht gesprochen, aber dafür habe ich ihn auch nicht verlinkt. Er sollte das Thema nur grundsätzlich um einige Aspekte bereichern. Vielleicht hätte ich einen Absatz vor der Verlinkung einfügen sollen.

 

Bitte fasse meine Aussagen nicht als Angriff auf - denn so sind sie nicht gemeint. Aber um gleiches bitte ich Dich ebenso. Der Ton macht die Musik - und natürlich auch auch die Verlinkung auf Quellen, die man bestenfalls als "offiziell" bezeichnen kann. ;)

 

Viele Grüße

olc

Link zu diesem Kommentar

Moin,

 

Da stimme ich mit Dir vollkommen überein - nur war das eben überhaupt nicht Thema dieses Beitrags.

 

ich wollte auch ursprünglich nur eine Ergänzung zu Yusufs zitierter Aussage machen. Mehr nicht.

 

Ja, vollkommen trivial. Wenn der Schema-Master in einem abgetrennten Netz steht oder der Schedule geschlossen ist, ist genau dies der Fall - kein Änderungen werden nach "draußen" repliziert.

 

Weiter unten scheinst du es ja doch einzusehen: Mein Hinweis war, dass der spannende Punkt erst danach kommt. Was mache ich denn mit den isolierten Servern, wenn das Update fehlerhaft war? Das ist eben nicht trivial.

 

Und da ich ein Systemstate Backup habe

 

Ahaaaaa! Jetzt wird's interessant. Davon war vorher nicht die Rede. Genau auf solche Dinge wollte ich hinaus. Wie du ja weiter unten anerkennst. Also können wir das ja einfach beenden.

 

(langsam werde ich Deinen in den Raum geworfenen, nicht greifbaren Behauptungen bzw. Untertönen überdrüssig)

 

Oha, willst du wirklich auf dieses Niveau? Ich nicht.

 

Bitte fasse meine Aussagen nicht als Angriff auf - denn so sind sie nicht gemeint.

 

Dann ist ja gut. Dann können wir das Beil ja in der Erde lassen.

 

natürlich auch auch die Verlinkung auf Quellen, die man bestenfalls als "offiziell" bezeichnen kann.

 

Diese Forderung lese ich öfter. In diesem Board erstaunt mich, dass ausgerechnet die Altgedienten so darauf herumreiten. Microsoft ist doch nicht die einzige Quelle von Fachwissen zu Windows. Es gibt da noch eine lebhafte Community drumrum (zu der ich eigentlich auch dieses Board zähle).

 

Gruß, Nils

Link zu diesem Kommentar

Buenos dias,

 

man kann sogar noch weiter gehen: Der empfohlene Weg, ein Schemaupdate in der Produktionsumgebung auszuführen, ist (neben dem etwaigen Tool eines Herstellers) ldifde.exe.

 

... und CSVDE (kann es zumindest auch).

 

 

Das Schemaupdate selbst ist dann eine LDIF-Datei.

 

Was genau im Falle von ADPREP der Fall ist.

Das ADPREP macht ja auch nichts anderes, als LDF-Dateien ins Schema zu importieren.

Link zu diesem Kommentar

Moin,

 

wie oben angemerkt wollte ich den Thread hier nicht kapern, aber scheinbar geht es halt nicht anders. :rolleyes:

 

habe ich erst was übersehen, oder ist dieser Beitrag tatsächlich nachträglich in den Thread gekommen?

 

Tut mir Leid, aber auf die persönliche Auseinandersetzung in diesem Beitrag werde ich nicht öffentlich eingehen. Wenn du ein direktes Problem mit mir hast, lass uns das bitte auch direkt klären. Ich weiß wirklich nicht, was dich zu solch einer Haltung treibt. Ich habe ursprünglich eine fachliche Ergänzung zu Yusuf gegeben und dem TO eine Antwort auf eine Frage gegeben.

 

EOT für mich.

 

Gruß, Nils

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...