Windows 10 Offlinedateien zurücksetzen (reset)

Veröffentlicht am von — 8 Kommentare ↓

Problem

Manchmal macht der (prinzipiell gutmeinende) Windows 10 Offline-Cache, namentlich „Offlinedateien“ oder auch „CSC“ für Client-Side Caching, absurde Sachen. Gerne lässt sich diese fiese kleine Mimose auch durch Serverumzüge verwirren und präsentiert unlösbare Konflike im Synccenter. Es „entstehen“ auch manchmal unlöschbare Ordner, neue Dokumente kommen auf Dateiservern nicht mehr (zuverlässig) an und generell ist das was der Explorer zeigt nicht mehr das selbe was der Explorer auf dem Fileserver auflistet.

Lösung

In den meisten Fällen hilft ein Zurücksetzen des Caches. Achtung, dabei wird sämtlicher zwischengespeicherter Inhalt entfernt, man sollte also von den betroffenen Daten eine Sicherung haben.

Möglichkeit 1: Cache neu erstellen lassen (liebevolle Variante)

Einen neuen DWORD-Wert (32bit) “ FormatDatabase“ mit dem Wert „1“ erstellen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001

Danach rebooten.

Die meisten Synchronisationsfehler sind damit schon behoben. Als hätten die Programmierer des CSC geahnt das dieses transparente Caching-Konzept … „anfällig“ sein könnte.

Möglichkeit 2: Cache komplett löschen (krasse Variante)

Der Offline-Cache wohnt in %windir%\CSC. Dieser Inhalt muss komplett entsorgt werden.

  1. Als ein anderer Benutzer anmelden (man kann seinen „eigenen“ Cache nicht wärend man aangemeldet ist löschen)
  2. Besitz von „C:\Windows\CSC“ als Benutzer (keine Gruppe!) übernehmen (mit Unterordnern und Dateien)
  3. Rechte in „C:\Windows\CSC“ für den Vollzugriff vererben
  4. Ordnerinhalt komplett löschen
  5. Registry-Eintrag (siehe oben) erstellen
  6. Rebooten
takeown /r /f C:\Windows\CSC
rd /s C:\Windows\CSC
reg add HKLM\SYSTEM\CurrentControlSet\Services\CSC\Parameters /v FormatDatabase /t REG_DWORD /d 1
shutdown -r -f -t 0

AADConnect Kennwort eines Benutzers neu in das Azure AD synchronisieren

Veröffentlicht am von — Keine Kommentare ↓

Problem

Nach der „Kennwort zurücksetzen“ Aktion der Administrators einer lokalen Domäne wird das neue Kennwort eines Benutzes nicht automatisch in das Azure AD (Office 365) synchronisiert.

Der Benutzer kann sich zwar in dem lokalen AD mit seinem neuen Kennwort anmelden, in Office 365 aber weiterhin nur mit dem alten.

Ändert ein Benutzer selbser sein Kennwort (STRG+ALT+ENTF), wird das neue Kennwort sofort (max 120 Sekunden) synchronisiert.

Lösung

Von manuellen Datenbank-Änderungen an der Client-API „vorbei“ bekommt AADConnect (ADsync) nichts mit. Da es (ohne weiteres) nicht möglich ist, Kennworthashes aus dem AzureAD für einen Vergleich zu exportieren, bleiben die Kennwörter bis zur nächsten Änderung unterschiedlich.

Das Kennwort kann aber einfach manuell (nachträglich) neu synchronisiert werden.

  • PowerShell auf der AADConnect Maschine öffnen („Als Administrator“, mit ExecutionPolicy auf mindestens „RemoteSigned“)
  • Distinguished Name (DN) des Benutzers besorgen:
    • Get-ADUser NAME | select D*
  • Assistenten zur Synchronisation des Kennworthashes des DNs starten:
    • Invoke-ADSyncDiagnostics
  • Dem Assistenten folgen (2 > 3 …)

Schon fertig 🙂

Zusätzliche Neztwerke via Windows VPN erreichen, ohne „Standartgateway für das Remote Netzwerk verwenden“ (Route zu VPN hinzufügen)

Veröffentlicht am von — Keine Kommentare ↓

Problem

Über einen Windows RRAS Server soll, beispielsweise über SSTP, nicht nur der Standort des VPN Routing und Ras Servers erreicht werden, sondern zusätzliche ein oder mehrere Netzwerke über andere Router.

Das ist, nachdem man die betreffenden Routen im VPN-Server eingetragen hat, auch kein Problem. Jedenfalls bis die Funktion „Standartgateway für das Remote Netzwerk verwenden“ auf dem Client deaktiviert wird.

Die Entfernung des Hakens sorgt zwar für einen direkten Internet-Zugang auf dem Client, verhindert aber den Zugang zu den weiteren Unternehmensnetzwerken.

Lösung

Seit Windows 8 kann man via PowerShell zusätzliche Routen außer der Einwahl-Standartroute weitere Routen für jede VPN-Verbindung hinzufügen.

Add-VpnConnectionRoute -ConnectionName "MEINE VPN VERBINDUNG" -DestinationPrefix 10.42.42.0/24

Beim Herstellen einer Verbindung wird die Route mit der selben Metrik wie die VPN „Standardroute“ aktiviert.

Solche neuen Routen lassen sich mit dem Befehl Remove-VpnConnectionRoute auch wieder entfernen. Leider kann man die Routen nicht auflisten, außer durch „route print“ nach dem Herstellen einer Verbindung.
Auflisten lassen sich die Routen mit

(Get-VpnConnection "MEINE VPN VERBINDUNG").Routes

oder auch

Get-VpnConnection "MEINE VPN VERBINDUNG" | Select-Object -ExpandProperty Routes

Debian 10 apt-get update „Hash-Summe stimmt nicht überein“

Veröffentlicht am von — 6 Kommentare ↓

Problem

Es tritt „auf einmal“ der folgende Fehler auf:

Hash-Summe stimmt nicht überein
......
Es wurden 42,42 MB in 42 s geholt (42 MB/s).
Paketlisten werden gelesen... Fertig
E: Fehlschlag beim Holen von ..... Hash-Summe stimmt nicht überein
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.

Lösung

Sofern die Eintröge in der /etc/apt/sources.list korrekt sind, kann es nur apt’s cache sein. Aufräumen hilft in der Regel:

sudo apt-get clean
sudo rm -R /var/lib/apt/lists
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt-get update

Ursache

Die möglichen Ursache sind zwar techinsch vielfältig, lassen sich aber in aller Regel auf eine dieser vier Möglichkeiten eingrenzen:

  1. APT hat andere Metadaten als der server. In den meisten Fällen ist das wegen der Verwendundung von TLS eher unwahrscheinlich, aber möglich.
  2. Der Metadatensatz stimmen aufgrund eines Fehlers beim kopieren/extrahieren/widerherstellen nicht (mehr) überein.
  3. Das Repository wurde von APT genau dann aktualisiert, wenn APT ein Update ausführen wollte, oder APT hat eine veraltete Metadatei zwischengespeichert (die wegen dieses Zugriffskonfliktes nicht entfernt werden konnt).
  4. Die Debian repositories wurden gehackt und der lokale, korrekte, Hash passt nicht zur gehackten Version (unwarscheinlich)

Aktivierung des ’sa‘ Benutzers auf SQL Server Express Edition

Veröffentlicht am von — 4 Kommentare ↓

Problem

Auf neuen SQL Express Edition Installationen ist der sa-Benutzer meist noch nicht aktiviert. Per Default ist nur die Windows-Authentifizierung eingeschaltet, was die Nutzugn des SQL-Benutzer ’sa‘ verhindert.

Lösung

Zuerst aktivert man im SQL-Server die ‚gemischte Authentifizierung‘.

So ändert man den Authentifizierungsmodus des SQL Server (SQL-Authentifizierung zulassen)

  1. Ausführen des SQL Management Studio „Als Administrator“
  2. Verbindung mit der Instanz herstellen (Windows-Authentifizierung)
  3. Im Objekt-Explorer ganz oben auf das Wurzelelement (die SQL-Server Instanz) mit der rechten Maustaste die Eigenschaften öffnen
  4. Link unter dem Punkt Sicherheit unter der Serverauthentifizierung den neuen gemischten Serverauthentifizierungsmodus auswählen und mit OK bestätigen
  5. SQL-Dienst neu starten (Im Objekt-Explorer mit der rechten Maustaste auf den Server ganz oben und dann auf Neu starten)

SA-Benutzer einschalten

An der SQL-Konsole, sofern man als Administrator vernbunde ist, reichen diese beiden schnellen Befehle:

ALTER LOGIN sa ENABLE ;  
GO  
ALTER LOGIN sa WITH PASSWORD = '123NEUES_SA_KENNWORT12343' ;  
GO