Whistleblower

Hi Steven,

paralleles Aufsetzen einer neuen Domäne war anfangs auch mein Favorit.

Habe dann allerdings (aufgrund der anschließend notwendigen Wiederherstellung der lokal gespeicherten User-Profile) die erwähnten Versuche unternommen, in die alte Domäne einen zweiten DC zu bekommen.

Grundsätzlich sehe ich auch kein großes Problem in einer neuen Domäne, da wir bis jetzt wirklich nur die Basics des ADS nutzen, sprich zentrale Benutzerverwaltung und einige Richtlinien.

Nur das Übertragen der Profile auf den Clients wird mit einiger Fleißarbeit verbunden sein, und da kenne ich bisher noch keine Lösung, die mir die Arbeit deutlich vereinfacht... :(

Von jedem PC die lokal gespeicherten Profile sichern und nach Umzug in die neue Domäne wieder herstellen wird sicher nicht bei jedem User problemlos funktionieren...

einen DC kann man unter Windows 2000 aber nur dann umbenennen, wenn der DC VORHER heruntergestuft wird. Also DC herutnerstufen, Server umbenennen und anschließend wieder zum DC hochstufen. Die Domäne konnte man unter Windows 2000 auch nicht so einfach umbenennen. Dazu muss man die Domäne neu aufsetzen. Wenn die Domöne aber nur durch einem DC bestand, dann kann man beides in "einem Rutsch" durchführen.

In welcher Form das damals geschah, kann leider keiner mehr nachvollziehen. Bekannt ist nur, das der Server einen anderen Namen hatte und die Domäne ebenfalls anders benannt war. Reste davon fanden sich u.a. noch unter Standorte und tw. im DNS.

Bekannt ist auch noch, dass es bei der späteren Schemaerweiterung für Exchange (bereits zu 2003-Zeiten) diesbezüglich noch Probleme gab. Ein MS-Techniker, der das ganze damals wohl betreute, meinte auch, dass wir wohl immer mit Problemen aufgrund der damaligen Umbenennung rechnen müssten...

Dann führe doch auf beiden DCs das DCDIAG sowie NetDIAG aus den Windows Support Tools aus. Das DNS ist in einer AD-Umgebung elementar, werfe auch darauf einen Blick. Auf dem neuen DC hast du noch den alten DC als primären DNS-Server eingetragen?

Habe ich gemacht, habe auch einiges (im alten Thread) klären können, aber irgendwo muss noch ein Problem bestehen. Ich füge die Ergebnisse gleich nochmal an.

Auf dem neuen DC ist der alte als primäre DNS eingetragen.

Mit Know-How, Zeit und Troubleshooting sicherlich. Ob man das alles selbst kann, ist eine andere Frage. Deine bestehenden Probleme lassen sich auch schwer über ein Forum lösen. Evtl. solltest du über einen Dienstleister nachdenken.

Den Ehrgeiz habe ich (noch) selber - man lernt dadurch besser als durch ausschalten und neuaufsetzen :D

MCSA/MCSE steht als Fernziel bei mir ja auch noch auf dem Plan...

Dienstleister kommt nicht in Frage, evtl. werde ich direkt auf Microsoft zurückgreifen, wenn alle Stricke reissen. Ist ja nicht so, dass der Betrieb momentan eingeschränkt wär - aber zu dem Thema kämen wir bei Ausfall des DCs... :(

Hi,

schlage mich schon seit längerem mit einem scheinbar inkonsistenten ADS auf einem Server2003 DC herum.

Mittlerweile weiss ich mehr über die Vorgeschichte des Server und somit über die potentiellen Ursachen des Problems.

Der Server läuft aktuell mit Server2003 Std, war früher aber ein 2000 Server.

Zu 2000-Zeiten hat mein Vorgänger sowohl Server als auch Domäne umbenannt.

Jetzt konnte ich der Domäne zwar einen weiteren DC hinzufügen, aber nicht erfolgreich alle Rollen übertragen, außerdem kann ich den neu hinzugefügen DC nicht wieder herunterstufen. Laut Ereignisprotokoll antwortet (u.a.) wohl der RPC-Dienst auf dem alten DC nicht.

Der komplette thread zu dem Thema findet sich schon hier.

Meine Frage ist jetzt, ob es überhaupt noch eine Möglichkeit gibt, den Server soweit gerade zu ziehen, dass ein neuer DC mit dem aktuellen Domänennamen in Betrieb gehen kann.

Ich investiere gerne noch etwas Gehirnschmalz in die Fehlersuche und -behebung statt gleich eine neue Domäne parallel aufzuziehen, aber wenn die Chancen eh gegen null gehen, wird wohl kein Weg daran vorbeiführen... :(

Bin für jeden Tipp dankbar !!!

Hallo zusammen und ein Frohes Neues!

Ich habe noch einmal in der Historie zu dem alten Domänencontroller geforscht und dabei folgendes herausgefunden:

- Ursprünglich war es mal ein Windows2000 Server

- Der Server wurde (damals bereits ein DC) zu Server2000-Zeiten umbenannt (!)

- Später wurde der Server auf Server 2003 hochgezogen

- Die Domäne wurde umbenannt, allerdings weiss ich nicht, ob zu Server2000 oder Server2003 Zeiten ...

Damit haben wir jetzt wohl auch die Ursache für die aktuellen Probleme. Laut Historie gab es wohl bereits früher bei der Schema-Erweiterung für Exchange Probleme, die auf der Umbenennung des Servers und der Domäne basieren.

Jetzt stellt sich die Frage: Lassen sich die Probleme noch beheben, oder macht es mehr Sinn, eine neue Domäne hochzuziehen? Wenn letzteres - mit welchen Tools bekomme ich mit möglichst wenig Zeitaufwand die (lokal gespeicherten) Profile auf den Clients wieder in die neue Domäne?

Bin für jeden Tipp dankbar !!! :) :) :)

Herunterstufen ist aktuell nicht das Ziel. Erstmal wollte ich sicherstellen, dass der zweite DC alle FSMO-Rollen übernehmen kann. Aber da nicht einmal die Replikation funktioniert, muss ich erstmal die Probleme vom alten DC lösen... :rolleyes:

Ooops, grad gemerkt, dass mein Thread hier etwas durcheinander gerät...

Die letzten zwei Ereignisse 13519 und 4149 habe ich auf dem ersten (aktiven) DC...

Na, das beruhigt mich ja... Aber irgendwo steckt noch ein Fehler in der Kiste, dass der RPC-Server nicht ansprechbar ist.

Eine Weitere Fehlermeldung habe ich auch noch vom Indexdienst:

Ereignistyp:	Warnung
Ereignisquelle:	Ci
Ereigniskategorie:	CI-Dienst 
Ereigniskennung:	4149
Datum:		18.12.2008
Zeit:		13:26:51
Benutzer:		Nicht zutreffend
Computer:	xxx
Beschreibung:
Das Lesen des USN-Protokolls für den NTFS-Datenträger c: ist mit Fehlercode 0xC000003E fehlgeschlagen. Der Datenträger wird solange offline bleiben bis der Indexdienst (cisvc) neu gestartet wurde.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Die Meldung erscheint auch beim Neustarten des Indexdienstes. Evtl. liegt da irgendwo das Problem begraben?

Hm, merkwürdig, in der Ereignisanzeige steht nach einem Reboot auch folgende Meldung:

Ereignistyp:	Informationen
Ereignisquelle:	NtFrs
Ereigniskategorie:	Keine
Ereigniskennung:	13516
Datum:		17.12.2008
Zeit:		21:48:02
Benutzer:		Nicht zutreffend
Computer:	xxx
Beschreibung:
Der Dateireplikationsdienst verhindert nicht mehr die Heraufstufung des Computers "xxx" zum Domänencontroller. Der Systemdatenträger wurde erfolgreich initialisiert. Der Anmeldedienst wurde benachrichtigt, dass der Systemdatenträger jetzt als SYSVOL freigegeben werden kann. 

Geben Sie "net share" ein, um die SYSVOL-Freigabe zu überprüfen.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Der Fehler tritt auf dem ersten DC auf, der ja eigentlich schon der Haupt-DC ist (sein sollte) ?

Kann man das Problem noch irgendwie beheben, ohne sich das ADS komplett zu zerschießen?

Das ist ja das Problem... Der Server wurde vor einigen Wochen zum DC heraufgestuft. FSMO-Rollen wurden noch keine übertragen. Heute mal ins Log geschaut und festgestellt, dass es noch diverse Probleme mit der Replikation gibt. Das Heraufstufen hatte damals problemlos geklappt, aber scheinbar ja doch noch nicht...

Muss mal sehen, ob ich heute abend mal einen Reboot machen kann...

Den RPC-Dienst kann ich aber nicht direkt neu starten, da über das Network Services-Konto gestartet wird.

Er befindet sich aktuell auch im Status "gestartet".

Ein Reboot kommt z.Zt. leider nicht in Frage, daher suche ich nach Möglichkeiten, den Dienst anderweitig wieder ansprechbar zu machen...

Hallo,

beim Versuch, einen DC (der vorletzte in der Domäne) herunterzustufen bekomme ich folgenden Fehler:

Ereignistyp:	Fehler
Ereignisquelle:	NTDS Replication
Ereigniskategorie:	Replikation 
Ereigniskennung:	2023
Datum:		17.12.2008
Zeit:		15:03:11
Benutzer:		NT-AUTORITÄT\ANONYMOUS-ANMELDUNG
Computer:	DC002
Beschreibung:
Der lokale Domänencontroller konnte Änderungen für die folgende Verzeichnispartition nicht auf den folgenden Remotedomänencontroller replizieren. 

Remotedomänencontroller:
2c80c960-b607-4f76-8365-4f35cab3241e._msdcs.domain.local 
Verzeichnispartition:
CN=Schema,CN=Configuration,DC=domain,DC=local

Der lokale Domänencontroller kann die Herabstufung nicht abschließen.  

Benutzeraktion 
Untersuchen Sie, warum die Replikation zwischen diesen beiden Domänencontrollern nicht durchgeführt werden kann. Versuchen Sie dann erneut, diesen Domänencontroller herabzustufen. 

Zusätzliche Daten 
Fehlerwert:
1722 Der RPC-Server ist nicht verfügbar.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Kennt jemand dieses Problem? Der RPC-Dienst an sich ist gestartet.

Täglich habe ich noch die folgende Fehlermeldung:

Ereignistyp:	Fehler
Ereignisquelle:	NTDS Replication
Ereigniskategorie:	Replikation 
Ereigniskennung:	1864
Datum:		17.12.2008
Zeit:		04:09:00
Benutzer:		NT-AUTORITÄT\ANONYMOUS-ANMELDUNG
Computer:	xxxxxx
Beschreibung:
Der Replikationsstatus für die folgende Verzeichnispartition des lokalen Domänencontrollers ist wie folgt. 

Verzeichnispartition:
CN=Schema,CN=Configuration,DC=xxx,DC=xxx
n
Der lokale Domänencontroller hat in jüngster Zeit von einer bestimmten Anzahl an Domäncontrollern keine Replikationsinformationen mehr erhalten. Die Anzahl an Domänencontrollern wird unterteilt in die folgenden Intervalle gezeigt. n

Länger als 24 Stunden:
1 
Länger als eine Woche:
1 
Länger als einen Monat:
0 
Länger als zwei Monate:
0 
Längerals die Tombstone-Ablaufzeit:
0 
Tombstone-Ablaufzeit (in Tagen):
60 
Bei Domänencontrollern, die nicht rechtzeitig repliziert werden, können Fehler auftreten. Ihnen können Kennwortänderungen entgehen, und sie können daher ggf. nicht in authentifiziert werden. Einem Domänencontroller, der innerhalb der Tobstone-Ablaufzeit nicht repliziert wurde, kann das Löschen von Objekten entgehen, und er wird ggf. für die zukünftige Replikation gesperrt, bis er wieder abgestimmt wurde. 

Installieren Sie die Supporttools von der Installations-CD und führen Sie dcdiag.exe aus, um Domänencontroller anhand des Namens zu identifizieren. 
Sie können auch das Supporttool repadmin.exe verwenden, um Replikations- latenzzeiten der Domänencontroller in der Struktur anzuzeigen. Der Befehl lautet "repadmin /showvector /latency <partition-dn>".


Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Ebenfalls täglich Probleme bei der Replikation:

Ereignistyp:	Warnung
Ereignisquelle:	NtFrs
Ereigniskategorie:	Keine
Ereigniskennung:	13508
Datum:		17.12.2008
Zeit:		06:45:56
Benutzer:		Nicht zutreffend
Computer:	xxxx
Beschreibung:
Der Dateireplikationsdienst konnte die Replikation von xxx nach xxx für c:\windows\sysvol\domain mit DNS-Namen xxx.xxx.xxx nicht aktivieren. Es wird ein neuer Versuch gestartet. 
Mögliche Ursachen für diese Warnung sind: 

[1] Der DNS-Name xxx.xxx.xxx von diesem Computer konnte nicht ausgewertet werden. 
[2] Der Dateireplikationsdienst wird auf xxx.xxx.xxx nicht ausgeführt. 
[3] Die Topologieinformationen im Active Directory dieses Replikats wurden noch nicht auf allen Domänencontrollern repliziert. 

Diese Ereignisprotokollmeldung wird einmal pro Verbindung angezeigt. Nachdem der Fehler behoben wurde, wird eine andere Ereignisprotokollmeldung angezeigt, die bestätigt, dass die Verbindung hergestellt wurde.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Daten:
0000: ba 06 00 00               º...    

Hm, evtl. ein Problem der Domänenfunktionsebene? Der alte DC ist noch auf 2000 gemischt eingestellt. Nach Übertragen der Rollen soll es eine reine Server 2003 Domäne sein. Mach ich die Hochstufung besser vor oder nach Übertragen der Rollen??

UPDATE:

Evtl. noch interessant: Fehler dcdiag auf dem alten Server:

 The replication generated an error (1722):
 Der RPC-Server ist nicht verfügbar.

Sorry, muss den Thread nochmal auf den aktuellsten Stand bringen... Irgendwas läuft immer noch unrund im ADS.

Ein zweiter DC ist jetzt zusätzlich im Betrieb (gleicher Standort), FSMO-Rollen wurden bisher noch nicht übertragen, läuft alles noch auf dem alten DC.

Habe jetzt mal wieder einen Blick ins Ereignisprotokoll geworfen und immer noch folgende Fehler auf dem "alten" DC:

Ereignistyp:	Fehler
Ereignisquelle:	CertSvc
Ereigniskategorie:	Keine
Ereigniskennung:	44
Datum:		12.12.2008
Zeit:		03:09:50
Benutzer:		Nicht zutreffend
Computer:	xxxx
Beschreibung:
Richtlinienmodul "Windows-Standard", Methode "Initialize", hat einen Fehler verursacht. Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. Zurückgegebener Statuscode: 0x8007054b (1355). Es konnte keine Verbindung mit dem Active Directory, das die Zertifizierungsstelle enthält, hergestellt werden.


Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Diese Fehlermeldung trat allerdings nur einmal vor 5 Tagen auf. Vorgehendes Ereignis:

Ereignistyp:	Warnung
Ereignisquelle:	CertSvc
Ereigniskategorie:	Keine
Ereigniskennung:	94
Datum:		12.12.2008
Zeit:		03:09:50
Benutzer:		Nicht zutreffend
Computer:	xxxxxx
Beschreibung:
Die Zertifikatdienste xxxxxxxxxxxx können den Zertifikatspeicher unter CN=NTAuthCertificates,CN=Public Key Services,CN=Services im Konfigurationscontainer von Active Directory nicht öffnen.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Vorher wurde der Zertifikatsspeicher (automatisch) wiederhergestellt, und ich vermute, dass der Server zu dem Zeitpunkt (ca. 3:00 Uhr) rebootet hat.

Ein DNS-Problem gab es zu dem Zeitpunkt ebenfalls:

Ereignistyp:	Fehler
Ereignisquelle:	DNS
Ereigniskategorie:	Keine
Ereigniskennung:	4015
Datum:		12.12.2008
Zeit:		03:05:29
Benutzer:		Nicht zutreffend
Computer:	xxx
Beschreibung:
DNS-Server hat einen kritischen Fehler im Active Directory ermittelt. Stellen Sie sicher, dass das Active Directory ordnungsgemäß funktioniert. Die erweitere Fehlerdebuginformation (die eventuell leer ist), ist "". Die Ereignisdaten enthalten den Fehlercode.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
Daten:
0000: 51 00 00 00               Q...    

dcpromo hat soweit erstmal funktioniert... Befasse mich jetzt erstmal mit anderen Installationen, bevor ich dann später mal den Betriebsmaster und glob. Katalog umziehe

das sind aber viele Weiterleitungen, kann das sein? Wo genau hast du die eingetragen, vielleicht einen Screenshot der Maske?

Kann ich leider nicht einfügen, mangels Webspace...

Sind die drei zugeteilten DNS des Providers, stehen unter Weiterleitungen für "Alle anderen DNS-Domänen"

Zur Sicherheit würde ich aber noch mal prüfen wie diese Weitergeleitet sind, oder falls vorhanden, deinen Router nehmen. Die haben ja auch meistens einen DNS Server, und leiten diesen dann wiederum zum Server, was den Vorteil hat, das die Server vom Provider ja schon mal anders sein können, die bekomm man (Vorrausgesetzt ein Dial-IN Account oder ähnlich) dann ja dynamisch.

Entfällt leider, da der Router kein DNS machen soll.

Aber Funktioniell, wenn deine DNS Server beim Provider mittels nslookup korrekt funtkionieren, und die Weiterleitung korrekt eingetragen ist, macht ads kein Problem:

 

nslookup DNS_NAME EXPLIZITER_DNS_SERVER

 

Wenn heir drauf geantwortet wird, dann sind das acuh Server die man für eine Weiterleitung nutzen kann

Das funktioniert soweit ohne Probleme

Nein, die Root-Server laufen sauber. Es handelt sich nur noch um die Weiterleitungen auf die DNS-Server unseres Providers, die er (aus welchem Grund auch immer) anmeckert. Ich vermute mal, dass es trivial ist, aber den Grund würde ich trotzdem gerne wissen...:suspect:

dcpromo lief bisher noch nicht (das letzte Mal anno 2005, das war vor meiner Zeit). Ich bereite den neuen DC und den zweiten DC für den anderen Standort aber auch schon soweit vor .

Das er keine Anmeldungen mehr haben wollte ist klar, aber warum wurde dann der 2. nicht mehr gefragt? Dazu sind doch mehrere DCs da. Und wenn es nur einen gibt, dann sollte eine replizierung doch gar nicht da sein, oder habe ich hier gerade einen Gedankenfehler?

Es ist ja kein zweiter DC vorhanden... Jedenfalls noch nicht...

Wie er sich mit sich selbst replizieren wollte, habe ich auch nicht ganz verstanden, aber vielleicht hat ja schon jemand anderes diese Erfahrung mal gemacht.

Key? Du meinst den Regeintrag? Also ist nun wieder alles im Lot, und dein Ursprüngliches Problem das die Domain und das AD strubelig sind sind erledigt?

Dann kannst du nun ja mit dem Austausch der DCs anfangen, oder?

Wie gesagt, noch das kleine Problem mit den DNS des Providers, ansonsten siehts gut aus.

dcdiag und netdiag sind nun auch der Meinung das alles perfekt ist?

Netdiag sieht soweit gut aus, nur ein Warning:

NetBT name test. . . . . . : Passed
           NetBT_Tcpip_{D6E02AFC-30ED-42DA-BB29-94E20FD306EC}
           FS02           <00>  UNIQUE      REGISTERED
           TEC            <00>  GROUP       REGISTERED
           TEC            <1C>  GROUP       REGISTERED
           FS02           <20>  UNIQUE      REGISTERED
           TEC            <1B>  UNIQUE      REGISTERED
           TEC            <1E>  GROUP       REGISTERED
           TEC            <1D>  UNIQUE      REGISTERED
           ..__MSBROWSE__.<01>  GROUP       REGISTERED
       [WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.

dcdiag schmeisst immer noch Fehler für die Provider-DNS aus:

TEST: Forwarders/Root hints (Forw)
Recursion is enabled
Forwarders Information: 
194.25.2.129 (<name unavailable>) [invalid (unreachable)] 
212.59.54.180 (<name unavailable>) [invalid] 
81.14.243.9 (<name unavailable>) [invalid] 
81.14.244.9 (<name unavailable>) [invalid] 

Okay, der Telekom-DNS ist noch ein alter Eintrag, den sollte ich nochmal rauslöschen. Die anderen sind aber erreichbar, und ich bekomme auch deren Namen.

        Summary of test results for DNS servers used by the above domain controllers:

           DNS server: 194.25.2.129 (<name unavailable>)
              1 test failure on this DNS server
              This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 194.25.2.129
              [Error details: 1460 (Type: Win32 - Description: Dieser Vorgang wurde wegen Zeitüberschreitung zurückgegeben.)]

           DNS server: 212.59.54.180 (<name unavailable>)
              1 test failure on this DNS server
              This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 212.59.54.180
              [Error details: 9003 (Type: Win32 - Description: Der DNS-Name ist nicht vorhanden.)]

           DNS server: 81.14.243.9 (<name unavailable>)
              1 test failure on this DNS server
              This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 81.14.243.9
              [Error details: 9003 (Type: Win32 - Description: Der DNS-Name ist nicht vorhanden.)]

           DNS server: 81.14.244.9 (<name unavailable>)
              1 test failure on this DNS server
              This is not a valid DNS server. PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 81.14.244.9
              [Error details: 9003 (Type: Win32 - Description: Der DNS-Name ist nicht vorhanden.)]

           DNS server: 10.10.1.3 (domcon.firma.lokal.)
              All tests passed on this DNS server
              This is a valid DNS server. 
              Name resolution is funtional. _ldap._tcp SRV record for the forest root domain is registered 
              Delegation to the domain _msdcs.firma.lokal. is operational

Also wie oben zu lesen ist in den Fehlermeldungen macht es nach wie vor den Anschein das er Namensauflösungen nicht so korrekt hinbekommt. Das ist alles ein bisschen mergwürdig.

 

Ansonsten auch noch mal nach den Fehlermeldungen Googlen. Aber ich denke das zumindest das mir den Sicherheitsrichtlinien daran liegen kann. Und was hat er nach den 5 Minuten die oben angekündigt wurden nun gesagt?

Gruß

Das war scheinbar ein ganz anderes Problem... Die Journaleinträge waren wohl nicht mehr ganz sauber, dadurch hat er (aufgrund dieses veralteten Registry-Eintrags) eine Replizierung versucht, was wohl etas nach hinten losging. Danach war erstmal keine Anmeldung mehr an der Domäne möglich, weil er durch die noch andauernde Replizierung keinen gültigen DC mehr hatte. Die Fehlermeldungen kamen regelmäßig im 5 Minutentakt, bis ich durch Ändern des Keys und anschließenden Reboot die Replizierung abgebrochen habe. Danach ist ist der DC wieder sauber hochgefahren, und hat auch später erfolgreich seine Replikation gestartet und abgeschlossen.

Das Replizierungsproblem lag übrigens an einem Eintrag aus alten Server2000-Zeiten in der Registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters
Enable Journal Wrap Automatic Restore = 1

Wird ja bereits seit 2000 SP3 nicht mehr von Microsoft empfohlen... Beheben von Journalumbruch-Fehlern auf Sysvol- und DFS-Replikatsätzen

Soviel zu dem Alter dieses DCs... :D

Evtl. das hier?

 

"Ipconfig /All" Command Shows the Node Type as Unknown

Hm, danke, guter Hinweis! Der Wert stand auf "2", aber nur 0 oder 1 möglich... Muss ich nach einem Reboot heute abend mal checken, ob das der Fehler war!

–

Wär ja auch zu schön gewesen, wenn alles glattlaufen würde... :(

Aktuell ist keine Anmeldung mehr an der Domäne möglich, Ereigniskennung 1006, 1030 und 1054:

Es konnte keine Bindung mit der Domäne tec.wtg hergestellt werden. (Lokaler Fehler). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.

Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Überprüfen Sie das Ereignisprotokoll auf frühere Fehlermeldungen des Richtlinienmoduls, die die Ursache für dieses Problem beschreiben.

Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.

Desweiteren hat sich der DC wohl selbst repliziert (oder ist noch dabei)...

Ereignis 13561:

Dieser Computer wird vom Dateireplikationsdienst aus dem Replikatsatz "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" gelöscht, um den Fehlerstatus zu beheben. 
Fehlerstatus = FrsErrorSuccess 
Beim nächsten Poll, der in 5 Minuten stattfindet, wird der Computer dem Replikatsatz wieder hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst.

Abwarten oder lieber gleich Sicherung von gestern wiederherstellen? :confused:

UPDATE:

Problem gelöst, DC läuft soweit wieder.

Ebenfalls gelöst: Knotentyp ist jetzt hybrid (nach Reboot)

Ob das da korrekt ist weiß ich nicht. Kann man ja nachsehen. Aber das ist Standard wenn man einen WINS angibt. Und da es bei ipconfig /all normal auch angezeigt wird, das bei Dir nicht der Fall ist, habe ich es mal angesprochen. Vielleicht weiß da jemand mehr.

 

Mein XP System zeig folgendes:

 

Knotentyp . . . . . . . . . . . . : Hybrid

Wie kann ich denn diesen Fehler beheben? Bzw. was könnte noch die Ursache dafür sein? Evtl. noch Leichen in der Registry? Zur Historie noch einmal: Urspünglich war der DC mal ein physikalischer Server, wurde später über den VMWare Converter in einen VMWare Server 1.0x Guest umgewandelt und vor einigen Monaten in einen ESX (3i) Guest erneut umgewandelt. Die alte VMWare NIC habe ich ja soweit schon aus der Registry entfernt. Kann jemand evtl. noch ein Tool empfehlen, was sicher (!) evtl. Leichen aus der Registry raushaut?

–

Mh, das ist aber wieder komisch, hast du den DNS Server vom Provider denn irgendwo stehen? Also es sollten die internen nur die Bekannten Zonen haben, und für alle anderen Zonen einen oder mehrere vom Provider fragen. Aber nicht für deine Zonen.

 

Kann es sein das Du die Reverse Zone nicht eingetragen hast auf allen DNS Server, und er deswegen die Rootserver bzw. die Öffentlichen danach befragt?

 

Kontrolliere das noch mal.

Hm, für die bekannten internen Netze (10.x.0.0, 10.y.0.0, 10.z.0.0 ...) sind die Reverse Zonen da.

Muss ich da noch zusätzlich Eintragungen vornehmen?

"nicht Notwendig", kann man hier doch auch besser mit "nicht zu empfehlen" gleichsetzen, oder?

Würde ich jetzt auch so verstehen. Wenn der alte DC soweit sauber läuft, sehe ich auch keinen Grund mehr für eine Umbennenung

Wenn, dann baue eine Vertrauensstellung zw. beiden auf und migriere alles via ADMT.

Dabei ist aber ein andere Name als der jetzige zu bevorzugen. Dann klappts auch mit den Profilen.

Welchen Namen meinst Du jetzt mit "der jetzige"? Den alten, oder den vom neuen System? Bin etwas verwirrt... :confused: Würde jetzt bei "firma.lokal" bleiben...

–

Wo genau hast du die DNS-Server des Providers eingetragen?

Die stehen unter den Weiterleitungen für alle anderen Domänen.

Was genau war da bitte, und was hast Du korregiert. Kann Dir gerade nicht folgen.

Ein Eintrag (l.root-servers.net) war veraltet (IP-Adresse hat sich geändert, siehe Root Server Technical Operations Assn).

Ob das da korrekt ist weiß ich nicht. Kann man ja nachsehen. Aber das ist Standard wenn man einen WINS angibt. Und da es bei ipconfig /all normal auch angezeigt wird, das bei Dir nicht der Fall ist, habe ich es mal angesprochen. Vielleicht weiß da jemand mehr.

 

Mein XP System zeig folgendes:

 

Knotentyp . . . . . . . . . . . . : Hybrid

Sieht bei meinem XP genauso aus. Ist auf dem DC aber auch nach Reboot noch "unbekannt".

Eines hat der Reboot aber gebracht, die Root-Server werden jetzt nicht mehr angemeckert.

Einzige DNS-Fehler sind jetzt noch die eingetragenen DNS des Providers, das sieht dann so aus:

DNS server: 212.59.54.180 (<name unavailable>)
1 test failure on this DNS server
This is not a valid DNS server. PTR record query for the 1.0.0.12
7.in-addr.arpa. failed on the DNS server 212.59.54.180
[Error details: 9003 (Type: Win32 - Description: Der DNS-Name ist
nicht vorhanden.)]

netdiag und dnslint laufen soweit ohne Fehler durch... Nur dcdiag meckert noch über die Root-Server (ein Eintrag war veraltet, habe ich schon korrigiert).

Der Knotentyp sollte eigentlich auch korrekt ausgegeben werden, in der Registry steht er korrekt als 0x8 unter "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters" drin...

Ist übrigens eine virtuelle Maschine, es war auch noch ein alter Eintrag eines anderen VM-Nic Adapters drin, habe ich entfernt.

Evtl. behebt ein Reboot noch letzte Fehler, kann ich nur grad nicht testen...