DC geschrottet - Expertenrat benötigt

[GinoBambino]

Shit. Ich wollte gerade meinen DC auf das neue Server 2012 R2 updaten und beim Vergrößern meiner VHD habe ich offensichtlich den Server geschrottet. Ich habe weder meine Snapshots noch startet das OS. Offensichtlich ist die Platte in einem völlig alten Zustand.

Deshalb ist es jetzt wichtig Ruhe zu bewahren und Expertenrat zu befolgen. Wenn ich meine Rechner das nächste Mal neustarte, werden sie sicherlich meckern. Bringt es was, die Rechner erst mal aus der Domäne zu nehmen und erst dann wieder in die Domäne aufzunehmen, wenn der neue Controller installiert ist.

Das Konfigurieren von DNS und Berechtigungen ist schnell getan. Ich habe nur Angst, dass meine Clients völlig durcheinander kommen und ich mich nicht mehr mit ihnen anmelden kann.

 

[Frightener]

Kein Backup?

An den Clients kannst Du Dich mit Cached Credentials anmelden, solange der DC nicht erreichbar ist. Wann Du sie aus der Domäne nimmst, ist eigentlich egal. Ohne DHCP/DNS wirst Du nur eingeschränkt arbeiten können. Spätestens wenn der neue DC läuft, mußt Du sie entfernen und neu joinen.

 

[Jaros]

Mit einem neu joinen ist es wahrscheinlich nicht getan. Sofern kein zweiter Controller existiert, kann man nach neuinstallation des Servers alle Benutzer neu einrichten und die entsprechenden zugriffsberechtigungen auf Daten, Verzeichnisse, Laufwerke USW. Das vorherige AD ist tot und du musst alles neu erstellen.
Daher sollte in einer AD-Umgebung mindestens zwei Server existieren, davon einer auf Blech.
Wieviel Benutzer sind im AD?

 

[Frightener]

Die Benutzer müssen neu eingerichtet werden. Diese haben aber mit dem Client nichts zu tun. Ich gehe mal davon aus, daß das eine Privatinstallation ist.

Ein DC auf Blech ist eigentlich nicht notwendig.

 

[GinoBambino]

Danke für die Hilfe!

Was heißt ein DC auf Blech?

Also es ist eine private Umgebung. Daher ist es auch verschmerzbar und der Aufwand hält sich in Grenzen. Ich hatte größtenteils irgendwelche Service-Accounts verwendet (TFS, SQL) sowie einen Account für meinen Bruder und meine Freundin.

Meine größte Sorge besteht eigentlich darin, dass das OS der Clients beim Aktivieren des neuen DC (der jedoch denselben FQDN hat wie der vorherige) merkt, dass es ein anderer DC ist.

Wenn ich die Clients zuvor aus der Domäne entferne und dann neu hinzufüge, schafft es dann das OS, das "neue" User-Profil auf die alten Profildaten/-Ordner zu mappen? (also z.B. "C:\Users\Username.AD")

Oder sollte ich vorher die Profilordner umbenennen ("C:\Users\Username.AD_Old"), sodass beim Aufnehmen in die Domäne neue Profile generiert werden können?

 

[Jaros]

Auf Blech heißt: auf einem richtigen Rechner.
Ok, wenn es in einer privaten Umgebung ist, ist der Schaden verschmerzbar.

Die Clients merken definitiv, dass der DC ein anderer ist, da die SID eine andere ist. Namen sind da nur Schall und Rauch. Neuer DC=neue SID bei Anwendern und Rechnern.

Bei den Profilen musst du eigentlich nur die Zugriffsrechte und den Besitzer neu setzen. Dann sollte das Anmelden eigentlich möglich sein.
Falls das nicht klappt, leg die Profile neu an (altes Profil, wie von dir vorgeschlagen, umbenennen). Inhalte wie Favoriten oder Eigene Dateien usw. kannst du dann in das neue Profilverzeichnis kopieren. Aber auch hier ev. Zugriffsrechte neu setzen.

 

[LinuxMcBook]

Daher sollte in einer AD-Umgebung mindestens zwei Server existieren, davon einer auf Blech.

Was spricht gegen rein virtuelle DCs? Hab ich bis heute nicht verstanden.
Wenn ich nicht beide auf der selben VM laufen lasse, sollte das doch egal sein.

 

[Jaros]

Das hat was mit der Zeitsynchronisierung zu tun. Außerdem verträgt das AD Snapshots nicht.
Nähere Infos hier: http://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/
und hier: http://www.faq-o-matic.net/2010/04/21/virtuelle-dcs-zeitprobleme-vermeiden/

 

[Frightener]

Man muß gewisse Sachen beachten, das muß man aber auch bei physikalischen DCs. Was in den Links steht stimmt teilweise nicht (mehr). Unter Hyper-V kann man mittlerweile auch DCs klonen.

 

[GinoBambino]

Danke. Hab mir die Infos gerade durchgelesen. Also hätte auch ein Backup meines virtualisierten DCs mir in diesem Fall nicht weitergeholfen.

Eine zusätzliche phsysische Installation ist bei mir nicht möglich, da ich den Server als Medenserver verwende und deshalb kein Server-OS installieren kann.


Würde es funktionieren, auf einer weiteren VM einen weiteren DC in Betrieb zu halten, sodass dieser einspringen kann, wenn der primäre DC kaputt geht?

B2W: Kennt ihr irgendwelche Fachbücher, die diese verschiedenen Grundlagen und Szenarien behandeln? Ich bin kein Admin, sondern Programmierer, würde aber dennoch gerne in dieser Materie firm werden. Ich weiß, dass man googlen kann und es die MS-Website gibt, aber dort stehen die Informationen wild zerstreut und nicht gut aufbereitet.

 

[Frightener]

Danke. Hab mir die Infos gerade durchgelesen. Also hätte auch ein Backup meines virtualisierten DCs mir in diesem Fall nicht weitergeholfen.

Warum nicht? Dafür ist ein Backup doch da.

Active Directory basiert auf einer Multimaster Replikation. Ein DC 'springt' dementsprechend nicht erst ein, wenn ein anderer ausfällt.

Möchtest Du Dich in das Thema Virtualisierung oder Actice Directory einarbeiten? Konkrete Empfehlungen habe ich nicht, ich würde erstmal zu einem allgemeinen Buch über Server 2012 (R2) raten. Dort sollten auch obige Themen abgearbeitet werden.

 

[GinoBambino]

Aber nur wenn das Backup exakt identisch alt ist oder?

Okay, ich werde mir mal ein ganz allgemeines Server-Buch zu legen. Das schadet nie, so etwas zu wissen

 

[Frightener]

Aber nur wenn das Backup exakt identisch alt ist oder?

Identisch mit was?

 

[GinoBambino]

Ich spreche von einem Backup der VM. Ich glaube, du meinst ein Backup des DC, richtig? Wie sieht denn solch ein Backup aus? Eine komplett eigene DC-Installation?

 

[Frightener]

Ich verstehe nicht ganz, was Du meinst. Funktionierendes Backup bedeutet, daß man einen älteren Zustand wiederherstellen kann, egal ob physikalisch, virtuell, DC, SQL oder sonstwas.

Konkret: Wenn Du ein Backup eines virtualisierten DCs hast, kannst Du es wiederherstellen, und der DC funktioniert wie vorher. Der DC ist in Deinem Fall doch eine VM.

 

[GinoBambino]

Ja, richtig. Von meinen anderen VMs (die meisten) habe ich Backups. Jedoch werden sie nicht innerhalb eines Raid-1 Verbunds erstellt, sondern einmal täglich über den Sceduler.

Wenn ich den Artikel über DCs richtig verstanden habe, würde der geringfügige Unterschied in der Aktualität zwischen produktivem DC und Backup dazu führen, dass ich den DC aus dem Backup nicht mehr verwenden könnte (weil die Transaktionsnummer etc. nicht mehr übereinstimmen). Sicherlich kann das irgendjemand hier besser erklären

 

[Simon]

Das Problem mit dem USN-Rollback hat man eigentlich nur, sofern mehr als ein DC in dem Forest vorhanden ist. Solange es nur einen DC gibt, kann man dort auch problemlos mit Snapshots arbeiten. Das schlimmste, was m.E. passieren kann ist, dass sich ein paar Computerkonten abschießen, die in der Zeit ihr Passwort geändert haben (ja, auch bei Computerkonten gibt es Passwörter). Ansonsten dürfte eigentlich nicht sooviel schiefgehen, zumindest nicht, wenn man einigermaßen regelmäßig den Backup macht (i.d.R. täglich). Zumindest ist es besser als garnichts und die Auswirkungen sollten beherrschbar sein.

Bei Domänen mit mehreren DCs kann man zwar Snapshots als Backup-Methode anwenden, jedoch muss man beim Recovery sehr vorsichtig sein, indem man die VM des jeweiligen DCs nach Möglichtkeit unmittelbar nach Wiederherstellung des letzten Snapshots vom virtuellen Netzwerk trennen sollte und den DC im Active Directory Recovery Modus beim Booten hochfahren sollte.

Alternative: DC komplett neu aufsetzen und von jeweiligen anderen wieder replizieren lassen. Das geht natürlich nur, wenn mehr als ein DC auch den globalen Katalog hält.

Bei uns laufen von insgesamt rund 50 DCs im EMEA-Vertriebsbereich (eine Domäne, ca. 25.000 Anwender) so ziemlich alle als virtuelle Maschine.

 

[Frightener]

USN Rollback tritt dann sowieso nur bei Snapshots auf. Ein AD-awares Backupprodukt (Windows Backup) funktioniert natürlich, weil die Invocation ID beim Restore zurückgesetzt wird. Bei mehreren DCs stellt man eigentlich keine DCs vom Backup wieder her (siehe Simon). GC sollten eigentlich alle DCs sein. Die FSMO Rollen müsen natürlich wiederhergestellt, d.h. übertragen warden, falls der ausgefallene DC eine inne hatte.

Ich schlage vor, daß Du Dir ein entsprechendes Buch zulegst, sonst verstehst Du sowieso nicht, was wir schreiben

RAID1 ist kein Backup!