BlackHell

17 Stunden Backup kommen daher, dass das bisherige interne Netzwerk nur auf 100MBit lief. Es hätte auf 1GBit laufen können, wenn der Server 2008 R2 mitgemacht hätte. Der sagte aber, dass er alle kommunikation nur mit 100MBit durchführt, da 1 Client, in dem Falle die LTE Box, nur 100MBit kann. Somit ist das ganze Netzwerk dazu verdonnert gewesen auf 100MBit zu bleiben. Durch den Umbau läuft das interne Netz jetzt auf 1GBit und der Server kann mit der LTE Box weiterhin in 100MBit kommunizieren. So weit so gut. Mit der GL rede ich jeden Tag. Der externe, der das System hier eingerichtet hat, bevor ich anfing, ist zwar IT-Systemkaufmann, hat aber nur die MCP Prüfung gemacht. Für mich ist das so: Ich habe 2 Router, die die selbe IP Adresse haben, aber natürlich unterschiedliche MAC-Adressen. Den ARP Cache juckt das aber nicht, der ist beim Umstecken bei der gleichen IP mit der anderen MAC Adresse parat. Die Firewall kann es eigentlich auch nicht sein, da diese rein über die IP Adressen eingerichtet ist und da muss ich ja nichts ändern, da beide Router ja die selbe haben. Ich hoffe, ich kann nächste Woche noch ein paar tests machen. Da es auf Ostern zugeht, ist bei uns immer so viel los, dass ich nicht genug Zeit zum Testen habe.

Es ist ein berufliches, aktives Netzwerk. Ich kann den alten Zustand nicht wieder herstellen und dort den Fehler suchen, da er dort NICHT aufgetreten ist. Wenn ich den alten Zustand wieder herstelle, dauern die Backups vom Server zum NAS wieder 17 Stunden und mehr. Das ist für das berufliche Netzwerk inakzeptabel. D.h. Ich lasse den jetzigen Zustand und hoffe weiterhin auf eine Lösung, warum etwas, das vorher klappte, nicht mehr funktioniert.

Ich kann hier nur mit dem Arbeiten, was vorhanden ist. Geld für einen extra Firewall Rechner, selbst mit IPFire, ist nicht vorhanden. Der Platz dafür auch nicht. Ich dachte auch schon daran, ob der Arp Cache schuld sein könnte, doch der ist nicht die Ursache.

Zum besseren Verständnis habe ich das mal mit DIA aufgezeichnet. Ich dachte, eventuell haut mir der ARP Cache vom Server da dazwischen. Konnte dies aber noch nicht prüfen.

Und da war er schon wieder, der Umrechnungsfehler von GigaBIT nach GigaBYTE :) Gemessen habe ich von einem Client-PC zum Server. Das ist aber das interne Netzwerk. Meine Herausforderung besteht ja dahingehend, dass ich die Fritz!Box gegen eine andere / neue austausche und der Teil, der für die Verbindung zum Internet verantwortlich ist, zusammenbricht und keine Verbindung mehr herstellen kann. Ich möchte auch kein ICS verwenden oder die Netzwerkkarten "überbrücken", da ich hier ein produktivsystem habe, welches ich nicht selbst aufgesetzt habe.

Mit Netio überprüft bekomme ich als höchstwert 73,60MBytes/s angezeigt. Das kommt mir schon sehr sonderbar vor. Ich hätte mit höheren Werten gerechnet. Der Server 2008 wurde per RRAS Rolle nur zum NAT Router. Sonst hätt ich wohl noch einige spezifische Router zu Router Einstellungen machen müssen.

Nur um Missverständnissen vorzubeugen: Wenn ich den Server mit einem Bein am Router habe, und der Router immer die selbe IP hat, egal ob ich ihn wegen ausgefallenem LTE oder ausgefallenem Router wechseln muss, wenn die IP des Routers dabei die selbe bleibt, sollte alles so funktionieren wie vorher eingestellt. Tut es aber nicht. Der Server geht auf 10MBit zurück und weigert sich mit dem neuen Router zu kommunizieren. Das ist das, worüber ich stolpere und keine Lösung für habe.

Der Windows Server 2008 R2 sagte von sich aus, dass er, da er nur mit 100MBit mit der LTE Box kommunizieren kann, alles auf 100MBit belässt. Dadurch haben auch die Clients untereinander nur mit 100MBit kommuniziert. Zu diesem Zeitpunkt war auch nur 1 Netzwerkkarte des Servers belegt. Der Server ist ein DC mit AD, DHCP, DNS, WSUS und Webserver. (Ich weiß, dass WSUS und DC nicht auf einem Server laufen sollten, aber aufgrund des LTE Datenvolumens und mangels Möglichkeiten für einen zweiten Server ist das so das optimalste) Das Backup ist das interne Windows Server Sicherungs Backup und erfolgt auf ein internes NAS.

Moin! Bisherige Situation: Vom Router ging das Netzwerkkabel in eine Gigabit Switch und dort waren auch alle PCs und der Server 2008 R2 angeschlossen. Da die Vodafone LTE Box mit dem Server nur in 100MBit kommunizieren kann, wurde damit das gesamte Netzwerk auf 100MBit beschränkt. Eine komplette Server Sicherung dauerte dadurch bis zu 17 Stunden. Für den Fall, dass die LTE Verbindung nicht funkioniert, konnte auf die "private" Fritz!Box umgesteckt werden. d.h. LTE Box und Fritz!Box haben die gleiche IP: 192.168.1.1/24 der Server 2008 R2: 192.168.1.100/24 die Client PCs hatten alle fest eingestellte IPs. Änderung: Ich habe nun die Verbindung vom Router direkt in den Server geleitet und diesen per Routing und RAS Rolle zum Gateway gemacht. Als neuen internen IP Bereich habe ich die 192.168.2.0/24 gewählt. Die Client PC wurden auf DHCP umgestellt. Der Server hängt nun mit 192.168.1.100/24 am Router und mit 192.168.2.100/24 im internen Netzwerk. Dadurch haben wir endlich 1GBit LAN und das Backup dauert nur noch 6 Stunden. Nach Anpassung der Firewall funktioniert auch der Netzwerkverkehr von intern ins Internet usw. Problematik: Fällt das LTE Netz aus und ich muss auf die "private" Fritz!Box umstellen, bekomme ich Verbindungsabbrüche, wenn ich versuche die Fritz!Box zu pingen oder andere Adressen außerhalb. Zudem fällt die Verbindungsgeschwindigkeit auf 10MBit runter, statt auf 100MBit zu bleiben. Ich kann auch die Benutzeroberfläche der Fritz!Box nicht erreichen, weder vom Server noch von einem der Clients. Normalerweise sollte doch alles weiter funktionieren auch wenn ich umstecken muss, da beide Router die gleiche IP haben. Wo ist mein Denk- und Einstellungsfehler?

Danke für die Antworten. Mit fiel noch eine Möglichkeit ein, die ich genutzt habe und die endlich auch den gewünschten Erfolg brachte. Ich startete immer im Abgesicherten Modus mit Netzwerktreibern. Das war wohl falsch. Heute ging ich her und stellte über msconfig den Diagnosesystemstart ein und meldete mich dort als Administrator an. Ich bearbeitete wieder die Registry und startete neu. Danach konnte ich mich ganz normal anmelden. JUHU. Ein erneuter Blick in msconfig offenbarte mir aber, dass nun immer ein Benutzerdefinierter Systemstart stattfindet. Es hat wohl eine Anwendung erwischt und diese scheint die Probleme zu verursachen, da genau diese die einzige ist, die unter Systemstart nicht aktiv ist. Ich werde noch prüfen, ob eine Neuinstallation dieser Anwendung mich unter msconfig wieder Normaler Systemstart auswählen lassen wird.

Moin! Bei uns gab es unerwartet einen Stromausfall, bei dem auch die Nachbars***aft usw. betroffen war. Dank USV konnte ich den Server korrekt herunterfahren. Bis auf einen einzigen Client kann man sich mittlerweile überall wieder normal anmelden. Auf diesem Windows 7 Professional Client kam die Meldung, dass der Profildienst nicht gestartet werden konnte. Ich wurde mit einem temporären Profil angemeldet. Nach dem ich mich als Administrator, ohne abgesicherten Modus, angemeldet hatte, in der Registry bei ProfileList alles notwendige editiert hatte, gelang mir auch das erneute einloggen. Aber nur 1x. Danach wurde ich immer per temporärem Profil angemeldet. Starte ich den Client im abgesicherten Modus, kann ich mich ganz normal mit dem richtigen Profil anmelden. Ich lies den Client angemeldet erstmal in Ruhe und als ich etwas später zurück kam, hatte er einen Neustart hinter sich und ich bekam wieder ein temporäres Profil. Es war garantiert keiner an dem Client, der den Neustart hätte auslösen können. Einmal war auch ein Bluescreen von 0x24 über die NTFS.sys, der tauchte aber nicht mehr auf. D.h. etwas, dass nicht im abgesicherten Modus geladen wird, aber beim normalen Start, scheint für diesen Fehler verantwortlich zu sein. Wie kann ich das noch weiter eingrenzen, ohne das Profil kopieren, bzw. neu anlegen zu müssen?