Autoren-Archiv: weed

Problem

Der Bitlocker-Assistent läuft fehlerfrei durch, legt den Recovery-Key ab bricht im letzten Schritt mit dieser Meldung ab:

Das System kann die angegebene Datei nicht finden

Lösung

Es hat wahrscheinlich bereits einen fehlgeschlagenen Verschlüsselungsversuch mit angelegtem RecoveryAgentKey gegeben. Dieser muss entfernt (oder umbenannt) werden, bevor der Assistent einen neuen erfolgreich ablegen möchte. Die Datei nennt sich ReAgent.xml.

• CMD „als Administrator“ starten

  C:\> pushd %windir%\system32\recovery

  
  

  C:\> ren ReAgent.xml ReAgent.old

Danach funktioniert der Assistent sofort wieder wie er soll.

Problem

Bitlocker lässt sich auf neuen Geräten nicht aktivieren. Nachdem der Einrichtungsassistent den Recovery-Key (scheinbar) erfolgreich abgelegt hat, startet Windows 10 zur Überprüfung neu und meldet:

Der Bitlocker-Verschlüsselungsschlüssel konnte nicht aus dem TPM abgerufen werden

oder auch (noch irritierender):

Der Bitlocker-Verschlüsselungsschlüssel konnte nicht aus der PIN abgerufen werden

Lösung

Sofern die Ausgangsvoraussetzungen (BIOS aktuell, TPM2.0, Windows 10 1803+) gegeben sind, gibt es eine Ursache über die wir recht oft gestolpert sind. die Meldung „… konnte nicht abgerufen werden …“ ist eventuell etwas irreführend.

Die betroffene Maschine wird aller Warscheinlichkeit nach nicht auf einer GPT-Partition gestartet, sondern via BIOS im Legacy-Mode. Das ist praktisch immer bei Notebooks der Fall, die mit Windows 7 in einer windows 10 Upgrade-Version aufgeliefert werden.

Man kann die Bitlocker-Bereitschaft des TPM via Powershell (oder tpm.msc) ablesen:

PS C:\> Get-Tpm | Select-Object tpm* | fl
            TpmPresent : True
            TpmReady : False

Sollte das der Fall sein, hilft entweder die Umstellung im BIOS und eine Windows-Neuinstallation, oder die Umstellung des bestehenden Windows auf GPT-Boot.

Windows 10 ohne Datenverlust auf GPT boot umstellen:

1. Windows 10 Legacy Mode booten
2. CMD (als Amin):

   C:\WINDOWS> mbr2gpt /Convert /allowfullOS

3. Reboot > BIOS > Das BIOS auf „UEFI“ (oder „UEFI only“ oder ähnlich) mit CSM umstellen
4. Windows startet jetzt von der neuen GPT Partition, die Get-TPM zeigt nun TpmReady:true
5. Bitlocker kann jetzt aktiviert werden

Das klappt auch in der Recovery-Console, also zum Beispiel wenn man das Bios schon auf UEFI umgestellt hat und Windows nicht mehr freiwillig starten will. Ein Windows-Setup vom USB-Stick und der beherzte Eingriff über die Widerherstellungskonsole helfen sofort weiter.

Problem

Auf eine Datei oder einen Ordner kann nicht mehr korrekt zugegrifen werden. Oft ist das in Profilen unter Windows 7 bei umgeleiteten Ordner der Fall. Beim Zugriff auf die Datei tauch der Fehler 0x800710FE auf. Der Fehler im Windows Explorer lautet:

Fehler 0x800710FE – Auf <DATEI/ORDNER> kann nicht zugegriffen werden. Diese Datei ist momentan nicht für die Verwendung auf diesem Computer verfügbar.

Lösung

Aller Warscheinlichkeit nach ist der Offline-Cache kaputt oder nicht mehr korrekt. Warscheinlich treten auch seltsame ungereimtheitem im Windows SyncCenter auf, wie „3 Fehler“, die aber nicht angezeigt werden.

Es hilft in der Regel, den Cache zurückzusetzen. Wir haben diesen Fehler sehr oft bei servergespeicherten Profilen gesehen, die über 15gb groß sind. Hier ist vielleicht auch einmal aufräumen angesagt. Der CSC (Client-Side Caching) Mechanismus wurde geschrieben, als 40Gb Platten noch normal waren. Da erschienen 10% noch als viel …

1. In der Registry (als Administrator) eintragen (oder Fix direkt hier herunterladen)

   Windows Registry Editor Version 5.00
   
   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
   "FormatDatabase"=dword:00000001

2. Reboot, ein paar Minuten warten, fertig

Problem

Man hat einen Windows Server 2012/2016 Routing und RAS (RRAS) Server als VPN-Einwahlpunkt installiert. Dann hat man das L2TP/IPsec aktiviert, den Server mit einem PSK (Preshared Key) versehen und die notwendigen Port-Forwardings in der Firewall konfiguriert. Bei einem internen Test klappt das auch super – bis man endlich wieder zuhause ist und sich durch sein eigenes NAT einwählen möchte. Dann sagt Windows 10 plötzlich nur noch:

Die Netzwerkverbindung zwischen ihrem Computer und dem VPN-Server konnte nicht hergestellt werden, da der Remoteserver nicht antwortet. Das Verbindungsproblem wird möglicherweise verursacht, weil eines der Netzwerkgeräte (zum Beispiel Firewalls, NAT, Router, usw.) zwischen Ihrem Computer und dem Remoteserver nicht für das Zulassen von VPN-Verbindungen konfiguriert ist. Wendenn Sie sich an den Administrator oder den Dienstanbieter , um zu ermitteln, welches Gerät das Problem verursacht.

Lösung

Das Problem ist wahrscheinlich nicht ein „Netzwerkgerät“ zwischen dem Computer und dem VPN (Internet), sondern eine Voreinstellung von Windows 10 die einseitiges und doppeltes NAT-T verhindert.

Fix: Windows L2TP NAT Registry-Patch (herunterladen) »

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002

Auf Server und Client eintragen/ausführen + Reboot (!), fertig.

Die lange Erklärung

Sind beide Parteien (VPN/RRAS-Server und Client) jeweils hinter einem NAT versteckt (Stichwort NAT-T-Umgebung, also mit Traversal) muss man einen Registrierungswert auf dem VPN-Client-Computer und dem VPN-Server ändern.

1. Regedit als Administrator ausführen
2. Den Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent öffnen
3. Den DWORD-Wert (32bit) „AssumeUDPEncapsulationContextOnSendRule“ einfügen und auf „2“ stellen

Diese Werte sind möglich

• • 0 – (null) lässt keine Sicherheitszuordnungen hinter NAT (NAT-T) zu. Dies ist der Standardwert.
  • 1 – lässt Sicherheitsassoziationen mit Servern zu, die sich hinter NAT-Geräten befinden (einseitiges NAT, Server).
  • 2 – lässt Sicherheitsassoziationen mit Servern zu, wenn sich Server und Client hinter NAT befinden (zweisitiges NAT-Traversal).

Unserer Meinung nach könnte Microsoft hier einen etwas sinnvolleren Standardwert vorgeben … zum Beispiel „2“. Windows ist übrigens das einzige „Massenbetriessystem“ das standardmäßig kein IPsec über NAT-T unterstützt.