Vor allem auf neuen Windows Server 2025 DCs gibt es „Geplante Aufgaben“, die plötzlich nicht mehr funktionieren. In der Regel sind das Batch- oder PowerShell-Scripts. Die Fehlermeldung im Ereignisprotokoll lautet:
Die Aufgabenplanung konnte die Aufgabe „<JOB>“ für den Benutzer „<USER>“ nicht starten. Zusätzliche Daten: Fehlerwert: 2147943785
Lösung
Die neue Windows Server-Version respektiert nun (endlich?) standardmäßig die Richtlinie „Anmelden als Stapelverarbeitungsauftrag“. Der Fehler „2147943785“ sagt aus, dass der ausführende Benutzer nicht berechtigt ist, Stapelverarbeitungsaufträge auszuführen.
Der ausführende Benutzername muss in der passenden Richtlinie, entweder die „Lokale Sicherheitsrichtlinie“ oder in die passende Gruppenrichtlinie (empfohlen) aufgenommen sein.
Der Pfad der GPO findet sich hier:
Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinie > Zuweisen von Benutzerrechten > „Anmelden als Stapelverarbeitungsauftrag“
Microsoft versucht ja bekanntlich, mit „Outlook (new)“ den guten, alten, abgehangenen und leidlich stabilen Outlook-Client abzulösen. Allerdings macht das neue JavaScript-Programm auch nach Jahren der Anpassungen immer noch einen äußerst unfertigen Eindruck, ganz abgesehen von der (naturgegebenen) zähen Langsamkeit der Weboberfläche. Wenn man dem Feedback-Hub zum neuen Outlook folgt, sind „zufriedene Anwender“ im maximal einstelligen Prozentbereich zu finden.
Ein überraschendes neues und ägerliches Phänomen ist, dass das „neue Outlook“ den Umgang mit langen Dateipfaden verlernt hat. Wenn man eine MSG/EML/PST Datei aus einem Pfad mit 1024 oder mehr Zeichen Länge öffnen möchte, erhält man diese irreführende (und offensichtlich nicht ans neue Design angepasst) Fehlermeldung:
Die Datei „XXX“ konnte leider nicht geöffnet werden. Sie sind nicht berechtigt, die Datei zu öffnen, oder die Datei ist leer.
Lösung
Inhaltlich ist das natürlich Unsinn, der Benutzer und praktisch alle anderen Windows-Apps (Notepad, Word, Excel, Outlook …) können die Datei problemlos öffnen. Nur das neue „Outlook (new)“ nicht. Verschiebt man die Datei an einen „kürzeren“ Ort, verschwindet das Problem aber sofort.
Microsoft Outlook, Excel und Word 365 aus den „Microsoft Apps for Enterrprise“ (früher Office Apps) stürzt seit Freitag in der Version Build 16.0.18324.20168 mit der „Programm reagiert nicht“ ab. Das passiert unter Windows Server 2016, beispielweise auf einem RDS (früher Terminalserver).
Die vorherige Version der „Microsoft Apps for Enterprise“ Office Version Build 16.0.18324.20168 funktioniert hingegen ohne Probleme.
Lösung
Lange Rede, kurzer Sinn: Ein aktuelles Microsoft Edge Update sorgt dafür, dass die Office-Apps unter Windows Server 2016 jetzt crashen. Schuld ist die neue Version der react-native-win32.dll.
Wir hoffen. Microsoft verklagt uns nicht, sondern repariert das defekte Update schnellstmöglich. Die Datei ist auch sicher echt, die Datei-Signatur ist intakt (SHA256: b15ea215d8cbb213c98a4d4ee45a2f42de07f5819a26394c40debae388882dae). Diese Lösung ist natürlich NICHT offiziell supported und wir warten auf ein repariertes Update von Microsoft.
⚠️ Wichtig: Die MP3-Endung der Datei ist aus Gründen da, aber das ist eine ganz normale ZIP-Datei. Einfach die MP3-Endung entfernen 😉
Update
Nach nur wenigen hundert Supportfällen, hat Microsoft das Problem anerkannt 👍
Die offizielle Meldung im Service-Portal: „Benutzerbeeinträchtigung: Microsoft 365-Anwendungen können auf Windows Server 2016 und 2019 Geräten unerwartet abstürzen.“
Während wir uns auf die Minderung konzentrieren, empfehlen wir betroffenen Kunden, ein Update zu erzwingen, um auf Version 2411 (Build 18227.20162) zurückzusetzen. Dies kann auch durch folgende Schritte erreicht werden:
Öffnen Sie die Eingabeaufforderung „als Administrator“
Führen Sie den folgenden Befehl aus: cd "C:\Program Files\Common Files\microsoft shared\ClickToRun"
Führen Sie den folgenden Befehl aus: OfficeC2RClient.exe /changesetting Channel=Broad
Führen Sie den folgenden Befehl aus: OfficeC2RClient.exe /update user
Ursache: Ein kürzliches Office-Update, das das React Native-Framework integriert, um bestimmte Funktionen in Microsoft 365-Anwendungen zu unterstützen, hat ein Problem eingeführt, das zu dieser Beeinträchtigung führt.
Update: Im FSLogix-Paket haben sich Pfade geändert, die unnötige Fehlermeldung zu Beginn ist entfernt und die Pfade sind angepasst.
Leider ist FSLogix nicht in Windows-Update(s) enthalten. Der Admin einer RDS-Farm muss also selbstständig für seine Updates sorgen.
Da es aber in der Tat häufiger mal Updates für FSLogix gibt (Siehe Hotfix-Liste), die beispielsweise Fehler mit der Microsoft Office 365 Aktivierung beheben, lohnt es sich diese auch wirklich zu installieren. Man kann das Setup in derselben Version auch mehrfach ausführen, es wird nur installiert, wenn wirklich etwas Neues dabei ist.
Der Vorgang ist prinzipiell einfach: Neue Version herunterladen, ZIP-Datei auspacken, App-Installer ausführen und Server neu starten. Wäre das nicht toll, wenn das auch automatisch geht?
Lösung
Bei dem letzten Einsatz, der das Problem „Leeres Microsoft 365 Anmeldefenster“ behebt, ist ein PowerShell Script das selbiges tut entstanden. Einsatz auf eigene Gefahr ☺️
# Update FSLogix to "latest"
# [email protected]
#
# Achtung: BOOTET bei Erfolg den Server neu, ohne Rueckfrage!
# Aktuelle FSLogix-Version liegt hier
$FslogixUrl= "https://aka.ms/fslogix_download"
# Download landet hier
if ( Test-Path "C:\Windows\Temp\fslogix\install" ) { Remove-Item "C:\Windows\Temp\fslogix\install" -Force -Recurse }
mkdir "C:\Windows\Temp\fslogix\install" -Force | Out-Null
Write-Host "Download von" $FslogixUrl "... (180Mbyte)"
# Ausblenden der ProgressBar macht den Download 5x schneller
$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $FslogixUrl -OutFile "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -UseBasicParsing
# Auspacken
Write-Host "Auspacken von C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip ..."
Expand-Archive -LiteralPath "C:\Windows\Temp\fslogix\install\FSLogixAppsSetup.zip" -DestinationPath "C:\Windows\Temp\fslogix\install" -Force -Verbose
Set-Location "C:\Windows\Temp\fslogix\install\x64\release"
# Installieren + Neustart
Start-Process "FSLogixAppsSetup.exe" -ArgumentList "/install /quiet" -Wait -Passthru
In einem IIS mit ARR der andere Web-Services hinter sich schützt, tritt (gehäuft in letzter Zeit) schon mal ein „unerwarteter“ Fehler 400 auf. Im Ereignisprotokoll gibt es auch einen (ernsthaft) hilfreichen Hinweis. Der Fehler tritt gehäuft bei Sites auf, die das Angular Framework verwenden.
Eventlog Anwendung, Quelle ASP.NET 4.0.<build>, Ereignis-ID (EventID) 1309,
Event code: 3005
Event message: Es ist eine unbehandelte Ausnahme aufgetreten.
Application information:
Trust level: Full
Application Virtual Path: /
Application Path: C:\inetpub\<PATH>
Exception information:
Exception type: HttpException
Exception message: Ein möglicherweise gefährlicher Request.Path-Wert wurde vom Client (:) entdeckt.
bei System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
bei System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
Die Request URL enthält einen Doppelpunkt. Einen „gefährlichen“ Doppelpunkt!!1elf
Dass der Doppelpunkt „gefährlich“ ist, liegt grundsätzlich nicht am IIS, sondern an der RFC1738, die genau definiert, wie eine URL aussehen darf („Uniform Resource Locators“). Darin ist nämlich festgelegt, dass …
„…only alphanumerics, the special characters „$-_.+!‘(), and reserved characters used for their *reserved purposes* may be used unencoded within a URL„
Der Doppelpunkt („colon“) „:“ ist so ein reserviertes Zeichen. Die RFC wird sogar noch deutlicher: „it’s used after the protocol (http, https) and after the domain to specify a port.“
Natürlich lässt sich das Verhalten des IIS anpassen, um solche „illegalen“ Requests zu erlauben. Das sollte man aber zumindest mit seinen Security-Leuten absprechen, die Änderung ist nicht ganz ohne. Die „Lösung“ hier lädt nur die Waffe, wenn sich der Admin damit selber ins Knie schießt, ist das sein Problem 😉
Lösung
Die „richtige“ Lösung ist natürlich, in der Webseite (Web App, Service, was auch immer) korrekt zu serialisieren. Angular nutzt dazu den UrlSerializer router; richtig eingesetzt tritt der Fehler nicht auf.
Oft hat man als Admin „am anderen Ende“ aber keinen Einfluss auf die Entwicklung so einer App. Man kann daher in der Site-Konfiguration (web.config) auf dem IIS die Request-Filterung konfigurieren.
Das hier ist eine Beispiel-Konfiguration, die mehrere solcher „Eigenheiten“ umgeht.
