Hallo, ich habe letztens einen Versuch unternommen, das Netzwerk auf IPv6 umzustellen, bzw. IPv6-Unterstützung hinzuzufügen.
FritzBox 7490 (OS6.83) + Netgear GS108E Switch, Duo2 mit VTI 14.0.x, PCs mit Win7Ux64.

Musste dazu IPv6 in der Fritzbox, in der Netzwerkverbindung der PCs und den NIOc-Einstellungen der PCs aktivieren.
Soweit, so gut. IPv4 und IPv6 waren dann beide aufseiten der Fritzbox aktiv.

Probleme bekam ich erst, als ich übers Netzwerk (Windows-Explorer) Dateien von der Duo 2 auf nen PC schieben wollte.
Dies funktionierte nicht mehr: Die Übertragung wurde stetig langsamer und brach irgendwann ganz ab.
Per FTP mit Filezilla ging es aber trotzdem noch
Erst, als ich in der FB und dem PC das IPv6 wieder deaktiviert hatte, war der Netzwerktransfer von der Duo wieder möglich.
Woran kann das liegen?
Muss ich bei der Duo2 IPv6 noch aktivieren oder Pakete nachinstallieren oder kommt die damit gar nicht zurecht?
Zumal die IPv4-Funktionalität seitens der FB und des PCs weiter gegeben war, dachte ich erst, dass das kein großes Problem sein sollte.
Kommt die Duo2 (bzw. das VTI) damit durcheinander?

Keine Ahnung, das System (Win7U) läuft schon ewieg auf dem System (X79 mit 2×Intel Gigabit-Lan onboard).
Die FB habe ich auch seit vier Jahren oder so und kann mich nicht erinnern, mal IPv6 ausgeschaltet zu haben oder nicht.
Als ich letztens nachschaute, sah es so aus, wie in dieser Screenshot-Sammlung:
Habe überall die IPv6-bezogenen Optionen aktiviert und zunächst gar keine Probleme festgestellt.
Erst, als ich später diese seltsamen Verbindungsabbrüche beim Netzwerkkopieren von der Duo bekam, habe ich nach einer ganzen Reihe anderer erfolgloser Fehlerbehebungsmaßnahmen das IPv6 überall wieder deaktiviert.
Danach klappte die Übertragung von der Duo sofort wieder.
Davor hatten schon mehrfache Neustarts der FB, des PCs und der Duo nichts gebracht.
Das Umstellen auf IPv6 war die letzte Änderung, die ich vor dem Auftreten des Problems gemacht hatte und darum habe ich einfach versucht, was passiert, wenn ich die wieder rückgängig mache

Gruß, Magnus

Ist mir entgangen, dass es eine neue gibt, oder ich habe die Update-Benachrichtigung weggedrückt und es vergessen...

Ich versuche gerade, von 7 auf 10 upzugraden... habe es zur Probe auf einem zweiten X-79-System aufgesetzt. Viele Probleme bisher, zur Zeit startet es nicht.

Danke für den Hinweis! Aber da habe ich mich mißverständlich ausgedrückt; ich meinte das Upgraden im übertragenen Sinne, als Umstieg.
Es ist eine Neuinstallation, nur der Schlüssel ist von Win7. Aber nach dem Versuch, einige Treiber von Hand zu aktualisieren, startet es nicht mehr.
Auch nicht mit Hilfe der Setup-DVD. Ich werde es wohl löschen und neu machen müssen.

Das Hardware-Setup ist von Ende 2012.

Ich habe eine ISO mit dem Creation Tool erstellt, Anfang Dezember. Da für die Erstellung die Daten direkt runtergeladen werden, kann ich nur hoffen, dass es die 1809 geworden ist.
Ich habe eine Pro installiert. Eigentlich wird doch immer das Gleiche installiert, es hängt von der Lizenz ab, was aktiviert wird, oder?


Ich finde es schon seltsam, dass nach Ende der Installation der Desktop weiterhin in einer Kompatibilitäts-Auflösung (1024) gebootet wird und nicht, wie beispielsweise nach dem Win7-Setup, gleich in der nativen Auflösung des Monitors (1080p).
Auch war nach dem Win7-Setup bereits ein zumindest herstellerspezifischer Grafiktreiber installiert (bei mir Nvidia), Win10 hatte da noch einen "Standard-Grafikkarten"-Treiber gewählt.
Der Sata-Controller des Chipsatzes war als "Standard-AHCI-Controller" eingebunden und nicht, wie bei Win7 nach dem Chipsatz-Update, als Intel X79/C600 Sata Controller. Dies hat sich auch nach Updateversuchen nicht geändert.
Einige Onboard-Geräte waren noch gar nicht installiert, und das bei einer etablierten Plattform.
Ich habe keine passenden Intel-Sata-Treiber (RST) für X-79 und Win10 gefunden, für die Onbaord-Controller von Marvell und ASMedia musste ich mir was aus Foren raussuchen, beim Hersteller und bei Microsoft wurde da erstmal nichts gefunden. Ich finde das alles sehr merkwürdig.

Irgendwann, nachdem ich manuell die Installation eines RST-Treibers angestossen hatte, startete das System nicht mehr richtig.
Ich schreibe "irgendwann", weil ich es nicht genauer eingrenzen kann, es lagen noch einige Neustarts dazwischen. Aber das war die letzte Änderung. Vielleicht noch die Installation eines Marvell-Treibers, aber auch diese führte nicht dirket zum "Versagen".
Ich kann jetzt stundenlang dem Startlogo und den kreiselnden Punkten zuschauen.
Reparatur-Aktionen und auch Reparatur-Installationen oder "Zurücksetzen" verlaufen alle erfolglos (genauso wie unter jedem vorherigen Windows, ich kann mich nicht erinnern, dass jemals ein Problem dadurch gelöst wurde), jedwede andere Startoption, ob von Bootmedium oder aus der Starthilfe heraus, verlaufen immer mit dem gleichen Ende: Ich drücke irgendwann Reset, wenn das Start-Logo wieder ewig lang zu sehen war.
Es gibt auch keine protokollierte Startoption, bei der ich sehen kann, was alles geladen wird und ab wann es hängt.

Ich habe irgendwann vor dem Monitor sitzend zu mir selbst gesagt, dass sich wirklich nichts Grundlegendes an Windows geändert hat: Solche Ausfälle und Stillstände kenne ich von Win2000, XP und 7 auch.
Wo ist denn da die grundlegende Verbersserung? Ein EDV-Händler riet mir vor einigen Jahren, ich solle es statt mit Win7 mal mit Win10 bei meinem X79-System versuchen. Da gäbe es weniger Probleme mit Treibern und Powermanagement.
Bis jetzt habe ich aber Win10 noch nicht mal dauerhaft zuverlässig ans Laufen gebracht

Ha, danke, ich bin schon in Fernandos Forum unterwegs
Da hangeln wir uns an dieser Frage entlang, allerdings betrifft es da eine konkrete Win10-Installation auf einem Test-X79-System, da ich nie das aktuelle System verlasse und auf ein neues wechsele ohne Evaluation.
Das Systemlaufwerk des alten Windows bleibt dabei meistens ebenfalls erhalten und es wird ein Ersatz beschafft...

Da ich bei dem anderen X79-System bisher einige Probleme bekommen habe, war diese Vorsicht also gar nicht so unangebracht.
Windows 10 hat aber zumindest schon selbst Nvidia-Treiber gefunden, ich werde wohl trotzdem nochmal den letzten, den ich habe, installieren.
In diesem Sytem kommt eine GT710 als Platzhalter zum Einsatz, das sollte kein Problem darstellen.

Aber auf dem System, von dem ich hier schreibe, läuft noch eine Weile Win7Ux64; und auf das beziehe ich meine Frage nach dem IPv6-Problem, dass ich hier habe.
Obwohl mir die Nebendiskussion, die sich hier ergeben hat, nicht unwillkommen ist.

Ich habe beim ersten Setup von Windows 10 gar keine Version ausgewählt, sondern einen Win7Ultimate-Key eingegeben.
Daraufhin konnte ich später nach dem Setup sehen, dass Win10 Pro installiert worden ist.
Aber da man durch Ändern des Schlüssels vom Desktop aus eh die Version ändern kann, wird am Ende doch immer das Gleiche installiert und basierend auf dem Schlüssel/der Lizenz einfach aktiviert oder nicht. Oder?
Wenn ich ein weiteres Mal auf die gleiche Partition installieren will (weil ja die erste und inzwischen auch die zweite Installation nicht mehr startet), dann wähle ich, dass ich keinen Schlüssel habe.
Danach komme ich erst in ein Auswahlmenü, in dem mir die Versionen oder Editionen oder wie auch immer das jetzt gerade im MS-Marketing-Sprech heißt, zur Auswahl angeboten werden.
Aber nein, ich habe nicht nur die Auswahl zwischen "Educational", "Home" und "Pro", sondern auch noch zwischen "Educational N", "Home N" und "Pro N". Was ist das jetzt wieder.

Die zweite Neu-Installation hat sich inzwischen in die "Bootet-nicht-zuende-Schleife" verabschiedet, nachdem ich versucht habe, den Marvell-Treiber zu installieren.
Ergebnis: Endlose Sanduhr auf dem Desktop.
Und dieses großartig weiterentwickelte beste Windows aller Zeiten schafft es nicht, von dort ausgehend, das System zu reparieren, zurückzusetzen oder die Änderungen rückgängig zu machen.
Wieder sind alle weiteren Anläufe aus dem Starthilfe-Menü oder von der Setup-DVD umsonst: Es passiert einfach gar nichts außer Meldungen, dass nichts repariert werden konnte oder endloser Startbildschirm-Sanduhr.
Wenn ich so eine "Zurücksetzung" anstosse, dann werkelt das System irgendwas rum, für das es länger braucht, als für ein komplettes Neu-Setup. Was macht es da??? Am Ende kommt, wie immer nichts dabei raus.
So einen Mist habe ich mit Windows 7 vielleicht auch mal erlebt, aber wenn, dann seltener.
Protokollierten Start haben sie ja auch entfernt, so dass man auch nicht mehr sehen kann, an welcher Stelle (welchem Treiber?) der Start hängen bleibt.
Was soll man mit sowas?

Bezüglich des RST-Treibers: In Fernandos Win-Raid Forum wurde mir zumindest dazu geraten, den zu installieren. Und das funktioniert auch mittlerweile, sogar direkt beim Setup, durch Einbindung vom USB-Stick.
Aber der Rest...

Die Marvell-Treiber sind nicht aus einer dubiosen Quelle, sondern von der Asus Website, der Treiber-CD und Fernandos Forum, dass man, wenn man sich etwas damit beschäfigt, nicht gleich als dubiose Quelle ansehen muss. Die Admins dokumentieren ihre Datenbak und deren Nutzung sehr ausführlich und mit denen schreibe ich auch über diese Problemstellung, nicht mit irgendwelchen anderen Bastlern.

Inzwischen habe ich viermal ein neues Setup durchgeführt, was auch durch Einbinden des Intel RST-Treibers deutlich schneller vonstatten ging als mit Bordmitteln des Bootmediums: Ungefähr je 10 Minuten statt vorher je 2 Stunden.
Soviel also zu fremden Treibern und dem Vertrauen aufs Bootmedium...
Der "Standard-Sata-AHCI-Controller" von Microsoft ist eben nicht der optimale Treiber.
Warums sollte sich das nach 7, 8 oder 10 Jahren auch ändern?

Wenn ich das System machen lasse und Windows Update befrage, werden irgendwann auch die Chipsatz-Infos installiert, die Fremd-USB-Controller und auch die Intel ME.
Sehr schön.

Was bleibt, ist ein Marvel 9128 Controller, der im Gerätemanager erst unbekannt ist, später als "Standard Sata AHCI-Controller" angezeigt wird.
Mit Ausrufezeichen.
Wenn ich dann eine mvs91xx.inf installiere, verschwindet zumindest das Ausrufezeichen und das Gerät scheint zu funktionieren.
Jedoch sind dann die meisten Felder im dazugehörigen Gerätemanager-Tab ausgegraut: Man kann es quasi nicht deinstallieren oder noch mal updaten oder sonstwie austauschen.
Es spielt auch keine Rolle, welche Version der mvs91xx.inf ich nehme: Ob sie aus den Paketen von Asus für Win 7 oder 8.1 stammt, oder aus der achso dubiosen Quelle eine Version für win 7, 8.1 oder 10 ist.
Sie werden alle akzeptiert und dann ist wohl die Grundlage für das Problem gegeben.

Ich habe diesmal einen Wiederherstellungspunkt anglegt, bevor ich mich mit dem Marvell-Controller befasst habe und darum konnte ich etwas ausrobieren:
Deinstallieren des Gerätes wird zur Endlosschleife, die Operation "Nach geänderter Hardware suchen" wird ebenfalls zur Endlosschleife.
Nicht ganz endlos, denn nach einer halben Stunde oder so höre ich den Rechner dann neustarten.
Der Neustart endet dann im beschriebenen Problem, dass das Sytem ewig im Win10-Boot-Bildschirm verbleibt.

Es haben auch keine Reparatur-Versuche mit Bord-Mitteln einen Sinn, egal welche ich anstosse.
Nur die Rückkehr zum vorherigen Wiederherstellungspunkt bringt mich wieder ins System.

Das Deaktivieren des Controllers im Bios ändert übrigens nichts am Ausrufezeichen im Geräte-Manager, das Gerät taucht trotzdem weiterhin auf.
Es scheint ein Problem speziell mit dem Marvell-Controller zu sein. Auf meinem anderen System und Win7 habe ich dieses Problem bisher nicht, die Ausstattung ist fast identisch.
Was ich nicht verstehe ist, warum Win10 nicht den Fehler verursachenden Treiber deaktivieren oder entfernen kann.
Was mache ich eigentlich bei zukünftigen Windows-Updates? Wenn dort versucht wird, die Gerätetreiber zu aktualisieren, dann kann ich ja wieder dieses Problem bekommen?