27
Merkwürdige DHCP Konfiguration in der Domäne
Wir haben eine einfache Domänenstruktur mit nur einem DC.
Der DC ist ein Windows Server 2008 Standard. Auf ihm sind folgende Rollen installiert:
- Active Directory Domänendienste
- Dateidienste
- DNS-Server
Es ist keine DHCP-Server Rolle installiert, folglich läuft auch nicht der DHCP-Serverdienst.
Jetzt kommts! Wir haben auf keinem der anderen 5 Server einen DHCP-Server installiert! Aber die IP-Vergabe erfolgt über DHCP. Mit dhcptest wird der o.g. DC als DHCP-Server ermittelt und über dhcpcheck als alive ermittelt.
Wie kann das sein?
Der DC ist ein Windows Server 2008 Standard. Auf ihm sind folgende Rollen installiert:
- Active Directory Domänendienste
- Dateidienste
- DNS-Server
Es ist keine DHCP-Server Rolle installiert, folglich läuft auch nicht der DHCP-Serverdienst.
Jetzt kommts! Wir haben auf keinem der anderen 5 Server einen DHCP-Server installiert! Aber die IP-Vergabe erfolgt über DHCP. Mit dhcptest wird der o.g. DC als DHCP-Server ermittelt und über dhcpcheck als alive ermittelt.
Wie kann das sein?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 310467
Url: https://administrator.de/contentid/310467
Printed on: April 19, 2024 at 17:04 o'clock
27 Comments
Latest comment
Hallo erst mal ...
kannst du mit dhcpmgmt.msc auf den Server verbinden?
Wenn nicht, ist vermutlich irgendein alternativer DHCPserver installiert
kannst du mit dhcpmgmt.msc auf den Server verbinden?
Wenn nicht, ist vermutlich irgendein alternativer DHCPserver installiert
Hi,
E.
Wie kann das sein?
Was ist denn sonst noch für Software auf diesem Server installiert?E.
Hallo,
Entweder ist dort ein DHCP Installiert oder nicht. Es gibt ja nicht nur die Rolle DHCP eines Server OSes. DHCP kann auch von anderen Software Quellen stammen. Sicher das es kein anderer DHCP ist (Router/WLAN Router/etc)? Was sagt denn ein IPConfig all werd dort die IP ausgegeben hat? mal den betroffen Server vom netz genommen - werden dann immer noch IPs ausgegeben? Mit ein Wireshark mal geschaut was auf Port UDP 67/69 los ist? Wir kennen nicht dein Netz noch dessen Struktur noch welche Gerätschaften sich dort tummeln noch wer dort was tut oder darf oder was alles angepappt (LAN / WLAN) ist. Und sollte auf besagten Server ein DHCP dort versteckt sein Werk tun - was treibt sich dann dort noch alles rum? Auch Router oder Switche können IPs vergeben DHCP).
Gruß,
Peter
Entweder ist dort ein DHCP Installiert oder nicht. Es gibt ja nicht nur die Rolle DHCP eines Server OSes. DHCP kann auch von anderen Software Quellen stammen. Sicher das es kein anderer DHCP ist (Router/WLAN Router/etc)? Was sagt denn ein IPConfig all werd dort die IP ausgegeben hat? mal den betroffen Server vom netz genommen - werden dann immer noch IPs ausgegeben? Mit ein Wireshark mal geschaut was auf Port UDP 67/69 los ist? Wir kennen nicht dein Netz noch dessen Struktur noch welche Gerätschaften sich dort tummeln noch wer dort was tut oder darf oder was alles angepappt (LAN / WLAN) ist. Und sollte auf besagten Server ein DHCP dort versteckt sein Werk tun - was treibt sich dann dort noch alles rum? Auch Router oder Switche können IPs vergeben DHCP).
Gruß,
Peter
Leider nein, der findet den Server nicht.
Hallo Peter,
wir haben ein kleines Netzwerk, da tummelt sich nach dem Firewallrouter noch eine Collax CBS als Proxy. ansonsten sind noch 5 weitere Server in Betrieb und 3 Layer 3 Switche von Netgear. Die Server und den Collax habe ich schon überprüft, der Firewallrouter scheidet auch aus, da der vor dem lokalen Netz liegt und mit DHCP nichts am Hut hat.
Auf dem DC läuft noch unsere zentral gemanagte Security-Lösung sowie eine Inventarisierungssoftware. beide wurden von mir installiert, als ich hier vor ca. 2 1/2 Jahren meinen Dienst antrat. Die haben auch nix mit DHCP am Hut.
Momentan habe ich noch einen zweiten DC aufgesetzt, der den alten ablösen soll. Das ist eigentlich der Grund, weshalb ich der Sache nachgehen möchte, da ich Kollisionen vermeiden möchte. Es wäre schön, wenn ich den "alten" DHCP deaktivieren und dann den neuen DHCP einfach in Betrieb nehmen könnte. Aber der teufel ist ein Eichhörnchen
wir haben ein kleines Netzwerk, da tummelt sich nach dem Firewallrouter noch eine Collax CBS als Proxy. ansonsten sind noch 5 weitere Server in Betrieb und 3 Layer 3 Switche von Netgear. Die Server und den Collax habe ich schon überprüft, der Firewallrouter scheidet auch aus, da der vor dem lokalen Netz liegt und mit DHCP nichts am Hut hat.
Auf dem DC läuft noch unsere zentral gemanagte Security-Lösung sowie eine Inventarisierungssoftware. beide wurden von mir installiert, als ich hier vor ca. 2 1/2 Jahren meinen Dienst antrat. Die haben auch nix mit DHCP am Hut.
Momentan habe ich noch einen zweiten DC aufgesetzt, der den alten ablösen soll. Das ist eigentlich der Grund, weshalb ich der Sache nachgehen möchte, da ich Kollisionen vermeiden möchte. Es wäre schön, wenn ich den "alten" DHCP deaktivieren und dann den neuen DHCP einfach in Betrieb nehmen könnte. Aber der teufel ist ein Eichhörnchen
Nachtrag: Ich möchte einfach vermeiden, alle Clients auf feste IP umstellen zu müssen bevor ich den alten DC abschalten kann, um danach den neuen als DHCP laufen zu lassen und dann alle Clients wieder auf DHCP umzustellen.
Oha, mir fällts wie Schuppen von den Augen!!
dhcptest und dhcpcheck haben den DC als DHCP identifiziert, weil der der letzte in der kette der Anfrage ist.
Jetzt habe ich nochmal DHCP-Find gestartet und siehe da, der DHCP ist ein Externer!!
Über tracert kann ich die Route verfolgen bis zu unserer externen IP von der Telekom am Routereingang. danach ist Schluss.
Aber wie kann das sein, dass ein externer DHCP-Server Zugriff auf unserelokale IP-Struktur hat?
dhcptest und dhcpcheck haben den DC als DHCP identifiziert, weil der der letzte in der kette der Anfrage ist.
Jetzt habe ich nochmal DHCP-Find gestartet und siehe da, der DHCP ist ein Externer!!
Über tracert kann ich die Route verfolgen bis zu unserer externen IP von der Telekom am Routereingang. danach ist Schluss.
Aber wie kann das sein, dass ein externer DHCP-Server Zugriff auf unserelokale IP-Struktur hat?
Hallo,
Davon macht keiner irgendwie den DHCP?
Gruß,
Peter
Davon macht keiner irgendwie den DHCP?
in Betrieb und 3 Layer 3 Switche
Die machen auch keinen DHCP?mit DHCP
Was sagt denn ein ARP -a oder IPCobnfig /all wer der DHCP ist? Was sagt ein Wireshark (UDP 67(67) welche MAC der DHCP haben soll? Gibt es denn Rechner? Schon mal den bedagten Server ausgeknipst (oder LAN Stecker gezogen) ob dann noch weiterhin IPs vergeben werden?Momentan habe ich noch einen zweiten DC aufgesetzt
Und der macht was? Wenn der doch schon DC spielt, welche Rollen hat der oder was nutzt ihr als DHCP?Aber der teufel ist ein Eichhörnchen
Aber ein Wireshark sagt es dir in 1 Minute wo der Teufel sitzt...Ausser bei dir sind sowohl IPs und MACS gefälscht...Wenn nicht, reicht auch ein IPConfig /all und ein arp -a.Gruß,
Peter
Moin,
Das geht nur wenn am Router (oder an einem der L3-Switches) ein Relay-Agent läuft. (DHCP basiert auf Broadcasts)
Also: Mal Karten auf den Tisch und das komplette dhcptest Ergebnis hier gepostet - daran lässt sich evtl noch was erkennen.
lg,
Slainte
externer DHCP-Server Zugriff auf unserelokale IP-Struktur hat?
Das geht nur wenn am Router (oder an einem der L3-Switches) ein Relay-Agent läuft. (DHCP basiert auf Broadcasts)
Also: Mal Karten auf den Tisch und das komplette dhcptest Ergebnis hier gepostet - daran lässt sich evtl noch was erkennen.
lg,
Slainte
Hallo,
sicher das nicht euer Router DHCP macht?
Gruß
Chonta
sicher das nicht euer Router DHCP macht?
Gruß
Chonta
Und ein billiger Telekom (Speedport) Router supportet gar kein DHCP Relay (Helper Adress) !
Fazit:
Wireshark nehmen und die eingehenden Reply DHCP Pakete (DHCPOFFER) ansehen UDP-Quellport 67 und UDP-Zielport 68.
Anhand der Mac Adresse in diesen UDP Paketen kann man den Absender dann sofort identifizieren und wenn man in die Mac Forwarding Database des Switches schaut auch sofort den Port an dem er angeschlossen ist.
Ein Klassiker...und es stellt sich die Frage warum der TO das nicht schon längst gemacht hat anstatt weiter im freien Fall rumzuraten wie Kollege SlainteMhath hier sehr richtig bemerkt ?!
Fazit:
Wireshark nehmen und die eingehenden Reply DHCP Pakete (DHCPOFFER) ansehen UDP-Quellport 67 und UDP-Zielport 68.
Anhand der Mac Adresse in diesen UDP Paketen kann man den Absender dann sofort identifizieren und wenn man in die Mac Forwarding Database des Switches schaut auch sofort den Port an dem er angeschlossen ist.
Ein Klassiker...und es stellt sich die Frage warum der TO das nicht schon längst gemacht hat anstatt weiter im freien Fall rumzuraten wie Kollege SlainteMhath hier sehr richtig bemerkt ?!
Warum nicht einfach einfach? Man nehme einen Client, öffne cmd (oder ps) und tippe ein:
ipconfig /all
dann bekommst du sowas:
da steht mittendrin der DHCP, der dir deine Adresse gibt. Spätestens dann wirst du den Server sicher leicht finden...
ipconfig /all
dann bekommst du sowas:
Ethernet-Adapter LAN-Verbindung 2:
Verbindungsspezifisches DNS-Suffix: xxx.intern
Beschreibung. . . . . . . . . . . : TAP-Windows Adapter V9
Physikalische Adresse . . . . . . : 00-FF-BC-92-88-A4
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::eda8:cf07:8e8b:87aa%24(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 172.32.255.2(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Donnerstag, 21. Juli 2016 18:42:49
Lease läuft ab. . . . . . . . . . : Freitag, 21. Juli 2017 18:42:49
Standardgateway . . . . . . . . . :
** DHCP-Server . . . . . . . . . . . : 172.32.255.254**
DHCPv6-IAID . . . . . . . . . . . : 553713596
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-1E-11-6B-DB-54-EE-75-46-80-AE
DNS-Server . . . . . . . . . . . : 192.168.2.249
NetBIOS über TCP/IP . . . . . . . : Aktiviertda steht mittendrin der DHCP, der dir deine Adresse gibt. Spätestens dann wirst du den Server sicher leicht finden...
@shadynet: Das war die erste Aktion, gehört doch zum Standard
Die Sache ist die, dass dort ebenso wie bei dhcptest als DHCP-Server der eingangs erwähnte DC aufgeführt wird. Der aber hat weder die Rolle noch den Dienst installiert, kann also eigentlich gar kein DHCP-Server sein.
Habe jetzt auch an einem DHCP-Client ipconfig /renew ausgeführt und mit wireshark mitprotokolliert. Dort fehlt der Eintrag DHCP OFFER, was aber daran liegen kann, dass die vorhandene IP als bevorzugt eingetragen ist. Und solange die frei ist bekommt der Client die auch. Macht auch nix, da wireshark die ack Meldung des DHCP-Servers ausgegeben hat. Und siehe da: wieder der DC.
Ich könnte verzweifeln.
Also werde ich wohl nicht umhin kommen, morgen eine Sonderschicht zu fahren und den alten DC einfach mal abschalten. Mal sehen, was dann bei ipconfig /renew rauskommt.
Die Sache ist die, dass dort ebenso wie bei dhcptest als DHCP-Server der eingangs erwähnte DC aufgeführt wird. Der aber hat weder die Rolle noch den Dienst installiert, kann also eigentlich gar kein DHCP-Server sein.
Habe jetzt auch an einem DHCP-Client ipconfig /renew ausgeführt und mit wireshark mitprotokolliert. Dort fehlt der Eintrag DHCP OFFER, was aber daran liegen kann, dass die vorhandene IP als bevorzugt eingetragen ist. Und solange die frei ist bekommt der Client die auch. Macht auch nix, da wireshark die ack Meldung des DHCP-Servers ausgegeben hat. Und siehe da: wieder der DC.
Ich könnte verzweifeln.
Also werde ich wohl nicht umhin kommen, morgen eine Sonderschicht zu fahren und den alten DC einfach mal abschalten. Mal sehen, was dann bei ipconfig /renew rauskommt.
Es kann doch nicht so schwer sein, alle laufenden Prozesse auf dem DC aufzulisten und zu schauen, zu was diese gehören.
Welche Dienste laufen? (nicht "welche Rollen sind installiert" !)
Läuft auf dem DC möglicherweise "bloß" ein Relay-Agent? Wobei aber auch hier am Client die IP-Adresse des DHCP-Servers angezeigt werden würde und nicht die des Relay Agents ...
Edit:
Welche Dienste laufen? (nicht "welche Rollen sind installiert" !)
Läuft auf dem DC möglicherweise "bloß" ein Relay-Agent? Wobei aber auch hier am Client die IP-Adresse des DHCP-Servers angezeigt werden würde und nicht die des Relay Agents ...
Dort fehlt der Eintrag DHCP OFFER, was aber daran liegen kann, dass die vorhandene IP als bevorzugt eingetragen ist. Und solange die frei ist bekommt der Client die auch. Macht auch nix, da wireshark die ack Meldung des DHCP-Servers ausgegeben hat. Und siehe da: wieder der DC.
Ich glaube nicht, dass beim einfachen "/renew" nochmal ein OFFER kommt. Da wird zunächst versucht, die vorhandene Lease aufzufrischen. Wenn, dann musst Du erst die Lease mit "ipconfig /release" explizit freigeben und erst danach ein "/renew" absetzen.Edit:
dass die vorhandene IP als bevorzugt eingetragen ist.
Wo eingetragen ist? An der NIC im Windows?
Versuchs doch am DC mal mit einem
Dann siehst du welcher Prozess welchen Port offen hat.
netstat -anbNur, dass DHCP an keinem bestimmten Port hängt ...
Also mein DHCP kommuniziert über udp/68 und udp/67 
Nur, dass DHCP an keinem bestimmten Port hängt ...
Also mein DHCP kommuniziert über udp/68 und udp/67 Zitat von @emeriks:
Es kann doch nicht so schwer sein, alle laufenden Prozesse auf dem DC aufzulisten und zu schauen, zu was diese gehören.
Welche Dienste laufen? (nicht "welche Rollen sind installiert" !)
Läuft auf dem DC möglicherweise "bloß" ein Relay-Agent? Wobei aber auch hier am Client die IP-Adresse des DHCP-Servers angezeigt werden würde und nicht die des Relay Agents ...
Es kann doch nicht so schwer sein, alle laufenden Prozesse auf dem DC aufzulisten und zu schauen, zu was diese gehören.
Welche Dienste laufen? (nicht "welche Rollen sind installiert" !)
Läuft auf dem DC möglicherweise "bloß" ein Relay-Agent? Wobei aber auch hier am Client die IP-Adresse des DHCP-Servers angezeigt werden würde und nicht die des Relay Agents ...
Routing und RAS ist deaktiviert, DHCP läuft auch nicht als Dienst.
Ich glaube nicht, dass beim einfachen "/renew" nochmal ein OFFER kommt. Da wird zunächst versucht, die vorhandene Lease aufzufrischen. Wenn, dann musst Du erst die Lease mit "ipconfig /release" explizit freigeben und erst danach ein "/renew" absetzen.
Der Tipp war gut. Ich hatte den Parameter "release" nicht mehr auf dem Schirm. Danke dafür, denn jetzt habe ich bei wireshark auch den DHCP OFFER, leider wieder der DC.
Habe ich sonst noch was vergessen? Bitte weiter posten, mir sind schon längst die Ideen ausgegangen. Und so einen Mist hatte ich noch nie in meinem langen Leben
Was ist denn das?
Auf diesen Ports läuft doch eigentlich der DHCP-Server? Kann es sein, dass der servicehost die DHCP Aufgaben übernommen hat?
Hallo,
Gemeinsame Nutzung der Internetverbindung. Warum läuft der? 2 Netzwerkkarten in dein Blech drin?
Warum stellst du immer fragen welche wir nicht eindeutig beantworten können da uns die Zusammenhänge deiner Konfigiurationen nicht bekannt sind? Beispielsweise: Ist deine IPConfig /all ein Staatsgeheimnis? Jetzt willst du Wissen warum bei dir ICS aktiv ist - wir kennen aber deine Konfigurationen nicht, schon gar nicht wie was bei dir zusammenarbeiten soll, nur Bruchstücke vom ganzen, sollen dir aber Antworten geben....
Gruß,
Peter
Gemeinsame Nutzung der Internetverbindung. Warum läuft der? 2 Netzwerkkarten in dein Blech drin?
Auf diesen Ports läuft doch eigentlich der DHCP-Server?
JaKann es sein, dass der servicehost die DHCP Aufgaben übernommen hat?
Nein.Warum stellst du immer fragen welche wir nicht eindeutig beantworten können da uns die Zusammenhänge deiner Konfigiurationen nicht bekannt sind? Beispielsweise: Ist deine IPConfig /all ein Staatsgeheimnis? Jetzt willst du Wissen warum bei dir ICS aktiv ist - wir kennen aber deine Konfigurationen nicht, schon gar nicht wie was bei dir zusammenarbeiten soll, nur Bruchstücke vom ganzen, sollen dir aber Antworten geben....
Gruß,
Peter
Hallo,
irgend was muss ja im netzwerk DHCP machen sonst würden die Rechner ja nix bekommen.
Trenne mal den DC vom Netz und schau mal nach ob es dann noch IPs gibt.
Router und Switche schon überprft ob die was machen?
Irgendwelche Hyper-V oder VM im Einsatz die ggf auch auf dem DC laufen?
Es sollte docheigentlich eine Dokumentation geben wie euer Netzwek aufgebaut ist und welche Kiste welche Dienste stellt.
Wenn Du auf dem DC nun versuchst den DHCP zu aktivieren findet der RougDHCPs? Oder findet der andere Authorized DHCP?
Zum Teil DC vom netzwerk trennen, das gleche auch mit Routern und Switchen machen um zu checken in welchem Netzsegment der GeisterDHCP sein unwesen treibt.
Gruß
Chonta
irgend was muss ja im netzwerk DHCP machen sonst würden die Rechner ja nix bekommen.
Trenne mal den DC vom Netz und schau mal nach ob es dann noch IPs gibt.
Router und Switche schon überprft ob die was machen?
Irgendwelche Hyper-V oder VM im Einsatz die ggf auch auf dem DC laufen?
Es sollte docheigentlich eine Dokumentation geben wie euer Netzwek aufgebaut ist und welche Kiste welche Dienste stellt.
Wenn Du auf dem DC nun versuchst den DHCP zu aktivieren findet der RougDHCPs? Oder findet der andere Authorized DHCP?
Zum Teil DC vom netzwerk trennen, das gleche auch mit Routern und Switchen machen um zu checken in welchem Netzsegment der GeisterDHCP sein unwesen treibt.
Gruß
Chonta
Auf diesen Ports läuft doch eigentlich der DHCP-Server? Kann es sein, dass der servicehost die DHCP Aufgaben übernommen hat?
SharedAccess macht auch DHCP, klar. Ich denke damit haben wir es.Auf einer NIC des DC ist die "gemeinsame Internetverbindung" aktiv. Das abschalten, dann sollte Ruhe sein.
Hallo,
Soll es gar mit DHCP geben.... nachdem nun herauskam das ein SharedAccess auf dein DC läuft (und mal wieder keiner weiss warum)
Gruß,
Peter
Soll es gar mit DHCP geben.... nachdem nun herauskam das ein SharedAccess auf dein DC läuft (und mal wieder keiner weiss warum)
Gruß,
Peter
Nach einer Wochenendsitzung habe ich zumindest eine Teillösung. Die sieht so aus, dass ich auf dem neuen DC den DHCP-Server eingerichtet habe und bei meinen Testclients nach ipconfig /release und /renew bei Wireshark den neuen DC als DHCK OFFER bekommen habe. Wenn also eine neue IP angefordert wird, macht das der neue DC. Keine Konflikte (bis jetzt).
Am WE habe ich die Ordnerumleitungen eingerichtet und ziehe jetzt sukzessive die servergespeicherten Profile um. Danach verschiebe ich die FSMO-Rollen und hoffe, dass alles läuft und ich den alten DC abschalten kann.
Frage, auch wenn es ein anderes Topic ist, beim Verschieben der FSMO-Rollen, werden da die GPO´s mit verschoben, oder muss ich die vorher sichern und auf dem neuen DC importieren?
Bis dahin zunächst einmal vielen Dank für Eure tatkräftige Unterstützung. Ich habe viel gelernt und vieles wieder auffrischen können
Es war für mich vor zwei Jahren nicht leicht den Job zu übernehmen, da es keinen "hauptamtlichen" Admin gab und alles über Wartungsverträge von verschiedenen externen Unternehmen gehandelt wurde. Dokus gab es nicht. Das Netzwerk lief ständig am Limit. An Neues hat sich niemand heran getraut.
Aber ich denke, dass ich das schon hinbekomme. Es gibt ja auch noch das tolle Administratorforum
Gruß
Stephan
Am WE habe ich die Ordnerumleitungen eingerichtet und ziehe jetzt sukzessive die servergespeicherten Profile um. Danach verschiebe ich die FSMO-Rollen und hoffe, dass alles läuft und ich den alten DC abschalten kann.
Frage, auch wenn es ein anderes Topic ist, beim Verschieben der FSMO-Rollen, werden da die GPO´s mit verschoben, oder muss ich die vorher sichern und auf dem neuen DC importieren?
Bis dahin zunächst einmal vielen Dank für Eure tatkräftige Unterstützung. Ich habe viel gelernt und vieles wieder auffrischen können
Es war für mich vor zwei Jahren nicht leicht den Job zu übernehmen, da es keinen "hauptamtlichen" Admin gab und alles über Wartungsverträge von verschiedenen externen Unternehmen gehandelt wurde. Dokus gab es nicht. Das Netzwerk lief ständig am Limit. An Neues hat sich niemand heran getraut.
Aber ich denke, dass ich das schon hinbekomme. Es gibt ja auch noch das tolle Administratorforum
Gruß
Stephan
Hallo,
Und wo ist der alte unbekannte geblieben? 2 DHCP im gleichen Netz die sich nicht kennen ist keine gute idee.
Gruß,
Peter
Und wo ist der alte unbekannte geblieben? 2 DHCP im gleichen Netz die sich nicht kennen ist keine gute idee.
beim Verschieben der FSMO-Rollen, werden da die GPO´s mit verschoben
Nein.Bis dahin zunächst einmal vielen Dank für Eure tatkräftige Unterstützung. Ich habe viel gelernt und vieles wieder auffrischen können
Also ich kann die eigentliche Lösung deines DHCP problems nicht nachvollziehen, vielleicht sagst du uns die ja noch...Gruß,
Peter
beim Verschieben der FSMO-Rollen, werden da die GPO´s mit verschoben, oder muss ich die vorher sichern und auf dem neuen DC importieren?
Die GPOs haben erstmal gar nichts mit den FSMO Rollen zu tun. Sie werden mittels AD- und Filereplikation auf allen DCs synchron gehalten.Zitat von @SlainteMhath:
Die GPOs haben erstmal gar nichts mit den FSMO Rollen zu tun. Sie werden mittels AD- und Filereplikation auf allen DCs synchron gehalten.
Die GPOs haben erstmal gar nichts mit den FSMO Rollen zu tun. Sie werden mittels AD- und Filereplikation auf allen DCs synchron gehalten.
Uups, sorry. Habe gerade nachgeschaut. Alles ok. Danke
Abschliessend muss ich feststellen, dass es keine Lösung gibt, außer, dass ich einfach den neuen DC zum DHCP-Server gemacht habe und der auch brav die Aufgabe übernommen hat.
Leider habe ich ein weiteres Problem, das ich aber in einem neuen Thread aufmachen möchte. Für Eure Unterstützung bei diesem problem danke ich herzlichst.
Leider habe ich ein weiteres Problem, das ich aber in einem neuen Thread aufmachen möchte. Für Eure Unterstützung bei diesem problem danke ich herzlichst.
