Im Prinzip sollte es jedes Sata-Kabel tun...
--> https://geizhals.de/?cat=kabelfp&xf=...rt=p&bl1_id=30
Wenn Kabel mit Sata1/2/3 beworben werden ist das erstmal nur marketing.
Ab Sata2 haben die Kabel Clips zum arretieren.
Wie gesagt, ist nur eine Vermutung ins blaue, weil das Problem mehrere identische Systeme betrifft (und die haben Kabel in der gleichen Qualität verbaut).
Bios-Update schadet idR auch nicht...
--> https://www.dell.com/support/home/de...e=optiplex-390
Geändert von drdope (07. September 2019 um 14:12 Uhr)
Danke dir.
Bei der Gelegenheit, wenn ich eh die paar Kabel bestelle stieß ich beim gleichen Thema noch kurz auf einen (anderen) Gedanken:
Als die Serverumstellung Anfang des Jahres ablief, hat der Techniker die beiden Patchkabel vom Server zum Switch ausgetauscht mit dem Hinweis darauf, dass die voherig verwendeten bei den anfallenden Datenmengen (oder der Geschwindigkeit, ich weiß jetzt nicht mehr genau wie die Formulierung war) der verwendete Kabeltyp nicht zeitgemäß/ausreichend wäre.
Ich gebe zu, ich weiß ad hoc nicht, welcher Kategorietyp das Patchkabel hatte, aber alle anderen Netzwerkkabel sind noch die gleichen. Welches der Techniker jetzt genommen hat, kann ich ja nachschauen, bin aber gerade nicht vor Ort.
Gibt es eine allgemeine Empfehlung, von wo nach wo innerhalb des LAN welche Kategorie für Patchkabel zu favorisieren ist?
(Router 1, Router 2, Switch, Server, Peripherie, NAS, …)
Lohnt sich mal eine grobe Aufstellung, wenn ich später in der Apo bin? Oder ist das eher irrelevant?
Hintergrund:
Ich bin nicht der Typ, der gerne alleine für eine SATA-Kabelbündel im Wert von 7,50€ eine Bestellung auslöst.
Daher die Überlegung...
Mundus vult decipi, ergo decipiatur.
Solang du keine Verbindungsabbrüche hast, die auf einen Kabeldefekt hindeuten könnten oder das (interne) Netz dir zu langsam ist, sind die Kabel egal.
Sehe ich auch so, solange es keine Probleme gibt, würde ich auch nichts tauschen.
--> https://de.wikipedia.org/wiki/Ethernet#Kabel
Alles >= Cat5e reicht aus, zumal dein Switch ja eh kein 1000BASE-T bietet.
Okok, dann nicht, alles gut.
Ich habe mal nachgeschaut, außer 5E und 6 finde ich da nichts. Wird also passen, wenn ihr das sagt.
Merci.
1)
BIOS-Updates der Klient-PCs habe ich heute versucht.
Funktioniert per Installer aus der Windows-Umgebung, soweit idiotensicher.
Bei einigen (4 oder 5 von den 7) ist das total reibungslos abgelaufen und dauerte 3 Minuten.
Wenige PCs streiken jedoch total, indem sie auf den Doppelklick der Datei gar nicht sichtbar reagieren.
Egal ob Doppelklick links oder Rechtsklick und Ausführen als Administrator, nix passiert.
Über die Eingabeaufforderung passiert ebenso nichts, auch im abgesicherten Modus das gleiche.
Hat jemand eine Idee?
Security-Software ist überall die gleiche installiert, ein Blocken über diese halte ich für unwahrscheinlich, zumal sicher eine Meldung erschienen wäre.
2)
Irgendwie ärgerte mich beim Kopieren des Firmware-Updates die Netzwerk-Konfiguration, indem ich bei einigen PCs mehrfach abgewiesen wurde beim Kopieren der DELL-Datei vom Netzlaufwerk auf die lokale HDD - angeblich kein Zugriff auf das Netzlaufwerk, im selben Augenblick hatte ich ja aber den Ordner offen.
Gibt es da bekannte Fallstricke in puncto Zugriffsrechte o.ä.?
Braucht ihr dafür die definitive Fehlermeldung, um es einschätzen zu können?
3)
Der Zentral-Klient bemängelt nun regelmäßig die zuletzt gepostete Fehlermeldung des "schwerwiegenden Fehlers" bei Klick in die Taskleiste.
Inzwischen habe ich bei den Wiederherstellungszeitpunkten auch keine "alte" Version mehr angezeigt zur Verfügungund sehe keinen echten Escape. Ich will doch jetzt nicht noch das komplette Benutzerprofil neu einrichten müssen...
Mundus vult decipi, ergo decipiatur.
zu 1)
Starte das Update mal testweise über die cmd/shell, dann sollte man zumindest eine Fehlermeldung bekommen.
Gibt es auf dem Mainboard evtl. einen Jumper für "Firmware-Schreibschutz"?
zu 2)
Schau dir mal die Freigabesettings des Servers an, siehe dazu auch:
--> https://www.thomas-krenn.com/de/wiki...dows_erstellen
Dort müßtest du schauem, welcher Client-User auf der betreffenden Freigabe was darf und nicht darf.
zu 3)
Hast du kein älteres backup/Image, daß du einspielen könntest?
Zitat von drdope
Ist das nicht das gleiche?
Wie gesagt: Ohne merkliches Ergebnis. Leere Zeile und sonst nix.
Was den Jumper angeht: Da muss ich schauen...
Ok.
Ich blicke schon folgendes nicht, hatte mir das auch noch nie detailliert zu Gemüte geführt:
Übersicht Laufwerke am Zentralklient
Laufwerk C:
Netzlaufwerk P:
Ich ging bisher immer davon aus, dass das Netzlaufwerk P ein freigegebener Ordner (und kein ganzes Laufwerk) auf dem Laufwerk C des Zentralklienten sei.
10.65.147.250 ist jedenfalls der Zentral-Klient.
Auch die identischen Laufwerkgrößen sprechen ja für denselben Datenträger, sprich die HDD des PCs.
Eine entsprechende Ordnerstruktur findet sich aber gar nicht auf dem Laufwerk C.
Wo ist mein Denkfehler?
Taucht ein Netzlaufwerk auf dem PC, der es beherbergt immer nur als Netzlaufwerk und nicht als lokales auf?
Sprich ist es quasi vermutlich als eigene Partition angelegt, die dann komplett freigegeben wurde?
Ähm. Nein. Nur das Image vor der Migration der SSD.
Ein Klient-Image (im speziellen des Zentralklienten) wurde nie erstellt.
Bis neulich ging's mit dem Rollback über den Systemwiederherstellungszeitpunkt, daher habe ich mir da keine Gedanken gemacht, dass möglicherweise die Wiederherstellungspunkte dann vom System peu a peu "eradiziert" werden.
Mundus vult decipi, ergo decipiatur.
zu 1) hatte die Hoffnung, daß auf der Shell/cmd eine konkrete Fehlermeldung zu sehen ist...
Alternativ kannst du dir ja auch einen bootfähigen USB-Stick erstellen, von dem du das Bios-Update startest.
--> https://www.thomas-krenn.com/de/wiki...tick_erstellen
zu 2)
Schau dir die Freigaben am besten direkt auf dem Server (10.65.147.250) selbst an...
--> https://www.windows-faq.de/2018/08/1...erk-freigaben/
zu 3)
Doof...
Wo ich das gerade gelesen habe:
Hast du jetzt die neuen SATA Kabel und läuft es besser?Problem gelöst!
Nicht Civ6 war der Übeltäter sondern ein Sata-Kabel.
Es gibt wohl tatsächlich Ältere welche die Platte ausbremsen...
Da gehts mir doch gleich viel besser. Der Thread kann somit gelöscht werden.
Nee, ich war immer noch zu müßig für 7,50€ die Bestellung auszulösen, da bin ich ehrlich.
Ich tu's gleich...
Danke für den Push. Der Fokus liegt momentan einfach zu sehr auf "daheim" oder den größeren EDV-Kniffligkeiten auf Arbeit.
Dafür schmieren die Rechner zu selten ab. Soll trotzdem natürlich kein Dauerzustand bleiben.
Inzwischen habe ich am vergangenen Montagabend noch einmal einen Anlauf mit dem Zentralklienten unternommen und per bisher irgendwie übersehenem Button "weitere Wiederherstellungszeitpunkte anzeigen"
Der Scannertreiber hat sich nach 3 problemlosen Tagen dann heute wieder verabschiedet, was ja immer ein "Vorbote" war...
Im selben Atemzug habe ich mich dann am Montag bei der Suche nach einer sinnvollen Umsetzung eines HDD-Backups mit Veeam auseinandergesetzt und einfach mal ein Image von Zentralklienten generiert, das jetzt auf dem NAS schlummert.
(wobei letzteres schon biestig ist/war, da ich nicht ohne weiteres eine "Freigabekonfiguration" gefunden habe, mit dem ich aus der Backup-Software heraus oder der Netzwerkumgebung von Win10 das NAS überhaupt habe auffinden können, Stichwort SMB, das sprengt meine vorhandenen Kenntnisse dann ohne weiteres Zutun doch mal wieder...).
"Am Ende" hat es aber dann geklappt und zumindest die Software hat nicht über mich gemeckert, als sie einmal über den Zentralklienten gelaufen war.Jetzt müsste ich natürlich irgendwann auch mal den Ernstfall proben und eine Rückeinspielung testen, gell...?
Mundus vult decipi, ergo decipiatur.
Wäre sinnvoll."Am Ende" hat es aber dann geklappt und zumindest die Software hat nicht über mich gemeckert, als sie einmal über den Zentralklienten gelaufen war.
Kannst es ja auch testweise auf eine der alten HDDs zurück spielen und dann schauen, ob dort die Instabilität/Freezes auch auftreten.
Falls ja -> der Fehler liegt doch bei Win10 und/oder deiner Upgrade-Install...
Fall nein -> der Fehler ist im Umfeld der Hardware (SSD/Kabel/MB-Bios/SSD-Firmware bzw einer Kombination selbiger zu suchen)...
Ist eine Idee.
Ich schaue mal, wann mir der nächste Klient einfriert und dort kann ich ja mal die Zeit zurückdrehen.
Wobei ich auf den ersten Blick etwas verwundert war beim Blick auf die Image-Datei, die Veeam generiert:
Schaut so aus als ist das Dateiformat/die Dateiendung eine Software-spezifische und ich kann auch nur mit einem Bootstick samt dieser Software das Image wieder zurückaufspielen, richtig?
Beim Server-HDD-Backup per Clonezilla damals fiel mir das nicht so auf, ich dachte die hießen alle *.iso und so...habe aber auch nicht konkret drauf geachtet.
Oder irre ich und Images haben klassischerweise doch alle das gleiche Format?
Mundus vult decipi, ergo decipiatur.
Du brauchst für jede Image-Anwendung ein Bootmedium, daß diese zurück spielen kann.
OpenSource-Kram setzt auf offene Standards, proprietäre nutzen eigene Standards...
"Standards"....
Ok. Irgendwie war ich da der Ansicht, dass ich natürlich irgendwo in ein OS vom USB-Stick oder von DVD hinein booten muss, aber dass ich dann noch eine spezifische Software benötige war irgendwie nicht mit auf meinem Horizont ersichtlich...
Also besser doch mal der Erinnerung von Veeam folgen, dass ich den Bootstick noch generieren müsste.
Ich dachte halt mit meinem Clonezilla-Stick bin ich fein raus und brauch' das nicht mehr...
Mundus vult decipi, ergo decipiatur.
Einer der Klient-PCs ist heute wieder eingefroren. Wie ich dann merkte war es allerdings einer der beiden, die zuletzt nicht das BIOS-Update über sich ergehen lassen wollten. Nachdem ich vor ein paar Tagen Windows-Updates wieder zugelassen habe ging unter der aktuellen und geupdateten Installationskonfiguration das BIOS-Update problemlos.
Update ist nun drauf, auf ein neues: "Warten"...
Ich berichte derweil diese Woche noch die komplette Geschichte mit der Telekom...
Mundus vult decipi, ergo decipiatur.
Berechtigungen
Zitieren
