12
Add second Domain Controller to existing Domain - Error RID Master is offline
Hallo,
folgende Konstellation. Es gibt in einer Serverumgebung 2 getrennte Netze (239 und 238). Im 238 Netz existiert 1 Domain Controller und jetzt möchte ich im 239 Netz einen 2. hinzufügen. Beim Prerequisite Check kommt aber die folgende Fehlermeldung:
Fehler bei der Überprüfung der Voraussetzungen für die Höherstufung des Domänencontrollers. Die Installation eines zusätzlichen Domänencontrollers ist derzeit nicht möglich, da der RID-Master "DomainController1.domain.domain" offline ist.
Daraufhin habe ich einen Test auf dem Domain Controller 1 welcher RID-Master ist ausgeführt (dcdiag /v /test:ridmanager) und dieser hat alle Tests bestanden.
Also habe ich dem Dienstleister des Rechenzentrum wo diese Server stehen (Netze) alle Ports angegeben die freigegeben werden müssen laut Microsoft zur Kommunikation zwischen Domain Controllern und die Aussage war dass bereits Any<>Any Rules zwischen den Netzen bestehen.
An was kann sowas noch scheitern falls es stimmt dass bereits Any<>Any Regeln existieren?
Wenn ich telnet benutze bekomme vom DC1 (238) zum DC2 (239) mit cmd -> telnet IP 135 (Port TCP 135 RPC Endpoint Mapper) eine Verbindung. Vom DC2 zum DC1 nicht.
Natürlich muss das auch dementsprechend auf dem Server laufen sonst bekomme ich nichts zurück aber das ist ja gerade das komische. Auf dem DC2 will ich die Domain Controller Rolle erst noch konfigurieren was ja nicht geht. Der DC1 ist ja bereits Domänencontroller und müsste daher auf Port 135 auch etwas zurück geben genauso wie der im 239 Netz. Port 135 ist nur ein Beispiel.
Danke und viele Grüße!
DK
folgende Konstellation. Es gibt in einer Serverumgebung 2 getrennte Netze (239 und 238). Im 238 Netz existiert 1 Domain Controller und jetzt möchte ich im 239 Netz einen 2. hinzufügen. Beim Prerequisite Check kommt aber die folgende Fehlermeldung:
Fehler bei der Überprüfung der Voraussetzungen für die Höherstufung des Domänencontrollers. Die Installation eines zusätzlichen Domänencontrollers ist derzeit nicht möglich, da der RID-Master "DomainController1.domain.domain" offline ist.
Daraufhin habe ich einen Test auf dem Domain Controller 1 welcher RID-Master ist ausgeführt (dcdiag /v /test:ridmanager) und dieser hat alle Tests bestanden.
Also habe ich dem Dienstleister des Rechenzentrum wo diese Server stehen (Netze) alle Ports angegeben die freigegeben werden müssen laut Microsoft zur Kommunikation zwischen Domain Controllern und die Aussage war dass bereits Any<>Any Rules zwischen den Netzen bestehen.
An was kann sowas noch scheitern falls es stimmt dass bereits Any<>Any Regeln existieren?
Wenn ich telnet benutze bekomme vom DC1 (238) zum DC2 (239) mit cmd -> telnet IP 135 (Port TCP 135 RPC Endpoint Mapper) eine Verbindung. Vom DC2 zum DC1 nicht.
Natürlich muss das auch dementsprechend auf dem Server laufen sonst bekomme ich nichts zurück aber das ist ja gerade das komische. Auf dem DC2 will ich die Domain Controller Rolle erst noch konfigurieren was ja nicht geht. Der DC1 ist ja bereits Domänencontroller und müsste daher auf Port 135 auch etwas zurück geben genauso wie der im 239 Netz. Port 135 ist nur ein Beispiel.
Danke und viele Grüße!
DK
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 285043
Url: https://administrator.de/contentid/285043
Ausgedruckt am: 25.11.2024 um 06:11 Uhr
12 Kommentare
Neuester Kommentar
Ich hatte mal ein ähnliches Problem.
Irgendwie wurden die AD Standorte nicht repliziert und ich hatte zwei verschiedene Standorte mit ein- und denselben Namen.
M.w. gibt es auch so ein AD Replication Toolkit, mit dem man die Replikation grundlegend überprüfen kann.
Nachtrag: Ist die Netzwerkschnittstelle vom zweiten DC "privat" oder "öffentlich"?
Irgendwie wurden die AD Standorte nicht repliziert und ich hatte zwei verschiedene Standorte mit ein- und denselben Namen.
M.w. gibt es auch so ein AD Replication Toolkit, mit dem man die Replikation grundlegend überprüfen kann.
Nachtrag: Ist die Netzwerkschnittstelle vom zweiten DC "privat" oder "öffentlich"?
Hi,
mal ein pragmatischer Ansatz:
Schon mal versucht, im Netz des 1. DC einen weiteren DC einzurichten? Dazu kann man einfach testweise eine VM herrichten und diese promoten. Oder - falls möglich - gleich den zukünftigen 2. DC vorübergehend im Netz des 1. DC betreiben und dort promoten.
Damit könntest Du Routing- und (externe) Firewall-"Probleme" ausschließen.
Falls Du den Test mit dem temporären DC (z.B. VM) gehst: Dieser muss dann auch wieder regulär demoted werden, bevor Du diesen wieder einstampfst!
E.
mal ein pragmatischer Ansatz:
Schon mal versucht, im Netz des 1. DC einen weiteren DC einzurichten? Dazu kann man einfach testweise eine VM herrichten und diese promoten. Oder - falls möglich - gleich den zukünftigen 2. DC vorübergehend im Netz des 1. DC betreiben und dort promoten.
Damit könntest Du Routing- und (externe) Firewall-"Probleme" ausschließen.
Falls Du den Test mit dem temporären DC (z.B. VM) gehst: Dieser muss dann auch wieder regulär demoted werden, bevor Du diesen wieder einstampfst!
E.
Zitat von @117471:
Irgendwie wurden die AD Standorte nicht repliziert und ich hatte zwei verschiedene Standorte mit ein- und denselben Namen.
M.w. gibt es auch so ein AD Replication Toolkit, mit dem man die Replikation grundlegend überprüfen kann.
Wenn er z.Z. bloß einen DC hat, dann kann er keine Replikationsprobleme haben. Irgendwie wurden die AD Standorte nicht repliziert und ich hatte zwei verschiedene Standorte mit ein- und denselben Namen.
M.w. gibt es auch so ein AD Replication Toolkit, mit dem man die Replikation grundlegend überprüfen kann.
Ja das habe ich eben schon versucht. Es existierte bereits ein 1. Domain Controller (nennen wir ihn mal 241) in einem anderen Rechenzentrum das per IPSec Tunnel angebunden ist. Von diesem habe ich den DC1 (238) repliziert und das ohne Probleme. Da ich aber nun den DC1 als Master für alles eingestellt (RID, Schema, etc.) habe da der 241 abgeschafft werden soll kann ich den DC2 (239) nicht replizieren vom 241 weil das könnte man ja angeben weil er sagt der RID-Master konnte nicht erreicht werden, was ja der DC1 (238) ist.
Da über den IPSec Tunnel aber keine Firewall Einschränkungen vorhanden sind, denke ich eben dass es doch daran liegen muss das es vom 239 zum 238 nicht geht...
Da über den IPSec Tunnel aber keine Firewall Einschränkungen vorhanden sind, denke ich eben dass es doch daran liegen muss das es vom 239 zum 238 nicht geht...
Gut dass wir darüber gesprochen haben ....
Du hast also zwei Standorte, welche nicht direkt miteinander verbunden sind, sondern jeder nur eine Verbindung zum RZ haben? Oder wie jetzt? 2 RZ?
Vielleicht legst Du mal die Konfiguration etwas genauer dar.
Wenn meine Vermutung stimmt (2 Standorte + 1 RZ),
Du hast also zwei Standorte, welche nicht direkt miteinander verbunden sind, sondern jeder nur eine Verbindung zum RZ haben? Oder wie jetzt? 2 RZ?
Vielleicht legst Du mal die Konfiguration etwas genauer dar.
Wenn meine Vermutung stimmt (2 Standorte + 1 RZ),
- dann hast Du möglicherweise vergessen, im AD diese Standorte abzubilden. Kann das sein? IP-Subnetze und Standorte im angelegt? Server zugeordnet? Site Links eingerichtet?
- Weiterhin: Wenn der Server aus Standort 2 nicht mit dem RID am Standort 1 kommunizieren kann, und die Verbindung über das RZ geht, dann liegt das Problem höchstwahrscheinlich am Routing bzw. an den Firewall-Regeln.
Ok dann versuche ich das mal zu beschreiben:
1 Standort (nur Clients, keine Server, eigene Firewall)
dieser verbindet sich per IPSEC Tunnel zum Rechenzentrum wo alle Server stehen. In diesem Rechenzentrum haben wir 2 Subnetze (.238 und .239).
Vorher gab es noch eine Verbindung zu einem anderen Rechenzentrum wo 1 Server steht, was der frühere einzige DC war (.241). Nun habe ich im .238 Netz einen 2. Domain Controller hochgezogen der vom anderen Rechenzentrum repliziert wurde. Dieser 1 Server .241 soll diesen Monat noch weg fallen.
Also zusammenfassend:
Standort 1 (Clients)
Standort 2 (10 Server, jetziger DC)
Standort 3 (1 Server, früherer DC) - wird bald abgeschafft
Wenn ich nun aber innerhalb des Standort 2 einen 2. Domain Controller vom Netz .239 hochziehen und vom .238 replizieren will kommt eben die Fehlermeldung oben.
Danke, LG David
1 Standort (nur Clients, keine Server, eigene Firewall)
dieser verbindet sich per IPSEC Tunnel zum Rechenzentrum wo alle Server stehen. In diesem Rechenzentrum haben wir 2 Subnetze (.238 und .239).
Vorher gab es noch eine Verbindung zu einem anderen Rechenzentrum wo 1 Server steht, was der frühere einzige DC war (.241). Nun habe ich im .238 Netz einen 2. Domain Controller hochgezogen der vom anderen Rechenzentrum repliziert wurde. Dieser 1 Server .241 soll diesen Monat noch weg fallen.
Also zusammenfassend:
Standort 1 (Clients)
Standort 2 (10 Server, jetziger DC)
Standort 3 (1 Server, früherer DC) - wird bald abgeschafft
Wenn ich nun aber innerhalb des Standort 2 einen 2. Domain Controller vom Netz .239 hochziehen und vom .238 replizieren will kommt eben die Fehlermeldung oben.
Danke, LG David
Weiterhin ist folgendes Problem das eventuell zur Problemfindung beiträgt:
- Wenn der alte DC im Standort 3 (.241) herunterfahren wird, laufen die Server im .239 Netz nicht mehr sauber. Die Datenbankverbindung (Windows Auth.) und das CRM können sich nicht mehr miteinander verbinden. Die Server im .239 Netz verbinden sich immer zum .241 DC und nehmen nie den neuen DC im .238 Netz. Die Server im .238 Netz sind davon nicht betroffen weil diese nehmen dann eben ihren DC im .238 Netz.
Laut Rechenzentrum sind alle Ports vom .239 und .238 bidirektional offen. Ein Test mit Zenmap ergab folgendes:
Scan vom 238 zum 239:
Scanning Server im 239 Netz (1x.xx.239.2) [65535 ports]
Discovered open port 3389/tcp on 1x.239.2
Discovered open port 22/tcp on 1x.239.2
Discovered open port 8888/tcp on 1x.239.2
Discovered open port 135/tcp on 1x.239.2
Discovered open port 443/tcp on 1x.239.2
Discovered open port 80/tcp on 1x.239.
Discovered open port 445/tcp on 1x.239.2
Discovered open port 49153/tcp on 1x.239.2
Discovered open port 47001/tcp on 1x.239.2
Discovered open port 8500/tcp on 1x.239.2
Discovered open port 49178/tcp on 1x.239.2
Discovered open port 6515/tcp on 1x.239.2
Discovered open port 808/tcp on 1x.239.2
Discovered open port 49202/tcp on 1x.239.2
Discovered open port 49194/tcp on 1x.239.2
Discovered open port 49154/tcp on 1x.239.2
Discovered open port 49152/tcp on 1x.239.2
Discovered open port 5985/tcp on 1x.239.2
Discovered open port 17218/tcp on 1x.239.2
Discovered open port 49155/tcp on 1x.239.2
Completed SYN Stealth Scan at 11:45, 19.25s elapsed (65535 total ports)
Scan vom 239 zum 238:
Scanning DC im 238 Netz (1x.238.4) [65535 ports]
Discovered open port 53/tcp on 1x.238.x
Completed SYN Stealth Scan at 12:00, 9.99s elapsed (65535 total ports)
Vom 239 zum 238 kann ich also wesentlich weniger erreichen obwohl dort eigentlich der Domain Controller ist.
- Wenn der alte DC im Standort 3 (.241) herunterfahren wird, laufen die Server im .239 Netz nicht mehr sauber. Die Datenbankverbindung (Windows Auth.) und das CRM können sich nicht mehr miteinander verbinden. Die Server im .239 Netz verbinden sich immer zum .241 DC und nehmen nie den neuen DC im .238 Netz. Die Server im .238 Netz sind davon nicht betroffen weil diese nehmen dann eben ihren DC im .238 Netz.
Laut Rechenzentrum sind alle Ports vom .239 und .238 bidirektional offen. Ein Test mit Zenmap ergab folgendes:
Scan vom 238 zum 239:
Scanning Server im 239 Netz (1x.xx.239.2) [65535 ports]
Discovered open port 3389/tcp on 1x.239.2
Discovered open port 22/tcp on 1x.239.2
Discovered open port 8888/tcp on 1x.239.2
Discovered open port 135/tcp on 1x.239.2
Discovered open port 443/tcp on 1x.239.2
Discovered open port 80/tcp on 1x.239.
Discovered open port 445/tcp on 1x.239.2
Discovered open port 49153/tcp on 1x.239.2
Discovered open port 47001/tcp on 1x.239.2
Discovered open port 8500/tcp on 1x.239.2
Discovered open port 49178/tcp on 1x.239.2
Discovered open port 6515/tcp on 1x.239.2
Discovered open port 808/tcp on 1x.239.2
Discovered open port 49202/tcp on 1x.239.2
Discovered open port 49194/tcp on 1x.239.2
Discovered open port 49154/tcp on 1x.239.2
Discovered open port 49152/tcp on 1x.239.2
Discovered open port 5985/tcp on 1x.239.2
Discovered open port 17218/tcp on 1x.239.2
Discovered open port 49155/tcp on 1x.239.2
Completed SYN Stealth Scan at 11:45, 19.25s elapsed (65535 total ports)
Scan vom 239 zum 238:
Scanning DC im 238 Netz (1x.238.4) [65535 ports]
Discovered open port 53/tcp on 1x.238.x
Completed SYN Stealth Scan at 12:00, 9.99s elapsed (65535 total ports)
Vom 239 zum 238 kann ich also wesentlich weniger erreichen obwohl dort eigentlich der Domain Controller ist.
Vom 239 zum 238 kann ich also wesentlich weniger erreichen obwohl dort eigentlich der Domain Controller ist.
OK, das ist eindeutig.Was ist, wenn Du vom 239 aus die Ports anderer Server im 238 scanst?
Um es auszuschließen: Deaktiviere mal vorübergehend die Firewall Dienste auf beiden Servern. Wenn es dann immer noch nicht geht, dann blockt etwas außerhalb der Server. Da muss dann die IT des RZ am Standort 2 helfen.
Da bekomme ich rein gar nichts zurück...
Aber laut den MA aus dem RZ ist alles freigegeben :/
Firewall ist durch die GPO grundsätzlich ausgeschaltet.
Was mir jetzt noch aufgefallen ist und wo ich glaube wo der Hund begraben ist, ist eine statische Route! Auf dem DC1 .238 ist eine statische Route zum DC .241 eingetragen und auf allen anderen Servern im .239 Netz auch:
route add 1x.241.xx.x mask 255.255.255.0 1x.xxx.238.251 metric 1 –p
Diese wenn hinterlegt ist, ist der Server komplett erreichbar per Monitoring (PRTG Monitoring Arbeitsspeicher Prozessor usw.). Auf dem DC1 .238 habe ich alle Routen rausgenommen und auf dem DC2 .239 auch -> dann ist er nur mehr ping und http erreichbar. Ein WMI Scan für RAM, CPU usw. ist nicht mehr möglich. Nehme ich die Route zum DC .241 wieder mit rein ist wieder alles voll erreichbar!
Das schreit doch förmlich nach Firewall Block oder nicht?
Was sollte ich eurer Meinung nach für statische Routen zu den Servern hinzufügen? Auf dem .238 DC1:
route add 10.xxx.239.0 mask 255.255.255.0 10.226.238.251 metric 1 –p
und auf dem .239 DC2:
route add 10.xxx.238.0 mask 255.255.255.0 10.226.239.251 metric 1 –p
Aber laut den MA aus dem RZ ist alles freigegeben :/
Firewall ist durch die GPO grundsätzlich ausgeschaltet.
Was mir jetzt noch aufgefallen ist und wo ich glaube wo der Hund begraben ist, ist eine statische Route! Auf dem DC1 .238 ist eine statische Route zum DC .241 eingetragen und auf allen anderen Servern im .239 Netz auch:
route add 1x.241.xx.x mask 255.255.255.0 1x.xxx.238.251 metric 1 –p
Diese wenn hinterlegt ist, ist der Server komplett erreichbar per Monitoring (PRTG Monitoring Arbeitsspeicher Prozessor usw.). Auf dem DC1 .238 habe ich alle Routen rausgenommen und auf dem DC2 .239 auch -> dann ist er nur mehr ping und http erreichbar. Ein WMI Scan für RAM, CPU usw. ist nicht mehr möglich. Nehme ich die Route zum DC .241 wieder mit rein ist wieder alles voll erreichbar!
Das schreit doch förmlich nach Firewall Block oder nicht?
Was sollte ich eurer Meinung nach für statische Routen zu den Servern hinzufügen? Auf dem .238 DC1:
route add 10.xxx.239.0 mask 255.255.255.0 10.226.238.251 metric 1 –p
und auf dem .239 DC2:
route add 10.xxx.238.0 mask 255.255.255.0 10.226.239.251 metric 1 –p
Du brauchst Verbindung zwischen 238 und 239. Was sollen da Routen zum 241 eine Rolle spielen?
Wenn der 238 den 239 scannen kann, dann hat er offensichtlich eine Route dorthin.
Was sagt denn ein
vom 239 zum 238? Wie weit kommst Du? Wo geht das lang?
Was ist das für eine Beziehung zwischen Euch und dem RZ. Firmen intern oder Kunde-Dienstleister?
Falls Firmen intern: Eskaliere das "nach oben".
Falls Du Kunde bist: Mach denen Druck oder lass denen "von oben" Druck machen.
Wenn sie Dich nicht ernst nehmen, dann sollen sie Dir wenigstens Hilfe anbieten. Oder liegt etwa da der Hund begraben. Seid Ihr als Kunde "untreu" geworden und die im RZ sind jetzt "sauer"?
Wenn der 238 den 239 scannen kann, dann hat er offensichtlich eine Route dorthin.
Was sagt denn ein
tracertWas ist das für eine Beziehung zwischen Euch und dem RZ. Firmen intern oder Kunde-Dienstleister?
Falls Firmen intern: Eskaliere das "nach oben".
Falls Du Kunde bist: Mach denen Druck oder lass denen "von oben" Druck machen.
Wenn sie Dich nicht ernst nehmen, dann sollen sie Dir wenigstens Hilfe anbieten. Oder liegt etwa da der Hund begraben. Seid Ihr als Kunde "untreu" geworden und die im RZ sind jetzt "sauer"?
Nene, das ist die NSA. Die vergessen nur, euch eure Daten nach dem Abgriff auch wieder zurückzugeben.
Sorry - ist Freitag...
Weil anscheinend er die Kommunikation vom 239 zum 238 über den 241 DC macht, deshalb. Wenn ich den 241 abschalte können die Server nicht vom 239 zum 238 kommunizieren, Server bringen Fehler etc.
bei einem Tracert sagt er wenn die Route 241 steht:
1 <1 ms <1 ms <1 ms crmxxx.firma.de [10.xxx.239.x]
bei keiner Route:
1 1 ms <1 ms <1 ms authxxx.firma.de [10.xxx.239.x]
Wir haben einfach nur Server dort gemietet im Rechenzentrum, alles extern. Beide Netze also 238 und 239 werden von diesen betreut.
Sie haben mir angeboten mit Ihrer Windows Abteilung das zu überprüfen was aber eben einer offiziellen Beauftragung bedarf. Ansonsten kann ich mich nicht beklagen, sind sehr gut im beantworten meiner Fragen.
Auf die Firewall Geschichte hin eben -> es ist alles < Any > freigegeben zwischen den Netzen.
Lg
bei einem Tracert sagt er wenn die Route 241 steht:
1 <1 ms <1 ms <1 ms crmxxx.firma.de [10.xxx.239.x]
bei keiner Route:
1 1 ms <1 ms <1 ms authxxx.firma.de [10.xxx.239.x]
Wir haben einfach nur Server dort gemietet im Rechenzentrum, alles extern. Beide Netze also 238 und 239 werden von diesen betreut.
Sie haben mir angeboten mit Ihrer Windows Abteilung das zu überprüfen was aber eben einer offiziellen Beauftragung bedarf. Ansonsten kann ich mich nicht beklagen, sind sehr gut im beantworten meiner Fragen.
Auf die Firewall Geschichte hin eben -> es ist alles < Any > freigegeben zwischen den Netzen.
Lg
