RogerG781

Zunächst einmal, würde es nicht mehr Sinn machen, wenn sich der User auf einen Client aufschalten kann, von dem aus er bestimmte Serverdienste nutzen kann? Ein aufschalten auf den Server halte ich für absolut problematisch. Naja, die GPO muss schon vom Server gelesen werden können, dass heißst du musst die GPO mit der OU verknüpfen, indem sich auch das Server Objekt befindet. Du kannst die GPO so einschränken, dass die definierten Regeln nur für dieses Serverobjekt gelten. Schau dir dazu auch folgenden Eintrag an: http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

denke auch, das du ggf. für spätere Aufgaben den Server vernünftig gegen Fehlbedienung sichern solltest. Auch ein WS2012 kann sein Dienst quittieren, wenn dieser unerwartet ausgeschaltet wird.

Ja, doppelte ARP-Adressen war ja von Beginn an ein Thema und evtl. auch eine Vermutung. Nachdem die Logs gesichtet, zeitweise eine andere NIC (ohne Virtualsierung) eingesetzt wurde, konnten keine doppelten MAC Adressen ermittelt werden. Auch Wireshark förderte in diese Richtung nichts ungewöhnliches zu Tage. Danke für den Link.

Hallo Light, ja es sind VMs, aber auf Basis von Hyper-V. Das Problem bestand aber unabhänig davon, auch auf einem Standalone WS2012R2/WS2016TP5 ohne aktivierte Rollen/Features. Problem wurde mittlerweile gefunden. Es lag an einer externen Firewall, diese war wohl so konfiguriert, dass Pakete an nicht bekannte IPs als ungültig beantwortet wurden. ​Allerdings ist das immer noch ziemlich unbefriedigend. Es stellen sich immer noch zwei Fragen: 1. Warum der Server nicht schneller als die Fw geantwortet hat. 2. Wieso es nur Auswirkungen auf WS2012R2/WS2016TP5 hatte, Linux Server hatten mit den gleichen IPs bei zuvor gleicher Fw Konfiguration keine Schwierigkeiten. Wenn da noch jemand was zu beitragen kann, wäre super ;)

Nein, ich meinte auch nicht damit, dass es am Dienstleister "liegt" sondern eher, dass dort z.Zt. keine Notwendigkeit für weitere Tests gesehen wird, weil aus deren Sicht alles läuft. Ob ich allerdings des Rätsels Lösung jemals präsentieren kann, ist ungewiss. Nachdem der Dienstleister erneut kontaktiert wurde, kam von dort zwar eher Ratlosigkeit, aber seitdem sind die Systeme wieder On. Bin erstmal vorsichtig optimistsich und hoffe, das bleibt auch so. Generell ist es aber doch sehr spannend zu sehen, dass die öffentlichen IPs auf anderen Host/VMs liefen und auf dem eigenen nicht. Warum es jetzt z.Zt. geht entzieht sich allerdings meiner Kenntniss ;) Sollte ich noch was in Erfahrung bringen, gebe ich es gerne weiter.

Hallo Ralf, ich denke auch das es kein Hardware Defekt ist, da ja eine zweite NIC zum selben verhalten führt. Aber ein wenig problematisch ist die Tatsache, dass sobald die IP einer anderen VM auf einem anderen Host zugeordnet wird,sofort einwandfrei funktioniert und erreichbar ist. Und das ist auf dem besagten Host bei unterschiedlichen VMs immer nur sehr kurzeitig der Fall, sobald der arp cache gelöscht wird. Beide unterscheiden sich in der Hardware und auch Virtualisierungslösung. Soweit ich weiß kommt KVM bei dem anderen System zum Einsatz. Und da gehen mir dann ein wenig die Argumente aus, wieso es am Dienstleister davor liegen sollte. :( Ich werde mal schauen, ob ich über Wireshark mehr Informationen ermitteln kann.

Hallo Ralf, der vorgelagerte Switch hatte keine Auffälligkeiten wurde aber auch mal komplett rausgenommen und umgangen. Der Server ist in einem Rack mit mehreren Servern. Die anderen Server können über die gleiche Verbindung problemlos erreicht werden, sowohl ein- als auch ausgehend. Testweise wurde die IP auch mal einem anderen Server im selben Subnetz zugeordnet. Diese ist dann erreichbar. Sobald diese wieder auf dem eigentlichen Server gebunden wird, bleibt es beim beschriebenen Verhalten. Auf die restliche vorgelagerte Technik habe ich keinen Zugriff. Da es aber bei anderen Servern funktioniert, scheint das Problem eher Serverseitig zu bestehen :(

Hab es in den Einstellungen deaktiviert, Server neu gestartet. Verhalten bleibt identisch, 1. Ping geht durch der Rest nicht. Allerdings ist es derzeit eine Standard WS2012R2 Installation ohne aktivierte Hyper-V Rolle.

Integrierte auf dem Mainboard ist eine Intel i350 dual LAN. weiterer getesteter Adapter ist ein HP NC360T Dual Port 1GB mit Intel 82571EB Chip. Die integrierte hab ich mir aktuellen treibern versorgt, bei der externen gibt es nur einen Treiber der älter als der Windows integrierte ist.

Hallo Freunde, derzeit evaluiere ich einen Windows SErver 2016 TP5 (installiertes CU 14.06.16). Das ganze auf einem Intel S2600CP2 Board mit Xeon CPU. Der Server verfügt über aktivierte Hyper-V Rolle mit einigen VMs. Zwei VMs haben öffentliche IP Adressen. Das ganze lief einige Wochen ohne Ausfälle oder Probleme. An einem Donnerstag ohne vorherige Patch Installation oder Wartung am Server waren die VMs mit den öffentlichen IPs nur noch sporadisch erreichbar. Mal waren die IPs erreichbar, dann wieder nicht, dies ging einige Zeit so weiter. :( Nun habe ich zunächst vermutet, es gibt evtl. noch Probleme mit der TP5. Also alle VMs abgeschaltet, Server 2012 R2 installiert. Hyper-V Rolle installiert VMs darauf hochgezogen, doch es gab keine Änderung. Die VMs waren weiterhin nur sporadisch erreichbar. Danach dann folgende Maßnahmen durchgeführt: 1. Da es eine interne NIC war, BIOS Update mit anschließendem BIOS Reset und mehrere Minuten vom Strom getrennt 2. Andere NIC installiert 3. Andere IP ausprobiert 4. wie bereits geschrieben, andere Windows Server Version installiert 5. kompletten Intel Server mit Intel Confidence Tool gecheckt Es brachte keine Änderung. Also alle VMs ausgeschaltet und den Host selbst mit einer öffentlichen IP ausgestattet. Auch dieser war nicht erreichbar. Nachdem ich auf dem Server den Befehl: netsh interface ip delete arpcache absetze geht ein Ping durch und beim nächsten erfolgt Zeitüberschreitung. Das kann ich beliebig öft wiederholen, arp cache löschen, 1. Ping geht durch die restlichen wieder nicht. :confused: Neu Installation von WS2012R2. Keine Rollen aktiviert, sondern nur die NIC mit einer öffentlichen IP konfiguriert. Problem bleibt allerdings bestehen, erster Ping geht nach löschen des Arp cache durch, der Rest wieder nicht. Sowohl von intern nach extern, als auch umgekehrt. Also Server 2016 TP5 noch mal installiert und damit getestet, keine Änderung. Nach beiden Installationen keine Rollen oder Features installiert, nur in den Firewall Einstellungen ICMP erlaubt. Es bleibt dabei, wenn ich den arp cache lösche, geht der erste Ping sowohl von intern nach extern als auch umgekehrt durch. Danach Timeout. Habt ihr einen Tipp, wo ich den Fehler suchen soll?

Danke für die Info, kommt mit auf die ToDo und wird morgen erledigt. ;)

So, konnte das Problem zwischenzeitlich lösen. Den Support hatte ich nicht eingeschaltet. DCDiag war bei der Spurensuche im ganzen Goldwert Auf beiden DCs wurden Sysvol und Netlogon nicht gemappt. Während auf dem WDC1 das Domainverzeichnis vorhanden war, wurde auf dem WDC2 mittlerweile ein Preexisting Domainverzeichnis angezeigt. Diese konnte ich zunächst mit der 2. Lösung aus dem Artikel https://support.microsoft.com/en-us/kb/958804 lösen. Nach einem manuellen Neustart des NTFRS-Dienstes wurden die Verzeichnise wieder gemappt und das Netzwerk mit bisheriger Konfiguration (ohne Gateway) als Domainnetwork erkannt. Auf dem WDC1 war nun noch die Löschung der ProfileList notwendig und nach einem Neustart wurde auch dort das Netzwerk wieder korrekt eingestuft. Nun werde ich noch die Replikation prüfen und das ganze ins Backup einfügen.

Hallo, vielen Dank, habe ich soeben auch gelesen. Hatte gehofft, dort evtl. noch andere Mitleser zu erreichen.

Vielen Dank für deine Hilfe. Das komplette bereinigen habe ich nochmal ausprobiert. Es hat leider keinen Effekt. Auch die Einstufung in den bereits erstellten bzw. neu erstellten Profile der Category 2 führt zwar dazu, dass es zumindest als Privat erkannt wird, aber nicht als Domainnetwork. Nach einem Neustart setzt das System den Wert auf 0 Public zurück und ich stehe wieder am Anfang. Die Logs sind ja weitesgehend sauber, aber die Einstufung und das Mappen der Verzeichnisfreigaben erfolgt in keinem Fall. Aus dem letzten Link hatte ich bereits die Einstufung über die Lokale Richtlinie und eben Registry versucht, aber es erzielt kein Ergebnis. Die Einstufung als Domainnetwork erfolgt ja normalerweilse automatisch beim Start. Weiß jemand welche Dienste bereits fehlerfrei gestartet sein, damit die NLA das Netz als Domain einstuft bzw. von welchem Dienst ist die korrekte Erkennung abhängig?

Mit den IP-Adressen hatte ich bereits versucht. Also ich hab mir nun Luft verschafft und das ganze in eine Laborumgebung gewandelt um dem Fehler zu finden. Mit dem STart der DCs werden auch alle Dienste gestartet. Im Log Directory Services werden einmalig Einträge generiert, danach für die gesamte Laufzeit keine weiteren. Interessant wird es im DNS-Log: - Regelmäßige Zonenübertragung an DNS-Server mit DNS-Zonen-Kopie erfolgreich - Nachdem Start wird Event 4013 DNS server is waiting for AD DS to signal that the initial synchronization of the directory has been completed in weiteren Laufzeit keine weiteren Meldungen bis auf Infos zur Zonenübertragung - Außerdem wird nach einem Neustart oder wenn ich die IP-Konnektivität kurzzeitig trenne, folgende Fehler im Log produziert: ++ Error 407 DNS could not bind a UDP Socket to 81.31 ++ Error 408 The DNS server could not open socket for address 81.31. ++ Error 404 DNS could not bind a TCP Socket to 81.31 Diese Fehler lassen sich auf beiden DCs reproduzieren und erscheinen nach Server-Neustart oder Trennung der Konnektivität, auch mit geänderten IP-Adressen. Wird hingegen nur der DNS-Service neugestartet, keine Fehler. WDC1-Roles: AD-CS, AD-DS, DHCP, DNS, IIS WDC2-Roles: AD-DS, AD-FS, DNS keine zusätzlichen Programme, Firewall oder Antivirus-Service. Ich werde nun mal schauen, ob ich die Fehler lösen kann und halte euch auf dem Laufenden. Über Ideen freue ich mich :) Gleich ein Nachbrenner. Wenn ich in den DNS-Einstellungen (WDC1) das IPv4 Adresse deaktiviere und Listening auf IPv6 Auto (fe80) lasse, wird das Netzwerk sofort als Domain Network erkannt :shock:

Sie sind über Kreuz eingetragen WDC1 hat als 1. DNS WDC2 & 2. DNS sich selbst eingetragen und bei WDC2 genau umgekehrt. Sind bereits beide auch mit eigener IP als 1. DNS neu gestartet worden. Stimmt, Sie sichern sich nicht sondern replizieren sich gegenseitig ;) Category Type ist ebenfalls eingetragen. Ja, die wurden ja aus dem Laufwerk mit gleicher GUID importiert. Es wurde keine Änderungen an der Hardware oder Zuordnung der Laufwerke oder ähnliches vorgenommen. Daher hat sich aus meiner Betrachtung für die DCs nur die MAC geändert. Es ist ja nicht da erste Mal, dass diese importiert wurden, aber das erste mal, dass das Netzwerk nicht mehr als eigenes erkannt wird.

Also ich hab alle Einträge aus HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\* gelöscht. Nach einem Neustart kam ein Profile wieder. Wenn kein Gateway eingetragen ist wird die Connection gar nicht erst unter dem Netzwerksymbol angezeigt. Nachdem ich ein Gateway eingetragen habe, wurde gefragt und Einstufung als Private erfolgte. Löschen des Gateways und manuelles Eintragen Cat 2 erfolgt, Neustart -> Erkannt als Unidentified Network (Public). Erfolgte alles auf WDC2. Der steigt stündlich. Nein leider nicht. Es sind Backups von allen Diensten und Servern vorhanden, aber eben nicht vom DC, da bisher davon ausgegangen wurde, dass die beiden sich gegenseitig sichern :schreck: Ich habe nun mal einen Legacy Adapter mit der gleichen IP konfiguriert. Nach einem Neustart wird Netzwerk Public erkannt. Im NetworkList\Profiles\* wird kein neues erzeugt, sondern das bestehende hat Auswirkung auf den neuen Adapter (alte Adapter ist deaktiviert, ohne IP). Sobald ich Category Type 2 eintrage wird das Netzwerk zumindest als Domainnetzwerk eingetragen, nach einem Neustart verschwindet diese zuordnung wieder und es wird automatisch 0 gesetzt. Es wird zwar Domainnetwork im Netzwerkcenter angezeigt, aber in der Windows Firewall bleibt die Einstufung trotzdem bei Public.

Ja,da gebe ich dir Recht! Tut mir wirklich leid! Probiere es gleich aus.

Kein Teamin vorhanden, weder auf dem Host noch auf den DCs. ;)

Das mit IPv6 war auch nur ein Test. Hab nun nochmals die komplett ursprüngliche Konfiguration hergestellt und davon ipconfig /all gezogen. Tur mir leid, dass ich da teilweise Altdateien hochgeladen habe. DCDiag ebenfalls aktualisiert. Löschen aller Einträge aus Networklist wäre noch eine Idee, probiere ich direkt mal aus. Manuell hatte ich es bereits eingetragen, aber nur Private da ja Domain automatisch gesetzt wird. Einen neuen DC installieren, wird vermutlich nicht gehen, da ja derzeit keine DC funktionieren :( Würde ich gern, aber ist aus Platztechnischen Gründen nicht möglich. Allerdings arbeite ich an einer Lösung. Ja, die erreichen sich untereinander per Ping und die manuellen Freigaben sind auch untereinander erreichbar.

Mist, mein Fehler! Das war nur von einem Test, in dem ich einen DNS eingetragen habe, auf dem eine DNS-Kopie liegt. :shock: Du hast recht und korrekt ist auch, dass beide DCs über Kreuz eingetragen sind, hab es entsprechend auch wieder zurück gelegt und die ipconfig aktualisiert. Beide DCs laufen auf dem selben Host (WS2012R2). Dort laufen keine weiteren Dienste drauf außer halt Hyper-V. Keine installierten Zusatzdienste, auch keine Firewall oder Antivirensoftware. Es ist nur die standardmäßige Windows firewall vorhanden. DCs sind erreichbar und anpingbar. Selbst die manuell hingezugefügten Freigaben (home) sind erreichbar, die DC-Freigaben (Sysvol, Netlogon) jedoch nicht.

Umgebung funktionierte, bis zum Host-Ausfall, mehrere Jahre ohne Gateway. Hatte auch dies bereits getestet, in dem ich Testweise eines eingetragen habe, von einem Server der als solcher für Clients fungiert, aber auch keine änderung. Sorry, hab die Dateien nun auf OneDrive hochgeladen. Dort ist sind beide ipconfig /all und Dcdiag vom WDC2 zu finden. Danke schon mal.

Nein, keine Warnung das die IP anderen Adapter zugeordnet ist. Hatte bereits zur Sicherheit geschaut, mit show_nonpresent_devices ob sich noch ein weitere Adapter eingeschlichen hat, ist nicht der Fall. NLA Dienst läuft, hatte ich bereits manuell gestartet und den Dienst (testweise) auf "Verzögerter Start" gestellt. Ein Interessanter Fehler der sich auf dem 2. DC findet (IP 192.168.81.32) ist Event 408: The DNS Server could not open a socket for address 192.168.81.32 Event 4013: DNS Server is waiting for AD DS Signal that the initial synchronisation of the directory has completed. Also es ist schon sehr auf den DNS-Server einzugrenzen. So recht erschließt sich mir noch nicht, wie ich das Henne-Ei-Problem lösen soll? Beide DCs haben gleiche sProblem und kommen nicht hoch. Anbei noch Ipconfig /all von DC1 (81.31) & DC2 (81.32) Ein Gateway ist nicht vorhanden, da alle Server im selben Subnetz vorhanden sind.

Hallo Leute, in meiner Umgebung befinden sich zwei virtualisierten Domaincontroller (2012 & 2012R2). DC1 hält die FSMO-Rollen. Beide sind auf einem Hyper-V-Host eingerichtet. Bei Wartungsarbeiten wurde die virtuelle Umgebung runtergefahren. Allerdings gab es Probleme mit dem Hyper-V-Host, was ein neu aufsetzen dessen zur Folge hatte. Nachdem importieren der VMs wurden beide DCs wieder gestartet. Diese erkennen nun allerdings das Netzwerk nicht mehr als Domainnetzwork sondern als Öffentliches. Aus meiner Sicht hat sich für die DCs nur die MAC-Adresse geändert. Dennoch kommen die Dienste nun nicht mehr hoch. In DCDiag schlägt der Connectivity Test direkt fehl, da der msdsc Eintrag nicht aufgelöst werden kann. Der DNS Dienst wird ausgeführt, zeigt keine Fehler im LOG an und die Verknüpfung zu IP ist auch korrekt. Testweise habe ich die Firewall fürr alle Bereiche deaktiviert und Neustart durchgeführt, keine Änderung. Eigene IP statt der 2. DC IP im DNS eingetragen. Secpol.msc konfiguriert um das eigene Netz als Private einzustufen, keine Änderung. Alles brachte bisher keine Änderung. Habt ihr Tipps wie ich das Problem lösen kann?

Leg dir doch eine Prepaid-Kreditkarte zu. Die eignet sich perfekt für solche Zwecke und du kannst max. das aufgeladene Guthaben verbrauchen. Nutze ich selbst für bestimmte Internetdienste.