Archiv der Kategorie: Microsoft

Windows Update Fehler 0x800F0986 bei Cummulativem Update

Veröffentlicht am von — Keine Kommentare ↓

Bei der Installation des aktuellen CU auf einem Windows Server 2019 weigerte sich Windows Update beharrlich, das Setup erfolgreich abzuschließen. Schuld war der hilfreich benannte Fehler „0x800F0986„.

Die Fehlernummer 0x800F0986 steht lauf MSEC für, ebenfalls wenig hilfreich, „Corrupted or missing system files“.

Lösung

In diesem Fall hat geholfen:

  1. Microsoft Edge installieren (war noch nicht vorhanden)
  2. Ausführen, „Als Administrator“ – wobei \\SERVERNAME\ eine „gesunde“, also erfolgreich gepatchte Maschine war:
    DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:\\SERVERNAME.EXAMPLE.TLD\C$\Windows
  3. Reboot

Danach wurde auch KB5041578 ganz ohne Fehler installiert. Was den Effekt ausgelöst hat werden wir (hoffentlich) nie erfahren.

Windows Hello (PIN/Biometrie) für Benutzer vollständig zurücksetzen

Veröffentlicht am von — Keine Kommentare ↓

Manchmal geht Windows Hello kaputt. Windows Hello verwaltet die Computerlokale Komfort-Anmeldung mit „einfachen“ PINs, Fingerabdrücken, der Gesichtserkennung und so weiter. Grundsätzlich eine nette Erfindung, welche Anmeldung an Windows etwas komfortabler macht.

Es gibt Momente, in denen das kaputtgeht. Zum Beispiel wenn sich in der Domäne (AD/AAD) die PIN-Richtlinien ändern oder sich zwei Profile widersprechen.

Die Fehlermeldungen sind leider wenig zielführend. Wir haben die Meldung „Diese Option ist derzeit nicht verfügbar“ nach der PIN-Eingabe gesehen, die Fehlernummer 0x801c0451 beim Versuch die PIN zurückzusetzen und verschiedene Fehler nach einer Biometrischen Anmeldung.

Lösung

Die einfachste Möglichkeit ist, Windows Hello radikal zurückzusetzen und sauber neu zu konfigurieren. Das geht am einfachsten, indem man den Zertifikatsspeicher von Hello vollständig zu entfernt:

Certutil -DeleteHelloContainer

Das muss im Kontext des betroffenen Benutzers passieren. Bei einer defekten Windows-Anmeldung tut es auch ein angemeldeter Administrator, der die Shell „Als Benutzer“ ausführt. Nach dem Reboot kann man Hello dann neu einrichten, als hätte es das vorher nicht gegeben.

Windows VPN Fehler „Ein interner Authentifizierungsfehler ist aufgetreten“

Veröffentlicht am von — Keine Kommentare ↓

Heute habe ich (viel zu lange) an einem interessanten Fehler herumgesucht.

Eine benutzende Person konnte sich nach einem (korrekten) Kennwortwechsel nicht mehr per VPN einwählen. Die Domänen-Anmeldung funktioniert aber, PC-Zugriff kein Problem, Dateiserver, Microsoft 365, ERP … alles mit dem neuen Kennwort kein Problem. Einzig die VPN-Einwahl funktioniert nicht mehr:

Im Ereignisprotokoll des Clients (der Server protokolliert gar nichts – auch im IASLog nicht) tauch diese Meldung „645“ von RasClient (Ereignis-ID: 20227) auf:

CoID={EE17AD36-00AF-4D2E-B293-A43EFD0E0DBA}: Der Benutzer "<NAME>" hat eine Verbindung mit dem Namen "<VERBINDUNG>" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet: 645.

Lösung

Das neue Kennwort enthielt ein ganz bestimmtes Sonderzeichen: € (Euro-Zeichen)

Windows NT4 ist schuld. Das konnte noch kein € (Euro-Zeichen). Ersetzt man das Zeichen geht’s sofort.

Details

In diesem VPN wird SSTP genutzt, also PPTP-over-TLS. Schnell, einfach, sicher, flexibel und sehr gut zu verwalten. Das bedeutet aber, dass die Authentifizierung CHAP (MSCHAPv2) nach RFC2759 nutzt. Und da gibt es schlichtweg nur ASCII im „Password“ Feld. Etwas anderes gab es 1999 unter NT4 noch nicht so richtig 🤪

Der Windows Client, NICHT der Server, prüft also die Kompatibilität mit der RFC und bricht bei der Nutzung von High-Characters sofort ab. Daher auch der interne Authentifizierungsfehler am Client.

Excel/Word „Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen“

Veröffentlicht am von — 2 Kommentare ↓

Es kommt vor, dass Benutzer beim Öffnen von Dateien aus tief verschachtelten Ordnern (oder sehr langen Pfadnamen) diese Fehlermeldung von Office-Apps wie Excel, Word oder PowerPoint erhalten:

Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen

Abgesehen von dem grammatikalischen Fehler, dass im ersten Satz das abschließende Verb fehlt (vermutlich „ist“), stimmt diese Meldung.

Lösung

Es gibt keine Lösung, aber einen Workaround.

Microsoft Office-Apps, allen voran Excel, unterstützen keine Pfade mit mehr als 259 Zeichen. Das hat mit der heiligen Abwärtskompatibilität zu tun, denn es könnte ja sein das noch ein Unternehmen auf VB-Macros aus den 90ern baut. Und mit „ein“ sind hier „100% der Fortune 500“ gemeint 😉

  • Windows local and UNC files: 260 characters
  • OneDrive / SharePoint files synced to the local drive: 260 characters
  • Online OneDrive / Online SharePoint files (opened directly in the WebApp) 400 characters

Der Workaround ist einfach: Die Excel-Web-App nutzen und die Datei direkt auf dem Sharepoint (Online) bearbeiten,

Microsoft 365 Exchange online Mailbox neu mit einem lokalen Benutzer verbinden

Veröffentlicht am von — Keine Kommentare ↓

Es kommt in Hybrid-Szenarien schon mal vor, dass ein Admin einen synchronisierten AD-Benutzer nachträglich innerhalb von Microsoft 365 mit einem Postfach versieht. Das ist nicht „supported“, das Postfach taucht nicht im Exchange ECP auf und es drohen fiese Konflikte, wenn Attribute synchronisiert werden. Außerdem kann es auf einmal doppelte Mailadressen geben, weil beide Exchange-Server auf unterschiedliche Adresslisten zugreifen.

Da sollen/müssen die Benutzer wieder auftauchen.

Lösung

Eine „offizielle“ Lösung gibt es nicht so richtig. Exchange Online verwaltet Postfächer etwas anders als der „on Premises“ Exchange, man kann daher Postfächer eigentlich nicht auf die Schnelle ab- und wieder anhängen. Vor allem nicht mit verbundenen Benutzern (Outlook oder Applegeräte).

Es gibt aber einen (bisher) ganz brauchbar funktionierenden Trick.

  • Wenn eine Mailbox in EXO angelegt wurde
  • UND diese On-Premises im ECP [noch] nicht existiert (Postfachtyp „Office 365“)
  • DANN kann man die Mailbox „noch einmal“ On-Premises als Remote-Mailbox enablen. ACHTUNG: Dabei werden die im Exchange Online erstellten Attribute (SMTP-Adressen, Kontaktinformationen, Berechtigungen …) bei der nächsten Synchronisation überschrieben.

Schritt für Schritt geht das so

  1. Exchange GUID der Mailbox aus Exchange Online holen:
    Get-Mailbox <NAME> | fl ExchangeGuid
  2. Primäre E-Mail-Adresse der Mailbox auslesen (wenn nötig):
    Get-Recipient <NAME>| fl PrimarySmtpAddres
  3. Alle weiteren E-Mail-Adressen der Mailbox auslesen (wenn nötig):
    Get-Recipient <NAME> -ResultSize Unlimited | fl @{Name="EmailAddresses";Expression={($_.EmailAddresses | Where-Object {$_ -clike "smtp*"} | ForEach-Object {$_ -replace "smtp:",""}) -join ", "}}
  4. Mailbox On-Premises „neu“ in Exchange Online enabeln
    Connect-ExchangeOnline
    Enable-RemoteMailbox <NAME> -RemoteRoutingAddress @domain.mail.onmicrosoft.com
    Set-RemoteMailbox <NAME> -ExchangeGuid <GUID AUS SCHRITT1>
  5. Im ECP (On-Premises) die E-Mail Adressen aus Schritt 2 und 3 der Mailbox wieder hinzufügen und einen „Entra ID Connect“ Sync („initial“) starten.

Wenn das erledigt ist, kann es eine Weile dauern, bis das Online-Adressbuch das Postfach wieder korrekt anzeigt. In meinem letzten Fall hier etwas weniger als 24 Stunden.