33
Ungewollte IP Änderung am DC sorgt für Probleme
Hallo Zusammen,
wir haben ein kleines Netz mit 5 verschiedenen VMs (DC, AD, Fileserver, Exchange, TK Anlage - alle W2k12R2). Es gab einen Crash. Alle VMs sind wieder Online und funktionieren. Der DC hatte allerdings eine falsche IP nach dem starten - keine Ahnung warum. Die IP ist wieder korrigiert und trotzdem funktioniert es nicht mehr korrekt. Clients können sich nicht anmelden, allerdings nicht alle. Und dann funktioniert der Login wieder. Wlan funktioniert auch nur bedingt. DECT Telefone finden keine Basis Station mehr, andere funktionieren.
Meine Vermutung ist der DC, hier stimmt etwas nicht. DHCP und DNS laufen, habe ich geprüft. Exchange läuft auch.
Wie kann ich diesen sporadischen Fehlern auf die Schliche kommen?
DANKE
Ciao Thomas
wir haben ein kleines Netz mit 5 verschiedenen VMs (DC, AD, Fileserver, Exchange, TK Anlage - alle W2k12R2). Es gab einen Crash. Alle VMs sind wieder Online und funktionieren. Der DC hatte allerdings eine falsche IP nach dem starten - keine Ahnung warum. Die IP ist wieder korrigiert und trotzdem funktioniert es nicht mehr korrekt. Clients können sich nicht anmelden, allerdings nicht alle. Und dann funktioniert der Login wieder. Wlan funktioniert auch nur bedingt. DECT Telefone finden keine Basis Station mehr, andere funktionieren.
Meine Vermutung ist der DC, hier stimmt etwas nicht. DHCP und DNS laufen, habe ich geprüft. Exchange läuft auch.
Wie kann ich diesen sporadischen Fehlern auf die Schliche kommen?
DANKE
Ciao Thomas
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: 454367
Url: https://administrator.de/forum/ungewollte-ip-aenderung-am-dc-sorgt-fuer-probleme-454367.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
33 Kommentare
Neuester Kommentar
Hallo,
bekommt der DC seine IP Adresse per DHCP??
brammer
bekommt der DC seine IP Adresse per DHCP??
brammer
Moin,
oder dieser ist virtualisiert und hat eine "neue" Netzwerkkarte bekommen...
Kraemer
oder dieser ist virtualisiert und hat eine "neue" Netzwerkkarte bekommen...
Kraemer
Hallo,
nun, als erstes die Logs prüfen?
Und auch mal den Switch checken.
nun, als erstes die Logs prüfen?
Und auch mal den Switch checken.
Moin,
Kann passieren.
Warum hast Du keine Ahnung, wie und warum der DC eine IP bekommt?
Wie wurde die IP korrigiert? Händisch eingetragen? Wurde auch geprüft, ob sie im DNS korrekt eingetragen ist? Was sagt ein nslookup auf den Namen des DC und auf den Namen der Domain?
Clients? Oder User? Oder beide? Fehlermeldungen?
Heißt genau was?
Das äußerst sich wie? Und warum vermutest Du da, dass das was mit Deinem IT-Netz zu tun hat?
Wie kommst Du auf diese Vermutung?
Mit systematischer Fehleranalyse.
Bitte mehr Infos. Einträge in der Ereignissanzeige? ipconfig /all auf DC und auf Client? Fehlermeldungen? etc.
Liebe Grüße
Erik
Zitat von @thomas-99:
wir haben ein kleines Netz mit 5 verschiedenen VMs (DC, AD, Fileserver, Exchange, TK Anlage - alle W2k12R2). Es gab einen Crash.
wir haben ein kleines Netz mit 5 verschiedenen VMs (DC, AD, Fileserver, Exchange, TK Anlage - alle W2k12R2). Es gab einen Crash.
Kann passieren.
Alle VMs sind wieder Online und funktionieren. Der DC hatte allerdings eine falsche IP nach dem starten - keine Ahnung warum.
Warum hast Du keine Ahnung, wie und warum der DC eine IP bekommt?
Die IP ist wieder korrigiert und trotzdem funktioniert es nicht mehr korrekt.
Wie wurde die IP korrigiert? Händisch eingetragen? Wurde auch geprüft, ob sie im DNS korrekt eingetragen ist? Was sagt ein nslookup auf den Namen des DC und auf den Namen der Domain?
Clients können sich nicht anmelden, allerdings nicht alle.
Clients? Oder User? Oder beide? Fehlermeldungen?
Und dann funktioniert der Login wieder. Wlan funktioniert auch nur bedingt.
Heißt genau was?
DECT Telefone finden keine Basis Station mehr, andere funktionieren.
Das äußerst sich wie? Und warum vermutest Du da, dass das was mit Deinem IT-Netz zu tun hat?
Meine Vermutung ist der DC, hier stimmt etwas nicht. DHCP und DNS laufen, habe ich geprüft. Exchange läuft auch.
Wie kommst Du auf diese Vermutung?
Wie kann ich diesen sporadischen Fehlern auf die Schliche kommen?
Mit systematischer Fehleranalyse.
Bitte mehr Infos. Einträge in der Ereignissanzeige? ipconfig /all auf DC und auf Client? Fehlermeldungen? etc.Liebe Grüße
Erik
1
Nein, alle IPs sind fest vergeben. DHCP ist nur für die Clients.
Alle VMs laufen wieder und der DC hat die korrekte IP.
Ciao Thomas
Alle VMs laufen wieder und der DC hat die korrekte IP.
Ciao Thomas
... und funktioniert die Namesauflösung?
Und was bitte hat das WLAN mit einem gecrashten Microsoft Server zu tun ?? Das der von Geisterhand eine andere IP bekommt gehört sicher ins Reich der Märchen oder ist Grund einer fehlerhaften Konfiguration. Fehlerhafte dynamische IP statt statischer IP wie es für Server Usus ist.
Vermutlich wie immer: Dummes, flaches Netzwerk ohne Design und jegliche Segmentierung und irgendwo rennt da ein DHCP Server Amok und verbreitet Chaos mit Geräten und nicht passenden statischen IP Adressen oder sowas.
Wireshark ist dein Freund...!
Vermutlich wie immer: Dummes, flaches Netzwerk ohne Design und jegliche Segmentierung und irgendwo rennt da ein DHCP Server Amok und verbreitet Chaos mit Geräten und nicht passenden statischen IP Adressen oder sowas.
Wireshark ist dein Freund...!
wir haben ein kleines Netz mit 5 verschiedenen VMs (DC, AD, Fileserver, Exchange, TK Anlage - alle W2k12R2).
Du schreibst, dass ihr 5 VMs haben: DC, AD, und weitere. Der DC (DomainController) ist aber der Server, der das AD (Active Directory) beherbergt. Irgendwie passt da was nicht zusammen.
Gruß
Ralf
Hi Erik,
ich weiß nicht, warum die VM vom DC eine andere IP hatte. Die Logs geben nichts her. Ich sehe die Zeit Power Off wann es war und dann starteten alle Systeme. Alle Server haben eine feste IP.
Der DNS ist ok. nslookup habe ich auf allen Servern gestattet - die IP wird korrekt aufgelöst. Auch externe Adresse funktionieren.
Clients funktionieren - der Login klappt bei einigen, andere nicht. Der Exchange 2013 funktioniert und doch können manche User sich nicht anmelden. Es wird nach einem PW gefragt, mache Clients konnten eine Verbindung herstellen andere nicht. Es wird das PW immer wieder neu angefragt.
DECT Telefone funktionieren wieder. Die Stationen hatten teilweise eine falsche IP hinterlegt zum TK Server. TK macht eine andere Firma, dazu habe ich keine Logs usw.
Glaube noch immer, dass der DC einen Treffer hat. Ich bin auf dem DC mit VPN und RDP. RDP bricht immer mal ab, VPN nicht. Ich kann mich wieder anmelden, das kenne ich so nicht. Ein Ping von einem Client auf dem DC zeigt keine Unterbrechungen. Ein Ping vom DC auf eine externe IP zeigt Unterbrechungen - deswegen wird die Verbindung beendet. Ping vom Client auf eine externe IP zeigt keine Unterbrechungen. Daher scheidet der Provider aus. Ping vom Fileserver externe IP zeigt keine Unterbrechungen.
dcdiag zeigt einen Fehler - VerifyReferences
ipconfig /all
Error log bin ich noch dabei.
DANKE
Ciao Thomas
ich weiß nicht, warum die VM vom DC eine andere IP hatte. Die Logs geben nichts her. Ich sehe die Zeit Power Off wann es war und dann starteten alle Systeme. Alle Server haben eine feste IP.
Der DNS ist ok. nslookup habe ich auf allen Servern gestattet - die IP wird korrekt aufgelöst. Auch externe Adresse funktionieren.
Clients funktionieren - der Login klappt bei einigen, andere nicht. Der Exchange 2013 funktioniert und doch können manche User sich nicht anmelden. Es wird nach einem PW gefragt, mache Clients konnten eine Verbindung herstellen andere nicht. Es wird das PW immer wieder neu angefragt.
DECT Telefone funktionieren wieder. Die Stationen hatten teilweise eine falsche IP hinterlegt zum TK Server. TK macht eine andere Firma, dazu habe ich keine Logs usw.
Glaube noch immer, dass der DC einen Treffer hat. Ich bin auf dem DC mit VPN und RDP. RDP bricht immer mal ab, VPN nicht. Ich kann mich wieder anmelden, das kenne ich so nicht. Ein Ping von einem Client auf dem DC zeigt keine Unterbrechungen. Ein Ping vom DC auf eine externe IP zeigt Unterbrechungen - deswegen wird die Verbindung beendet. Ping vom Client auf eine externe IP zeigt keine Unterbrechungen. Daher scheidet der Provider aus. Ping vom Fileserver externe IP zeigt keine Unterbrechungen.
dcdiag zeigt einen Fehler - VerifyReferences
Starting test: VerifyReferences
[1] Problem: Erwarteter Wert nicht vorhanden.
Basisobjekt:
CN=NTDS Settings,CN=FIRMA-SRV,CN=Servers,CN=Default-First-S Sites,CN=Configuration,DC=FIRMA,DC=local
Beschreibung des Basisobjekts: "DSA-Objekt"
Attributname des Wertobjekts: serverReferenceBL
Beschreibung des Wertobjekts: "SYSVOL-FRS-Mitgliedsobjekt"
[1] Problem: Erwarteter Wert nicht vorhanden.
Basisobjekt: CN=FIRMA-SRV,OU=Domain Controllers,DC=firma,DC=local
Beschreibung des Basisobjekts: "DC-Kontoobjekt"
Attributname des Wertobjekts: msDFSR-ComputerReferenceBL
Beschreibung des Wertobjekts: "SYSVOL FRS-Mitgliedsobjekt" ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : FIRMA-SRV
Primäres DNS-Suffix . . . . . . . : firma.local
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : firma.local
Ethernet-Adapter Ethernet 3:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : XenServer PV Network Device
Physische Adresse . . . . . . . . : 2E-5E-E4-25-A4-41
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Nein
IPv4-Adresse . . . . . . . . . . : 192.168.0.1
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.0.254
DNS-Server . . . . . . . . . . . : 192.168.0.1
127.0.0.1
NetBIOS über TCP/IP . . . . . . . : Deaktiviert
Tunneladapter isatap.{E2E2AA86-FAFE-4B3D-898D-1F29C110E2FE}:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : JaError log bin ich noch dabei.
DANKE
Ciao Thomas
Moin,
ganz schön wenig infos...
0)
1)
Wie ist IP, Maske, DNS konofiguriert auf
a) Clients
b) den Servern
c) dem DC?
2)
3)
Auf dem DC schonmal dcdiag laufen lassen?
4)
lg,
Slainte
ganz schön wenig infos...
0)
Es gab einen Crash
Bedeutet was? Platten geschrottet -> Restore aus dem Backup? Stromausfall?1)
Wie ist IP, Maske, DNS konofiguriert auf
a) Clients
b) den Servern
c) dem DC?
2)
Clients können sich nicht anmelden
Bedeutet was? Fehlermeldung? Eventlogeinträge?3)
Auf dem DC schonmal dcdiag laufen lassen?
4)
DECT Telefone finden keine Basis Station mehr,
Das 100%ig nichts mit deinen Server/AD Problemen zu tun...lg,
Slainte
Hi,
Bezüglich Anmelden: Sind die Uhrzeiten auf allen Systemen korrekt und weichen nicht mehr als 5 Minuten voneinander / vom DC ab?
Gruß
Bezüglich Anmelden: Sind die Uhrzeiten auf allen Systemen korrekt und weichen nicht mehr als 5 Minuten voneinander / vom DC ab?
Gruß
1
Hi,
sag mal, kann es sein das IPs doppelt vergeben sind?
Lösen alle Rechner auch die gleiche Ip vom DC auf?
VG,
Deepsys
sag mal, kann es sein das IPs doppelt vergeben sind?
Lösen alle Rechner auch die gleiche Ip vom DC auf?
VG,
Deepsys
Tippe auch auf doppelte IP.
Gerade eine 192.168.0.1 schreit ja förmlich nach "hiiier! Nimm mich! Ich bin billig und willig!"
Gateway ist wirklich 192.168.0.254 und nicht .1 ?
Gerade eine 192.168.0.1 schreit ja förmlich nach "hiiier! Nimm mich! Ich bin billig und willig!"
Gateway ist wirklich 192.168.0.254 und nicht .1 ?
Zitat von @Ex0r2k16:
Tippe auch auf doppelte IP.
Gerade eine 192.168.0.1 schreit ja förmlich nach "hiiier! Nimm mich! Ich bin billig und willig!"
Gateway ist wirklich 192.168.0.254 und nicht .1 ?
<Satire>Tippe auch auf doppelte IP.
Gerade eine 192.168.0.1 schreit ja förmlich nach "hiiier! Nimm mich! Ich bin billig und willig!"
Gateway ist wirklich 192.168.0.254 und nicht .1 ?
Passt doch Server und Gateway mit gleicher Adresse.
</Satireende>
Gruss Penny.
1
DCDIAG am DC
Auf den nichtfunktionierenden Clients ergibt ein ipconfig -all welche Ausgabe? Sollten es einen IP-Konflikt geben, dann siehst Du es hier. Kontrolliere auch den DHCP. Möglicherweise spielt einer der APs DHCP? Hier siehst Du es.
Uhrzeit, auch ein guter Tip.
Auf den nichtfunktionierenden Clients ergibt ein ipconfig -all welche Ausgabe? Sollten es einen IP-Konflikt geben, dann siehst Du es hier. Kontrolliere auch den DHCP. Möglicherweise spielt einer der APs DHCP? Hier siehst Du es.
Uhrzeit, auch ein guter Tip.
nochwas: Je nach Switches wird nach einem Stromausfall eine andere Config geladen, wenn die falsche Standard Config beim Bootup hinterlegt ist. Leider kann ja fast jeder billig Switch mittlerweile auch DHCP. Ziemlicher Fallstrick für Anfänger.
<Satire>
Dann ist das Routing auch viel schneller wenn alles auf dem localhost intern abläuft
</Satire>
Gruß
Ex0r
Zitat von @Penny.Cilin:
<Satire>
Passt doch Server und Gateway mit gleicher Adresse.
</Satireende>
Gruss Penny.
<Satire>
Passt doch Server und Gateway mit gleicher Adresse.
</Satireende>
Gruss Penny.
<Satire>
Dann ist das Routing auch viel schneller wenn alles auf dem localhost intern abläuft
</Satire>
Gruß
Ex0r
Moin,
Heißt das, dass nach dem Absturz der DC eine andere feste IP eingetragen hatte, ohne dass jemand diese händisch geändert hat?
Liebe Grüße
Erik
Zitat von @thomas-99:
ich weiß nicht, warum die VM vom DC eine andere IP hatte. Die Logs geben nichts her. Ich sehe die Zeit Power Off wann es war und dann starteten alle Systeme. Alle Server haben eine feste IP.
ich weiß nicht, warum die VM vom DC eine andere IP hatte. Die Logs geben nichts her. Ich sehe die Zeit Power Off wann es war und dann starteten alle Systeme. Alle Server haben eine feste IP.
Heißt das, dass nach dem Absturz der DC eine andere feste IP eingetragen hatte, ohne dass jemand diese händisch geändert hat?
Liebe Grüße
Erik
Hallo,
- die IP wird korrekt aufgelöst.
Wie wurde das bewerkstelligt? Server und VMs einfach neu gebootet? An jeder VM per Hand die IP geändert? Was ar denn die falsche IP?
Ausser du meinst DECT over IP https://www.elektronik-kompendium.de/sites/net/0904221.htm und https://en.wikipedia.org/wiki/IP-DECT
Gruß,
Peter
Zitat von @thomas-99:
ich weiß nicht, warum die VM vom DC eine andere IP hatte. Die Logs geben nichts her. Ich sehe die Zeit Power Off wann es war und dann starteten alle Systeme. Alle Server haben eine feste IP.
Und diese feste IP hat sich an allen geändert oder nur am DC (diese eine VM)? Was war denn die geänderte IP?ich weiß nicht, warum die VM vom DC eine andere IP hatte. Die Logs geben nichts her. Ich sehe die Zeit Power Off wann es war und dann starteten alle Systeme. Alle Server haben eine feste IP.
Der DNS ist ok.
Das heisst alle einträge im DNS wie geprüft? Cache bereinigt usw?nslookup habe ich auf allen Servern gestattet
Wie macht man das denn? Bzw. wie macht ein nicht gestatten?- die IP wird korrekt aufgelöst.
Wie wurde das bewerkstelligt? Server und VMs einfach neu gebootet? An jeder VM per Hand die IP geändert? Was ar denn die falsche IP?
DECT Telefone funktionieren wieder
DECT selbst hat mit IP Adressen null am Hut, bzw. kennt diese nicht.https://de.wikipedia.org/wiki/Digital_Enhanced_Cordless_Telecommunicatio ...Ausser du meinst DECT over IP https://www.elektronik-kompendium.de/sites/net/0904221.htm und https://en.wikipedia.org/wiki/IP-DECT
Glaube noch immer, dass der DC einen Treffer hat. Ich bin auf dem DC mit VPN und RDP. RDP bricht immer mal ab, VPN nicht.
Nun, wer macht VPN und wer macht RDP?Ich kann mich wieder anmelden, das kenne ich so nicht.
Das ist doch normal das man sich immer wieder anmelden kann.Ein Ping von einem Client auf dem DC zeigt keine Unterbrechungen. Ein Ping vom DC auf eine externe IP zeigt Unterbrechungen
Einmal Traffiv´c im LAN und einmal Traffic im Internet, Das kannst du nicht miteinander vergleichen. Im LAN hast du die Kontrolle über allen Geräten. Im WAN kennst du noch nicht mal alle beteiligten.- deswegen wird die Verbindung beendet.
Nur wenn dein Gegenspieler dieser Verbindung deine Externe IP ist die immer mal wieder abbricht.Ping vom Client auf eine externe IP zeigt keine Unterbrechungen.
Lässt deinen DC im schlechten Licht darstehen DNS-Server . . . . . . . . . . . : 192.168.0.1
127.0.0.1
Die 127.0.0.1 ist ein Idealer 2ter DNS 127.0.0.1
Gruß,
Peter
Zu deinem DCDIAG Fehler schau dir mal folgenden Link an
https://www.mcseboard.de/topic/189636-dcdiag-frscomputerreferencebl/
Naheliegende Fehler wären:
DHCP Server ist nicht mehr im Active Directory freigegeben->Adressen werden nicht verteilt.
Das als erstes prüfen, mmc aufrufen, Autorisierte Server verwalten, alles alte rauslöschen, DC neu hinzufügen, ggf. Fehler analysieren falls welche auftreten. Wahrscheinlich passt dein Binding nicht mehr zum Netzwerkadapter des DC.
Zeitserver funktioniert nicht, daher Abweichungen der Zeit auf den Clients->Keine Anmeldung möglich.
Check mal mit Net time und w32tm ob die Zeit auf den Clients ordentlich mit dem DC synct, ohne das geht Kerberos nicht.
Exchange Error mit PW neu eingabe deutet darauf hin das dein Autodiscover nicht funktioniert. Check am Outlook Client mit Strg+Shift Rechtsklick auf dem Tray Symbol mal deine Autokonfiguration und schau ob die sauber durchläuft.
Ggf. läuft DNS aber dir fehlt der SRV Eintrag um den Autodiscover Dienst zu finden.
Wenn man sich auf dem DC befindet ist das sogar Windows Standard.
Das man Radius mit dem NPS Dienst von Windows macht ist nichts ungewöhnliches. Wenn dann ein Server crasht und das Passwort ist ein altes würde es nicht mehr funktionieren.
https://www.mcseboard.de/topic/189636-dcdiag-frscomputerreferencebl/
Naheliegende Fehler wären:
DHCP Server ist nicht mehr im Active Directory freigegeben->Adressen werden nicht verteilt.
Das als erstes prüfen, mmc aufrufen, Autorisierte Server verwalten, alles alte rauslöschen, DC neu hinzufügen, ggf. Fehler analysieren falls welche auftreten. Wahrscheinlich passt dein Binding nicht mehr zum Netzwerkadapter des DC.
Zeitserver funktioniert nicht, daher Abweichungen der Zeit auf den Clients->Keine Anmeldung möglich.
Check mal mit Net time und w32tm ob die Zeit auf den Clients ordentlich mit dem DC synct, ohne das geht Kerberos nicht.
Exchange Error mit PW neu eingabe deutet darauf hin das dein Autodiscover nicht funktioniert. Check am Outlook Client mit Strg+Shift Rechtsklick auf dem Tray Symbol mal deine Autokonfiguration und schau ob die sauber durchläuft.
Ggf. läuft DNS aber dir fehlt der SRV Eintrag um den Autodiscover Dienst zu finden.
Wenn man sich auf dem DC befindet ist das sogar Windows Standard.
Das man Radius mit dem NPS Dienst von Windows macht ist nichts ungewöhnliches. Wenn dann ein Server crasht und das Passwort ist ein altes würde es nicht mehr funktionieren.
Hallo Zusammen,
es ist alles ganz anders als vermutet und noch immer besteht der Fehler. Es gibt keine doppelten IPs und ähnliches. Alle Server haben unterschiedliche feste IPs.
Ich habe beim DC Aussetzer im Ping z.b. auf den Gateway. Ein andere VM (Exchange) hat keine Aussetzer im Ping auf den Gateway! Merkwürdig!
Auf der Konsole vom Hypervisor läuft der Ping auf den Gateway durch. Keine Aussetzer!
Damit ist der Switch nicht das Problem.
Wird noch besser, denn ein Ping vom Client auf dem DC läuft ebenfalls durch! Ping von anderem Server auf den DC laufen durch - keine Aussetzer.
Ich habe den DC2 auf einen anderen Hypervisor verschoben. Wollte eine Ausfallversicherung, falls der DC irgendwann keine Datenpakete mehr sendet.
Grundsätzlich läuft alles wieder, allerdings mit Aussetzern. In einer guten Phase klappt alles - eine Stunde - DNS funktioniert, Anmeldungen und Exchange ist verfügbar.
Dann kommt es zu den Aussetzern. Wenn der DC keine Anfragen beantwortet, dieser allerdings erreichbar ist, hat der DC2 keine Chance - als Failover? Der würde nur einspringen, wenn der DC tot ist?
Wie auch immer, der DC darf keine Aussetzer haben.
Ich weiß nicht, wie ich hier das eingrenzen kann und den Fehler finden soll? Es sind ja keine NICs - ist ja alles virtualisiert.
DANKE
Ciao thomas
es ist alles ganz anders als vermutet und noch immer besteht der Fehler. Es gibt keine doppelten IPs und ähnliches. Alle Server haben unterschiedliche feste IPs.
Ich habe beim DC Aussetzer im Ping z.b. auf den Gateway. Ein andere VM (Exchange) hat keine Aussetzer im Ping auf den Gateway! Merkwürdig!
Auf der Konsole vom Hypervisor läuft der Ping auf den Gateway durch. Keine Aussetzer!
Damit ist der Switch nicht das Problem.
Wird noch besser, denn ein Ping vom Client auf dem DC läuft ebenfalls durch! Ping von anderem Server auf den DC laufen durch - keine Aussetzer.
Ich habe den DC2 auf einen anderen Hypervisor verschoben. Wollte eine Ausfallversicherung, falls der DC irgendwann keine Datenpakete mehr sendet.
Grundsätzlich läuft alles wieder, allerdings mit Aussetzern. In einer guten Phase klappt alles - eine Stunde - DNS funktioniert, Anmeldungen und Exchange ist verfügbar.
Dann kommt es zu den Aussetzern. Wenn der DC keine Anfragen beantwortet, dieser allerdings erreichbar ist, hat der DC2 keine Chance - als Failover? Der würde nur einspringen, wenn der DC tot ist?
Wie auch immer, der DC darf keine Aussetzer haben.
Ich weiß nicht, wie ich hier das eingrenzen kann und den Fehler finden soll? Es sind ja keine NICs - ist ja alles virtualisiert.
DANKE
Ciao thomas
Merkwürdig!
Merkwürdigkeiten gibts eigentlich in der IT nicht... Hast du diese Aussetzer nur wenn du via vSwitch, sprich also rein nur in der virtuellen Umgebung pingst und keine externe Switch bzw. Netzwerk Infrastruktur nutzt ?
Dann hast du in der Tat einen Fehler in der Hardware, eine Überlast auf dem Server der die Virtualisierung hält oder falsche virtuelle NIC Karten verwendet.
Was anderes bleibt ja nicht mehr über.
Ja merkwürdig gibt es in der IT nicht und doch gibt es manchmal Eigenarten ... die nur schwer zu durchschauen sind.
Die Hardware - also der Server selber - hat zwei genutzte NICs, eine für die Verwaltung und der andere für den Zugriff auf die Infrastruktur.
Die Verwaltung ist hier außen vor.
Die andere NIC zeigt keine Unterbrechungen, wenn ich vom Hypervisor auf den Gateway einen Ping setze. Bedeutet, der Switch zwischen Server Hardware und Gateway einschließlich Patchkabel machen, was sie sollen. Selbst die anderen VMs (Exchange, Filierter usw.) haben keine Unterbrechungen zum Gateway. Der Ping von einem Client zum Gateway läuft ebenso.
Nur der DC hat diese Aussetzer. Ist die Frage, ob W2K12 (als Software auf den Hypervisor) einen Treffer hat oder vSwitch oder?
Die Last von dem Server liegt bei 30% im Schnitt, am Wochenende ehr bei 10%. Heute hat keiner gearbeitet = keine Last und doch gab es die Aussetzer. Habe die Treiber neu installiert, die NICs deaktiviert und neu eingerichtet, neue MAC Adressen ... hat alles nichts geholfen.
Mir gehen die Optionen aus ....
Die Hardware - also der Server selber - hat zwei genutzte NICs, eine für die Verwaltung und der andere für den Zugriff auf die Infrastruktur.
Die Verwaltung ist hier außen vor.
Die andere NIC zeigt keine Unterbrechungen, wenn ich vom Hypervisor auf den Gateway einen Ping setze. Bedeutet, der Switch zwischen Server Hardware und Gateway einschließlich Patchkabel machen, was sie sollen. Selbst die anderen VMs (Exchange, Filierter usw.) haben keine Unterbrechungen zum Gateway. Der Ping von einem Client zum Gateway läuft ebenso.
Nur der DC hat diese Aussetzer. Ist die Frage, ob W2K12 (als Software auf den Hypervisor) einen Treffer hat oder vSwitch oder?
Die Last von dem Server liegt bei 30% im Schnitt, am Wochenende ehr bei 10%. Heute hat keiner gearbeitet = keine Last und doch gab es die Aussetzer. Habe die Treiber neu installiert, die NICs deaktiviert und neu eingerichtet, neue MAC Adressen ... hat alles nichts geholfen.
Mir gehen die Optionen aus ....
Debug logging für den vSwitch einschalten wâre eine Option
Dann kommt es zu den Aussetzern. Wenn der DC keine Anfragen beantwortet, dieser allerdings erreichbar ist, hat der DC2 keine Chance - als Failover? Der würde nur einspringen, wenn der DC tot ist?
Dann fahre doch einfach mal DC1 herunter und gucke was passiert.DC2 übernimmt dann ja normalerweise.
Wenn dann alles wieder läuft, setzt du einen DC auf ein aktuellerem Windows Server auf, später dann auch DC2 hochziehen und dann die AD-Struktur auch hochleveln.
VG,
Deepsys
Hast du denn schonmal versucht, die NIC im DC zu entfernen und neu zu "installieren"? Ggfs. auch mal die Intetgrationstools (oder wir auch immer das sich bei XenServer nennt) neu zu installieren?
Nebenbei: Die Konfig für den DNS Client ist nicht ganz nach BP.. DNS 1 = "der andere DC", DNS 2 = "127.0.0.1" wäre korrekt.
Nebenbei: Die Konfig für den DNS Client ist nicht ganz nach BP.. DNS 1 = "der andere DC", DNS 2 = "127.0.0.1" wäre korrekt.
Habe die XenServer Tools deinstalliert und neu installiert. Habe den DC runter gefahren und dachte, der DC2 macht seinen Job. Falsch gedacht. DNS teilweise nicht erreichbar (DC ist ein anderer Server Hardware) Es wurde vorher alles repliziert, es gab keine Fehler. Und doch klappt es nicht wirklich zufriedenstellend.
DC wieder gestartet und es funktionierte - nicht lange. DC war Online, auf dem DC nslookup gestartet alles ok. Konnte alles auflösen auch externe Domains. Von den anderen Servern funktionierte es sporadisch. Ohne Änderungen war Zugriff von Servern auf den DC da und dann nicht mehr.
Ich habe nachgesehen, warum der Zugriff nicht möglich war. Teilweise waren UDP und TCP Ports nicht verfügbar.
Habe dann die FW deaktiviert auf allen Servern. Das brachte keine Änderung. Hat der Exchange eine Verbindung zum DC, klappt alles. Der Fileserver im selben vSwitch kommt plötzlich nicht zum DC durch. Es fehlen wieder Ports.
Warum diese Ports? Kann man Ports überwachen - kein Portscanner - mehr Monitoring auf Portebene?
Bringt ja nichts, die Ports zu überwachen. Die müssen erreichbar sein.
Weiß noch immer nicht, ob der DC den Ärger macht oder vSwitch oder Hypervisor oder?
Am Client habe ich:
DNS1 = DC mit DNS
DNS2 = DC2
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
DC wieder gestartet und es funktionierte - nicht lange. DC war Online, auf dem DC nslookup gestartet alles ok. Konnte alles auflösen auch externe Domains. Von den anderen Servern funktionierte es sporadisch. Ohne Änderungen war Zugriff von Servern auf den DC da und dann nicht mehr.
Ich habe nachgesehen, warum der Zugriff nicht möglich war. Teilweise waren UDP und TCP Ports nicht verfügbar.
UDP port 137 (netbios-ns service)
UDP port 138
TCP port 42 (nameserver service)
UDP port 88 (kerberos service)
UDP port 53 (domain service)Habe dann die FW deaktiviert auf allen Servern. Das brachte keine Änderung. Hat der Exchange eine Verbindung zum DC, klappt alles. Der Fileserver im selben vSwitch kommt plötzlich nicht zum DC durch. Es fehlen wieder Ports.
Warum diese Ports? Kann man Ports überwachen - kein Portscanner - mehr Monitoring auf Portebene?
Bringt ja nichts, die Ports zu überwachen. Die müssen erreichbar sein.
Weiß noch immer nicht, ob der DC den Ärger macht oder vSwitch oder Hypervisor oder?
Zitat von @SlainteMhath:
Nebenbei: Die Konfig für den DNS Client ist nicht ganz nach BP.. DNS 1 = "der andere DC", DNS 2 = "127.0.0.1" wäre korrekt.
Nebenbei: Die Konfig für den DNS Client ist nicht ganz nach BP.. DNS 1 = "der andere DC", DNS 2 = "127.0.0.1" wäre korrekt.
Am Client habe ich:
DNS1 = DC mit DNS
DNS2 = DC2
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Moin,
Wie jetzt? Du hast als zweiten DNS einen DC eingestellt, auf dem gar kein DNS läuft? Dann ist das kein Wunder, wenn nichts richtig geht.
Liebe Grüße
Erik
Zitat von @thomas-99:
Am Client habe ich:
DNS1 = DC mit DNS
DNS2 = DC2
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Am Client habe ich:
DNS1 = DC mit DNS
DNS2 = DC2
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Wie jetzt? Du hast als zweiten DNS einen DC eingestellt, auf dem gar kein DNS läuft? Dann ist das kein Wunder, wenn nichts richtig geht.
Liebe Grüße
Erik
Zitat von @SlainteMhath:
Nebenbei: Die Konfig für den DNS Client ist nicht ganz nach BP.. DNS 1 = "der andere DC", DNS 2 = "127.0.0.1" wäre korrekt.
Nebenbei: Die Konfig für den DNS Client ist nicht ganz nach BP.. DNS 1 = "der andere DC", DNS 2 = "127.0.0.1" wäre korrekt.
Am Client habe ich:
DNS1 = DC mit DNS
DNS2 = DC2
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Nebenbei 2: DNS macht kein "klassisches" transparentes Failover. Wenn DNS1 nicht antwortet gibt's ne Fehlermeldung und dann wird DNS2 gefragt. Das dauert dann u.U. auch länger, da erst der timeout ablaufen muss etc.
Hallo,
Und da auch im AD fast alles über Namensauflösungen läuft ist ein DNS notwendig und unerlässlich. Deshalb die Frage - warum keinen DNS auf DC 2? Es muss nicht zwingend ein MS DNS sein, kann auch ein Linux mit einen DNServer sein, aber ein MS DNServer macht alles was deine Domäne haben will, bei Linux musst du schon wissen was du alles per nad in dein DNServer eintragen musst damit es mit deiner Domäne klappt.
https://www.serverlab.ca/tutorials/linux/network-services/using-linux-bi ...
https://superuser.com/questions/247560/linux-dns-for-windows-domain
https://community.spiceworks.com/topic/575447-dns-on-linux-vs-windows
Gruß,
Peter
Zitat von @thomas-99:
Am Client habe ich:
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Du meinst sicherlich wenn der Client deinen DC1 nicht findet, soll er DC2 nutzen um die DNS auflösung zu machen. Aber auf DC2 ist kein DNS, Was soll dir das also bringen, ausser Timeouts? Oder soll, wenn dein Client den DC1 nicht findet (Warum sollte er den nicht finden?), dann den DNS 2 anfragen welcher auf irgendeine deiner Maschinen werkelt? Du weisst wie ein DNS arbeitet? Wenn dein DNS 1 sagt er hat für deine Anfrage (z.B. welche IP hat www.aldi.de) keine IP dann kommt es auf deine Konfiguration an wie weiter verfahren wird. Und bei dir steht ja als DNS die IP von DC 1 und als IP von DNS 2 eine Loopback 127.0.0.1 drin, also sollte dc 1 mit seinen DNS 1 offline sein wird DNS 2 sofort gefragt (aufgrund weil DC 1 und DNS 1 eben nicht am laufen sind). Sollte DC 1 mit DNS 1 aber laufen und dir sagen das es www.aldi.de nicht kennt, gibt es auch keinen Timeout weil deine DNS Anfrage ja korrekt beantwortet wurde, auch wenn dir die Antwort nicht gefällt - geantwortet hat er ja. Alles aus sicht eines Clients.Am Client habe ich:
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Und da auch im AD fast alles über Namensauflösungen läuft ist ein DNS notwendig und unerlässlich. Deshalb die Frage - warum keinen DNS auf DC 2? Es muss nicht zwingend ein MS DNS sein, kann auch ein Linux mit einen DNServer sein, aber ein MS DNServer macht alles was deine Domäne haben will, bei Linux musst du schon wissen was du alles per nad in dein DNServer eintragen musst damit es mit deiner Domäne klappt.
https://www.serverlab.ca/tutorials/linux/network-services/using-linux-bi ...
https://superuser.com/questions/247560/linux-dns-for-windows-domain
https://community.spiceworks.com/topic/575447-dns-on-linux-vs-windows
Gruß,
Peter
Wie jetzt? Du hast als zweiten DNS einen DC eingestellt, auf dem gar kein DNS läuft? Dann ist das kein Wunder, wenn nichts richtig geht.
Ja hatte ich versucht, den DC2 auf DC1 im DNS zu setzen. Das ist natürlich Unsinn. Habe das wieder geändert.
Nebenbei 2: DNS macht kein "klassisches" transparentes Failover. Wenn DNS1 nicht antwortet gibt's ne Fehlermeldung und dann wird DNS2 gefragt. >Das dauert dann u.U. auch länger, da erst der timeout ablaufen muss etc.
Gibt es eine Möglichkeit den DNS (DC1) als echten Failover zu betreiben? Also Ausfall und sofort wird DC2 einbezogen?
Der Exchange will so garnicht mit dem DC2 arbeiten. Wenn ich den DNS auf DC2 ändere, stehen alle Räder still. Muss ich im Exchange den DC2 repetieren, autorisieren oder sonst welche Dinge tun? Habe dazu nichts gefunden.
Zitat von @thomas-99:
Am Client habe ich:
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Du meinst sicherlich wenn der Client deinen DC1 nicht findet, soll er DC2 nutzen um die DNS auflösung zu machen. Aber auf DC2 ist kein DNS, Was soll dir das also bringen, ausser Timeouts? Oder soll, wenn dein Client den DC1 nicht findet (Warum sollte er den nicht finden?), dann den DNS 2 anfragen welcher auf irgendeine deiner Maschinen werkelt? Du weisst wie ein DNS arbeitet? Wenn dein DNS 1 sagt er hat für deine Anfrage (z.B. welche IP hat www.aldi.de) keine IP dann kommt es auf deine Konfiguration an wie weiter verfahren wird. Und bei dir steht ja als DNS die IP von DC 1 und als IP von DNS 2 eine Loopback 127.0.0.1 drin, also sollte dc 1 mit seinen DNS 1 offline sein wird DNS 2 sofort gefragt (aufgrund weil DC 1 und DNS 1 eben nicht am laufen sind). Sollte DC 1 mit DNS 1 aber laufen und dir sagen das es www.aldi.de nicht kennt, gibt es auch keinen Timeout weil deine DNS Anfrage ja korrekt beantwortet wurde, auch wenn dir die Antwort nicht gefällt - geantwortet hat er ja. Alles aus sicht eines Clients.Am Client habe ich:
Und das über DHCP eingestellt. Wenn der Client den DC mit DNS nicht findet, soll er DC2 verwenden. Falsch?
Und da auch im AD fast alles über Namensauflösungen läuft ist ein DNS notwendig und unerlässlich. Deshalb die Frage - warum keinen DNS auf DC 2? Es muss nicht zwingend ein MS DNS sein, kann auch ein Linux mit einen DNServer sein, aber ein MS DNServer macht alles was deine Domäne haben will, bei Linux musst du schon wissen was du alles per nad in dein DNServer eintragen musst damit es mit deiner Domäne klappt.
Ich weiß, wie eng AD und DC im DNS verankert sind. Der DC2 hat einen DNS Server, der auch funktioniert und nslookup alles korrekt wiedergibt. Der DC1 ist ist zu keiner zeit Offline. Ein Server ist mit dem DNS verbunden, der andere zeigt "unbekannt" im nslookup. Alle sind verbunden über feste IPs und durchweg per Ping zu erreichen.
Aber wie schon geschrieben, sind die Ports vom DC1 nicht verfügbar. Warum? Das verstehe ich nicht. Keine Firewall funkt dazwischen. Ich ändere nichts, frage über nslookup den Staus ab, Fileserver alles i.O., Exchange keine Verbindung. Teste ich die Ports, sind diese vom Exchange nicht nicht erreichbar. Und dann ohne Änderungen sind sie wiederverfügbar.
Wichtig wäre es, wenn ich den Exchange auf den DNS2 vom DC2 umstelle und den DC1 ausführlich zu testen.
Hat jemand eine Idee?
DANKE
ciao thomas
Hallo,
Kann es sein das du nicht das Wissen hast um hier gezielt vorzugehen, oder zu Erkennen was du wo Einstellst und warum es dann irgendwie etwas zerbröselt? Nicht Büse sein, aber wäre es nicht hilfreicher wenn sich das jemand vor Ort mit dir zusammen anschaut und von dem du abgucken kannst?
Gruß,
Peter
Zitat von @thomas-99:
Gibt es eine Möglichkeit den DNS (DC1) als echten Failover zu betreiben? Also Ausfall und sofort wird DC2 einbezogen?
Ja.Gibt es eine Möglichkeit den DNS (DC1) als echten Failover zu betreiben? Also Ausfall und sofort wird DC2 einbezogen?
Ich weiß, wie eng AD und DC im DNS verankert sind. Der DC2 hat einen DNS Server, der auch funktioniert
Sagst du nicht selbst das DC 2 keinen DNServer hat?Ein Server ist mit dem DNS verbunden, der andere zeigt "unbekannt" im nslookup.
Im nslookup? Schau mal warum nslookup unbekannt sagt (Das ist nichts um sich sorgen zu machen)Aber wie schon geschrieben, sind die Ports vom DC1 nicht verfügbar. Warum?
Wie und womit hast du festgestellt das vom DC1 die Ports (Welche) nicht verfügbar sind? Ist aber dann ein ganz anderes zusätzliches Problem.frage über nslookup den Staus ab, Fileserver alles i.O., Exchange keine Verbindung. Teste ich die Ports, sind diese vom Exchange nicht nicht erreichbar. Und dann ohne Änderungen sind sie wiederverfügbar.
!?!Wollte eine Ausfallversicherung
Dann geh zum Versicherungsmakler.Kann es sein das du nicht das Wissen hast um hier gezielt vorzugehen, oder zu Erkennen was du wo Einstellst und warum es dann irgendwie etwas zerbröselt? Nicht Büse sein, aber wäre es nicht hilfreicher wenn sich das jemand vor Ort mit dir zusammen anschaut und von dem du abgucken kannst?
Gruß,
Peter
Evtl. ist das ein Problem mit deinem Hypervisor...
=> dort schonmal Logs geprüft? Firewall-einstellungen gecheckt? Ggfs. mal einen komplett neuen vSwitch eingerichtet und die Gäste mit dem verbunden?
Oder ein L2 Problem in deinem Netzwerk?
=> Was sagen denn die Logs von deinem Hardware-Switch(en) an den(en) der/dir Hypervisor(en) hängen?
Kann auch sein das an dem DC(1?) der tcp Stack mal einen Reset braucht... findet man über google
Ok, mach mal folgendes auf BEIDEN DCs
1) ein "ipconfig /flushdns" und dann ein "ipconfig /registerdns"
2) nslookup <fqdn deiner AD Domäne>
3) dcdiag
Und dann bitte das (anonymisierte) Ergebnis von 2) und 3) posten. Bei 3 bitte nur die Fehler die aufgetreten sind.
=> dort schonmal Logs geprüft? Firewall-einstellungen gecheckt? Ggfs. mal einen komplett neuen vSwitch eingerichtet und die Gäste mit dem verbunden?
Oder ein L2 Problem in deinem Netzwerk?
=> Was sagen denn die Logs von deinem Hardware-Switch(en) an den(en) der/dir Hypervisor(en) hängen?
Kann auch sein das an dem DC(1?) der tcp Stack mal einen Reset braucht... findet man über google
Ein Server ist mit dem DNS verbunden, der andere zeigt "unbekannt" im nslookup.
Du solltest echt mal versuchen dich technisch korrekt auszudrücken... was bedeutet denn "mit dem DNS verbunden"?? und bei welcher Gelgenheit zeigt "der andere" "unbekannt!"??Ok, mach mal folgendes auf BEIDEN DCs
1) ein "ipconfig /flushdns" und dann ein "ipconfig /registerdns"
2) nslookup <fqdn deiner AD Domäne>
3) dcdiag
Und dann bitte das (anonymisierte) Ergebnis von 2) und 3) posten. Bei 3 bitte nur die Fehler die aufgetreten sind.
OK, es war alles etwas ganz anderes! Ein defekter Treiber hatte stellenweise für eine Auslastung von 100% erzeugt!!!!!
Der Server hat versucht einen Treiber zu laden, was nicht klappte. Dadurch wurde der RAM voll ausgelastet und der DC war bei 100% CPU.
Offensichtlich hat W2K12 diese Auslastung alleine zurückgesetzt und der Server war bei 5%.
Immer wenn der Server bei 100% war, konnte er keine DNS Anfragen beantworten, AD war nicht erreichbar, Ports geschlossen usw.
Wenn der Server das unterbrochen hat, lief er wieder. .... bis er wieder bei 100% war und von vorn. Ich habe den Dienst angehalten und seit dem ist Ruhe.
So einfach ..... und doch so kompliziert!
Danke euch für eure Hilfe!!
Ciao thomas
Der Server hat versucht einen Treiber zu laden, was nicht klappte. Dadurch wurde der RAM voll ausgelastet und der DC war bei 100% CPU.
Offensichtlich hat W2K12 diese Auslastung alleine zurückgesetzt und der Server war bei 5%.
Immer wenn der Server bei 100% war, konnte er keine DNS Anfragen beantworten, AD war nicht erreichbar, Ports geschlossen usw.
Wenn der Server das unterbrochen hat, lief er wieder. .... bis er wieder bei 100% war und von vorn. Ich habe den Dienst angehalten und seit dem ist Ruhe.
So einfach ..... und doch so kompliziert!
Danke euch für eure Hilfe!!
Ciao thomas
