Q -kju:-

Hmm, gegen Geiz kann man leider nix machen. Das Umdenken setzt erst nach dem Schaden ein..:rolleyes:

Ja, habe ich auch schon mehrfach durchgezogen. Das Ereignisprotokoll glüht zwar temporär rot, aber danach ist alles wieder paletti. Man sollte vor dem Tausch noch prüfen, ob im DNS-Server oder den Terminaldiensten evtl. eine Bindung an die (alte) Karte fest eingestellt ist und diese auf "Alle verfügbaren Adapter" umstellen. Nachdem die Karte getauscht und konfiguriert ist, kann man bei Bedarf die Bindung wieder zuordnen.

Einen überdurchschnittlichen Anstieg der Defekte kann ich aus meiner Praxis nicht bestätigen. Festplatten sind und waren jedoch schon immer die häufigste Ausfallursache am PC, dicht gefolgt von Netzteilen. Und ja, Desktop-Platten (IDE/S-ATA) gehen häufiger kaputt als SCSI-Platten. Letztere sind offensichtlich robuster gebaut und haben auch eine weitaus höhere MTBF. Ich setze sie in Servern aber nicht deswegen bevorzugt ein, sondern weil Modelle mit ähnlich niedrigen Zugriffszeiten im ATA-Lager kaum zu finden sind. Da ich bei Servern ohnehin grundsätzlich mit RAID1 arbeite, spielt die Ausfallsicherheit eine untergeordnete Rolle. Wo es auf geringen Lärmpegel ankommt, z.B. wenn der Server in einem Büro stehen muß, verbaue ich wiederum in erster Linie ATA-Platten. Kurioserweise mußte ich bisher noch keine einzige IDE- oder S-ATA-Platte ersetzen, die in einem RAID-Verbund arbeitete. Und manche davon liefen/laufen schon mehr als 5 Jahre im Dauereinsatz. Murphys Gesetz at it's best. :D Es gibt auch immer wieder mal "schwarze Serien", also Harddisks, die wegen Konstruktionsfehlern sterben. Krassestes Beispiel dafür waren die vor einigen Jahren auf den Markt gekommenen Modelle von Fujitsu, die als erste Flüssiglager besaßen und sich wegen der Laufruhe großer Beliebtheit erfreuten. Die Freude hielt allerdings nicht lange an. Infolge fehlerhafter Chips fielen die reihenweise aus, natürlich erst nach Ablauf der Garantie. Die Ausfallrate belief sich (bei mir) auf ca. 75%!! Fujitsu war der Fehler bekannt und startete dennoch keine Rückrufaktion. Kulanz auch Fehlanzeige. Aus diesem Grund meide ich bis heute alle Produkte, wo Fujitsu beteiligt ist. Auch IBM hatte ähnliche Probleme mit bestimmten Deskstar- und auch SCSI-Modellen, tauschte diese jedoch anstandslos aus. Man kann Ausfälle erfahrungsgemäß nicht verhindern, aber man kann den Festplatten Gutes tun, indem man sie ordentlich kühlt. Killerfaktor Nr.1 sind nämlich zu hohe Temperaturen. Bewährt haben sich folgende Grundsätze: - die Platten sollten nach oben und unten mindestens eine Bauhöhe Luft haben. - sie sollten im Gehäuse möglichst weit unten eingebaut sein, wo die niedrigsten Temperaturen herrschen. - wo immer möglich, sollte ein Lüfter die Platten zusätzlich mit kühler Luft von außen anströmen. Das kann auch ein langsam drehender, leiser Lüfter sein. - wenn aktive Kühlung aus baulichen Gründen nicht möglich ist, sollte die Platte zumindest im Luftstrom liegen oder großflächig mit dem Gehäuse verschraubt sein. Silencer-Kits, welche die Vibrationen dämpfen, wirken sich auf die Kühlung leider kontraproduktiv aus, weil sie auch die Wärmeabfuhr verschlechtern. - and last but not least, wenn's geht RAID1 benutzen. Die Riesenkapazitäten moderner Festplatten haben leider auch einen dramatischen Nachteil. Die Daten lassen sich kaum noch sinnvoll auf externe Medien sichern, außer wiederum auf andere Festplatten. Ein Teufelskreis... :suspect:

Daß ein Controller die Platten zerstört, habe ich noch nicht erlebt. Zum Fehlerbild fallen mir spontan zwei Dinge ein. Erstens hat das Mainboard mgwl. Probleme mit dem Bus-System und zweitens, wie wird das Ganze eigentlich gekühlt? Wie heiß werden die Platten?

Hast du das so realisiert, wie ich es oben beschrieben habe (Client-Bridge)? Wenn ja, dann arbeitet der zweite Router gar nicht als Router, sondern quasi als eine Art Switch und hat weder mit NAT, noch mit Gateway etwas zu tun. Standardgateway muß der Speedport sein, DNS-Server normalerweise auch (sofern es keinen anderen im Netz gibt). Da ein Ping auf externe Server funktioniert, liegt mglw. ein DNS-Problem vor. Du kannst das testen, indem du statt der Domain mal die IP-Adresse im Browser eingibst, bspw. "http://216.239.59.104/" (Google). Schau mal, ob das funktioniert, dann sehen wir weiter.

Nur so als Hinweis: Du bist dir schon bewußt, daß die aktivierte Fernkonfiguration ein hohes Sicherheitsrisiko in sich trägt?? Zumal, wenn ich mich recht erinnere, in einigen Netgear-Routern von Haus aus Backdoor-Paßwörter eingebaut waren. Ich habe mit den Teilen allgemein keine gute Erfahrungen gemacht und setze sie nicht mal mehr im SoHo-Bereich ein. Desweiteren ist die Fernverwaltung mittels simpler Portweiterleitung gleich das nächste Hochrisiko. Alles was einen Angreifer dann noch hindert, ist die Kombination aus Benutzername und Kennwort. Ich würde dir empfehlen, eine hardwarebasierte VPN-Lösung mit vernünftigen Routern (z.B. LANCOM) zu realisieren. Selbst wenn keine sicherheitskritischen Daten in dem Netz liegen, ein Sciptkiddie-Angriff könnte zumindest die Arbeit lahmlegen. Ich würde da meinen Kopf nicht hinhalten wollen. ;)

Guck mal im Taskmanager unter Ansicht/CPU-Verlauf, was da angehakt ist. Es lassen sich nämlich auch alle Kerne in ein Diagramm zusammenfassen.

Besitzt der Router einen "Stealth"-Mode und ist dieser womöglich aktiviert?

Dem Tip würde ich mich 1:1 anschließen. Ich sehe die Situation so: Eure System-Kenntnisse gehen nur wenig über die eines Durchschnitts-Users hinaus. Geld wollt ihr möglichst auch nicht ausgeben. Die Schweizer müssen ein sehr optimistisches Volk sein. Sonst würdet ihr bestimmt nicht davon ausgehen, eine solche, nicht unheikle Operation unter diesen Voraussetzungen hinzubekommen. Es ist schlichtweg nicht möglich, das über Jahre praktischer Erfahrung erworbene Wissen eines Administrators in einem Handvoll-Postings-Crashkurs weiterzugeben. Selbst wenn wir euch eine Step-by-Step-Anleitung liefern, bleiben immer noch zahlreiche Unwägbarkeiten, mit denen ihr im Ernstfall überfordert wäret. Setzt euch einfach mal hin und rechnet die Kosten für einen Spezialisten mit denen auf, die anfallen, wenn die Aktion schiefgeht und der Server ausfällt oder gar die Daten weg sind. Da kommen ratzfatz ein paar 1000 Euro zusammen. Müßt ihr selbst wissen, ob es das Risiko wert ist...

Das ist ein ganz böses Zeichen, die Platte liegt im Sterben. Jede Festplatte hat ein Defektmanagement, welches unzuverlässige Sektoren automatisch in Reservebereiche umlagert. Man bekommt davon extern gar nichts mit. Sind die Reservesektoren jedoch auch schon voll, dann führen weitere Defekte unmittelbar zu Datenverlusten. Mach am besten sofort ein Image von deiner Installation, damit die nicht umsonst war.

Merkwürdige Sache. Kontrollier als erstes, ob die Bootreihenfolge im BIOS noch stimmt bzw. ob die Festplatte dort überhaupt als Bootdevice auftaucht. Ansonsten starte von der Windows-CD, rufe die Wiederherstellungskonsole auf und repariere mit den Befehlen "fixmbr" und "fixboot" den MBR und den Bootsektor.

Das hat (leider) nicht viel zu sagen. Die MTBF ist auch nur ein statistischer Mittelwert, ermittelt in einem aufwendigen Test mit einer großen Stückzahl von Harddisks. Einzelne Platten können durchaus viel öfter oder früher ausfallen. Wie dem auch sei, die SMART-Daten lassen sich nicht manipulieren. Sie werden in speziellen Spuren gespeichert, auf die nur die interne Platten-Firmware Zugriff hat. Sie gehen auch bei einer Lowlevel-Formatierung nicht verloren.

Zusätzlich "Scriptverarbeitung ...deaktivieren" auf JA setzen, dann werden auch keine Batches mehr ausgeführt. Nachteil: Logonscripts funktionieren ebenfalls nicht mehr.

Du meinst, wir sollen hier deine Hausaufgaben mundgerecht aufarbeiten?? Einen groben Vergleich kannst du hier nachlesen. Für weitere Details schaden ein paar eigene Recherchen sicher nicht, auch wenn sie bißchen Arbeit machen. Aber so lernst du auch mehr, als nur fremde Ausführungen per Copy-and-Paste zu übernehmen. ;)

Bevor du an Einstellungen drehst, solltest du zunächst feststellen, in welcher Richtung der Fehler zu suchen ist bzw. noch besser, wo er nicht zu suchen ist. Du mußt ja nicht gleich einen Router kaufen, irgendjemand wird dir doch sicher einen für paar Stunden borgen können. ;)

klingt nicht übel, aber der Preis ist für die Bastelwerkstatt wohl zu heftig.

Ich hatte bisher drei ähnlich gelagerte Fälle. Im ersten Fall traten sporadische Zusammenbrüche des VPNs bei allen Außenstellen auf. Die Telekom hatte den DSL-Anschluß der Firmenzentrale überprüft und i.O. befunden. Nach tagelanger Suche und Ausschluß anderer Fehlerquellen intervenierte ich mit Hilfe des Pingplotter-Logs erneut bei der Telekom. Die Techniker waren wiederum überzeugt, daß ihrerseits alles OK wäre, schlugen dann jedoch sicherheitshalber vor, die Leitung auf einen anderen DSLAM zu schalten. Nachdem dies geschehen war, hörten die Probleme schlagartig auf. Im zweiten Fall war nur eine Außenstelle gestört. Der Techniker der T-Com wußte offensichtlich gleich, was Sache ist, denn kurz zuvor hatten sie dem Multiplexer ein Software-Update verpaßt. Nach Umschaltung der Leitung gab es auch hier keine Störungen mehr. Im dritten Fall konnte ich die Paketverluste auf eine Übergangsstelle zwischen T-Com-Netz und Enviatel eingrenzen. Trotz mehrfacher Anmahnung war die T-Com (bzw. Enviatel) jedoch bis heute nicht in der Lage, Abhilfe zu schaffen.

Ja, da hatte ich mich verlesen. Versuch es trotzdem mit einem anderen Router, möglichst ein völlig anderer Typ und Hersteller. Wenn der Fehler nachvollziehbar weiter auftritt, tausch als nächstes die WLAN-Karte.

WIE nutzt er es denn? Für VPN wahrscheinlich nicht. Beim Surfen im Web stören ein paar verlorene Pakete nicht, ein VPN stören sie kolossal. Mach mal einen Dauertest mit Pingplotter. Dann siehst du, ob die Verbindung wirklich stabil ist bzw. wo die Paketverluste auftreten.

Stimmt so nicht. Richtig ist, daß viele ältere WLAN-Karten kein WPA unterstützen. Das liegt aber an der Firmware bzw. dem Treiber. Der WLAN-Chip, über den ich gerade WPA-verschlüsselt poste, ist auch ein 802.11b (Intel Pro 2100). Ich vermute die Ursache in einer Fehlfunktion des Netgear-Routers. Mit den Teilen hatte ich schon sehr oft nicht nachvollziehbare Probleme, vor allem bei WLAN. Vielleicht kannst du mal ein anderes Gerät borgen und damit testen, ob der Fehler bestehen bleibt oder nicht.

Windows 3000 :shock: Hehe, ihr seid der Zeit ja weit voraus. :D Fernwartungsprogramme heißen Fernwartungsprogramme, weil man: 1. damit Wartungsaufgaben von der Ferne erledigen kann und 2. man recht lange auf den Bildaufbau warten muß. Sprich Fernwartungsprogramme wie Teamviewer, VNC usw. sind zu langsam, als daß man damit vernünftig arbeiten könnte. Wenn das Programm auf Terminalserver läuft, wäre dies die empfehlenswerte Variante. Alternativ ließen sich auch normale PCs (mit Windows XP Prof.) per Remotedesktop fernbedienen. Allerdings kann da nicht gleichzeitig remote und lokal gearbeitet werden, sondern nur entweder oder. Also besser Terminalserver, alles andere ist mehr oder weniger Bastelei.

Das macht Keyfinder mit einer einzigen Zeile: keyfinder.exe /u key.txt

@ducke Na gut, die aus der Rütli-Schule vielleicht nicht. Deren Interessenschwerpunkt ist anders gelagert...:D

Ist auch von Microsoft höchstselbst sehr gewagt, den ehemaligen ERD-Commander nunmehr als "Microsoft Diagnostics and Recovery Toolset" (kurz DaRT) zum freien Download anzubieten.. ;)

Grauzone würde ich sagen. Auf die Daten kann man ohnehin mit jeder Knoppix-CD oder ERD-Commander zugreifen, weiß jedes Kind. Das funktioniert sowieso nur mit lokalen Konten. Bei AD-Konten, einschließlich des Domänen-Admins versagt der Offline-Editor. Die Netzwerk-Administratoren können sich also beruhigt zurücklehnen (zumindest in dieser Beziehung).. ;)