Es ist zwar irgendwie nett zu wissen, das man mit den aktuellen Windows Updates nun endlich auch auf seinem Windows Server (und auf Windows Server Core) vernünftig mit seinem X-Box Live Account spielen kann, aber notwendig ist das für den Unternehmensbetrieb eher nicht.
Windows Server brauchte DRINGEND unterstützung für XBox-Games
Wir wissen nicht was Microsoft dazu bewegt hat die Xbox „GameSaveTasks“ aus Server zu verteilen, zumal der Konzern selbst eher das genaue Gegenteil empfielt.
Lösung
Zum Glück kann man die entsprechenden Tasks schnell mit der PowerShell entfernen.
Ein Ressourcenpostfach (z.B. Shared Mailbox) ist in Exchange Online mit „AutoAccept“ (automatische Zusagen, AutomateProcessing) konfiguriert, damit der Kalender Besprechungsanfragen bestätigt.
Die Besprechungsanfragen werden auch korrekt automatisch angenommen. Der Besprechungsbetreff wird im Postfach des Organisators auch angezeigt.
Aber alle anderen Benutzer (mit Berechtigungen auf dem Postfach) sehen statt des Besprechungsbetreffs nur den Namen des Organisators.
Lösung
Dies ist das Standardverhalten von Exchange Online (und Exchange seit 2010) und seither irritierend. Das passiert immer dann, wenn AddOrganizerToSubject und/oder DeleteSubject auf True festgelegt sind.
Windows 11 bietet per Rechtsklick ein „neues“ Kontextmenü im Explorer an, das um alle wichtigen Funktionen beschnitten wurde. Wer das, wie wir Admins, ebefalls nicht mag, kann auch weiterhin das „alte“ Menü von Windows 10 nutzen.
Lösung
Im Explorer (und Desktop) kann man die Tastenkombination Shift+F10 nutzen, um das alte Kontextmenü sofort zu öffnen.
Ab Windows 11 Version 22572 reicht sogar das einfache drücken von Shift aus, um das gute alte Kontextmenü aufzurufen.
Wer nur das alte Kontextmenü nutzen möchte, kann mit einer schnellen Änderung in der Registry das Default-VErhanlten ändern.
Ein WSUS-Server mag keine Updates mehr ausliefern. Wir haben das bei „alten“ WSUS-Setups gesehen, aber auch bei nagelneu und ganz frisch installierten Server-Rollen.
Auf den (Windows 10) Clients gibt es nur die wenig hilfreichen Windows-Update Fehlermeldung 0x8024401f gegen die auch kein „Troubleshooting“ hilft:
Auf dem WSUS-Server hingegen sagt das Ereignisprotokoll unter „Anwendung“ mit dem Fehler 1309 zumindest etwas mehr aus, wenn auch sehr kryptisch:
Event code: 3005
Event message: Es ist eine unbehandelte Ausnahme aufgetreten.
Event sequence: 4
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/2062417591/ROOT/ClientWebService-1-132949411067470524
Trust level: Full
Application Virtual Path: /ClientWebService
Application Path: C:\Program Files\Update Services\WebServices\ClientWebService\
Machine name: SRV-DC01
Process information:
Process ID: 10664
Process name: w3wp.exe
Account name: NT-AUTORITÄT\Netzwerkdienst
Exception information:
Exception type: InvalidCastException
Exception message: Das Objekt des Typs "System.Web.Compilation.BuildResultCustomString" kann nicht in Typ "System.Web.Compilation.BuildResultCompiledType" umgewandelt werden.
bei System.Web.UI.WebServiceParser.GetCompiledType(String inputFile, HttpContext context)
[...]
Lösung
Ab WSUS3 mit allen Updates und „einigen“ Clients, schlägt bei gleichzeitigen Anfragen eine Typkovertierung fehl. Das ist ein Bug im WSUS-Installer, der die Anwendung fälschlicherweise mit der klassischen (meint: Typenstrenger ISAPI) Pipeline konfiguriert.
Korrekt ist die „Managed ASP.NET“ Pipeline für diesen Applikationspool:
Den IIS-Manager auf dem WSUS-Server öffnen
Link unter SERVERNAME\Anwendungspools\WsusPool öffnen
Den „Verwalteter Pipelinemodus“ von „Klassisch“ auf „Integriert“ umstellen
„Anwendungspool sofort starten“ anhaken
Man muss den Server (oder den IIS) danach nicht neu starten, die Änderungen setzt sich sofort durch und die Updates fließen wieder fehlerfrei. Oder zumindest ohne diesen Fehler.
