robotroonie

Verweis darauf ist an diversen Stellen im Web zu finden; aber eben zu lapidar z.B. MSXFAQ.DE - Syslog Ãœberwachung IT SecCity.de - IT-Security, Safety & High Availability-Magazin Und hier noch ein Suchender: syslog server - MCSE Forum für Zertifizierungen, Betriebssysteme & Netzwerke

Gesucht und nirgends gefunden. Muss man diese nachinstallieren? Wie ist diese Funktion nutzbar/gibts hier ein Manual? Will eigentlich nur einen Remote-Router (Lancom) überwachen. Wenn ich auf diesem Syslog aktiviere, werden dann Einträge bei unterbrochener Verbindung zeitversetzt gesendet oder gehen diese verloren?

Hatte bei MS Hotfix 842804 angefordert und erhalten. Ist allerdings zwiespältig: Aus KB-Artikel geht nicht eindeutig hervor, dass der Hotfix bereits im SP1/2 enthalten ist. So scheitert auch die Installation mit entspr. Fehlermeldung. Der erwähnte Registry-Key ist aber trotzdem nicht vorhanden - hier enthält die deutsche KB-Seite den Fehler, dass hier der Reg-Pfad fehlt. Habe ihn erstellt - wirken sollte er erst nach einem Neustart (heute abend). Nun aber noch etwas anderes herausgefunden: KB935918 erwähnt Befehl dfsutil /pktinfo dieser gibt auf dem Betroffenen DC aus: ... --mup.sys-- 0 entries auf anderem DC ist 1 entry vorhanden die mup.sys selbst ist ja wohl nur eine Treiberdatei; scheint auch auf beiden DCs identisch zu sein. Allerdings ist sie auf dem DC mit Eintrag ca. 2 Stunden jünger. Bringt es etwas, diese Datei zu verwenden? Wirkung gibt das sicher auch erst nach Neustart. Ich vermute aber, die entries sind woanders hinterlegt.

@amichel genauso habe ich es ja gemacht (s.o.) Ich möchte das Thema noch einmal aufnehmen. Die letzten 2 Wochen lief das System im Großen und Ganzen ohne Eingriffe / wie gehabt. Nach einer ausführlichen Kontrolle stellt sich die Problematik im nun als scheinbar gelöst heraus - bis auf einen GRL-Restfehler (s.u.) - repadmin /showreps scheint OK zu sein (zeigt inbound Neighbors analog zu anderem DC) - Prüfen der Replikationstopologie: OK - netdiag: OK (nach registerdns auch dnstest) - ldp scheint OK - Ausgabe wie oben, jedoch nun GCReady=True - adsiedit: offenbar OK; keine gravierenden Abweichungen zu anderem DC - Systemfreigaben: Sysvol vorhanden; Netlogon manuell angelegt (Rechte wie auf anderem DC) > funktioniert; Änderungen werden repliziert - Logs: nur noch eine Doppelmeldung, die sich alle 5 Minuten wiederholt: ID 1030 / 1058 >> hier wird einer von 9 Gruppenrichtlinien-Ordnern angemeckert: 1058: auf die Datei gpt.ini des GPO kann nicht zugegriffen werden. Die Datei muss im Pfad \\domain\...vorhanden sein (Zugriff verweigert). Die Verarbeitung der GP wird abgebrochen 1030: Die Abfrage der Liste der GPO ist fehlgeschlagen. Die Datei ist natürlich vorhanden; Berechtigungen gleich wie auf den anderen Ordnern. Ein Löschen und neues Einspielen des kpl. Verzeichnisses (inkl. NTFS-Berechtigungen) bringt nichts (meist wird der Ordnerbezeichnung ein Suffix angehängt; manuelles Umbenennen in Soll-Namen). Auch ein Löschen des Objektes auf dem betroffenen DC führt nicht zur automatischen Erzeugung durch Replikation (auch nicht nach Stunden). Ich gehe davon aus, dass die anderen GP korrekt abgearbeitet werden, da diese im Log nicht erwähnt werden (und nicht, dass die Verarbeitung bei der ersten GP abbricht und die anderen gar nicht erst anfasst). MS sagt zu den EventIDs: mit ADSIedit Attribute prüfen > nur sind diese OK Wie lässt sich das Problem lösen?

repadmin /showreps zeigt zumindest keinen Fehler; es werden aber nur Inbound Neighbours vom gleichen Standort angezeigt (vor De/promoten hatte ich manuelle Replikationsverknüfungen erstellt; nach dem dcpromo noch nicht wieder). Nun: GC aktiviert; manuelle Replikationsverknüpfungen erstellt. Ausgabe bleibt wie oben.

Sieht schlecht aus: nachdem nach Stunden immer noch der DC-Eintrag in AD Nutzer+Computer enthalten war, habe ich diesen auf einem anderen DC (Standort 2) gelöscht. Hier ging das. Danach hat dcpromo funktioniert. ABER: Netlogon und Sysvol fehlen wieder; dcdiag-Fehler wie gehabt; Ereignis-ID 13508 Zum GC habe ich ihn noch nicht gemacht.

Habs nun aufgegeben, den ev. nur kleinen Fehler zu suchen. DC nach MS-Anleitung entfernt. DNS-Fkt bleibt ja erhalten. Entsprechend angepasst. dcpromo scheitert jedoch mit "Der angegebene Benutzer ist bereits vorhanden". Kontrolle zeigt: Objekt ist noch in AD Nutzer+Computer\DCs enthalten. Lässt sich hier auch nicht löschen ("das dsa-objekt konnte nicht gelöscht werden"). Im KB stand ja nur, dass es in Sites+Services gelöscht werden soll. Da ging das auch ohne Fehler. Mt replmon Replikation erzwungen - trotzdem gehts nicht. Und nun? Versuche ich mit ntdsutil auf den entfernten Server zu verbinden, erscheint nicht der DSA-Fehler, der kommen sollte, sondern (DsBindW-Fehler 0x6d9 [in der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.]) > was auf eine fehlerhafte RPC-Endpunktzuordnung hinweisen soll. Mit list servers in site wird der DC nicht mehr angezeigt. Also doch Repliaktion abwarten? Standort 3 ist über Slow Link verbunden.

Richtig Hilfe bietet der KB-Article leider nicht: soll ja auch nur für Datacenter und Enterprise gelten. Auf jeden Fall stimmt die Struktur (Adsiedit) nicht ganz. Habe da trotzdem Abweichungen festgestellt: Attribute ServerReference ist auf dem betroffenen DC nicht gesetzt - manuell eingetragen; außerdem ist der Eintrag frsmemberreferenceBL nicht gesetzt > lässt sich auch nicht setzen, da System die Berechtigungen hat ("Das Attribut konnte nicht geändert werden, da es dem System gehört") Das Attribut frsmemberreference, durch dessen Setzen das Attribut frsmemberreferenceBL automatisch erzeugt werden soll, ist auf keinem DC vorhanden.

Natürlich. Sonst geht das ja nicht. Adprep/forestprep/domainprep/Erweitern des AD-Schemas erfolgte, als der erste 2k3-DC (Standort 3) in die Dom aufgenommen wurde. dcpromo (Herabstufen) geht nicht. Fehler: AD konnte die verbleibenden Daten in der Verzeichnispartition nicht übertragen. Beim 1. Versuch zum DC1 / beim 2. Versuch zum DC2 am gleichen Standort. Fehler: Der RPC-Server ist nicht verfügbar.

Vor allem das mit den BurFlags schien mir erfolgversprechend > also: Dienst auf DC defekt angehalten; Reg editiert (D2); auf anderem DC (PDC-Master) reg editiert (D4); Neustart Dienst; Start Dienst auf DC defekt; Ergebnis: alles beim alten (burflags jeweils wieder auf 0). Fehler noch da; dcdiag bringt Fehler. Zeit ist synchron. Firewall kann ich nicht ganz ausschließen. Am Standort des neuen DC (2k3) befinden sich nur noch 2 2k-Server; die anderen Standorte haben 2k3. Bei diesen gab es keine Probleme. Vielleicht liegt es daran, dass bei dem Problemkind die Replikation mit 2k klappen muss. Firewall ist über GRL aktiviert; würde ich nur ungern editieren. Zurücksetzen des Computerkontos ohne Erfolg.

Folgendes: DC an anderem Standort und anderer DC (Exchange) am gleichen Standort: nichts feststellbar. DC 2 am gleichen Standort enthält einen Eintrag etwa zu dem Zeitpunkt des dcpromo auf dem betroffenen DC: ID 13562 Das nTFRSMember-Objekt cn=xxx,cn=domain system volume (sysvol share),cn=file replication service,cn=system,dc=xxx,dc=local hat einen ungültigen Wert für das Attribut frsComputerReference. Ist aber auch möglich, dass sich das auf die erste Installation auf dem betroffenen DC bezieht. Am betroffenen DC eine Stunde später folgender Eintrag: Der Dateireplikationsdienst initialisiert den Systemdatenträger mit Daten eines anderen Domänencontrollers. Der Computer "xxx" kann nicht zum Domänencontroller benannt werden, bis dieser Vorgang beendet ist. Das Systemvolumen wird dann unter SYSVOL freigegeben. Um die SYSVOL-Freigabe zu überprüfen, geben Sie an der Eingabeaufforderung folgendes ein: net share Wenn der Dateireplikationsdienst den Initialisierungsvorgang beendet, erscheint die SYSVOL-Freigabe. Die Initialisierung des Systemdatenträgers kann einige Zeit in Anspruch nehmen. Der Zeitaufwand ist von der Datenmenge im Systemdatenträger, der Verfügbarkeit anderer Domänencontroller, und dem Replikationsintervall zwischen anderen Domänencontrollern abhängig. Erstellt wurde diese vom System bis jetzt nicht. 2 Minuten später (bis jetzt) dann immer weider ID 13508 Nachdem ich nun vorhin die 2 Freigaben selbst erstellt habe (Rechte und Inhalt wie auf den anderen; einige Ordner waren zT schon vorhanden, jedoch keine Freigabe) nun der Fehler 13567 Der Dateireplikationsdienst hat durchschnittlich mindestens 15 Dateiupdates in den letzten 3 Stunden ermittelt und unterdrückt, weil die Updates die Inhalte der Datei nicht verändert haben. Die Ablaufverfolgungs- einträge in den Debugprotokolldateien des Dateireplikationsdienstes enthalten den Dateinamen und die Ereigniszeit der unterdrückten Updates. Die Ablaufverfolgungseinträge enthalten das Datum und die Uhrzeit gefolgt von :T: als Präfix. Updates, die die Inhalte der Dateien nicht ändern, werden unterdrückt, um unnötige Replikationsaktivitäten zu verhindern. Folgende sind allgemeine Beispiele für Updates, die die Inhalte der Dateien nicht verändern. [1] Eine Datei mit der Kopie der gleichen Datei überschreiben. [2] In einer Datei mehrfach die gleichen ACLs setzen. [3] Identische Kopie der Datei einer bestehenden Datei wiederherstellen. Unterdrückung von Updates kann durch das Ausführen von "regedit" deaktiviert werden. Klicken Sie auf "Start" und dann auf "Ausführen", und geben Sie "regedit" ein. Erweitern Sie HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Services, NtFrs, Parameters, und erstellen oder aktualisieren Sie den Wert "Aktualisierungen identischer Dateien unterdrücken" auf 0 (Standard ist 1), um das Replizieren von identischen Updates zu erzwingen.

Fehler bei Netdiag: Domain membership test . . . . . . : Failed [WARNING] Ths system volume has not been completely replicated to the local machine. This machine is not working properly as a DC. Klar, liegt an der fehlenden Freigabe. Sonst offenbar keine gravierenden Fehler. ldp bringt folgendes: 3> supportedCapabilities: 1.2.840.113556.1.4.800; 1.2.840.113556.1.4.1670; 1.2.840.113556.1.4.1791; 1> isSynchronized: TRUE; 1> isGlobalCatalogReady: FALSE; 1> domainFunctionality: 0 = ( DS_BEHAVIOR_WIN2000 ); 1> forestFunctionality: 0 = ( DS_BEHAVIOR_WIN2000 ); 1> domainControllerFunctionality: 2 = ( DS_BEHAVIOR_WIN2003 );

Hallo, habe einen (weiteren) DC im Netz aufgesetzt, der aber scheinbar Probleme hat: - Sysvol- und Netlogon-Freigaben fehlen - Befehl dcdiag: DSGETDCNAME gibt einen anderen Namen zurück (entweder Server a oder Server b am gleichen Standort; richtig wäre Server c) > failed Test advertising - im Log stehen Fehler des Dateireplikationsdienstes (ID 13508) - repadmin /showreps ergab LDAP error 81 (Server heruntergefahren) Win32 Error58 > dieser Fehler scheint behoben - Replikationstopologie überprüfen bringt Fehler "Die Verzeichniseigenschaft wurden nicht im Cache gefunden" (auf den anderen Server fkt dies) Der Server hat 2k3 SP2 installiert; DNS-Funktion wurde erst eine Weile nach dcpromo hinzugefügt (liegt hier der Fehler?). DC hat globalen Katalog. Replikationsverknüpfungen wurden manuell erstellt. DNS ist AD-integriert. 5 Server befinden sich an 3 Standorten (an dem betreffenden 3 Server) Was kann man da noch tun? Mit dcpromo herunter- und dann wieder heraufstufen ist wohl nicht ganz risikofrei. Ein händisches Anlegen der 2 System-Freigaben dürfte wohl kaum alle Pobleme lösen, sondern nur Symptome kurieren Wie verhält sich das, wenn ich einen Server manuell aus dem AD entferne und dann (ein paar Stunden später) einen mit gleichem Namen wieder mit dcpromo hinzufüge? Ist es möglich, dass die Replikation des gelöschten Servers noch nicht abgeschlossen ist? Nach der 1. Inst. des Servers gab es (nach dcpromo) nämlich ein Problem mit einem beschädigten Raid, daraufhin wurde genau das durchgeführt. Den gKat habe ich nun wieder entfernt, da es am Standort noch einen gibt. PDC-, RID- und Infrastrukturmaster gibts auch am Standort - natürlich auf einem Server ohne gKat.

Hi, Ein Firmennetz mit 3 Subnetzen; Jeder Standort hat mindestens 1 Server mit DNS und WINS. 2*2k3 / 2*2k. Subnetz 2 ist mit Subnetz 3 über einen VPN-Tunnel gekoppelt; dito Subnetz 1 und 3. SN 1 und 2 sind über eine Funkstrecke verbunden (separate Router) Das Problem: Sporadische Zugriffsprobleme subnetzübergreifend. Der Fehler stellt sich wie folgt dar: - einige Clients (nicht alle) vom Subnetz 1 können nicht auf den Server (Subnetz 2) zugreifen - der Name wird korrekt in IP aufgelöst - ping mit IP und Name scheitert - Erneuern der IP (z.B. Umstellen statisch auf dynamisch) oder auch andere Massnahmen beheben das Problem mitunter > aber nicht dauerhaft - Ändern der Gruppenrichtlinien (Verschieben in OU mit deaktivierter Firewall; aktualisieren) helfen nicht - In der anderen Richtung scheitert der Zugriff auf Clients ebenso > zum Teil sogar vom Server - FW-Update der Router (Lancom 1721vpn an allen 3 Standorten) wurde durchgeführt - Router-Kfg "netbios über IP-Routing" hat keine erkennbaren Auswirkungen - Router-Kfg > Deaktivieren "block Netbios/WINS name tresolution via DNS" hat keine erkennbaren Auswirkungen - In den Ereignisprotokollen der Server sind folgende Fehler häufiger geloggt (vor allem Server Subnetz 2 / 2k3): 537 529 673 seltener: 680 675; außerdem: DCOM 10009, WINS 4102 (manchmal den ganzen Tag im 30min-Rhythmus; dann wieder nur 0-1x/Tag) - Erreichbarkeit innerhalb des gleichen Subnetzes ist überall gewährleistet - betroffen ist z.B. auch die Telefonanlage: Aus SN 1 sind beide Anlagen pingbar; aus SN 2 nur die im lokalen SN - aus Subnetz 3 sind alle Clients erreichbar - die Systemzeit auf dem betroffenen Client ist korrekt Ich vermute, dass die Problematik mit der Konstellation am Hauptstandort (Standortkopplung SN 1 und 2 über Funkstreckenrouter) zusammenhängt. Zugangsdaten für diese Router liegen nicht vor. Ggf enthalten die Lancom-Router am Hauptstandort Konfigurationsfehler. Allerdings wurde diese Kfg monatelang nicht verändert (außer neuen VPN-Zugängen). Verstärkte Sicherheitseinstellungen am Windows Server 2003 bzw. WINS/DNS/Kerberos-Probleme halte ich für weniger wahrscheinliche Ursachen. Bezüglich EventId 537 habe ich den HotFix (322389) angefordert. Dito für EventID 677/673 (824905) ID 529 kann ignoriert werden Windows Article - Welcome Der Ansatz für den Fehler ist wohl hier zu suchen: nslookup im SN 2 bringt die Ausschrift "Der Server für die Adresse...(DC im lokalen SN). konnte nicht gefunden werden. No response from Server. Server: abc Address: 123 > der benannte Server ist ein DC im SN 1 > Der Name des Clients wird korrekt ausfgelöst > In den Einträgen in Forward- und Reverse-Lookup-Zonen finde ich keinen Fehler > Im SN 2 und 3 funktioniert nslookup auf Clients in den anderen beiden SN problemlos

Hi, habe einen Server Win03 Std deu R2, auf dem AVK installiert wurde (mit der Option MySQL-Datenbank/statt interne DB). Danach wurde der Server in Dom aufgenommen bzw. zum DC hochgestuft (erster 2003-DC, also vorher adprep und forestprep). Seither war keine Verbindung des AVK Administrator zum Management Server mehr möglich. Bei Eingabe aines falschen PW wurde dies bemängelt; bei Eingabe des richtigen kam die Meldung, dass keine Verbindung zum M-Server möglich sei. Dies sowohl vom Server als auch vom Client aus (im anderen Subnet/andere Site). Support wollte auf Namensauflösungsproblem abstellen, das wars aber nicht: Der SQL-Dienst lief nicht (auch Einträge im Fehlerspeicher) und war auf ein (System-)Nutzerkonto eingerichtet (AUTHORITY\NetworkService) - nicht auf "lokales Systemkonto". Nach Ändern auf "lokales Systemkonto" war der Fehler weg. Ich würde aber gern die Ursache des Fehlers beseitigen - eigentlich sollte die Kontenzuordnung bereits bei Installation derart erfolgen. Nach Deinstallation des AVK ist es mir aber nicht möglich, den SQL zu deinstallieren (trotz vorheriger Deaktivierung des Dienstes). Auch Löschen der Dienste im Total Commander geht nicht. Die noch vorhandenen Dienste sind SQL Server Browser und SQL Server; zudem AVK Wächter und AVK Proxy. Bei Deinstallationsversuch des SQL (über Sys-Strg>Software) kommt die Fehlermeldung "Unerwarteter Setupfehler während interne Eigenschaften werden festgelegt. Fehler: schwerwiegender Fehler bei der Installation". Was nun? Ich könnte zwar die interne Datenbank bei Neuinstallation des AVK verwenden, finde das aber weniger optimal. Übrigens war auch das Backup neu einzurichten (Job ist seit dcpromo komplett verschwunden).

Vielen Dank. Viel komme ich damit leider auch nicht weiter. So wie ich das verstanden habe, kann man den Connector mit dem Exchange-Setup komplett entfernen, aber keine einzelnen Connectoren für bestimmte Nutzerkonten bearbeiten. Oder gibt es da eine Möglichkeit?

Hallo, ich habe folgendes Problem. Ein User in unserer Firma hatte bisher 2 AD-Konten, mit denen er 2 verschiedene Mailadressen abrufen konnte (hat mein Vorvorgänger eingerichtet, da er es nicht besser wusste). Das eine wurde aber quasi nicht genutzt. Wir verfahren sonst so: Mail A wird auf B weitergeleitet (beim Provider); Abruf Mail B normal eingerichtet. Damit auch unter Adresse von Mail A verschickt werden kann, wird lokal das pop3-Konto eingerichtet (ausschließlich zum Versand). Mit dieser Verfahrensweise hatten wir bisher nie Probleme. Es wird Exchange 2000 und Office 2002 sowie 2003 verwendet. Ich habe also den AD-Nutzer gelöscht und die Weiterleitung beim Provider eingerichtet. Einen Fehler stellte ich fest: wenn ich eine interne Mail beantworte, die vor dem Löschen mit dem mittlerweile nicht mehr vorhandenen Konto verschickt wurde, funktioniert dies nicht. Soweit logisch und kein Problem (da unwichtig). Das Gravierendere: schickt man eine Mail an den Adressbuch-Eintrag, ist alles OK. Schickt man jedoch eine Besprechungsanfrage an den gleichen Eintrag, kommt diese mit Fehlermeldung zurück (er verweist auf den gelöschten Benutzer und meint, diesen nicht erreichen zu können). Ich habe versuchsweise die vorherige interne Mailadresse noch als SMTP-Adresse an das noch gültige Konto geknüpft - dies hat aber nicht geholfen. Daher wieder entfernt Die Maileinträge am AD-Nutzerkonto entsprechen exakt denen bei einem anderen Konto, bei dem es funktioniert. Wie kann es sein, dass Mails funktionieren und nur Besprechungsanfragen zurückkommen?

Tk-Problem wurde von der Firma heute gelöst. Die Telekomiker hatten wohl am Freitag einfach ein Patchkabel direkt vom NTBA auf den Ethernet-Switch gesteckt. Das Router-Problem war davon unberührt. Ich habe mir die öffentliche IP geben lassen, diese manuell bei dyndns eingetragen und ab dann funktionierte es wieder (Tunnel untereinander aufgebaut, Zugriff möglich; beim Ping von intern gehen keine Pakete mehr verloren; Internetzugriff von intern OK). Rauschabstand liegt bei 8-8,5db (also keine wesentliche Verbesserung). Einstellen des Linemanagements auf auto und dann wieder fest auf 992.1 brachte nicht die prognostizierten 2db Unterschied (wenn überhaupt, dann 0,5db). Da nach dieser Änderung jeweils die Verbindung zum Provider neu aufgebaut wurde, musste ich manuell dyndns aktualisieren, damit Zugriff (intern und von extern) wieder geht. Der Eintrag im Router zur automatischen Aktualisierung ist aber sicher korrekt (hat ja unverändert wochenlang dyndns aktualisiert). Habe nun noch als 1. DNS den der T-Com eingetragen. Außerdem funktioniert der Zugriff von externen VPN-Clients auf den Router nicht, obwohl ich keinen Fehler entdecken kann. Die Einstellungen sind mit denen der anderen Lancoms vergleichbar, und da funktioniert es. Könnte mit dem anderen Problem zusammenhängen.

Für Montag morgen ist nun die Fa bestellt, die sonst die Tk-Anlage betreut (aber auch die Möglichkeit hat, den Router zu tauschen). Mal schauen was dabei rauskommt.

Ein Ping auf den dyndns funktionierte beim ersten Ausfall sofort und permanent - hier vermute ich aber, dass die registrierte IP schon einen neuen Besitzer hatte. Heute vormittag funktionierte der Ping stark sporadisch (geschätzt 30-40% Verlust), nun gar nicht mehr. Das bietet aber sowieso wenig Aussagewert. Ich bin nun etwas ratlos, was ich noch unternehmen kann, da ich mich nicht vor Ort befinde und keinen Fernzugriff habe. Durch Mitarbeiter vor Ort wurden schon die genannten Massnahmen durchgeführt. Ist vielleicht anhand der Symptomatik die Fehlerursache einzugrenzen? Klar, in meinen Augen ist der Router der Hauptverdächtige. Laut Aussage unseres Systemhauses (der Router wurde aber nicht da gekauft) ist dies aber sehr unwahrscheinlich - hier wird eher ein Kfg-Fehler vermutet. Nur wieso hat es dann eine Zeit lang mit der gleichen Kfg funktioniert? Und warum ist das Teil sporadisch erreichbar? Sorry für den langen Text, aber ist nun mal etwas komplexere Sache. Bin für jeden Hinweis dankbar.

Folgende Problematik: Netz aus 6 PCs, einem Server (dieser ist noch nicht DC; PCs arbeiten in AG; später soll Aufnahme in Domain erfolgen, die sich an Remote-Standort befindet / über VPN-Tunnel) 16-port Ethernet-Switch D-Link DES-1016D Lancom 1721 VPN-Router dyndns (im Router hinterlegt) Am Dienstag war ich vor Ort, habe den Server aufgestellt (dient momentan nur als Datei-und Druckserver) sowie die Router-Konfiguration mehrfach verändert (Zwischen-Konfigurationsstände liegen lokal vor). Stand war der, dass zu den 2 anderen Standorten permanente VPN-Tunnel zwischen den Routern (alles 1721VPN) aufgebaut waren. Über den Tunnel war ein netzwerkübergreifender Zugriff problemlos möglich und wurde von mir auch über mehrere Stunden intensiv genutzt (Remotedesktop; Zugriff auf Freigaben; Übertragen von Dokumenten). Bereits am nächsten Tag mittags - während eines Fern-Zugriffs von mir auf Daten an diesem Standort (also in umgekehrter Richtung wie am Vortag) brach die Verbindung ab und fiel für ca. 2 Stunden aus. Der Ausfall hatte zur Folge, dass am Standort kein Internet funktionierte. Nachdem die Verbindungen wieder standen, stellte ich fest, dass der Rauschabstand des Anschlusses nur zwischen 6,5 und 7,5dB liegt (andere 2 Standorte: 16,5 / 26dB). Störungsmeldung bei Tcom erfolgte Do morgen. Seit Do mittag ist die Verbindung wieder ausgefallen. Zur Behebung wurde von der Tcom heute eine komplett neue Leitung von der Vermittlungsstelle geschalten. Laut Auskunft des Tcom-Technikers beträgt der Rauschabstand gemäß seiner Messung nun 18/19dB (ein/abgehend). Im Lanmonitor werden allerdings nur 9dB angezeigt. Nachdem die WAN-Verbindung (DSL) heute vormittag gemäß Lanmonitor öfter unterbrochen wurde, scheint sie nun aber länger zu bestehen. Fakt ist aber: Internet der PCs lokal funktioniert nicht. Der Router ist aus dem internen Netz nur sporadisch erreichbar (pings gehen unregelmäßig verloren, lanmonitor öffnet/schließt). Heute wurde an der Lancom-Kfg noch Folgendes verändert: Leitungscode von Auto auf G992.1 gestellt (soll ca 2db bringen - die hat es ja auch nun mehr). Der Router (auch Switch und Server) wurden mehrfach resettet; anderer Lan-Port am Router verwendet. Beim Ausfall am Mittwoch auch (erfolglos) ältere Router-Kfg eingespielt. Die eingespielte Firmware 6.15 entspricht der aktuellsten für den Linecode a27.4.11 (entnehme ich zumindest dieser Tabelle: http://www.lancom-systems.de/fileadmin/pdf/sonstiges/LCOS_Versionsuebersicht.pdf ) Ursachen, die mM nach noch in Betracht kommen: - Router selbst defekt (erst 08/06 gekauft) - Switch defekt - NW-Kabel? - Router-Kfg falsch (unwahrscheinlich: bei falsch kfg. Firewall oder anderen Kfg-Fehlern sollte kein SPORADISCHER Zugriff resultieren) Zusätzlich funktioniert (seitdem heute die Tcom-Techniker vor Ort waren) das abgehende Wählen der ISDN-Anlage nicht mehr (eingehend geht). Auch hier erfolgloser Reset. Der Server ist momentan als Wins-Server eingerichtet (auch auf allen Clients eingetragen); DNS noch nicht. DNS-Funktion ist auf dem Router aktiviert. Hier fehlt noch der Eintrag des externen (Telekom-) DNS-Servers Dass der Server hier irgendeine Rolle spielt, halte ich für eher unwahrscheinlich, da vor ca. 3-4 Wochen schon einmal eine ähnliche Symptomatik auftrat (Server stand da noch nicht vor Ort). Damals war die Funktion nach Einspielen einer älteren Router-Kfg verschwunden - aber vermutlich war das nicht die Ursache für die Fehlerbehebung. Nichtsdestotrotz müssten eigentlich die Tunnel unter den Routern aufgebaut sein - der Router am Standort meldet gemäß LEDs Synchronität und bestehende Verbindung. Die anderen 2 versuchen permanent aktiv, eine Verbindung herzustellen.

Bleibt nur noch die Frage, ob eine Einstellung bei Computerkonfig. -> Admin. Vorlagen -> Netzwerk/Netzwerkverbindungen -> 'Verwendung des Internetverbindungsfirewalls im eigenen Domänennetzwerk nicht zulassen" dann wirklich den Eintrag der Domain Policy in jedem Fall (seiner Anwendung) überlagert. Diese ist ja genaugenommen an einer anderen Stelle > Computerkonfig. -> Admin. Vorlagen -> Netzwerk/Netzwerkverbindungen -> Windows-Firewall -> Domänenprofil Im Normalfall sollte es so sein, da ja auch der Eintrag Windows-Firewall der anderen Einstellung untergeordnet ist.

@ nobex Die Einstellung ist vorhanden. (Natürlich fehlt auch diese in der beschädigten Default Domain Policy). Sicher ist das die bessere Wahl zum Konfigurieren der Einstellung. Stellt sich nur die Frage: wie wird bestimmt, ob jemand "im eigenen DNS-Domänennetzwerk" ist? Auch so, wie von ITHome beschrieben? Oder anders?

Danke. Das mit den Suffixen hatte ich in dem Artikel auch so verstanden. Aber die Schlußfolgerung hat mir gefehlt (Bestimmung über DNS-Suffix überlagert Bestimmung über IP). Nur warum steht das (Bestimmung über IP) nicht im Artikel? Dieser beschreibt ja ausdrücklich das MS-Verhalten zur Netzwerkbestimmung. Da noch kein DHCP implementiert ist, wäre es relativ aufwändig, auf jedem Client einen DNS-Suffix einzutragen (DHCP kommt aber bald). Da die Einstellung aber keine Lücke darstellt, wäre das Ganze in diesem speziellen Fall unkritisch (Firewall aus Standardprofil wird auch im anderen Subnetz auf dem Notebook angewendet, statt nur off site). Fazit wäre also: bewege ich einen Client (Computer und User sind Domänenmitglieder) von einem Subnetz der Domäne in ein anderes (und es ist kein DNS-Suffix konfiguriert), wird das Domänenprofil NICHT angewendet. Da das doch etwas einer allgemeinen Logik (bzw. dem angenommenen Standard-Verhalten) widerspricht, müsste so etwas in den MS-Unterlagen eigentlich besser herausgestellt werden.

Danke; werde ich mir morgen mal anschauen.