AndiG

Hallo, danke für die Ratschläge. Werde Thema DNS auf jeden Fall nächste Woche angehen und die Vorschläge umsetzen. Ist leider nicht ganz so einfach bei uns. Wir hatten früher einen Linux Kern und hatten ein Admin (der jetzt nicht mehr da ist …) hatte die Windows Domäne eingeführt. Bzw. Damit angefangen. Son sind die DHCP, DNS Server teilweise noch auf den Linux Maschinen, die nebeher noch Entwicklungsserver sind. Ein Chaos. Mehrere Standorte, externe Mitarbeiter usw. ist alles noch irgendwie mit Hand am rücken gelöst aber nicht richtig und unbefridigend. Hinzu kommt die Forderung von der Geschäftsführung der Compliance Konforme IT. Nun habe ich es übernommen und muss nach und nach das ganze rund zu kriegen. Hab zwar keinen Großen Zeitruck, dafür aber eine Menge an Arbeit. Aber ihr kennt das ja! Danke euch. Gruß AndiG

So Leute, hab das Problem gelöst. Kann leider nicht genau sagen was es war, aber was Abhilfe brachte. Ich hatte bei meinen Fehlersuche irgendwann den VMTK -Server zur Seite gelegt und hatte dann mit einer Testmaschine weiter gemacht. Dabei sind im Eventlog die Meldungen von NetBT aufgetaucht, die es auf dem VMTK Server leider nicht gab. Ehren Wort! ############# Protokollname: System Quelle: NetBT Datum: 03.07.2014 17:15:19 Ereignis-ID: 4321 Aufgabenkategorie:Keine Ebene: Fehler Schl?sselw?rter:Klassisch Benutzer: Nicht zutreffend Computer: VMWIN7-IE9.stb-ag.local Beschreibung: Der Name "VMWIN7 :0" konnte nicht auf der Schnittstelle mit IP-Adresse 198.168.168.122 registriert werden. Der Computer mit IP-Adresse 198.168.168.22 hat nicht zugelassen, dass dieser Computer diesen Namen verwendet. ############## Geprüft: Namenskonflikte gab‘s keine, IP ebenfalls. Bei Recherche im Internet ist manchmal das Wort Topologieerkenung gefallen. Habe daraufhin auf beiden Rechnern (SBS und VMTK) bei den Netzwerkeistellungen, die Protokole dafür abgeschaltet. Und siehe da, schon hat alles wunderbar funktioniert. Wieder eingeschaltet funktioniert immer noch. Jetzt ist erst mal nachhaken angesagt. Bin bisher damit noch nicht in Berührung gekommen. Mus mal rausfinden was es genau tut und ob ich es wirklich brauche. Ich danke euch für die Unterstützung und hoffe, dass dieser Beitrag anderen Leuten hilft. Gruß AndiG

Hallo, danke für die Info. DNS ist bei uns sowieso eine Baustelle für sich und muss noch aufgeräumt werden. Jetzt auf die schnelle ist es leider nicht zu machen. Werde die Beschreibung auf der Seite auf jede fall berücksichtigen. Komme jetzt wieder zum Arbeiten an der Maschine. Musste heute Feuerwehr auf einem Postfix-Server spielen. Hab inzwischen den Switch neustarten lassen – leider ohne Verbesserung. Ich denke langsam an Plan-B und die Umstellung auf eine andere IP. Muss wohl in den sauren Apfel beißen. Leider wäre es dann immer noch nicht klar, was das Problem ist. Gruß AndiG

Hallo Leute, riesen riesen Dank für die Rückmeldungen. Es gibt inzwischen ein paar neue Erkenntnisse (siehe weiter unten) aber noch keine Lösung. @Sanches: im Eventlog gibt zwar einige Meldungen aber nichts was weiter helfen würde: DCOM konnte mit dem Computer <COMPUTER> unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen. MSExchangeTransport Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen „CONOSO“ im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für den Connector "Relay intern" mit einem FQDN-Parameter von „CONOSO“ nicht unterstützt werden. Überprüfen Sie … Diese Meldungen waren aber auch schon vor dem Problem da und es hat bisher keine spürbare Einschränkung gegeben. Sicherheitssoftware ist natürlich vorhanden. Hab ab die Konfiguration auch gecheckt – nicht auffälliges. Da hier schon lange nichts geändert wurde und das Kommunikationsverhalten irgendwie nicht ins Bild-firewallproblem passt, würde dies ausschlissen. @h-d.neuenfeldt: „Abschalten der der IPV6 auf dem Server ist ein NoGO“ hatte ich mir mal gemerkt und auf einem Produktiven Server ist doppelt gefährlich. Den es ist so, dass sehr viele Dienste unter einander über IPv6 kommunizieren. Ich hatte auf zwar auf dem Telefonie Server (TK) die IPv6 Unterstützung mal ausgeschaltet, dass das verhalten aber nicht geändert. @Dunkelmann: Anbei die Ipconfigs: die Öffentliche Netz-Adressen habe ich durch 192.168.168.* ersetzt. Die Host IP ist die richtige: SBS-Server: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : SBS Primäres DNS-Suffix . . . . . . . : contoso.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Ja WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : contoso.local Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) Physikalische Adresse . . . . . . : F0-4D-A2-3F-07-3D DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja IPv4-Adresse . . . . . . . . . . : 192.168.168.105(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.168.194 DNS-Server . . . . . . . . . . . : 127.0.0.1 192.168.168.198 77.90.128.15 77.90.130.2 NetBIOS über TCP/IP . . . . . . . : Aktiviert Ethernet-Adapter LAN-Verbindung 2: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #2 Physikalische Adresse . . . . . . : F0-4D-A2-3F-07-3F DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Ethernet-Adapter LAN-Verbindung 3: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #3 Physikalische Adresse . . . . . . : F0-4D-A2-3F-07-41 DHCP aktiviert. . . . . . . . . . : Ja Autokonfiguration aktiviert . . . : Ja Ethernet-Adapter LAN-Verbindung 4: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Broadcom BCM5709C NetXtreme II GigE (NDIS VBD Client) #4 Physikalische Adresse . . . . . . : F0-4D-A2-3F-07-43 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{E4AA7591-63B7-47D6-BE9A-BB174571809D}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{C169AFFE-1C52-4C8E-B367-F878AC592F83}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{79756BF1-D770-49CE-9423-E687F0D88B49}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter isatap.{2AFC83E8-1309-4DEC-A21E-CF1C761A3820}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #4 Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter 6TO4 Adapter: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-6zu4-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja IPv6-Adresse. . . . . . . . . . . : 2002:4d5a:9469::4d5a:9469(Bevorzugt) Standardgateway . . . . . . . . . : DNS-Server . . . . . . . . . . . : 127.0.0.1 192.168.168.198 77.90.128.15 77.90.130.2 NetBIOS über TCP/IP . . . . . . . : Deaktiviert Server VMTK: Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : VMTK Prim?res DNS-Suffix . . . . . . . : contoso.local Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : contoso.local Ethernet-Adapter LAN-Verbindung 2: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Citrix PV Ethernet Adapter Physikalische Adresse . . . . . . : 5A-7B-C1-3B-71-73 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Verbindungslokale IPv6-Adresse . : fe80::1a3:ca72:2558:1cd4%15(Bevorzugt) IPv4-Adresse . . . . . . . . . . : 192.168.168.122(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.168.194 DHCPv6-IAID . . . . . . . . . . . : 240810945 DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-15-8B-C6-48-5A-7B-C1-3B-71-73 DNS-Server . . . . . . . . . . . : 192.168.168.105 192.168.168.198 NetBIOS ?ber TCP/IP . . . . . . . : Aktiviert Tunneladapter isatap.{3BA40996-D248-4831-8314-1D50049F21B8}: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Tunneladapter 6TO4 Adapter: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Microsoft-6zu4-Adapter Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja IPv6-Adresse. . . . . . . . . . . : 2002:4d5a:947a::4d5a:947a(Bevorzugt) Standardgateway . . . . . . . . . : DNS-Server . . . . . . . . . . . : 192.168.168.105 192.168.168.198 NetBIOS ?ber TCP/IP . . . . . . . : Deaktiviert Tunneladapter LAN-Verbindung*: Medienstatus. . . . . . . . . . . : Medium getrennt Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0 DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja Nun die neuen Erkenntnisse. Dass die keine Pakete am SBS-Server ankommen war ein Irrtum, bzw. ich hatte den Filter Wireshark falsch eingestellt. Sorry an deser Stelle. Pakete kommen an aber keine ICMP. Handshake Klappt noch danach kommen immer „TCP Restransmission“ Anfragen vom SBS-Server an den VMTK-Server. Es scheint so, dass die ICMP Pakete defekt ankommen?! Und das war überraschend: Dienste wie Dateifreigabe (SMB) und Web (http) die auf dem SBS-Server laufen kann man abrufen. Auch Anmeldung mit Domain User ist möglich. Nach 2. War mir mehr so ganz klar, auf welcher Seite (SBS-, oder VMTK-Server) das Problem eigentlich liegt. Daraufhin hatte die IP Adresse am VMTK der die ..122 hatte auf eine andere geändert. Auf einem Anderen Windows 7 Rechner hatte ich nun die IP des VMTK (…122) eingerichtet. Und siehe da exakt das gleiche seltsame verhalten. Das Problem scheint auf dem SBS-Server zu liegen. Nslookup mit dem SBS als Server funktioniert ebenfalls nicht. Der SBS kriegt keine DNS Anfragen des VMTK und es werden Broadcast Abfragen an port: sentinelsrm (1947) am SBS empfangen. Weis nicht ob die Broadkasts mit dem nslookup zusammen hängen. Ich hatte in vergangenen Woche ein Update auf Exchange Server durchgeführt: Version 14.3 (Build 123.4) ob’s damit zusammen hängt? Das Problem scheint mir so tief im TCP Stack zu sitzen, so dass die Vermutung habe, das eventuell der Netzwerk Switch das Problem verursacht. Denn werde ich mal heute Mittagspause neustarten lassen. Und berichte wieder. Danke noch mal an alle für die Beteiligun. Gruß AndiG

Hallo liebe Gemeinde, dies ist mein erster Hilferuf hier im Forum, verzeiht mir bitte daher, sollte ich etwas falsch machen. Zu nächst zu meiner Person. Ich als Administrator für eine Windows-Linux Umgebung mit 28 Windows Clients und einigen Servern verantwortlich. Bin in diese Rolle als Quereinsteiger reingerutscht und versuche Autodidaktisch mich Einzuarbeiten. Bin zwar kein absoluter Profi, Grundlagen sind aber einige da. Nun Zum Problem: hab aktuell Problem mit einem Windows Server 2008 R2 (eine VM auf dem XenServer) welcher in der Domäne hängt. Der Server beherbergt den Serverteil der Telefonie Software „XPhone UC“. Heute Vormittag melden User, dass die Software nicht nutzbar ist. Also angefangen zu suchen, Feststellung: die User können sich nicht Anmelden. Windows Authentifizierung schlägt fehl. Ereignis Meldung: „ Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: NULL SID Kontoname: - Kontodom?ne: - Anmelde-ID: 0x0 Anmeldetyp: 3 Konto, f?r das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: ### Kontodom?ne: ### Fehlerinformationen: Fehlerursache: Unbekannter Benutzername oder ung?ltiges Kennwort. Status: 0xc000006d Unterstatus:: 0xc0000064 Prozessinformationen: Aufrufprozess-ID: 0x0 Aufrufprozessname: - Netzwerkinformationen: Arbeitsstationsname: PC005 Quellnetzwerkadresse: fe80::b83d:a682:e2bb:15e0 Quellport: 51762 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: NtLmSsp Authentifizierungspaket: NTLM ?bertragene Dienste: - Paketname (nur NTLM): - Schl?ssell?nge: 0 ... Mir kam das Problem irgendwie bekannt vor. Tag vorher hatte einen ähnlich Fall auf einem Windows 7 Rechner. Der Benutzer konnte sich nicht mit den Laufwerken Verbindung und musste immer wieder sich anmelden. Das Problem konnte ich nur so lösen, indem ich dem Rechner neue IP Vergab und Ihn erneut in die Domäne eingehängt habe. Durch Wechsel zu der alten IP Adresse kam das Problem wieder. Ich bin nicht auf die Ursache gekommen. Der User meinte, der Rechner hatte schon eher mal Probleme gemacht und ich belies es dabei. Nun Kommen ich wieder zum Server. Was ich nun feststellte ist, dass Kommunikation mit dem Domain-Server - sagen wir mal - gestört ist. Domain Server ist ein SBS 2011. Der Server antwortet nicht auf den ping. Andere Rechner sind aber über Ping erreichbar. Zum Vergleich änderte ich die IP Adresse und schon war der Domain-Server über ping wieder erreichbar. Ich dachte als nächtest die IP gibt es doppelt im Netz – nein ist’s nicht. Firewall Regeln auch nicht. Desweitern hatten ich die Netzlast über den XenCenter für diese VM überwacht und habe den Ping Paketen etwas Gewicht gegeben: ping SBS-Server -l 65500 –t Folge keine Antwort, keine Last. Dagegen ping ANDERER-Server -l 65500 –t Folge Antwort, und Last auf dem Netz. Wireshark bestätigt es - Es kommen keine ICMP Pakete auf dem SBS-Server an. Theoretisch könnte man natürlich wieder die IP Adresse ändern, was ich aber unbedingt vermeiden will. Deseitern ist es jetzt der zweiter Rechner mit dem Problem und man sollte dem Fehler auf den Grund gehen. Nun bin ich mit meinem Latein am Ende. Habt ihr eine Idee?