Synology Secure Erase – Probleme mit „gesperrten“ Western Digital WD20EFRX-Festplatten

Wie viele andere Nutzer auch wollte ich vor dem Verkauf meines NAS von Synology auf jeden Fall die darin enthaltenen Festplatten ordentlich und sicher löschen. Schließlich hat man auf dem NAS so einige Daten liegen, von denen man am Ende nicht möchte, dass diese wieder herzustellen sind.

So landet man schnell im Menü von Synology DSM bei einem Punkt der da heißt „Secure Erase“. Synology schreibt dazu auf seiner Hilfeseite folgendes:

Secure Erase ausführen:

  1. Gehen Sie zur Registerkarte HDD/SSD.
  2. Wählen Sie ein Laufwerk aus und klicken Sie auf Aktion > Secure Erase.

Hinweis:

  • „Secure Erase“ kann auf Festplatten in Expansionseinheiten nicht durchgeführt werden.
  • „Secure Erase“ löscht endgültig alle Daten auf Ihrer Festplatte. Stellen Sie sicher, dass die ausgewählte Festplatte nicht verwendet wird und die Daten gesichert wurden, bevor Sie fortfahren.
  • Wenn das System „Secure Erase“ durchführt, wird die ausgewählte Festplatte vorübergehend gesperrt und automatisch entsperrt, wenn der Vorgang abgeschlossen ist.
  • Wenn „Secure Erase“ während der Ausführung unsachgemäß angehalten wird, können Sie „Secure Erase“ direkt auf der Benutzeroberfläche erneut ausführen. Wenn die Festplatten entfernt oder anderweitig verwendet werden, wenn sie noch gesperrt sind, müssen Sie das Kennwort „Synology“ eingeben, um sie zu entsperren.

Das hört sich alles erstmal prima an. Die böse Überraschung kommt dann ein paar Stunden später: um zu kontrollieren, ob der Löschvorgang erfolgreich war, hatte ich die 4 Platten aus dem NAS ausgebaut und in einen PC eingebaut. Dort waren die Platten allerdings nicht mehr ansprechbar und meldeten unter anderem I/O_Fehler.

Also erstmal ein paar Grundlagen, um überhaupt zu verstehen, was passiert war. Die ATA-Spezifikationen sehen in der Tat einen Vorgang vor, den auch Synology in seinem NAS nutzt, um Platten sicher zu löschen. Hintergründe zum „Secure Erase“ findet man z.B. unter https://en.wikipedia.org/wiki/Parallel_ATA#HDD_passwords_and_security

Nun ist es offensichtlich so, dass aus welchen Gründen auch immer diese Funktion in den Synology-NAS mit manchen Platten und unter manchen Kombinationen aus Softwareversion der dazu eingesetzten Werkzeuge nicht optimal funktioniert. Die Platten werden zwar gelöscht, allerdings nicht mehr ordnungsgemäß entsperrt.

Wie kann man nun kontrollieren, in welchem Zustand sich die Platte befindet?

Dies kann man mit jedem Linux-System und dem Tool „hdparm“ tun. Ich habe dazu eine bootbare Live-CD von „gparted“ genutzt, die bereits alle Werkzeuge mitbringt.

Schritt 1: Wir kontrollieren in welchem Status sich die Platte befindet mit

sudo hdparm -I /dev/sdX

Ersetzen Sie bitte das „X“ im Befehl durch die passende Platte in ihrem System, z.B. „a“, „b“, c“, etc. Wir erhalten ein Ergebnis, dass sich ungefähr wie das nachfolgende liest:

ATA device, with non-removable media
Model Number: TX21B10400GE8001
Serial Number: FG002VTA
Firmware Revision: PRO6F515
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
...........................
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
...........................
Security:
Master password revision code = 65534
supported
enabled
locked
not frozen
not expired: security count
supported: enhanced erase
284min for SECURITY ERASE UNIT. 284min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 50011731001636dc
NAA : 5
IEEE OUI : 001173
Unique ID : 1001636dc
Checksum: correct

Entscheidend sind die beiden Zeilen „enabled“ und „locked“, was bedeutet, dass die Fesplattensicherheit aktiviert ist und die Platte gesperrt ist. Jetzt haben wir zumindest die Bestätigung, wo unser Problem mit der Platte liegt.

Nun wird es spannend, denn wir sind nur noch 2 kurze Befehle vom Entsperren der Platte entfernt. Nun muss noch ermittelt werden, von welchem Hersteller die Platte ist. Bei mir trat das Problem mit Platten von Western Digital des Typs WD20EFRX auf, also einer 2TB 3,5 Zoll Version.

Um die Platte zu entsperren ist es nämlich nötig ein Master-Passwort zu kennen, mit dem sich die Platte wieder entsperren lässt. Das Passwort für Western Digital-Platten habe ich gefunden unter: https://www.forensicswiki.org/wiki/Hard_Drive_Passwords

Dort sind auch noch Passwörter von anderen Herstellern vermerkt, von denen ich aber nicht sagen kann, ob diese funktionieren. Das Passwort für Western Digital-Platten hat auf jeden Fall einwandfrei funktioniert.

Jetzt sind es nur noch 2 kurze Befehle:

sudo hdparm --user-master m --security-unlock WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdX

sudo hdparm --user-master m --security-disable WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW /dev/sdX

Danach kontrollieren wir wieder mit

sudo hdparm -I /dev/sdX

und freuen uns über die nachfolgende Ausgabe, in der dann stehen sollten „not enabled, not locked, not frozen, etc.)

Viel Erfolg!

Bezeichnung der Netzwerkschnittstellen unter Ubuntu von z.B. „enp0s25“ oder „ens33“ umstellen auf „eth0“

Ubuntu benennt seit 16.04. die Netzwerkschnittstellen anders. Die Bezeichnungen können dabei z.B. lauten „enp0s25“ oder „ens33“ es gehen aber auch andere Namen, da Ubuntu die Karte nach einem Schema benennt, welches auf die Hardwareumgebung des jeweiligen Rechners zurückgreift. So bezeichnet etwa „enp0s25“ den PCI-Bus „0“ Slot „25“.

Ich finde dies weitgehend unpraktisch, gerade wenn man Skripte erstellt hat, die z.B. auf das „alte eth0“ zurückgreifen. All dies funktioniert dann nicht mehr.

Wie kann man die neue Bezeichnung nun wieder auf das alte „ethX“ umstellen?

Folgende Schritte:

  1. $ sudo nano /etc/default/grub
  2. In der Zeile „GRUB_CMDLINE_LINUX“ folgendes hinzufügen:
    GRUB_CMDLINE_LINUX=“net.ifnames=0 biosdevname=0″
  3. Danach GRUB neu konfigurieren:
    $ sudo grub-mkconfig -o /boot/grub/grub.cfg
  4. Nicht vergessen unter: /etc/network/interfaces die passenden Bezeichnungen entsprechend auf eth0, eth1, etc. abzuändern……
  5. $ sudo reboot

Fertig. Den Erfolg der ganzen Aktion kann man nach einem Reboot kontrollieren mit z.B.:

$ ip a

oder

$ ifconfig

HIKVISION Kamera – Einzelbild abrufen

Mit dem nachfolgenden Link kann man auf einer HIKVISION Kamera ein einzelnes Bild abrufen:

http://USER:PASSWORD@IP:PORT/Streaming/channels/1/picture?snapShotImageType=JPEG

Seit dem Firmware-Update auf 5.5.0 gibt es noch eine Einstellung „Hikvision CGI aktivieren“ zu beachten, die standardmäßig deaktiviert ist. Die muss man noch anschalten, dann funktioniert alles.

[GELÖST] Medion Akoya E2228T: Touchpad, Touchscreen und USB-Maus funktionieren im Akkubetrieb nicht mehr richtig nach Update auf Windows 10, Version 1709 (Fall Creators Update)

[UPDATE & LÖSUNG]

Inzwischen hat Microsoft zu unten stehendem Problem einen Patch veröffentlicht. https://support.microsoft.com/de-de/help/4048955/windows-10-update-kb4048955

Den dazu passenden Download findet ihr hier:

http://www.catalog.update.microsoft.com/Search.aspx?q=KB4048955

Sobald dieser installiert ist, funktioniert wieder alles so wie es soll.

[UPDATE & LÖSUNG]

 

Bislang verrichtete das Medion Akoya E2228T klaglos seinen Dienst bei mir.  Das Gerät ist scheinbar baugleich mit dem Medion Akoya E2227T. Der Unterschied scheint darin zu bestehen ob es über ALDI Süd/Nord (E2228T) oder direkt über die Website von Medion (E2227T) vertrieben wird.

Und dann kam das Update von Microsoft Windows 10, Version 1709. Das sogenannte „Fall Creators Update (FCU).

Das Update lief problemlos durch. Doch dann fingen die Probleme an.

Symptome

  • Gerät läuft im Netzbetrieb völlig problemlos
  • Die Symptome treten alle nur im Akkubetrieb auf:
    • Das Touchpad funktioniert nicht mehr.
    • Der Touchscreen funktioniert nicht mehr.
    • Die Tastatur funktioniert nicht mehr richtig. Aktiviert sich erst wieder nach Drücken einer Taste (wird von den meisten Usern in den Foren als das „Verschlucken“ des ersten Tastendrucks beschrieben)
    • Eine in der Not angeschlossene USB-Maus schaltet sich nach 1-2 Sekunden Nicht-Nutzung ab und lässt sich nur durch „Klicken“ wiederbeleben. Sobald man sie wieder nicht nutzt, schaltet sie sich wieder ab.
    • Die Power-LED fängt an zu blinken

So ist das Gerät natürlich nur sehr eingeschränkt zu nutzen, denn der Sinn eines Notebooks ist ja der mobile Betrieb ohne Netzstecker.

Fängt man das Problem an zu googeln, so findet man auch etliche andere Notebooks anderer Hersteller, die von dem Problem seit dem Update von Microsoft betroffen sind. Also irgendwas ist wohl schief gelaufen ….

Lösungsansätze von Medion

  • Medion hat das Problem zumindest bislang im Community-Forum von Medion bestätigt. https://community.medion.com/t5/Notebook-Netbook/E2227T-MD60713-Win10-update/td-p/47878
  • Es gibt aber noch keine offizielle Lösung. Medion vertröstet und weist darauf hin, dass Sie am Problem dran sind und sobald es eine Lösung gibt, diese dann verkündet wird. Mal schauen und abwarten.
  • Inzwischen gibt es einen Patch von Microsoft (siehe oben) der das Problem behebt.

Workaround

  • Es gibt aber bestimmt Menschen, die auf das Gerät angewiesen sind und nicht warten können. In verschiedenen Foren kursiert ein Workaround der über das Verändern verschiedener Registry-Werte das Problem zumindest eindämmt.
  • Man schaltet damit der „Enhanced Power Management“ für das Touchpad, den Touchscreen und den Fingerprintsensor ab. Danach funktionieren die Geräte auch im Akkubetrieb wieder normal.
  • Manche User in den Foren berichten danach über Probleme beim „Sleep-Modus“ ihres Geräts und dem danach folgenden „Aufwachen“. Das erstaunt jetzt nicht besonders, wenn man an den Werten des Enhanced Power Managements herumspielt. Aber für denjenigen der das Gerät zum Arbeiten benötigt ist dies unter Umständen zu verschmerzen.
  • Anbei die zu verändernden Registry-Werte:
    1. TouchscreenHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\FTSC1000\4&34076dda&1\Device Parameters\EnhancedPowerManagementEnabled [von 1 auf 0 ändern]
    2. Tastatur: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0911&PID_2188&MI_00\7&8614ad5&2&0000\Device Parameters\EnhancedPowerManagementEnabled [von 1 auf 0 ändern]

    3. Touchpad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0911&PID_2188&MI_01\7&8614ad5&2&0001\Device Parameters\EnhancedPowerManagementEnabled [von 1 auf 0 ändern]
    4. Fingerprint-Sensor:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_04F3&PID_0C16&MI_01\7&2d36603e&0&0001\Device Parameters\EnhancedPowerManagementEnabled [von 1 auf 0 ändern]

In Outlook 365 fehlt der Ordner „Alle Nachrichten“ von Google Mail

Es kann manchmal so verdammt einfach sein, aber man muss halt einfach drauf kommen.

Mich hat schon immer total genervt, dass in Outlook 365 mit verbundenem Account von Google Mail, der Ordner „Alle Nachrichten“ fehlte. So war Outlook für mich immer nicht richtig nutzbar, denn ich nutze sehr gerne die Funktion „Archivieren“ in Google Mail für diejenigen Mails die man zwar aus der Inbox rausschieben aber nicht löschen, eben „archivieren“ möchte.

Nun gibt es ja einen schicken Button in der Menüleiste von Outlook 365 der einem anbietet Nachrichten zu „archivieren“:

Nur leider taucht dann im Folgemenü, wenn man „Vorhandnen Ordner auswählen“ anklickt.

Eben genau nicht der Ordner „Alle Nachrichten“ von Google Mail auf. So kann man auch nicht den „Archivordner“ den Google nutzt wählen und das alles erscheint einem reichlich nervig.

Beim rumprobieren bin ich dann auf einen wirklich nicht offensichtlichen Zusammenhang gestoßen. Legt man unter dem Eintrag „[Gmail]“ nämlich einfach den Ordner „Alle Nachrichten“ an, so klappt das einwandfrei auch in Outlook 365:

Ist der Ordner angelegt, dann synchronisiert sich auch wie von Zauberhand der Ordner mit Google Mail und noch viel besser, dann kann man ihn auch als Archivordner auswählen.

Möchte man irgendwann mal einen anderen Archivordner auswählen so geht das hier:

Viel Spaß!

Kaspersky Antivirus macht kein automatisches Update der Virusdatenbank

Seit längerem wunderte ich mich über ein Problem mit dem automatischen Update der Virusdefinitionen bei „Kaspersky Antivirus“ auf meinen Notebook. Mal wurde ein automatisches Update der Virusdatenbank gemacht und mal eben nicht.

Nach intensivem Durchforsten der Einstellungen habe ich das Problem jetzt klären können. Warum auch immer setzt Kaspersky in den Einstellungen im Reiter „Leistung“ einen Haken bei der Option: „geplante Aufgaben bei Akkubetrieb nicht starten„. Betroffen sind dabei aber auch die automatischen Updates. Das ist ziemlich ungeschickt bei Notebooks, die man ja eher nicht so oft am Stromnetz sondern eher im Akkubetrieb nutzt.

Haken rausmachen bei der Option lässt dann auch die automatischen Updates wieder reibungslos funktionen:

Kaspersky macht im Akkubetrieb keine automatischen Updates.

 

Synology Diskstation als Netzwerk-USV-Server für Linux oder Windows-Rechner verwenden

Beim Einsatz einer unterbrechungsfreien Stromversorgung (USV) wird diese gerne an NAS-Geräte angeschlossen, um die darauf abgelegten Daten gegen Stromausfälle zu schützen.

Bei Synology Diskstations gibt es die Möglichkeit diese als Netzwerk-USV-Server zu betreiben, also die Informationen über die USV auch anderen im Netzwerk befindlichen Rechnern zur Verfügung zu stellen. Der Vorteil liegt darin, dass dann auch Rechner, die nicht direkt mit dem Kabel der USV verbunden sind, geordnet herunterzufahren, wenn der Batteriepuffer der USV zur Neige geht.

Synology verwendet auf den Diskstation die „Network UPS Tools (NUT)“. Wie man diese über das Webfrontend der Diskstations konfiguriert ist hier beschrieben.

In unserem Beispiel werden wir für einen weiteren Linux-Rechner im Heimnetz den Dienst zur Verfügung stellen und dort konfigurieren.

Schritt 1: Eintragen des neuen „USV-Clients“ auf der Synology Diskstation unter „Systemsteuerung / Hardware und Energie / USV“. Zuerst setzen wir aber noch den Haken bei „Netzwerk-USV-Server aktivieren“

Aktivieren des USV-Netzwerk-Servers auf der Synology Diskstation

Danach klicken wir auf „Zugelassene Diskstation Geräte“. Keine Sorge – auch wenn uns Synology hier mit dem Text suggeriert, dass dies nur für weitere Synology Diskstations geht: es geht auch für andere Rechner.

Schritt 2: Im nachfolgenden Dialog tragen wir dann die IP-Adresse des neuen Rechners ein, den wir als neuen Client betreiben wollen.

Hinzufügen des neuen Clients als IP-Adresse

Danach konfigurieren wir den Client. Ich beschreibe das hier für Debian/Ubuntu:

Schritt 1: Installieren von NUT

 sudo aptitude install nut

Danach konfigurieren wir nut zuerst mit:

 sudo nano /etc/nut/nut.conf

und setzen dort die Einstellung, dass wir NUT im Client Mode nutzen wollen:

 MODE=netclient

Danach verweisen wir dann in der Datei:

 sudo nano /etc/nut/upsmon.conf

auf den Synology USV-Netwerk-Server:

 MONITOR ups@192.168.178.3 1 monuser secret slave

Selbstverständlich ersetzen sie hier die IP 192.168.178.3 durch ihre passende IP ihres Netzwerk USV Servers.
Danach starten wir NUT auf dem Client neu mit:

 sudo service nut-client restart

Und kontrollieren per:

 sudo upsc ups@192.168.178.3

ob die Verbindung klappt. Tut sie das, liefert der obige Befehle eine ähnlich Ausgabe wie diese hier:

Init SSL without certificate database
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: not set
battery.mfr.date: 2015/01/16
battery.runtime: 1447
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 13.7
battery.voltage.nominal: 12.0
device.mfr: APC
device.model: Back-UPS ES 700G
device.serial: 
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.version: SDS6-0-8445-factory-repack-8445-160817
driver.version.data: APC HID 0.95
driver.version.internal: 0.38
input.sensitivity: medium
input.transfer.high: 266
input.transfer.low: 180
input.transfer.reason: input voltage out of range
input.voltage: 230.0
input.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 871.O3 .I
ups.firmware.aux: O3
ups.load: 21
ups.mfr: APC
ups.mfr.date: 2015/01/16
ups.model: Back-UPS ES 700G
ups.productid: 0002
ups.serial: 5B1503T03854
ups.status: OL
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d

Fertig. Bei Stromverlust melden der Netzwerk-USV-Server den niedrigen Batteriestand an die Clients weiter. Diese fahren dann per NUT sauber herunter.

Für Windows gibt es das Programm WinNUT. Dies funktioniert analog zu dem, was ich hier beschrieben hatte. Hier müssen Sie lediglich nach Installation in der Datei

%Programfiles%\WinNUT\upsmon.conf

den Netzwerk-USV-Server eintragen.

Doppelte Portweiterleitung oder: Wie kann man Rechner hinter einer Routerkaskade erreichen?

In meinem Beitrag Einrichten einer echten DMZ mit zwei Fritz!Boxen habe ich aufgezeigt, wie man mit 2 Fritz!Boxen zu einer echten Hardware-DMZ kommen kann, um sein privates Netz in eine dem privaten Netz vorgelagerte „rote“ Zone und eine abgesicherte nachgelagerte private „blaue“ Zone unterteilen kann.

Immer wieder erreichen mich Nachfragen, ob es denn nicht trotzdem möglich sei Rechner-IPs aus dem privaten „blauen“ Netz von seiten des Internets zu erreichen?

Zu der Thematik hat auch Ernst Ahlers von der c’t aus dem heise Verlag einen schönen Artikel verfasst, den man unter Router Kaskaden aufrufen kann.

Ganz abgesehen davon, dass man sich dazu Gedanken machen sollte, ob so etwas überhaupt sinnvoll ist, so kann es doch Szenarien geben, die dies sinnvoll erscheinen lassen: z.B. eine VPN-Verbindung in das blaue Netz. Oder ein Server steht aus gutem Grund im blauen Netz und soll doch von außen erreichbar sein.

Die Lösung ist eigentlich recht einfach und Ihnen sicherlich schon in Teilen bekannt: man löst dies mit einer doppelten Portweiterleitung.

Machen wir ein einfaches Beispiel und treffen ein paar Annahmen:

  • Sie haben ihr Netz in einen „roten“ Aussenbereich und einen „blauen“ geschützten Bereich segmentiert. Es spielt dabei keine Rolle, ob sie das per Hardware-DMZ oder anderweitig gelöst haben.
  • Ihr rotes Netzwerk, dass direkt mit dem Internet verbunden ist, hat in unserem Beispiel folgende Daten:
    • Router „rot“ hat die interne IP-Adresse: 192.168.0.1
    • Router „rot“ hat auch eine externe IP-Adresse, die im Normalfall durch den Provider zugeordnet wird. Mit dieser IP ist häufig auch gerade bei DSL-Anschlüßen mit wechselnden IPs die vom Provider zugeteilt werden, eine dynamischer DNS-Dienst verbunden (z.B. selfhost.eu oder dyndns.org, etc.). In unserem Beispiel wäre dies „beispiel.selfhost.eu“
  • Ihr blaues geschütztes Netzwerk hat die folgenden Daten
    • Router „blau“ hat die externe IP-Adresse 192.168.0.254
    • Das durch den Router „blau“ verwaltete interne Netz lautet z.B. 192.168.178.XXX
  • Sie wollen jetzt auf den Rechner 192.168.178.99 auf dem in unserem Beispiel ein Webserver auf Port 80 läuft von außen zugreifen. Das ist mal der Plan – schauen wir wie wir das umsetzen…

Die Lösung: doppelte Portweiterleitung:

  1. Sie richten eine Portweiterleitung auf dem roten Router ein und zwar von Port 80 auf Port 80 mit dem Ziel 192.168.0.254 (also der externen IP unseres blauen Routers). Alle Pakete die auf dem roten Router auf Port 80 extern aus dem Internet ankommen werden mit dieser Weiterleitung an den blauen Router auf Port 80 weitergereicht.
  2. Sie richten eine weitere Portweiterleitung auf dem blauen Router ein. Und zwar von Port 80 auf Port 80 mit dem Ziel 192.168.178.99. Damit werden alle Pakete von Port 80 an den Zielrechner auf Port 80 weitergeleitet.

Sie können jetzt von extern mit der Adresse „http://beispiel.selfhost.eu:80“ auf den im blauen Netz stehenden Webserver zugreifen.

Fertig.

 

UTC und LOCAL TIME – Spaß mit der Zeit unter Debian-Linux

Eigentlich sollte man meinen, dass es in Zeiten gut funktionierender NTP-Server nicht wirklich entscheidend ist, wo die Hardware-Uhr des Rechners uhrzeittechnisch eingestellt ist. Auf UTC-Format, so wie Debian es annimmt, oder eben halt auf LOCAL-TIME-Format (also Ortszeit).

Nun kann es aber sein, dass man den Rechner z.B. zeitgesteuert über das BIOS anschalten möchte. Die Uhr des BIOS sollte in diesem Fall also auf LOCAL-TIME (Ortszeit) stehen, sonst startet der Rechner nicht zur richtigen Uhrzeit.

Dumm läuft das Ganze, wenn Debian jetzt denkt, die BIOS-Uhr würde auf UTC laufen und diese soll aber auf Ortszeit laufen.

Da sucht man sich die Finger wund, warum der Rechner z.B. immer im eine Stunde falsch startet, denn bei jedem „shutdown“ schreibt Debian die aktuelle Systemzeit in die BIOS-Uhr zurück. Da Debian in UTC denkt, schreibt er damit immer die falsche Zeit ins BIOS zurück.

Wo stellt man es um?

Unter: /etc/adjtime stellt man die Vorgabe „UTC“ auf „LOCAL“ um und hat mit dem Problem Ruhe.

Windows 10 Upgrade manuell anstoßen

Voraussetzungen: eine sauber lizenzierte Version einer upgradefähigen Windows-Version (z.B. Windows 7 oder 8, 8.1)

Schritt-für-Schritt-Anleitung:

  1. Download des Media-Creation-Tools von Microsoft unter diesem Link von Microsoft
  2. Media-Creation-Tool ausführen und Upgrade starten