Jump to content

Massive AD Probleme nach Neustart d. Server


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!

Leider scheine ich im Moment aus unerfindlichen Gründen ein Massives Problem mit dem AD zu haben.

 

Ich habe einen DC (ohne FSMO) jedoch mit GC neu gestartet. Danach ist mir zu allererst nichts aufgefallen, da es keine Fehlermeldungen gab.

 

Es meldeten sich aber ein paar Leute, dass sie sich nicht mehr anmelden können.

 

Nach Blick in die Ereignisanzeige des neu gestarteten Server gibt es ein paar Einträge mit USERENV, die mir gar nicht gefallen:

 

Ereignistyp: Fehler

Ereignisquelle: Userenv

Ereigniskategorie: Keine

Ereigniskennung: 1058

Datum: 28.12.2010

Zeit: 08:39:15

Benutzer: NT-AUTORITÄT\SYSTEM

Computer: TIME

Beschreibung:

Auf die Datei gpt.ini des Gruppenrichtlinienobjekts CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=gemeinde,DC=domaene,DC=at kann nicht zugegriffen werden. Die Datei muss im Pfad <\\gemeinde.domaene.at\sysvol\gemeinde.domaene.at\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini> vorhanden sein. (Anmeldung fehlgeschlagen: Der Zielkontoname ist ungültig. ). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen.

 

 

Auch sagt mir Replmon, dass andere Server (unter anderem der DC mit allen FSMO und GC) diesem Server den Zugriff bei der Replication verweigern.

 

Sysvol ist auf dem SERVER mit den Fehlermeldungen geshared.

 

 

 

Damit sich die Leute wieder anmelden können hab ich jetzt mal als Primären DNS bei allen Cients die IP des DC mit allen FSMO eingetragen und den Server (TIME) der die Fehlermeldungen ausspuckt bei den Clients als DNS rausgeschmissen.

 

Ich weiß im Moment echt nicht, was ich machen soll und hoffe auf schnelle Hilfe.

 

Macht es Sinn den betroffenen Server manuell aus dem AD zu entfernen? Ich gehe davon aus, dass ein normales DCPROMO auf dem betroffenen Server (TIME) nichts bringt , oder?

 

Danke!

 

LG

Link zu diesem Kommentar

Weshalb wurde der DC neu gestartet?

 

Wurde dieser DC irgendwann in den vergangenen Tagen oder Wochen wiederhergestellt, und zwar aus einer Imagesicherung?

 

Von welchem Betriebssystem der DCs reden wir? (Das ist eine grundsätzliche Information, die Du bitte ohne Nachfrage publizieren solltest.)

 

Wie viele DCs hast Du insgesamt an diesem Standort?

 

Laufen auf dem betroffenen DC andere Dienste wie Netzlaufwerke, WSUS, Exchange Server etc.? (Auch das sind grundsätzliche Informationen.)

Link zu diesem Kommentar

Hey!

Sorry in der Hitze des Gefechtes (Telefon ging über) hab ich wichtige Details weg gelassen. Tut mir leid.

 

Das hier sind 2x 2k3 R2 Server + 1x 2k Server (der aber demnächste in Pension geht). Der Server wurde deshalb neu gestartet, weil ich neue Festplatten installiert habe und ohnehin ein Neustart wg. Windowsupdates durchzuführen war.

 

Die neuen Platten haben allerdings die Windows Serverinstallation nicht betroffen! (waren nur Bilddaten abseits der Windowsinstallation). Es wurden auch keine Laufwerksbuchstaben verschoben.

 

Es wurde kein Image wiederhergestellt, kein Exchange, kein WSUS, jedoch Netzlaufwerke (Freigaben) sind vorhanden und EPO Orchestrator (McAfee / INTEL)

 

Was ich nun gemacht habe und was auch funktioniert hat:

 

Habe die Replikationsverbindungen bei den verbleibenden Servern zu TIME gelöscht. Replikationsverbindungen von TIME ausgehend ebenso entfernt und TIME auch aus AD Standorte und Dienste geschmissen.

Danach TIME selbst über Active Directory Benutzer und Computer gelöscht.

 

Sichergestellt, dass die verbleibenden Server ordnungsgemäß replizieren und auch ein paar Tests mit dcdiag, net dom und replmon durchgeführt.

 

Nachdem das alles ok war, wurde TIME ohne Netzwerkverbindung mit dcpromo /forceremoval aus der Domäne "geschossen" und neu gestartet.

 

Auf dem DC (FSMO Inhaber) nochmals geprüft, ob keine Konten/OU bezogen auf TIME mehr vorhanden sind und den entfernten Server (TIME) wieder ans Netz angeschlossen.

 

Beitritt zur Domäne als Memberserver verlief ohne Probleme. Genau so wie ein darauffolgendes DCPROMO.

 

Es scheint nun wieder alles zu laufen. DNS funktioniert ebenso.

 

Mir ist nur unklar, was hier genau passiert ist. Vielleicht hab ich irgendetwas übersehen? Ich weiß auch nicht, ob mein Weg zu kompliziert war. Jedoch war ich mir bei der Aktion sicher zu wissen was ich tue, ohne mit ADSI EDIT ins AD abtauchen zu müssen :-)

 

LG und Danke!

Link zu diesem Kommentar
Mir ist nur unklar, was hier genau passiert ist. Vielleicht hab ich irgendetwas übersehen?

 

Dein Lösungsweg mit "dcpromo /forceremoval" und anschliessendem neuen Heraufstufen zum Domänencontroller ist pragmatisch und wirksam.

 

Andererseits weisst Du jetzt wahrscheinlich nicht mehr, als dass ein DC nicht mehr als Replikationspartner akzeptiert wurde. Dies wird durch USN-Rollbacks/verwaiste Objekte ausgelöst. Langfristig hätte es Dir möglicherweise mehr geholfen, dies zu diagnostizieren und zu untersuchen.

Link zu diesem Kommentar

Hallo und guten Morgen!

 

Die gute Nachricht ist, dass alles ohne Probleme läuft. Die etwas schlechtere allerdings, dass der DC (alle FSMO) im Eventlog alle paar Stunden folgendes meldet:

 

Ereignistyp: Informationen

Ereignisquelle: NTDS KCC

Ereigniskategorie: Konsistenzprüfung

Ereigniskennung: 1104

Datum: 29.12.2010

Zeit: 06:19:44

Benutzer: NT-AUTORITÄT\ANONYMOUS-ANMELDUNG

Computer: SERVER

Beschreibung:

Die Konsistenzprüfung (KCC) hat die folgenden Änderungsbenachrichtigungen erfolgreich beendet.

 

Verzeichnispartition:

CN=Configuration,DC=gemeinde,DC=domaene,DC=at

Zielnetzwerkadresse:

acd1ab3d-2c14-4916-8142-838eb8f2904d._msdcs.gemeinde.domaene.at

Zieldomänencontroller (falls verfügbar):

CN=NTDS Settings\0ADEL:acd1ab3d-2c14-4916-8142-838eb8f2904d,CN=TIME\0ADEL:230059ce-9afd-4ffb-9a64-b525e0e0ba1f,CN=Servers,CN=Standardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=gemeinde,DC=domaene,DC=at

 

Dieses Ereignis tritt aber nur auf dem DC der alle FSMO hat im Eventlog auf. Alle andren DC melden das nicht im Eventlog.

 

Noch aufgefallen ist mir, dass im Replmon die 2k3 R2 Server folgendes mehr eingetragen haben, wie mein 2K Server:

 

DC=DomainDnsZones,DC=gemeinde,DC=domaene,DC=at

DC=ForestDnsZones,DC=gemeinde,DC=domaene,DC=at

 

Inwieweit dies irgendetwas zu sagen hat, kann ich leider nicht beurteilen?

 

Replmon findet nach wie vor keine Fehler. Mich wundert dieser Eventlogeintrag, da ich ja keinen Server "an einen anderen Standort" verschoben habe.

 

Wenn ich auf dem DC der alle FSMO inne hat, einen User anlege, wird dieser innerhalb von kurzer Zeit auch bei den andren DC im Container User angezeigt. Es scheint also so, als dass die Replikation funktioniert. (das auch nicht zeitverzögert).

 

Wo könnte ich hier ansetzen?

 

LG und Danke!

bearbeitet von mcdaniels
Link zu diesem Kommentar
Noch aufgefallen ist mir, dass im Replmon die 2k3 R2 Server folgendes mehr eingetragen haben, wie mein 2K Server:

 

DC=DomainDnsZones,DC=gemeinde,DC=domaene,DC=at

DC=ForestDnsZones,DC=gemeinde,DC=domaene,DC=at

 

ForestDNSZOnes und DomainDNSZones können von Domänencontrollern mit Windows 2000 Server nicht repliziert werden, da sie erst mit Windows Server 2003 eingeführt wurden:

 

http://www.mcseboard.de/windows-server-forum-78/domaindnszones-forestdnszones-fehlt-dns-probleme-119222.html#post736998

Application Directory Partitions (Windows)

 

Was sagt dcdiag.exe?

Link zu diesem Kommentar

Hallo!

 

DCdiag gibt auf allen DC alle Tests als PASSED aus, keine Fehlermeldungen.

 

Replmon zeigt bei der Replication Topologie / Server Properties / Server Flags an, dass die beiden Server die keine FSMO haben kein Primary Domain Controller sind. Nur der Server der alle FSMO hat, wird hier als Primary Domain Controller angezeigt (Server is a Primary Domain Controller for the Domain). Ist aber auch normal, da ja nur der FSMO Holder ein PDC ist. (AFAIK)

 

Was ich bislang nicht erwähnt habe: Alle Server haben den GC aktiv.

 

Kann mir die Domäne aufgrund dieses "Fehlers" im Eventlog und der damit verbundenen Problematik "köpfeln?" Frage mich gerade wohin "TIME" lt. dem AD verzogen sein soll? :-)

 

LG

Link zu diesem Kommentar
Zieldomänencontroller (falls verfügbar):

CN=NTDS Settings\0ADEL:acd1ab3d-2c14-4916-8142-838eb8f2904d,CN=TIME\0ADEL:230059ce-9afd-4ffb-9a64-b525e0e0ba1f,CN=Servers,CN=Standardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=gemeinde,DC=domaene,DC=at

 

Die Meldung in der Ereignisanzeige weist darauf hin, dass beim Herunterstufen des DCs nicht alle seine Metadaten bereinigt wurden. "0ADEL" bezieht sich auf ein gelöschtes Objekt. In diesem Fall handelt es sich um den Domänencontroller vor dessen Herunterstufung und sein korrespondierendes NTDS Settings-Objekt.

 

Auch wenn der DC nach dem erneuten Heraufstufen den gleichen DN hat, handelt es sich aus Sicht von Active Directory um einen neuen Domänencontroller mit neuer DSA GUID und neuer Invocation ID für die lokale Instanz der AD-Datenbank ntds.dit.

 

Dieses Papier sollte helfen:

 

How to remove data in Active Directory after an unsuccessful domain controller demotion

 

Und noch etwas Hintergrundwissen:

 

Zwei wichtige IDs eines DCs: DC GUID und InvocationId

How the Active Directory Replication Model Works

Link zu diesem Kommentar

Danke für diese Information. Eines was ich in diesem Fall nicht verstehe, das Papier spricht von dem entfernen eines DC + dessen verwaiste Einträge der nicht ordnungsgemäß aus dem AD entfernt wurde.

 

Ich will ja nicht den Server wieder komplett entfernen. Oder, kann man hier auf dieses gelöschte Objekt verweisen?

 

LG

Link zu diesem Kommentar

Servus,

 

Ist aber auch normal, da ja nur der FSMO Holder ein PDC ist. (AFAIK)

 

das stimmt, aber du solltest dich mit dem Schweizer Messer Werkzeug für die AD-Replikation REPADMIN anfreunden. REPLMON existiert ab Windows Server 2008 ohnehin nicht mehr und ist auch nicht notwendig. Die Informationen die einem REPLMON anbietet, sind sehr spärlich. Klar, REPADMIN ist ein Kommandozeilentool ohne GUI, aber wenn man sich damit etwas beschäftigt, kommt man damit schnell klar und lernt es vor allem zu schätzen.

 

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c6054092-ee1e-4b57-b175-5aabde591c5f&displayLang=en

 

Was ich bislang nicht erwähnt habe: Alle Server haben den GC aktiv.

 

Wenn es sich um einen Single-Domain Forest (es existiert nur eine einzige Domäne) handelt, ist der GC für das AD unrelevant.

 

Kann mir die Domäne aufgrund dieses "Fehlers" im Eventlog und der damit verbundenen Problematik "köpfeln?"

 

Ich weiß zwar nicht genau was du mit "köpfeln" meinst, aber trotzdem sage ich dazu ein klares "Nein".

 

Frage mich gerade wohin "TIME" lt. dem AD verzogen sein soll?

 

dmetzger hat's schon geschrieben, er ist noch nicht sauber aus dem AD entfernt. Da solltest du nochmals mit NTDSUTIL Hand anlegen (ab Windows Server 2008 kann man das über die GUI lösen) und insbesondere das DNS kontrollieren.

Link zu diesem Kommentar
Eines was ich in diesem Fall nicht verstehe, das Papier spricht von dem entfernen eines DC + dessen verwaiste Einträge der nicht ordnungsgemäß aus dem AD entfernt wurde.

 

Ja, genau darum geht es. Wenn der DC sauber aus dem AD entfernt worden wäre, würde eben dieser Eintrag nicht erscheinen:

 

CN=NTDS Settings\0ADEL:acd1ab3d-2c14-4916-8142-838eb8f2904d,CN=TIME\0ADEL:230059ce-9afd-4ffb-9a64-b525e0e0ba1f,CN=Servers,CN=Standardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=gemeinde,DC=domaene,DC=at

 

Ich will ja nicht den Server wieder komplett entfernen. Oder, kann man hier auf dieses gelöschte Objekt verweisen?

 

Du sollst auch nicht den aktuellen, sondern den "gewaltsam" entfernten DC komplett aus dem AD löschen. Wenn dir die GUI lieber ist, verbinde dich in ADSIEdit und entsprechenden Rechten mit der Konfigurationspartition und navigiere zu diesem Container:

 

CN=Servers,CN=Standardname-des-ersten-Standorts,CN=Sites,CN=Configuration,DC=gemeinde,DC=domaene,DC=at

 

Überprüfe ob dort das folgende Objekt existiert und falls ja, lösche es: "CN=NTDS Settings\0ADEL:acd1ab3d-2c14-4916-8142-838eb8f2904d,CN=TIME\0ADEL:230059ce-9afd-4ffb-9a64-b525e0e0ba1f".

 

 

Aber wenn du dir bei dem was du da tust nicht sicher bist, hole dir jemanden zur Seite der sich damit auskennt!

Link zu diesem Kommentar

Hallo,

das Problem bei solchen Dingen ist, dass ich eben niemanden habe, der mir zur Seite stehen könnte. Also muss ich das Problem selbst lösen :-).

 

Adsiedit am PDC (FSMO Inhaber)gestartet

Connect mit Naming Context Configuration

Stehe nun bei Configuration[server.gemeinde.domaene.at]

Nach erweitern des + gibt es aber keinen CN=Servers nur CN=DisplaySpecifiers, CN=Extended-Rights, ....

 

Da bin ich dann wohl falsch, obwohl das ja eigentlich die Configuration sein sollte?

LG

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