Nicht UEFI-Windows 10-Installation auf UEFI aktualisieren

Nicht UEFI-Windows 10-Installationen auf UEFI-only Rechner bringen

Neue Rechner werden oft nur noch mit UEFI (Unified Extensible Firmware Interface) ausgeliefert, sodass man Betriebssysteme auf Festplatten aus älteren Legacy Geräten nicht direkt im neuen Rechner verwenden kann. Auch ein Klonen der alten Festplatte auf eine neue funktioniert nicht, da im Anschluss keine Bootdateien vorhanden sind, welche das UEFI nutzen kann. Seit Windows 10 (Version 1703) gibt es das Kommandozeilen-Tool „mbr2gpt“ was helfen kann. Da immer etwas schiefgehen kann, dieser Anleitung nur auf eigene Gefahr folgen.

Am praktischen Beispiel „alte Festplatte auf neues System klonen“ kann wie folgt vorgegangen werden:

1. Backup des Rechners erstellen (zum Beispiel ein Systemimage mit Clonezilla). Erforderlich, da im Falle eines Fehlers der Prozedur der Rechner in einem nicht-bootbarem Stand verbleiben könnte und alles zurückgesichert werden müsste.

2. Alten Rechner anschließen, Windows Version prüfen (größer als 1703)

3. Datenträgerverwaltung und die Eigenschaften der betreffenden Systemplatte öffnen (wird GPT anstatt MBR angegeben ist man bereits auf der UEFI Version)

(Zusatztipp: Nutzt man Tools wie Clonezilla sollte an dieser Stelle noch einmal sichergestellt werden, dass die neue Festplatte die gleiche oder eine größere Kapazität als die alte hat. Sollte die neue Platte kleiner sein, schlägt Clonezilla im Kopiervorgang fehl. Ist die neue Festplatte kleiner, sollte die alte per Datenträgerverwaltung oder Partitionstool so verkleinert werden, bis die Kapazität entsprechend kleiner ist.)

4. Mit gedrückter SHIFT-Taste einen Neustart durchführen

5. Im darauf erscheinenden Menü „Problembehandlung“ und dann „Kommandozeile“ wählen

6. mbr2gpt /validate /allowFullOS eingeben

Sollte dies ohne Fehler durchlaufen, kann man die Konvertierung wagen…

7. mbr2gpt /convert eingeben

Läuft dies sauber durch (Fehler bzgl. Windows PE kann man hier ignorieren) ist der Vorgang abgeschlossen. Ab diesem Punkt könnt ihr mit dem alten Rechner nicht mehr booten, sofern ihr dort im BIOS nicht auf UEFI wechseln könnt.

8. Konvertierte Festplatte auf neues System klonen.

9. Den neuen Rechner starten, Treiber installieren etc.

Das war es dann schon. Sicherheitshalber möchte ich hier nochmal darauf hinweisen, dass keine Haftung für Schäden übernommen wird und die Ausführung auf eigene Gefahr geschieht. Der Punkt 1 sollte daher keinesfalls übersprungen werden, sodass hier noch eine Wiederherstellung im Disaster-Fall passieren kann.

Sie haben einen neuen Rechner, aber möchten die Konvertierung bzw. den Umzug nicht selbst durchführen? Kontaktieren Sie uns, wir helfen Ihnen schnell, einfach und preiswert!

Volumenschattenkopien-Dienstfehler Ereignis VSS 12293 beim Backup

Fehlerbeschreibung beim Kunden: Vollbackup überspringt Dateien und sichert somit nicht den gesamten Server (MS Server 2008). Im Eventlog findet sich als Auslöser die folgende Meldung:

VSS 12293 Fehler Backup

„Volumenschattenkopien-Dienstfehler: Beim Aufrufen einer Routine auf einem Volumenschattenkopienanbieter … ist ein Fehler aufgetreten. Routinedetails EndPrepareSnapshots…“

Die von Microsoft empfohlene Fehlerbehebung mit Prüfung der VSS Provider (vssadmin list providers) und Testlauf einer Volumenschattenkopie (vssadmin create shadow) hilft hier leider gar nicht.

Lange Rede, kurzer Sinn: Nach längerer Fehlersuche stellte sich heraus, dass eine auf NTFS formattierte 4TB große Festplatte per USB am Server angeschlossen war. Kann man so machen, allerdings gibt es hier Probleme mit MS Server 2008. Um das Problem zu beseitigen, sind wir wie folgt vorgegangen:

 

  1. Kompletten Inhalt der USB-Festplatte sichern
  2. Schnellformattierung auf exFAT durchgeführt
  3. Daten zurück gespielt

Siehe da, Bingo! Im Anschluss laufen alle Backups wieder bestens und alle Dateien werden gesichert, ohne Fehler in den Logs.

Das Problem taucht übrigens bei allen Plattengrößen über 2TB mit NTFS Dateisystem auf und kann mit Umstellung auf exFAT behoben werden (Daten vorher sichern!!!).

Da muss man erstmal drauf kommen…

T-Home Entertain Fehler F104030 beim MR400

Hier Mal wieder was kurioses aus der ISP-Welt…

Seit Jahren lief ein T-Home Anschluss fehlerfrei in Bezug auf Internet, Telefonie und Fernsehen.

Nachdem der Vertrag verlängert und auf Entertain 2.0, sowie dem Media Receiver MR400 umgestellt wurde, gab es vom ersten Tag an Ruckler beim Fernsehen, welche im Fehler F104030 endeten. Außer dem neuen Media Receiver wurde dabei nichts an der Infrastruktur geändert.

Nun begann die wochenlange Support-Odyssee mit First-Level („bitte starten Sie den MR400 neu“) Second-Level („bitte starten Sie den MR400 und Ihre Fritzbox 7580 gleichzeitig neu“) und Third-Level… Niemand konnte helfen.

Plötzlich funktionierte dann IPTV über den Entertain Receiver ohne Erklärung  für mehr als eine Woche fehlerfrei nur um dann wieder mit F104030 und Rucklern auszusteigen.

Auch die nächste Supportkette wusste nicht weiter, sodass ein Techniker-Einsatz vereinbart wurde. Am Vorabend des Termins musste ein langes Lan-Kabel besorgt werden, damit eine Direktverkabelung zwischen MR400 und Fritzbox 7580 realisiert werden konnte.

Da kein Kabel übrig war, wurde kurzerhand die TP-Link WLAN Bridge aus dem oberen Stockwerk vom Strom genommen um das Kabel zu nutzen.

Der Techniker konnte am Anschluss keine Probleme finden und holte einen Speedport Smart aus dem Koffer zum testen und was soll ich sagen, es funktionierte auf Anhieb und was noch komischer war, auch in Kombination mit der Fritzbox 7580 ging es im Anschluss wieder.

Für genau eine Woche… Dann wieder Ruckler und F104030. Das das Ganze nervt, braucht man wohl nicht extra zu erwähnen.

Zwar wurde wieder eine Störung bei der Telekom hinterlegt, aber wir haben nun selber geforscht und letztlich auch das Problem gefunden.

Na, wer hat eine Idee? Des Rätsels Lösung steht bereits oben…

Mit der Firmware 6.83 hat AVM aufgrund der derzeit aufkommenden Probleme mit Entertain 2.0 und dem MR400 eine zusätzliche Diagnose/Log Funktion in Bezug auf IPTV eingebaut. Hier konnte man durch die Einträge sehen, dass das Gerät mit der IP xxx.xxx.xxx.221 den für Entertain benutzen Datenstrom geändert hat „IGMPv2 changed„… Diese IP gehört der TP-Link Bridge WR710N aus dem oberen Stockwerk welche lediglich einen PC versorgt!

 

Dann war alles plötzlich nachvollziehbar:

Am Tag der Umstellung und dem Wechsel auf MR400 war das Gerät an und es kam zum Fehler. Dann wurde es eine Woche nicht genutzt, was das Fernsehen wieder ermöglichte. Als der Fehler wieder bestand, wurde ein langes Lan-Kabel gebraucht, sodass es zum Techniker-Besuch wieder ging, da die TP-link Bridge am Abend zuvor deaktiviert wurde usw usw

Fazit: Egal, ob Ihr die Fritzbox direkt mit dem MR400 verbunden habt, so kann das entfernteste Gerät, zumindest im Moment, den Netzwerkverkehr von Entertain erheblich stören.

Da unsere WLAN Bridge ein total vernachlässigtes Gerät ist, wären wir ohne die neue Logfunktion der Fritzbox noch lange nicht auf den Fehler im Netzwerk gekommen.

Zum Abschluss nochmal die Checkliste für Störungen von Entertain und MR400:

  • Wird bei eingeschaltetem MR400 und ruckligem Bild der Datenverkehr von der Fritzbox in der Internet-Übersicht als IPTV oder Internetverkehr erkannt? Falls kein IPTV-Traffic angezeigt wird, sind wir auf der richtigen Spur.
  • Ist der MR400 direkt per Lan-Kabel verbunden? Wenn nicht, lange Leine werfen und ausprobieren.
  • Sind Router und MR400 auf dem letzten Stand? Wenn nicht Firmware aktualisieren (beim MR400 4 Mal über den hinteren Powerknopf an und ausschalten für eine manuelle Aktualisierung)
  • Schaut ins Log der Fritzbox. Gibt es dort Einträge bezüglich IGMP? Wenn ja, Gerät identifizieren und testweise ausschalten.

Habt Ihr nun ein ruckelfreies Bild, dann ist das Gerät der Verursacher. Viele Geräte lassen sich einstellen. Sucht im Menü nach Einträgen wie igmp-proxy, igmp-snooping und deaktiviert die igmp Komponenten. Falls dies nicht hilft, müsst ihr derzeit das Gerät auslassen oder ein anderes kaufen.

Wir vermuten, dass der Fehler derzeit auf Seiten der Telekom liegt, da solche Probleme nicht mit dem vorigen Entertain und Media Receiver aufgetreten ist. Vielleicht kann aber auch AVM demnächst mit neuer Firmware helfen.

UPDATE: In unserem Fall müssen wir keine neue WLAN-Bridge kaufen. Im Menu des TP-Link WR710N findet sich der entsprechende IGMP Eintrag „IGMP Proxy“, welchen wir einfach deaktivieren bzw. auf disable stellen…

Schon ist ein fehlerfreier Enteratain Betrieb möglich und wir können unsere Bridge auch wieder nutzen..

OC-Karat Performance Probleme unter Windows 7 und Windows 8 beseitigt

OC-Karat ist ein umfangreiches und stabiles Warenwirtschaftssystem, dass sich auf den Bedarf von Stapler-Vertrieben spezialisiert hat. Obwohl Funktionen und Geschwindigkeit von OC-Karat seit jeher überzeugen konnten, kam es bei unseren Kunden seit der Umstellung von Windows XP auf Windows 7 bzw. Windows 8 zu unerklärlichen Geschwindigkeitsproblemen.

„Keine Rückmeldung“ und dadurch verbundene, vom Betriebssystem erzwungene, Programmneustarts kosteten von nun an Nerven und jede Menge Zeit, was einen großen Verlust an Produktivität zur Folge hatte.

Nach langer Analyse ist es uns nun gelungen, die Geschwindigkeitsprobleme von OC-Karat bei unseren Kunden zu beseitigen! Weiße Fenster mit der Überschrift „Keine Rückmeldung“ und unerwünschte Programmneustarts gehören der Vergangenheit an. Darüber hinaus optimierten wir die Betriebssysteme weiter, sodass Windows 7 und Windows 8 nun Ihre volle Leistung zeigen und in Benchmarks Windows XP weiter deklassieren. Gleiches gilt natürlich auch für den Terminalserver-Betrieb unter Server 2008 R2 und Server 2012.

Um es vorweg zu nehmen: Wie vermutet lag der Fehler nicht in der Programmierung von OC-Karat, sondern im Kern der neuen Betriebssysteme. Da eine Umstellung von Windows XP aufgrund des abgelaufenen Supports unumgänglich ist, wird dieses Problem in Kürze noch häufiger in Erscheinung treten.

Wenn auch Sie von den Performance Problemen und Abbrüchen von OC-Karat unter Windows 7 und Windows 8 betroffen sind, sprechen Sie uns an. Wir helfen Ihnen schnell und unkompliziert zurück zu optimaler Produktivität!

Wir freuen uns auf Ihre Anfrage!

Smart-Home / KNX mit edv-alken.de

Ab sofort berät edv-alken.de seine Kunden kompetent und zertifiziert zum Thema Smart-Home / KNX. Von Planung bis Inbetriebnahme sind wir für Sie da! Die Partnerschaft mit der KNX-Organisation unterstreicht diese Qualität nachhaltig.

Mehr zum Thema finden Sie hier auf unseren Smart-Home Themenseiten.

Wenn Sie, egal ob Privat- oder Unternehmenskunde, Interesse an einer Smart-Home / KNX Anlage haben und nach einem verlässlichen Partner suchen, stehen wir Ihnen bei Planung, Umsetzung und Optimierung gerne zur Verfügung. Lassen Sie sich überzeugen! Wir freuen uns auf Ihre Anfrage!

Fehler 0x80042306 bei Backups und die Behebung unter Server 2008R2

Neues Jahr, neue Herausforderungen:

Ewig fehlerfrei mit Symantec Backup Exec gelaufene Backups schlugen plötzlich von einen auf den anderen Tag fehl. Erstes Mittel der Wahl ist dann immer ein Sicherungslauf mittels Windows Server-Sicherung, was aber ebenfalls nicht funktionierte. Die Protokollierung ergab den Fehler 0x80042306 (0x80042306-vss-wb-error-server2008r2).

Da sowohl Symantec Backup Exec als auch die Windows Server-Sicherung Volumenschattenkopien (Volume Shadow Copy Services) nutzt, muss der Fehler in dieser Richtung liegen. Nachdem sichergestellt wurde, dass Dienste und Abhängigkeiten laufen, galt es die einzelnen VSS Komponenten zu prüfen. CMD mit erhöhten Rechten aufrufen:

„vssadmin list writers“

Dies prüft die einzelnen Komponenten. Sollten hier Timeouts oder Fehler auftauchen liegt etwas im argen.

Lösungsversuch 1: Neustart des Servers

Klingt trivial, ist aber meistens der effizienteste Weg um die VSS-Writer unter Server 2008R2 wieder online zubekommen. In unserem Fall waren alle Writer nach dem Neustart wieder up and running. Nachdem die Sicherung erneut fehlschlug, stellte sich aber auch unter vssadmin list writers wieder das gewohnte Fehlerbild (0x80042306 & vsswriter timeout/error) ein.

Lösungsversuch 2: Schattenkopien löschen

Über die Zeit werden viele Schattenkopien von Geräten und Volumes erstellt, welche oft nicht mehr benötigt werden. Schlimmer noch: Fehlerhafte Schattenkopien von Volumes können ebenfalls Probleme verursachen. Ein Mittel um Schattenkopien zu säubern ist das Programm Ghostbuster. Da es sich hierbei um Tiefe Eingriffe in das System handelt und Ihr aufgrund des Fehlers wahrscheinlich keine aktuellen Backups habt, ist hier absolute Vorsicht geboten!!!

Lösungsversuch 3: Fehlerhafte Einstellung der Volume-Einstellungen

Auch wenn unter Server 2008R2 Schattenkopien deaktiviert sind, werden die Volume-Einstellungen doch im Zuge von VSS bei Sicherungen verwendet. Hier gilt es die Einstellungen der Laufwerke zu prüfen. Rechtsklick auf ein Laufwerk im Arbeitsplatz und „Schattenkopien konfigurieren“ auswählen. Nun ein Volume auswählen und Einstellungen klicken:

In unserem Fall war hier ein Limit von 32MB festgelegt (diesen Wert kann man übrigens nicht manuell eingeben, Server 2008R2 fordert hier mindestens 320MB, sodass noch zu klären ist, wie diese Einstellung zustande kam). Hier pragmatisch Vorgehen und „Maximale Größe“ für jedes Volume auf „unbegrenzt“ stellen.

Auch wenn Schattenkopien bei jedem Volume auf „deaktiviert“ steht, ist dies ein fester Bestandteil der Sicherung über VSS.

Ergebnis:

Erfolg! Windows Server-Sicherung und Symantec Backup Exec sichern nun wieder vollständig ohne Abbrüche. 0x80042306, Timeouts und Fehler bei den VSS Writern gehören nun der Vergangenheit an.