Jump to content

RogerG781

Junior Member
  • Content Count

    111
  • Joined

  • Last visited

Community Reputation

22 Popular

About RogerG781

  • Rank
    Junior Member
  • Birthday 07/11/1981
  1. 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/
  2. 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.
  3. 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.
  4. 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 ;)
  5. 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.
  6. 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.
  7. 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 :(
  8. 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.
  9. 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.
  10. 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?
  11. Danke für die Info, kommt mit auf die ToDo und wird morgen erledigt. ;)
  12. 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.
  13. Hallo, vielen Dank, habe ich soeben auch gelesen. Hatte gehofft, dort evtl. noch andere Mitleser zu erreichen.
  14. 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?
  15. 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:
×
×
  • Create New...