Misterjudie

Kurze Information für Administratoren von Windows-Systemen. Microsoft hat bereits zum 4. März 2026 bekannt gegeben, dass man Windows Server 2025 und Windows 11 24H2 im Hinblick auf eine GPP-Diagnose (Group Policies Preferences) verbessert habe. Mit den Updates vom Januar 2026 liefert die Ereignisanzeige wesentlich mehr Informationen für Einträge unter Windows 11 – für Windows Server 2025 soll diese Funktion später folgen.

Group Policies Preferences (GPP) sind schon immer ein leistungsstarkes Tool zur Verwaltung von Dateien, Ordnern, Laufwerkszuordnungen, Registrierung, lokalen Benutzern und Gruppen und vielem mehr gewesen, argumentiert Microsoft. Wolfgang Sommergut hat 2012 auf WindowsPro den Artikel Vergleich: Gruppenrichtlinien versus Group Policy Preferences zum Thema veröffentlicht. Von Microsoft gibt es das Support-Dokument Group Policy preferences zum Thema.

Raten bei der GPP-Fehlerdiagnose

In der Vergangenheit war das Problem bei der Diagnose von GPP-Fehlern, dass in der Ereignisanzeige nur wenige Informationen zu finden waren. Es gab nur die Ereignis-ID 4098 mit einem Fehlercode. Es wurden weder ein Objektname noch ein Pfad angegeben, es gab einfach keinen Hinweis darauf, welches GPP-Einstellungselement fehlgeschlagen ist. Administratoren konnten per Debugging-Funktion oder ProcMon versuchen, mehr zu erfahren, waren oft aber auf Vermutungen angewiesen.

GPP-Fehlerdiagnose wurde verbessert

Mit dem Update-Rollup von Januar 2026 haben die Microsoft-Entwickler nun wesentlich umfangreichere Diagnosefunktionen für Gruppenrichtlinienpräferenzen in Windows 11 24H2 und 25 H2 implementiert. Wann das Gleiche für Windows Server 2025 implementiert wird, ist derzeit noch nicht bekannt.

Das hat das Active Directory Service Team zum 4. März 2026 im Techcommunity Blog-Beitrag From Guesswork to Clarity: GPP Diagnostics Improve in Windows Server 2025 and Windows 11 24H2 offen gelegt (via).

Es gibt nun ein neues Ereignis mit der Event ID 4117 (Group Policy Preferences Diagnostic Data). Dieses Event ID 4117 wird zusätzlich zu den alten Ereigniseinträgen (z.B. Ereignis-ID 4098) protokolliert. Die alten Ereigniseinträge bleiben aus Kompatibilitätsgründen erhalten. Nachfolgender Screenshot zeigt den (alten) Ereigniseintrag für Event 4098 bei einer fehlenden Datei. 

Das neue Ereignis 4117 liefert nun den fehlenden Kontext, den Administratoren zur Fehlerdiagnose benötigen. Nachfolgend findet sich der Eintrag des Ereignisses 4117 mit genauen Angaben, welches Datei nicht gefunden wurde.

Microsoft hat im Techcommunity-Beitrag diverse Beispiele für alte und für neue Ereigniseinträge gegenüber gestellt. Die nachfolgende Tabelle listet die alten Event-IDs, die für die GPP-Diagnose existieren, und die neuen Ergänzungen für die ID 4117 auf.

Das Microsoft Team schreibt, dass die Ereignis-ID 4117 endlich die für die Diagnose von Fehlern in Gruppenrichtlinienpräferenzen benötigten Informationen liefert und das Ganze auf den neuesten Stand bringt. Microsoft will den Beitrag aktualisieren, sobald diese Ergänzungen in Windows Server 2025 integriert wurden. Frage an die Administratoren: Ist das wirklich ein so großer Fortschritt, wie von Microsoft dargestellt? Oder nutzt das eh keiner der Administratoren in der Praxis?

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros. Kommentare abseits des Themas bitte unter Diskussion. Kommentare, die gegen die Regeln verstoßen, werden rigoros gelöscht.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros. Kommentare abseits des Themas bitte unter Diskussion. Kommentare, die gegen die Regeln verstoßen, werden rigoros gelöscht.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros. Kommentare abseits des Themas bitte unter Diskussion. Kommentare, die gegen die Regeln verstoßen, werden rigoros gelöscht.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros. Kommentare abseits des Themas bitte unter Diskussion. Kommentare, die gegen die Regeln verstoßen, werden rigoros gelöscht.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.

Microsoft ist dabei, Exchange Web Services (EWS) in den Ruhestand zu schicken. Dieser Vorgang beginnt im Oktober 2026 und endet mit einer vollständigen Abschaltung von EWS im Jahr 2027. Ich hatte dies kürzlich im Beitrag Exchange Online: Zeitplan für das Ende von EWS veröffentlicht erwähnt. Nun hat Microsoft einen Beitrag veröffentlicht, wie Administratoren von Exchange Online-Tenants Apps, die EWS verwenden identifizieren und das Problem beheben können.

EWS-Abschaltung 1.10.2026 – 1. April 2027

Spätestens ab dem 1. Oktober 2026 will Microsoft ja gemäß Ankündigung beginnen, EWS in Exchange Online zu blockieren. Aber bereits ab Ende Juni 2026 wird Microsoft den EWS-Zugriff für Benutzer ohne Lizenzrechte für EWS (z. B. bestimmte Kiosk- und Frontline Worker-Lizenztypen) sperren. Dies kann dazu führen, dass EWS-basierte Integrationen für solche lizenzierten Benutzer vor dem allgemeinen Auslaufdatum im Oktober fehlschlagen.

Wie im Beitrag Exchange Online: Zeitplan für das Ende von EWS veröffentlicht erwähnt, können Administratoren während einer Übergangszeit noch wählen, ob ein Tenant EWS weiter unterstützen soll. Ab dem 1. April 2027 wird EWS vollständig und dauerhaft deaktiviert und die Steuerung über EWSEnabled für Administratoren von Exchange Online-Tenants entfernt.

Wer in seiner Umgebung Branchenanwendungen, Tools von Drittanbietern oder Automatisierungslösungen hat, die noch auf EWS angewiesen sind, muss nun zwei Dinge tun.

• Eine Bestandsaufnahme vornehmen, um die derzeitige EWS-Nutzung festzustellen.
• Einen Migrationsplan für unterstützte Alternativen (in der Regel Microsoft Graph) entwickeln.

Denn spätestens ab April 2027 werden die EWS-Apps nicht mehr mit Exchange Online funktionieren. Und wer Benutzer ohne Lizenzrechte für EWS im Bestand hat, läuft bereits im Juli 2026 in Probleme.

EWS-Apps in der Microsoft 365-Umgebung identifizieren

Die Tage hat Microsoft in der Techcommunity den Beitrag Notes From the Field: Finding and Remediating EWS App Usage Before Retirement veröffentlicht und weist in nachfolgendem Tweet darauf hin.

Es geht im Beitrag darum, die EWS-App-Nutzung vor der Stilllegung von EWS zu finden und diese Abhängigkeiten zu beheben. Im Beitrag versucht Microsoft Administratoren eine praktische Anleitung an die Hand zu geben, um herauszufinden, welche Azure AD-App-Registrierungen noch Exchange Web Services (EWS) verwenden, und was die Änderungen an den Kiosk-/Frontline-Lizenzen für eine Umstellung auf Microsoft Graph bedeuten.

Microsoft empfiehlt, aufgrund der Ende Juni 2026 auslaufenden Lizenzen zu überprüfen, ob Benutzer mit diesen Lizenzen EWS verwenden. Hier kommt die unter der GitHub-Seite Exchange-App-Usage-Reporting gelisteten PowerShell-Skripte zum Einsatz. Mittels der PowerShell-Scripte lassen sich App-Registrierungen mit EWS-Berechtigungen finden und mit den letzten Anmeldeaktivitäten zu korrelieren. So sollen Administratoren Prioritäten zur Auflösung der EWS-Abhängigkeiten festlegen können.

Die GitHub-Seite Exchange-App-Usage-Reporting enthält Hinweise zum Aufrufen des benötigten Scripts. Der Techcommunity-Beitrag Notes From the Field: Finding and Remediating EWS App Usage Before Retirement enthält Vorschläge zur konkreten Vorgehensweise.

Auch Benutzer von Outlook Classic werden wieder von einem doofen Bug geplagt, den Microsoft in die Software fabriziert hat. Der Bug führt dazu, dass der Mauszeiger ungewollt ausgeblendet wird. Kann auch OneNote oder andere MS 365-Apps treffen. Microsoft hat den Fehler endlich bestätigt.

Benutzerbeschwerden über Mauszeiger in Outlook

Auf Microsoft Learn findet sich im Q&A-Forum der Thread Why does my mouse arrow disappear while using outlook? von Anfang Dezember 2025. Ein Nutzer beklagt sich und meldet, dass sein Mauszeiger in Outlook-Classic plötzlich verschwindet. Der Nutzer schrieb “Meine Maus ist plötzlich nicht mehr sichtbar, während ich Outlook benutze” und merkt an, dass das sehr frustrierend sei. Er können jetzt ich nichts mehr finden, keine E-Mails öffnen, nichts kopieren und einfügen etc.

Der Thread hat dann einige Antworten erhalten, in dem andere Outlook Classic-Anwender dieses Problem bestätigen. Die Antworten von Seiten der Microsoft-Moderatoren sind – wie erwartet – ein Totalausfall.

Microsoft bestätigt das Problem

Nun hat Microsoft, nach über zwei Monaten dieses Problem eingestanden. Ich bin über nachfolgenden BlueSky-Post der Kollegen von Bleeping Computer auf den Sachverhalt gestoßen, den sie hier beschrieben haben.

Es gibt ein offizielles Microsoft Support-Dokument vom 19. Februar 2026 mit dem Titel Mouse pointer disappears when hovering over classic Outlook, in der Microsoft auf das Problem eingeht. Betroffen sind Nutzer von Outlook 365 Classic, wo es vorkommen könne, dass der Mauszeiger verschwindet, wenn dieser über das Outlook-Fenster bzw. die Benutzeroberfläche bewegt wird.

Microsoft hat aber eine gute Nachricht: Obwohl der Mauszeiger nicht mehr zu sehen ist,  ist der nicht weg, sondern nur unsichtbar. Die Anwendung ändert bei einer E-Mail in der Nachrichtenliste die Farbe, wenn Nutzer mit dem Mauszeiger darüber fahren. Dieses Problem wurde in geringerem Maße auch bei OneNote und anderen Microsoft 365-Apps gemeldet. Soll ja schließlich jeden treffen.

Es gibt eine weitere gute Nachricht: Nach immerhin etwas über zwei Monaten untersucht das Outlook-Team dieses Problem. Irgendwann gibt es dann sogar einen Patch zum Beheben des Fehlers – man soll die Hoffnung nicht aufgeben.

Wer vom Problem betroffen ist, soll seine M365-Mandantenadministrator bitten, einen Supportfall zu eröffnen. Die im Artikel WebView2Feedback/diagnostics/script.md at main MicrosoftEdge/WebView2Feedback genannten WebView2-WPR-Traces sollen erstellt und dem Supportfall beigefügt werden. Der Fall sollte zur weiteren Analyse und Eskalation an das Outlook-Supportteam weitergeleitet werden.

Ein Workaround für Betroffene

Wer von diesem Bug betroffen ist, kann sich am Workaround, den Microsoft vorschlägt, versuchen.

• Wenn Sie mit der Maus über die Outlook-Nachrichtenliste fahren und sich die Farbe der E-Mail ändert, wählen Sie eine E-Mail aus. Dadurch wird der Mauszeiger möglicherweise wieder angezeigt.
• Öffnen Sie PowerPoint, klicken Sie in ein bearbeitbares Fenster in PowerPoint, klicken Sie dann zurück zu Outlook und überprüfen Sie, ob der Mauszeiger wieder angezeigt wird.

Wenn das nicht hilft, soll man den Rechner mit Windows einfach mal neu starten. Jemand aus der Leserschaft von diesem Bug betroffen?

Im Oktober 2026 und Anfang 2027 läuft der reguläre Support für Windows 10 Enterprise 2016 LTSC sowie für die IoT-Version, und für Windows Server 2016 aus. Nun hat Microsoft Programme für Extended Security Updates (ESU) für diese Windows-Versionen angekündigt. Die Windows-Versionen können drei Jahre kostenpflichtiges ESU erhalten.

Im Jahr 2016 wurden drei Windows-Versionen veröffentlicht, die in den kommenden Monaten aus dem regulären Support fallen, also keine Sicherheitsupdate mehr bekommen. Es handelt sich um folgende Produkte:

• Windows 10 Enterprise LTSB 2016: 13. Oktober 2026
• Windows 10 IoT Enterprise 2016 LTSB: 13. Oktober 2026
• Windows Server 2016: 12. Januar 2027

Nun hat Microsoft zum 20. Februar 2026 im Techcommunity-Beitrag Plan for Windows Server 2016 and Windows 10 2016 LTSB end of support veröffentlicht, ist mir hier und hier untergekommen. Dort weist Microsoft erneut auf das Auslaufen des Supports für die Produkte hin. Gleichzeitigt kündigt man ein Extended Security Update (ESU) Programm für die betreffenden Produkte an.

Unternehmen, die zusätzliche Zeit benötigen, um auf neuere Windows-Versionen zu migrieren, können das Programm für erweiterte Sicherheitsupdates (ESU) nutzen, um die oben genannten Windows-Versionen abzusichern.

Windows Server 2016

Wer Windows Server 2016 nicht bis zum 12. Januar 2027 (Ende des Supports) auf eine neuere Version aktualisieren kann, hat die Möglichkeit, Extended Security Updates (ESU) für bis zu drei Jahre zu erwerben. Windows Server 2016 bekommt dann Sicherheitsupdates bis zum Januar 2030. Die Preise und Verfügbarkeit dieser ESU-Programme werden in den nächsten Monaten bekannt gegeben.

Windows 10 Enterprise 2016 LTSB

Wer diese Windows 10-Version über den 13. Oktober 2026 betreiben möchte, dann gibt es das letzte Sicherheitsupdate, kann eine ESU-Verlängerung beantragen. Microsoft wird erweiterte Sicherheitsupdates für Windows 10 Enterprise 2016 LTSB für bis zu drei Jahre bereitstellen. Die Updates werden dann bis Oktober 2029 bereitgestellt.

Erweiterte Sicherheitsupdates können im zweiten Quartal 2026 über Volumenlizenzen oder einen Microsoft Cloud Solution Provider (CSP) erworben werden. Der Preis beträgt im ersten Jahr 61 US-Dollar pro Gerät. Für Systeme, die mit Microsoft Intune oder Windows Autopatch verwaltet werden, wird der Preis auf 45 US-Dollar pro Gerät reduziert.

Windows IoT Enterprise LTSB 2016

Der Ratschlag Microsofts lautet, die Systeme so bald wie möglich auf eine neuere Version von Windows IoT Enterprise LTSC zu aktualisieren. Wer bis zum 13. Oktober 2026 kein Upgrade auf die nächste Version durchführen kann, hat die Möglichkeit, erweiterte Sicherheitsupdates für bis zu drei Jahre zu erwerben. Die Updates werden dann bis Oktober 2029 bereitgestellt.

Bezüglich Preisen und Verfügbarkeit gilt: Erweiterte Sicherheitsupdates für Windows IoT Enterprise LTSB 2016 sind nur über IoT-Originalgerätehersteller (OEMs) erhältlich. Informationen zu Preisen und Verfügbarkeit erhalten Interessierte vom Hersteller des Geräts. Wer ein IoT-OEM ist, soll sich bitte an seinen Kundenbetreuer oder IoT-Händler wenden, um Informationen zu Preisen und Verfügbarkeit zu erhalten.

Klarstellung zu ESU

Das ESU-Programm bietet ausschließlich kritische und wichtige Sicherheitsupdates (gemäß Definition des Microsoft Security Response Center). Der technische Support beschränkt sich auf die Aktivierung der ESU-Lizenzen, die Installation der monatlichen ESU-Updates und die Behebung von Problemen, die möglicherweise durch ein Update verursacht wurden.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros. Kommentare abseits des Themas bitte unter Diskussion. Kommentare, die gegen die Regeln verstoßen, werden rigoros gelöscht.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.