Rücksicherung eines DC's in einer Domaingesamtstruktur

[holunder 10]

Hallo Boardler,

 

ich hoffe mein formulierter Titel ist nicht sehr vom Thema abgewichen. Meine Frage an euch: Wenn in einem Netz mit 3 Subnetbereichen ein DC eines Subnetbereiches durch Hardwarecrash ausfällt. Von diesem DC ein Systemstate als Sicherung zur Verfügung steht. Die beiden anderen DC's noch online sind (jeweils einer in einem Subnetbereich). Der ausgefallene DC die FSMO Rollen hostet und DNS. Reicht es den Server nur zu installieren und dann eine nicht authorisierte Rücksicherung mit ntbackup durchzuführen, um das AD wieder nutzen zu können auf dem DC?¿? Oder, wovon ich ausgehe, gibt es noch mehr zu beachten??? Wie zum Beispiel müssen die FSMO Rollen erst auf einen anderen DC übertragen werden? Gruß Holunder

[blub 115]

Hallo,

 

Microsoft Corporation

 

Empfohlen wird die Rücksicherung eines einzelnen AD-Controllers nicht, da die Gefahr besteht, dass deine AD-Datenbank beim Crash etwas abbekommen haben könnte. Sicherer ist eine Neuinstallation mit dcpromo, bzw. bei langsamer Verbindung ein "Install from media - IFM" , siehe beigefügtes Whitepaper

 

Die FSMO-Rollen solltest du auf einen anderen DC übertragen (ntdsutil: Seize FSMO..)

 

cu

blub

[holunder 10]

Danke. 2 DC's exisitieren ja noch, die das aktuelle AD hosten. Also wäre es besser den gecrashten DC neu zu installieren, in die Domain aufnemen und replizieren lassen. Aber dann hat er ja nen anderen Namen als vor dem Crash. Ich dachte ich installiere den DC neu (es exisitert noch ein mit sysprep erstelltes Images) wenn das erfolgt ist, mit ntbackup Daten Wiederherstellen Systemstate und das war es schon. Danach oder vor dem Wiederherstellen den DNS installieren?? .. So machst man das also nicht?

[firefox80 10]

das was ich gelernt habe sieht etwas anders aus...

 

wenn du vorhast den rechner nach einem restore wieder in die domäne zu nehmen, darfst du in seiner abwesenheit die fsmo rollen nicht entfernen, da nach einem restore die rollen doppelt vorhanden wären.

 

die rücksicherung non authorative erfolgen. alles was der dc in der zwischenzeit verpasst hat, soll er ja von den übrigen dcs replizieren.

 

wenn du von einzelnen subnets redest, redest du auch von ad standorten, versteh ich dich da richtig? du brauchst an deinem standort zumindest einen laufenden dc als gc um den kaputten wieder ins netz zu bekommen.

 

dns-dienst muss du installieren. wenn die zone ad integriert ist, wird sie über die replikation übernommen.

 

alles nur graue theorie - korrekturen also willkommen ;)

[holunder 10]

Danke. So wie Du es beschreibst (firefox80) hatte ich mir es auch gedacht und gehofft :shock: . Jetzt kann ich nur hoffen, dass das Systemstate Backup nicht älter als 60 Tage ist. Muss ich den DNS Service vorher, während oder nach dem Backup des Systemstates installieren. Oder ist das ganz und gar unerheblich? Es exisitieren eigentlich 3 DC's. 2 davon sind noch online, der 3. ist down (Hardwarecrash) Trotz unterschiedlicher Subnetzbereiche existiert nur eine Domain. "Firma.local" Der DC der down ist hostet die FSMO Rollen.

[BrainStorm 10]

Du hast zwei Möglichkeiten die in Betracht kommen.

1. Ein non authoratives Backup des DCs oder
   
2. Eine komplette Reinstallation des DCs - denke vorher daran mit NTDSUTIL die FSMO Rollen zu seizen.
   

Ich persönlich würde den 2. Weg gehen, aber das muss jeder selbst entscheiden. Möglich sind beide Lösungen.

[blub 115]

Hallo Holunder,

Wie die Kollegen schon geschrieben haben, sind beide Möglichkeiten (nonauthoritativer Restore und Neuinstallation) möglich

Beim Restore sind jedoch einige Fallstricke (z.b. settings im ntbackup) dabei, daher lies dir bitte den Artikel durch, den ich oben verlinkt habe. Ungefährlicher, nicht langsamer und daher empfohlen ist der Weg über IMF

 

cu

blub

[holunder 10]

Danke für die Hinweise. Zu MetaDataCleanUp habe ich mal noch eine Frage. Sind die Punkte:

• Removing the failed server object

• Removing the failed computer object

• Resetting the computer account password of the domain controller

• Resetting the krbtgt password

• Resetting a trust password on one side of the trust

noch so in der Reihenfolge notwendig, wenn mit ntdsutil das CleanUp vorgenommen wurde? Der defekte DC wurde komplett ausser Betrieb genommen. Und die Serverfunktionen auf andere verteilt. Da auf dem DC auch DNS installiert war (einziger DNS) wurde DNS auch auf einen anderen DC übertragen. Jetzt habe ich allerdings eine Fehlermeldung die ich mit dnscmd /config bootmethod unterdrücken kann, allerdings taucht die nach jedem Reboot wieder auf. Habe da zwar eine Lösung gefunden How to reinstall a dynamic DNS Active Directory-integrated zone aber da weiss ich nicht was ich tue und wollte mir mal noch Rat holen :) ob das Verfahren funktioniert.

Zu Active Directory Integrierte Zone(n) habe ich mal noch ne Frage: Wenn oder besser muss der DNS Server der die Primäre Zone in Active Directory hostet unbedingt auf einem DC installiert werden? Damit Änderungen die mit DNS zu tun haben auch am Verzeichnis vorgenommen werden können? So richtig klar ist mir das nicht .. :confused: Gruß holunder

 

@BrainStorm habe mich für Weg 2entschieden, allerdings ohne Reinstallation des DC's, also eher Weg 2.5

[gysinma1 13]

Hallo Zusammen

 

Die FSMO Rolle RID Master zu seizen sollte erst gemacht werden, wenn der FSMO RID Master wegcrashed. Das Risiko besteht (John Craddock Kimbley Assoc.), dass der RID Master duplicated RIDs generiert. Ohnehin sollten FMSO Rollen nicht leichtfertig geseized werden sondern transfer-eriert werden d.h. uebertragen.

 

Es gibt keinen Grund einen authoritativen(oder non-autoritativen) AD Restore vorzunehmen, wenn noch zwei funktionierende Domaincontroller im Netz sind.

 

Schaut Euch mal den Thread an http://www.mcseboard.de/windows-forum-ms-backoffice-31/dc-restored-clients-domaene-126592.html was da so geschehen kann ... ich wuerde den Domaincontroller in der AD komplett entfernen und danach den neu promoten.

 

Gruss

Matthias

[holunder 10]

como esta :) ich mag gar nicht darüber nachdenken, falls der EX auch noch streikt.

 

@gysinma1

Ohnehin sollten FMSO Rollen nicht leichtfertig geseized werden sondern transfer-eriert werden d.h. uebertragen.

Worin besteht da der Unterschied? Da der DC der die FSMO Rollen (alle) hostete, einen vollständigen Hardwarecrash erlitt, wurde ein anderer via ntdsutil zum FSMO Hoster :) erhoben. Mit MetaDataCleanUp hoffentlich alles was zum gecrashten DC im AD gehört hat gelöscht. Der Server der den Platz des gecrashten übernommen hat ist aber kein DC. Er hat zwar die selbe IP, aber einen anderen Namen und andere Platten. Im übrigen ist dem Server das selbe passiert wie in Deinem Link beschrieben. RAID 5 SATA onBoard Controller. Crash und nix mehr an Daten vorhanden. gruß holunder

[gysinma1 13]

Hallo

 

Ein Transfer verschiebt die Rollen. Dazu muss der alte FSMO Holder noch aktiv sein. Mit Seize wird die entsprechende FSMO Funktion des entsprechende DC authoritative gesetzt. (Die Rollen "schlummern" auf jedem DC).

 

Im Prinzip reicht im dssite.msc den alten DC komplett zu entfernen, danach in der AD (Rubrik DC is immer wech). Danach kannst Du den DC mit demselben Namen wieder in das Netz bringen.

 

Ein DC hat mehr zu verlieren als seine IP und Namen :D - Zum Glueck war ich am Microsoft IT Forum 2005 mal in einem Vortrag von John Craddock, wo der TRansfer des FSMO RID MAster eingehend diskutiert wurde.- :D

 

Der RID Master generiert RIDs. RID's sind eindeutige Kennzeichen der Objekte innerhalb der AD (haeufig wird auch SID dafuer verwendet - nur RID ist ein relative Identifier). Jeder Domaincontroller hostet eine Anzahl RIDs die nur dieser vergibt (in der Regel 500 Objekte). Diese Objekte koennen Computerkonten, User, Gruppen etc. sein. Ist der Pool von 500 erschoepft bezieht der DC seinen naechsten Pool von 500 Objekten bei dem RID Master. Der RID MAster ist unique pro Domain. Wird nun ein RID Master gesized, berechnet der RID Master anhand der hoechsten RID innerhalb der SAM die neuen Pools. Normalerweise funktioniert dies zuverlaessig. Das (kleine) Risiko besteht jedoch, wenn der kuenftige RID Master nicht alle Geraete finden kann oder weitere Fehler innerhalb der Domain SAM bestehen, dass der neue RID Master Pool den alten Pool ueberschneidet, was zur Folge hat, dass Accounts doppelt existieren koennen. Mit LDP kann dies geprueft werden (Ich bin jedoch noch bis am 11.1. in den Ferien und habe meine Linksammlung dazu nicht da liefere das noch nach wie dies getestet werden kann).

 

Interessant waere auch den GlobalCatalog in die Betrachtung einzubeziehen - grad da Du von Exchange redest.

 

DNS ist absolut problemlos solange AD integrierte Zonen existieren. Diese bauen sich selbst auf.

 

Gruss

Matthias

[firefox80 10]

Ist der Pool von 500 erschoepft bezieht der DC seinen naechsten Pool von 500 Objekten bei dem RID Master.

Minimale Korrektur: Wenn nur mehr 100 vorhanden sind, versucht der DC schon wieder auf 500 aufzustocken

[Daim 12]

Minimale Korrektur:

 

Dann korrigieren wir direkt weiter...

 

 

Wenn nur mehr 100 vorhanden sind, versucht der DC schon wieder auf 500 aufzustocken

 

Das war bis Windows 2000 SP4 so.

Ab Windows 2000 SP4 versucht der DC bereits nach Verbrauch von 50% des RID-Pools, dass standardmäßig aus 500 RIDs besteht, zu erneuern.

Im Klartext, wenn ein DC 250 RIDs verbraucht hat, versucht dieser vom RID-Master neue anzufordern.

 

"Domain controller has failed to obtain a new identifier pool" error event in Windows 2000 Server SP3 and earlier

[gysinma1 13]

:D okey

 

Nur wir hben das in Feldtest mit W2K3 SP1 nachgestellt (Firewalls) und die Anfrage kam immer erst bei etwa 450 NeuObjekten. Besteht die Moeglichkeit, dass dies in einem Brigdehead/BrancheOffice Konstrukt noch zuesatzlich verzogert wird ?

 

Gruss

Matthias

[Daim 12]

Besteht die Moeglichkeit, dass dies in einem Brigdehead/BrancheOffice Konstrukt noch zuesatzlich verzogert wird ?

 

Nein --> eigentlich nicht.

Denn wie die Domänenstruktur aussieht, ist dem RID-Master völlig egal. Es kommt vielmehr darauf an, wie die Verbindung zum RID-Master aussieht. Wenn der RID-Master ausgelastet ist, hohe Latenz in den Ping-Zeiten hat etc. kann es gut sein, dass das dauert.

Mich wundert das aber nicht, denn das AD hat teilweise sein "Eigenleben", es hält sich nämlich nicht immer an die Theorie ;) .