Fehler in NTDS Datenbank

[H. Hennig 10]

Hallo,

folgendes Szenario:

Server 2008R2 SP1, DC, einziger DC in der Domäne (kleines Netzwerk, nur 1 Server).

 

Zufälligerweise wurde bei Wartungsarbeiten festgestellt, dass offensichtlich schon seit längerer Zeit ein Problem mit der NTDS Datenbank vorliegt.

Im Protokoll vom Verzeichnisdienst erschein regelmäßig und in kurzer Folge folgender Fehler:

"NTDS (624) NTDSA: Datenbank C:\Windows\NTDS\ntds.dit: Index INDEX_000200A9 von Tabelle datatable ist beschädigt (0).", Quelle: NTDS ISAM, ID: 467

Da die ältesten Einträge im Protokoll vom 15.07.2016 sind und der Fehler da schon auftauchte kann ich nicht sagen wie lange dieser schon vorliegt.

Im Netzwerk sind keine Probleme feststellbar, weswegen bis jetzt niemand auf diesen Fehler aufmersam wurde.

Zwischzeitlich gibt es im Protokoll normale Meldungen:

- "NTDS (624) NTDSA: Onlinedefragmentierung hat einen vollständigen Durchlauf der Datenbank 'C:\Windows\NTDS\ntds.dit' begonnen.", ID: 700

- "Die Active Directory-Domänendienste haben den globalen Katalog in folgendem Standort gefunden." , ID: 1869

- "NTDS (624) NTDSA: Die Onlinedefragmentierung hat einen vollständigen Durchlauf der Datenbank 'C:\Windows\NTDS\ntds.dit' abgeschlossen und dabei 0 Seiten freigegeben. ...", ID: 701

- "Internal event: The Address Book hierarchy table has been rebuilt.", ID: 1162

Offensichtlich scheint die Beschädigung der Datenbank nicht gravierend zu sein.

 

Meine Suche nach Reparaturmöglichkeiten hat im Wesentlichen zweierlei ergeben:

Erste Variant: DC herabstufen, aus der Domäne nehme und dann wieder zum DC machen - geht nicht weil einziger DC in der Domäne

Zweite Variante: Prüfung / Reparatur der Datenbank mit NTDSUtil

 

Vor letzterer Variante habe ich ein wenig Respekt. Was ist, wenn dabei die Datenbank noch mehr Schaden nimmt und der Dienst "NTDS" anschließend nicht mehr startet? Es gibt zwar eine tägliche Datensicherung, aber ich will natürlich schlimmeres verhindern.

Hat jemand irgendeine Empfehlung oder einen Tipp für mich?

 

H.H.

 

[Doso 77]

Deswegen hat man:

 

1. Ein Backup seines Domain Controllers, vor allem wenn es der einzige ist.

2. Einen zweiten Domain Controller

[H. Hennig 10]

@Doso

 

Ein Backup liegt vor. Da allerdings nicht bekannt ist seit wann der Fehler auftritt kann es gut sein, dass kein Backup ohne diesen Fehler existiert (5 Backups Mo. - Fr. rotierend).

Das man besser mehr als einen DC haben sollte ist bekannt. In kleineren Netzwerkumgebungen wird dies aber kaum praktiziert.

[magheinz 110]

@Doso

 

Das man besser mehr als einen DC haben sollte ist bekannt. In kleineren Netzwerkumgebungen wird dies aber kaum praktiziert.

Tja, lernen durch Schmerzen,

Jeder der eine AD betreibt sollte irgendwo zur Not noch einen ausrangierten PC haben und sich eine Standard-Serverlizenz leisten können.

Ansonsten sollte man es lieber lassen.

[H. Hennig 10]

Ich will mich ja nicht unbeliebt machen, aber ich glaube, dass unkonstruktive Beiträge hier nicht wirklich weiterhelfen. Ich hatte eigentlich nach Tipps gefragt und nicht nach Erklärungen wie b***d ich eigentlich bin.

[blub 115]

Ein Backup liegt vor. Da allerdings nicht bekannt ist seit wann der Fehler auftritt kann es gut sein, dass kein Backup ohne diesen Fehler existiert (5 Backups Mo. - Fr. rotierend).

Oben schreibst du, dass es Einträge im Protokoll gibt. Da steht doch sicher auch ein Datum dabei.

 

Beherrscht du das Backup bzw. den Restore eines DCs? Falls ja, dann führe die Reparatur testweise auf einer netzwerktechnisch abgeschotteten, restorten Maschine durch.

[magheinz 110]

Oder bring schnell einen zweiten DC ins Netz. Mit etwas Glück zieht der sich erst mal die komplette AD sauber rüber.

 

Abgesehen davon:

Bitte hör auf mit irgendwelchen Reparaturversuchen auf deinem einzigen DC rumzuspielen. Was willst du denn machen wenn du kaputtrepariert hast?

[blub 115]

Und mit etwas Pech macht der zweite DC die DB ganz kaputt.

[magheinz 110]

Gesetz dem Fall man kann die Kiste noch gefahrlos neu starten würde ich eh immer nur auf einem Klon arbeiten.

Bleibt die Frage ob man den reboot(abschalten -> klonen -> einschalten) riskieren kann?

 

Am offenen Herzen würde ich möglichst nix machen. Man könnte ja auch mal versuchen die Datenbank offline zu reparieren. Die ist halt im DC immer online, denke ich. Das ist aber alles Bastelei.

 

Das letzte Backup könnte man ja auch mal auf eine separate Maschine restoren. Eventuell ist da ja alles sauber.

[Doso 77]

Oder man ist mutig und repariert am offen Herzen und hofft auf das Backup wenn was schief geht.

[magheinz 110]

Fände ich ok wenn man wenigstens einen Anhaltspunkt hat ob es ein vernünftiges Backup gibt. Hier steht's das ja nicht fest.

 

Ich bin einfach mal froh das es nicht mein DC ist...

[H. Hennig 10]

Hallo,

 

vielen Dank für die Antworten.

Es gibt regelmäßige Komplettsicherungen des betreffenden Servers (Mo. - Fr. mit Backupsoftware komplett, Sa. Windows Serversicherung komplett Bear Metall).

Wir werden eine Windows Serversicherung unter Hyper-V starten und dort die Reparatur durchspielen. Dann können wir immernoch schauen wie wir weiter vorgehen.

Da sich keine Funktionsstörungen am System zeigen könnte das ganze theoretisch auch so weiter laufen. Bei einem Serverwechsel (steht in den nächsten 18 Monaten an) könnte man dann immernoch eine Reparatur probieren oder im schlimmsten Fall die Domäne neu aufsetzen. Da es sich, wie gesagt, um ein kleines Netzwerk handelt (7 Clients) wäre dies sicher auch ein gangbarer Weg.

 

H.H.

[Doso 77]

 

Es gibt regelmäßige Komplettsicherungen des betreffenden Servers (Mo. - Fr. mit Backupsoftware komplett, Sa. Windows Serversicherung komplett Bear Metall).

 

 

SCNR: http://i282.photobucket.com/albums/kk263/Dandanimal99/HMBEAR.jpg :cool:

[NorbertFe 2.062]

:d ich hab schon drauf gewartet, dass jemand was sagt.