Active Directory - Fallback - Recovery?

[Apex 15]

Hallo

 

wir haben ca. 25 Domain Controller, 3 in der Zentrale und der rest in den außenstellen.

 

Wir haben vor einige Active Directory Feldwerte zu ändern.

 

Die Frage ist wie man am besten zurückgeht auf den vorherigen Stand, falls was nicht klappt.

 

Authorative Wiederherstellung? Backup & Systemstate? Änderungen nur auf manche DCs replizieren und erst wenn OK auf alle, sonst zurück?

Mir schwirren einige Ideen durch den Kopf, vielleicht hat jemand von Euch mehr Erfahrung dabei?

[Daim 12]

Moin,

 

Die Frage ist wie man am besten zurückgeht auf den vorherigen Stand, falls was nicht klappt.

 

es kommt darauf an wieviele Werte in welchen Attributen ihr die Werte auf einmal ändern wollt. Tragt ihr z.B. Werte in den Attributen die zur Klasse USER gehören ein, könnt ihr die eingetragenen Werte auch leicht wieder ändern. Aber testet es doch vorher in einer Testumgebung aus. Ich würde mir dazu mit dem VMWare-Converter vorher einen DC virtuallisieren und die Änderung dann in einer Testumgebung, die natürlich keine Verbindung zur produktiven Umgebung hat, austesten. Dann seht ihr ja was passiert.

 

 

Authorative Wiederherstellung? Backup & Systemstate?

 

Eine Autoritative Wiederherstellung wäre zwar eine Möglichkeit, aber bei 25 DCs (sind die wirklich notwendig?) eine Riesenakt. Eine System State Sicherung muss ohnehin existieren, mindestens vom FSMO-Rollen Träger oder besser von jedem DC.

 

 

Änderungen nur auf manche DCs replizieren und erst wenn OK auf alle, sonst zurück?

 

Das wäre eine Möglichkeit, das ihr auf dem DC wo ihr die Änderung durchführt die ausgehende (Outbound) Replikation und auf 23 DCs die eingehende Replikation deaktiviert. Somit erhält nur ein anderer DC die Änderung.

 

 

Mir schwirren einige Ideen durch den Kopf, vielleicht hat jemand von Euch mehr Erfahrung dabei?

 

Da ihr ja noch unsicher seit und die Auswirkungen noch nicht kennt, gehört das selbstverständlich vorher in einer Testumgebung getestet. Das Testen in der produktiven Umgebung wäre mehr als grob fahrlässig.

[Apex 15]

Danke für Deine Antwort

Es sind nur Änderungen an den Werten der Klasse User.

 

Getestet haben wir es sind aber noch nicht fertg.

Wir haben eine Menge User und eine dezentrale Struktur.

 

Reicht die authoritative Wiederherstellung nicht auf unserem HauptDC?

Repliziert sich das wieder zurück?

Das wäre eine Möglichkeit, das ihr auf dem DC wo ihr die Änderung durchführt die ausgehende (Outbound) Replikation und auf 23 DCs die eingehende Replikation deaktiviert. Somit erhält nur ein anderer DC die Änderung.

Das können wir also nutzen klingt doch gut :)

[Daim 12]

Es sind nur Änderungen an den Werten der Klasse User.

 

OK.

 

 

Getestet haben wir es sind aber noch nicht fertg.

 

Na dann testet es doch erstmal durch.

Auch wenn man es durch die Rücksicherung rückgängig machen kann, sollte es vorher komplett durchgetestet, bewertet und anschließend in der produktiven Umgebung technisch umgesetzt werden.

 

 

Wir haben eine Menge User und eine dezentrale Struktur.

 

Umso mehr solltet ihr es vorher druchgetestet haben.

 

 

Reicht die authoritative Wiederherstellung nicht auf unserem HauptDC?

Repliziert sich das wieder zurück?

 

Da ich erst jetzt weiß von was du konkret sprichst... ja, wenn alle Stricke reißen könnte man das Benutzerobjekt z.B. löschen und durch eine autoritative Wiederherstellung das Benutzerobjekt vor der Änderung wiederherstellen. Natürlich muss vor der Änderung sichergestellt werden, dass eine funktionierende sowie aktuelle SYSTEM STATE Sicherung existiert.

 

Abgesehen davon, bei einer Änderung am Benutzerobjekt ist die Gefahr sehr niedrig das Benutzerobjekt zu "zerschießen". Falls die Änderung nichts gebracht hat, löscht man i.d.R. den eingetragenen Wert einfach wieder raus.

 

 

Das können wir also nutzen klingt doch gut :)

 

Hajo, wäre zwar machbar, aber wie gesagt, vorher in einer VM testen und du kannst dir die Mühe sparen. ;)

[Apex 15]

Klar wird ordentlich getestet aber ein Recoverykonzept muss trotzdem sein.

Wollen ja bei einem Problem nicht rumlaufen wie die aufgescheuchten Hühner :D

 

Also gibt es drei möglichkeiten:

1 - Werte wieder resetten, also neue Werte mit alten überschreiben

2 - alles user löschen und authorative wiederherstellung, replizierung laufen lassen und warten

3 - replikation für den zeitraum umbiegen und erst bei erfolg auf alle ausführen lassen (das sowieso wahrscheinlich)

[Daim 12]

Klar wird ordentlich getestet aber ein Recoverykonzept muss trotzdem sein.

 

Aber selbstverständlich. Nur das ein Recoverykonzept ohnehin in jedem Unternehmen existieren müsste, nicht nur wegen einer Änderung. ;) Aber wenn man wegen einer Änderung sich dann mal ein Recoverykonzept erarbeitet, umso besser.

 

 

Wollen ja bei einem Problem nicht rumlaufen wie die aufgescheuchten Hühner :D

 

Wer will das schon.

 

 

Also gibt es drei möglichkeiten:

1 - Werte wieder resetten, also neue Werte mit alten überschreiben

2 - alles user löschen und authorative wiederherstellung, replizierung laufen lassen und warten

3 - replikation für den zeitraum umbiegen und erst bei erfolg auf alle ausführen lassen (das sowieso wahrscheinlich)

 

Korrekt.

[Apex 15]

ich danke Dir :)

[Daim 12]

ich danke Dir :)

 

Der Amerikaner würde jetzt sagen: You are welcome. ;)

[blub 115]

Hallo Apex,

Wie ändert ihr denn die Feldwerte? Doch hoffentlich reproduzierbar per Skript. Dann brauchst du doch eigentlich nur ein Fallbackskript.

 

cu

blub

[Apex 15]

Korrekt das wäre unsere erste Option. Das werden wir bereit halten.