kosta88
-
Gesamte Inhalte
478 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von kosta88
-
-
Zugegeben, es ist schon sehr kompliziert, aber positiv gesehen, funktioniert jetzt scheinbar schon alles...
-
Weitere Fehler nach dem Neustart (Analyse am RZ-DC):
##
Der DFS-Replikationsdienst beendet die Kommunikation mit Partner S02 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
Weitere Informationen:
Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.)
Verbindungs-ID: 6F67EEEB-2412-4A98-BB70-24D221336A60
Replikationsgruppen-ID: E16379D9-90D8-4D50-A0CD-71718A2A3186##
Der DFS-Replikationsdienst beendet die Kommunikation mit Partner ZAUBERKISTE für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
Weitere Informationen:
Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.)
Verbindungs-ID: 57274992-2AFB-4C45-BD66-D159D192A886
Replikationsgruppen-ID: E16379D9-90D8-4D50-A0CD-71718A2A3186##
Wieder:
Der DNS-Server hat einen kritischen Active Directory-Fehler ermittelt. Stellen Sie sicher, dass Active Directory ordnungsgemäß funktioniert. Die erweiterten Fehlerdebuginformationen (die eventuell leer sind) lauten "". Die Ereignisdaten enthalten den Fehlercode.
##
Zeitüberschreitung bei der Namensauflösung für den Namen _ldap._tcp.dc._msdcs.domain.local., nachdem keiner der konfigurierten DNS-Server geantwortet hat.
##
Die folgenden SPNs konnten vom WinRM-Dienst nicht erstellt werden: WSMAN/RZ-DC.domain.local; WSMAN/RZ-DC.
Zusätzliche Daten
Empfangener Fehler: 8344: %%8344.
Benutzeraktion
Die SPNs können von einem Administrator mithilfe des Hilfsprogramms "setspn.exe" erstellt werden.##
repadmin /replsummary schaut auch grausig aus:
Zeigt NUR Ziel-DSA, kein Quell-DSA.
##
Aber zum Positiven:
Nach paar Minuten jetzt erscheinen die o.g. DNS Einträge auf dem S02 und ZAUBERKISTE.
Keine laufenden Fehler am RZ-DC.
Welche der Diskussionen ist denn jetzt die aktuelle?
Für hier: liegt am NAT
Hier ist alles aktuell.
OK Status jetzt, 09:56:
repadmin /replsummary OK
eventvwr zeigt keine Replikation oder DNS bezogene Fehler
pings funktionieren
Test mit Änderung der Beschreibung geht jetzt innerhalb von 30sec
Warum domain.local Einträge gefehlt haben... weiß ich nicht. Aber sind jetzt vorhanden und statisch.
S02 verweis auf 10.241.56.131 ist aber wieder verschwunden. Ich frage mich jetzt auch warum dieser immer wieder weg ist.
UPDATE 10:32:
Jetzt wieder diese Meldung:
##
Der DFS-Replikationsdienst beendet die Kommunikation mit Partner S02 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
Weitere Informationen:
Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.)
Verbindungs-ID: 6F67EEEB-2412-4A98-BB70-24D221336A60
Replikationsgruppen-ID: E16379D9-90D8-4D50-A0CD-71718A2A3186##Der DFS-Replikationsdienst beendet die Kommunikation mit Partner ZAUBERKISTE für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
Weitere Informationen:
Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.)
Verbindungs-ID: 57274992-2AFB-4C45-BD66-D159D192A886
Replikationsgruppen-ID: E16379D9-90D8-4D50-A0CD-71718A2A3186##
Ebenso auf dem S02:
Der DFS-Replikationsdienst beendet die Kommunikation mit Partner RZ-DC für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
Weitere Informationen:
Fehler: 1726 (Der Remoteprozeduraufruf ist fehlgeschlagen.)
Verbindungs-ID: 943AD73F-B6F6-4622-B43D-6250A2DDC8E8
Replikationsgruppen-ID: E16379D9-90D8-4D50-A0CD-71718A2A3186##
Aber glaube nicht dass das ein Problem ist. Es ist nur eine Warnung und dann das:
Ich starte die Server nochmal einen nach dem anderen langsam neu und lasse das ganze dann laufen.
-
Probleme.
Die Replizierung dauert zu lang für meinen Geschmack. Von S02 -> ZAUBERKISTE dauerte schon ne Weile, also gefühlte 1-2 Minuten bis der Rechnername und Beschreibung aktualisiert wurde. Jedoch OK...
Aber auf RZ-DC kommt nix an, da kommen auch viele DNS Fehler:
Der DNS-Server hat einen kritischen Active Directory-Fehler ermittelt. Stellen Sie sicher, dass Active Directory ordnungsgemäß funktioniert. Die erweiterten Fehlerdebuginformationen (die eventuell leer sind) lauten "". Die Ereignisdaten enthalten den Fehlercode.
IPCONFIG auf allen Servern sieht derzeit so aus:
S02:
IP 10.146.32.131/24
GW 10.146.32.254
DNS1: 10.146.32.131
ZAUBERKISTE:
IP 10.146.32.145/24
GW 10.146.32.254
DNS1: 10.146.32.145
RZ-DC:
IP 10.225.159.1/24
GW 10.225.159.250
DNS1: 10.241.56.131
DNS2: 10.225.159.1
Auf RZ-DC:
ping domain.local -> NEIN. (Verweis auf das 10.146.32.0 Netz)
ping S02 -> NEIN. (Verweis auf das 10.146.32.0 Netz)
ping ZAUBERKISTE -> NEIN. (Verweis auf das 10.146.32.0 Netz)
ping 10.241.56.131 -> JA.
Im DNS fehlen lauta Einträge. Die hatte ich aber zuletzt gemacht.
Hääää? Warum?
Und jetzt frage ich mich stark, warum das gestern am Abend noch funktioniert hat. Habe extra die Server neugestartet um sicher zu stellen dass alle Caches gelöscht sind.
Und jetzt EDIT:
Habe folgendes gemacht:
Entsprechende PTR gelöscht
domain.local A-Record 10.241.56.131 gelöscht und nochmals erstellt
S02 A-Record gelöscht und wieder erstellt
ZAUBERKISTE A-Record gelöscht und wieder erstellt
DNS Cache gelöscht und DNS neugestartet
Ereignisanzeige zeigt jetzt keine laufenden DNS-Server-Service Fehler mehr. Vorher waren sie jede 5 Minuten, jetzt ist seit 18 Minuten Ruhe.
dcdiag /q zeigt viele Fehler, aber soweit ich sehe, das ist die Analyse der Ereignisanzeige, Einträge noch vor 1 Stunde.
Jetzt funktioniert zwar das pingen des S02 und domain.local, es kommt auch die richtige IP zurück, aber es findet (noch) keine Replikation statt - die neuen DNS Einträge sind auf anderen Servern noch nicht eingetragen.
Vielleicht dauert es ja...? Ich habe jetzt mal alle Server wieder neugestartet. Mal sehen.
-
Ich muss nochmals fragen, was ist DC1, was ist DC2? Sind das beides DC im LAN, im 32?
Das sind nur Beispiele, keine spezifischen Namen. Ist nur ein Beispiel, und Frage an dich, welche DNS man in Netzwerkeinstellungen eintragen soll?
Das wäre, in meinem Beispiel von S02 und ZAUBERKISTE:
S02:
1.DNS: S02
2.DNS: ZAUBERKISTE
ZAUBERKISTE:
1.DNS: ZAUBERKISTE
2.DNS: S02
Jedoch ist derzeit so konfiguriert:
S02:
1.DNS: S02
2.DNS: leer
ZAUBERKISTE:
1.DNS: ZAUBERKISTE
2.DNS: leer
RZ-DC:
1.DNS: S02 (genatet)
2.DNS: RZ-DC
3.DNS: voraussichtlich das benötigte RZ-DNS
-
2 Stunden später: keine Fehler mehr in dcdiag /q. Auf keinem der 3 Server.
Konfiguration in RZ-DC:
1.DNS: 10.241.56.131 (lokal DC)
2.DNS: 10.225.159.1 (RZ-DC)
Die lokalen DCs haben DNS sich selbst und nichts anderes.
-
Okay, also... habe jetzt folgende Einstellung im RZ:
1.DNS: 10.241.56.131 (S02 genatet)
2.DNS: localhost
3.DNS: voraussichtlich RZ-DNS (RZ-eigen)
Keine sonstigen Einstellungen, Registry-Einträge oder DNS-Einträge.
Es funktioniert.
Es irritiert mich allerdings dass ich ZWINGEND den S02 als 1.DNS in RZ-DC Netzwerkeinstellungen eintragen muss. Wenn ich ihm als 2.DNS eintrage, geht schon nichts mehr: ping an domain.local geht nicht mehr, Replikation scheitert usw. Und das sollte eben nicht sein.
Gibt es Fehlermeldungen in den Ereignisanzeigen der DCs?
Ich muss es länger in jetziger Konfiguration laufen lassen um Fehler via eventvwr verlässlich ansehen zu können. Bisher gab es einige ja, aber es wurde auch permanent umgestellt.
Stellen die Ergebnisse von dcdiag zufrieden?Das einzige was jetzt noch aufschlägt (Test auf dem RZ-DC ausgeführt):
Wird das AD, Änderungen dessen repliziert von einem DC im LAN zum DC im RZ und auch umgekehrt?Scheint so. Auch AD Replication Status Tool meldet keine Fehler (es werden auch alle 3 Server getestet).
Sind die DNS der DC tatsächlich AD-integrierte?Ja, schon. _msdcs Subdomäne ist vorhanden, wird delegiert an die parent zone, und sowohl bei der _msdcs wie auch bei der domain.local Domäne ist das Häkchen gestzt (bzw. wird auch in FLZ und RLZ als Typ angezeigt).
-
Dachte ich mir dass das reicht. Besten Dank für die Info, lefg.
-
Entschuldige meine offensichtlich unklare Ausdruckweise: mit primärer DNS war für mich klar dass es sich um DNS Einstellungen in der IPv4 Netzwerk-Einstellungen der NIC.
Normalerweise, in einer Domäne mit AD-integriertem DNS zeigt am DC der Eintrag Primärer DNS auf die IP-Adresse des Servers/DC selbst. Gibt es einen zweiten DC, zeigt der Eintrag Sekundärer DNS auf den. Beim zweiten DC ist es ebenso.
Um das genau zu verstehen, nicht das hier Missverständnis herrscht:
DC1:
1.DNS: DC1
2.DNS: DC2
DC2:
1.DNS: DC2
2.DNS: DC1
So ist gemeint?
Sind die DNS an beiden DC denn AD-integriert?Ja natürlich, und auch die Replizierung geht an alle (also genau gesagt die Default Einstellung alle Domains in der Forest).
Worauf welche Adresse zeigt den der sekundärer Eintrag am DC im RZ? Zeigt er auf die 32- oder auf die 56er-Adresse des DC im LAN? Da die 32 nicht existent aus dem RZ, muss der 56er-holder dafür eingetragen sein. So mein Gedanke.Dieser ist derzeit noch leer, aber ist sozusagen reserviert. RZ braucht den 2.DNS für eigenen DNS, wegen Windows Updates soweit mir gesagt wurde.
D.h. ich kann angeblich nur 1.DNS verwenden... obwohl mir hier ein wenig unklar ist, warum soll ich nicht einen 3., 4. usw. eintragen können? Ist doch grundlegend egal, oder?
Da hast du Recht - ist auch das was mir der Kollege aus RZ gesagt hat - ein DNS, also der 1.DNS muss auf 10.241.56.131 hinzeigen, da sonst kein Rechner im 32-er Netz gefunden wird.
Aber, wenn die oben genannte Einträge bei 1.DNS/2.DNS das übliche sind, dann mache ich das ja auch so, jedoch will ich den 1.DNS schon immer als DC selber behalten. Da sonst keine Auflösung zustande kommt, wenn der andere DC ausfällt.
Wenn ich das ganze so lösen kann, 3 DNS Einträge zu haben, und bevorzugterweise 3. DNS ist das RZ-DNS, dann glaube ich dass ich das Thema abhaken kann. Hoffentlich...
-
Es wäre eventuell besser das Thema DC over NAT hier weiterzuführen, als in dem anderen Thread.
Wie schon erwähnt, derzeit muss es so sein, dass ich wohl beide DCs, sowohl lokal und RZ, betreibe - wahrscheinlich nicht langfristig, aber ich muss es zum laufen bringen.
Es rennt bereits und alle 3 syncen. Und zwar so: DC im RZ hat den primären DNS Server den lokalen DC. Also lautet der primäre DNS im RZ-DC: 10.241.56.131 (das ist die genatete IP des lokalen DCs, 10.146.32.131).
Jedoch ist für mich interessant, wie ich das bewerkstelligen könnte, so wie es sich eigentlich gehört: primärer DNS ist der DNS (DC) selbst.
Also das habe ich bisher:
https://blogs.technet.microsoft.com/enterprisemobility/2009/04/22/dcs-and-network-address-translation/ -> eingetragen. Funktioniert auch, NSLOOKUP S02 localhost zeigt beide IPs.
So, und wenn ich im RZ-DC den primären DNS ändere:
- ping domain.local -> keine Antwort, die angezeigte IP ist die Original-IP des lokal DCs, also 10.146.32.131, anstatt 10.241.56.131
- ping S02 -> in Ordnung, zeigt auch die genatete IP
Damit die Replikation funkt muss man domain.local pingen können. Kann ich das irgendwie in DNS lösen? Vor allem ist es so dass DNS alles repliziert, so wie soll ich denn genau sagen dass von RZ-DC domain.local per 10.241.56.131 zu erreichen ist?
Alternativ denke ich an die hosts Datei, da kann ich sagen dass domain.local per 10.241.56.131 zu erreichen ist.
So, Ideen?
-
Ich weiß dass man sie lieber meiden soll. Jedoch weiß ich noch nicht ob ich sie meiden kann - wird noch besprochen.
Derzeit wäre es gut zu versuchen, auch wenn nicht langfristig, die Sache zum laufen zu bringen.
Jedoch würde ich das gerne so lösen, ohne auf dem RZ-DC DNS vom lokalen DC eintragen zu müssen und ohne host-datei Einträgen. Die DCs müssen eigentlich selbstständig arbeiten können, wenn ich es richtig verstehe.
Lässt sich das machen?
Ich denke schon dass es machbar ist, jedoch verstehe ich noch nicht ganz das Thema msdcs und alle Einträge richtig, wie sie korrelieren und welche repliziert werden. Ich bin derzeit stark beim lesen über Replikation und DNS, damit ich es einfach besser verstehen kann.
Was ich jetzt weiß:
RZ-DC muss domain.local anpingen können und die Antwort durch die genatete IP des lokalen DCs bekommen (na eh klar).
Man muss den lokalen DC anpingen können (erschließt sich aus dem oberen Satz).
Man muss den RZ-DC auflösen und erreichen können (geht eh immer).
Hier sehe ich ein Zusammenhang zwischen diversen DNS Einträgen als notwendig, und vom Sinn her, dürfte es eh funktionieren, vor allem wenn man auf dem lokalen DC den Registry-Eintrag für mehrere IPs setzt (damit bekennt sich DC als ansprechbar mit sowohl lokaler als auch genateten IP).
Und nein, handelt sich um 2012R2.
Und wie sieht es mit einer Konfiguration aus, wenn ich lokal keinen DC mehr habe? Dann werden nur die Clients genatet, DC würde nur im RZ stehen. Gibt's da Probleme?
-
Also, ein wenig Fortschritt. Oder ob wirklich Fortschritt...
Nachdem ich gesehen habe dass die Replikation lokal funkt, die lokalen DCs stabil sind, war heute soweit den RZ-DC hochzustufen.
Jedoch um die Daten ins RZ zu übertragen, war wohl das einfachste die Replikation zum laufen zu bringen - ja ja, Replikation über NAT...
Hochstufen ging OK. Ich weiß ehrlich gesagt nicht mehr ob ich etwas speziell konfiguriert habe, damit es funktioniert, aber gleich danach wollte ich natürlich sehen ob die Replikation funktioniert. Nein. Probleme, beim Öffnen von ADUC Fehlermeldung, bei manueller NTDS Replikation in AD Standorte und Dienste kam zu RPC-Fehlern usw.
Nun Troubleshooting: mal sehen wer wem sehen oder nicht sehen kann. Egal was ich versucht habe, die Replikation lief in Fehlermeldungen - auch mit dem Registry-Eintrag. Ich habe mich zu dem Zeitpunkt entschieden den Kollegen in RZ zu erreichen. Denjenigen der die Sache vor 2 Monaten bei uns angefangen hat zu konfigurieren.
Üblich ist es ja so - beim "dcpromo" bekommt der DC als DNS in Netzwerk-Einstellungen sich selbst (üblicherweise 127.0.0.1) eingetragen. Zuerst muss DNS vom anderen DC eingetragen werden, damit domain-join funktioniert, jedoch wenn man dann den DC hochstuft, wird er als DNS "eigenständig", und braucht ja normalerweise nicht andere DNS. Die Replikation muss natürlich stattfinden, die DCs müssen sich ja sehen.
Und da genau begann mein Problem.
Ich habe versucht das Thema mit dem Registry-Eintrag. Kein Erfolg, oder ich habe was falsch gemacht...
Habe versucht mittels zusätzlichen A-Records auf dem RZ-DNS...
2 IPs für einen Namenserver (original + genatet)...
Und was weiß ich noch was.
Nichts brachte Erfolg. Mag sein auch dass ich etwas nicht korrekt gemacht habe, wie zB. die fehlenden CNAME Einträge für den RZ-DC in _msdcs Zone (später) eingetragen.
Bis mich der Kollege angerufen hat und meinte:
- ich soll ein A-Record im DNS des RZ-DC für die genatete IP des lokalen DCs erstellen (also genau gesagt S02 = 10.241.56.131)
- ich soll doch den lokalen DC (also 10.241.56.131) als DNS für den RZ-DC eintragen
Replikation läuft durch.
Da kam ich mir da ein wenig doof vor. Berechtigt?
Warum soll RZ-DC-DNS den lokalen DNS zum auflösen verwenden...??? Er muss ja doch selbst auflösen können, oder!!??
Was passiert wenn die alle gemeinsam laufen, und lokale DC ausfällt?
Und das beste: aus irgendeinem Grund verschwindet das erstellte A-Record immer wieder, und trotzdem funktioniert die Auflösung (was auch logisch ist, nachdem 10.241.56.131 primärer DNS ist)
Was passiert, sollte ich dann am Ende die lokalen DCs entfernen, habe ich weiterhin ein Problem, da ich dann die DCs hinterm NAT habe, die Clients vorm NAT bedienen müssen. Bin ich der einzige der hier auch Probleme sieht?
Recht interessant das ganze, aber gleichzeitig auch sehr ermüdend.
-
Moin,
Also jetzt bin ich ganz verblüfft.
Ich habe folgende (Test-)Konfiguration:
Eine Test-OU, diese enthält das Computer-Objekt, den Rechner mit dem getestet wird.
Eine GPO, mit einem Eintrag, Windows Store (Win10) zu deaktivieren (ADMX wurden direkt von MS für Win10 1607 bezogen und "installiert", erscheint auch in GPME als vom zentralen Server bezogen), verlinkt auf die OU und aktiv.
Die Sicherheitsfilterung ist defaultmäßig auf Authentifizierte Benutzer.
Gruppenrichtlinienmodellierung zeigt unter Details die GPO als aktiv.
GPRESULT /R /scope computer zeigt auch die GPO als aktiv.
Der Benutzer ist kein Admin/Lokal Admin.
Rechner wurde neugestartet.
Ergebnis: ich kann Windows Store aufrufen.
Die GPOs greifen ansonsten, zB. Eingeschränkte Gruppen für die lokalen Admins zieht.
Mache ich was falsch?
Danke
-
Genau. Ich melde mich dann noch mit dem Thema DHCP...
Aber eins: ich muss mich einfach nur herzlichst bedanken. Kann mich noch auf meine ersten Posts erinnern, vor ca. 3 Jahren. Was ein Konto und was ein Profil ist war so ne Sache, aber was eine Domäne, AD, DNS, FQDN, UNC, und noch vieles mehr, das waren ja noch Fremdbegriffe. Mal davon was gehört, aber die Bedeutung war vollkommen unklar. Angefangen mit viel Wikipedia, dann viel lesen (googeln), aufschreiben, skizzieren, lernen, probieren, div. Lernvideos, Bücher zu WinServer... und dann auch noch hier die tolle Unterstützung haben mich weit gebracht. Echt toll!!!
-
Von der Reverse Lookup Zone. Ich muss sie bei uns erstellen. Ist aber egal, die wird repliziert, jedoch offensichtlich nicht sofort. Aus welchen Grund auch immer.
-
Wir müssen für unsere Software immer zwingend eine RLZ anlegen, die wird benutzt. Auch RZ benötigt eigene Einträge, irgendwas in Verbindung mit Windows Update.
-
Danke.
Und die Replikation der RLZ sollte genauso wie die FLZ sein? Kann es sein dass hier Verzögerungen entstehen, bzw. kann man DNS irgendwie sofort replizieren?
-
Aber zwei Sachen verstehe ich nicht.
Auf der ZAUBERKISTE, wenn ich cmd starte und nslookup eingebe, kommt FQDN + IP. Wenn ich aber in DNS mit Rechtsklick nslookup starte, steht unknown und IPv6 link local (fe80).
Jedoch auf S02, in cmd steht localhost und ::1 und in DNS Rechtsklick und die IPv6 link local.
Reverse lookup sind beide (neu)erstellt und Einträge für die Server vorhanden.
Und dann noch dazu dass die Reverse Lookup Zone nicht repliziert. Ist das normal? Werden die PTR Einträge nur dann erstellt wenn DNS ein A-Record erstellt?
Dann wünsche ich dir ein schöners Wochenende und ruhigen Schlaf.
Danke, das hatte ich :)
UPDATE:
Ein Teil gelöst: wenn man die IPv6 Einstellungen in der Netzwerkkarte alle auf DHCP umstellt, kommt bei der CMD Abfrage die IPv4 Adresse.
Jedoch noch immer offen die Frage:
Warum in DNS-Konsole, Rechtsklick auf Server, nslookup starten, zeigt unknown und link-local?
Die Frage ist rein nur interessenshalber...
-
Das wollte ich eigentlich genau fragen. Ich möchte ihm loswerden und hoffe dass damit die Sache sauber wird!
UPDATE:
Schaut gut aus. AD Replication Status Tool ist komplett sauber, dcdiag ist auch OK. Auch dabei den RZ DC hochzustufen, auch keine Fehler wie oben beim S02... Server sind gesichert. Phuh.
Ich würd sagen die Kurve richtig gekratzt. :)
Interessant dabei dass die AD Datenbank auf LAPTOPDC2 defekt war. So viel darüber dass es egal ist ob wir noch ein Monat warten oder nicht...
Bleibt noch das Thema DHCP. Nächste Woche. Jetzt kann ich ruhig schlafen ;-)
-
Ich würde gerne Neubau vermeiden, wenn es nur geht. Habe wirklich genug andere Sachen, und niemand macht sie für mich... :rolleyes:
S02 scheint stabil zu sein und habe gerade auch meinen Rechner darüber laufen, und DHCP auch umgestellt. Mal sehen ob am Montag alle schreiend aus dem Haus laufen :shock: , oder ist Ruhe im Haus :D
Nur LAPTOPDC2 macht Troubles, und ihm kann ich zur Zeit nicht herabstufen. Ich glaube mir wird nichts anderes übrig bleiben, ihm auch einfach abzuschalten und säubern.
Übrigens, aus der Ereignisanzeige des Laptops:
NTDS (480) NTDSA: Datenbank C:\Windows\NTDS\ntds.dit: Index DRA_USN_index von Tabelle datatable ist beschädigt (0).
Ob WinRM hier die Ursache oder die Datenbank, k.A., aber ich kann auf jeden Fall die ADDS-Dienste nicht entfernen, um herabzustufen. Oder geht das irgendwie anders?
-
Hi Nils,
Nein, die Rollen wurden auf die ZAUBERKISTE übertragen.
Aber ironisch... habe jetzt den S02 geschafft hochzustufen. Dafür habe ich einen weiteren Benutzer erstellt, und mit diesem ginge es dann.
S02 steht und repliziert.
Die Replikation auf S02 geht von der ZAUBERKISTE, das scheint i.O. zu sein.
Am Ende des Tages, wenn wirklich alles kaputt, dann kein Dienstleister, sondern baue es alles neu. Sprich Rechner aus der Domäne, alle DCs kübeln und neu. Wäre eh keine schlechte Idee, nachdem die bestehende Server (Installationen) alt sind. Würde mich halt paar Tage AZ kosten, aber mind. Chef weiß bescheid und das wäre OK für ihm...
Aber schauma mal...
Das nächste Problem:
-
Hallo,
ich denke es ist besser zum Troubleshooting ein neues Thema zu eröffnen.
Es ist die Fortsetzung dieses Threads: http://www.mcseboard.de/topic/210248-thema-dc/
Ausgangssituation is hoffentlich zT. bekannt:
Zwei Laptops tragen DCs (ZAUBERKISTE, LAPTOPDC2), neuer 2012R2 (S02) wurde installiert.
FSMO Rollen fehlen (alter Server, offline).
Nun, was ist bisher geschehen:
FSMO Rollen übernommen - OK, netdom auf beiden Rechnern OK.
SRV-DC1 (alter DC) aus DNS bereinigt, und sonst wo noch gefunden (habe ich nicht protokolliert).
Replikation geprüft (AD Replication Status):
LAPTOPDC2 failed, kann nicht kontaktiert werden - finde keine Ursache.
Jedoch werden die Daten scheinbar repliziert (zB. Benutzer-Erstellung auf ZAUBERKISTE wird auf LAPTOPDC2 repliziert)
dcdiags:
ZAUBERKISTE:
Verzeichnisserverdiagnose
Anfangssetup wird ausgefhrt:
Der Homeserver wird gesucht...
Homeserver = Zauberkiste
* Identifizierte AD-Gesamtstruktur.
Sammeln der Ausgangsinformationen abgeschlossen.
Erforderliche Anfangstests werden ausgefhrt.
Server wird getestet: Default-First-Site-Name\ZAUBERKISTE
Starting test: Connectivity
......................... ZAUBERKISTE hat den Test Connectivity
bestanden.
Prim„rtests werden ausgefhrt.
Server wird getestet: Default-First-Site-Name\ZAUBERKISTE
Starting test: Advertising
Achtung: Von ZAUBERKISTE werden keine Ankndigungen als Zeitserver
vorgenommen.
......................... Der Test Advertising fr ZAUBERKISTE ist
fehlgeschlagen.
Starting test: FrsEvent
......................... ZAUBERKISTE hat den Test FrsEvent bestanden.
Starting test: DFSREvent
......................... ZAUBERKISTE hat den Test DFSREvent
bestanden.
Starting test: SysVolCheck
......................... ZAUBERKISTE hat den Test SysVolCheck
bestanden.
Starting test: KccEvent
......................... ZAUBERKISTE hat den Test KccEvent bestanden.
Starting test: KnowsOfRoleHolders
......................... ZAUBERKISTE hat den Test KnowsOfRoleHolders
bestanden.
Starting test: MachineAccount
......................... ZAUBERKISTE hat den Test MachineAccount
bestanden.
Starting test: NCSecDesc
......................... ZAUBERKISTE hat den Test NCSecDesc
bestanden.
Starting test: NetLogons
......................... ZAUBERKISTE hat den Test NetLogons
bestanden.
Starting test: ObjectsReplicated
......................... ZAUBERKISTE hat den Test ObjectsReplicated
bestanden.
Starting test: Replications
......................... ZAUBERKISTE hat den Test Replications
bestanden.
Starting test: RidManager
......................... ZAUBERKISTE hat den Test RidManager
bestanden.
Starting test: Services
......................... ZAUBERKISTE hat den Test Services bestanden.
Starting test: SystemLog
Fehler. Ereignis-ID: 0x00002720
Erstellungszeitpunkt: 05/12/2017 12:54:38
Ereigniszeichenfolge:
Durch die Berechtigungseinstellungen fr "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITŽT\SYSTEM" (SID: S-1-5-18) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" fr die COM-Serveranwendung mit der CLSID
......................... Der Test SystemLog fr ZAUBERKISTE ist
fehlgeschlagen.
Starting test: VerifyReferences
......................... ZAUBERKISTE hat den Test VerifyReferences
bestanden.
Partitionstests werden ausgefhrt auf: ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... ForestDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... DomainDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: Schema
Starting test: CheckSDRefDom
......................... Schema hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... Schema hat den Test CrossRefValidation
bestanden.
Partitionstests werden ausgefhrt auf: Configuration
Starting test: CheckSDRefDom
......................... Configuration hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... Configuration hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: datev
Starting test: CheckSDRefDom
......................... datev hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... datev hat den Test CrossRefValidation
bestanden.
Unternehmenstests werden ausgefhrt auf: datev.local
Starting test: LocatorCheck
Achtung: Fehler beim Aufrufen von DcGetDcName(TIME_SERVER): 1355
Es wurde kein Zeitserver gefunden.
Der Server mit der Rolle fr den prim„ren Dom„nencontroller ist nicht
verfgbar.
Achtung: Fehler beim Aufrufen von
DcGetDcName(GOOD_TIME_SERVER_PREFERRED): 1355
Es wurde kein geeigneter Zeitserver gefunden.
......................... Der Test LocatorCheck fr datev.local ist
fehlgeschlagen.
Starting test: Intersite
......................... datev.local hat den Test Intersite
bestanden.
LAPTOPDC2:
Verzeichnisserverdiagnose
Anfangssetup wird ausgefhrt:
Der Homeserver wird gesucht...
Homeserver = laptopdc2
* Identifizierte AD-Gesamtstruktur.
Sammeln der Ausgangsinformationen abgeschlossen.
Erforderliche Anfangstests werden ausgefhrt.
Server wird getestet: Default-First-Site-Name\LAPTOPDC2
Starting test: Connectivity
......................... LAPTOPDC2 hat den Test Connectivity
bestanden.
Prim„rtests werden ausgefhrt.
Server wird getestet: Default-First-Site-Name\LAPTOPDC2
Starting test: Advertising
Achtung: Von LAPTOPDC2 werden keine Ankndigungen als Zeitserver
vorgenommen.
......................... Der Test Advertising fr LAPTOPDC2 ist
fehlgeschlagen.
Starting test: FrsEvent
......................... LAPTOPDC2 hat den Test FrsEvent bestanden.
Starting test: DFSREvent
......................... LAPTOPDC2 hat den Test DFSREvent bestanden.
Starting test: SysVolCheck
[LAPTOPDC2] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist
der Fehler 64 aufgetreten,
Der angegebene Netzwerkname ist nicht mehr verfgbar..
......................... Der Test SysVolCheck fr LAPTOPDC2 ist
fehlgeschlagen.
Starting test: KccEvent
Fehler. Ereignis-ID: 0x000001D3
Erstellungszeitpunkt: 05/12/2017 13:50:24
Ereigniszeichenfolge:
NTDS (480) NTDSA: Datenbank C:\Windows\NTDS\ntds.dit: Index DRA_USN_index von Tabelle datatable ist besch„digt (0).
Warnung. Ereignis-ID: 0x80000495
Erstellungszeitpunkt: 05/12/2017 13:50:24
Ereigniszeichenfolge:
Internal event: Active Directory Domain Services has encountered the following exception and associated parameters.
Fehler. Ereignis-ID: 0xC000043C
Erstellungszeitpunkt: 05/12/2017 13:50:24
Ereigniszeichenfolge:
Internal event: Active Directory Domain Services could not update the following object with changes received from the following source directory service. This is because an error occurred during the application of the changes to Active Directory Domain Services on the directory service.
Fehler. Ereignis-ID: 0xC000083C
Erstellungszeitpunkt: 05/12/2017 13:50:24
Ereigniszeichenfolge:
Dieses Ereignis enth„lt Reparaturvorg„nge fr das Ereignis "1084", das zuvor protokolliert wurde. Diese Meldung deutet auf ein bestimmtes Problem in Bezug auf die Konsistenz der Active Directory-Dom„nendienste-Datenbank fr dieses Replikationsziel hin. Bei der šbernahme von Replikations„nderungen fr das folgende Objekt ist ein Datenbankfehler aufgetreten. Die Datenbank enth„lt nicht erwartete Inhalte, die verhindern, dass die Žnderung durchgefhrt wird.
......................... Der Test KccEvent fr LAPTOPDC2 ist
fehlgeschlagen.
Starting test: KnowsOfRoleHolders
......................... LAPTOPDC2 hat den Test KnowsOfRoleHolders
bestanden.
Starting test: MachineAccount
Pipe konnte nicht mit [LAPTOPDC2] ge”ffnet werden: Fehler: 64:
Der angegebene Netzwerkname ist nicht mehr verfgbar.
NetBIOS-Dom„nenname konnte nicht abgerufen werden.
Fehler: Test fr HOST-SPN nicht m”glich.
Fehler: Test fr HOST-SPN nicht m”glich.
......................... LAPTOPDC2 hat den Test MachineAccount
bestanden.
Starting test: NCSecDesc
......................... LAPTOPDC2 hat den Test NCSecDesc bestanden.
Starting test: NetLogons
[LAPTOPDC2] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist
der Fehler 64 aufgetreten,
Der angegebene Netzwerkname ist nicht mehr verfgbar..
......................... Der Test NetLogons fr LAPTOPDC2 ist
fehlgeschlagen.
Starting test: ObjectsReplicated
......................... LAPTOPDC2 hat den Test ObjectsReplicated
bestanden.
Starting test: Replications
[Replications Check,LAPTOPDC2] Bei einer krzlich ausgefhrten
Replikation ist ein Fehler aufgetreten:
Von ZAUBERKISTE nach LAPTOPDC2
Namenskontext: DC=DomainDnsZones,DC=datev,DC=local
Beim Replizieren ist ein Fehler aufgetreten (8451):
Der Replikationsvorgang ist auf einen Datenbankfehler gestoáen.
Auftreten des Fehlers: 2017-05-12 13:50:24.
Letzter erfolgreicher Vorgang: 2017-05-12 12:56:23.
Seit dem letzten erfolgreichen Vorgang sind 12 Fehler aufgetreten.
Die Replikation kann aufgrund eines schwerwiegenden Fehlers nicht
fortgesetzt werden.
Ausfhrlichere Informationen finden Sie im Fehlerprotokoll.
Ist ein bestimmtes Objekt angegeben, muss dieses Objekt
m”glicherweise
manuell ge„ndert oder gel”scht werden.
Wenden Sie sich an Microsoft, wenn sich das Problem nicht beheben
l„sst.
......................... Der Test Replications fr LAPTOPDC2 ist
fehlgeschlagen.
Starting test: RidManager
......................... LAPTOPDC2 hat den Test RidManager bestanden.
Starting test: Services
Die Remote-IPC fr [laptopdc2.datev.local] konnte nicht ge”ffnet
werden: Fehler 0x40
"Der angegebene Netzwerkname ist nicht mehr verfgbar."
......................... Der Test Services fr LAPTOPDC2 ist
fehlgeschlagen.
Starting test: SystemLog
......................... LAPTOPDC2 hat den Test SystemLog bestanden.
Starting test: VerifyReferences
......................... LAPTOPDC2 hat den Test VerifyReferences
bestanden.
Partitionstests werden ausgefhrt auf: ForestDnsZones
Starting test: CheckSDRefDom
......................... ForestDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... ForestDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: DomainDnsZones
Starting test: CheckSDRefDom
......................... DomainDnsZones hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... DomainDnsZones hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: Schema
Starting test: CheckSDRefDom
......................... Schema hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... Schema hat den Test CrossRefValidation
bestanden.
Partitionstests werden ausgefhrt auf: Configuration
Starting test: CheckSDRefDom
......................... Configuration hat den Test CheckSDRefDom
bestanden.
Starting test: CrossRefValidation
......................... Configuration hat den Test
CrossRefValidation bestanden.
Partitionstests werden ausgefhrt auf: datev
Starting test: CheckSDRefDom
......................... datev hat den Test CheckSDRefDom bestanden.
Starting test: CrossRefValidation
......................... datev hat den Test CrossRefValidation
bestanden.
Unternehmenstests werden ausgefhrt auf: datev.local
Starting test: LocatorCheck
Achtung: Fehler beim Aufrufen von DcGetDcName(TIME_SERVER): 1355
Es wurde kein Zeitserver gefunden.
Der Server mit der Rolle fr den prim„ren Dom„nencontroller ist nicht
verfgbar.
Achtung: Fehler beim Aufrufen von
DcGetDcName(GOOD_TIME_SERVER_PREFERRED): 1355
Es wurde kein geeigneter Zeitserver gefunden.
......................... Der Test LocatorCheck fr datev.local ist
fehlgeschlagen.
Starting test: Intersite
......................... datev.local hat den Test Intersite
bestanden.
Wo ich gerade anstehe ist, den neuen DC heraufzustufen.
Der neue DC, S02, wurde in die Domäne gesetzt, soweit alles OK.
Jedoch wenn ich das heraufstufen versuche, kommt folgende Fehlermeldung:
Was verpasse ich denn bitte?
Das kommt auf beiden Servern.
Und das auch, gefunden:
Das sollte ja funktionieren, oder?
Wenn man aber die Replikation über NTDS Settings aufruft, keine Fehler.
-
-
Genau so ist es, danke lefg - die NAT-Einrichtung und die jetzige Konfiguration haben 3 Kollegen gemacht - ein Kollege hier und zwei Kollegen aus dem Mutterkonzern (RZ). Ich war zu dem Zeitpunkt noch nicht mal angestellt.
Grundsätzlich wie schon mehrmals geschrieben: die Netze sind unterschiedlich und die einzige Lösung ist zu NATen, da RZ vermutlich unser aktuelles lokales Netz nicht nutzen kann oder will. Verständlich, denn was passiert wenn ein anderer Kunde auch den selben lokalen Bereich hat (und der VPN-Endpunkt ja der selbe ist, wie ich bereits informiert wurde). RZ bestimmt in welches Netz wir wandeln müssen (oder wir stellen lokal auf dieses Netz um - was auch nicht möglich ist!!).
DHCP am LANCOM, wie aktuell installiert, funktioniert. Jedoch weiß ich dass DHCP, wenn möglich, am DC installiert sein soll - so ist die offizielle Empfehlung (ob nur wegen Dynamischen Updates, oder sonst noch was?, weiß ich nicht... habe ich aber schon irgendwo gefragt).
DHCP im RZ ist rein die Idee, um die Konfiguration schon einfach zu halten - wenn es funktioniert, ist ja nichts gediechselt und in DHCP klar dargestellt. Das ist einfach nur meine persönliche Meinung, da ich die DHCP Verwaltung im LANCOM ja kenne.
-
Das ist wie's gerade eingerichtet ist, aber eher gezwungenermaßen.
Sind ca. 35 Rechner, jedoch mind. 10 sind nicht mit fixen IPs konfigurierbar. Dazu sind noch etwa 20 IP-Telefone, ca. 20 Mobilegeräte, Netzwerk-Komponenten, einige Bereiche für gewisse Sachen mit RZ reserviert...
Das System ist ein wenig eigen, da ich nur die Adressen ab .130-254 eines Subnetzes nutzen kann, und dann wird schon langsam eng.
Deswegen wäre mir lieber DHCP auf einem Win Server managen zu müssen, als im LANCOM, was einfach nur wesentlich aufwändiger ist - so meine Meinung nur. Machbar am LANCOM? Klar.
magheinz:
Basteln? Was ist da gebastelt? Unser Haupt-DC ist im RZ, DHCP wäre drauf (wie sonst üblich), sonst wird nichts geändert. Ich habe nicht gefragt wie ich es zum funktionieren bringe, sondern ob das funktioniert.
Rein interessenshalber: warum sagst du nein nein nein?
Abgesehen davon dass die VPN-Leitung abschießen kann, und dann kein DHCP zur Verfügung steht, gibt es andere Gründe? - ich kann bspw. längere Lease vergeben, damit vermeide ich die Probleme mit dem VPN-Ausfall.
Netzauslastung sehe ich keine große da die paar Pakete die gelegentlich übertragen werden, nicht unbedingt viel bedeuten.
Router sind zwei, also einer als Backup, beide bauen eine LTE Verbindung auf, also haben wir immer 2 VPN Kanäle zum RZ aufrecht, jedoch wird immer einer benutzt (LANCOM VRRP).
Thema DC - Fortsetzung, Troubleshooting
in Windows Server Forum
Geschrieben · bearbeitet von kosta88
Naja, es ist nichts kaputt derzeit. Die Fehler tauchen ja immer wieder auf, aber immer darauffolgend die Meldung dass es funktioniert hat. Objekte replizieren, DNS auch.
Ich habe glaube ich bereits wo geschrieben dass ich das via NAT nicht so belassen will, die Entscheidung ist nur jetzt, ja kurzfristig so zu belassen bis alle Server in RZ installiert und bereit sind, d.h. zwei DCs dort, und dann alle Server hier entfernt.
Die einzige Variante dass ich lokal einen Server haben werde ist wenn ich irgendwie NAT vermeiden könnte... die Idee ist noch ein lokales Netz mit Adresse 10.225.159.0 zu erstellen und nachsehen ob das eventuel was hilft.
Ich dachte ich hätte schon klar gestellt dass DC over NAT für mich keine langfristige Lösung ist.
Bei einigen habe ich schon Ahnung, und auch die Ursache, die ich auch beseitigt habe.
DFS Replikation Warnung ist auch weg - das weiß ich nicht warum.
Wie schon gesagt, ich kann mit einer nicht standardisierten und supporteten Lösung leben, deswegen wird das auch abgeschafft - aber in Schritten, damit ich eben sicher bin was genau passiert.
Einer Hochschule? Ne. Keine Hochschule. Eigentlich ist unser RZ eines der Top IT-Unternehmen in DE und wir sind eine 20-Mitarbeiter Tochtergesellschaft. Jedoch ist dem Mutterkonzern grundstzlich egal was wir mit unserer IT machen.
Grundsätzlich muss man sagen dass vor mir die Firma ohne DC funktioniert hat (vor über 3 Jahren) - jedoch wollten die vorigen IT-Leute einen DC machen. Das kam irgendwie nie Zustande.
DC wurde eingeführt da die Administration der Workstations (meistens kleine Updates, Zugangssoftware zum RZ) mühsam war. Mehr war zu dem Zeitpunkt nicht dahinter. Unsere Firma ist eigentlich RDS Host basiert, da arbeiten wir in RZ in DE (ganz andere Abteilung als Hosting, aber die selbe Firma).
Im Endeffekt macht DC nichts mehr als User-Auth, ein paar GPOs und das war's eigentlich. Die GPOs sind dafür da Usern lokale Admin Rechte zu vergeben, einige Registry-Keys zu verteilen, aber nichts was das tägliche Geschäft brechen würde, würden alle DCs absolut ausfallen. Dann könnte man noch immer mit dem lokalen Admin einsteigen, und sich wieder mit RDS verbinden.
So, einerseits wäre es dann mühsam wieder alles aufzubauen, aber man muss auch von der anderen Seite verstehen, dass auch ein totaler Ausfall zwar mühsam wäre, aber nichts was die Ressourcen blockieren würde.
Es sind bei uns auch keine lokalen Shares vorhanden, keine Roaming Profiles usw.
Bald wird eine NAS vorhanden sein, die dann die Images, Backups einiger ext. Platten und paar Rechner trägt, aber das war's schon.
Und genau so ist es: ich habe ziemlich die freie Hand, sogar vom Chef persönlich. Ich soll die Sache besten Gewissens machen, und dafür dass wir keine Ausfallzeiten hatten (von die "Probleme" muss ja keiner wirklich was wissen...), habe ich heute ein Klopfen beim Meeting bekommen, lol...
Ja, und das ist natürlich ein Vorteil daraus. Dadurch dass ich zwar vorsichtig bin, aber auch probieren kann, lerne ich viel glaube ich, und wenn was nicht geht, wie die Probleme vorher, muss ich sie ja lösen. Die Analyse und Forschung bringen einiges an Erfahrung - die ich auch leider auch nicht wirklich von wem anderen sammeln kann - ich bin sozusagen die höchste IT-Stelle im Unternehmen (außer halt die Oberfuzzis im RZ, versteht sich, mit denen ich nicht viel Kontakt habe).
Ich kann mich nur immer wieder für die Hilfestellungen bedanken, es ist echt toll, und bringt mir sehr viel bei - nur Bücher lesen und Videos schauen bringt alleine nicht viel.